Component Based Architecture

As the CCM specification uses IDL for defining datatypes and interfaces, CORBA provides the natural means for implementing the RPC (remote procedure call) based communication between components using IDL defined interfaces.

As shown in Figure 1, CCM components defining synchronous request/reply ports (using or providing an interface over which to interact) would implicitly get either a CORBA (facet or provider) servant embedded or a CORBA object reference installed (at its receptacle). The component having the object reference installed at its receptacle uses this to send requests to the component providing the facet servant from which the object reference was obtained. Although simple and easy to use this tightly linked CCM component request/reply interaction with CORBA leaving no room for other transport options.
Essentially this approach integrated interaction pattern implementation with the business logic implementation of a component prohibiting substitution of interaction pattern implementations by simple component reassembly.

With the addition of the IDL extensions supporting Generic Interaction Support (GIS), the DDS4CCM specification, and the AMI4CCM specification the implementation of component interaction patterns itself became componentized.

Where the (synchronous) request-reply interaction patterns supported by basic CCM were implicitly implemented using CORBA, AMI4CCM and DDS4CCM specified a decoupled approach where business components connect using abstracted interface implementations to specialized connector components which implemented the actual middleware solution supporting inter process and networked interactions.
Figure 2 provides a diagram of the deployment of an asynchronous request/reply connection showing this solution.

In this setup the component (AsyncA) uses an asynchronous mapping for the defined interaction interface (Foo) that is locally connected to an implementation of that same asynchronous mapping provided by the connector (AMIFooConn). The connector in turn uses a middleware (CORBA in the case of AMI4CCM) specific asynchronous mapping of the interface to connect to a (remote) reference providing a matching asynchronous mapping implementation.
Using this connector model the (business) components become fully decoupled from middleware implementations and as connectors are components this makes middleware implementations substitutable.

In the case of the AMI4CCM implementation for (Lw)CCM the (remote) reference provider was still the implicit, non-connector, facet servant embedded in the (business) component (B in figure 2).
AXCIOMA however has improved on the original CCM model by consistently applying GIS and the connector concept throughout its implementation including the implementation of synchronous request-reply interaction. In AXCIOMA all middleware specific interaction pattern implementations are separated into connectors including synchronous CORBA based request/reply support. Figure 3 shows the deployment diagram for the synchronous and asynchronous component connections as they are implemented in AXCIOMA.

As shown in this figure, in AXCIOMA all user defined components are fully decoupled from specific middleware implementations supporting the interaction patterns and defined interfaces.

As (standard) connectors are fully automatically generated based on the IDL definitions for the interfaces and datatypes this decoupled setup does not add an additional burden on the application developers.

AXCIOMA comes with a selection of code generators and support libraries for various interaction pattern connectors such as:

Support for other connector implementations of the same interaction patterns (for example HTTP/REST based request/reply) or even other interaction patterns can easily be integrated into AXCIOMA as can custom specialized connectors (imagine for example connector implementations for a peripheral device that can be communicated with over either USB, serial or networked connections).