Re: results of Boston F2F metamodel meeting

["Marcia L. McLure Ph.D." <marcia.mclure@mmiec.com>]

Thank you Bob for the overview of the Boston Meta-model meeting. Gaging from
your comments and the decisions that were made during the course of the
meeting, the issue resolutions were important and timely.

Thank you Karsten for a job well done and to all those meta-modelers
attending the meeting.

Best regards,

Marcia McLure


----- Original Message -----
From: "Bob Haugen" <linkage@interaccess.com>
To: "'ebXML-BP@llists.ebxml.org'" <ebxml-bp@lists.ebxml.org>
Sent: Monday, December 11, 2000 10:33 AM
Subject: FW: results of Boston F2F metamodel meeting


> 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
>
>
>