RE: Clarification on proposal

[Karsten Riemer <Karsten.Riemer@east.sun.com>]

Tony,
my statement about the WHOLE model was relative to the topic of the meeting,
namely the BP-TP hand-off layer. So the sentence should read "The WHOLE
metamodel for the hand-off is on the one diagram you saw". That differentiates
it from the other proposal which had a number of references to pieces of model
stored elsewhere.

-karsten


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