ebBP 11/27/2005: isPositiveResponse Attribute (Green)

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

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