Scaling Web Services (SOAP) in the Back Office
Clearly, a protocol is needed that allows the interleaving of requests over a single connection. HTTP could be extended to support request identifiers, but modifications to this standard have taken years to be accepted because of the sheer number of deployments. Solving this problem within the bounds of a SOAP-based specification - WS-ReliableMessaging, for example - will always be subject to the limitations that HTTP imposes. A variety of alternatives to HTTP exist. Some are described below.

MQSeries
MQSeries is a widely deployed enterprise messaging system from IBM. It has been in production for many years and has proven its robustness and scalability in enterprise deployments. It has traditionally been used in single-threaded applications (based on the age of many deployments), but there is no reason why an application could not have multiple threads posting to the same queue, even before responses are read back from a reply queue. This would solve the problem described, but MQSeries is proprietary and expensive. It is much better suited to asynchronous communication, and demands a pair of queues for pseudo-synchronous communication.

JMS
JMS is a standard messaging interface designed as part of the J2EE specification. It does not specify any details about wire-level implementation, so two separate JMS implementations are unlikely to interoperate. With a JMS-based solution, therefore, all communication must take place using the same implementation; however, the API is widely accepted and adopted, and it's very friendly to the J2EE domain. Just like MQSeries, JMS is asynchronous, thereby allowing interleaving of requests. JMS is completely Java-centric, but many of the core back-office systems in production today are not, which means that successful integration of these systems with JMS can prove to be a challenge.

IIOP
The Object Management Group (OMG) adopted the Internet Inter-ORB Protocol (IIOP) as part of the CORBA 2.0 specification. A number of groups have adopted IIOP as their standard protocol, not least of which was Sun Microsystems, who adopted it as the standard protocol for Java RMI. Given its CORBA heritage, a number of IIOP implementations exist in a variety of languages. The variety of available IIOP implementations covers the range of commercial, free, and open source software. Most implementations of IIOP have matured to a point where they interoperate seamlessly with each other, and IIOP has proven itself in some of the most demanding environments such as telecommunications provisioning and network management. IIOP offers support for multiple qualities of service, including optimal delivery of large messages over TCP/IP (which would be ideal for SOAP). Just like HTTP it natively supports a request-reply paradigm, but in addition it allows for the interleaving of requests, replies, and fragments thereof, all over a single connection.

SOAP over IIOP
IIOP presents a very strong case for adoption as the protocol of choice within the back office. It's one of the few standards-based protocols (thus offering a wire-level interoperable transport) proven to scale in the enterprise. If one wanted to build a Web services framework that supported SOAP messages over IIOP, integrating open-source projects such as Apache AXIS with the JDK IIOP stack might do it.

The Need for an Enterprise Service Bus
A key difference between a Web services toolkit and an Enterprise Service Bus (ESB) is the ability to switch message format and protocol as necessary. For the sake of this discussion, we are talking only about switching the underlying protocol used to deliver SOAP messages, and we're working under the assumption that there is no need to integrate with legacy systems that expose endpoints with other message formats. The programming model should insulate developers from the protocol and transport, which should instead be a deployment option as opposed to a decision made at development time.

Most ESBs, with minimal additional development effort, allow you to build distributed systems that communicate using any of the following:

• SOAP over HTTP
• SOAP over MQSeries
• SOAP over JMS

An ESB must also allow you to expose your business logic over more than one protocol/transport. In particular, it should be capable of exposing the endpoint over an enterprise-strength transport without sacrificing support for SOAP/HTTP. The vast majority of data (in the back office) should be transmitted over an enterprise-strength transport while still allowing for use of SOAP/HTTP where applicable. The forthcoming WS-Addressing standard from W3C will support metadata within its endpoint reference (EPR) construct, thus making it possible to describe and reference endpoints regardless of the protocol and transport used.

In some cases, however, you will not be able to control the volumes of requests coming from SOAP/HTTP-based clients. In such situations the ESB should provide you with a relay that accepts SOAP messages over the HTTP transport and sends them over the enterprise-strength transport to the ESB-enabled back-office server. This is effectively a concentrator implementation, instance-pooling inexpensive relays (typically behind a hardware HTTP load balancer) rather than attempting to create pools of expensive and complex back-office systems.

In the past there was a barrier to accessing back-office systems in the learning curve associated with the middleware technologies involved. With the advent of Web services, this barrier has been lowered substantially; this is a step in right direction and is essential for effective deployment of an SOA. An ESB insulates the developer from the middleware used in deployment. Given this empowerment granted by the ESB, the traditional vendor lock-ins in the back office can be removed. To be truly services oriented you should not be beholden to any individual middleware vendor, regardless of the scalability requirements. Most ESB vendors will provide proprietary alternatives to HTTP where scalability requirements demand it, e.g., IBM is encouraging the use of MQ to deliver SOAP messages. Alas all direct consumers of the service need to have this vendors' technology installed. Your ESB should provide you with a higher quality standards-based alternative, such as SOAP/IIOP.

• Figure 1
• Figure 2