[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]