RE: [wsrm] Definitions proposal

[Scott Werden <scottw@wrq.com>]

On the crash tolerance issue - My concern arises from what I hear people are
looking for Web services to achieve, and one of those things is to be able
to reliably integrate applications. For that purpose, the bar that is being
used to measure reliability is what is delivered by traditional messaging
systems (message queues). I believe a person who buys a WSRM compliant
application or piece of middle ware will want the knowledge that it carries
a certain standard of Quality of Service. 

So, here is another proposed wording:
"We say that an implementation of a specification is crash tolerant, if it
is able to resume operation in the case of a system crash, in such a way
that it is largely transparent to other nodes, and to the application, that
a crash has occurred." 

I went back to some of Payrit's original wording, changed "hardware failure"
to "system crash" but left in the part about transparency.

Scott


> -----Original Message-----
> From: Scott Werden [mailto:scottw@wrq.com] 
> Sent: Monday, May 19, 2003 3:23 PM
> To: 'Szabolcs.Payrits@nokia.com'; wsrm@lists.oasis-open.org
> Subject: RE: [wsrm] Definitions proposal
> 
> 
> Comments in-line <scott></scott>.
> 
> Scott Werden
> 
> > 
> > Crash tolerance:
> > ----------------
> >  We say that an implementation of a specification is crash 
> > tolerant, if it is able to resume sensibly or continue 
> > operation in case of a hardware failure. 
> >
> 
> <scott>
> 
> I believe the need for this definition is from requirement 
> 4.5 [1], which
> talks about what the spec must address. But this definition 
> applies to an
> implementation of a spec, not just the spec. For instance, I 
> *can* have a
> crash tolerant implementation of TCP, but that is not 
> guaranteed at all by
> the TCP spec. I also believe that we need to be succinct in 
> what we mean by
> "resume sensibly". But that really goes to the core of the 
> requirements.
> 
> How about: "We say that a specification is crash tolerant, if every
> conformant implementation of the specification ("node") is 
> able to resume
> operation in the case of a hardware failure, in such a way that it is
> largely transparent to other nodes, and to the application, 
> that a crash has
> occurred." 
> 
> </scott>
> 
> > 
> > Fault tolerance:
> > ----------------
> >  We say that an implementation of a specification is fault 
> > tolerant, if it is able to resume sensibly or continue 
> > operation in case of an application or hardware failure.
> >
> <scott>
> We should include network failures.
> </scott> 
> > 
> > Persistant data
> > ---------------
> > A message or part of a message is considered to be persistent 
> > at a given node if it is stored in a persistent storage 
> > during its lifecycle at that node.
> > 
> > 
> > Persistant storage:
> > -------------------
> > Persistant storage is a repository for statically stored data.
> > 
> > 
> > Static
> > ------
> > A static data storage is a data storage that retains 
> > information even while power is turned off. 
> > 
> > 
> > Synchronous SOAP HTTP binding:
> > -------------------------
> >  We say that synchronous SOAP HTTP binding is in use if SOAP 
> > messages are sent in both HTTP request and respond messages. 
> > We refer to this binding as "synchronous" in order to 
> > acknowledge HTTP transactions' blocking behaviour as the more 
> > common case.
> > 
> > 
> > 
> > Asynchronous SOAP HTTP binding:
> > --------------------------
> >  We say that asynchronous SOAP HTTP binding is in use if SOAP 
> > messages are sent only in HTTP Requests, no SOAP-level data 
> > is conveyed in the HTTP response messages. We refer to this 
> > HTTP binding as "asynchronous" in order to emphasize that 
> > using this HTTP binding, all SOAP-level messages are 
> > completely independent on the transport level.
> > 
> > 
> > 
> > SOAP intermediary:
> > ------------------
> >  A SOAP intermediary is both a SOAP receiver and a SOAP 
> > sender and is targetable from within a SOAP message. It 
> > processes the SOAP header blocks targeted at it and acts to 
> > forward a SOAP message towards an ultimate SOAP receiver.
> > 
> <scott>
> There is a definition in SOAP 1.1, section 4.2.2 that we should use by
> reference.
> </scott>
> > 
> > 
> > Participating intermediary:
> > --------------------
> >  A SOAP intermediary is considered to be participating, if it 
> > is a participant node in the formal Message Exchange Pattern 
> > description, so that it can change the message flow described 
> > in the Message Exchange Pattern definition.
> > 
> <scott>
> This begs the question - what is the "formal Message Exchange Pattern
> description". If this a WSRM concept, we need a definition 
> for it. Outside
> of WSRM, there is no formalism for describing an MEP with an 
> intermediary.
> Intermediaries in WSDL are all transparent, reducing this 
> case to the one
> below.
> </scott>
> > 
> > 
> > Non-participating intermediary:
> > -------------------------------
> >  A SOAP intermediary is considerend to be non-participating, 
> > if it is transparent to the SOAP Message Exchange Pattern, so 
> > that it cannot change the message flow described in the 
> > Message Exchange Pattern definition. A non-participating 
> > intermediary can only transform the SOAP messages flown 
> > through it under normal operation.
> > 
> > 
> 
> 
> [1]
> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php
> /1423/Web_Serv
> ice_Reliability_Requirements.pdf
> 
>  
> 
> 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