[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 11/27/2005: isPositiveResponse Attribute (Green)
In Tuesday's call last week just before the Thanksgiving holiday, we
discussed condition expressions, transitions and composition given
questions raised by Stephen Green. In that discussion [1], Stephen asked
about isPositiveResponse attribute and the transitions specifically. I
would ask that everyone review, at a minimum, sections 3.5.1, 3.6.3 and
3.4.9.3.3 that discuss this in detail. During the release of v2.0 and
subsequently the v2.0.1, the team engaged in detailed discussions about
condition expressions, guards and transitions and states. The
isPositiveResponse attribute and its intent was also questioned by
several members in ebBP and/or ebXML IIC. See this relevant excerpt from
those historical discussions. [2]
(Yunker [3]) However most of the order document exchanges I am
involved in have the "orderRequest" followed by the "orderResponse",
and the order response can have success, failure, and partial
success as a result. The orderRequest and orderResponse constitute
the transaction that resultsin the commitment.
We cannot be as simplistic about the "isPositiveResponse" being the
key driver of choreography, because that requires simplifying
business requests to an "all or nothing" result. I am VERY nervous
about assigning business success / failure to the envelope. While
this greatly simplifies implementation, it is simply moving the
complexity around, instead of meeting it head on and working through
the proper mechanisms for communicating the context driving business
execution.
We should provide a mechanism for a transition to reference a
business contextual value other than the envelope. I have long
argued for an
expression on transition guards, [corrected from startsWhen]
beginsWhen, and endsWhen. That expression should have "syntax" and
"expression" atttributes, so the appropriate syntax for the
expression may be used...
[Martin - Note: This discussion eventually resulted in allowing external mechanisms to be used via semantic variable, which is what John references here.]
The isPositiveResponse is specifically related to Business (not
Protocol) Success or Failure. It is an indicator. There are multiple
facilities to enable transitions and state changes associated with the
choreography within a Business Collaboration - capability to use
semantic variables, the conditions expressions (including, if desired in
implementation, computable beginsWhen, endsWhen, etc), guards on
transitions, etc.
I believe the examples we are working on will be valuable to
implementers in using ebBP. We have had similar questions from Green,
Novelli and the health care experts (Dr. Dogac and company) on these
points so I believe the examples linked to the descriptions in the
technical specification will help provide that connection for the user
community.
Finally, I propose two simple updates to the Status section at the
beginning of the technical specification and in Section 3.4.9.3.3:
Status
Change from: Exemplary process definition and signal instances and
illustrations are also provided in publicly available package on the
OASIS site. This final package is non-normative and outside the
review and TC process cycle of this technical specification.
Change to: Exemplary process definition and signal instances and
illustrations are also provided in publicly available package on the
OASIS site. This final package is non-normative and outside the
review and TC process cycle of this technical specification. This
technical specification provides non-normative examples (XML
instance snippets) while more complex ebBP definitions may be found
in the examples package.
Section 3.4.9.3.3:
Change from: The isPositiveResponse attribute of a DocumentEnvelope
is not part of the Business Transaction protocol and therefore does
not impact the Protocol Success or Failure of a transaction. If the
DocumentEnvelope received as a response is specified with the
isPositiveResponse=false (at design time) the Business Transaction
will end in a Business Failure state. The choreography of the Binary
(Business) Collaboration MAY use this information to execute
corresponding transitions or stop the collaboration altogether. Note
that this attribute is optional and some Document Envelope MAY
neither be positive or negative (consider for instance the case of a
partial acceptance on a purchase order, where only a few line items
are refused, or a back order response). In this case, the BTA is
considered successful, again after it has reached a Protocol Success
state.
Change to: The isPositiveResponse attribute of a DocumentEnvelope is
not part of the Business Transaction protocol and therefore does not
impact the Protocol Success or Failure of a transaction (although it
is relevant to Business Success and Failure). If the
DocumentEnvelope received as a response is specified with the
isPositiveResponse=false (at design time) the Business Transaction
will end in a Business Failure state. The choreography of the Binary
(Business) Collaboration MAY use this information to execute
corresponding transitions or stop the collaboration altogether. Note
that this attribute is optional and some Document Envelope MAY
neither be positive or negative (consider for instance the case of a
partial acceptance on a purchase order, where only a few line items
are refused, or a back order response). In this case, the BTA is
considered successful, again after it has reached a Protocol Success
state. Conditions guards on transtions are discussed in detail in
Section 3.6.3.
It is important to note that the isPositiveResponse attribute such
as other facilities in ebBP - condition guards on transitions,
semantic variables, conditions expressions - are enabling mechanisms
for the ebBP process definitions whereby the choreography, control
flow, state transitions, logical business documents, and the
expectations of the parties are clearly understood. It is their
collective use that provides the capability to enable Business
Collaborations.
Please comment on the list before the meeting or bring your thoughts to
the TC call Tuesday, 29 November 2005 if you have relevant suggestions.
Thanks.
==========
Relevant references:
from Section 3.5.1...."All Business Transactions succeed or fail.
Success or Failure depends on:
...· The computation of Business Failure or Success by detecting if the
response document was specified – at design time – with
isPositiveResponse=false...."
from Section 3.6.2.4....
*/isPositiveResponse/*/ /
A parameter that MAY take the value of TRUE or FALSE. This is a Boolean
attribute. If TRUE this DocumentEnvelope is intended as a positive
Response to the Request. If isPositiveResponse = FALSE, the BTA ends in
Business Failure mode. The value for this parameter supplied for a
DocumentEnvelope is an assertion by the sender of the DocumentEnvelope
regarding its intent for the transaction to which it relates, but does
not bind the recipient, or override the computation of transactional
Success or Failure.
from Section 3.6.3...(Note: Here is where the Business Success and
Failure and associated path diagrams are provided on the condition
guards on transitions):
· BusinessSuccess (isPositiveResponse=true or no isPositiveResponse
attribute)
BusinessFailure(isPositiveResponse=false)
from Section 3.4.9.3.3..."In order for a BTA instance to reach a
“Success” state at run-time, the following things SHOULD be true:
· no timeout would have occurred (signals or response)
· no signal can have a negative content
· the response document sent to the requester MUST be marked as
isPositiveResponse = ‘true’ in the ebBP instance that specifies the
Business Collaboration in order to support Business Success
Conversely, if all signals are positive and sent and received on time,
the transaction will be successful from a protocol perspective.
The isPositiveResponse attribute of a DocumentEnvelope is not part of
the Business Transaction protocol and therefore does not impact the
Protocol Success or Failure of a transaction. If the DocumentEnvelope
received as a response is specified with the isPositiveResponse=false
(at design time) the Business Transaction will end in a Business Failure
state. The choreography of the Binary (Business) Collaboration MAY use
this information to execute corresponding transitions or stop the
collaboration altogether. Note that this attribute is optional and some
Document Envelope MAY neither be positive or negative (consider for
instance the case of a partial acceptance on a purchase order, where
only a few line items are refused, or a back order response). In this
case, the BTA is considered successful, again after it has reached a
Protocol Success state...."
=============
[1] See meeting minutes, 22 November 2005 at:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/15582/ebxmlbp-2.0.1-Minutes-112205.txt.
[2] Much of the history can be found by typing in "isPositiveResponse"
in the search email facility in Kavi under Email.
[3]
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200406/msg00064.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]