RE: Deconstructing MEPs

As far as that goes, the in-only MEP also uses "no-faults", so it's not a perfect match for the in portion of in-out, either. And you can't use robust in-only, nor in-optional-out, either.
 
The decomposition will never be perfect if we use the existing one-way MEPs, because they have not been designed to be used in this way. We would need to change them to make them usable as components. I guess, what we'd really need is one-way components, which could be assembled in various ways to make all of the MEPs.
 
Do we need this?
 
Tony Rogers
CA, Inc
Senior Architect, Development
tony.rogers@ca.com

________________________________

From: www-ws-desc-request@w3.org on behalf of Jonathan Marsh
Sent: Tue 04-Jul-06 7:34
To: www-ws-desc@w3.org
Subject: Deconstructing MEPs



There has been a practice of modeling essentially request-response interactions (especially in the absence of WS-Addressing) as two one-way messages.  IIRC, we recommend this strategy when the request and response are over two different transports.

 

However, there seems to be a missing piece.  If I have an in-out MEP, I should be able to deconstruct it into it's component parts fairly easily.

 

"in" of "in-out" -> "in-only"

"out" of "in-out" -> "out-only", only, "in-out" uses the fault propagation rulset "fault replaces message" and "out-only" uses "no faults".

 

This shows our primitive in-only and out-only MEPs might not be adequate to decompose our multi-message MEPs.  Do we want to enable such a scenario?  If so, do we need a "fault-only" with "no-faults" MEP?  Or do we need "out-only" with a "fault-replaces message" MEP?

 

 

 [  Jonathan Marsh  ][  jmarsh@microsoft.com <mailto:jmarsh@microsoft.com>   ][  http://auburnmarshes.spaces.msn.com  ]