Metamodel narrative

[Bob Haugen <linkage@interaccess.com>]

Here is the promised draft narrative for the BP metamodel.
Consider this to be an experiment; it is incomplete.  
I'd like to get some feedback before going further.

Also, if this seems to work, I'll try a version with a
storyboard of metamodel class diagram excerpts.

Please advise if you think it makes the metamodel more
understandable, or if you have any suggestions for 
improvement.

In the narrative, metamodel classes are designated
by "camel" case, e.g. CapitalizedWordsMashedTogether.

I will frame the narrative in terms of the V2.0 metamodel,
although we may be simplifying the hierarchy somewhat,
which will simplify the narrative in some places.

_Overview_

The most common use of ebXML will probably be for
buyer and seller companies to exchange products 
or services for money.

In the ebXML metamodel, companies are Parties.
Buyer and seller are PartnerRoles.
Products, services and money are all EconomicResources.
Delivery of a product or service is an EconomicEvent.
Payment is another EconomicEvent.  Delivery and
payment are connected by Duality relationships.

While the exchange of EconomicResources is the goal,
there may be many preliminary InformationExchanges
leading up to the consummating EconomicEvents.

For example, purchase orders may be transmitted.
Purchase orders are Contracts in the metamodel,
and line items are Commitments.

In supply chain relationships, long-term Contracts
may be formed, with weekly or daily delivery schedules
(yet another type of Contract).

Information about offered products and services may
be exchanged: these are EconomicResourceTypes,
and may be presented in the form of a ResourceCatalog.

_BusinessTransactions_

Business is conducted in BusinessTransactions.

One Party plays a initiator PartnerRole (e.g. "Buyer")
in a BusinessTransaction (e.g. sending a purchase order).
Another Party plays a responder PartnerRole "Seller" and receives
the purchase order.

The BusinessTransaction consists of one InformationExchange
which in turn consists of two BusinessMessages:
1) the purchase order
2) acceptance of the purchase order.

A BusinessTransactionConstraint says that without the
acceptance, the transaction is not completed.  A rejection
message would abort the transaction.

If the purchase order is accepted, the BusinessTransaction
forms a Contract (the purchase order agreed to by both
Parties).  The purchase order line items become
Commitments (agreements by the Parties to execute
future EconomicEvents, e.g. the Seller commits to deliver 
some products, and the Buyer commits to pay for them).

_BusinessProcessDefinition_

The purchase order is not the end of the business process.
The Buyer wants to receive the products, and the Seller
wants to get paid.

So the BusinessTransaction of sending a purchase order
is one StepDefinition in a larger BusinessProcessDefinition.

The next BusinessTransaction would usually be product
shipment, which might consist of several InformationExchanges
sending BusinessMessages like Advanced Shipping Notice
and Confirmation of Receipt.

A BusinessTransactionConstraint might say which BusinessMessage
would result in the EconomicEvent of legal transfer of ownership
of the products.

...on to payment, returns, etc...

Respectfully,
Bob Haugen