W3C home > Mailing lists > Public > public-ws-desc-comments@w3.org > October 2006

RE: Deconstructing MEPs

From: Jonathan Marsh <jonathan@wso2.com>
Date: Mon, 16 Oct 2006 11:14:04 -0700
To: "'Jonathan Marsh'" <jonathan@wso2.com>
Cc: <public-ws-desc-comments@w3.org>
Message-ID: <00b601c6f14e$de8f3c70$3901a8c0@DELLICIOUS>
Thanks for your comment.  The WS Description Working Group tracked this
issue as a CR069 [1].


The Working Group declined to add any new MEPs at this stage.


Unless you let us know otherwise by the end of October, we will assume you
agree with the resolution of this issue.


[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR069 


Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com



From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Jonathan Marsh
Sent: Monday, July 03, 2006 2:35 PM
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  ][   <mailto:jmarsh@microsoft.com> jmarsh@microsoft.com
][  http://auburnmarshes.spaces.msn.com  ]

Received on Monday, 16 October 2006 18:14:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:31:05 UTC