Re: i003: WSDL 1.1/2.0 MEPs. Initial proposal (long)

Two comments inlined below.
-Anish
--

Martin Gudgin wrote:

> Issue i003[1] is about which MEPs from WSDL 1.1/2.0 WS-Addressing supports and includes asynchronous use of such MEPs.
> 
> WSDL 1.1[2] ostensibly has 4 MEPs (ne้ 'transmission primitives');
> 
> 1) One-way
> 2) Request-response
> 3) Solicit-response
> 4) Notification
> 
> WSDL 2.0[3] defines 8 MEPs;
> 
> 5) In-only
> 6) Robust In-only
> 7) In-out
> 8) In-Optional-Out
> 9) Out-Only
> 10) Robust Out-Only
> 11) Out-In
> 12) Out-Optional-In
> 
> This proposal takes the various MEPs above and notes which of the core message properties are mandatory/optional in the various messages in a given MEP. I propose we add this information to the WSDL part of the spec. Note that I am NOT suggesting that one can infer a MEP based on the presence and/or absence of message properties. 
> 
> 1.	WSDL 1.1 One-way
> 
> Message 1.
> 	Mandatory properties
> 	[destination]
> 	[action]
> 
> 	Optional properties
> 	[message id]
> 	[source endpoint]
> 	[reply endpoint]
> 	[fault endpoint]
> 	[relationship]
> 
> Comments: This is a straightforward one-way message. No responses are expected but replies could be sent as part of other message exchanges.
> 
> 2.	WSDL 1.1 Request-response
> 
> Message 1
> 	Mandatory properties
> 	[destination]
> 	[action]
> 	[reply endpoint]
> 	[message id]
> 

Any particular reason why [reply endpoint] should be mandatory. I.e., if 
[source endpoint] is specified, the reply/fault endpoint can default to 
the source (a la WS-MD).
This is similar to what SMTP does with From/Reply-to headers.

