Update: In the comments, Frank Greco correctly points out that I have miscategorized Tuple Spaces technology. On his web log, Dan Creswell implies the same. This was pure laziness on my part. I wanted to give Tuple Spaces a mention because of the renewed interest it seems to be receiving, and I added it hastily to the message-oriented middleware category, when, in fact, Tuple Spaces implement a distributed shared memory model. In this light, it seems to me that Tuple Spaces are not designed to address the problem set up in this post: making business logic available over the network, and I have removed this technology from the list of potential solutions. Note to self; download Blitz and get smart.
Do you remember that Star Trek TOS episode where a hyper-intelligent shade of the color red locks a Klingon crew and the Enterprise crew in unending violent combat so that it can feed off their heightened emotions? Remind you of anything?
If the RESTafarians are the Klingons (I’m being nice) and the SOAPies are the Federation, who is the alien? Who the heck is getting off on this? I suspect, that we all are. Recently, however, a number of voices have been trying to rise above the din and laugh the alien off the Enterprise. Or, as Kirk put it, “Captain’s log, stardate… Armageddon. We must find a way to defeat the alien force of hate that has taken over the Enterprise, stop the war now, or spend eternity in futile, bloody violence.”
What all of these voices have in common is the notion of “using the right tool for the job.” A phrase I’ve used myself from time to time, both in print and in conversation, so I’m cool with this. Neither SOAP nor REST are universal solutions. They both address similar problem sets, but there are times when one or the other is the more appropriate solution. There are also times when a different technology altogether is the appropriate solution. In the interest, then, of genuine rapprochement lets do some positioning.
First, we’ll note the general problem we’re trying to solve: Making business logic available over the network.
Second, we’ll enumerate the technologies that are commonly used to address this problem (not all inclusive):
- Binary RPC Style
- RMI / EJB
Third, let’s try and establish some axioms:
- All of these technologies work, i.e. you can build systems today using any of these technologies.
- Binary RPC-styled technologies are no longer considered viable for underpinning large scale distributed systems, but remain viable for tightly coupled systemsâ€”in particular RMI/EJB
- There is no need to rip and replace existing systems that use these technologies.
Tuple Space oriented technologies are not as widely deployed.
- MOMs are not interoperable.
- Deploying APIs and JMS providers is an issue.
- SOAP/WS-* is complex, and large swaths of WS-* remain unstandardized and unimplemented.
- Vendors will eventually make most of WS-* work, but interoperability among implementations will remain challenging.
- REST is based on proven, scalable, interoperable, standards.
- Awareness of REST outside of common Web applications is lacking, and so too are codified REST best practices.
And finally, some positioning:
- Your default messaging style should be REST. This allows for data to be created and consumed by the largest possible audience. Before considering any other distributed architecture, one should have valid reasons for discounting REST.
- If asynchronous, reliable messaging is absolutely required, use a MOM1.
- If event driven or broadcast messaging is absolutely required, use a MOM.
- If pub/sub is absolutely required, use a MOM.
- If you have to integrate with existing WS interfaces, use SOAP/WS-*.
- if you desire to stay in step with the product direction of certain large vendors (e.g. Microsoft or IBM) use SOAP/WS-*.
The above, of course, is my opinion, a considered opinion, but biased nonetheless. It is also rather superficial, but it’s a start. I think it may be valuable to flesh this out, and I’m seeking your opinion. If there’s enough feedback I’ll create a wiki to manage this permanently. I’m especially interested in the use cases that Jini and JavaSpaces (Tuple Spaces) are particularly well suited for.
Also, this positioning is likely to change in the future. As WSA, WSRM, WS-Eventing, and WS-Notification mature, implementations will be able to address some of what is solved today by MOMs. Not all of it, but some. And while I doubt that such implementations will be easily interoperable, if you stick with a single vendor you will gain the benefit of having this functionality available with a standard JEE/.NET deployment.
Another point of interest, especially to the SOA people, is intermediation. This is not a concern for REST, as it too is designed to have intermediaries between endpoints, but it’s not so easy for MOMs. In the SOA world it is possible to put something like a web service management system or an XML appliance (and sometimes an ESB) in the message path. It is then possible to use these systems to do what is often done on an app server today, like message transformation and security processing. This provides the advantage of centralizing certain corporate policies and alleviating the service developer and app server from having to do this work (possibly erroneously). I admit that this is attractive, though I’m dubious about how broadly it can be put into practice. In any event, it is a compelling argument for moving away from MOMs as soon as possible, so long as WS-* messaging really delivers on its promise. Like I said, though, REST can be intermediated as easily as SOAP, though it may need some more standardization, for instance around message-level security.
So, am I hanging up my Claymore? No, no I’m not. I think the SOAP/REST debate is different from other techno-religious wars in that a fair number of people (myself included) believe that SOAP/SOA is being oversold. You see, systems vendors large and small are pushing web services as a cure for all your IT woes and advocating a stepwise re-architecture of IT around SOAP-based service orientation. Whereas a comparatively small but vocal minority have been advocating a REST-styled approach to some of these same problem domains. So long as SOAP is positioned outside of the boundaries listed above, it will be important to educate users and vendors alike on how REST is the better tool for the job.
1. Plain old HTTP can do asynchronous communication and there are simple extensions to HTTP to allow reliable messaging. However, there is no agreement that spells out the one true way (or more) to do asynchronous messaging and the HTTP reliability extensions have not been standardized.