Re: [ebxml-cppa-negot] Re: Negotiation pattern, transactions, CPP A

[bhaugen <linkage@interaccess.com>]

I might agree with Brian's colleague,
depending on the details of what he means.

There is a business protocol stack that rides
on the technical protocol stack.

The business protocol stack goes something
like (from the bottom):
* transaction
* economic event, commitment, or claim
* order
* long-term contract

A shipment notice is an economic event.
Yes it may apply to many orders.
If so, it will usually (but not always) be covered
by the same long-term contract.
If not, it's probably a custom handling
procedure, or dependent on human
intervention.

The business protocol stack is being defined
in eBTWG.  So far we have modeled up to
the order level as a Business Collaboration
in BPSS terms.  Long-term contracts may
live at another technical level (maybe
Business Process in UMM) or just nested
Business Collaborations.

But to handle the application of shipment
notices to many orders in an automated
manner as part of the external business
collaboration, we will need an explicit
business protocol stack up to the
long-term contract level.

If the long-term contract is part of the
electronic business process management
architecture, then conversation_id is just
how the lowest level business collaborations
are factored.

-Bob Haugen

----- Original Message -----
From: Hayes, Brian

> A comment from one of my Commerce One colleages regarding conversation
Ids:
> -----Original Message-----
>
> Brian,   here is my 2-cent:  conversation_id is a runtime concept to
ensure
> the choreography, not a logic or semantic one.  The issue of "the
shipment
> notice and/or the invoice will cover multiple purchase orders" seems
at the
> logic or semantic level.  As long as the collaboration is defined to
handle
> the shipment notice in such a way, it should be acceptable...
>
> -George