RE: What would a SOAP one-way MEP look like?

I believe the proposal mentioned by MM would be David Orchard's proposal
to the WS-Addressing wg [1]. The proposal has an HTTP binding. 
 
[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0159.ht
ml


  _____  

From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org] 
Sent: Wednesday, Mar 09, 2005 8:48 AM
To: public-ws-async-tf@w3.org
Subject: What would a SOAP one-way MEP look like?


I originally sent this out on the 7th, but it doesn't seem to be in the
archives.  From Michael Mahan's message to XMLP, it appears we may
already have such a proposal.  If so, the proposal below is redundant,
but I must have missed the original.  If not, here's something to at
least get the ball rolling for use case 1.

Attached is a strawproposal for SOAP one-way MEP, which I produced by
genetically modifying the existing request/response MEP in section 6.2
of SOAP 1.2 Adjuncts.  Several caveats:


*	This is aimed at an abstract SOAP one-way MEP.  I haven't taken
on how to bind it to HTTP, thereby sidestepping questions like how to
use HTTP POST for one-way and what response code if any to use, or
whether a cell phone polling a server for a request constitutes a
one-way message.  The hope is that just defining the abstract MEP at all
would be an incremental step forward. 

*	I'm deliberately vague on faults here.  In particular, I'm
trying to cover the non-robust WSDL MEPs.  My guess is that robust MEPs
would have to be treated separately. 

*	I took all this from the XMLP page, and munged it with
CuneAForm, which I had never used before.  The formatting looked OK on
my screen but may not on yours.  Any not-immediately-visible
information, such as anchors or other attributes, is probably nonsense.
I didn't draw a new state diagram, though to be fair I don't think the
state diagram would have added as much here.



  _____  


6. SOAP-Supplied Message Exchange Patterns and Features





6.4 SOAP One-way Message Exchange Pattern


This section defines the message exchange pattern (MEP) called
"One-way". The description is an abstract presentation of the operation
of this MEP. It is not intended to describe a real implementation or to
suggest how a real implementation should be structured.


6.4.1 SOAP Feature Name


This message exchange pattern is identified by the URI (see SOAP 1.2
Part 1 [SOAP
<imap://TSI-PA%5Cdmh@na-pa-vfe01.tibco.com:143/fetch%3EUID%3E/Sent%3E204
?part=1.1.2&filename=SOAP%20Version%201.2%20Part%202%20%20Adjuncts.htm>
Part 1] SOAP
<http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#procsoapmsgs>
Features):

*	
"http://www.w3.org/2003/05/soap/mep/one-way/"
<http://www.w3.org/2003/05/soap/mep/one-way/> 


6.4.2 Description


The SOAP one-way MEP defines the exchange of a single SOAP message
between a sender and a receiver. In the absence of failure in the
underlying protocol, this MEP consists of exactly one SOAP message.

In the normal operation of a message exchange conforming to the one-way
MEP, the message is first transferred from the sending SOAP node to the
receiving SOAP node. 

Abnormal operation during a One-way message exchange is be caused by a
failure to transfer the message. Such failure might be silent at either
or both of the sending and receiving SOAP nodes involved, or might
result in the generation of a SOAP or binding-specific fault (see
<imap://TSI-PA%5Cdmh@na-pa-vfe01.tibco.com:143/fetch%3EUID%3E/Sent%3E204
?part=1.1.3&filename=SOAP%20Version%201.2%20Part%202%20%20Adjuncts.htm>
6.4.4 Fault Handling). Also, during abnormal operation the SOAP nodes
involved in the message exchange might differ as to whether the message
exchange completed successfully. 

The scope of a one-way MEP is limited to the exchange of single message
between one sending and one receiving SOAP node. This pattern does not
mandate any correlation between multiple messages nor specific timing
for multiple messages. Implementations MAY choose to support more
complex patterns of interaction.


6.4.3 State Machine Description


The One-way MEP defines a set of properties described in
<imap://TSI-PA%5Cdmh@na-pa-vfe01.tibco.com:143/fetch%3EUID%3E/Sent%3E204
?part=1.1.4&filename=SOAP%20Version%201.2%20Part%202%20%20Adjuncts.htm>
Table 3.


Table 3: Property definitions for Request-Response MEP
Property Name	 Property Description	 Property Type	
http://www.w3.org/2003/05/soap/mep/OutboundMessage 	An abstract
structure that represents the current outbound message in the message
exchange. This abstracts both SOAP Envelope and any other information
structures that are transferred along with the envelope.	 Not
specified	
http://www.w3.org/2003/05/soap/mep/ImmediateDestination 	The
identifier of the immediate destination of an outbound message.
xs:anyURI	

