RE: Collaboration Services (was: Business Service Interface)

[Bob Haugen <linkage@interaccess.com>]

My comments below Dale's most excellent message...

<Dale Moberg>
I think that defining preconditions and postconditions on "segments"
of business processes (where a segment is something like an edge
in a graph of business states) would without doubt be general enough
for anything to be choreographed for a number of years.

My problem is that it is _so_ general that it is difficult to see
how the resulting processes will "modularize out" for implementation levels.

Here is a case that I hope illustrates my point. A large motherboard
manufacturer needs weekly small parts (capacitor resistors etc) from 
its multiple suppliers, say 10 large suppliers. It wants aggregate numbers 
of capacitor C for the upcoming production run, and knows no one supplier 
will be able to meet that aggregate number.
So the manufacturer broadcasts to each supplier to say how many C (at what
cost) can be made available by time T, and to reserve those quantities for 5 hours, 
or until they get a release-or-order document. Meanwhile the precondition for 
responding to the availability messages might be phrased as "wait until a majority 
of suppliers have responded or 5 hours elapse" or it might be "wait until the 
aggregate available C crosses the threshold or 5 hours elapse" or "(wait until 
the optmized price per C is below X and aggregate available C crosses threshold) 
or 5 hours elapse".

The point here is that while middleware products might coordinate processes
where the join precondition is in terms of number of messages received, if the
precondition wanders into optimizations over business quantities, normally we 
would think that an application needs to be specially constructed/confgiured to 
do those jobs.
So it is hard to see where to draw the line at session layer coordination of
processes and more substantial business quantity coordination of BPs.
</Dale Moberg>

Dale, thank you thank you thank you for giving a business example!
I fully agree that no mechanism in ebXML documents will handle
most business collaboration scenarios of any significance.
Pre and post conditions just give the business collaboration
software something to work with.  

I also agree that they are too general to do much real work,
so the real work needs to be done by the collaboration patterns
that surround the business documents.

I also fully agree that applications need to be specially constructed
to handle most real business collaborations.  However, there are
several common collaboration patterns that can be (will be) pre-
configured by the ebXML BP-CC Core Processes group, to the
extent at least of UML models.  Real software even for the common
collaboration patterns will need to be developed by real software
vendors, but the hooks for developing them will exist in the
ebXML (BP) metamodel and the core process patterns.

What you described sounds to me like a variation of a common
RFQ pattern: broadcast the request with a timeout, select the
best response(s), and send order(s).  The variations are reserving 
the parts and aggregating the quantity.  The process involves
forming Commitments, for which there are hooks in the
ebXML (BP) metamodel.  The collaboration service software to
do this would need some custom development, but if the main
components were present in a scripting environment, might
be fairly simple to do.

Thanks for your input,
Bob Haugen