Origin
The development of large scale, complex, distributed software systems puts ever more strain on the ability of companies to control development and maintenance costs. For that reason architectures that promote separation of concerns, loose coupling and reuse have been designed.
The OMG CORBA Component Model (CCM) is a component based architecture intended to improve the possibilities for development of complex distributed systems as described above. The full specification however proved too heavyweight for most common use and therefor a slimmed down specification was created appropriately named Lightweight CCM (LwCCM). This version trims down on little used features as navigation, introspection and such, but retains the essential properties allowing proper implementation of component based systems.
AXCIOMA is an optimized implementation of the LwCCM specification maximizing separation of concerns and reducing dependency on the traditional CORBA middleware technology underlying the original CCM specification. The Generic Interaction Support (GIS) introduced for LwCCM with the DDS4CCM (DDS for Lightweight CCM) specification is consistently applied in AXCIOMA resulting in a common connector model for interaction pattern implementations thereby completely decoupling business functionality from middleware/transport logic. By further reducing remote interface support requirements for components AXCIOMA greatly reduces dependencies on the CORBA middleware. In AXCIOMA components are by default purely local objects.
In addition AXCIOMA is based on the modern IDL to C++11 language mapping. This language mapping provides a far simpler and less error inducing programming API as the older language mapping for C++.
Component Based Architecture (CBA)
It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change.
Component based architectures emphasize separation of concerns to achieve maximized decoupling. Its approach is to define, implement and/or compose loosely coupled independent (software) components that interact using clearly defined interfaces and arrange these to construct a complete system.
Each component implements some semantically related business logic organized in a separated entity.
Interaction with other components is achieved using strictly defined interfaces and datatypes.
The interfaces one component needs to transfer information to another component are
called provided interfaces for the component on the responding (receiving) end of the communication
and used interfaces for the component that drives the communication flow (sends information, executes
function calls).
As the interfaces are the only way to interact with the business logic implemented in the components this
effectively shields the actual implementation details from all other parts of the system. The components
are said to encapsulate functionality.
The encapsulation and strict interfaces are key to another important property of components which is substitutability. As components only rely on certain key aspects of the defined behavior of other components and interact over strictly defined interfaces without dependencies on actual implementation details it becomes completely feasible and even easy to replace components. As long as a component replacing another component conforms to the expected ('designed') behavior and uses or provides the same interfaces as the component being replaced the combined system should keep functioning without a problem.
For example in the system depicted by figure 1 any implementation of the Thermostat component could be
combined with an implementation of the other two components to deliver a correctly functioning system as
long as the Thermostat implementation provided the specified Monitor interface for the Thermometer
component to use and used the Control interface provided by the Heater interface. In addition the
implementation would have to comply with the expected behavior for the component which would most likely
involve controlling the heater to raise or lower the temperature according to the ambient temperature
reported by the thermometer.
In general it can be said that any component can be replaced by another component providing similar functionality through identical interfaces. Alternatively, any component can be rearranged to interact with different components providing and/or using identical interfaces. Loose coupling and strict interfaces used to define the interaction patterns between the components allow for maximum reusability and adaptability.
Since the definition of a component relies on the interfaces defined to interact with it combined with it’s
expected ('designed') behavior rather than it’s implementation, another key feature of CBA is provided through
the flexibility with which combinations of components can be composed, named assemblies.
By selectively mixing and matching components it is possible to create a reusable collection that itself can be viewed
as a component. Such a collection is called an assembly.
Figure 2 shows a component diagram with a component assembly composed of the Thermostat and Thermometer
components from the previous figure. These are combined in what can be logically viewed as a ClimateControler
component providing an interface Settings and using an interface Control. From the viewpoint of this
component assembly the Monitor interface has now become an implementation detail.
Multiple compositions of ClimateController assemblies could be made available based on different implementations
of the constituent components Thermostat and/or Thermometer.
Like a singular component, as long as an assembly conforms to the expected behavior and interacts through the
same interfaces one implementation (composition) will be interchangeable with another.
As figure 3 shows it would even be possible to redesign/extend and add some parts and create a more enhanced version of the ClimateController assembly that still remains interchangeable with simpler versions of the component assembly.
Encapsulation, strictly defined interfaces, substitutability and assemblies make CBA an ideal solution to implement software systems that are highly resilient to change.