OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrm] NEC position -> SOAP binding independency


 I would like to comment one of your points below:

> h]  R3.4.3 seems to be an implementation issue ("w/o any change in the
> WS-Reliability implementation") and needs to be clarified.  
> Does it really mean: "It must be possible to change the SOAP 
> binding w/o
> any change in SOAP message header elements which contain WS-RM
> information."  That implies independence between SOAP message 
> content and
> SOAP binding.  If so, the synchronous attribute of "Ack 
> Required" could be
> a problem.

I am sorry for being long, but in order to present my view on the attribute you mentioned, I need to draw my model of SOAP messaging. Then I will try to apply this model to this very case to show that the problem you raised doesn't prevent the upcoming specification to be independent from the SOAP bindings. Then I will give a short summary of my argument.

Something about the terminology I would like to use: (I'm sorry to use the term MEP very extensively, but I am sure that it is a fundamental and useful abstraction of SOAP)

 - There are the abstract Message Exchange Patterns of SOAP. They consist of messages that are correllated if there are more than one.
 - There are standard SOAP MEPs that SOAP specification explicitely addresses: One-Way and Request-Response. (I don't want to detils here, we all know what they mean)
 - The SOAP bindings are the actual implementation of these MEPs with actual transport protocols. 
 - For every MEP you need a binding to implement it. 

 - Therefore given an actual transport protocol, you need at least two bindings for that protocol: one for the One-Way and one for the Request-Reponse MEP in order to cover the standard SOAP features.)

All the statements above are about the standard SOAP level. As for the Reliable-SOAP level, let's concentrate only one One-Way MEP for the time being to cover the question you have raised.


The submitted WS-Reliability spec only offers one-way messages. So on the Reliable-SOAP level we have one message: a Reliable One-Way Message (abbreviated as RM, from A to B)
    RM: A->B   

On the SOAP level, we need two ordinary SOAP messages to implement the Reliable One-Way message.
 1. - MESSAGE: That contains the content of the Reliable Message.
 2. - ACK: That is the acknowledgement. 
So on the SOAP level we have two SOAP-level messages to be transferred. 

    ACK    : B->A

  The two message need to be correlated.

Trying to cover the logic behind the WS-Relibaility/1.0, we have a choice. As SOAP defines standard Message Exchange Patterns, we can choose, how we implement the two logical messages above. We can use

  a)  one Request-Response SOAP MEP (direction A->B). 
  The RR (Request-Response) MEP consist of two messages: [req] and [req]. (I use different notion for messages to show that they are at different levels)

  The mapping is as follows:
       MESSAGE <-> [req]     { direction match A->B }
	 ACK     <-> [res]     { direction match B->A }
 Here it is not necessary to correlate MESSAGE and ACK explicitely as the Request-Response MEP solves this already on the SOAP level.

  b)  two One-Way MEP  (direction A->B and B->A)
  The One-Way MEP only consist of one message: [Mes]. We use two One-Way patterns to implement this, so we have [Mes]-1 and [Mes]-2
  The mapping is as follows:

       MESSAGE <-> [mes]/1     { direction of [mes]/1 must be set to A->B }
       ACK     <-> [mes]/2     { direction of [mes]/2 must be set to B->A }

  Here there is a need for explicit correlation of MESSAGE and ACK. It must be solved by correlating [mes]/1 and [mes]/2.

Note, that we haven't used any bindig-specific information until now. We exploited only the abstract Message Exchange Patterns. So the model above can work with every bindings that offer One-Way and Request-Response MEPs.
--> Let's try to apply the theory above to the WS-Reliability 1.0 proposal 

 If you set the synchronous attrbiute of AckRequested to "true" -> it matches 
   - option a) above 
   - with the standard SOAP HTTP binding of the Request-Response MEP.
   - the RefToMessageID could even be omitted.

 If you set the synchronous attribute of AckRequested to "false" -> it matches
   - option b) above
   - with a semi-standard SOAP HTTP binding of the One-Way MEP.
   - RefToMessageID element is used for correlating MESSAGE and ACK.

You may realize that for the sake of simplicity I have omitted Faults. Of course the implementation of the Reliable One-Way message is that 
   MESSAGE       : A->B
   ACK | FAULT   : B->A
But ACK can be subsituted wih FAULT in the model above, and same same modes of a) and b) can be deduceted depending on the value of the attribute "synchronous". So the Fault-case is also covered by the abstract model above.

My argument is that the mode of operation you refer to, and what is controlled by the "synchronous" attribute in the Ws-Reliability/1.0 proposal, is dependent on Message Exchange Patterns of SOAP. It is not dependent on the SOAP transoprt bindings directly. 
Any transport bindings that offer One-Way and Request-Response Message Exchange Patterns can be used in the way described above.

			Best regards,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]