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

RE: Deconstructing MEPs

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Thu, 6 Jul 2006 10:49:02 -0700
Message-ID: <37D0366A39A9044286B2783EB4C3C4E803344668@RED-MSG-10.redmond.corp.microsoft.com>
To: "Amelia A Lewis" <alewis@tibco.com>, "Rogers, Tony" <Tony.Rogers@ca.com>
Cc: <www-ws-desc@w3.org>

CIL

> -----Original Message-----
> From: Amelia A Lewis [mailto:alewis@tibco.com]
> Sent: Wednesday, July 05, 2006 8:45 AM
> To: Rogers, Tony
> Cc: Jonathan Marsh; www-ws-desc@w3.org
> Subject: 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).

Buzzword adverse reactions aside, yes, that's the problem.

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

Decomposition seems to me a primary usage for the outbound MEPs, so I
don't find it too much more bizarre than these MEPs in the first place.

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

I was just suggesting defining a new MEP (or more than one), such as
out-or-fault-only, which would be in-only with the ruleset "fault
replaces message".  Not an overhaul of the framework.

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

Well, perhaps _I_ have instead of _we_ (the specs) have.  But I still
think this is a common way to model things.  Doesn't BPEL encourage this
kind of scenario?  Only under the current specs, the faults must be
modeled as application-level messages when you decompose, which may be
sub-optimal in some circumstances.

> 
> 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 Thursday, 6 July 2006 17:50:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:41 GMT