SOA Solutions and Web Services Providers

Todd Duran

Subscribe to Todd Duran: eMailAlertsEmail Alerts
Get Todd Duran: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal, SOA & WOA Magazine

J2EE Journal: Article

Making the Case for Application Service Modeling in SOA Environments

A Fortune 100 discovers visibility it didn't know was possible

Even as a $35 billion global company, our vision of SOA is no less challenging, if not unique, than that of other companies. It is vitally important to deploy an application infrastructure that allows IT to add additional services on top of an existing application without having to change the underlying foundation each and every time. Agile and extensible, today's composite applications are expected not only to align with business processes at deployment, but then to adjust to change quickly and dynamically as market pressures dictate. The more unique Web Services that can be sourced and provided to customers from "the cloud" then integrated within our fulfillment application site without recoding, the better. Yet this "last mile" of alignment - which sometimes dictates that deployed applications get reconfigured weekly or even daily - is trying to guarantee the continued delivery of business-critical services on the backs of some pretty volatile applications.

Controlling the inherent volatility of SOA is the only way we can remain able to roll out new services quicker and respond to customer needs better. For example, over the past year we've added an enhanced shopping cart, enhanced product search and order status, to name a few.

Yet in the course of implementing SOA, we identified a major "visibility gap" inherent in traditional systems management tools and application performance management solutions. Sure, these tools are great at tracking IT assets, what they're running, whether they're operating efficiently, and who's using them. But SOA's composite approach to building and delivering applications renders discovery mechanisms such as SNMP monitoring, transaction tracing, and infrastructure mapping tools pretty ineffective. The major middleware technologies that organizations invested so heavily in actually hide the key relationships between business functions - like connections between inventory, fulfillment, and accounts receivable, for example.

A recent survey of 150 IT executives by industry analyst firm Enterprise Management Associates (EMA) found that the top concerns in managing heterogeneous distributed applications were the high cost of support and the lack of available management tools. Few enterprises can track the changing relationships among workgroup servers, databases, Web servers and enterprise service buses and metadata repositories. They can see part of the overall picture, according to EMA, but the visibility gap means they can't necessarily track end-to-end performance or handle change management, and they do no Application Service Modeling. EMA found that mapping the impact of change management alone can slam an enterprise hard. "For enterprises with a highly structured IT management environment, 25% of their changes result in some kind of production problem," the report said. "For those who aren't as structured, that figure can run as high as 80%."

While a standalone APM approach will suffice for relatively simple J2EE applications, APM alone has become obsolete in monitoring and managing SOA and other complex composite applications. What these tools fail to capture are the service entry and exit points associated with a particular application or transaction. You might have application component services running on three different servers, but which handles shipping logistics versus quote functions? This gets harder to discern as applications leverage shared components on middleware platforms. These legacy tools provide visibility into the performance of code components, but they fail to correlate component performance to the performance of the application services delivered.

Why is this important? Service correlation is critical because it provides the ability to set performance metrics on particular services or business functions, and then diagnose and optimize the performance of applications on a service-by-service basis. The very purpose of an enterprise application is to provide business services, and if a problem with the performance or availability of a particular application service supported by shared application components can't be triaged quickly, the value of the application is soon overcome by the cost of outages, poor performance, and the general maintenance chaos associated with constant support. Service-oriented application complexity makes it doubly challenging to benchmark and tune performance, trace root cause of problems, and adequately plan capacity.

Common SOA Requirements Lead to a Service Modeling Approach
As many readers know, the most widely used application profiling technique is bytecode instrumentation. How it works is that the profiler inserts bytecode into each class. For CPU performance profiling, these bytecodes are typically methodEntry() and methodExit() calls. For memory profiling, the bytecodes are inserted after each new or after each constructor. All of this bytecode insertion is done either by a post-compiler or a custom class loader.

The key limitation in this technique is that once a class has been modified, it doesn't change. This lack of flexibility often causes problems down the road. If you choose to profile the entire application, the overhead of all that instrumentation can cause serious performance problems. But if you use a package or class-based filter to limit the instrumentation, you might end up not profiling an important part of the application. Further, if changing the instrumentation requires restarting the application, the profiling process slows down considerably.

In our case, the incumbent application management system in place relied purely on bytecode instrumentation. So we began our search for a better way to monitor the health of our service-oriented applications by eliminating what we know we didn't want and by defining what we did: context. Bytecode instrumentation in and of itself isn't bad, but when employed without knowing the context of the application services as delivered it's a bit like getting dressed in the dark. You can do it, but you really have no idea how you look.

The search for a solution to our visibility problem was not short on requirements. We knew what we wanted. Among other requirements, we wanted an intuitive management console, deep transaction mapping and modeling, persistent performance metrics on all components, advanced diagnosis and resolution capabilities, and historical/trend reporting. We're an IBM shop, so the solution selected had to run well on WebSphere and related middleware. Finally, any solution had to pass muster with our outsourcing vendor and deploy rapidly without needing to loop in developers or additional expert resources.

More Stories By Todd Duran

Todd Duran, director of enterprise architecture and chief architect at Ingram Micro Inc., is responsible for the company’s SOA-based architecture. He has been with Ingram Micro for nearly two years, and has over 20 years of experience in application and enterprise architecture. Prior to Ingram Micro, Duran founded the enterprise architecture and SOA disciplines at an international food service company. He was also director of systems management, data warehouse, and disaster recovery for a Fortune 40 retailer. He has managed technology teams in retail, manufacturing, distribution and financial organizations. Duran has a bachelor of arts in business management from Hope College in Holland, MI.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.