[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: JC 1/4/2006: Timing Parameters and Coupling between Specs
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]