RE: MEP proposal

 

	-----Original Message-----
	From: FABLET Youenn [mailto:youenn.fablet@crf.canon.fr] 
	Sent: 21 February 2003 16:54
	To: Martin Gudgin
	Cc: www-ws-desc@w3.org; Jeffrey Schlimmer; Amelia A. Lewis
	Subject: 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.
	 
	[MJG]
	I don't think you have misunderstood the {direction} property.
However, as I stated in my previous mail, I think that such an
interaction should be modelled using multiple port types.

		
		  

			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. 
	 
	[MJG]
	I now understand your point. I disagree. I think that in and out
are enough and that any 2+ node interactions should be modelled using
multiple port types. 
	

		  

			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.  
	 
	[MJG]
	I don't understand why intermediaries should be visible to WSDL.
	 
	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. 
	 
	[MJG]
	There are a whole load of things in Web Services that you
eventually have to write down in some human readable ( as opposed to
machine readable ) language. To me this doesn't make the 80/20 cut for
the latter.
	
	

			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... 
	 
	[MJG]
	You have not misunderstood. In and out are the only allowable
values.
	

			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