To initiate a message exchange conforming to the One-way MEP, the
sending SOAP node instantiates a local message exchange context.
<imap://TSI-PA%5Cdmh@na-pa-vfe01.tibco.com:143/fetch%3EUID%3E/Sent%3E204
?part=1.1.5&filename=SOAP%20Version%201.2%20Part%202%20%20Adjuncts.htm>
Table 4 describes how the context is initialized.


Table 4: Instantiation of a Message Exchange Context for a requesting
SOAP node
Property Name	 Property Value	 Notes	
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Exchange
PatternName 	"http://www.w3.org/2003/05/soap/mep/one-way/"
<http://www.w3.org/2003/05/soap/mep/one-way/>  	 	
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureR
eason 	
"None"

A relative URI whose base URI is the value of
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Exchange
PatternName 

http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role 	
"SendingSOAPNode/"

A relative URI whose base URI is the value of
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Exchange
PatternName 

http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State 	
"Init"

A relative URI whose base URI is the value of
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role 

http://www.w3.org/2003/05/soap/mep/OutboundMessage 	An abstraction
of the message 	 	
http://www.w3.org/2003/05/soap/mep/ImmediateDestination 	An
identifier (URI) that denotes the receiving SOAP node 	 	

There may be other properties related to the operation of the message
exchange context instance. Such properties are initialized according to
their own feature specifications. 

Once the message exchange context is initialized, control of the context
is passed to a (conforming) local binding instance. 

The diagram below shows the logical state transitions at the requesting
and responding SOAP nodes during the lifetime of the message exchange.
At each SOAP node, the local binding instance updates (logically) the
value of the http://www.w3.org/2003/05/soap/bindingFramework/
ExchangeContext/State property to reflect the current state of the
message exchange. The state names are relative URIs, relative to a base
URI value carried in the
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role
property of the local message exchange context.

<figure omitted>


Figure 2: One-way MEP State Transition Diagram.

When the requesting and responding SOAP nodes transition between states,
the local binding instance (logically) updates a number of properties.
<imap://TSI-PA%5Cdmh@na-pa-vfe01.tibco.com:143/fetch%3EUID%3E/Sent%3E204
?part=1.1.6&filename=SOAP%20Version%201.2%20Part%202%20%20Adjuncts.htm>
Table 6 and
<imap://TSI-PA%5Cdmh@na-pa-vfe01.tibco.com:143/fetch%3EUID%3E/Sent%3E204
?part=1.1.7&filename=SOAP%20Version%201.2%20Part%202%20%20Adjuncts.htm>
Table 7 describe these updates for the requesting and the responding
SOAP nodes, respectively.
  
Table 6: SendingSOAP Node State Transitions
CurrentState	 Transition Condition	 NextState	 Action	
"Init"	 Unconditional	 "Sending"	 Initiate transmission of
request message abstracted in
http://www.w3.org/2003/05/soap/mep/OutboundMessage .	
"Sending"	 Message transmission failure	 "Fail"	 Set
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureR
eason to "transmissionFailure"	
Completed message transmission
	"Success"	 Set
http://www.w3.org/2003/05/soap/mep/ImmediateSender to denote the sender
of the response message (may differ from the values in
http://www.w3.org/2003/05/soap/mep/ImmediateDestination ). Start making
an abstraction of the response message available in
http://www.w3.org/2003/05/soap/mep/InboundMessage .	

 


Table 7: Responding SOAP Node State Transitions
CurrentState	 Transition Condition	 NextState	 Action	
"Init"	 Start receiving request message	 "Receiving"	 Set
http://www.w3.org/2003/05/soap/mep/ImmediateSender to denote the sender
of the request message (if determinable). Start making an abstraction of
the request message available in
http://www.w3.org/2003/05/soap/mep/InboundMessage . Pass control of
message exchange context to SOAP processor.	
"Receiving"	 Message reception failure	 "Fail"	 Set
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureR
eason to "receptionFailure".	
Message received. Message available in
http://www.w3.org/2003/05/soap/mep/OutboundMessage 	"Success"
Initiate transmission of response message abstracted in
http://www.w3.org/2003/05/soap/mep/OutboundMessage .	


6.4.4 Fault Handling

This MEP makes no claims about the disposition or handling of SOAP
faults generated by the either SOAP node.