OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: results of Boston F2F metamodel meeting

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC