[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 4/7/2005: Comment re: General Exception (wd11/schema-4/1)
In Tuesday's call we resolved how to handle General Exception in more detail. Discussion summary: * It is important to understand General Exception but not purely from a state alignment and business perspective. However, it is a capability that is outside of the patterns. Some felt it didn't belong there (St. Amand and Dubray). * We however need to enable those who will build software to be aware of this exception type. * Resolution was to implementation note in the schema annotations and technical specification for implementers. Therefore, here are the suggested changes relative to the spec and schema. If you have any suggestions or changes, please advise. As a secondary note, I've queried Hima Mukkamala, who was unable to attend Tuesday's call because of a conflict, about our decision. Thank you. ================================================================== Section 4.7.1 Interaction Predictability Change from: · All business transactions succeed or fail. Success or failure depends on:.....(bulleted list) * ......(last bullet) The occurrence of a notification of failure business message or general exception signal (Described later in Section 4.8.2.3) Change to: All business transactions succeed or fail. Success or failure depends on:.....(bulleted list) * ......(last bullet) The occurrence of a notification of failure business message Although not part of or described in the BT patterns, general exception may occur that impacts a party's capability. The NOF and general exception are described later in Section 4.8.2.3. Chapter 4.8.2.3 [add after this sentence] A general exception is a limited case and distinct type of technical failure, i.e. AnyProtocol Failure). The involved parties determine if such exceptions are used in order to recognize and handle the possibility of a catastrophic failure. [add] Implementers note The General Exception is outside of the currently defined concrete BT patterns. Software implementers MAY choose to enable software that is aware of this exception type. Schema: Change from: - <#> <xsd:complexType name="*GeneralExceptionType*"> - <#> <xsd:annotation> <xsd:documentation>The type of a Business Action of general exception (exceptions other than Receipt and Acceptance Acknowledgement). Note, this type was added in v2.0. During an interaction, the general exception can be used when a party must trigger an exception, for example, for a general communication failure. A signal is used for state alignment.</xsd:documentation> </xsd:annotation> Change to: - <#> <xsd:complexType name="*GeneralExceptionType*"> - <#> <xsd:annotation> <xsd:documentation>The type of a Business Action of general exception (exceptions other than Receipt and Acceptance Acknowledgement). During an interaction, the general exception can be used when a party must trigger an exception, for example, for a general communication of catastrophic failure. A signal is typically used for state alignment. The General Exception is outside of the currently defined concrete BT patterns. Software implementers may choose to enable software that is aware of this exception type. Note, this type was added in v2.0.</xsd:documentation> </xsd:annotation> ==================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]