- From: Mayilraj Krishnan <mkrishna@cisco.com>
- Date: Tue, 18 Mar 2003 09:57:37 -0800
- To: "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
- Cc: "Patil Sanjaykumar" <sanjay.patil@iona.com>, public-ws-chor@w3.org
I don' t think anybody suggesting not to use WSDL. There were suggestions to define the business message exchanges or business signals which could be mapped to basic MEPs.. As you are pointing out if basic MEPs could not map all our needs, then we might have to define additional MEPs. Regards Mayilraj At 03:17 PM 3/18/2003 +0100, Jean-Jacques Moreau wrote: >Yes, I think WSDL will provide only a subset of the MEPs you will need. >The MEPs that WSDL is likely to provide are described here [1]. This is >work in progress and should be considered as such. > >BTW, I have been somewhat puzzled by messages in this thread saying the WG >is not going to use MEPs or WSDL -when I expected it would. Is this the >WG's opinion? Have I missed something? > >Regards, > >Jean-Jacques. > >[1] ><http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.html> > >Patil, Sanjaykumar wrote: >> >>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) receiptAcknowledgement >> from '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 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 >> <mailto:tony.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 <mailto:steve@enigmatec.net> >>> To:Tony.Fletcher@choreology.com >>> <mailto:Tony.Fletcher@choreology.com>, public-ws-chor@w3.org >>> <mailto: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 >>>> <mailto:tony.fletcher@choreology.com> (Home: >>>> amfletcher@iee.org) >>>> >> >> >>--------------------------------------------------------------------------------------------------------- >> Christoph Bussler >> ChBussler@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 Tuesday, 18 March 2003 13:02:55 UTC