RE: Collaboration Services (was: Business Service Interface)

[Martin W Sachs/Watson/IBM <mwsachs@us.ibm.com>]

Bob,

You are making good sense.  The TP team plans to work with the BP team to
define how the CPP/CPA will mesh with the BP model so that the
orchestration rules in the CPA can be derived from the BP model for the
process.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Bob Haugen <linkage@interaccess.com> on 10/23/2000 11:53:30 AM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "ebxml-tp@lists.ebxml.org" <ebxml-tp@lists.ebxml.org>,
      "'ebXML-BP@llists.ebxml.org'" <ebXML-BP@lists.ebxml.org>
Subject:  RE: Collaboration Services (was: Business Service Interface)



<Martin Sachs>
Nothing really got resolved at the F2F except the technical content of the
team requirements document.  I believe that the consensus of the group that
was present was to start with the tpaML sequencing rules and later add a
more general orchestration representation, perhaps an ECA state machine
representation. There is a timing question - what can we hope to complete
for a May deliverable?
</Martin Sachs>

I can see I am not stating part of my argument very clearly.
Let me try a different tack:  I am arguing that some very
common business scenarios contain their own choreography
or ordering or sequencing rules.  I am not really arguing
for a more general orchestration representation, I think
the pre and post conditions in the BP metamodel
are sufficient, and would not really object to other
representations being added as long as the BP
style is preserved.

But general representations pose problems
for actually doing business, because it takes two
to tango, if you know what I mean.  Both partners
in the collaboration need to agree on the same
rules, which is much easier if they just subscribe
to a common business process rather than descend
to the level of negotiating sequencing rules.

For example, in electronic business, you will find
yourself doing offer-acceptance collaborations all
the time.  They are directly represented in the
BP metamodel by a predefined pattern which
both trading partners can adopt and get on with
the business, rather than trying to redefine offer-
acceptance from first principles every time.
It's already been defined (actually for many
many years).

Likewise there are many common business
process patterns that should be canned and
re-used:  order-fulfillment-payment,
contract negotiation, etc.  There is actually
an ebXML group working on what they call
Core Processes that is tackling these issues.
Many of these core processes will be defined
by the ebXML deadline.  If people want variations,
specializing the core process will still help them
get going faster.

I think that core processes need the pre and post condition
style of choreography to be freely re-usable.  That is the
reason I am making a point of this technique, not
that there is anything wrong with linked lists in the
proper context.  (That is why I requested business
scenarios...)

Am I making sense yet?

Regards,
Bob Haugen