- From: Assaf Arkin <arkin@intalio.com>
- Date: Thu, 27 Feb 2003 18:16:07 -0800
- To: "bhaugen" <linkage@interaccess.com>, "James M Snell" <jasnell@us.ibm.com>
- Cc: <www-ws-arch@w3.org>
> -----Original Message----- > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On > Behalf Of bhaugen > Sent: Thursday, February 27, 2003 4:09 PM > To: Assaf Arkin; James M Snell > Cc: www-ws-arch@w3.org > Subject: Re: Business Protocol (was: Application Protocol Definition) > > > > Here are some distinct things: > 1. Offer-Acceptance as a description > of the rules of contract formation. > 2. UNECE Recommendation 31, Electronic Commcerce Agreement > as a pretty neutral set of rules for doing offer-acceptance > electronically. > 3. RosettaNet PIP 3A4 as a document specifying > a particular set of messages and signals for executing > UNECE Recommendation 31. > 4. An ebXML BPSS script describing PIP A34 in XML > (which RosettaNet is actually developing). > 5. An implementation of the BPSS script using BPEL > or BTP or BPML. > 6. Web Services for participating in that implementation. > 7. A runtime transaction executing that implementation. > > I would tend to call #1 a Business Protocol, > but whatever you call them, each of the above > is something different-but-related. Excellent list. At least in my understanding #1 and #2 are equivalent, with #1 being any Joe's description and #2 being a UNECE Recommendation, but they are both at the same level. I would not call this 'business protocol', just because I'm afraid that talking to a business person about rules of engagement and using the term protocol I would be thrown out the window ;-) Maybe a more appealing term like 'business use case'? No #3 and no #4 seem to be at the same level. We usually refer to that as 'business scenario', basically an outline of what you are planning to do in that particular business context. We usually describe that using very abstract choreographies (no services included). No #5 is really an implementation, but I would switch order and put the interaction first (#6->#5) and then build an implementation to support it at #6. Quite frankly, I would much rather use the term 'WS Choreography' to describe that. So where is the 'business protocol'? Maybe it's the mythical beast that exists when one combines scenarios with actual communication, it's half way between #4 and #5 and maybe both at the same time? arkin
Received on Thursday, 27 February 2003 21:17:45 UTC