Service oriented architecture centres heavily on the concepts of service providers and consumers. It’s easy with request/reply web services to fall into the lazy habit of thinking of the provider as being the “server” side of the request/reply interaction. The consumer requests information from the provider, which the provider – naturally – provides! But this is wrong.

What happens in an N-tier architecture where there may be many “servers” in the stack? What happens with JMS-based services using a one-way message exchange pattern (MEP)? If one application is using SOAP/JMS to send a message to another application, which is the consumer and which is the provider?

On the face of it, you might say the “sender” is the “provider” and the “receiver” is the “consumer”, but that ignores the fact that there are two types of one-way MEP – “one-way out” and “one-way in.” (Actually there are many types of MEP and they differ slightly depending on the version of WSDL you use, see the WSDL standard for more confusing details).

We really need to look beyond the technology to find the answer and the Web Services Glossary gives a clue. It splits the model into an “agent” (software or process) that operates on behalf of an “entity” (person or organization). Specifically a Provider Agent and a Requester Agent operate on behalf of a Provider Entity and a Requestor Entity respectively.

So the “provider” of a Web service is basically the person or organization responsible for that service. It is the person or organization that you contact to get permission to use the service, or obtain the WSDL, or give your credit card details for charging.

An example will help to clarify the relationship between provider and consumer in one-way MEPs. Suppose a service provides alert notifications. Multiple consumers subscribe to this service to receive alerts on subjects that are important to them. At the messaging level, the provider puts a message onto a JMS Topic and multiple consumers receive the message. This is a “one-way out” MEP.

Another service might be a central audit service where multiple agents send messages via a JMS Queue representing steps in a distributed process. This is commonly used for “track and trace” in distributed workflows. In this case, the message senders are not responsible for the audit system, they are “users” or “consumers” of the service. This is a “one-way in” MEP.

In summary, service providers and consumers can be confusing in an N-tier architecture or with one-way MEPs. The fundamental consideration is more “business” than “technical”. Who is the organization or person responsible for the service? Then the way consumers interact with them determines the MEP that is being used.

JMS has brought messaging more into the mainstream which is a good thing. But just like any new technology there is the danger that the first implementations will reflect older paradigms. I remember when I made the move from FORTRAN to C, for a while I wrote a lot of FORTRAN programs in the C language syntax until I got more familiar with C features and idioms. The same goes for my more recent ventures into Ruby with many years of Java thinking under my belt.

Coming back to JMS, I find when I review distributed applications that have been designed by people with a strong client-server or web background I see a lot of rpc message semantics. While rpc (or synchronous request/reply) has it’s place, this is not always the best approach. A common mistake is to regard messaging as simply a way to get messages from point A to point B…treating JMS as a simple transport such as a TCP socket or HTTP.

Messaging originated as the concept of a distributed queue. Most programmers are familiar with queues from GUI frameworks where communications between widgets are mediated via an event queue. The event queue supports a number of functions such as decoupling widgets from each other…allowing each widget to do what it needs to in it’s own time, and supporting event driven interactions between widgets. The event queue along with multi threading is key to giving user interfaces the responsiveness and robustness that you expect. In this way queueing provides more than just a communications mechanism but is key to the architecture of a GUI framework.

The same is true of distributed messaging systems. In their original conception distributed queues do more than just provide a way for data to pass from one system to another, they provide an important element of isolation.

A fundamental difficulty in building distributed systems is that the different components have different performance characteristics. In addition the uptime of your total system is the product of the uptime of individual components. To ensure maximum uptime you want your components to be independent of each other and, in the event of failure you want to be able to restart from where you left off. This is where message queues work really well. Component A puts a message onto a queue and doesn’t  care if or when component B takes that message off the queue. This is known as the fire and forget message pattern and it provides the best isolation between your system components.

If instead we make Component A wait for an acknowledgment from Component B before it proceeds then we are building a tight coupling into the system. Any performance difficulties or failure experienced by Component B could spread back to Component A and thence to other components up the chain.

