RE: MEP proposal

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

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

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

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

> 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

Received on Friday, 21 February 2003 11:19:15 UTC