Is ProcessMessage imperative?

Continuing on the topic of MEST, I've had reactions from Savas and Jim and also a few comments on my previous post, from which it seems I wasn't clear enough in my post.

Basically, I was baffled until recently about what exactly MEST is meant to be. Yesterday I thought it might be about the imperative of SOAP's MustUnderstand semantics, i.e. MustUnderstand headers in SOAP messages must be processed according to their specification or the receiver must not process the message at all. After reading the replies, I'm getting the impression that MEST is really just a catchy name intended to promote the lower-level message passing network interface as opposed to any abstractions built on top of that.

So here's a question to the MEST folks: does MEST imply/require the imperative semantics or should ProcessMessage (AndDoWhatISay) really be named HereIsAMessage (DoWhatYouWillWithIt)?

By the way, I'm highly encouraged by the fact that at least some of the MEST people actually seem to read my blog. 8-)

Posted at 0939 on Wed, Feb 2, 2005 in category Ideas | TrackBack | Comments feed
Comments

Hey Jacek,

MEST isn't imperative. In fact it's deliberately un-imperative. The focus of MEST is simply on the transfer of SOAP messages. The action taken on receipt of a SOAP message is a function of the structure and content of that message, and the receiving service implementation.

This, we believe, helps with loose coupling and robustness and enables other useful stuff like straightforward scalability and fail-over.

Jim

Posted by: Jim Webber at February 2, 2005 12:30 PM

Jim, what's more important in determining the action on a receipt of a message - the content of the message or the implementation? I.e. can you construct a message that will make me print something out or fail if I cannot print, or is it me who decides totally what I do with the message, possibly basing my decisions on the content of the message?

If it's the latter, MEST seems only like a new name for an old thing, not even bringing things together in a novel way. The value of MEST would only be in PR.

Posted by: Jacek at February 2, 2005 12:38 PM

Hi Jacek. I think this entry and your comment on Jim's post gets right to the core of the problem. As far as I can see (like yourself), MEST is describing a "plain 'ol message passing" paradigm or, put as you put it ProcessMessage is HereIsAMessage. It doesn't add anything architecturally to the same old debates we've seen around MOM for years.

Posted by: anon at February 3, 2005 8:29 AM