RE: [wsrm] Persistence requirement in the WS-RM specification

[Scott Werden <scottw@wrq.com>]

Comments in-line ... <scott></scott>

Scott


> -----Original Message-----
> From: magdolna.gerendai@nokia.com 
> [mailto:magdolna.gerendai@nokia.com] 
> Sent: Friday, May 30, 2003 10:03 AM
> To: scottw@wrq.com; wsrm@lists.oasis-open.org
> Subject: RE: [wsrm] Persistence requirement in the WS-RM specification
> 
> 
> Hi Scott,
> 
> See my comments below.
> 
> br,
> Magdolna
> 
> -----Original Message-----
> From: ext Scott Werden [mailto:scottw@wrq.com]
> Sent: May 30,2003 16:47
> To: wsrm@lists.oasis-open.org
> Subject: RE: [wsrm] Persistence requirement in the WS-RM specification
> 
> 
> Yesterday we closely tied reliability to persistence. After 
> thinking a bit
> about this, I am not sure this is a good way to define 
> reliability, or a
> good requirement for conformance to WSRM. For instance, are 
> we requiring all
> implementations to persist all messages? Or must the 
> implementation just
> have persistance available and it is up to the vendor to 
> decide when to use
> it? Or must the implementation persist only if it holds onto 
> a message for
> more that X length of time? Same with state information for 
> ordering. I can
> envision a system that only orders a sequence of messages 
> sent in a short
> burst - are we saying that system must persist all messages 
> in the burst
> even though the burst interval may be far less than the time 
> to persist each
> message (or its state)? For these reasons, it seems like 
> persistance is a
> slippery requirement to put on an implementation of WSRM.
> [MG] Very valid considerations. 
> 
> I believe the requirements we put on WSRM implementations 
> must come through
> the semantics of the protocol, such as the ACK. In this case, each RM
> message sent has a requested service level (such as the ones 
> described by
> Magdolna) to the message receiver. If the receiver can meet 
> it, it ACKs, if
> it cannot, it replies with a fault. We let the implementor 
> decide how to
> achieve the service level, but we make sure that each service 
> level is well
> defined within the WSRM spec. 
> 
> [MG] Do you mean an implied service level ? Currently the 
> information about the party's abilities 
> (features+capabilities) are based on out of bound mechanism. 
> In this case they know about each other, what level they can provide.
> If we want dynamically send (update) these configuration 
> informations, we can introduce a configuration header 
> optionally to inform the parties about their configuration parameters.
> Otherwise I couldn't agree more.
> 
<scott>
I was thinking that there would be a parameter passed as part of the WSRM
message that indicated the desired service level, e.g.,

<soap:header>
  <wsrm:ReliableMessage>
     <wsrm:MessageType ServiceLevel="MUST_PERSIST">
        .......
     </wsrm:MessageType>
  </wsrm:ReliableMessage>
</soap:header>

The spec would define 2 or 3 base levels of service, such as MUST_PERSIST,
DO_NOT_CARE, and MUST_DELIVER. The semantics of the latter would be (for
example): "You MUST deliver the message to the application, whether that QoS
assurance is met through using persistance (to non-volitile storage) is up
to the WSRM implementation".

An ACK indicates the service level was met by the receiver. A Fault would be
available to indicate the WSRM node cannot meet the requested service level.

Putting pre-defined service levels in the spec will allow WSRM apps to be
written once without having to write special code for each WSRM vendor that
comes along that someone wants to send messages to.

</scott>

> Service levels might also be extensible to
> allow vendors to define their own, in which case the 
> semantics would be a
> private agreement between the users.
> 
> Is the above testable? Probably not, but a customer will 
> quickly know if a
> vendor is not meeting its service levels and will have the 
> spec to beat them
> over the head with.
> 
> Comments?
> 
> Scott
> 
> 
> > -----Original Message-----
> > From: magdolna.gerendai@nokia.com 
> > [mailto:magdolna.gerendai@nokia.com] 
> > Sent: Friday, May 30, 2003 4:16 AM
> > To: wsrm@lists.oasis-open.org
> > Subject: [wsrm] Persistence requirement in the WS-RM specification
> > 
> > 
> > Hi all,
> > 
> > I know, that you had a long discussion yesterday about the 
> > persistence requirement in the WS-RM specification, and I 
> > would like to add my view to this picture. I'll participate 
> > on the today's meeting via telcon too.
> > 
> > The reliability itself from engeneering point of view means 
> > at least two things:
> > - a protocol between parties, which determines the 
> > informations exchanged on the wire and the description of the 
> > necessary or possible steps they have to or may do to follow 
> > the state transitions during the communication. 
> > - capabilities of the parties, which can be used to maintain 
> > the state transitions of the communication.
> > 
> > There are different, valid use cases, which obviously show, 
> > that they require different, scalable reliability levels 
> > according to the  application environment and capabilities of 
> > the participants. We can not say, that there is THE 
> > reliability, which mandates a capability requirement, the 
> > persistence, as no one can say, that there is THE security, 
> > which has to provide all levels of security, including 
> > authentication, integrity, confidentality, etc.. We can not 
> > exclude from the  deployment of the WS Realibility the 
> > devices, which are not capable to have persistent storage and 
> > even may not require that level of reliability either. Let 
> > the application environment decide, how strong reliability 
> > they want or able to use.
> >   
> > There are some reliability levels identified (at least):
> > - communication reliability
> > - limited crash tolerance reliability
> > - crash tolerance reliability
> > - crash tolerance reliability with state synchronization
> > - ...
> > and I think, no one can say, that any of them has no value.
> > 
> > Just very shortly an explanation, without the demand of the 
> > perfect definition:
> > - Communication reliability: this is a low level reliability, 
> > because it assumes, that the parties are not crashed or 
> > swithed off during this communication, e.g. no need to store 
> > persistently any message context.
> > - Limited crash tolerance: this is a next level reliability, 
> > which may ensure, that the communication parties are able to 
> > give some limited error (status) indication about the 
> > previous state of the communication.
> > - Full crash tolerance: this is the higher level reliability, 
> > which the parties can provide for each other saving the full 
> > message context persistently...
> > 
> > The introduction of the reliability levels in the 
> > specification means, that we insert some 
> > clarifications/descriptions, which state transitions can not 
> > be followed, what are the error cases, which they can not 
> > handle, and specify some new Fault codes for the indication 
> > of the inconsistencies on the wire.
> > 
> > And last, but not least: there are two, published reliability 
> > papers (private specifications) re the WS reliability area, 
> > the  WS-Acknowledgement and the WS Reliable Messaging 
> > Protocol. The first one requires the persistence only for the 
> > messageID (though the persistence is defined in a large 
> > scale) and the second one doesn't mention persistence or 
> > store of any data at all.
> > 
> > Again, WS Reliability specification, standardized by this TC, 
> > should be intended to a large scale of possible deployment. I 
> > hope, it will happen.
> > 
> > Thanks.
> > 
> > br,
> > Magdolna
> > 
> > 
> > 
> > 
> > You may leave a Technical Committee at any time by visiting 
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leav
> e_workgroup.ph
> p
> 
> You may leave a Technical Committee at any time by visiting 
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.ph
p