[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC