A COHORTE application is composed of a set of components requiring and providing services. These components can be located in one node or dispatched between a set of nodes.
In a classical component-based frameworks, components are instantiated statically at a predefined locations. They are also configured to communicate together before starting the application. This leads to a situation in which a lot of configuration files should be managed or to recompile the components if the communication aspects are hard coded.
In contrast, COHORTE Components are instantiated, configured and placed in the right node automatically. There is no need to implement the distribution related aspects like serialization or client/server interaction. Components are seen as black-boxes wired by declared (remote) services.
Service Oriented Component Models (SOCM)
To implement COHORTE managed components, COHORTE supports two main, already existing component-based frameworks :
- Apache Felix iPOJO (Java)
- Pelix/iPOPO (Python)
If you are already familiar with one of the two frameworks, all whats you have to do in order to get your components managed by COHORTE is to not instantiate them (using
@Instantiate annotation or its XML equivalent). COHORTE will instantiate them automatically. To have benefits of Remote Services feature, your services should use primitive types instead of complex user-specific types.
The following picture shows a component requiring and providing services.
In this section, we will provide a brief introduction to the supported Service Oriented Component Models in COHORTE.
OSGi / Apache Felix iPOJO
iPOJO is a component-based service-oriented framework that works on OSGi platforms. Components in iPOJO are simple Java classes décorated with annotations to provide, require or define callbacks when the stat of the component change.
|Apache Felix iPOJO (Java)|
If your class provides several interfaces (services), you should specify which of them are exported as remote services or not.
By default, all the components instantiated using Cohorte are exported as Remote Services.
You need to explicitly reject the export of services by adding a provides service property:
IRemoteServicesConstants.PROP_EXPORT_REJECT as showed on the following example.
For more information about iPOJO, feel free to visite the official web site here.
Pelix / iPOPO
iPOPO is a python implementation, iPOJO like service-oriented component-based framework. It adds the missing modularity for Python projects.
iPOPO run on Pelix runtime (which is an implementation of part of OSGi specification on Python). iPOPO components uses decorators simular to those found on iPOJO, and could consume services implemented in Java using iPOJO component-model (using Cohorte’s Remote Services).
|Pelix iPOPO (Python)|
For interoperability between Java and Python components, we should add
java:/ prefix to the required services on Python components.
Partial support using IronPython.
Other legacy code
Wrapping in iPOPO (Python) or iPOJO (Java) components