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


Scott, Payrits and all

We agree that transport bindings are not the primary focus of the WS-RM TC and that the WS-RM spec should work properly, independent of binding.

However, we still recommend that examples of transport bindings be
contained in an Appendix/ Informative Annex of the spec.  This is
because the choice of binding (and how the binding uses TCP or a
different Transport protocol) will have a measurable impact on the SOAP messaging (end to end or intermediary) connection.  The binding may
also be important for the configuration time setting of WS-RM parameters
(e.g. No ACK timer and retry counter) and meaning of failure
indications.

Summary points on WS-RM relationship to transport bindings:

1.  WS-RM should provide end to end reliable delivery of SOAP
messages/MEPs to the App layer above, independent of the transport
binding below.  See point 4. below

2.  Each type of SOAP MEP requires a separate binding, e.g. 1-way,
Request/Response, other?  Any binding that supports SOAP MEPs can be
used.  However..................

3.  The choice of binding may dictate the reliability and robustness
of the underlying end to end connection.  SOAP messages may be lost,
duplicated, or arrive out of sequence, depending on the reliability
of the underlying subnetworks, the transport binding, and how that
binding invokes TCP or another Transport layer protocol (?).

4.  WS-RM layer will attempt to recover from message loss,
duplication, or misordering, independent of the binding and Transport
layer protocol

Thanks for your attention and consideration

Alan Weissberger
DCT (NEC)
2013 Acacia Ct
Santa Clara, CA 95050-3482
1 408 863 6042 voice
1 408 863 6099 fax
----- Original Message -----
From: Scott Werden <scottw@wrq.com>
Date: Mon, 28 Apr 2003 09:08:36 -0700
To: "''Szabolcs.Payrits@nokia.com''" <Szabolcs.Payrits@nokia.com>, ajwdct@technologist.com, wsrm@lists.oasis-open.org
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
> > 
> > 



Alan Weissberger
2013 Acacia Ct
Santa Clara, CA 95050-3482
1 408 863 6042 voice
1 408 863 6099 fax



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