Re: Comments about thedocument"ebXML Business Process Specification Schema Version 0.90"

[Jim Clark <jdc-icot@lcc.net>]

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