Canonical Model Format & Atom

It has been awhile since I thought a lot about canonical models. I have been involved in a few over the years.

I'm thinking about them tonight.

In creating one today, is there a reason why you wouldn't use Atom instead of say SOAP or more likely your own proprietary solution? I re-read Pete Lacey's classic The S stands for Simple to remind myself why I left SOAP behind.

SOAP isn't even on my radar these days, but perhaps someone can convince me otherwise on why it belongs in the heart of your integration architecture? Of course you have to interoperate with it, but you can certainly keep it at the edges (i.e., integrate with legacy web services, packaged apps that only expose a SOAP interface that you want to use).

We are talking about your lingua franca here - there are few things in my opinion, more important to an integration architecture than a canonical model - you want to get this right.

SOAP started simple enough - it just became an industry and now it is fairly hard to separate the wheat from the chaff. Here's to hoping that Atom stays simple.

I kinda doubt that many people are using SOAP as a part of their canonical model. I would have to bet that they are using something they made up. From what I can tell, Atom seems to give you what you need out of the box - most people will need to add some more standard elements to it, but it has all of the basics so why reinvent the wheel?

SOAP over JMS

Hey, looks like SOAP really does work over any protocol. Well over JMS anyway (not really a protocol). Saw this here and here. I'm sure all of these vendors (I know Sonic does) provide their own proprietary SOAP to JMS mapping. I suppose there is some value in them mapping it the same way.

The chances of me using this? Zero.

With SonicMQ, however, I have happily used their RESTish HTTP Adapter that just maps destination names into the URL & looks for HTTP Headers for any messaging specifics. Want to check for a message? Check the response queue via a different HTTP GET. Certainly not perfect, but can be useful when working with a technology that does not have a richer client available.

I took a quick scan of this document & remembered a Tim Bray post from last year.

I guess I won’t offer any further commentary on the contents of this document. I can’t help but feel for the H/I/I/M staff who are going to have to do the work, and am reminded of Fritz Lang’s immortal Metropolis, where Maria says: “Nobody cared about the slaves who died laboring to raise the Tower of Babel.”

Not sure if they already are (don't see any of their names listed), but it would be nice if these vendors got involved in AMQP. That seems to have some promise.

Why AMQP? Though many networking protocol needs have been addressed, a large gap exists in common guaranteed-delivery messaging middleware. AMQP fills that gap...

What is AMQP? AMQP enables complete interoperability for messaging middleware, both the networking protocol and the semantics of broker services are defined in AMQP.

AMQP Model The AMQP model explicitly defines the server's semantics because interoperability demands the same semantics for any server implementation.

Wire-level Format To enable technology-neutral interoperability, AMQP defines an efficient wire-level format with modern features.