- From: Patil, Sanjaykumar <sanjay.patil@iona.com>
- Date: Tue, 18 Mar 2003 15:56:54 -0800
- To: "Monica J. Martin" <monica.martin@sun.com>
- Cc: <public-ws-chor@w3.org>
Agree, not all errors would result into stopping a conversation. And sometimes the conversation for which an error/exception is received has already exited (or never kicked off), which will not be an uncommon scenario, IMO. I guess, an additional requirement for the specification would be to provide support for defining behavior of the system, when valid error/exception messages arrive for choreography instances after their completion (or before their initiation). We may want to look into the solutions offered by previous work for this problem, such as the PIP 0A1 by RosettaNet - http://www.rosettanet.org/PIP0A1 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: Monica J. Martin [mailto:monica.martin@sun.com] Sent: Tuesday, March 18, 2003 3:27 PM To: Burdett, David Cc: 'Assaf Arkin'; Patil, Sanjaykumar; Fletcher, Tony; ChBussler@aol.com; steve@enigmatec.net; public-ws-chor@w3.org Subject: Re: [Requirements] Non-requirement for MEPs Remember to account for those 'errors' that are actually exceptions or less traveled paths that may not be substantive in nature. Therefore, the exception may or may not result in stop the conversation. Thanks. Monica J. Martin Sun Microsystems "Burdett, David" wrote: > 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, > steve@enigmatec.net writes: > > > > > Subj:RE: [Requirements] > > Non-requirement for MEPs > > Date:3/17/03 7:04:24 AM > > Pacific Standard Time > > From:steve@enigmatec.net > > > > o: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. > > > > > > Requirements: > > > 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) > > > > > > Business 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 > > > > > > tony.fletcher@choreology.com > > > (Home: amfletcher@iee.org) > > > > > > > > > > > > - > ------------------------------------------------------------------------------------------------------- > > Christoph Bussler > ChBussler@aol.com > hometown.aol.com/ChBussler/ > > ww.google.com/search?q=bussler > > www.google.com/search?hl=en&q=bussler&btnI=I%27m+Feeling+Lucky > > ---------------------------------------------------------------------------------------------------------- >
Received on Tuesday, 18 March 2003 18:57:29 UTC