You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

The dependency handler manages OSGi service dependencies. It allows a component to consume service without managing service discovery, tracking and binding. The handler manages all this interaction and injects required service in the component.

Dependency

What's a dependency?

A dependency represents a required service. Therefore, it manages the service lookup and the service binding. When an instance requires a service, the handler injects directly a service object inside a field, or invokes a method when a consistent service appears (or disappears). Dependencies have several attribute. A dependency can be:

  • Simple / Aggregate : the component can require one or several service providers
  • Mandatory / Optional : a component can declare an optional dependency
  • Filtered : a component can filter available providers

Dynamism & Instance Lifecycle

In OSGi?, services can appear and disappear dynamically. This implies dependencies can target a service that can appear or disappear dynamically.  So, dependencies need to manage this dynamism by tracking every time available service. At any moment, a dependency can be unresolved.  In the case of a mandatory dependency, the instance becomes invalid (an invalid instance is no more accessible externally, for example provided service are unpublished). If a service, resolving the unfilled dependency appears, the instance becomes valid. In consequence, dependencies affect directly the instance state, and must manage correctly the dynamics of OSGi to allow a complete unloading when a service goes away. As soon a mandatory dependency cannot be fulfilled, the instance is invalidated.

Dependency Injection Mechanisms

The handler manages two types of injections:

  • Field injection: a field contains the service object. As soon as the field is used, a consistent service object is injected. This injection type fully hides the dynamism
  • Method invocation: when a service appears, or disappears a method in the component is invoked. For each dependency, bind and unbind methods are used to allow the developer to manage the dynamism.

Moreover, the two injections type can be merged. A field will contain the value and 'binding' methods will be invoked.

Field injection

Imagine a Hello service with one method 'getMessage' returning a "Hello Message". The following component implementation can use this service by attaching this service to a field and by using the field:

public class HelloConsumer {
                private Hello m_hello;
                public doSomething() {
                               System.out.println(m_hello.getMesage());
                }
}

For this component, metadata could be:

<component classname="...HelloConsumer">
<dependency field="m_hello"/>
...
</component>

The metadata contains a dependency (representing the service dependency). This element has a field attribute. This attribute is the name of the field representing the service dependency in the implementation class. The implementation uses the field as a normal field without managing service interactions.

Method invocation

The second injection mechanism uses methods in the implementation class. By this way, the dynamics can be managed directly by the developer. Each dependency declares two methods:

  • A bind method called when a service appears
  • An unbind method called when a service disappears

These methods can have three signatures:

  • Without any argument: the method is just a notification
  • With an object of the required service: the object is the implicated service object
  • With an OSGi service reference: the service reference appearing or disappearing

The following component shows an example of implementation using this mechanism:

public class HelloConsumer {
  private Hello m_hello;

  public void bindHello(Hello h) { m_hello = h; }
  public void unbindHello() { m_hello = null; }
  public doSomething() { System.out.println(m_hello.getMesage()); }
}

For this component, metadata could be:

<component classname="...HelloConsumer">
<dependency >
    <callback type="bind" method="bindHello">
    <callback type="unbind" method="unbindHello">
</dependency>
...
</component>

Note, that the bind the unbind method can be have different signature. By using this mechanism, you need to be sure to manage the dynamism correctly.

(see note on type discovery)

Field injections and Method invocations

The two mechanisms can be merged together. In this case, the field receives the value before the bind method invocation.

The following component shows an example of implementation using this mechanism:

public class HelloConsumer {
     private Hello m_hello;

     public void bindHello() { System.out.println("Hello appears"); }
     public void unbindHello() { System.out.println("Hello disapears"); }
     public doSomething() { System.out.println(m_hello.getMesage()); }
}

For this component, metadata could be:

<component classname="...HelloConsumer">
<dependency  field="m_hello">
    <callback type="bind" method="bindHello">
    <callback type="unbind" method="unbindHello">
</dependency>
...
</component>

Injection mechanisms & lazzy object creation

IPOJO creates objects only when required. When needed, iPOJO invokes the constructor of the implementation class. The implementation class can use field dependency because values are already injected. However, method dependencies are called just after the constructor. If the service already presents, the invocation of the methods are delayed after the constructor invocation.

Some Examples

Simple Dependency

By default, a dependency is mandatory, non-filtered and simple (non-aggregate). The two previous examples illustrate this kind of dependency. When services goes away and appears, the service substitution is hidden.