So the role of messaging in distributed systems goes beyond just getting a message from point A to point B. It also acts as a kind of expansion joint for your system allowing individual components to vary in their performance characteristics – or even fail totally for short periods – without breaking adjacent components.

Without these messaging expansion joints, your system is tightly coupled and prone to system wide failure originating from a single component. Messaging – using the fire and forget pattern – allows these issues to be locally absorbed and managed within normal system operations.

One of the original and fundamental tenets of the SOAP standard was that the SOAP message is independent of the underlying transport. Ostensibly you could use SOAP over HTTP, JMS, email, FTP etc. but the reality is that a standard binding has only ever existed for SOAP over HTTP. To paraphrase Henry Ford – “you can have any SOAP transport you like, as long as its HTTP”.

While HTTP is undoubtedly a good choice for SOAP – given its ubiquity – there is at least one other transport which demands attention. This is the JMS transport which is widely used inside the firewall of many organizations. Of all the companies that I work with, their SOA infrastructure heavily relies on JMS transports inside the firewall, with HTTP transports outside the firewall or to selected service end-points such as web pages. Of course my experience has significant selection effects, but nevertheless JMS is an important transport in many SOAs. Testament to this is that every major web-services product vendor (save Microsoft) supports SOAP over JMS (and even Microsoft now has SOAP over MSMQ as an important part of WCF).

The fly in the ointment is that there has never been a standardized binding for SOAP over JMS and as a result there is little interoperability between SOAP/JMS solutions provided by different platform vendors. If you happen to have any combination of different web-service platforms in your organization, then they cannot easily communicate with each other using SOAP over JMS without performing some unnatural acts.

Some of issues that need to be considered with a SOAP binding to JMS are:

• How do you represent the message content – text or binary? Most vendors have chosen a text message representation, but that has problems with multi-byte encodings, so other vendors have gone with a byte message representation.
• What headers do you define and what should their names be? How do you use the standard JMS headers? different vendors have different naming conventions and semantics.
• In the WSDL description, how do you represent the connection details to the JMS provider?
• How do your service endpoints manage the different message exchange patterns that are available with message-oriented transports?

Each of the vendors went their own way on many of these issues and as far as interoperability was concerned they basically ceded the field to HTTP. They made life difficult for large organizations with heterogeneous platforms and in my opinion didn’t do themselves any favours on the way. (Actually SOAP-encoding interoperability was so broken for a while that noone noticed the JMS issues…so maybe it wasn’t so bad).

Subsequently it was great to see some of the vendors get together a couple of years ago to agree on a standard SOAP binding for JMS that addresses most of the important considerations. The result was a Member Submission to W3C in September last year. My understanding is that this submission was previously circulated through most of the vendor community so hopefully it has general agreement on the technical details.

This has now taken its first steps to standardization with the initiation of a SOAP-JMS Binding Working Group who aim to publish a recommendation by April next year. Hopefully vendor support of the binding will be hot on its trail.

Note that the standard binding won’t address the fact that different JMS implementations do not interoperate. For example, a TIBCO JMS client will not be able to talk to a Websphere JMS provider because JMS is an API standard, not a wire-protocol standard. What the SOAP/JMS binding standard does mean is that once you have settled on a standard JMS provider for your services, you could define your service description in standard WSDL and your service provider (say Websphere or TIBCO or WSO2) and your service consumer (say TIBCO or WebLogic or Axis) would be able to communicate directly using SOAP over JMS “out of the box”.

Its been eight years (almost to the day) since SOAP 1.1 came out with the HTTP binding. Wouldn’t it be great if a standard JMS binding could be achieved within the decade! It’s been a very long wait. The JMS binding should have happened a lot sooner and I can’t say the “wait has been worth it” but it does fill an important hole in the Web-Services standards.

So what do we do in the meantime? You can eschew JMS altogether and stick with HTTP, but that requires another lot of hard work. You can stick with one and only one service platform, but that is difficult in large heterogeneous organizations – which is where SOA is supposed to provide maximum benefit. Or you can continue to do what many SOA implementers have done and deal with SOAP directly at the JMS layer – effectively using SOAP as plain-old-XML over JMS. I wrote more about this approach recently.

