Over, Under, Sideways, Down

Jacek follows up on my MEST-Up post with the following:

I think the proposed name SomethingInterestingHappened (intentionally) leaves out the imperative and that's wrong. I'm not aware of any MustUnderstand semantics in the traditional message passing systems, and that's perhaps exactly what SOA(P) gives us. In other words, ProcessMessage represents a way for a sender of a message to be sure the recipient will do what the sender says (given compliant SOAP processors).

Yes, I was intentionally omitting the imperative (DoThis) because it implies that the sender knows what processing the receiver will apply to a given message. This necessarily requires an omniscient, top-down design of the over-all system; the antithesis of loose coupling.

However, the lack of imperative in a message's application-level semantic is orthogonal to SOAP's mustUnderstand semantic, which still applies in all its glory.

Both and Jim's and Savas's responses carry some great discussion in comments. I must say that I agree completely with Brian's comments to both follow-up posts.

Jim responds:

There are two themes which these comments are strung out along: that message-passing and procedure calls are equivalent; and that ProcessMessage is too low-level. Both of these are inaccurate and unhelpful

I don't recall making the analogy that message passing and procedure calls are equivalent. I certainly don't believe it to be the case. As to the point that ProcessMessage is too low-level; based on my more than likely limited understanding of MEST (and I'll have to admit that I only know from what I've read in Savas's and Jim's blogs. Ahem, guys... is there a paper we can read?) I tend to agree . I read with interest the ppt that Jim referenced. Specifically, chart 14, which reads:

Each Web Service we develop has to deal with message exchanges

• Those that it requires to expose its own functionality;
• Those that the Web Services it uses to interact with other Web Services;
• Message exchanges pertaining to the QoS protocols it supports.

Protocol demolishes the idea of Web Services as entities which are “invoked.”

• If you insist on having an operation to invoke, then “invoke” the ProcessMessage operation.

ProcessMessage is abstract, semantics:

• A transfer of a message from sender to receiver; and
• A request to process the received message.

What troubles me is that after reading this presentation, I am even more confused as to where MEST fits from an architectural perspective. Is it a programming model (as implied by the statement regarding invocation of an operation)? Or, is it an architectural style, as suggested by its namesake -- REST? Or, is it simply a retrograde slide towards what was once common practice before the layers upon layers of middleware made dealing directly with the lower-level protocol APIs, such as UDP and TCP/IP, a thing of the past?

Jim, citing the Waldo et al paper, correctly points out how things start collapsing like a house of cards when we fail to heed the collective wisdom in that paper. (Recall the infamous eight fallacies of distributed computing. Anyone designing a distributed system who does not first stop to cherish and grok these words of wisdom should be forced to have a scarlet 'E' tattooed on their forehead! But, I digress.). He continues:

Focussing on messages rather than procedure calls is a fine way to conceptualise and build services which are able to deal with the truth on the wire.

This statement is where I start to think that MEST is more about a programming model abstraction rather than an architectural style, such as that defined by REST. It's not that there's anything wrong with that, I just think that we shouldn't be confusing the two.