« Semantic Web: crippled? | Main | Mike Champion on SOAs »

Messaging: Welcome to the 1970s

The Mountain of Worthless Information

Ted Neward gets messaging religion. Brilliant, I want to to review the book. Anyway...

A messaging-based system, by virtue of the fact that it intrinsically doesn't try to do request-response, tightly-coupled communication, allows for a tremendous flexibility in enterprise systems. RPC was created because messaging-oriented approaches were considered "too hard", owing to the loosely-typed nature of messages. But with Schema to provide strong-typing rules for XML payloads in SOAP, and with JMS using Java objects (which in turn must be strongly-typed) for Message payloads, this isn't as much of an issue anymore, and I'll argue removes much of the burden of working with messaging-driven systems. The inherent flexibility gained from a messaging-driven system, however, is something that no RPC-based system can ever match.

In my experience schema provide little value over an agreed upon XML document. Schema are good to check for a structurally sound document, but there's a bunch of other business level quiddities which require code or a rules language to enforce. This difference is that of a spell checker and peer review. At the moment information sharing using even the basic SOAP/XSD types is something of a black art. It's all highly fragile, and would be a lot worse if it wasn't for some seriously committed people.

Though if you are lucky enough to have Java across the enterprise, then using JMS and exposing SOAP doc/lit at the enterprise boundary is going to work well. But how many enterprises are truly homogenous like this?

When people first tried to run RPC and protocol tunneling over the web years ago, it was swiflty kicked out into CGI, not built into HTTP. And it seems no-body working on web architecture back then was paying much attention to this.

What finally cemented my relationship with messaging approaches, however, was the SOAP 1.2 spec. For those of you who haven't read the spec, you owe it to yourself to do so. Not because it's particularly fascinating reading, but because SOAP 1.2 is quite possibly the best thing to have hit the industry in a number of years.

SOAP is at heart an RPC technology with messaging retrofitted and boosted in the last eighteen months (that's being generous, it's only in the last six months people have stopped using getStockQuote to explain or justify SOAP).

Maybe this is my recent infatuation with workflow coming through (and workflow and messaging have such a deep relationship with one another that I suspect it's all one big love affair)

Don't go there. Build workflow on top of messaging. Munging the two together screws with dataflow and makes things too complicated. Rule of thumb taught to us via banking fulfilment systems - if you can't figure out how to automate a dataflow after a day or so, kick the flow out to manual processing. Messaging should be simple, clean, elegant; workflow is hard, dirty, bloody.

I can't imagine building an enterprise system of any large size without building on a messaging-based backbone. To do otherwise would just somehow seem to tie your hands too tightly.

Open secret: nobody in their right mind does anything other than messaging or flat data transfer for systems that are meant to be scalable and available. Every attempt to do otherwise has missed the target.

Get your messaging on:

ebXML 2.0

April 3, 2003 11:29 PM


Trackback Pings

TrackBack URL for this entry: