ebBP 6/14/2005: Comment re: Response wd-2-0-1-01 (for wd-02 tech spec)

[Monica J Martin <Monica.Martin@Sun.COM>]

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.