Re: MEP proposal

Martin Gudgin wrote:

>
>  
>
>>-----Original Message-----
>>From: FABLET Youenn [mailto:youenn.fablet@crf.canon.fr] 
>>Sent: 21 February 2003 15:52
>>To: Martin Gudgin
>>Cc: www-ws-desc@w3.org; Jeffrey Schlimmer; Amelia A. Lewis
>>Subject: 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 ?
>>    
>>
>
>I think it was along the lines of we know 2 role MEPs make the 80/20
>cut, we're not sure about 2+. All the MEPs we did decide to model were
>the former.
>
>  
>
>>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 ?
>>    
>>
>
>I don't understand this question.
>
I understood with the current defintion of WSDL abstract meps that we 
can only describe messages origin or destination in term of in or out.
If we have a 3 role mep (S, R1 and R2), then we might need to describe 
that a message is out+to R1 or is in+from R2.
I may have misunderstood the {direction} property.

>
>  
>
>>First question :
>>    If we disallow all more-than-two-nodes abstract meps, we should 
>>clearly state this in the mep definition.
>>    
>>
>
>I don't think we are disallowing people from defining 2+ role MEPs. Are
>you asking for 'number of roles' to be added to the description of the
>MEPs?
>
>  
>
>>    In this case, the direction of the message is sufficient to know 
>>where are going the messages.
>>    
>>
>
>OK
>
>  
>
>>    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
>>    
>>
>
>I can't follow this, sorry. It seems to me that you contradict yourself.
>  
>
I was thinking that {direction} could only take the in or out values.
I was saying that we should allow other values than in and out but do 
not need to show meps specification that use other values than in and out.

>  
>
>>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) .
>>    
>>
>
>I don't understand where you are going with this. 
>
>  
>
>>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.
>>    
>>
>
>I disagree that this is a MEP at all. I think this is two separate
>operations on two separate port types on two separate services. We need
>to be careful here. It is possible, using MEPs to define everything in
>terms of a single operation, essentially elevating operation to the
>level of port type. It is also possible to write complex software that
>consists of a single method called 'DoStuff' that takes a variety of
>arguments and just keeps calling itself. I'm not sure either is a
>sensible design philosophy. I would very much push for MEPs being
>relatively simple and doing more complex stuff at the port type level (
>and yes, I realise that 'simple' is somewhat subjective ).
>
I agree with you that we should keep the bar to 'simple'.
However the request and forward mep seems 'simple' to me.
This is the type of interaction that a visible intermediary would do.
Breaking this kind of operation in two operations seems strange to me 
because the link between the two operations is not obvious at all while 
using the request and forward mep makes the link clear.

>
>  
>
>>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.
>>    
>>
>
>Agreed.
>
>  
>
>>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 ?
>>    
>>
>
>I not sure I understand what you mean by semantics here.
>  
>
I think I misunderstood the in and out direction thing.
As I understood it, the direction property could only take in or out 
values and nothing else.
Now, if the direction property can target precisely nodes and have other 
values than in and out, the rest of the mail is not meanigful...

>  
>
>>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. 
>>    
>>
>
>Again I'm not sure what you mean by semantics. A service provides a
>given port type, with a set of operations that use MEPs. The service
>binds that port type to two different bindings. What's wrong with that? 
>
>Jeff and I have been thinking about a particular example of this which I
>suspect we'll talk about at the FTF.
>
>  
>
>>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.
>>    
>>
>
>I'm fairly certain I disagree.
>
>Gudge
>
>  
>