Field attached to simple dependency points always a consistent service object. For a simple dependency, the bind method is called once time at the beginning. If the service disappear the unbind method is called. The bind method is re-invoked as soon as another service provider is available. If another service provider is presents when the used one disappears, the instance is not invalidated.

Aggregate Dependency

When a component requires several providers of the same service, it declares an aggregate dependency.

Aggregate Dependency with field injection

public class HelloConsumer {
     private Hello m_hellos[];
     public doSomething() {
            synchronized(m_hellos) {
                     for(int I = 0; I < m_hellos.length; i++) { System.out.println(m_hellos[i].getMessage());}
            }
       }
}

For this component, metadata could be:

<component classname="...HelloConsumer">
<dependency field="m_hellos"/>
...
</component>

To declare an aggregate field for field dependency, you only need to declare an array (instead of a simple type). IPOJO will create and inject the service object array.

Note: To avoid array modification during the loop, you need synchronized the block.

Aggregate Dependency with method invocation

public class HelloConsumer {
      private List m_hellos= new ArrayList();
      private void bindHello(Hello h) { m_hellos.add(h); }
      private void unbindHello(Hello h) { m_hellos.remove(h); }
      public doSomething() {
               synchronized(m_hellos) {
                     for(int I = 0; I < m_hellos.size(); i++) { System.out.println(m_hellos.get(i).getMessage());}
                }
        }
}

For this component, metadata could be:

<dependency  aggregate="true">
    <callback type="bind" method="bindHello">
    <callback type="unbind" method="unbindHello">
</dependency>

In this case, iPOJO cannot detect if the dependency is aggregate or not. So, you need to add the 'aggregate' attribute. The bindHello and unbindHello will be called each time a Hello service appears or disappears.

Note: To avoid the list modification during the loop, you need synchronized the block.

Optional Dependency (non-aggregate)

An optional dependency does not invalidate the instance if it is not resolved.

Optional Dependency with field injection

public class HelloConsumer {
         private Hello m_hello;
         public doSomething() {  System.out.println(m_hello.getMesage());  }
}

For this component, metadata could be:

<component classname="...HelloConsumer">
<dependency field="m_hello" optional="true"/>
...
</component>

To declare an optional dependency, you need to add the 'optional' attribute. To avoid null pointer exception, iPOJO injects a Nullableobject in the field when no service provider is available. The nullable object implements the service interface, but does nothing. For further information see the note about nullable object.

Optional Dependency with method invocation

public class HelloConsumer {
     private Hello m_hello;
     public void bindHello(Hello h) { m_hello = h; }
     public void unbindHello() { m_hello = null; }
     public doSomething() { if(m_hello != null) { System.out.println(m_hello.getMesage()); } }
}

For this component, metadata should be:

<component classname="...HelloConsumer">
<dependency optional="true">
    <callback type="bind" method="bindHello">
    <callback type="unbind" method="unbindHello">
</dependency>
...
</component>

As for field dependency, the dependency metadata needs to contain the optional attribute. IPOJO invokes the method only when a 'real' service is available, so you need to test if m_hello is null before to use it.

Aggregate & Optional Dependency

A dependency can be both aggregate and optional.

Aggregate & Optional Dependency with field injection

public class HelloConsumer {
     private Hello m_hellos[];
     public doSomething() {
        synchronized(m_hellos) {
           for(int I = 0; I < m_hellos.length; i++) { System.out.println(m_hellos[i].getMessage());}
        }
     }
}

For this component, metadata could be:

<component classname="...HelloConsumer">
<dependency field="m_hellos" optional="true"/>
...
</component>

To declare an optional & aggregate field dependency you need to write the optional attrbiute in the dependency metadata and to point on a field array. If no service available, iPOJO injects an empty array.

Note: To avoid array modification during the loop, you need synchronized the block.

Aggregate & Optional Dependency with method invocation

public class HelloConsumer {
     private List m_hellos<Hello> = new ArrayList<Hello>();
     private void bindHello(Hello h) { m_hellos.add(h); }
     private void unbindHello(Hello h) { m_hellos.remove(h); }
     public doSomething() {
        synchronized(m_hellos) {
               for(int I = 0; I < m_hellos.size(); i++) { System.out.println(m_hellos.get(i).getMessage());}
        }
     }
}

For this component, metadata could be:

