[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 6/14/2005: Comment re: Response wd-2-0-1-01 (for wd-02 tech spec)
Everyone, Last week, I received a request from John Yunker for an editorial change to Section 3.4.9.1 to emphasize the importance of the existing Business Transaction model. See the change which complements and supports our discussion and decision. If you have any questions, please let me know. This is integrated into the wd-02 that will be proposed for vote this week. Thank you. ======== Section 3.4.9.1 Change from: The requesting role performing the Requesting Business Activity and the responding role performing the Responding Business Activity are abstract (placeholders). These roles become explicit when the transaction is used within a BTA as part of a Business Collaboration. There is no need to make these roles concrete such as buyer or seller. In particular some Business Transactions, for example “Cancel Purchase Order” MAY be used either way within the same Business Collaboration as two different Business Transaction Activities. Role changes and role bindings are described in more detail later in this section. There is always a Requesting Document Flow. A Business Transaction definition specifies whether a response document is required. A Business Transaction with a request or response could be used for notifications. A common example of a Response that is a notification is an Advance Ship Notice or Despatch (Dispatch) Advice. Business Transaction involving a response (to a request) may be associated with the formation of contracts and agreements. Business Action, an abstract element, is the holder of attributes that are common to both Requesting Business Activity and Responding Business Activity. This element cannot appear in ebBP instances. Change to: Section 3.4.9.1 The requesting role performing the Requesting Business Activity and the responding role performing the Responding Business Activity are abstract (placeholders). These roles become explicit when the transaction is used within a BTA as part of a Business Collaboration. There is no need to make these roles concrete such as buyer or seller. In particular some Business Transactions, for example “Cancel Purchase Order” MAY be used either way within the same Business Collaboration as two different Business Transaction Activities. Role changes and role bindings are described in more detail later in this section. There is always a Requesting Document Flow. A Business Transaction definition specifies whether a response document is required. The Requesting Document Flow relates to the Business Transaction being implemented and may have a relationship with other Business Transactions (where applicable). For example, a Requesting Document Flow may be implicit or manual, or associated with a previous Business Transaction. A common example of a Requesting Document Flow that is a Notification Business Transaction (related to the Notification Pattern) is an Advance Ship Notice or Despatch (Dispatch) Advice. These are both requests. In this case, a previous Commercial Transaction may have been completed between two parties and one party desires to notify of shipment. That shipment may be logically considered an additional response to the original Business Transaction. However, the original Business Transaction and this Notification are separate. This and related cases are outlined in Appendix F. A Business Transaction involving a response (to a request) may be associated with the formation of contracts and agreements. Business Action, an abstract element, is the holder of attributes that are common to both Requesting Business Activity and Responding Business Activity. This element cannot appear in ebBP instances. Appendix F Change from: As indicated in Section 3.4.9.1, the patterns are applied to Business Transactions. In a Business Transaction, a Request may be manual, implicit or not apply, whereby the intent of the involved parties may be important. Take the case where a user community is incrementally automating its business collaborations such as a telephone or fax request or a Status Order sent for quality certification. * If the Request is manual, a Commercial Transaction pattern could be used where the trigger is known when the Request occurs. * If the Request may or may not be used, the Data Exchange pattern could be used as the parties may bound the scope of how the pattern is used. When flexibility rather than predictability is desired, the Data Exchange specialization of a Business Transaction may be used. * If the Request is implicit (i.e. the Response is based on previous Commercial Transaction), the Notification pattern could be used. In this case, the Requesting Business Activity is a Response, i.e. the result of an action within the notifying entity. The actual Request may be implicit and the Response indicative of the intent of the parties. Regardless of the options chosen, the visible state transitions available are modeled, in order to manage the transactions that occur. For example, a fork may be used between the two types of transactions (manual and automated), in order to make the visible state available for monitoring. Change to: As indicated in Section 3.4.9.1, the patterns are applied to Business Transactions. In a Business Transaction, a Request may be manual, implicit or not apply, whereby the intent of the involved parties may be important. Take the case where a user community is incrementally automating its business collaborations such as a telephone or fax request or wishes to provide a Status Order sent for quality certification (for a previous Business Transaction). * If the Request is manual, a user community may choose to use a Commercial Transaction pattern where the trigger is known when the Request occurs. * If the Request may or may not be used, a user community may choose to use the Data Exchange pattern as the parties may bound the scope of how the pattern is used. The Data Exchange element allows the flexibility to specialize how a Business Transaction may be used. * If the Request is implicit, a user community may choose to use the Notification pattern. In this case, the Requesting Business Activity in the Notification Business Transaction may logically be a Response, i.e. the result of an action within the notifying entity. As described previously in Section 3.4.9.1, the Requesting Document Flow in the Notification Business Transaction is indicative of the intent of the parties. Regardless of the options chosen, the visible state transitions available are modeled, in order to manage the transactions that occur. For example, a fork may be used between the two types of transactions (manual and automated), in order to make the visible state available for monitoring. Consider a user community that requires the flexibility to accommodate varied cases, the process could be modeled as a fork-join combination where Commercial Transaction (Requester to Responder) or Notification (Responder to Requester) are used. This allows a monitoring (business protocol) engine to manage the Business Collaboration using established patterns for Business Transactions.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]