Re: MEP proposal

I'd like to make one clarification (or I hope that it is a clarification):

I understood that the decision was to disallow MEPs with more than two node ROLES, not MEPs with more than two NODES.  The multicast example (mep7) has 1 or more nodes, but precisely two node roles.

Amy!
On Fri, 21 Feb 2003 16:51:42 +0100
"FABLET Youenn" <youenn.fablet@crf.canon.fr> wrote:

> This is a good starting point :o)
> I would like to have some clarification on the abstract mep definition 
> though.
> Here are some questions
> First question: was the scottsdale decision a commitment to disallow all 
> more-than-two-nodes meps at the abstract level or was it a commitment 
> for this wg to not come up with specifications of this kind of mep ?
> Second question: If we disallow more-than-two-nodes meps at the abstract 
> level, do we disallow more-than-two-nodes meps at the binding level to 
> be used ?
> 
> First question :
>     If we disallow all more-than-two-nodes abstract meps, we should 
> clearly state this in the mep definition.
>     In this case, the direction of the message is sufficient to know 
> where are going the messages.
>     Personly I would favor :
>         - not coming up with more-than-two-nodes meps specification
>         - defining a WSDL abstract mep definition
>             - like in SOAP, where meps specifications have requirements 
> (a mep needs to have a uri, it needs to follow the feature spec...)
>         - defining a WSDL abstract mep definition that does not disallow 
> more-than-two-nodes mep
> 
> Second question :
>     I do not think we should disallow more-than-two-nodes meps at the 
> binding level. If someone creates a service with a three-nodes SOAP mep, 
> WSDL should be able to describe this service (because WSDL should 
> support the extension mechanisms provided in SOAP) .
> 
> If we do not disallow more-than-two-nodes meps at the binding level, 
> what would be their counter parts at the abstract layer. Either there 
> should have a mapping between more-than-two-nodes implementation meps 
> and the wsdl abstract meps or we should have a mulit-abstract operations 
> mapped to a single implemented operation...
> Let's look at option 1
> Let's take the Request-Forward MEP example (i.e. A sends a request to 
> service B, service B sends the result of the request to C).
> The request being an in-message and the forward being an out-message, 
> its corresponding mep should be MEP2.
> MEP2 maps also to the SOAP request-response and SOAP-response meps.
> This seems all fine and interesting because the semantics of the 
> abstract operation do not change according the chosen implementation mep.
> However, I am not sure that all cases will be like this one. Will there 
> be cases where the semantics will change according the chosen 
> implementation mep ?
> Let's take MEP3, which is One-Request/Multiple-Responses. This mep could 
> then be mapped to implementation meps like :
>     - an implementation mep that takes one request and then sends one 
> response to several nodes
>     - an implementation mep that takes one request and then sends 
> several responses to a single node (the requester ?)
> At the abstract layer, the operation is defined exactly the same in both 
> examples, but IMHO, these operations have not the same semantics. One op 
> is a multi-cast kind of request-response. The other op is a 
> send-a-request/get-the-response-over-time kind of operation.
> IMHO, this difference of semantics should appear at the abstract layer 
> and not be hidden in the binding.
>    
> Keep up the good work,
>     Youenn
> 
> 
> 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
> >
> >  
> >
> 
> 


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

Received on Friday, 21 February 2003 11:04:26 UTC