Standard SOA SOAP Stacks are Key to Performance

Web Service and SOA Performance is a concern for any IT environment. Web service messages pass through multiple intermediaries, and each message must be processed in its entirety (parsing the whole message), all of which can put the brakes on message speed. But, as this worst practice illustrates, it is critical to employ standard SOA SOAP in your network.

The Idea: "I Know That It's a Standard SOAP Stack. What's Wrong with a Little Change?"

Seeking to speed up its Web service messages, the IT team at Hutchings Healthcare decided to split SOAP messages into two parts: the envelope and the body. The envelope would be passed in the usual manner, but the body would always be passed as an attachment, instead of abiding by the SOAP standard and being passed in the message.

Why It Wasn't So Smart

The IT team was using a standard SOAP stack, but in an unorthodox way. As a result, the messages and applications that used this stack were incompatible with other standards-based implementations. Although the IT team claimed that this was a standards-based SOA, they really had created a proprietary form of messaging.

The IT team mistakenly assumed that it could have an effective SOA while using mandatory proprietary "extensions." Here's why this cannot work:

1. Such extensions inhibit interoperability, which then drastically limits the scope of your SOA effort and dramatically increases the cost of the services.
2. Due to the proprietary nature of this messaging, specific code must reside on each end of the wire. You therefore need to customize all of your applications and server software.
3. The extensions prevent you from efficiently using your developer tools, which are optimized around standard SOAP stacks.
4. Web services versioning is more difficult. When ISVs update their software, the messaging technology will likely have to be updated for the revised platform.

SOAP is an open language, so by modifying it, Hutchings Healthcare was removing its value. If SOAP was not working for its SOA, the company would have benefited more by having the standard updated than by creating a proprietary solution.

A Better Approach

Performance boils down to the design of your SOA architecture. A true SOA allows you to use open standards to facilitate Web services reuse and flexibility. As a result, you are not locked in to a specific vendor or technology. Even the most heterogeneous systems can communicate quickly and easily across different software and hardware platforms. This all changes, however, once you introduce a proprietary solution, as Hutchings Healthcare did when it modified SOAP.

SOA Design: When designing your SOA, avoid the telephone game—that is, too many components and services passing the message and adding load. Instead, make sure that the components are loosely coupled and use a universal language. That way, they can avoid steps, say A to D, and go straight to step E to obtain the requested data or initiate the correct process. You then can simply flow the information you need.

SOAP is meant to be an open standard. Just as your overall service-oriented architecture is meant to employ open standards. The use of standard SOA SOAP will ensure that all of the components and services will work together well – and that you will avoid getting locked into any one vendor's proprietary technology.

For More Information

Find out why the use of standard SOA SOAP and other Web services standards are essential for the performance and interoperability of your services network: download the free webinar, SOA Introduction: IT and Business Perspectives