Re: MEP proposal

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

Received on Friday, 21 February 2003 10:52:20 UTC