RE: Collaboration Services (was: Business Service Interface)

[Cory Casanave <cory-c@dataaccess.com>]

I am having a bit of trouble here.  The trouble is in relation to activity
graphs (which are state machines) and pre/post conditions (Which are
expressions).  It seemed that there was good agreement on the use of
activity graphs.  This provides for the sequencing of messages as well as
commercial transactions with all the power of a state machine (which if
anything is more than required).  I don't see why pre/post conditions are
also being used at all and I have not seen any example that could not be
expressed more simply in an activity graph.

The reasons not to have both are;
1) Simplicity - we should use as few constructs as we can, activity graphs
are already being used.
2) Coupling.  Pre/post conditions are expressions which will require
internal "variables" and such, exposing or constraining implementation.
Also, binding a full expression syntax and Meta model into UML is complex
(See OCL).
3) It is much easier to automate the execution of a state machine
4) Activity graphs are more visual 


So, why not use activity graphs (or a subset of them) for all sequencing
semantics?

Regards,
Cory Casanave



> -----Original Message-----
> From:	Bob Haugen [SMTP:linkage@interaccess.com]
> Sent:	Wednesday, October 25, 2000 12:01 PM
> To:	'Moberg, Dale'; 'stefano.pogliani@sun.com'; jjdubray@exceloncorp.com
> Cc:	ebXML-BP@lists.ebxml.org; ebXML-tP@lists.ebxml.org
> Subject:	RE: Collaboration Services (was: Business Service Interface)
> 
> 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