Skip to content

Day of the Dove

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):

  1. Binary RPC Style
    • CORBA
    • DCOM
    • RMI / EJB
  2. Message-Oriented Middleware
    • Topics
    • Queues
    • Tuple Spaces
  3. SOAP / WS-*
  4. REST / HTTP

Third, let’s try and establish some axioms:

  1. All of these technologies work, i.e. you can build systems today using any of these technologies.
  2. 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.
  3. Message-Oriented Middleware (MOM) is a proven technology with wide deployment.
    • Tuple Space oriented technologies are not as widely deployed.
    • MOMs are not interoperable.
    • Deploying APIs and JMS providers is an issue.
  4. Most ISVs have lined up behind SOAP/WS-* as the “remoting” technology of the future.
    • 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.
  5. REST-styled systems based on HTTP have the broadest reach.
    • 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.

{ 9 } Comments

  1. Dan Pritchett | December 23, 2006 at 12:23 pm | Permalink

    Great post Pete. A couple of comments I’d like to add.

    In general, I’m not a huge fan of the broad concept of intermediaries. There are some functions though that make sense to push in front of the application server. QoS enforcement and transport security are just a couple that come to mind.

    Your last point about HTTP for asynchronous messaging is a good one. Too often the transport and dialog semantics get confused. Messaging is a dialog style. It can be implemented on top of synchronous or asynchronous transports, just like I can implement a call style dialog over an asynchronous transport.

    Reliability at the messaging layer is another of the unnecessary complexities. It’s far easier to support an at-least-once semantic and require the subscribers to be idempotent. With that semantic, HTTP works just fine as is.

  2. Mike Champion | December 23, 2006 at 5:42 pm | Permalink

    Yes, great post, and hopefully the beginning of a more productive debate about HTTP, WS, etc.: Let’s argue about when to use what, not which is unconditionally the best.

    A couple of comments that attempt to go in that direction. First, I think of WS-* as being good for addressing the fact that MOMs are solid, widely used technologies but they don’t interoperate. I’d say “If you have to integrate multiple MOM back ends or integrate with front ends that use existing WS interfaces, consider WS-*”.

    Also, I’m not so sure that WS-* is important to “stay in step with the product direction of certain large vendors”. Speaking only for my little corner of Microsoft, I don’t think the company as a whole takes sides; there are teams who work with REST/POX, teams who work primarily with SOAP/WS (but are moving in the POXy direction too), and those who build stuff that works with either (e.g. our Data Programmability group). Worry about *your* needs and strategic direction, not the vendor’s, since almost all are agnostic *overall* even if a given product group takes sides.

    Finally, my suspicion is that if people start thinking hard about REST-like multi-hop or multi-protocol reliability / security / etc., they will end up reinventing something that looks an awful lot like the SOAP stack. I presume you disagree, but why?

  3. Geva Perry | December 24, 2006 at 1:34 am | Permalink

    Pete,

    We at GigaSpaces can share with you some of the use cases in which we — with our JavaSpaces base product — get chosen over other alternatives. We can go into details, but at the end it is a question of performance and scalability. I’d like the opportunity to go into more detail with you.

    Geva Perry
    GigaSpaces
    http://www.gigaspaces.com
    http://www.gigaspacesblog.com

  4. Frank Greco | December 30, 2006 at 6:40 pm | Permalink

    Why are you classifying tuple-spaces as *message-oriented* middleware? When you program with tuple-spaces (eg, javaspaces) you don’t program in terms of messages; its more of a higher-level distributed shared memory model that has transactionality.

  5. Pete | December 30, 2006 at 8:48 pm | Permalink

    Frank: “Why are you classifying tuple-spaces as *message-oriented* middleware?”

    Laziness on my part. I wanted to get Tuple Spaces in there due to the new found interest I’m noticing on the Web. But didn’t do enough homework to classify it properly. You’re right it’s not a MOM. And in the next iteration of this positioning I’ll break it out into its own category.

    The sad thing is a couple of years ago I had a brief love affair with tuple spaces, but couldn’t get my then employer to consider it, and I haven’t looked at it since. So, though I grokked tuple spaces once, I’ve largely forgotten it all since.

    However, I am still keen on finding out what business use case Tuple Spaces are ideally suited for (for instance, STP in the financial area) and why. Any pointers?

  6. Dan Creswell | January 1, 2007 at 5:00 pm | Permalink

    Hi Pete,

    Just wanted to say, if you do get to checking out Blitz and need help, have questions or comments or whatever drop me a line.

    Happy New Year!

    Dan.

  7. Eric Newcomer | January 2, 2007 at 3:29 pm | Permalink

    Pete,

    Great post, and I completely agree with the need for further education. As one of the “right tool for the right job” people I definitely believe it can only help if more people understand the tools better.

    I take it from this and from some of your other posts that many of the comments you’ve made are more or less in the spirit of trying to counteract excessive marketing hype. That is definitely also a good thing.

    However talking about technologies in the abstract doesn’t quite go far enough IMHO.

    For one thing, SOA isn’t about technology. As many times as we all say that and agree, we (technologists) continue to fall into the trap of debating technologies in comparison to each other rather than according to how each does (or does not) meet specific application or user requirements. Here the point is also that we know what the “car is” - we know what we need from an operating system, programming language, database management system, and distributed computing system - the point now is not to figure out which among many is “the best” single solution but rather how each and every one can be improved. Especially how they can all work together better.

    The second thing is that saying something like “never use RPC” because it defeats loose coupling doesn’t really get to the issue. That’s one reason I would rather characterize messaging styles according to whether they are “synchronous” or “asynchronous” and recommend one or the other based on an application’s requirements. Whether the coupling is tight or loose may be more or less significant than the choice of asynch/synch for example.

  8. replica prada purse | June 21, 2013 at 9:54 am | Permalink

    Hi there, yup this post Pete Lacey’s Weblog : Day of the Dove is genuinely good and I have learned lot of things from it regarding blogging. thanks. replica prada purse http://www.voguebagsstore.com/prada-handbags-c-13.html

  9. louisvuittonfakepurs | June 21, 2013 at 9:23 pm | Permalink

    This piece of writing Pete Lacey’s Weblog : Day of the Dove is related to website programming is really fastidious in favor of me as I am website developer. Thanks for sharing keep it up.

{ 2 } Trackbacks

  1. Stefan Tilkov's Random Stuff | December 23, 2006 at 5:07 pm | Permalink

    Day of the Dove…

    Another great post by Pete Lacey. A good argument introduced in a recent discussion thread (I’ll try to dig up the reference) was that if your existing backends expose a coarse-grained interface, let’s say via CORBA, the move towards WS-* i…

  2. [...] [Inspired in part by some bits of this posting and associated comments.] [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *