RE: [wsrm] Definitions proposal

[Scott Werden <scottw@wrq.com>]

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