[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] NEC position -> SOAP binding independency
My belief on this topic is that bindings are not our primary focus for WSRM.
I think first we need to define the semantics of reliability and
implementation at the SOAP header level, and then perhaps take on the task
of defining the "concrete implementation" at the WSDL level, which will
include the bindings. I view these two activities as being independent and
decoupled from each other. What we create should work across any binding.
Note that many of the other WS-?? Specs do not define bindings at all so it
is not clear to me that we need do that. However, doing so will probably
help people in understanding how to use WSRM.
Scott Werden
WRQ, Inc.
> -----Original Message-----
> From: Szabolcs.Payrits@nokia.com [mailto:Szabolcs.Payrits@nokia.com]
> Sent: Friday, April 25, 2003 10:50 AM
> To: ajwdct@technologist.com; wsrm@lists.oasis-open.org
> Subject: RE: [wsrm] NEC position -> SOAP binding independency
>
>
> Hi,
>
> 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.
>
> (Explanatory)
> - 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.
>
> MESSAGE: A->B
> 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.
>
> Summary:
> --------
>
> 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,
> Szabolcs
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]