SOA and web services
The following is a message to the service-orientated-architecture yahoo group. It’s in response to a thread about standardized interfaces and protocol semantics. I don’t think it bring anything new to the table except my own understanding of some issues, but – especially since Yahoo Group’s search interface is so bad – I’m going to post it here in case other people find it useful.
On Mon, 2005-01-10 at 19:14, Spork, Murray wrote:
Should we add new verbs that incorporate (for example) complex transactional semantics – or should we instead refine the current verbs through other mechanisms. For example – by layering other protocols on top of HTTP. If we do the later then I strongly agree with Mark – the semantics of the verbs in the higher level protocol should not contradict the verbs in HTTP.
Yes.
I think what is happening here is that the HTTP verbs are being implicitly refined by attaching some semantic behavior to the resource - in this case the verb PUT is refined by stating that a particular resource is of type “order-acceptor” – in this way a client (that understands what an order-acceptor is) can infer that PUTing an order to this resource will cause a order to be placed.
IMO verbs are all about defining side-effects.
Yes. The hard assurances, side-effects and basic semantics are defined by the verbs, and refined, as well as contextualized, by the type of the data being operated over.
It seems like all the effort that’s gone into WS-* in the last few years could have instead been directed at determining new verbs, collections of verb-profiles and more-rich media-types. Somehow, a lot of MEPs and the yet-another-RPC mechanism doesn’t seem as useful… I’m not exactly sure why not, though.
nor that HTTP is sufficiently flexible for allowing the incorporation of new verbs.
Hmm… is it even possible to have a protocol that both specifies operational semantics and does not do so … and still be efficient?
I’m not sure I understand your question – could you elaborate?
Not well enough, as it’s a poorly formed quesiton: “efficient” is too loose and relative of a word. But that won’t stop me from trying :) …
Especially for the “does not do so” part, I guess I’m thinking of a protocol whereby the operation isn’t specified, so much as the semantics of the unspecified operation being performed. I guess somewhere between HTTP and RPC; one would make an request^Winvocation of the form:
[ a :Invocation ; :informativeOperationName "get" ; :idempotent "true" ; :safe "true" ; :cacheControl [ :cacheable "true" ; :cacheStateTag "12345" ; :expirationDate "2005.01.12T10:19:00Z" ] ].
[For the "specifies" part I was thinking of something like HTTP, where the above properties for a handful of operations are specified in the ... uh ... specification. But that's not important once you have the above.]
But what I’ve specifed is basically what’s become of SOAP and WS-*, except that — for the most part — the transfer semantics aren’t explicitly specified in the content of the messages, but are implicit in the namespaces and qualified-names present in the data being exchanged.
I guess that it is the obvious and direct consequence of the implementation of SOAP’s design… the quest for “protocol independence” leads to trivial use of a transport protocol that is basically: open connection and execute “Process Message”. Since all the semantics are defined in the data, there is no need for protocol-level verbs. As well, it actively seeks to ignore the semantics defined by any protcol it “rides”. Thus, an application protocol like HTTP is converted into transport.
As well, answers about “efficiency” are now more clear…
no, it can’t be as efficient (as HTTP), since intermediateries need to do message inspection. A lot of message inspection.
as well, it’s hard to see how one even describes the full semantics of these messages in a machine-processable way…
but, it can be quite flexible, which further reduces intermediateries capabilities.
the underlying protocol must be completely ignored to prevent conflict with higher-level semantics.
It continues to sound nothing like the web. I guess it could be used to implement services.