- From: David Hull <dmh@tibco.com>
- Date: Wed, 09 Mar 2005 14:52:49 -0500
- To: public-ws-async-tf@w3.org
- Message-id: <422F5411.4020300@tibco.com>
Aha. That explains the nagging feeling I had that this had already been done ... I haven't read Dave's proposal yet, because Firefox can't seem to find the schema and so thinks it's invalid, but given that Dave's proposal has been out longer, is more complete and is almost certainly better thought out, I'll gladly take my effort off the table. Yalcinalp, Umit wrote: > 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.html > > ------------------------------------------------------------------------ > *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 Part 1] > <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> > SOAP Features > <http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#procsoapmsgs>): > > * > > "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 *6.4.4 Fault Handling* > <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>). > 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 *Table 3* > <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: 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 4* > <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> > 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/ExchangePatternName| > "http://www.w3.org/2003/05/soap/mep/one-way/" > |http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason| > > > "None" > > > > A relative URI whose base URI is the value of > |http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName| > > > |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/ExchangePatternName| > > > |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. *Table 6* > <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> > and *Table 7* > <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> > 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/FailureReason| > 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/FailureReason| > 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 19:53:23 UTC