Re: agenda for today's MEP call

I'd be very happy to see a lot of this dropped; less work for me.

I don't think that the tool builders are likely to be very happy with us
if we keep current definitions that do not permit specification of where
the response message goes.  If choreo languages can live without it (or
can effectively ignore the fact that the current set of definitions does
not actually require classic request/response semantics), then that's
fine, and we don't need to worry about those folks.

The original discussion of MEPs had to do with the call to throw away
outbound operations, as I recall.  However, the current task force was
in fact formed after the resolution of that issue resulted in the
initial draft of the MEPs subdocument (part two), in large part as a
response to Gudge's "Interesting Pattern".  That pattern *does* comply
with the definition of sequence, cardinality, and direction applied to
classic request/response, but *is not* (at all) classic
request/response. Initial response to the presentation was "oh, that's
fine," but after folks went off and thought about it a bit, several came
back with the solid requirement that the specification of
request/response *had* to exist, that they *required* the ability to
expect that the response message would be returned to the source of the
request message.  This in turn led to questions about whether the
current definition of patterns (cardinality, sequence, direction) were
adequate.

We probably could live with a single request/response MEP, but the
initial "pattern two" in part two *was not it*.  So we added pattern
three (which is, specifically, request/response), and then the task
force was organized to determine if the overall definition of patterns
that we had adopted was inadequate, and if so, what needed to be added.

Or such is my recollection of the history, in any event.

Amy!
On Tue, 17 Jun 2003 20:55:58 +0600
"Sanjiva Weerawarana" <sanjiva@watson.ibm.com> wrote:

> "Amelia A. Lewis" <alewis@tibco.com> writes:
> > 
> > I don't believe that the requirements put forward by SOAP/XMLP are what
> > is driving the attempt to better define patterns.  I believe that the
> > primary drivers come from the folks who are creating tools that generate
> > client stubs.  The primary argument seems to be that, if an input/output
> > pattern is defined using only direction, cardinality, and sequence, then
> > the client cannot expect to get a response, to be the only person
> > getting a response, and may receive responses without sending requests.
> 
> IIRC the whole MEP thing started as a way to deal with the
> outbound operations problem. The problem of course was that
> different people had different interpretations of the outbound
> ops. The idea was that MEPs would provide a way to provide
> clarity and semantics to make it clear to all what the various
> patterns are.
> 
> I think we should restrict ourselves to clarifying the outbound
> patterns rather than exploding the simple request-response MEP.
> My point about SOAP 1.2 was to point out that it appears that
> SOAP can live with a single r-r MEP and so why can't we?
> 
> > I believe that choreography languages could probably also benefit from
> > better definition of where messages go ("out" from the service may not
> > be enough), or where they come from (if those languages use WSDL as a 
> > base, that is).
> 
> I'm a co-author of two WSDL-based choreography languages (WSFL and
> BPEL) and neither needed this. BPEL uses partners to solve the where
> do messages come from and where do they go problem. 
> 
> We haven't seen how MEPs will materialize in WSDL yet, but I am
> concerned that we're introducing a lot of complexity to handle
> somewhat edge cases. I guess I'll have to wait and see.
> 
> Sanjiva.
> 


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

Received on Tuesday, 17 June 2003 11:43:33 UTC