Minutes of metamodel meeting

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

BP/CC Metamodel meeting minutes 11/27/2000

Attendees:

Bob Haugen
Bill McCarthy
Scott Hinkelman
Sig Handelman
Marty Sachs
Jim Clarke
Tony Weida
Paul Levine
Karsten Riemer
Cory Casanave
Lisa Shreve
Michelle Erwin
Nita Sharma
 
Agenda:

Discussion of two proposals for a 'specification metamodel', 
proposal 1 being the evolution of the work done in Tokyo (submitted by Karsten
Riemer, Cory Casanave, Antoine Lonjon, J.J.Dubray),  proposal 2 being a
profile of the 4 layer metamodel, consolidating the BOV and FSV layers
(submitted by Jim Clark, and Tony Weida).

Discussion:

Karsten stated that with proposal 2 on the table, a quick comparison seems to
indicate that the two proposals are quite close in scope, and in semantics,
but proposal 2 has some extra levels of modeling constructs relative to
proposal 1. Optimistically we should be able to merge the two models by the
December 6-8 face to face and joint BP/TP meeting in Boston.

Paul asked how proposal 1 supported the business service design patterns
submitted as an appendix to proposal 2.  Jim explained that the patterns
consist of two aspects, the type of interaction (notification, request/reply,
request/confirm, etc...) and the type of network component at either end
(service or agent) and that when you combine these two aspects you get the set
of discretely named pre-defined patterns.  Karsten stated that proposal 1
would support these patterns by having each commercial transaction (activity)
refer to the discrete name of the pattern desired, that pattern being stored
in the repository outside the discrete process definition. 

Paul pointed out that ebXML has changed the name of Commercial Transaction to
Business Transaction. Karsten will change this throughout proposal 1. Jim will
make public a new version of the .mdl for the 4-layer-model with that change,
too. Jim clarified that the word  CommercialTransaction still exists, but now
refers to an interaction pattern.

Karsten asked if proposal 2 was intended to support choreography of multiple
common business processes. Jim said it wasn't shown, but that at the BRV layer
you can establish collaboration patterns based on the REA semantics.

Karsten asked if the chaining of processes available in the BOM level could be
reified down to the consolidated level. Jim said that he was nut sure if this
layer needed to be able model that level of choreography.

Karsten asked about the relevance of the RequestingActivity/RespondingActivity
as discrete modeling elements when you can define a CommercialTransaction
directly in terms of its message exchange. Jim explained that the current
model relies on RequestingActivity/RespondingActivity in part as holders of
timing/security parameters, in part as a 'bridge' between the b2b interchange
and the process that goes on behind each of the fire-walls. Cory stated that
what is behind the firewall should not be specified as part of ebXML. Lisa
interpreted the named RequestingActivity/RespondingActivity as being
'instructions for a workflow engine'. Jim said that
RequestingActivity/RespondingActivity were also included in order to establish
legally binding contracts according to legal models around EDI. Cory stated
that legal contracts are between legal entities, not between processes. 
Karsten stated that it is possible to hold the timing/security parameters
directly at the commercial transaction level,
RequestingActivity/RespondingActivity are not needed for that reason.

Based on the discussion of RequestingActivity/RespondingActivity, Lisa asked
about the ability to choreograph based on events. Karsten stated that he
thought the REA modeling elements needed to be reified down to the
specification metamodel. Bill McCarthy said that could be discussed at the
Boston face-to-face. Jim felt that REA belongs at the BRV level and should not
be reified further. Cory asked how one would project REA onto a system
specification if it is only at BRV.

Lisa asked about an example of shipment notice being used for multiple
purposes. Someone stated that business documents can be re-used in multiple
processes, but if the purpose is different then separate commercial
transactions should be spefified. General agreement on this.

Lisa asked about common business processes that may have shared steps, but
each implementation could differ merely in sequencing, e.g. invoice before or
after shipment. This let to a spirited discussion about whether business
processes should be defined prescriptively down to minute sequencing, or
generically with room for choice. If room for choice then is that choice made
by BP or TP. Scott described a scenario where processes are defined in terms
of roles, and sequence choices were deferred to CPA creation time. Various
reactions to this. There was agreement that for now we should assume that
discrete business process definitions exists for each variation, and that TP
would not have to do any further specification. But to be open for further
exploration of Scott's idea we need proper focus on the "Role".

More discussion on choreography via prescriptive sequencing or event based.
General agreement that event based choreography provides more loose coupling.

Meeting concluded with a plan to have an XML discussion at next meeting. Jim
will provide an XML representation of proposal 2 by then.

Next meeting:

Tuesday December 5th, noon EST, call info to be announced