ebbp 12/20/2004: Patterns Summary Update

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

As promised, here is a summary in preparation for tomorrow's call and 
discussion:

Six concrete, business transaction patterns + extensibility pattern + 1 
backward compatibility pattern:

    * 1. Commercial Transaction: Formal exchange between parties. Per
      any decision between the parties, may be subject to a Notification.
    * 2. Request-Response: Request for information a partner already
      has. Response requires aggregation or a complex set of
      interrelated results. Example: Product and price availability.
    * 3. Request-Confirm: Partner requests information on a previous
      partner relationship such as is the partner authorized to sell
      product x to partner y. Use of non-repudiation is allowed and
      doesn't change the semantics.
    * 4. Query-Response: Request for information a partner already has. 
      Response does NOT require complex processing (i.e. query doesn't
      require interdependency of results) such as do you sell product x?
      Use of non-repudiation is allowed and doesn't change the semantics.
    * 5. Information Distribution: An informal exchange between parties.
      Simple as it sounds, information is distributed and can be
      acknowledged. No response.
    * 6. Notification: A formal exchange between parties that revokes a
      previous request (obligation) that is acknowledged. No response.
      Relates to Commercial Transaction (both formal exchanges).
    * 7. Data exchange pattern: Allows a domain-specific or
      partner-agreed pattern. Semantics, signals, assumptions are
      partner specific.
    * 8. Backward compatibility pattern: Retained Business Transaction
      as a pattern for backward compatibility / transformations in v2.0
      only. Note, Business Transaction was colloquially known and is
      actually the Commercial Transaction.

In guiding documents, the concrete operational details for the 6 
patterns, to date, have been underspecified (for example, 
non-repudiation and optional use of signals). Conflicting details exist 
about these areas, constraints, etc. Our main challenge/opportunity is 
to provide some concrete operational details, and seek user community 
feedback to assess our recommendations. At some point, I would suggest 
we feed this information back to the original reference model owners.

    * Signals: Use of both signals under specific conditions.
    * NOF: Constrain on formal exchange. If you note this, the only
      potential use of NOF MAY be partner-specific. It MAY be used for
      Commercial Transaction and some specialization via Data Exchange
      (no other patterns apply).
    * Non-repudiation: Is this a function of formal exchange only?
      Likely not. It appears to be an important assumption for certainty
      between the parties regardless of the type of exchange. This or
      any similar assumption requires TC discussion and agreement.
    * Default values: Where are they applicable? See matrix for
      HasLegalIntent particularly.

I would encourage everyone's comments. If you are unable to attend 
tomorrow's meeting, please send comments to Dale and I, or to the list. 
Thanks and happy holidays to everyone. Regards.

Note: In matrix, key items for discussion are block highlighted in 
fuschia. In addition, any text changes since last version is in bold 
blue type. Note comments in many cells.

bt-patterns-umm-based-mm1-121604.xls