email article printer friendly

Exploring the Dark Side of SOAs
Gaining visibility into a Web service helps you troubleshoot problems
by Robbie Clark

December 17, 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 Gartner), 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 in either the same 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 which and more can happen in combination with a Web service and one or more clients.

Here's just a few examples of some of the problems that client application developers may encounter when using a Web service: it fails entirely—this could mean it has a bug or object leak; it returns the wrong answer—this could be a logic error or unexpected behavior; it returns results too slowly—is it the Web service or the database?—and narrowing it down further is difficult for the application developer; and it fails to scale—in many cases, this is due to 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.

These might sound like normal issues surrounding application development, even if the client and service platforms are different, except that the Web service is developed typically and maintained by groups other than those building the application. Application developers working with Web services lack insight into the application details, and even the platform upon which the service is built.