OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: multiparty (was) Fwd: Re: message routing


This is really an important conversation.

I think it is imperative to think of the business requirements here
and not trip off into all the possible permutations of multi-party
interactions.

* Questions:
1. What are the real business scenarios requiring business collaborations
composed of multiple related transactions?  (I mean transactions in
the BPSS BusinessTransaction sense here.)

2. What are the real business scenarios requiring multi-party
collaborations?

* Tentative stabs at answers:
1. The most common business scenario will probably be order-fulfillment,
where one transaction forms the order (a kind of contract) which could be
composed of many commitments (e.g. line items) to deliver and pay for
goods or services.

So in this case, some of the transactions in the collaboration will have
commitment-fulfillment relationships between them.  (This is all described
or at least sketched out in UMM.)

I have proposed on the BP list that commitment-fulfillment relationships
be used explicitly to manage multi-transaction collaborations in the next
stage of BPSS work, when UN/CEFACT gets rolling.

But you can still think of them implicitly as one of the main business
requirements for multi-transaction collaborations, where one transaction
has depencies on another.

2. One of the main scenarios involving multiple parties is when one
party needs help to fulfill commitments to another party.  I think,
but cannot yet prove, that most or all of these scenarios can be
resolved into reciprocal commitments between two parties.
(Bill McCarthy says there is proof that all multi-party scenarios
can be broken down into binary commitments.)

So it may be possible to resolve multi-party collaborations to
a simpler group of related dialogs, not only as a temporary
expedient but as a permanent solution for at least a large
majority of real use cases.

I agree with Jamie that good examples are required here.  Besides
the one that he sketched out, the dropship scenario used in the ebXML-BP
Worksheet document would work for a starter.

I fully agree that there important unresolved issues of who controls
the overall multi-party collaboration, who gets what information,
who controls each transaction (which will be different from who controls
the overall collaboration), etc.

-Bob Haugen



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC