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. Next, you need to write a small description of your application components using the format explained hereafter.
Multi-platform discovery and transport framework
Supported protocols :
In this section, we will provide a brief introduction to the supported Service Oriented Components Models in COHORTE.
OSGi / Apache Felix iPOJO
|Apache Felix iPOJO (Java)|
Pelix / iPOPO
|Pelix iPOPO (Python)|
Interoperability between Java and Python implementation?
- We should add
java:/prefix to required services in Python.
Partial support using IronPython.
Other legacy code
Wrapping in iPOPO (Python) or iPOJO (Java) components