> 	Optional properties
> 	[source endpoint]
> 	[fault endpoint]
> 	[relationship]
> 
> Message 2
> 	Mandatory properties
> 	[destination]
> 	[action]
> 	[relationship]
> 
> 	Optional properties
> 	[message id]
> 	[source endpoint]
> 	[reply endpoint]
> 	[fault endpoint]
> 
> Comments: This is request-response. A reply is expected hence mandating [reply endpoint] in message 1. Message 2 might be a fault.
> 
> 3.	WSDL 1.1 Solicit-Response
> 
> 	As 2.
> 
> Comments: This is the same as 2, but reversed (from the *WSDL* perspective) in terms of which party sends the first message. WS-Addressing doesn't care about this distinction, hence it being the same as 2.
> 
> 4.	WSDL 1.1 Notification
> 
> 	As 1.
> 
> Comments: This is the same as 1, but reversed (from the *WSDL* perspective) in terms of which party sends the first message. WS-Addressing doesn't care about this distinction, hence it being the same as 1.
> 
> 5.	WSDL 2.0 In-only
> 
> Message 1.
> 	Mandatory properties
> 	[destination]
> 	[action]
> 
> 	Optional properties
> 	[message id]
> 	[source endpoint]
> 	[reply endpoint]
> 	[fault endpoint]
> 	[relationship]
> 
> Comments: This is essentially the same as 1.
> 
> 6.	WSDL 2.0 Robust In-only
> 
> Message 1.
> 	Mandatory properties
> 	[destination]
> 	[action]
> 	[message id]
> 	
> 	Optional properties
> 	[relationship]
> 	[source endpoint]
> 	[reply endpoint]
> 	[fault endpoint]
> 
> Message 2.
> 	Mandatory properties
> 	[destination]
> 	[action]
> 	[relationship]
> 	
> 	Optional properties
> 	[source endpoint]
> 	[reply endpoint]
> 	[fault endpoint]
> 	[message id]
> 
> Comments: This one-way MEP allows fault messages. Any fault message MUST be sent to the originator of Message 1. So if [fault endpoint] appears then [source endpoint] MUST also appear and the two properties MUST be exactly the same. We need [message id] in order to be able to correlate any fault with message 1.
> 
> 7.	WSDL 2.0 In-Out
> 
> Message 1
> 	Mandatory properties
> 	[destination]
> 	[action]
> 	[source endpoint]
> 	[reply endpoint]
> 	[message id]
> 
> 	Optional properties
> 	[relationship]
> 	[fault endpoint]
> 
> Message 2
> 	Mandatory properties
> 	[destination]
> 	[action]
> 	[relationship]
> 
> 	Optional properties
> 	[message id]
> 	[source endpoint]
> 	[reply endpoint]
> 	[fault endpoint]
> 
> Comments: This two-way MEP states that Message 2 MUST be sent to the originator of Message 1 (even if it's a fault). So for message 1 the [reply endpoint] property MUST be exactly the same as the [source endpoint] property. And if [fault endpoint] appears it must also be exactly the same as the [source endpoint] property. I could see making the [source endpoint] property optional and stating that [reply endpoint] is considered to be the originator. And then say that IF [source endpoint] and [reply endpoint] appear then they must be exactly the same.
> 
> 8.	WSDL 2.0 In-Optional-Out
> 
> 	As 7.
> 
> Comments: This MEP differs from 7. in that Message 2 is optional. This difference doesn't affect the message properties.
> 
> 9.	WSDL 2.0 Out-only
> 
> 	As 5.	
> 
> Comments: This is the same as 5, but reversed (from the *WSDL* perspective) in terms of which party sends the message. WS-Addressing doesn't care about this distinction, hence it being the same as 5.
> 
> 10.	WSDL 2.0 Robust Out-only
> 
> 	As 6.
> 
> Comments: This is the same as 5, but reversed (from the *WSDL* perspective) in terms of which party sends the first message. WS-Addressing doesn't care about this distinction, hence it being the same as 6.
> 
> 11. 	WSDL 2.0 Out-in
> 
> 	As 7.
> 
> Comments: This is the same as 5, but reversed (from the *WSDL* perspective) in terms of which party sends the first message. WS-Addressing doesn't care about this distinction, hence it being the same as 7.
> 
> 12.	WSDL 2.0 Out-optional-in
> 
> 	As 11.
> 
> Comments: This MEP differs from 11. in that Message 2 is optional. This difference doesn't affect the message properties.
> 
> Observations:
> 
> Despite there being 12 MEPs, there are only 5 WS-Addressing 'patterns'.
> 
> None of the WSDL 2.0 MEPs provide for sending fault messages to a different endpoint than the sender of the initial message.
> 
> The WSDL 2.0 MEPs say that response message are send back to the same node. But it's not clear from a WS-Addressing perspective whether this means same [address], [address] + [reference properties] or [address] + [reference properties] + [reference parameters]. I'm leaning toward the second.
> 

The issue, I think, is the fact that WSDL 2.0 part 2 (MEPs) does not 
define what a node is.

> Regardless of the answer to the previous point, the WSDL 2.0 MEPs don't lend themselves very well to being performed over, say, 2 distinct HTTP connections, one in one direction, one in the other. Because of the requirement to send subsequent messages to the originator it seems that I can't send a message to http://example.org/server/ from the anonymous endpoint and have replies sent to http://example.org/client/. I could say that the [source endpoint] had an [address] of http://example.org/client/ I suppose, but that doesn't seem to necessarily be true.
> 
> 
> Asynchronous MEP usage. 
> 
> The second part of this issue to to do with asynchronous usage of the WSDL MEPs. I'm not entirely sure what the definition of asynchronous is in this context, but I'm going to base the following on the assumption that it means that in cases where response messages are returned, they are NOT returned over the same network connection that was used to deliver the request. Therefore the sender of the initial message doesn't have to wait around for the response. I realise this may not match what some people think of when they think about asynchrnous behaviour, hopefully we can get to a shared definition for the purposes of resolving this issue fairly quickly.
> 
> I think the main point to make here is that WS-Addressing doesn't really care whether a given MEP is being used asynchronously or not. If [source endpoint] and [reply endpoint] are different (and the [address] property of the [reply endpoint] is NOT the 'use the back channel' URI) then the request and response messages can be sent over separate network connections. IN fact, even if [source endpoint] and [reply endpoint] were the same ( and again, the [address] property of the [reply endpoint] was not the 'use the back channel' URI) then separate connections could still be used to send the messages. It seems to me that the support or lack thereof for asynchrony is more a function of the WSDL MEP (esp. in the case of 2.0) and the actual binding in use than a function of any addressing headers.
> 
> That said, if the [address] property of the [reply endpoint] is the 'use the back channel' URI and the binding in use is the SOAP 1.1 WSDL binding or the SOAP 1.2 Request-Response MEP then asynchrony is ruled out as the response is required to travel down the same HTTP connection used to send the request.
> 
> Cheers
> 
> Gudge
> 
> [1] http://www.w3.org/2002/ws/addr/wd-issues/#i003
> [2] http://www.w3.org/TR/wsdl#_porttypes
> [3] http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#meps
> 
>

Received on Tuesday, 16 November 2004 01:33:23 UTC