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 Monday, 10 July 2006 15:30:19 UTC