RE: Deconstructing MEPs

At this point my concern is only theoretical, I'd heard of folks (were
they BPEL users?) modeling request-response messages as two one-way
messages, but realized fault propagation rules make that more difficult.

At this point, I don't think adding MEPs is practical, since it's likely
some of the existing ones are marked at risk.

> -----Original Message-----
> From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
> Sent: Sunday, August 06, 2006 6:50 PM
> To: Jean-Jacques Moreau
> Cc: Amelia A Lewis; Jonathan Marsh; www-ws-desc@w3.org
> Subject: RE: Deconstructing MEPs
> 
> 
> 
> I think WS-Addressing is looking for Schroedinger's MEP - the one that
> might be in-only or in-out, but you don't know which until you look in
> the message...
> 
> Tony Rogers
> tony.rogers@ca.com
> 
> -----Original Message-----
> From: Jean-Jacques Moreau [mailto:jean-jacques.moreau@crf.canon.fr]
> Sent: Wednesday, 2 August 2006 17:48
> To: Rogers, Tony
> Cc: Amelia A Lewis; Jonathan Marsh; www-ws-desc@w3.org
> Subject: Re: Deconstructing MEPs
> 
> So shall we assume that, at least for this version of the spec, quatum
> MEPs have not been discovered yet and we are still relying on good old
> style Newtonian MEPs? Unless Jonathan has a really pressing need of
> course.
> 
> JJ.
> 
> Rogers, Tony wrote:
> > I agree, even though I hadn't articulated it with the clarity that
Amy
> 
> > has done. Yes, the MEPs we have today are atomic, which is why we
> > strike these nasty problems in trying to decompose them.
> >
> > MEP quarks (to stretch our metaphor well past its breaking point...
> > and yes, I know I've skipped the electron/proton level) work
> > differently from MEP atoms. The classic in-out MEP atom uses
> > fault-replaces-message; the component quarks would have an "in"
quark,
> 
> > and an "out-or-fault" quark - not too difficult. The robust-in-only
> > atom would use the "in" quark and a "out-fault-or-nothing" quark.
> > Clearly the quarks would have different properties from the atoms.
> > That should be a surprise - the reason we're discussing this is
> > because of those different properties. In particular, we must note
> > that the quarks do NOT have patterns like "fault-replaces-message" -
> > those patterns are a property of the atomic level, rather than the
> > quark level.
> >
> > Tony Rogers
> > CA, Inc
> > Senior Architect, Development
> > tony.rogers@ca.com <mailto:tony.rogers@ca.com> co-chair UDDI TC at
> > OASIS co-chair WS-Desc WG at W3C
> >
> >
----------------------------------------------------------------------
> > --
> > *From:* www-ws-desc-request@w3.org on behalf of Amelia A Lewis
> > *Sent:* Tue 11-Jul-06 1:30
> > *To:* Jonathan Marsh
> > *Cc:* www-ws-desc@w3.org
> > *Subject:* Re: Deconstructing MEPs
> >
> >
> > Heyo.  Responses inline.
> >
> > On Thu, 6 Jul 2006 10:49:02 -0700
> > "Jonathan Marsh" <jmarsh@microsoft.com> wrote:
> > >> -----Original Message-----
> > >> From: Amelia A Lewis [mailto:alewis@tibco.com]  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.
> >
> > Then we part company *very* early on in the discussion.
> >
> > It seems to me that the justification for "message exchange
patterns",
> 
> > such as it is, is that it models 'atoms' of a particular networking
> > paradigm, that these 'atoms' are more or less self-contained (this
> > permits optionality, but retains the belief, or possibly the
> > assertion, that there is a "thing" that a MEP corresponds to).
> >
> > out-initial MEPs happen to work *very well indeed* to model network
> > paradigms which are not "client/server".  Certainly c/s is dominant
> > (particularly inasmuch as HTTP is c/s and it is dominant in SOAP
> > deployments), but it is neither universal nor always optimal.  The
> > 'atoms' of pub/sub, for instance, typically work best with
out-initial
> 
> > MEPs of various flavors.
> >
> > Considered from this perspective, there is nothing bizarre about
> > out-initial MEPs.  They model something that happens not to be in
the
> > client/server worldview (server-initiated activity), but that isn't
> > "bizarre" when other paradigms are foundational, it's entirely
> natural.
> >
> > If MEPs are 'atoms', then decomposing them should create something
> > that isn't another 'atom' (MEP).  If they aren't atomic, then we
> > should feel pretty nervous about having them at all.  This leads to
> > wondering about creating a description language in which messages
are
> > simply listed, with their direction and the possible responses that
> > they could draw ... and boom we're out of scope for WSDL.
> >
> > >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.
> >
> > s/in-only/out-only/
> >
> > *shrug*  I think it's a silly and bizare MEP, but then, I think the
> > same of several of the others (which, in my opinion, were created to
> > soothe someone's need for parity, rather than to model actual
> > networking idioms).
> >
> > >> Jonathan, you suggest that we "recommend" the practice of
> > >>decomposition.
> > >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.
> >
> > Out of my knowledge base, I'm afraid.  The argument, then, is that
> > people are using things in this fashion, so we need to adjust our
> > model (dropping the concept of atomicity in MEPs) to match?
> >
> > Ugh.  *sigh*  On the other hand, in the end, it probably doesn't
> > matter much, and I'm not sure that we've managed, despite all the
> > shouting and lengthy negotiations, to achieve a definition of MEP
that
> 
> > has any conceptual integrity.
> >
> > Amy!
> > --
> > Amelia A. Lewis
> > Senior Architect
> > TIBCO/Extensibility, Inc.
> > alewis@tibco.com
> >
> >
>

Received on Wednesday, 9 August 2006 18:40:21 UTC