- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 18 Mar 2003 21:17:51 -0800
- To: "Monica J. Martin" <monica.martin@sun.com>, "Burdett, David" <david.burdett@commerceone.com>
- Cc: <edwink@collaxa.com>, "'Patil, Sanjaykumar'" <sanjay.patil@iona.com>, "'Fletcher, Tony'" <Tony.Fletcher@choreology.com>, <ChBussler@aol.com>, <steve@enigmatec.net>, <public-ws-chor@w3.org>
I would say that we need to differentiate between 'business errors', which I prefer to call exceptions, and technical errors. They may cause the process to stop, but they may also cause the process to follow another path. The reason for expressing them is to indicate what the path would be. For example, as long as the seller can keep talking to the buyer they progress along one path. But if the seller identifies some technical error, the seller may not be able to progress along that path, but would like to communicate the end of the transaction as part of a 'fault handling' path. That makes it more declarative in terms of what events lead to what paths. I'm not sure there is much value in identifying specific faults, I think some coarse distinction will suffice. For example, the seller may send a message that the buyer cannot validate. The buyer can send back some fault. But the seller may validate the message on its side before sending it, determine the fault without having to receive it from the buyer. The seller may find that it's implementation is wrong and it cannot proceed. It's able to fix the implementation but that may take longer than the transaction timeout. So suffice that the seller can say 'oops, something went wrong, let's decide to cancel the transaction'. I don't think there's need to delve into the what went wrong in much detail, coarse grain would work fine for all the scenarios I've seen. arkin > -----Original Message----- > From: Monica J. Martin [mailto:monica.martin@sun.com] > Sent: Tuesday, March 18, 2003 8:13 PM > To: Burdett, David > Cc: edwink@collaxa.com; 'Assaf Arkin'; 'Patil, Sanjaykumar'; 'Fletcher, > Tony'; ChBussler@aol.com; steve@enigmatec.net; public-ws-chor@w3.org > Subject: Re: [Requirements] Non-requirement for MEPs > > > Do we need to differentiate error, failure, and exception? The latter > may or may not result in an action that stops the process, only directs > into another path. > > Thanks. > > "Burdett, David" wrote: > > > EdwinGood points. Here's my complete "stack" of different types of > > errors that can occur - they all have an impact on choreographies > > ...1. Transmission error. - The message was never sent. This is a send > > side error, the rest below are receive side.2. Delivery Failure - The > > message was sent but was (probably) not received - this is the WS-RM > > domain3. Message format error - the components of the message were not > > validly constructed. If this is really bad, you might not be able to > > work out who sent the message and therefore can't send an error > > back.4. Message Content structure error. These are errors where one of > > the parts of the message is not valid. This splits into several > > different lower level variations: a) Not well formed - e.g it's not > > well formed XML, or its a MS Word doc that can't be read b) Invalid - > > it's well formed but does not conform to its rules, e.g it does not > > conform to the schema c) Integrity error - for example the total > > amount on the Invoice does not equal the sum of the individual line > > items d) Reference error - for example the part number on a line item > > is not recognized by the receiver5. Process error. This also has a > > number of lower level variations: a) Process failure. For example, > > you wanted to order 10 widgets, but they were out of stock. You could > > argue this is a normal business response and not actually an error. > > b) Process abort. For some reason the processing of the message > > started but crashed part way through. The resultant state may not be > > known.However from a choreography perspective you can simplify this > > to:1. Transmission error - 1 above2. Delivery failure - 2 above3. > > Message not processed (3 & 4 above)4. Process Failure - 5a above5. > > Process Abort - 5b aboveThoughts?David > > > > -----Original Message----- > > From: Edwin Khodabakchian [mailto:edwink@collaxa.com] > > Sent: Monday, March 17, 2003 11:19 PM > > To: 'Burdett, David'; 'Assaf Arkin'; 'Patil, Sanjaykumar'; > > 'Fletcher, Tony'; ChBussler@aol.com; steve@enigmatec.net; > > public-ws-chor@w3.org > > Subject: RE: [Requirements] Non-requirement for MEPs > > > > David,If you look at BPEL today, you will see that there are > > 2 types of errors: (1) errors that are described as part of > > the WSDL of the service (business errors like Insuficient > > Credit, Invalid Part Number, etc...) and (2) errors that are > > caused by SOAP "remoting" stack (equivalent of > > RemoteException in Java like IO exception, version mismatch > > exception etc...).Both kind of error need to be handled and > > manage by the orchestration layer and therefore defined in > > the choreography layer.BPEL4WS v1 forgot to standardize (2) > > which is a problem with regard to portability across BPEL4WS > > engine.Edwin > > > > -----Original Message----- > > From: public-ws-chor-request@w3.org > > [mailto:public-ws-chor-request@w3.org] On Behalf > > Of Burdett, David > > Sent: Monday, March 17, 2003 10:44 PM > > To: 'Assaf Arkin'; Patil, Sanjaykumar; Fletcher, > > Tony; ChBussler@aol.com; steve@enigmatec.net; > > public-ws-chor@w3.org > > Subject: RE: [Requirements] Non-requirement for > > MEPs > > > > I tend to agree with Assaf.I think that WS-Chor > > should focus on describing exchanges of > > information that change the state of the process. > > For example if a buyer sends an order to a > > supplier the message sent in return is often an > > order response that indicates the extent to which > > the supplier can (or can't) satisfy the > > order.However other "errors" can occur as a > > reysult of sending the order which are detected at > > different levels in the stack:1. Delivery errors - > > for example the message could not be delivered. > > This is typically WS-RM function to detect2. > > Message structure errors - this means tha the > > order could not be unpacked from its (SOAP ) > > envelope at its destination - this is a messaging > > error3. Document structure errors - e.g. the > > structure of the document was not valid. If bad > > enough this can prevent the generation of the > > "business level" order response.Any of these > > errors can be sufficient to stop the conversation > > (i.e. an instance of the choreography) from > > completing and therefore the idea of an "error" as > > the result of sending a message in a choreography > > is definitely part of the choreography. However, > > how the error is detected, is not, IMO, > > particularly relevant. So in this case this > > choreography should say, for example ... "Send > > Order, from Buyer to Supplier" ... and the valid > > responses could be ... "Send "OrderError" from > > Supplier to Buyer", or "Send "OrderResponse" > > from Supplier to Buyer.... where "Order Error" > > could be any of the errors described > > above.Thoughts?David > > > > -----Original Message----- > > From: Assaf Arkin > > [mailto:arkin@intalio.com] > > Sent: Monday, March 17, 2003 5:38 PM > > To: Patil, Sanjaykumar; Fletcher, Tony; > > ChBussler@aol.com; steve@enigmatec.net; > > public-ws-chor@w3.org > > Subject: RE: [Requirements] > > Non-requirement for MEPs > > > > I'm going to do the "hot potato" thing > > and suggest that we leave those issues > > that are not specific to choreography to > > other working groups.For example, > > signals. How do you represent the fact > > that a message must be acknowledged? > > Let's say WS-Chor comes up with a > > solution. Can you use it with a service > > that it no used in the context of any > > defined choreography? Or do we have one > > way to do it in WS-Chor and another in > > WSD?What about WS-RM (1 and 2) which > > already deal with that issue. Do we come > > up with yet another solution for > > sending/receiving acks? Do we try to > > model their approach with WS-Chor? Did > > anyone identify the need to use WS-Chor > > to define these acks?Try as I may I only > > found one sequence set that is > > parameterized by the QoS requested. So > > we can exchange different sequences, but > > it appears to me that just exchanging > > different QoS policies would be easier > > (to write, validate and process). This > > seems more of a problem for WS-Policy to > > provide the framework, and WSD to allow > > these patterns to occur within the > > operation (so not to affect it's > > abstract definition).arkin > > > > -----Original Message----- > > From: > > public-ws-chor-request@w3.org > > [mailto:public-ws-chor-request@w3.org]On > > Behalf Of Patil, Sanjaykumar > > Sent: Monday, March 17, 2003 > > 11:05 AM > > To: Fletcher, Tony; > > ChBussler@aol.com; > > steve@enigmatec.net; > > public-ws-chor@w3.org > > Subject: RE: [Requirements] > > Non-requirement for MEPs > > > > Agree, except that perhaps we > > should keep the two issues > > (supporting MEP and supporting > > signals) separate.Regarding > > MEP, I guess WSDL may not > > define all the MEPs for us, > > specifically the ones that > > have additional semantics in > > the context WS-choreography > > and which in the context of a > > single WSDL may map to one of > > the pre-defined MEP. For > > example, a multi-cast MEP in > > the context of a choreography > > that sends a request for quote > > to multiple parties may be > > perceived as a simple > > notification MEP by the > > individual services of the > > recipient parties. Basically, > > I think, we can expect WSDL to > > define only a set of basic > > MEPs, that are meaningful in > > the context of individual > > services. We, the WS-chor > > group may define the > > additional complex MEPs and > > perhaps we (along with the > > WSDL working group) should > > ensure that the the WS-chor > > defined MEPs can be decomposed > > into the WSDL defined basic > > MEPs.The issue of signals on > > the other hand is orthogonal > > to the WSDL defined MEP. I > > guess, the signals will be > > defined by the WS-chor (and > > perhaps some other > > specifications) and their > > transmittal can be mapped to a > > pre-defined MEP. For example, > > the receival of a business > > message and sending an > > acknowledgement signal can be > > mapped to a request-response > > MEP. On a side note, I would > > however like to raise an issue > > related to the proper scoping > > of the signals, whenever we > > define them. In some of the > > previous business process > > related work (such as > > RosettaNet), signals were used > > to represent simultaneously > > different meanings such as a > > notification of the status of > > the delivery of message and > > also the notification of the > > outcome of the business level > > content validation, etc. > > Although it was not a blocker > > issue, this overloading of the > > semantics of signals had kind > > of intermixed the different > > functional layers, making it > > harder to provide for > > exceptional handling, etc. We > > should perhaps identify > > clearly the signals that map > > to the WS infrastructure stack > > such as the message delivery > > guarantee and the ones that > > have application semantics > > such as business > > content-validation. With this, > > we would also be able to reuse > > support for the > > infrastructural signals from > > other specifications such as > > WS-reliability (whatever and > > wherever this spec is today!), > > etc and focus only on the > > business process level > > signals. thanks,Sanjay Patil > > Distinguished Engineer > > sanjay.patil@iona.com > > > > > ------------------------------------------------------ > > > > IONA Technologies > > 2350 Mission College Blvd. > > Suite 650 > > Santa Clara, CA 95054 > > Tel: (408) 350 9619 > > Fax: (408) 350 9501 > > > > > ------------------------------------------------------ > > > > Making Software Work Together > > TM > > > > -----Original > > Message----- > > From: Fletcher, Tony > > [mailto:Tony.Fletcher@choreology.com] > > > > Sent: Monday, March > > 17, 2003 8:22 AM > > To: > > ChBussler@aol.com; > > steve@enigmatec.net; > > public-ws-chor@w3.org > > > > Subject: RE: > > [Requirements] > > Non-requirement for > > MEPs > > > > Dear Colleagues,I > > should make it clear > > that I was not > > thinking in terms of > > WSDL at all. (I > > guess that by its > > nature this group > > will have to map > > onto WSDL as a > > 'lower' thing and so > > hopefully we can > > make use of WSDL's > > basic MEPs - we may > > just need a simple > > 'send' and 'receive' > > at the WSDL level > > (i.e. only 2 of its > > current 4 / 7 > > patterns) and we > > compose those at > > will to make other > > patterns at the > > WS-Chor spec > > level).I was > > thinking in terms of > > the message pattern > > that is built into > > BPSS. This called a > > Business Transaction > > and is a Request ( > > only mandatory part) > > from 'Requester' to > > 'Responder' followed > > by an (optional) > > receiptAcknowledgement > > from 'Responder' to > > 'Requester' > > followed by an > > (optional) > > acceptenceAcknowledgement > > from 'Responder' to > > 'Requester' followed > > by an > > (optional) Response > > from 'Responder' to > > 'Requester' > > followed by an > > (optional) > > receiptAcknowledgementfrom > > 'Requester' to > > 'Responder' . The > > Request and Response > > are messages > > compiled by the > > driving application > > (/process). The > > Acknowledgements are > > pre-defined messages > > structures were only > > the values are > > supplied on the > > fly.So in BPSS a > > Business Transaction > > (that which I was > > meaning as a MEP) is > > the lowest layer of > > message sequencing. > > Business > > transactions can be > > composed into sets > > known as binary > > collaborations > > (which will have a > > particular purpose) > > and can be built > > into higher level > > binary > > collaborations (with > > a wider purpose) and > > so on. The highest > > layer of BPSS adds > > in multiple roles > > and the sequencing > > of the binary > > collaborations into > > a complete multi > > role > > collaboration.The > > folks who designed > > BPSS believe that > > the Business > > Transaction message > > exchange pattern is > > all that is required > > to provide any > > *business* message > > exchange and are > > thus prepared to > > live with its > > restriction. They > > may be correct, but > > personally I am not > > sure and feel that > > it may be safer to > > allow the users of > > the WS-Chor language > > to have freedom to > > design their own > > business message > > exchange patterns.I > > do think that > > specifying some > > standard 'messages' > > (the things that > > BPSS calls signals) > > that users of the > > language can readily > > call up and invoke > > would be useful and > > should be added to > > the > > requirements Best > > Regards TonyA M > > Fletcher Cohesions > > 1.0 (TM) Business > > transaction > > management software > > for application > > coordination Choreology > > Ltd., 13 Austin > > Friars, London EC2N > > 2JX UKTel: +44 > > (0) 20 76701787 > > Fax: +44 (0) 20 7670 > > 1785 Mobile: +44 > > (0) 7801 > > 948219tony.fletcher@choreology.com > > (Home: > > amfletcher@iee.org) > > > > > > ----Original > > Message----- > > > > From: > > public-ws-chor-request@w3.org > > [mailto:public-ws-chor-request@w3.org] > > On Behalf > > Of > > ChBussler@aol.com > > > > Sent: 17 > > March 2003 > > 15:38 > > To: > > steve@enigmatec.net; > > Fletcher, > > Tony; > > public-ws-chor@w3.org > > > > Cc: > > ChBussler@aol.com > > > > Subject: > > Re: > > [Requirements] > > Non-requirement > > for MEPs > > > > Hi, > > > > I think it > > is > > preferrable > > not to be > > restricted > > to WSDL, > > but also > > allow for > > the > > inclusion > > of other > > definitions/mechanisms. > > > > Christoph > > > > In a > > message > > dated > > 3/17/03 > > 7:04:24 AM > > Pacific > > Standard > > Time, > > > > teve@enigmatec.net > > writes: > > > > > > > > > Subj:RE: > > > [Requirements] > > > Non-requirement > > > for MEPs > > > > > > Date:3/17/03 > > > 7:04:24 > > > AM > > > Pacific > > > Standard > > > Time > > > > > > rom:steve@enigmatec.net > > > > > > To:Tony.Fletcher@choreology.com, > > > public-ws-chor@w3.org > > > > > > Sent > > > from the > > > Internet > > > > > > > > > > > > > > > Tony, > > > > > > I think > > > that > > > there is > > > an > > > implication > > > of this > > > exclusion. > > > It is > > > that the > > > choreography > > > would be > > > tied to > > > WSDL > > > based > > > MEP's. > > > If > > > however > > > we make > > > MEP's > > > part of > > > the > > > scope > > > then we > > > could > > > extend > > > the > > > reach of > > > the > > > groups > > > work to > > > include > > > non-WSDL > > > based > > > formalisms. > > > > > > Cheers > > > > > > Steve T > > > > > > > > > > -----Original > > > > Message----- > > > > > > > > From: > > > > public-ws-chor-request@w3.org > > > > > [mailto:public-ws-chor-request@w3.org]On > > > > Behalf > > > > Of > > > > Fletcher, > > > > Tony > > > > Sent: > > > > 17 > > > > March > > > > 2003 > > > > 13:26 > > > > To: > > > > public-ws-chor@w3.org > > > > > > > > Subject: > > > > [Requirements] > > > > Non-requirement > > > > for > > > > MEPs > > > > > > > > > > > > Dear > > > > Colleagues, > > > > > > > > Just to > > > > put in > > > > a > > > > message > > > > what I > > > > stated > > > > at the > > > > inaugural > > > > F2F. > > > > > > > > Non- > > > > requirement > > > > for > > > > MEPs: > > > > It > > > > presently > > > > seems > > > > to me > > > > that it > > > > is a > > > > 'non-requirement' > > > > to > > > > standards > > > > message > > > > exchange > > > > patterns > > > > (MEP) > > > > as part > > > > of the > > > > WS-Chor > > > > work. > > > > MEPs > > > > act as > > > > a > > > > constraint > > > > on what > > > > you can > > > > do, so > > > > if one, > > > > or > > > > more, > > > > are > > > > defined > > > > we will > > > > have to > > > > be very > > > > sure > > > > that > > > > users > > > > of the > > > > technique > > > > can > > > > live > > > > within > > > > that > > > > set of > > > > constraints > > > > without > > > > having > > > > to > > > > 'jump > > > > through > > > > hoops' > > > > such as > > > > extending > > > > the > > > > standard > > > > MEPs or > > > > having > > > > to > > > > chain > > > > them > > > > together > > > > to get > > > > the > > > > pattern > > > > they > > > > actually > > > > need. > > > > > > > > > > > > equirements: > > > > > > > > We > > > > certainly > > > > need to > > > > specify > > > > the > > > > 'construct' > > > > for > > > > sending > > > > a > > > > single > > > > message > > > > so that > > > > should > > > > be > > > > added > > > > to the > > > > requirements > > > > list. > > > > > > > > We may > > > > also > > > > wish to > > > > standardise > > > > as part > > > > of the > > > > specification > > > > (in a > > > > normative > > > > appendix > > > > perhaps) > > > > some > > > > standard > > > > business > > > > messages, > > > > such as > > > > a > > > > generic > > > > error > > > > reporting > > > > message > > > > and an > > > > acknowledgement > > > > message > > > > > > > > Best > > > > Regards > > > > Tony > > > > A M > > > > Fletcher > > > > > > > > Cohesions > > > > 1.0 > > > > (TM) > > > > > > > > > > > > usiness > > > > transaction > > > > management > > > > software > > > > for > > > > application > > > > coordination > > > > > > > > Choreology > > > > Ltd., > > > > 13 > > > > Austin > > > > Friars, > > > > London > > > > EC2N > > > > 2JX > > > > UK > > > > Tel: > > > > +44 (0) > > > > 20 > > > > 76701787 > > > > Fax: > > > > +44 (0) > > > > 20 7670 > > > > 1785 > > > > Mobile: > > > > +44 (0) > > > > 7801 > > > > 948219 > > > > > > > > ony.fletcher@choreology.com > > > > (Home: > > > > amfletcher@iee.org) > > > > > > > > > > > > > > > > > > > > > > > - > > > ------------------------------------------------------------------ > ------------------------------------- > > > > Christoph > > Bussler > > > > hBussler@aol.com > > > > hometown.aol.com/ChBussler/ > > > > www.google.com/search?q=bussler > > > > www.google.com/search?hl=en&q=bussler&btnI=I%27m+Feeling+Lucky > > -------------------------------------------- -------------------------------------------------------------- >
Received on Wednesday, 19 March 2003 00:19:43 UTC