RE: Collaboration Services (was: Business Service Interface)

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

<Stefano Pogliani>
I did not fully understand the position which is expressed in your message.
What Bob was saying (if I interpret correctly) is, in summary, that :
	- sequencing is not a pattern that could be generally used to
	  model the business intelligence
	- that some software (Bob mentions two levels) is required to 
	  manage long collaborations (and their status)
</Stefano Pogliani>

<BobHaugen>
Stefano, thank you for a careful reading.  Slight clarification: 
I would not deny the usefulness of simple sequencing in some
cases, but there are other important cases where it is inadequate
and pre and post conditions would also be simple and work well.
I believe there is general agreement in the BP group now that
pre and post conditions are important choreography hooks.
</BobHaugen>

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.