Re: Deconstructing MEPs

Heylas,

The problem is matching the faulting pattern of in-out, because that faulting pattern assumes a "synchronous" connection with a "back channel" (to use a random selection of identifiers/buzzwords).

No, you can't model in-out with a pair of message exchanges, because there is no "out-only" with "fault replaces message", and the concept is slightly bizarre (or perhaps I mean to say "reeks of the lamp").  One would *only* invent such an exchange in order to perform the decomposition contemplated.

The in-out MEP is justified *because* it's a natural idiom in certain types of protocols (client/server request/response connection-oriented protocols).  If you are trying to "map" the exchange pattern onto other protocols, which have some or all of those characteristics different (pub/sub, for instance, or messaging systems, or datagram styles), then it *won't* *work* *properly*.  You'll have to do something to sort of pretend, if you squint just right and stand in the right place and have your hands *just so*, that it's the same.  It ain't.

So long as fault propagation rulesets are considered integral to the MEP, this issue will exist.  MEPs are not designed to "decompose".  An alternative solution might have been to define direction, node identity (although we made an utter @#$%^& of that, anyway), sequence, and cardinality alone, and to identify  fault propagation rulesets separately, then let them be specified in the interface or in the binding.

Jonathan, you suggest that we "recommend" the practice of decomposition.  Could you point to where we do so?  I'd like to suggest that we remove such a recommendation, if we have one.  I don't believe that it's at all a good idea.

Amy!
On Tue, 4 Jul 2006 18:22:45 +1000
"Rogers, Tony" <Tony.Rogers@ca.com> wrote:

>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  ]
>
> 
>
>


-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Wednesday, 5 July 2006 15:45:47 UTC