The development of large-scale, complex, distributed software systems places ever more strain on companies’ ability 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 development of complex distributed systems as described above. The full specification, however, proved too heavyweight for most common uses, so a slimmed-down specification was created, appropriately named Lightweight CCM (LwCCM). This version removes less commonly used features such as navigation and introspection while retaining the essential properties required for proper implementation of component-based systems.
AXCIOMA is an optimized implementation of the LwCCM specification that maximizes separation of concerns and reduces 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 and thereby completely decoupling business functionality from middleware and transport logic. By further reducing remote interface support requirements for components, AXCIOMA greatly reduces dependencies on CORBA middleware. In AXCIOMA, components are purely local objects by default.
In addition, AXCIOMA is based on the modern IDL to C++11 language mapping. This language mapping provides a much simpler and less error-prone programming API than the older C++ language mapping.
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.
Charles Darwin
Component-based architectures emphasize separation of concerns to maximize decoupling. Their approach is to define, implement, and compose loosely coupled, independent software components that interact using clearly defined interfaces and are arranged to construct a complete system.
Each component implements semantically related business logic organized in a separate entity.
Interaction with other components is achieved using strictly defined interfaces and data types.
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 or executes
function calls).
Because these interfaces are the only way to interact with the business logic implemented in the components, they
effectively shield the actual implementation details from all other parts of the system. The components
are said to encapsulate functionality.
Encapsulation and strict interfaces are key to another important property of components: substitutability. Because components rely only on certain key aspects of the defined behavior of other components and interact through strictly defined interfaces without depending on implementation details, replacing components becomes both feasible and straightforward. As long as a replacement component conforms to the expected (‘designed’) behavior and uses or provides the same interfaces as the component being replaced, the combined system should continue to function correctly.
For example, in the system depicted in figure 1, any implementation of the Thermostat component could be
combined with implementations of the other two components to deliver a correctly functioning system, provided that
the Thermostat implementation provided the specified Monitor interface for the Thermometer
component to use and used the Control interface provided by the Heater component. In addition, the
implementation would have to comply with the expected behavior of 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, 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 or using identical interfaces. Loose coupling and strict interfaces used to define interaction patterns between components allow for maximum reusability and adaptability.
Because the definition of a component relies on the interfaces used to interact with it, combined with its
expected (‘designed’) behavior rather than its implementation, another key feature of CBA is the
flexibility with which combinations of components can be composed into assemblies.
By selectively mixing and matching components, it is possible to create a reusable collection that can itself 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 into what can logically be viewed as a ClimateController
component providing a Settings interface and using a Control interface. 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 Thermostat and Thermometer components.
Like a single component, as long as an assembly conforms to the expected behavior and interacts through the
same interfaces, one implementation (composition) is interchangeable with another.
As figure 3 shows, it is even possible to redesign or extend an assembly and add components to create a more advanced version of the ClimateController assembly that remains interchangeable with simpler versions of the component assembly.
Encapsulation, strictly defined interfaces, substitutability, and assemblies make CBA an ideal solution for implementing software systems that are highly resilient to change.