Chris's Rants

Tuesday, February 01, 2005

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.


  • Chris,

    I didn't mean to imply that you said that message-passing and procedure calls are equivalent, but one of the comments posted to your previous entry did and it was that comment I wanted to challenge, not your original posting.

    As for the paper, yes, there will be one of these days. We have been writing it on and off for months, but the day job always seems to get in the way. How about you agree to act as a reviewer to spur us on? :-)


    By Anonymous Anonymous, at February 02, 2005 10:22 PM  

  • I get the impression that the MEST guys haven't read some pretty fundamental texts, like Tanenbaum's Concepts and Designs of Distributed Systems. It's been around in one edition or another for well over a decade and is highly relevant today.

    By Anonymous Anonymous, at February 03, 2005 2:09 AM  

  • I'd really love to see why pub-sub as a unifying architectural principle for loosley-coupled systems doesn't fit the bill that the MEST advocates say their stuff does. I'm not saying that pub-sub is the only paradigm that's come up in MOM over the past 2 decades, but it's the one that seems to keep coming back again and again, for pretty good reasons.

    By Anonymous Anonymous, at February 03, 2005 2:33 AM  

Post a Comment

<< Home