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?
1 comment:
Perhaps the first clue about SOAP was its provenance from the Borg...
Post a Comment