- From: Burdett, David <david.burdett@commerceone.com>
- Date: Fri, 28 Feb 2003 03:16:14 -0800
- To: "'Assaf Arkin'" <arkin@intalio.com>, bhaugen <linkage@interaccess.com>, James M Snell <jasnell@us.ibm.com>
- Cc: www-ws-arch@w3.org
Some more thoughts ... 1. I am not sure that *business* protocol is the right term since protocols at the same level can be used for non-business purposes. However I am not sure what term would be better, so perhaps we live with for the time being. 2. We really need to distinguish between: a) Standards that define protocols, and b) The protocol definitions instances themselves. For example ebXML BPSS is a protocol definition language, where a RosettaNet PIP 3A4 specified using BPSS is a definition instance. The two are independent as you can have the same definition instance recorded using different representations, for example a MS Word and an ebXML BPSS specification of PIP 3A4 are both the same business protocol. 3. There is a difference between an "internal business process" and a "business protocol" as defined above. The latter has to be agreed between the parties involved for interoperability to occur. The former, since it describes the business process within an enterprise, does not. However the internal business process is *constrained* by the business protocol it needs to use so the two are not entirely separate. Languages such as BPEL4WS and WSCI only define the internal business process. They do *not* define the business protocol in the way that BPSS does for example. In fact I don't believe you can define a business protocol (as defined above) with a single BPEL4WS or WSCI definition. There is a gap and architectural requirement here that needs to be resolved. 4. Instead of calling a combination of protocols used together some other kind of protocol, I suggest we call them a "Protocol Profile". A Protocol Profile could detail a specific combination of: Network, Transport, Messaging, Utility and Business Protocols. Is this an idea worth exploring further? David -----Original Message----- From: Assaf Arkin [mailto:arkin@intalio.com] Sent: Thursday, February 27, 2003 6:16 PM To: bhaugen; James M Snell Cc: www-ws-arch@w3.org Subject: RE: Business Protocol (was: Application Protocol Definition) > -----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 Friday, 28 February 2003 06:16:46 UTC