W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2003

RE: Business Protocol (was: Application Protocol Definition)

From: Burdett, David <david.burdett@commerceone.com>
Date: Fri, 28 Feb 2003 03:16:14 -0800
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1798@C1plenaexm07.commerceone.com>
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


-----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?

Received on Friday, 28 February 2003 06:16:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:04 UTC