Supported Service-Oriented Component models

Overview

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.

Supported SOCMs

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.

@Component("AggregatorFactory")
@Provides
public class Aggregator implements ITemperature {
  @Requires List<ISensor> sensors;
  @Requires IStore store;

  @Validate public void start( ) {
  /* Do something to regulate 
  temperature depending on room's 
  internal temperature. */
  }
}

If your class provides several interfaces (services), you should specify which of them are exported as remote services or not.

package org.example;

import org.osgi.framework.Constants;
import org.cohorte.remote.IRemoteServicesConstants;

@Component("AggregatorFactory")
@Provides(specifications = ITemperature.class, properties = {        
        @StaticServiceProperty(name = IRemoteServicesConstants.PROP_EXPORT_REJECT,
                type = "String",
                value = "org.example.IController") })
public class Aggregator implements ITemperature, IController {
  // ...
}

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).

@Component("AggregatorFactory")
@Provides("java:/Itemperature")
@Requires("sensors", "java:/ISensor", aggregate=True)
@Requires("store", "java:/IStore")
class Aggregator(object):
  def __init__(self):
    self.sensors = []
    self.store = None

  @Validate 
  def start(self): 
    """
    Do something useful to regulate 
    temperature depending on room's
    internal temperature.
    """
    pass

C# support

Partial support using IronPython.

Other legacy code

Wrapping in iPOPO (Python) or iPOJO (Java) components