email article printer friendly

Troubleshoot Your SOA
Gaining visibility into a Web service helps you troubleshoot problems
by Robbie Clark

Posted July 2, 2004

Building a service-oriented architecture (SOA) involves creating multiple services in support of business practices. The advantage is that the use of multiple services can make an enterprise more flexible and better able to respond to rapidly changing competitive conditions. Building services can increase the efficiency of existing applications and make it easier to build new ones.

In many enterprises (about 70 percent, according to the Gartner Group), both Java and Microsoft platforms are employed. Ideally, this mixture of platforms shouldn't matter to the SOA. The service can be written in one platform, while the client application can be written in either the same platform or the other. That's one of the significant advantages promoted by the SOA approach to building applications—many different skills can be applied to creating services, and even legacy application components can be modified to perform as services.

In theory this is certainly true. The only required common element between the client application and the service is the ability to send, receive, and decode SOAP messages. Of course, there's a little more to it than that, in that both client and service must also agree on the schema of those messages, or provide a mechanism such as the Web Services Description Language (WSDL) to enable the client to determine the appropriate schema.

But in general the concept of loosely coupled application components requires remarkably little coordination. Assuming that the schema has been negotiated, communication between client application and service should just work.

Except when it doesn't. That may sound contradictory, but in fact it's a perfectly understandable state of affairs. Many things can go wrong with an application, often stemming from poorly developed requirements, bad design, errors in coding, and inefficiencies that lead to performance or scalability problems. All of these things, and many more besides, can happen in combination with a Web service and one or more client applications.

Here are just a few examples of some of the problems that client application developers may encounter when using Web services:

• The Web service fails entirely – the failure could mean there is a bug or object leak.
• The Web service returns the wrong answer – the incorrect answer could be a logic error or unexpected behavior.
• The Web service returns results too slowly – is the slowness because of the Web service or the database? Narrowing it down further is difficult for the application developer.
• The Web service fails to scale – in many cases, the failure to scale is because of inefficient code or bottlenecks that aren't caught until the load of a production application is applied.

These problems are compounded when the Web service uses a different platform than the client application. As mentioned previously, one of the other key advantages of Web services is that the concept is platform agnostic. Web services can be written in any language on any platform, making it problematic that any single group of developers building a client application will be able to understand and appreciate the strengths and limitations of services their applications call.