Kopretinka: Comments on Is ProcessMessage imperative?

Comment by Jim Webber

2005-02-02T11:30:08Z

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

Comment by Jacek

2005-02-02T11:38:16Z

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.

Comment by anon

2005-02-03T07:29:32Z

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.