OMG Component Collaboration Architecture (CCA) & the BP Meta Mode l

[Cory Casanave <cory-c@dataaccess.com>]

While the BP Meta-Model group has been making great progress on the model
and UML representation, there has been similar activity going on within the
OMG.  The OMG activities come from the "Enterprise Distributed Object
Computing (EDOC) RFP effort, the "Enterprise Application Integration" RFP
and to some extent from workflow.  These activities are all sponsored out of
the OMG Analysis and Design task force, which is the group responsible for
the standardization of UML.   Virtually all of these efforts are being done
as UML "profiles", which use UML extension mechanisms to specialize UML for
specific needs.  The BP Meta Model is also using a UML profile approach.

Up until the last OMG meeting (Week of Sept 11) these efforts where somewhat
fragmented - two EDOC teams, multiple EAI proposals and another effort
starting for a workflow definition RFP.  The obvious concern is that these
areas are highly related if not, in some cases, addressing the same things.
I would include the ebXML work in this group of highly related things.

What happened at the last meeting was that a kernel part of one of the EDOC
proposals was recognized as a very general architecture for decomposition of
collaborating components - something that was addressed in each proposal in
a different way.  The hope was that this kernel could be extracted and made
a core part of EDOC, EAI and (eventually) workflow - bring these together.
This core piece was given the name "CCA" (Component Collaboration
Architecture) and has since been successfully culled out as an independent
document.  While this is still work in progress, there is a very good
feeling that this synthesis is succeeding.  It looks like it will be the
basis for joining the two EDOC camps and for integrating EAI.  Just last
night we had a phone meeting with the combined EAI group and confirmed this
direction.  While technical work still needs to be done, the companies
involved all feel this will work.  This involves a LOT of players, including
Sun, IBM, Oracle, Rational, Unisys, Schwab, Iona, Hitachi, CBOP and a lot of
smaller but influential companies like yours truly.  Given the level of
support and evolving consensus in the core group responsible for UML, this
will probably go through and may well become part of UML core in later
revisions.  One of the reasons for this level of support is that it is quite
easy to do the CCA integration, it is non-intrusive.

What this is leading to is that we have a golden opportunity.  What are now
divergent efforts in the OMG and ebXML can be brought together under a
common architecture that could provide a substantial leverage to the
industry and users.  It just makes no sense to represent the same semantics
in different ways, all under UML, just because it is the "XML camp", "UML
camp" , EAI Camp", "Corba Camp"...  By having a common way to model how
components collaborate, communicate and compose into business processes we
can bring these disciplines together.  Minor technology differences of how a
message is passed can be just that, and not require a different approach to
modeling business semantics.  The huge advantage of this is that the same
concepts and constructs are used at each level of a system.

CCA is intended to be specialized.  It provides a core architectural
foundation which is expected to be refined for specific purposes and various
levels of granularity.  It is not expected that it replaces the more
specialized profiles, but that it for a foundation for them.  By using the
same UML extension mechanisms, profiles are created for specific purposes.
We should take a careful look to see if the BP model can likewise use this
common foundation.  Note that CCA components are process related and not the
same as "core components" in ebXML.  Core components could use the CCA
"document" to model an ebXML component.

Many of the concepts in the BP Meta-model are virtually identical to
concepts in CCA, but use UML in somewhat different ways to express them.  In
addition to expressing the same or similar concepts, CCA provides the
linkage into "lower level" components within the enterprise, those that will
serve to implement the ebXML protocols.  Karsten has looked at this in some
detail and feels that CCA is particularly suited to the FSV layer in the BP
model and that this would be a relatively easy fit.  We don't think
embracing CCA would change ebXML semantics but only how they are rendered in
UML (CCA Uses both collaborations and activity graphs while the BP model is
mostly activity graph based).  So what we would propose that we take a
serious look at bringing these now diverse efforts together and do the
technical work to make it happen.  There are other parts of the BP model
that are not "CCA" at all, and would remain as is.

Many of the same companies are involved in  both efforts, in some cases the
same products.  Users will invariably use technologies from all of these
areas. Having to embrace divergent modeling paradigms within the same or
related products will add confusion, complexity, cost and delay.  We have
all seen this happen before.

The technical and political status of CCA is similar to the BP model.  It
has a good but not ready for publication specification and growing
consensus.  There is still time to feed ebXML requirements into CCA and to
bring this together.  We are ready to work with both groups to help make
this happen.   The CCA document is not officially public yet, but if anyone
from this group would like to review it - please email me.  A few people in
the BP group already have access and are part of the CCA workgroup.


Regards,
Cory Casanave
Data Access Technologies