W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2003

RE: MEP proposal

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Fri, 21 Feb 2003 08:02:38 -0800
Message-ID: <92456F6B84D1324C943905BEEAE0278E02D30D0E@RED-MSG-10.redmond.corp.microsoft.com>
To: "Jacek Kopecky" <jacek@systinet.com>, "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com>, "Amelia A. Lewis" <alewis@tibco.com>
Cc: "WS Description WG" <www-ws-desc@w3.org>



> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@systinet.com] 
> Sent: 21 February 2003 15:42
> To: Martin Gudgin; Jeffrey Schlimmer; Amelia A. Lewis
> Cc: WS Description WG
> Subject: Re: MEP proposal
> 
> 
> Amy, Gudge, Jeff,
> 
> I think it's the good direction. I do have comments/questions:
> 
> The MEPs say nothing about where the 'in' messages come from 
> or where the 'out' messages go to, which may be confusing. 

Everything is described from the POV of the service. Therefore input
messages are messages the service accepts, output messages are messages
the service sends. I don't see any need at the WSDL level to say anymore
than that.

> Although I first thought it's OK, the MEP8 below suggests 
> otherwise. Without the comments specifying the 
> sources/destinations, the MEP would be extremely abstract and 
> confusing.

I think the intent is that the MEPs at the operation level in WSDL be
abstract.

> 
> Why does a fault reference refer to possibly multiple 
> messages? Why is this not similar to normal message 
> references? What does it mean if a fault reference 'C' refers 
> to messages 'M1' and 'M2'?

It means that either message M1 or message M2 can appear at point 'C' in
the MEP. We ( Amy, Jeff and I ) wrestled for a while with how to deal
with faults and this is one approach, which we think captured the intent
of the direction decided at the FTF. We also thought a little about
generalizing message references to allow multiple messages, but I don't
think it makes the 80/20 cut.

> 
> Will MEPs and message references in the MEPs document be 
> named in any more sensible way? (I believe naming was just 
> put off 'till later - a good idea there.)

Naming the MEPs something other than MEP1-7? I don't really mind. I
would suggest we leave them as is because then they don't accumulate any
baggage due to people reading particular properties into a particular
name.

Naming the message references something other than 'A', 'B', 'C'? I
guess we could, again I don't really see the benefit, they're just there
to allow us to sequence things.

> 
> Who will specify (and where will that be) the relationships 
> between SOAP MEPs, possible abstract MEPs (if anyone comes up 
> with such beasts) and WSDL MEPs? 

WSDL bindings will specify the relationship between the MEPs at the
operation level in WSDL and the SOAP MEPs.

> For example, SOAP 
> Request/Response maps to MEP2, SOAP Response maps either to 
> MEP4 or MEP2, and a potential SOAP Req/Resp MEP involving one 
> intermediary would map to two WSDL MEPs - MEP2 for the 
> service and MEP8 (below) for the intermediary. And that's not 
> considering describing the client in a WSDL. 8-)

We agreed that WSDL describes things from the POV of the service.

> 
> MEP8: exactly two or four messages:
>   1) an in message A        // coming from client
>   2) optionally
>     i) an out message B     // going to service
>    ii) one of the following 
>       x) an in message C    // coming from service
>       y) an in fault D      // coming from service
>   3) one of the following
>     i) an out message E     // going to client
>    ii) an out fault F       // going to client
> 
> (just a fast-and-dirty hack of an MEP)

I don't see the need for such a MEP in our spec for a couple of reasons.
We agreed at the FTF to describe MEPs for 2 nodes only initially and I
think the presence of intermediaries should be transparent to a given
MEP.

> 
> The comments above (after //s) might be put in a note below 
> the text of the MEP as the expected usage, or something.
> 
> I guess that's all of it. No flames, I must be having a bad day. 8-)
> 
> Best regards,
> 
>                    Jacek Kopecky
> 
>                    Senior Architect, Systinet Corporation
>                    http://www.systinet.com/
> 
> 
> 
> 
> 
> On Thu, 2003-02-20 at 18:11, Martin Gudgin wrote:
> > We agreed at the Scottsdale FTF to incorporate MEPs into 
> our design. 
> > Amy, Jeff and I have done some work on this. Proposed 
> changes to part 
> > 1 are detailed in[1,2] using diff markup. Proposed 
> definitions for the 
> > 7 MEPs we decided to define are at[3,4].
> > 
> > Comments, suggestions, flames etc. to the usual address.
> > 
> > Gudge
> > 
> > [1] 
> > 
> http://dev.w3.org/cvsweb/>
~checkout~/2002/ws/desc/wsdl12/wsdl12.xml?rev
> > =1
> > .46.2.3&content-type=text/xml
> > [2]
> > 
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12
.html?rev=
> 1.21.2.1&content-type=text/html
> [3]
>
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-meps.xml?
> rev=1.6&content-type=text/xml
> [4]
>
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-meps.html
> ?rev=1.1&content-type=text/html
Received on Friday, 21 February 2003 11:03:32 GMT

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