FW: results of Boston F2F metamodel meeting

[Bob Haugen <linkage@interaccess.com>]

In today's BP-CC conference call, I was asked to forward
my summary of last week's metamodel face-to-face meeting.  
This is not the official summary, but the conference call attendees 
thought it was at least useful and probably not too inaccurate.

Short version:  I thought the meeting was a great success.
Karsten Riemer did a wonderful job setting the stage and
moderating.  The outcome was a resolution of most of
the disagreements that have been circulating around
the BP metamodel since before Tokyo.  In other words,
there will be only one unified metamodel, not two, and
there will be a simplified "infrastructure specification
schema" that is directly derived from the metamodel.

Here is a little more detail.

1. There was an executive decision in Tokyo to put out an early
"infrastructure" release of ebXML specs so that implementors
can get up and running.

2. The infrastructure release will contain business transactions
(previously named commercial  transactions) and very simple 
business collaboration choreography expressions.

3. The metamodel F2F group decided that a simple 
"infrastructure specification schema" (*not* a separate 
metamodel) could be defined based on the commercial 
transaction patterns - in other words, the transaction 
patterns  would be used as-is, and those would be the 
only transaction-level interactions supported.  

4. There were some metamodel changes made
but they were minor and were made both to the
foundation metamodel as well as to the specification
schema, so that the principle of one and only one metamodel
was preserved.

5. The biggest changes (in my opinion) were:
    a. FunctionalRole was renamed to AuthorizationRole,
        which also describes its semantics.
    b. A single BusinessCollaboration must be binary, that is,
        between two and only two AuthorizationRoles.
        (This is a CPA limitation in the infrastructure release.)
        Bill McCarthy and others think that all multi-party
        collaborations can be decomposed into related groups
        of binaries.
    c. BusinessCollaborations are now recursive or multi-level,
        and the higher-level BusinessCollaboration can have
        multiple parties and roles that map to the binary roles
        in the CPA collaborations.
    d. There was (I think) general agreement that there needs
        to be another CollaborationManager software layer
        to handle the more elaborate collaboration scenarios,
        and choreograph the multi-party collaborations.
    e. Any runtime support for metamodel levels beyond
       BusinessCollaborationProtocol (e.g. the BRV) will
       need to implemented in the higher-level CollaborationMgr
       software.  However, I think that all levels of the metamodel
       should be registerable and retrievable from registries.


Respectfully,
Bob Haugen