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

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

 Magdolna,

 My comment was neither specific to your msg. nor to Scott's mail. I was replying in the
 context of yesterday's discussion at the F2F.

 The discussion yesterday boiled down to "Levels of Persistence".

 Here is the snippet from Tom's Meeting Minutes:
        ---------------
          Define two Classes of persistence (requires a change to definition of persistence):

            -         persistent until permanent storage mechanism failure.

            -         Persistent until system power loss
       ----------

 I was very concerned about this direction and hence the mail.


 -Sunil

magdolna.gerendai@nokia.com wrote:

> Hi Sunil,
>
> See my comments below.
>
> br,
> Magdolna
>
> -----Original Message-----
> From: ext Sunil Kunisetty [mailto:sunil.kunisetty@oracle.com]
> Sent: May 30,2003 17:07
> To: Scott Werden
> Cc: wsrm@lists.oasis-open.org
> Subject: Re: [wsrm] Persistence requirement in the WS-RM specification
>
>  I'd like to remind everyone that we are dealing with WS-ReliableMessaging
>  and NOT WS-Reliability.
>
> [MG] I don't use this wording, because I would like to avoid any mixing with the Microsoft/IBM/.. specification. Otherwise I always speak about Reliable Messaging.
>
> 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.
>
> [MG]I don't think, we want to solve all the problems. I've written, that we describe in the specification, which error cases can not be handled on different level of reliability. It's far from the solution of everything.
>
>  We should define the baseline in this version. If needed, we can have another
>  version.
>
>  We should tie reliability to existence of persistence storage.
>
> [MG] Exactly this is, what I argue with. I think, the reliability as a notion is not tied to persistence, it's not black and white, i.e. if no persistence, no reliability at all. I think, this is a crucial point of this specification.
>
> 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".
>
> [MG] I proposed levels of reliability, not 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
>
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php
>
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php