OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa-negot message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ebxml-cppa-negot] RE: BSI distinguishing success, failure,and transition conditions


Dear Marty and Dipan,

Sorry, I am not a BSI implementer, but you both lost me.  How can a system
determine successor failure without reference to the driving business
application?

An incoming document from a responder may indicate 'success' from the
responder's perspective, but the requesting business application (the one
driving the negotiation in your case Marty) may take a dim view of the data
contained in the response document and declare failure by sending (have sent
on its behalf) a negative acknowledgment signal.

Or am I wrong way up?

Best Regards     Tony
A M Fletcher

Cohesions 1.0 (TM)
Business transaction management software for application coordination

Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
Tel: +44 (0) 20 76701787         Mobile: +44 (0) 7801 948219
tony.fletcher@choreology.com <mailto:tony.fletcher@choreology.com>    (Home:
amfletcher@iee.org <mailto:amfletcher@iee.org> )


-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: 14 August 2002 15:14
To: Anarkat, Dipan
Cc: ebtwg-bps@lists.ebtwg.org; ebxml-cppa-negot@lists.oasis-open.org
Subject: [ebxml-cppa-negot] RE: BSI distinguishing success, failure, and
transition condition s







Dipan,

Thank you for the advice.  So, what I need to do is to express the
condition expression as an XPATH predicate pointing into the message
payload to an element or attribute whose value distinguishes among success,
failure, and transition. Logically, that makes sense.

Is there a BSI implementer reading this list who can say if it is practical
for the BSI to process the payload to the point where it can look inside
the payload? Presumably this means fully parsing (with validation) the
payload into the DOM tree or some other internal object structure. Is this
in fact something that BSI implementations already do?

Regards,
Marty

****************************************************************************
*********

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************
*********



                      "Anarkat, Dipan"
                      <DAnarkat@uc-            To:       Martin W
Sachs/Watson/IBM@IBMUS, ebxml-cppa-negot@lists.oasis-open.org, ebtwg-
                      council.org>              bps@lists.ebtwg.org
                                               cc:
                      08/14/2002 09:45         Subject:  RE: BSI
distinguishing success, failure, and transition condition       s
                      AM





Marty,
   The value of the condition expression MAY be a previously exchanged
document. In that case the expressionLanguage should be set to
'DocumentEnvelopeLanguage' in the BPSS instance and the value of
'expression'  should then be the name of the 'DocumentEnvelope' exchanged.


   Depending on the Business Collaboration you may want to specify more
complicated conditions for 'Success' , 'Failure' or 'Transition'. In that
case you may want to specify your condition expression using 'XPATH' as you
'expressionLanguage' with an XPATH predicate in the 'expression'attribute.


   Typically you would have guard conditions expressed in OCL, on the input
and output transitions from the BTA, in your Business Collaboration models
(as per UMM). When you map the Business Collaboration models (in UMM) to a
corresponding BPSS process specification you would map the OCL expressions
to XPATH predicates in the 'ConditionExpression' element.


   Any incoming message in a conversation would then be validated against
the condition expression in the BPSS process specification, if specified.
The BSI would then advance the conversation to the appropriate
collaboration state based on the evaluation of the condition expression on
the message recieved. I think this is how the BSI would behave.


Regards,


+ dipan


Dipan Anarkat
Systems Analyst, Standards Development
Uniform Code Council, Inc.
Tel: (609)-620-4509
http://www.uc-council.org/






-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, August 14, 2002 9:20 AM
To: ebxml-cppa-negot@lists.oasis-open.org; ebtwg-bps@lists.ebtwg.org
Subject: BSI distinguishing success, failure, and transition conditions






How does a BSI know if the exit condition from a BusinessTransaction
Activity is Success, Failure, or Transition?  The value of the condition
expression in these elements is the value of the name attribute of some
BusinessDocument element.  How does the BSI know which condition expression

the incoming message matches?  I can' find anything in the ebXML message
header that contains this attribute value.


Unless the BSI knows whether the incoming message satisfies the Success,
Failure, or Transition condition, it can't track the choreography.


Regards,
Marty


****************************************************************************
*********



Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************
*********






----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebtwg.org/ob/adm.pl>







----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC