[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
Tony, Response below. 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 ************************************************************************************* "Tony Fletcher" <tony_fletcher@btope To: Martin W Sachs/Watson/IBM@IBMUS, "Anarkat, Dipan" <DAnarkat@uc-council.org> nworld.com> cc: <ebtwg-bps@lists.ebtwg.org>, <ebxml-cppa-negot@lists.oasis-open.org> Subject: RE: [ebxml-cppa-negot] RE: BSI distinguishing success, failure, and transition 08/14/2002 04:57 PM 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? MWS: The system can only decide what the sender of the document tells it in the message via the information referenced by the specificationID attribute of the BPSS BusinessDocument element. This drives the exits from the Success, Fail, and Transition elements which determine the next business transaction (or whatever) as defined in the BPSS instance documet. 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. MWS: That's correct. The application design should tell the message sender when to specify Success, Fail, or Transition but it's up to the message recipient do do the full analysis. The analysis is done in the code reached via the Success, Fail, or Transition element. 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