3 A middleware solution based on Jonathan

The OSGi infrastructure architecture presented in the previous section offers infrastructure services accessible only in the execution space of the Java virtual machine. For example, a " trader service" that helps us to retrieve a service searches for it only in a local space of the framework. Thus it is impossible to retrieve a service that has not already been loaded and registered locally within the framework. This working hypothesis is justified when all the locally installed services are considered as an autonomous collection; it means that a set of the imported services is self-consistent.

Bearing in mind this last hypothesis, what happens if we try to make communication between several OSGi frameworks, or simply if the framework needs to deal with other communication functions different from the loading function? If we formulate this in terms of object language concepts, we need to express importation and exportation of the services (represented by their interfaces) between different OSGi frameworks (therefore between different JVMs). Thus, when we propose a middleware based on an ORB such as Corba or RMI, this technology will allow us to extend the local OSGi service notion to a distributed OSGi service notion. In fact we want to extend this approach and provide to each OSGi framework an ORB (Object Request Broker) which allows it to communicate with another framework.

We define two steps for this approach:

implementation of the infrastructure services needed to connect distributed applications;
definition of a typical architecture for distributed applications.

3.1 Implementation of an ORB service

If we decompose ORB services into elementary services, we have two sets:

A set of offered services:
- Synchronous or asynchronous remote method calls with parameters passed by value and/or reference.
- Management of object references.
- Management of naming spaces which provide a translation between a name and its object reference.
- Services related to trading, events, and memorisation are useful, but are considered to be additional services and are not strictly necessary.
A set of internal services, which are not exported since they are not usually part of an ORB but are rather part of an operating system (memory management, session management, multithreading management, protocol stack, etc). (http://www.objectweb.org) is an open source and provides the possibility to share services.

The first experiment considered the Corba personality of Jonathan naming service as OSGi services. As a result two new OSGi services are offered by the framework. They enable an application service to call another application service operating in a remote OSGi framework.

Figure 8.4: Service A and service B call an ORB to manage linking objects (proxy, relay, stub, skeleton)

Some remarks can be formulated concerning the introduction of an additional framework for managing the distribution of services:

Trading services are duplicated : one for the external services, and another for local services. Moreover, they provide identical functions; searching for services by their names and/or their properties. Their programmable interfaces are thus different.
Do we need a naming service by framework for all non-local services, or do we need only a simple relay (proxy) pointing to an external naming service?
Could we link the naming service and its relays in order to propagate the requests from one server to another so as to obtain the requested services?

In fact, all these combinations are suitable and correspond to several optimisations, each one taking into account physical constraints such as computing power, transmission speed and throughput, and memory size .

A relay pointing to an external naming service can be sampled, for example, by a mobile architecture with enough memory size, obtaining the address of the remote naming service during its connection. This service is then connected either by linking or directly to other services available in the network.
A local naming service can be illustrated by a PDA that register its self exported services. During a connection it allows accessibility to its internal services by exporting its own naming service.
On the other hand the linking in the importation mode of naming services to the PDA corresponds then to all the available external services.

3.2 Definition of an architecture for a distributed application

By exploration of different possibility to organise our naming service, according the same concern of homogeneity and to maintain the same approach, the other applications services will follow the same exploration. The built-in distributed application is organised on the basis of several services running in different frameworks. The criteria of the services distribution are not the aim of this paper, they take certainly into account an available resource optimisation function and notions like safe and security. In this paper only technical solutions are involved to ensure the distribution.

When we put a distributed application at disposal we start by the search of its compound services: this search can be extremely complicated depending on the number and the function of the services involved. It is anyway a complete research field to try to express the composition of services and to deal with request on compound services. Another service thus arise, the loader : all the services are not necessarily reached locally or remotely. This property leads to a dynamic configuration of the services: the configuration can be adapted according to criteria such as physical localisation, availability of the services. shared carrying, autonomy, breakdown tolerance, etc.

Finally the distributed application is in place. Some services are locally installed and other remotely installed, thus the application can be activated.

This architecture briefly described will be applied and integrated for the home gateway achievement on a PDA within the DIN project ie Cocooning . The principles of architecture design developed here will be applied to the communication between an OSGi home gateway, installed on a PC, and a PDA on which all the home gateway services can be reached dynamically through their interfaces. The PDA can then drive the different multimedia services of the "familibrary project" like video recorder, picture viewer, photolibrary, hifi device, TV etc. From this last described context we present in the next section a simplified example of application for pedagogical reasons.