OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Proposed resolution for Rel-32


Here is a proposed resolution for Rel-32:

Add the first seven definitions in Requirement document
at Section 3.2 Definitions to the Specification
at 1.8 Terminology.

Thanks,

Iwasa

--
REL-32 Spec 1.5 def Editorial Active  Iwasa 
Title: Add new terms from requirments 
Description: See resolution for definition issues.  

--
Requirement document:

3.2.Definitions

The Specification : 
    Denotes the future WS-Reliability specification that is the
    output document of the Technical Committee.

Reponse RM-Reply Pattern :
    We say that a response RM-Reply pattern is in use if the
    outbound Reliable Message is sent in the underlying protocol
    request and the Acknowledgment Message (or RM-Fault
    message) is contained in the underlying protocol response
    message corresponding to the original request.

Callback RM-Reply Pattern:
    We say that a callback RM-Reply pattern is in use if the
    Acknowledgement Message (or RM-Fault message) is
    contained in an underlying protocol request of a second
    request/response exchange (or a second one-way message),
    operating in the opposite direction to the message containing
    the outbound Reliable Message.

Polling RM-Reply Pattern:
     We say that the polling RM-Reply pattern is being used if a
    second underlying protocol request is issued in the same
    direction as the one containing the outbound Reliable
    Message to act as a request for acknowledgement. The
    Acknowledgement Message (or RM-Fault message) is
    contained in the underlying protocol response to this request.
    This polling pattern is expected to be used in situations where
    it is inappropriate for the sender of reliable messages to
    receive underlying protocol requests.

Fault :
    A fault is a physical defect, imperfection, or flaw that occurs
    within somw hardware or software component.

Error:
     An error is a manifestation of a fault. Specifically, an error is a
    deviation from accuracy or correctness.

Failure :
    If an error results in the system performing one of its
    functions incorrectly then a system failure has occured.

Fail-stop model:
     A fault is said to be fail-stop if whenever it occurs, the only
    visible effect is that the affected component stops
    functioning. Thus, any component affected by a fail-stop
    failure can show no incorrect or arbitrary behavior.

Byzantine fault model:
     A failure is said to be byzantine if whenever it occurs, the
    affected component can show any arbitrary, thus possibly
    malicious, behavior.

Crash failure:
     Crash failure (or simply Crash): Any failure that is
    consequence of a fail-stop fault.

Crash Tolerance:
     Crash Tolerance is the ability of a system (either only
    specified or a software/hardware implementation) to ensure
    predetermined properties despite the occurence of one or
    more unpredictable crash failure.

Failure Recovery:
     Failure recovery is the process of regaining operational status
    or restoring the system's integrity after the occurance of a
    failure.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]