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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


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


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC