The Bundle Activator

An activator is the first point of contact for the OSGi framework after a bundle has been started (and, only if an activator exists!). Within its activator a bundle may register services with the OSGi service registry, or search the registry for required services (or both!). These processes will be covered in sections 3.9.4 and 3.9.5. The bundle activator is also called by the OSGi framework as the bundle is moved to the stopped state. This allows the bundle activator to perform operations, such as unregistering its services, or removing links to external services, ensuring that the bundle can leave the framework cleanly.

3.9.4 Registering Services

The OSGi registry maintains a list of services (or implementations of interfaces) along with a set of attributes of that service (as shown in Figure 3.14). For a bundle to register a service with the registry, it submits three items:

• An interface: This is a well known service interface which service users will know about in advance. In abstract terms, the service interface acts as the classification of the service.

• The service: As previously mentioned, the service is an implementation of a particular interface.

• A set of properties: Properties can be used to distinguish between services. For example, two services which implement a LightInterface can be distinguish

by the value of a Location property.

On submitting a service for registry, the OSGi registry assigns a service registra- tion, which acts as a unique reference for the service. This provides the providing bundle with a link to the service object within the registry. Service properties are largely left to the developer to define, as there is a lack of properties defined by the OSGi specification.

A bundle is able to register multiple services with the OSGi registry, and is responsible for notifying the registry when the service is no longer available.

3.9.5 Discovering Services

Within the bundle activator, a bundle can discover desired services within the frame- work by using the OSGi registry. To discover a service, the bundle submits an interface and property query to the framework. The interface is used to match im- plementations within the registry, with the property query used to further match suitable services to the query. In simple terms, the bundle asks the registry to ‘find a service which implements this interface and has these properties’.

Property queries are expressed using a Lightweight Directory Access Protocol (LDAP) syntax, which allows a more expressive form of querying, over simple prop- erty matching.

On discovering suitable matches, the registry returns a list of service references which correspond to services within the registry. The querying bundle can then select a reference from the list, and submit this reference back to the registry. The registry then provides the service to the querying bundle.

Bundles can place requests within the OSGi framework to be notified in the event of a particular service joining the framework. In this manner, bundles which offer multiple services can join the framework in stages. For example, a LightControl service provides a graphical user interface for controlling the lights within the home. As a new LightService joins the framework, the LightControl service can add a new light object to the interface.

Figure 3.15: Relation Between Services and Users

3.9.6 Using Services

As Java is an object orientated language, services are modeled as objects. When services are retrieved from the registry, the client bundle receives a direct reference to the service object. The service object may be shared between many bundles, as all users share the same implementation (see Figure 3.15). The client bundle interacts with the service by applying the service interface to the service object. In simple terms, this means the service client uses functions defined by the service interface.

As a service unregisters from the framework, service users are notified by a service event. This alerts the service user that the service reference is no longer valid, and should be discarded. In this way, services can leave the framework gracefully, ensuring references are stable and sound.

3.9.7 Scope of OSGi

OSGi is executed within a single Java Virtual Machine (JVM), along with all regis- tered bundles. This places a limitation on an OSGi framework, as all elements of a OSGi network can be susceptible to faults affecting the JVM, such as power failure and class loader errors.

Sharing a single JVM also limits all bundles to share the same implementa- tions of libraries. For example, suppose an existing bundle both offers and uses a LightInterface Java class. If a new bundle joins the framework with a new version of the LightInterface class, it will be unable to start as only one definition of the

LightInterface class can exist within the framework.

An OSGi-supported network can also be constrained by OSGi’s inability to fed- erate requests between all existing frameworks within the domain. Suppose two OSGi frameworks exist, one which contains entertainment services and one which contains home care services. Service A is contained within the first domain, and is designed to play background music when the user enters the living room. This service wishes to discover if any movement detection services are available. Move- ment detection services are located within the second OSGi framework, and are used by a number of home care services. Service A would be unable to discover these movement detection services, as it can only discover within it’s own framework. The OSGi frameworks are unable to share discovery requests between each other. This OSGi issue has attracted an amount of research and development to resolve. OSGI- R (r-osgi.sourceforge.net/) is one solution to this issue, but has yet to be integrated into the OSGi specification.

3.10

Jini

Jini is another Java-based architecture designed to support distributed computing [93]. The architecture is designed for complete management of the network, cov- ering the behaviour of both network management components and network clients. Network management components may also be distributed within the network. Jini was originally developed by Sun and has been transferred to Apache for future de- velopment and refinement[34]. Due to the well defined specifications, Jini has also found itself being applied within home network research projects [49]

3.10.1 Jini Clients

Clients within a Jini network can be said to be mobile. The code of which they comprise can be moved throughout the network. This is necessary, as each Jini client may be executing within its own JVM.

A Jini client can be a service provider, a service user or both. Jini service providers register their services with a service registry. This registry can be queried

by service users. Services take the form of service objects. These objects model the functions of the service. For example, a Clock service may provide functions for users to get the time, or set alarms.

3.10.2 Registering Services

Figure 3.16: Jini Registry Providing a Registrar

Figure 3.17: Copying The Service Object Into The Registry

The Jini architecture specifies a Service Registry architecture which is designed to handle all aspects of the discovery process. To register, a service provider first discovers the registry by either a unicast to a specific address (if the register address is known) or a multicast to the whole network. The multicast may result in more than one registry responding.

Once the provider has a reference, it obtains a Registrar object from the registry (see Figure 3.16). This object acts as a proxy to the registry, providing a local interface for the provider. The provider then passes a copy of the service object to the registrar along with a list of properties about the service. The registrar then

places the copied service object within the service registry (shown in Figure 3.17). The provider is then given a unique reference for the service.

Entry Objects

The properties submitted in a service registry take the form of Entry Objects. An Entry is a class which embodies a specific attribute, such as the location af- fected by the service, the developer of the service, or the manufacturer of hard- ware which the service controls. Encapsulating attributes within a concrete class allows for a more relevant matching of properties. For example, the service reg- istry would be able to differentiate between uk.ac.cs.stir.lsd.toaster.Location and uk.ac.cs.stir.lsd.gps.Location. Both properties describe a Location attribute, but the context in which it applies is different for each Entry object.

An Entry object simply contains a value, with the property name being identical to the classname of the object. The Jini architecture specifies a number of Entry attributes for describing services. Users can also implement their own Entry objects.

3.10.3 Discovering Services

The initial step of discovering services follows that of registering services. A service user must first find a service registry, if one is not already known. On contacting a registry, the service user receives a Registrar object.

Figure 3.18: Interaction Between the Registry and User

To discover services, a service user must construct a ServiceTemplate. This template requires a list of desired service types (defined by a service interface) and a

list of desired properties (defined by Entry objects). The template is then submitted to the Registrar, which queries the service registry. If a suitable match is found, a copy of the service object is passed to the service user. The interaction between these components is shown in Figure 3.18. As a Jini network can be distributed, the service user receives a copy of the service to execute within its own JVM.