ebBP 12/20/2004: Patterns Summary

["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:
          o 1. Commercial Transaction: Formal exchange between parties.
            Per any decision between the parties, may be subject to a
            Notification.
          o 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.
          o 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.
          o 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.
          o 5. Information Distribution: An informal exchange between
            parties. Simple as it sounds, information is distributed and
            can be acknowledged. No response.
          o 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).
          o 7. Data exchange pattern: Allows a domain-specific or
            partner-agreed pattern. Semantics, signals, assumptions are
            partner specific.
          o 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.
          o Signals: Use of both signals under specific conditions.
          o 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).
          o 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.
          o What are default values where 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