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

RE: Business Protocol (was: Application Protocol Definition)

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?

Received on Thursday, 27 February 2003 21:17:45 UTC

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