RE: ISSUE : Extensible message exchange patterns

Glen,

MEP definition could be an optional default extension complimenting SOAP binding (which is another optional default extension).

Do you have an example of a simple SOAP sequence implementing a MEP? How would those URIs identifying MEPs look like in a SOAP message? I was trying to locate an example and couldn't find one...

It crosses with orchestration, so it may be difficult to coerce the scope to a service definition...

-- Igor Sedukhin .. (Igor.Sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



-----Original Message-----
From: Glen Daniels [mailto:gdaniels@macromedia.com] 
Sent: Thursday, May 30, 2002 11:11 AM
To: 'www-ws-desc@w3.org'
Subject: ISSUE : Extensible message exchange patterns




Hi folks!

At last week's concall I volunteered to send out a description of this issue which came up on the call.  Sorry for the delay, I've been travelling.

The idea here is that SOAP 1.2 contains a notion of abstract MEPs [1], which are extensible in that anyone who wants to create a new one is free to write a spec, describe the distributed state machine and requirements for each state/message, and publish it.  I think it might be nice if we could tie WSDL's concept of MEP into this exact same mechanism, and therefore allow WSDL description of any MEP which can be spec'ed via SOAP's guidelines.

There are a number of ways this could be done.  The simplest is just to use the same URI for basic req/resp as SOAP does.  Slightly more complex (but perhaps ultimately more successful) would be to codify the idea of naming messages as per their role in a given MEP - so "input" and "output" would become just names that happen to map to messages in the req/resp MEP.  Though these names would likely be reused by many other MEPs (one-way, reliable-req-resp, etc), it would also be possible to use other names like "notification" or "acknowledgement".  This needs a little more thought, to be sure, but I think the idea of putting in the framework for this and only spec'ing the core cases we care about (req/resp, one-way) allows the language to expand to cover more interesting cases without needing to seriously rev the spec.  I think this warrants investigation.

--Glen

[1] http://www.w3.org/2000/xp/Group/2/05/14/soap12-part1-1.117.html#soapmep

Received on Thursday, 30 May 2002 13:07:41 UTC