2004/05/21
Add your comment
Via Savas, I noticed a good post from Eric Newcomer;
The doc/literal style would seem to be the most abstract or the most “loosely coupled,” since it does not include data typing (although data typing is provided by an associated XML Schema) and does not include a method name in the message.
Wow, I’ve been saying exactly that – “not include a method in the message” – for years now. Good to see Eric on board! 8-)
But unfortunately that’s not the whole story. For the kind of loose coupling that folks really seem to want, simply removing the method from the message isn’t sufficient. The method has to be removed, as Don Box would say, from the contract. Or, put another way, give all services the same contract (trust me, it’s true, and it’s worth spending considerable time understanding why)
Another way – a software architectural way – of looking at this, is to ask what the different architectural constraints are at work between a message without the method in the body while still having service-specific contracts/interfaces, and an architectural style where all contracts/interfaces are the same. If you can’t find an architectural explanation for the loose coupling, then it’s not there. I’ve mused about this recently.
And there you have it, the principle difference between SOA and REST, and the reason why I’ve also been saying that REST is what Web services folks have been looking for all along.
2004/05/20
2004/05/19
2004/05/18
Savas posted a good state-of-the-conversation post upon his return, so I’ll respond to it. I still hope to respond to his earlier response to a question of mine, in what will likely end up being a mini treatise on state and state references. But that’ll have to wait.
I am now thinking that it is time to explore whether it would be possible to take the “processThis” idea to a next level. First, we really need to change the name; perhaps something like “processDocument” or “processMessage”; I like the latter better.
I could live with either, but I’d prefer “processDocument” since it’s more specific. “processMessage” could include the processing of a document (i.e. a chunk of state), or the processing of an explicit request for some action to occur. To my mind, “processDocument” suggests the former, which is what we all seem to want; state transfer.
Then, we need to demonstrate that we are not that far really from REST and, in fact, the REST approach can be seen as a subset of our model where the protocol verbs are effectively modelled as a submission of documents to the “processMessage” abstract operation.
Yes, you really aren’t very far from REST. Your architectural style seems to be state transfer based, which is awesome. I say “seems”, because Jim’s response to Matt Garland’s suggestion for how queries should be done suggested that he supported a non-state-transfer approach to querying. Which brings us to …
This last observation answers Mark’s point about the semantics of GET in this post. The semantics of GET can be captured through an appropriate SOAP message. An HTTP request-response pattern can also be described as a message exchange pattern in which the receiver of the request will send a message to the “processMessage” operation of the sender.
I think this is an absolutely critical point to the understanding of REST, or at least how it relates to the style you promote. But I think you’ve got it wrong there Savas, on two counts.
Second point first; I think the comparison between HTTP request/response and “processMessage” is incorrect; the comparison should be between HTTP POST and “processMessage”. That is, if you take away all the HTTP operations except POST, what you’ve got remaining is an application protocol with a single explicit (though it could just as well be implicit) operation which is semantically identical to a state-transfer semantic, which I understand processWhatever to be.
Second, though related, I’m certain that query semantics cannot be captured by an “appropriate SOAP message”. Consider that for any SOAP query document you can construct, I can present a SOAP service which simply adds that document to a queue (just as an example), and returns a success bit (e.g. an HTTP 204 message) with no other information. What this means then, is that a service which does respond to the query, is actually presenting a different abstraction than the one which places it in the queue. In other words, the query service isn’t using “processMessage” semantics. To query, you need a query semantic. And if you’ve got a uniform document submission semantic in processMessage, then why not a uniform query semantic? In my view, that should be the “next level” we take; it need not be full REST, of course, just an, IMO, superior style than what’s there now.
I’ll leave it at that for now, I think. The state issue needs to be addressed as I mentioned, but I think it can be decoupled from this argument.
P.S. enough of the love-in, ok guys? I’ve got a rep to maintain. 8-)
2004/05/14
And so the platform battle begins; can Yahoo extend their services as quickly and cheaply as Google?
(link) [Mark Baker’s Bookmarks]
(link) [Mark Baker’s Bookmarks]
Oops, sorry for not participating but it seems that Yahoo had me pegged as a “soft bouncer”, and moreover, my notice of that change in status got caught in my spam folder. Doh!
(link) [Mark Baker’s Bookmarks]
(link) [Mark Baker’s Bookmarks]
2004/05/13
This makes some sense, but ouch, they should have gone to the Atom community first.
(link) [Mark Baker’s Bookmarks]
(link) [Mark Baker’s Bookmarks]