Pete Lacey’s Weblog

I’ve been otherwise occupied for the last two weeks or so, but there’s been some interesting feedback on my Day of the Dove post and it’s related successors, Strategic Direction and Reinventing the WS Stack. My apologies for letting them linger unanswered for so long. I’ll respond to some of that feedback here and now, and update the positioning accordingly.

First, there is this fantastic post from Don Box (and a follow up) regarding how WCF is not promoting WS-* as a strategic direction for Microsoft, but that it is an open and extensible platform. Since this echoes what Mike Champion has to say, and recognizing the authority of these two Microsoft engineers, I concede this point. I’m not sure this jives with Microsoft’s more public presence, but my thinking is probably stuck in the early Indigo days. It’s more difficult to say the same for IBM given the plethora of WS/SOA related products they offer, but I will strike the whole point from my positioning statement: it is not necessary to adopt SOAP/SOA/WS in order to stay in step with the product direction of many large vendors.

Next comes Mike, who had a long response to “Reinventing the WS stack.” To be honest, I’m not sure if Mike has a final conclusion, so I’ll excerpt the interesting bits piecemeal.

Hmmm … I come away feeling that you more or less agree that a lot of the basic ideas of the WS stack (such as envelopes and the WS-Security model) would be preserved if it were rewritten by RESTifarians.

This is the bit I have the most difficulty parsing. I certainly don’t speak for the REST community (if there is such a thing) but I imagine that no REST proponent is even remotely interested in rewriting the WS stack. What I was getting at, in the context of the original question, is that if you examine the entire stack, there’s potential value in WS-Security, and since that requires (?) an envelope, the SOAP envelope will work. But helping oneself to a couple of good ideas does not constitute agreement with the basic idea of the WS stack. In fact, I’m not sure I can say what the basic ideas of the WS stack are. It seems to be a dumping ground for every conceivable technology. By Burton Group’s latest count there are more than 50 WS-* specifications. Some of the security related specs may be useful to the REST community, but not much else.

I think the main way various parties to this discussion see the world differently is that some start from the Web and ask “why can’t the enterprisey people just do it the Web Way?” The WS-* folks start from the enterprisey world today (where reliable messaging Just Works, even across multiple nodes and across oceans, gigabytes a day) and ask “how can we achieve these service levels over the internet?” So, the hybrid system is the only one of interest, AFAIK, since you can indeed do things better with a MOM if you don’t have to worry about the Web. (Emphasis mine.)

Exactly! For an example of the first view of the world see this recent post by Mark Baker.

To restate: The Web has reach and MOMs are enterprisey. What then does WS-* have? Today, not much. Basic SOAP processing doesn’t offer much, and the advanced WS functionality is not widely implemented, nor does it have much, if any, production use. Also note that implementing, say, WS-ReliableMessaging, does not necessarily mean that the implementation itself is robust - it might implement the spec perfectly, but still drop every other message on the floor. WebSphere MQ, on the other hand has been around in one form or another for 30-odd years. It’s proven, high performing, fault tolerant, transactional, etc. It would be madness to toss it aside. Thus, one can imagine a pure REST system, a pure MQ system, or a hybrid of both.

Though I have a hard time imagining what WS-* offers, WS proponents will argue that WS-* offers the following:

Platform neutrality: For the first time ever, all major vendors are backing a single “remoting” technology. No more DCOM over here and CORBA over there. That’s great! However, this is really the second time. The first was when they embraced HTTP.

Common messaging standard: MOMs use binary messaging. MOMs don’t interoperate. With WS-* you have a messaging/middleware solution that is open, interoperable, and easily intermediated. You can put a series of intermediaries in the message path that apply organizational policies and processes centrally. This is a very compelling argument that looks great on paper. Today, though, even basic SOAP/WSDL interoperability remains challenging, let alone the rest of the WS stack. And the practice of consistently applying corporate and technology policies via an intermediary is still in its infancy. Furthermore, to me anyway, mediation on this scale fails the sniff test. For one thing it smacks of moving intelligence into the network, generally a bad thing. For another, it reeks of inefficient, top-down control that will either be ignored in practice or stifle innovation. And for a third, these intermediaries are anything but transparent (they can’t be without a uniform interface) to either the client and the server, burdening developers on both sides with intimate knowledge of what the intermediaries are doing.

However, the jury’s still out, and I’ll put this down as a possible future win for WS. Of course, HTTP is also designed for intermediation, and there is a wealth of experience building proxy servers and caches and security solutions. Stuff you likely already own. An HTTP proxy can’t intermediate an MQ message transfer, true, but I’m pretty sure I don’t want it to.

So I don’t understand your conclusion “But the multi-hop/multi-protocol issue is not going to be the impetus”. HTTP may be multihop already, but the people who have bet the farm on MQ for the last 30 years are *not* going to rip out their MOM and replace it with HTTP, so fuggidaboudit. (I know Pete isn’t advocating this).

I’m certainly not advocating ripping out a MOM. What I meant by the “impetus” statement is that the RESTafarians may want to mimic some of the messaging styles found in MOMs and WS-*, e.g. async or pub/sub. But if they do, it won’t be because of challenges presented crossing protocol or server boundaries, but rather because these messaging styles are attractive. For clarity’s sake, note that implementing a messaging style like pub/sub, does not imply implementing a robust, fault-tolerant, etc. MOM, it’s just another messaging style alongside HTTP’s existing synchronous, request/response style.

SOAP, like XML, may not be elegant or optimal for much of anything, the question is whether it is good enough to provide a standardized tool platform that is better than all those ad hoc agreements that would be needed without a standard.

No, the question is whether these standards are needed at all. Remember, the REST folks have not implemented any of the mythical messaging styles I put down, and they may never do so. Whereas the WS camp has gone ahead and created specs (and very few implementations) for just about everything, whether people wanted it or not. The same is true when you go beyond messaging and into management, configuration, discovery, metadata, orchestration, choreography, transactions, federation, trust, and so on. Who asked for all this stuff?

“Pornography, gambling, lies, theft and terrorism: The Internet sucks”. They do NOT trust the Web, they spend their days trying to keep the mess out of their nice clean machine rooms. So, a lot of the points about how one might use HTTP in a reliable, secure, multi-hop way without WS-* seem technically valid, but pragmatically implausible.They do NOT trust the Web, they spend their days trying to keep the mess out of their nice clean machine rooms.

I’m sorry, I can’t buy this one at all. To conflate HTTP with a number of dubious web sites is just plain wrong. If there’s a jenna_jameson resource whose representation happens to be a jpeg, how is that the fault of HTTP? What if there’s a SOAP service for gambling online? Besides, what protocol do you think SOAP is tunneling over?

Use what works, ignore the rest, let Father Darwin sort it all out in the long run. The real world Web isn’t purely RESTful, the real world enterprise needs to accommodate the Web to some degree, let’s quit arguing about abstract principles and discuss what works in which scenarios.

Another point of agreement and the whole point of the original dovish post. Alas, we now have one less reason to use SOAP/WS today.

I also need to highlight Stu Charlton’s comment, if only to say that I am in 100% agreement.

Incorporating this feedback the new positioning is as follows :

• 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 MOM.
• 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-*.

That doesn’t leave much for WS-* to do to except integrate with other, existing WS-* systems.  Of course, standards-based, interoperable, readily intermediated, advanced messaging is still the WS-WildCard.  We’ll see if it pans out.  Though I remain dubious.