W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2006

RE: Deconstructing MEPs

From: Rogers, Tony <Tony.Rogers@ca.com>
Date: Tue, 4 Jul 2006 18:22:45 +1000
Message-ID: <BEE2BD647C052D4FA59B42F5E2D946B317B598@AUSYMS12.ca.com>
To: "Jonathan Marsh" <jmarsh@microsoft.com>, <www-ws-desc@w3.org>
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


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  ]

Received on Tuesday, 4 July 2006 08:25:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:55:00 UTC