RE: Comments about the document"ebXML Business Process Specification Schema Version 0.90"

[Bob Haugen <linkage@interaccess.com>]

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