Call it the technology problem du jour. Whenever you reach some level of expertise in application performance management,...
you quickly find another performance challenge to conquer.
If, for example, an enterprise is able to solve application performance problems related to networks, databases and the Web, it then meets new issues in the form of J2EE servers with EJB containers or caching front ends with Ajax-style frameworks, and so on.
Chief among new challenges are Web services and closely associated service-oriented architectures (SOA), Software as a Service (SaaS) and composite applications stacks. SOA, particularly, presents a new pattern with which test and performance management planners must grapple. Most often based on XML Web services, SOA applications exchange data and do not couple systems at a binary level. SOAP was the XML protocol that initially introduced many developers to standards-based inter-application integration of the services variety.
Virtualization soon may be the next hurdle. But for many shops, Web services and SOA are the hurdle now.
Analysts affirm the view that SOA is growing and its requirements are different. IDC's Tim Grieser has written that Web services will emerge as an increasingly important management requirement. ZapThink's Ron Schmelzer tells us that continuous change is the special province of SOA. He says SOA, in fact, involves the composition of loosely coupled, heterogeneous services in an "environment of continuous change." Good SOA quality tools, Schmelzer notes, don't do just unit testing but also test whether the related schema and policy meta data are enforced. Meanwhile, Butler Group's Michael Azoff says SOA creates challenges both for developers and for operations administrators.
"Things were bad enough when you had a complex end-to-end application to manage," said Azoff. "But now that they are also composed of components that come from different sources that are brought into the application, it makes it that much more difficult to monitor. It is even more difficult to understand and to know what it is you have."
What is unique in SOA performance?
This is perhaps the most essential difference between SOA performance management and previous enterprise application integration management hurdles. You do not have control over all your components.
In SOA, applications are mashups composed at runtime with elements from various sources. Did a source component change since the last run? Did an improvement in latency for an underlying Java component uncover a new behavior in outlying Web service calls? Sometimes you don't know.
Granted, some SOA challenges are just extensions of Web challenges that IT has been dealing with for several years. Your user pool can grow unexpectedly, changing performance just as unexpectedly. The focus of new tools adept at inspecting Web message payloads is at base much like message middleware managing solutions that predate Web services. How those payloads interact with server objects is one of the deeper secrets to uncover in modern SOA performance management.
But, because Web service application elements evolve as they are used in the field, production monitoring takes on a new character and importance. Analyses of continuously monitored operations are fed back to development, which can use the data to uncover emerging bottlenecks. In a sense, development never stops. The lines between development and operations become less rigid.
New ways of testing and measuring have come into place along with Web services. Services are described by contracts (in the Web services world that typically means Web Services Description Language (WSDL) contracts), and software tools must be in place to validate services. Meta data can help ensure that services fit within corporate policies. Often described as SOA governance solutions, whole suites of governance software have developed around the services paradigm.
Among long-established application performance management software vendors such as BMC Software Inc., Borland, CA, Compuware Corp., Empirix, Hewlett-Packard, and IBM, there are several that have tailored special tool suites for SOA and Web services needs. Newer companies such as ClearApp, dynaTrace Software, iTKO Inc. and MindReef Inc. specifically targeted SOA performance management with their flagship tools.
Scoping the SOAP
It should be remembered that SOAP came before SOA, by a few months anyway. The first blast of Web services was all about XML and SOAP, the first popular Web services protocol.
For Jan Arendtsz, managing partner at Celigo LLC, keeping an eye on that XML traffic remains a main point of SOA performance management -- that and how services interact with underlying object functions.
Celigo provides technical consulting and sells software to customers of NetSuite, a maker of Web-based systems that integrate ERP and CRM, and one among notable players in the SaaS arena. Arendtsz spent the last five years working on SaaS and on-demand applications.
"The concept of SOA is built into the on-demand paradigm," he said. "We put together applications that go to different Web services. We pull the data, and we [reconstruct] it."
Arendtsz added, "We use [MindReef's} SOAPscope [Server 5.3] to capture the SOAP messages, and we can pinpoint problems. For us, the SOAP message is the key."
He said Celigo uses SOAPscope before writing any code to be able to "introspect" the WSDL, making calls to test certain behaviors. Having the SOAP message as the focus allows better communication with the outlying development teams that oversee "visiting" services.
To try to discuss Java business object issues with busy off-site third-party development teams -- although it is the object interaction with Web services that may ultimately decides performance -- is probably too much to ask for, Arendtsz indicates. By focusing on the XML messages, an aggregator of services can better discuss performance issues with a services provider.
The fact that an application integrator is not in charge of all SOA system elements is inescapable.
"There is only so much I have control over," Arendtsz said. "If a service is not snappy, there are little things I can do, but beyond that, not a whole lot, which is why SaaS is very different."
As an example of small things that can be done to improve service performance, Arendtsz mentioned processing messages in smaller chunks.
"You have to architect your application in a different way," he said. "You cannot take for granted that you can move millions of records from one point to another."
Consultant and integrator Roger Schlegel, principal at the Schlegel Group, has worked with services as part of efforts to improve performance of a healthcare provider portal. Like some others, he is more comfortable with the term "Web services" than "SOA."
"I look at SOA as a product set to a certain degree. Any Web service can be loosely associated with the term 'SOA,'" he said.
Schlegel has employed ClearApp Quick Vision tools to uncover bottlenecks in deployed services. He said one may sometimes find that the application architecture has not kept up with the type of traffic hitting a portal.
"Whether it connects pools or what have you, we find often times that it is superfluous code that is causing more processing or I/O than was required," he said. "That was the impetus for bringing in ClearApp. We didn't have a view into the system."
The tool, which correlates the services provided by applications to the underlying code components supporting those services, "significantly improved response time," Schlegel said. "We were able to find a myriad of issues."
Some flaws were very simple, such as database tables that were performing poorly. Before, these were not visible to developers and operations people. The symptoms Schlegel described show the sometimes-difficult interaction between services and underlying functions. Tables were being written to, but they were not cleaned up afterward.
"A table had grown beyond its original design," Schlegel said. "We found code looping through code that wasn't necessary. Objects were called in loops multiple times when once was enough."
Tools can help. Schlegel said software helped find cases where Web services were set up in such a way that a user would log in to a portal and the portal application would call another Web service. This would subsequently go out through proxies and load balancers to finally come back to an already-resident Web service. Upon discovering this behavior, the system was then reconfigured so this work remained local.
Note: This article Includes some material that previously appeared on TheServerSide Interoperability Blog.