[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebCPP/A 10/28/2005: Suggestions on Timing Parameters
As requested today, I've done some research and provided a summary and
proposed text change for v2.1 CPPA. I also went and searched the
archives (see under "Additional points to consider"). Here is a rough
draft to hash through. Thanks.
Summary:
1. Originally, a common definition was proposed that allowed a
relationship between the business process and the CPP/A,
recognizing that often the CPA might use a subset of the process
definition (i.e. several CPA may be associated with the actual
process definition). See [1] and 1. below.
2. Therefore, the boundaries of the CPA tend to be relative to what
process definition it helps implement. It also provides guidance
to the technical aspects of secure, reliable messaging. See [1]
and [2].
3. Currently, the ebBP process definition specifies TimeToPerform
element on Business Collaboration and Business Transaction
Activity levels as well as Forks. [3] This is similar for the
timeToPerform attribute used in ebXML BPSS v1.x for Binary
Collaboration, BTA and Fork. While the CPA includes the boundary
indicative of a BTA (Requesting and Responding Business Activity
with the receipt of a document where applicable). It is this final
point that may require some descriptive clarification in Section
8.4.14.10 of v2.1 CPP/A. In order to handle either a subset or the
full context of timing parameters in a process definition, this
CPP/A v2.1 would need to expand the timeToPerform attribute as it
is affected by multiple attributes or elements in associated
process definitions (and versions).
Suggested change for description only
Also see "Open questions".
Change from:
Section 8.4.14.10 timeToPerform attribute
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].
Section 10.6.5 TimeToPerform
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:
Section 8.4.14.10 timeToPerform attribute
In the CPP/A, 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. This usage may be a targeted subset of
the timing parameters and boundaries that may occur in a business
process definition, relative to its use in the CPP/A and any
influence on the underlying messaging services.
NOTE: For ebXML BPSS v1.x versions, the timeToPerform attribute
in CPP/A MAY be associated with the Requesting and Responding
Business Activity related to a Business Transaction Activity in
the process definition, such as in ebXML BPSS. The
BinaryCollaboration is currently not explicitly modeled in this
specification. Therefore, if the timeToPerform attribute value
of the process definition for a BinaryCollaboration is used in
the CPP/A for its corresponding attribute, that value MUST be
used and MUST NOT be overriden.
In the context of Requesting and Responding activities when
synchronous reply mode is in use (see Section 8.4.23.1), the
TimeToPerform attribute 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].
10.6.5 TimeToPerform
In [ebBPSS2], the @timeToPerform attribute has been replaced by a
TimeToPerform element that allows new means of specification of
varying performance times for a BusinessTransactionActivity,
BusinessCollaboration or Fork. Therefore, the content model for both
MessagingCharacteristics and BusinessTransactionCharacteristics has
been generalized to allow extension by other namespace content.
NOTE: For ebXML BPSS v2.x versions, the timeToPerform attribute
in CPP/A MAY be associated with the Requesting and Responding
Business Activity related to a Business Transaction Activity in
the process definition, such as in ebBPSS2. The xxxCollaboration
(Multiparty, Business or Binary) is currently not explicitly
modeled in this specification. Therefore, if duration value is
available in the TimeToPerform elemen in the associated process
definition for a xxxCollaboration and is can be used in the
CPP/A for its corresponding attribute, that value SHOULD be used
and SHOULD NOT be overriden. If future versions, the aspects of
dynamic timing parameters may be considered.
Open questions:
1. Whether or not timing should have some relationship from
process=>profile=>messaging at least in the context of request and
response pairs. At this time I am not requesting this be addressed
just recognizing that this question may be considered. This seems
to be inferred from the comment regarding synchronous reply mode
usage (paragraph three, 8.4.14.10).
2. For ebBP v2.x, determine whether the further specification in a
business process should be reflected in CPA (i.e. the ebBP uses
TimeToPerform element with characteristics now that can be
acquired at design, configuration or runtime). At a minimum, we
need to bound what CPA can handle relative to the business process
view of timing regardless if a subset and at a minimum by
description. I am uncertain how the type extensibility changes
could handle this. Dale may be able to provide some explanation.
Determine if CPA cares about Fork time to perform.
3. If the reference for synchronous reply mode is still valid,
suggest a corresponding statement in Section 8.4.23.1. No
reference currently exists.
Additional points to consider:
1. It also appears that the constraints on Service and Action
relative to the business process, what seeded in the fact that a
given CPA may only implement a subset of the business process
definition (i.e. a tailored business process definition). [1] In
addition, the relative context of Time To Perform was also
discussed although it doesn't appear that it was clarified. [2]
2. Shows even how constraints in CPA influence ebMS and question of
override occurred there too more than 4 years ago, and whether or
not override should be constrained:
http://lists.oasis-open.org/archives/ebxml-cppa/200111/msg00047.html,
http://lists.oasis-open.org/archives/ebxml-cppa/200111/msg00048.html
(Why wasn't this suggestion acted upon then?)
[1] See: November 2001,
http://lists.oasis-open.org/archives/ebxml-cppa/200111/msg00081.html.
[2] See: November 2001,
http://lists.oasis-open.org/archives/ebxml-cppa/200111/msg00096.html,
http://lists.oasis-open.org/archives/ebxml-cppa/200111/msg00097.html,
http://lists.oasis-open.org/archives/ebxml-cppa/200111/msg00100.html
[3] Business collaboration could be a binary or multi-party
collaboration (2, or 2 or more roles respectively).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]