RE: Deconstructing MEPs

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