JC 1/4/2006: Timing Parameters and Coupling between Specs

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

Briefly in our ebxml-jc 8 December 2005 call, we began to discuss a 
question has arisen in ebBP and CPPA regarding timing parameters. This 
also affects ebMS.  It appears that the key discussion item surrounds 
the Business Collaboration timing parameters.  I was asked to provide a 
summary so we can discuss this item. I've opted to get some feedback 
before providing to the respective lists.

   1. In the business process timing parameters exist for (TimeToPerform
      element or attribute):
          * Activities: A Business Collaboration, Business Transaction
            Activity, or Complex Business Transaction Activity (elements)
          * A Fork (element)
          * For Business Signals: Receipt Acknowledgement and Acceptance
            Acknowledgement (attribute)
                o Note (important) that time to perform can be defined
                  at design, configuration or at runtime (and acquired
                  from an external source).
   2. In configuration of delivery channels in CPP/A, these parameters
      are limited to:
          * The timeToPerform attribute on
            BusinessTransactionCharacteristics (BTC).
                o This attribute is associated with Business
                  Collaboration although CPP/A can only handle (in
                  delivery and configuration) a BTA. Perhaps a CBTA is
                  modeled as a BTA and the visible embedded BTA(s) are
                  not specified at CPP/A level.
                      + Note: The timeToPerform attribute can not be
                        overridden.
                      + When synchronous reply mode is used, the
                        timeToPerform value should be used as the
                        connection timeout (Normative SHOULD in v2.1
                        working draft).
          * Timing attributes on BTC for Receipt and Acceptance
            Acknowledgement business signals
                * Note: The CPP/A can override these values.
          * Other information relevant to these parameters in the CPP/A:
                o If one of these attributes is not specified, the
                  corresponding default value should be obtained from
                  the Process-Specification/ /document.
                o Namespace extensibility on these attributes has been
                  provided to accommodate process changes indicated.
                o MessagingCharacteristics bound how these parameters
                  are used or realized for business messages and
                  signals, and for messaging (including messages and
                  acknowledgements).
   3. In messaging the parameters are further restricted to or realized as:
          * May reference timing parameters as an operational context
            for reliability. Context data is held in reliability
            headers. [1]
          * May reference back to a CPPA as an agreement. It appears
            that this could be realized at the application level how
            this is enforced.

            The AgreementRef MAY reference an instance of a CPA as
            defined in [ebCPPA].
            An example of the CPAId element follows:

            <eb:AgreementRef>http://example.com/cpas/ourcpawithyou.xml</eb:AgreementRef>


Open questions:

   1. (ebBP and CPP/A) Should business signal timing parameters for ebBP
      be elements as well so if the TTP is dynamically acquired, the
      timing can be consistently applied?
   2. (CPP/A and ebMS): What happens if the default is not specified in
      CPP/A and the process specification indicates it is defined at
      configuration or runtime? Is the extensibility mechanism inferred
      for use? Does this allow external specification of the timing
      parameters? How does ebMS handle this?
   3. (CPP/A): How does CPP/A handle a CBTA if at all? See reasoning above.
   4. (for ebMS and CPP/A teams) How does ebMS constrain timing
      parameters or is this left to the application layer (and assuming
      some agreement is used such as CPP/A)?

In lieu of more discussion or action (if applicable), Dale and I have 
discussed some descriptive text in CPP/A to bound what can be 
effectively handled. For example (Dale pegged me to suggest text before 
Christmas):

Change from (Section 8.4.14.10):

    The timeToPerform attribute is of type duration [XMLSCHEMA-2]. It
    specifies the time period, starting from the initiation of the
    RequestingBusinessActivity, within which the initiator of the
    transaction MUST have received the response, i.e., the business
    document associated with the RespondingBusinessActivity.

     NOTE: The timeToPerform attribute associated with a
    BinaryCollaboration in BPSS is currently not modeled in this
    specification. Therefore, it cannot be overridden. In other words,
    the value specified at the BPSS level MUST be used. 

    When synchronous reply mode is in use (see Section 8.4.23.1), the
    TimeToPerform value SHOULD be used as the connection timeout. 

    NOTE: See section 10.6 for a description of changes in the CPPA 2.1
    schema made to the data type of the timeToPerform attribute to align
    with Process Specifications conforming to [ebBPSS2].

Change to (same - minor change):

    ...NOTE: The timeToPerform attribute associated with a Business
    Collaboration in BPSS is not modeled in this specification.
    Therefore, it cannot be overridden. In other words, the value
    specified at the BPSS level MUST be used. This specification is
    primarily scoped for business transactions....

Change from (Section 10.5):

    In [ebBPSS2], the @timeToPerform attribute has been replaced by a
    TimeToPerform element that allows new means of specification of
    varying performance times for a BusinessTransaction. Therefore, the
    content model for both MessagingCharacteristics and
    BusinessTransactionCharacteristics has been generalized to allow
    extension by other namespace content.

Change to (same):

    In [ebBPSS2], the @timeToPerform attribute has been replaced by a
    TimeToPerform element that allows new means of specification of
    varying performance times for a BusinessTransaction. Therefore, the
    content model for both MessagingCharacteristics and
    BusinessTransactionCharacteristics has been generalized to allow
    extension by other namespace content.

    In addition, TimeToPerform in the context of a Business
    Collaboration(s) may span several Business Transactions. Other than
    as specified in Section 8.4.14.10, these timing parameters are
    outside of the scope of this specification.

[1] In looking at WS-Reliability, timing parameters are typically in the 
context of resources for reliability. From WS-Reliability, v1.1: 
http://www.oasis-open.org/apps/org/workgroup/wsrm/document.php?document_id=12516