<dependency aggregate="true" optional="true">
     <callback type="bind" method="bindHello">
     <callback type="unbind" method="unbindHello">
</dependency>

In this case, you need to add the 'aggregate' attribute and the 'optional' attribute. The bindHello and unbindHello will be called each time a Hello service appears or disappears.

Note: To avoid the list modification during the loop, you need synchronized the block.

Filtered Dependency

A filtered dependency applies an LDAP filter on service provider. IPOJO reuses OSGi LDAP filter ability. The following metadata illustrates how to use filters:

<component classname="...HelloConsumer">
<dependency filter="(language=fr)">
     <callback type="bind" method="bindHello">
     <callback type="unbind" method="unbindHello">
</dependency>
...
</component>

To add a filter, just add a 'filter' attribute in your dependency containing the LDAP filter. IPOJO will select only provider matching with this filter.

Note: to use the & operator in your filter, you need to use '&'.

Dependency Metadata

A dependency metadata:

  • Field : name of the field representing the dependency in the component class
  • Interface : type of the Field
  • Optional: is the dependency an optional dependency?
  • Aggregate: is the dependency an aggregate dependency?
  • Filter : filter selecting service provider
  • Callback : allow to call a method on the component instances when a service provider (matching with the dependency) appears or disappears

Some of these attributes are optional. Indeed, either the component implementation contains the information; either iPOJO uses default behavior.

The field attribute is optional if callbacks are specified. The field attribute contains the name of the field of the component attached with this dependency.

The interface attribute describes the required service. This element is optional because the component implementation contains the same information (the type of the field). If the interface attribute has a value, the consistency of the information is checked. However, sometimes this attribute is mandatory if iPOJO cannot discover the type of the dependency.

The optional attribute describes if the dependency is optional or not. An optional dependency is always valid, and does not interact with the instance state. On the other hand, when a mandatory is no more valid the component state becomes INVALID.

The aggregate attribute determines if the dependency needs to inject several providers on just one. This attribute is optional if the dependency point on a field array.

The filter attribute contains the LDAP request on the service provider. By default, iPOJO use no filter, but you can specify a filter. For further information, see the OSGi specification.

The callback elements contain the name of method to call when a service provider matching with the dependency appears or disappears. This allows the component to be notified when a service provider arrives or goes away.

Technical details on service discovery and service invocation

The handler of the registers an OSGi service event listener and listens for interesting events. When an interesting service arrives, it stores the service reference. When the service is used, it obtains the service object and injects the object in the instance. If it is an aggregate dependencies, it returns an array of service object or/and call the bind method for each provider.
When a service goes away, the handler removes the reference from its list (and call the unget method): the manager does not keep any reference on the old service. This allows a complete unloading of the service.
Two calls to a service can use two different service providers if the used provider has gone. IPOJO tries to return always the same service object if possible, since the service goes away.

Note about nullable object

The instance implementation can use an optional dependency without any checking. Indeed, when an instance declares an optional dependency using field injection, iPOJO create on the fly a Nullable class implementing the service specification but doing nothing (mock object). Therefore, iPOJO cannot return a service to the instance, for an optional dependency, it returns a nullable object.

A nullable object returns:

  • Null when the method returns an object
  • 0 when the method returns an int, log, byte, short, char, float or a double
  • False when the method return a boolean

You can check if the returned object is a nullable object with the test: _m_myservice instanceof Nullable._

Note about synchronization

When you want to be sure to have always the same service objects, you can use a synchronized block. It is useful for multiple dependencies. Indeed when you want to be sure that a service does not go away during the iteration on your array, you can put your loop inside a synchronized blocks.

Note about Callbacks

Dependency manages two type of callback: bind and unbind. A callback with a type "bind" is called each type that a service provider arrives and the binding is necessary. According to the cardinality of the dependency it means:

  • Simple dependency : at the firs binding and at each rebinding to another service provider
  • Aggregate dependencies: each time that a service provider arrives

An unbind callback is called each time that a used service provider goes away. For a simple dependency this method is called each time that the used service provider goes away. For a multiple dependency this method is called each time that a service provider goes away.

The method can receive in argument the service object or the service reference (in order to obtain service properties). The bind methods are delayed since a component instance is created.

Note on service type discovery

The 'interface' attribute is generally optional except when iPOJO cannot discover the type of the service. IPOJO cannot infer the type when the dependency has no field and no callbacks receive the service object in parameter. In this case, you need to declare the service interface.

  • No labels