W3C home > Mailing lists > Public > public-ws-async-tf@w3.org > March 2005

What would a SOAP one-way MEP look like?

From: David Hull <dmh@tibco.com>
Date: Wed, 09 Mar 2005 11:48:00 -0500
To: public-ws-async-tf@w3.org
Message-id: <422F28C0.2050802@tibco.com>
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 Part 1] 
SOAP Features 



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

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 *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. *Table 
describes how the context is initialized.

Table 4: Instantiation of a Message Exchange Context for a requesting 
SOAP node Property Name 	Property Value 	Notes



A relative URI whose base URI is the value of 




A relative URI whose base URI is the value of 




A relative URI whose base URI is the value of 

|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 
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. 
*Table 6* 
and *Table 7* 
describe these updates for the requesting and the responding SOAP nodes, 
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 
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 
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.
Received on Wednesday, 9 March 2005 17:07:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:48:42 UTC