- From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
- Date: Mon, 25 Oct 2004 14:40:44 -0700
- To: "Gary Brown" <gary@enigmatec.net>, <public-ws-chor@w3.org>
See comments below. I am expecting that we spend time tomorrow in the con-call to discuss these issues in greater detail. -- Nick ----- Original Message ----- From: "Gary Brown" <gary@enigmatec.net> To: <public-ws-chor@w3.org> Sent: Wednesday, October 20, 2004 2:08 AM Subject: Follow on discussion: Fault handling endpoint generation to BPEL > > Hi, > > [Observations based on BPEL1.1 fault handling - may have changed since?] > > Although BPEL does define fault handlers at the process level, that could be > used to interrupt a process if a fault was to occur, it does also allow > fault handlers to be scoped to the 'invoke' activity. This effectively means > that alternative paths through the process can be taken, depending on > whether a normal or a fault message occurs, without interrupting the > process. > > I think it is important that a choreography should be able to receive a > fault message without necessarily causing an exception, so that more > comprehensive choreographies can be defined - otherwise each interaction > that may result in a fault message would have to be defined in its own > sub-choreography. However, I don't know that embedding exception handlers > within the 'interaction'/'exchange' statement would necessarily be the best > thing. > > If we were to model the alternative responses as separate interactions, with > their own exchange and record elements, this would simplify the notation - > but then the problem is ensuring that the association between the > interactions is valid - which I think could be handled by a semi-intelligent > parser. For example, we need to ensure that all of the interactions > statements (representing the receipt of the normal response or one of > possibly many fault responses) are placed in a single choice statement, so > they are mutually exclusive. > > When doing endpoint generation to BPEL, it would then be relative > straightforward to take the projections associated with each of the choice > elements, and place the fault projections within fault handlers inside the > associated invoke activity. <NK> Two points: 1) the rules for associating the exchange/record parts of an interaction that span multiple interaction elements have to be clearly specified and this may be a challenging exercise. What are the exact rules your are proposing for the associations? 2) even if the association rules are properly spelled out, we still need to support a single interact element that has two or more exchange elements with one request and one or more respond actions. </NK> > > The other approach would be to have multiple exchange elements in a single > interaction (as Nick's proposal suggested), but we would need to ensure that > the occurance of a fault did not simply cause an exception to be thrown. > However, this would mean having some form of decision block following the > interaction that would have to check to see which variable had been > populated, before knowing which workunit (path) to take next. <NK>As we've discussed in last week's con-call there are no surprises in this approach</NK> > > I believe this second approach may not be as straightforward to project onto > BPEL exception handlers (within the invoke statement) due to the potential > for a user to define more complex guards on the workunits following the > interaction - although we could always validate to avoid this situation > aswell. <NK> Again, I think that there are no surprises here: Either: -faults that are caused in an interaction are triggering exception work units to be considered for matching Or -normal data populating variables in a exchange/record of an interact are triggering normal work units to be considered for matching </NK> > > Regards > Gary > > > >
Received on Monday, 25 October 2004 21:41:28 UTC