Using HTTP and JMS for Web Services
The Road to Enterprise-Class SOA Executive Summary
One early misconception in IT was that Web services were equal to a Service-oriented architecture (SOA). The reality is that SOA is more. Though SOAP is an increasingly common format for messages, an SOA often requires many underlying transports. The selection of these underlying transports is one of the most important decisions in the creation of an SOA. To support the requirements of business-critical applications, the transports employed must be flexible, reliable and scalable. They must also support different types of synchronous or asynchronous service communication. HTTP and Java Message Service (JMS) are two of the most widely used standards-based transports for SOAP messages.
This paper examines the benefits and trade-offs of HTTP and JMS, highlights where each transport is best suited and demonstrates how each can be used as part of an SOA.

Enterprise SOA Communication Requirements
Flexibility, reliability, scalability. These are three attributes that any transport method must provide in an enterprise SOA to take maximum advantage of all connected services. In an SOA, a transport needs to be able to convey messages in real time (synchronously) to provide responsiveness to users or systems. Yet often an enterprise also requires the flexibility to communicate asynchronously with services. One reason may be that the services aren’t always available. Another may be an unreliable or occasionally connected network, such as a wireless connection. In both cases, synchronous transmission will result in failure unless the services themselves are written to perform additional “retries” and error handling. Additionally, communication between processes in an SOA is not always point to-point, or one-to-one. Often, a service needs to send a message to several other processes or systems at the same time, a one-to-many association. While a service can also be written to communicate with multiple “consumers,” this adds complexity to the service itself and tightly couples the service to the end points. In many cases, services also require a transport to be reliable. Without reliable message delivery provided by the transport, additional verification must be built in at the application level. Finally, transports must scale. The transport itself should not impose limitations upon the ability to deliver messages as the number of messages, message senders and message receivers increases.