minutes from metamodel meeting

[Karsten.Riemer@east.sun.com]

Consider the attached four files the minutes of today's metamodel meeting.

-karsten
Minutes from metamodel meeting 2/27/2001

We covered the following topicmatter:

UMM update from TMWG meeting in Dallas.
Main SpecSchema issues:
     Document Model
     Document Transfer Model
     REA
     Multiparty Choreography
     Signal message set
     Pattern simplification

I will cover these issues in separate sections, even though there is overlap.

We agreed that we would try to state (in these areas, and probably others) what
we think is clearly in scope for 1.0. and what we see as migration paths towards 
a 2.0 and beyond.
Minutes from metamodel meeting 2/27/2001

UMM update from TMWG meeting in Dallas.

In the Dallas meeting Karsten, representing ebXML metamodel meeting and ebXML BP analysis teams, brought the following issues/concerns/questions for resolution against the UMM metamodel:

In summary the following was resolved by the TMWG in response to these issues/concerns/questions:

A. Agreed to drop the BusinessProcessActivityModel from the BOM layer of the UMM metamodel.
B. Agreed to merge the modeling element ObjectFlow with the modeling element DocumentEnvelope.

Other than that the issues/concerns/questions resulted no changes to the UMM metamodel, either because it was deemed by TMWG to be already addressed, or because of differences in opinion of how to resolve.


The detail of the TMWG discussions on the issues/concerns/questions follows:

1. Drop BSV layer, except message design, i.e. payload transformation rules
(That’s what UMM intro already says)
Resolution: Reorganize UMM document into BP modeling audience and BP Pattern Modeling audience
ActionItem: Get UMM and TP people together to map across.

2. Drop BusinessProcessActivityModel
(It has been identified as ‘historical artifact’)
Resolution: Drop the BusinessProcessActivityModel construct from the metamodel
Resolution: Add recursion to metamodel CollaborationProtocol
This resolution was subsequently determined by TMWQ to be already addressed by core UML metamodel, and not needing specific modeling in UMM metamodel. This leaves a specifically recursive ebXML specSchema mapping to an implicitly recursive UMM metamodel.
Related Proposal: Collapse BusinessProcess and BusinessCollaboration and call it BusinessCollaboration

3. Drop BusinessCollaboration Realization
(It is redundant?)
Resolution: What we are really looking for is a way to reflect that a business process can have some
Variance from domain to domain, variances from a generic usecase (Automotive flavor)
Issue: REA should be at generic collaboration, not just at realization (actually REA needs to be visible at all levels of the model, including BTV)
Counter resolution: Collapse, but use Collaboration, not UseCase

4. Change BusinessTransaction into a UML collaboration instead of a UML activity graph
SWIFT suggestion, 
Resolution: None yet, one faction wants collaboration, another wants state machine, SWIFT wants both

5. Simplify patterns: Drop AcceptanceSignal and Agent
Resolution: AcceptanceSignal should be optional
Resolution: Agent pattern is implied by employee role. Select employee pattern separate from 
transaction pattern.
Resolution: Look for a new term for agent that doesn’t conflict with economic/business agent
Resolution: Look for a new term for signal

6. Integrate the context based information model
Resolution: We need to invite (or await) core component context team
Issue: We need a generic approach to context based selection (REA, Process, Info)
Collapse object flow and document envelope
Resolution: yes, do it. DocumentEnvelope is a stereotype with base class object flow
Issue: can we have more than one documentEnvelope per response activity
Minutes from metamodel meeting 2/27/2001

Multiparty Choreography:

In response to issues #10 and #53 raised against v0.90:

Proposed changes for 1.0:

0.90 has the ability to transition from BusinessActivity to BusinessActivity within a BinaryCollaboration. All transitions are scoped to a given binary collaboration, in fact the transitions are "owned' by the BinaryCollaboration. Transitions are among BusinessActivities, that are either TransactionActivities or CollaborationActivities. So you can in fact transition from the use of one binary collaboration to the use of another binary collaboration, all within the scope of a higher level binary collaboration, provided the authorized roles are the same.

