Documents for metamodel meeting

[Karsten Riemer <Karsten.Riemer@East.Sun.COM>]

For the metamodel meeting at noon EST Tuesday, here are the documents we will
be reviewing. This represents a plan to create the hand-off layer between BP
and TP.

To access the call, dial 888-699-0348 domestically and +1 732-336-6000
internationally, with  a PIN of 7142#.

Thanks,
-karsten


Proposal for enhancement of FSV layer to create the "XML" layer.

The goal for this effort is to create a metamodel that:

1. Is the minimum, sufficient, subset of ebXML metamodel to drive TP
1.a. Minimum to drive business side of CPP (collaboration protocol profile)
1.b. Minimum to drive business side of CPA (collaboration protocol agreement)
2. Is the minimum, sufficient, subset metamodel to drive BSI (thru CPP)
3. Is fully compatible, and semantically compliant with the ebXML metamodel and supports
3.a. Modeling down through the BOM/BRV/BOV/FSV layers
3.b. Direct modeling at the "XML" layer
4. Has as simple as possible an XML representation, suppressing any parts of UML that are not directly part of the semantics of ebXML
4.a. Can be XMI or can be unambiguously generated via XMI
5. Enables edoc or other component architecture to generate/configure/execute the software that executes the b2b collaboration

The proposal is:

Retain (almost) all current classes of the FSV layer. Add a new class ServiceInteraction that is the FSV level reification of a CommercialTransaction. Add pre-condition based sequencing of ServiceInteractions. Add recursive and re-useable composition of such sequencing. You now have all the semantics (at the class level) needed to drive TP CPP (from ServiceTransaction) and to drive TP CPA (from ServiceInteraction). If we align names and slightly adjust semantics, we will also have a mapping to EDOC's Process Component Definition spec, with the option to extend the model into EDOC's Process Composition spec.

The opportunities for alignment are:

a. FSV reifies BOV, i.e. expresses structure and behavior of a commercial transaction and business collaboration model. That means that FSV has (most of) the semantics we need to capture.
b. OMG edoc is representing virtually the same set of semantics in its component model
c. An FSV service collaboration is a stereo type of UML collaboration
d. OMG edoc builds further on the UML collaboration to create 'connect-the-dot' collaborating components
e. BRV layer uses preconditions for sequencing business collaborations relative to each other, this sequencing is implicitly reified to BOV and FSV.
e. Mega/Excelon sequencing, when based on preconditions, accomplishes same semantics, but explicitly reifies it at "XML" layer. This allows modelers the choice of modeling these preconditions at a higher level, or directly at the "XML" level.
f. Modeling with preconditions only allows an option to bypass activity diagrams. Activity diagrams (or activity graphs) have been questioned and may be up for review at OMG.
g. Proposed sequencing provides recursive re-use of pieces of service collaborations
h. Proposed sequencing provides loose coupling, i.e. pointers ot other pieces of service collaborations, that may not even be ebXML expressions. (need to validate this)
i. Proposed new "XML" layer will be sufficient for an 'isolated' use of TRP/TP specs
j. Proposed new "XML" layer will enable us to sort out
   what parts are really TP
   what parts are really TRP


Notes on the proposed model:

We preserve the FSV semantics for ServiceTransaction, RequestionServiceTransaction, RespondingServiceTransaction, BusinessActionMessage,  BusinessSignalMessage, and all the relationships between them.
We introduce new class ServiceInteraction which is one RequestingServiceTransaction and one  RespondingServiceTransaction.
We then introduce a generic Interaction as the anchor point for both recursive composition and sequencing. An Interaction can be either an simple ServiceInteraction, or a complex ServiceInteractionProcess. 
A ServiceInteractionProcess is a set of ServiceInteractionRoles, each defined by an interaction, and sequenced relative to each other using pre-/post-conditions.
The use of ServiceInteractionRole enables you to re-use the same ServiceInteractions in multiple business processes, and to even have the same ServiceInteraction more than once within one process.
Sequencing is as follows:
Every ServiceInteractionRole has a set of pre-conditions that must be satisfied for this ServiceInteractionRole to be initiated.
A pre-condition can point to either other ServiceInteractionRoles or to a BusinessActionMessage, specifying the exact outcome of the previous interaction.
Post-conditions are really just statements of the expected state after the interaction, differentiated by the "postKind".
Ignore the "Role" for now.

jpeg

dtd_auto_file