Another thing you can do in the meantime is ask your vendor when will they support the new SOAP/JMS binding?

In a recent ThoughtWorks podcast, Jim Webber introduced himself as a “MESTian”. This was a new term for me, so I had to investigate. MEST is a message-centric approach to SOA which resonates strongly with my own views on how services ought to be implemented. The MEST approach is a pragmatic approach to SOA to which I think/hope Web Services are evolving naturally. Therefore I agree with Neil Ward-Dutton that we don’t really need to coin a new term (MEST). This is really just Web Services “done properly”.

My views on this are a product of my past experience with MOM-based distributed computing. My earlier description of an ESB is based on a MOM approach and probably differs from the common perception of a “black box” ESB. The MEST approach would be very natural to people with an MQ, Rendezvous or JMS background…which is probably the minority of current SOA practitioners.

About 10 years ago, MOM messages were exchanged between systems using proprietary message representations such as COBOL Copybook or AE-Message formats. Enterprise concerns such as scalability, reliability and fault-tolerance were dealt with using techniques at the messaging level. MOM quality-of-service dealt with guaranteed message delivery and message ordering (in normal cases). Where possible, message endpoints were implemented in a stateless manner to allow for easy failover and load-balancing. This general approach is still valid today…only the message representation has changed.

When XML became more mature and accepted, MOM messages started to be implemented with XML payloads. Even after SOAP became a standard, my experience is that it wasn’t rapidly adopted by the MOM community. Proprietary XML message schemas ruled for a couple of years and SOAP had its initial application in RPC over HTTP implementations. But the great thing about SOAP is that it is a nice generic message envelope that is acceptable by everyone. Put your meta-data into the SOAP header and the payload into the SOAP body. If you didn’t have it, you would have to invent it – and many did. Hence, as a pragmatic approach SOAP was adopted as a generalized envelope over – now – JMS. Add the correct JMS headers and you have SOAP Document Literal Encoding over JMS. Additional standards like WS-Addressing, WS-Security are additional sets of meta-data in the SOAP header with meaning to the endpoints and intermediaries in the message journey. WSDL is simply a way of representing the contract between message producer and consumer. I think this is a relatively natural progression from proprietary MOM to more open mechanisms for message exchange which are compliant with the core Web Services standards.

Contrast this with the original RPC approach to Web Services. SOAP RPC Encoding was the original standard, buried within code generation tools which attempted to hide complexity from the developer. Unfortunately this resulted in Web Services which lacked interoperability and created tight couplings between provider and consumer. Moreover, the attempt to shield developers from the distributed nature of their services and the underlying transports – all very necessary concerns – led to huge problems with meeting the enterprise requirements for services. This is the experience of most Web Services developers and it is no wonder that Web Services have such a bad reputation. Subsequently, Web Services – SOAP in particular – has moved to more inter-operable approaches through WS-I. But a lot of damage has been done, and the continued tendency to ignore the distributed nature of Web Services continues to cause problems in terms of unrealistic expectations.

So I like the MEST approach and find that it resonates well with the “pragmatic” approach to Web Services via the adoption of SOAP and other WS-* standards by the MOM community. I can summarize this “pragmatic” approach as:

• Transport Independence is a myth. Use the transports for their strengths – JMS for reliability and HTTP for ubiquity.
• Understand the distributed nature of Web Services and use the long history of best practices from distributed computing and Message Oriented Middleware (MOM).
• Understand the standards and how they fit together. Most importantly, know where the holes are.
• Use the standards where they make sense. Augment them with your own enterprise standards and best practices where necessary.

The result will be better confidence and ownership of your SOA infrastructure. You will rule the standards and your tool vendors rather than the other way around. As an added bonus, you get asynchronous services as a natural part of your SOA – an area where the WS-* standards struggle right now.