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

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

 I'd like to remind everyone that we are dealing with WS-ReliableMessaging
 and NOT WS-Reliability. Solving all the Crash Tolerant/Fault Tolerant
 issues is just out-of-scope and will delay our deliverables. ebXML tried
 to solve all the problems (as my friend said once ebXML tried to solve
 the world hunger problem) and became complex enough to make it
 unusable. We shouldn't go the same track.

 We should define the baseline in this version. If needed, we can have another
 version.

 We should tie reliability to existence of persistence storage. However, I do
 acknowledge Scott's concern. For that we need to define ways/levels of
 message persistence, such as:
    i) Always persist the message
   ii) Persist until TTL expires
   iii) Persist until Ack is sent or msg is consumed etc...

 I believe this approach is better & simpler than "levels of persistence".

 Vendors can always extend or have optimization features which they
 can document in their manuals. Spec. shouldn't ALL the options.

 Simpler is better.

Scott Werden wrote:

> 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.
>
> 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. 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/leave_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.php