Enterprise Collaboration Architecture

The first version of the Enterprise Collaboration Architecture (ECA) has been published by the Object Management Group (OMG) in 2001. The vision of the (ECA) is to simplify the development of component based and services oriented systems by providing a modeling framework aligned with the model-driven architecture (MDA) of the Object Management Group (OMG).[1]

The ECA thus provides a modeling framework for technology neutral business process design followed by implementation mappings onto the chosen architecture and technologies. It requires bi-directional traceability across the specification, implementation and operation.

The ECA specifies a set of UML models used to model different aspects (e.g. static and dynamic aspects) of the system and a set of viewpoints addressing different concerns (e.g. business, engineering, technology, ...).

## ECA models

[edit]

The ECA comprises four UML models:

1. the Component Collaboration Architecture,
2. the Business Process Model,
3. the Events Model, and
4. the Entities Model.

### The Component Collaboration Architecture (CCA)

[edit]

The Component Collaboration Architecture (CCA) provides a recursive decomposition and assembly of logical parts or process roles. These represent abstract role players which are ultimately mapped onto physical system components. ECA thus separates process roles from the physical process components realizing these roles.

### The Business Process Model

[edit]

The business process model defines the business processes across levels of granularity using compound task diagrams. A compound task coordinates lower level activities to perform a higher level activity. Process roles can be defined for activities. ECA defines the following three process roles

* Responsible party
* Performer
* Artifact

The ECA does not require the formal specification of services contracts for performers, but in most cases this would be encouraged.

### The Events Model

[edit]

The events model aims to support the specification of loosely coupled, event-driven applications. It defines

* processes with events in-flow and action out-flow, as well as
* entities with action in-flow and events out-flow.

### The Entities Model

[edit]

The entities model defines the structure of and relationships between business entities.

## ECA Views

[edit]

The ECA views are directly taken from the Reference Model of Open Distributed Processing RM-ODP:

* the Enterprise view : The enterprise view specifies the CCA, the processes, business entities and their relationships, the events leading to actions in a technology neutral way.
* the Computational view : The computations specification gets as inputs the enterprise specification and a set of mapping patterns and produces the computational specification.
* the Information view : The information view gets as inputs the entity specifications, relationships and a set of mapping patterns and generates the information specification.
* the Engineering view : The engineering view specifies abstract technology decisions like which components are to be network accessible, where messaging is to be used as integration channel and how entities are to be mapped onto persistent storage without specifying the concrete technologies to be used.
* the Technology view : The technology view specifies the mapping onto technologies like the component hosts (e.g. JavaEE, SOA/JBI, CORBA-CCM, Microsoft.Net, ...), concrete middleware providers, concrete persistence providers.

## See also

[edit]

* Enterprise Distributed Object Computing (EDOC)
* Model Driven Engineering (MDE)
* Model-driven architecture (MDA)
* Metamodeling
* Unified Modeling Language (UML)

## References

[edit]

1. ^ Interoperability for Enterprise Software and Applications: Proceedings of the Workshops and the Doctorial Symposium of the Second IFAC/IFIP I-ESA International Conference: EI2N, WSI, IS-TSPQ 2006. Germany, Wiley, 2010\. 111.

## External links

[edit]

* OMG ECA Specification