RE: Clarification on proposal

[Tony Weida <TonyW@EDIFECS.COM>]

Karsten,

Some thoughts on your note follow ...

> -----Original Message-----
> From: Karsten Riemer - Sun IR Development
> [mailto:Karsten.Riemer@East.Sun.COM]
> Sent: Thursday, November 02, 2000 1:55 PM
> To: ebxml-bp@lists.ebxml.org
> Subject: Clarification on proposal
>
>
> To those who attended this week's metamodel meeting:
>
> I wanted to point out that the proposal I presented (based on
> work by Jean
> Jacques and Antoine) represents a complete hand-off layer between
> BP and TP.
> It contains all the BP knowledge that TP needs. It is built
> directly around the
> current FSV layer, but it does not depend on pointers to several
> other layers.
> The WHOLE metamodel is one the one diagram you saw (reattached
> below). It seems
> like this point was lost because we started discussing the use of
> pre-conditions
> vs. some other form of sequencing.

<TW>
The BP team's metamodel is much more than that one diagram, and as a whole
it provides crucial context for modelling collaborations.  The attached
diagram is not "the WHOLE metamodel" at all; rather it partially
approximates and partially redefines/extends just a portion of the
metamodel.  In my view, it is obviously essential for ebXML to have exactly
one definitive specification for modeling business collaborations.  That
definitive specification should, of course, be the "Collaboration Modeling
Metamodel & UML Profile" (see
http://www.ebxml.org/project_teams/business_process/wip/).  Any changes that
may be required should be made in the metamodel, and should be made there
first.  Alternative representations, such as DTDs, should be derived (more
or less mechanically) from the metamodel.  To have changes originate in
various alternate representations is sure a recipe for confusion and chaos.

I would like to point out that having a hand-off representation ("layer") is
independent of the number of metamodel layers that it reflects.  Indeed,
multiple layers of the metamodel are inherent to the purpose of
collaboration protocol agreements -- they entail bindings of collaboration
specifications to specific technology choices.  The collaboration specs are
at the metamodel's FSV layer (as everyone seems to agree) and arguably at
higher layers (as some of us firmly believe), while technology choices are
clearly at the IFV layer.
</TW>

> I think that we should strive for this kind of a simple, but
> complete hand-off
> layer rather than a collection of pointers into the 4 layers of
> the current
> model.

<TW>
Collaboration protocol profiles and agreements should contain (or reference)
models of the relevant collaborations that are formed in TERMS of the
metamodel.  The goal is to accurately preserve the semantics of the
metamodel by using fully consistent structure and terminology.  That does
does not equate to "pointers".
</TW>

> A complete hand-off layer will also give us a single DTD for what
> minimally
> should be registered about a business process in the repository.

<TW>
A single DTD is fine, of course.  However, a single DTD is simply not the
result of a handoff layer.  (In fact, a single DTD can express the entire
metamodel, any entire model conforming to the metamodel, or any derivation
thereof.  Either automatic DTD generation via XMI or hand-generation of a
more human-friendly DTD would perfectly well produce a single DTD.)
</TW>

> This DTD is
> simple enough to support both the "thin" and the "thick" partner
> agreements, and
> will allow users to create simple business process definitions
> directly at this
> layer.
>
> If we can get agreement on that, then I am sure we can also
> quickly decide on the right sequencing mechanism within that
> hand-off layer.


<TW>
I believe everyone agrees that thin and thick agreements are desireable.  We
don't all agree on the question of layers, but I look forward to collegial
discussion and rapid resolution of that issue.  Unless I'm missing
something, (agreement on) the sequencing mechanism is entirely independent o
f (agreement on) thin/thick agreements and single vs. multiple layers, but
I'm hopeful that we can quickly reach agree on that too.

Looking forward to seeing everone in Tokyo!

Regards,

Tony Weida
Edifecs
</TW>

> thanks,
> -karsten
>
> ---------------------------------------------------
> Karsten Riemer,
> Director, Information Architecture,
> Enterprise Management Architecture Group
> Sun Microsystems Inc.,
> MailStop UBUR03-313
> 1 Network Drive,
> Burlington, MA 01803-0903
>
> ph. 781-442-2679
> fax 781-442-1599
> e-mail karsten.riemer@sun.com
>
>