Subject: RE: Comments about the document"ebXML Business Process Specification Schema Version 0.90"
Alain and all, I wanted to reflect on a couple of issues in your most excellent document, based on some work that is going on in the ebXML-CC-BP-Analysis group on business "collaboration" patterns. (I put "collaboration" in quotes for reasons that I hope will be clarified below.) You wrote (in your comments document): <Alain De Preter> Some constraints could be: . The sequence of messages must be one among several as described in the above picture. . The Invoice must have been sent maximum 2 days after the Order has been sent. . The ordered items contained in the Invoice must be the same as in the Order. . The quantities of Items in the Invoice must be less or equal to the quantities of the same items in the Order. </Alain De Preter> These are among the precise issues we are dealing with in a pattern that we are currently calling "Commitment-Fulfillment-Settlement". We are using William McCarthy's REA model (now included in the UMM Metamodel - Business Requirements View) to describe the semantic relationships among transactions and documents in this pattern. We want to describe the business semantics explicitly (instead of burying them in technical features of transaction models like time-outs). For example, a Commitment is a promise to execute some future EconomicEvent(s) to fulfill the commitment. An Order is a container for Commitments. The relationships between order items and fulfillment (e.g. delivery) items and quantities must be as described in your issues. Claims are much like Commitments, but stronger. A Claim is based on an unrequited EconomicEvent - e.g. a resource delivered but not paid for, or resources paid for but not delivered. Invoices are collections of Claims. Claims, like Commitments, have due dates and times, and other information model consistency issues as you outlined above. All of these fulfillment timing relationships can be managed by software, but see next paragraph: We think that all of these relationships can and should be explicited modeled. However, this modeling will not be complete in ebXML version 1.0, nor will the required technical facilities be present to use such models if available. So this is a job for some follow-on activity. It is not at all clear to me where such follow-on activity will take place, although there were many candidate organization suggested during the Vancouver ebXML meeting. My personal preference is for an international non-commercial organization. Now, back to the word "collaboration". While the word suggests UML Collaboration models, this association is misleading if you are thinking in UML terms. ebXML Business Collaboration Protocols are actually represented as UML Activity models. I suspect that the Activity model is actually more appropriate for representing the required semantics. A further note about the facilities of ebXML version 1.0: there have been attempts to define an implicit or explicit software protocol stack for ebXML. Certainly one can detect a Business Service level (transport & routing), and a Business Transaction level (handling the various transaction patterns defined in the UMM Metamodel Chapter 4), but the level of managing ebXML Business "Collaborations" and above has not been well-defined. While I understand the limitations of binary request- response transactions, they are a decent starting component, and are pretty well understood from practice. I believe strongly that larger configurations belong in a higher protocol layer, either Business "Collaboration" or "Process" management. In fact, there are several higher layers that will evolve (in my opinion): * "Collaboration" Management, handling order-fulfillment and similar relationships; * Process Management, handling long-term contracts and their relationships to periodic order-fulfillment patterns; * Something else to handle still-larger configurations: master agreements, community agreements, geopolitical and regulatory matters, etc. Lots of fun in the future! Thanks for the opportunity to send a message to such a distinguished list of addressees, hope nobody minded my "replying to all". Bob Haugen ebXML CC-BP-Analysis Group
Powered by
eList eXpress LLC