1.0. will support transitions from one BusinessActivity to another BusinessActivity across BinaryCollaborations, within the scope of a MultipartyCollaboration. The way we know it is within the scope of a MultipartyCollaboration is that the AuthorizedRoles of the 'from' BusinessActivity and the 'to' BusinessActivity  are both performed by the same BusinessPartnerRole. For example we can state that there is a transition from the 'CreateOrder' BusinessActivity of the 'Ordering' BinaryCollaboration to the 'ReleaseShipment' BusinessActivity of the 'Shipping' BinaryCollaboration. This is OK because  the 'Vendor' BusinessPartnerRole plays the 'Seller' role in 'CreateOrder' and the 'ShipReleaser' role in the 'Shipping' BinaryCollaboration. The semantics created is that upon completion of the 'CreateOrder' BusinessActivity between 'Buyer' and 'Seller' we will transition to the 'ReleaseShipment' BusinessActivity between the 'ShipReleaser' and the 'Shipper'. The transition belongs to the!
!
 BusinessPartnerRole called 'Vendor'. It is the 'Vendor' who upon completion of one role with one partner, turns around and performs another
role with another partner. 

A special flavor of this multiparty transition supports nested transactions. We could model that the 'CreditCheck' BusinessActivity is nested within the 'CreateOrder' BusinessActivity. The way to do this is to create the transition between 'CreditCheck' and 'CreateOrder'. The transition would again be owned by the 'Vendor' BusinessPartnerRole, but this time it would be marked as 'OnInitiation'=Yes. This means that upon initiation of the 'CreateOrder' we transition to the 'CreditCheck' BusinessActivity. The transition would happen after any acknowledgements but before the response. Then upon completion of the 'CreditCheck' we return and finish up the response of the 'CreateOrder'. This kind of nesting is always within a BusinessTransactionActivity, not within a CollaborationActivity.


Out of scope for 1.0, potential for 2.0 - where we are going:

There is still no transition mechanism among MultiPartyCollaborations, only among binary-collaborations within a MultiPartyCollaboration. Future would explore more complex transitions among multiparty collaborations, and more complex nestings within binary or multiparty collaborations, not just within a BusinessTransactionActivity.

Minutes from metamodel meeting 2/27/2001

REA:

In response to issues #9 and #11 raised against v0.90:

Proposed changes for 1.0:

v0.90 provides transitions between BusinessActivities within a BinaryCollaboration, but does not provide the ability to state pre- and post-conditions.

v1.0 will provide the ability to state a post-condition for a BusinessTransaction and a pre-condition for any BusinessActivity. We will state these pre- and postconditions in terms of EconomicContract and EconomicEvent.
This will enable us to state that a BusinessTransaction results in either an EconomicContract and EconomicEvent, but not in both.
It will also enable us to state that BusinessTransactionActivity or a CollaborationActivity requires the existence of EconomicContract in order to proceed.
The intend of design time validation is that in order to test that any pre-condition EconomicContract required by a certain BusinessActivity is actually the postcondition of a transaction referred to by a prior BusinessTransactionActivity in the same MultiPartyCollaboration scope.
To help make names of EconomicContract EconomicEvent types more consistent we suggest that the Core Components team develop a set of named standard EconomicContract and EconomicEvent types and provide them in a catalog similar to, and perhaps linked to the BP catalog.
The intent of runtime validation of these pre and post conditions are intended to be at the most at the level of validating that a document number is provided whenever an EconomicContract is either a pre- or a postcondition.
EconomicEvent instances should be assigned a transaction sequence number.


Out of scope for 1.0, potential for 2.0 - where we are going:

Out of scope for 1.0. is the use of REA to state the 'inside' protocol for a contract negotiation. While you in 1.0. will be able to say what EconomicContract governs the collaboration, and what EconomicContract results from the collaboration, you will not be able to state how that EconomicContract is built from commitments through a negotiation process.

Also out of scope for 1.0. is the automated interpretation of contract terms to govern the processing of an incoming request or reply.

Also out of scope for 1.0. is the management and monitoring of long running 'conversations', for instance the management and monitoring of a negotiation conversation.

Also out of scope for 1.0. is the management and monitoring of long running 'transaction' for instance the 'transaction' covering the placement of the order and the susequent fulfillment of the order.