[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Comments about thedocument"ebXML Business Process Specification Schema Version 0.90"
Bob, Alain and all, Bob reflects well the current structure and alignment of the metamodel and design patterns. I hope his explanation adds clairity to some of the issues. Best regards, Jim Clark I.C.O.T. Bob Haugen wrote: > 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 > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: ebxml-ccbp-analysis-request@lists.ebxml.org
begin:vcard n:Clark;James tel;cell:936.524.4424 tel;work:936.264.3366 x-mozilla-html:FALSE org:I.C.O.T. adr:;;10987 Quinlan N Lake;Conroe;TX;77303; version:2.1 email;internet:jdc-icot@lcc.net title:Principal Consultant fn:James Clark end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC