4 Example of application: the generic remote command

When we use a remote command service we apply on one hand the principles described previously concerning deployment of services in an OSGi framework and on another hand exploitation of inherent services of the middleware Corba installed in an OSGi framework.

The generic remote command is built as an application allowing command of remote equipment installed in home local network through a home gateway (OSGi framework). The remote command service was installed on a PDA and it was implementing the command interface of a service present on a remote gateway.

As the application service is open , the remote command function remind itself open, so that is the significance of generic notion. The configuration ie the remote command (number and name of the command) can be programmed according to and by the remote controlled service.

The example presents the remote command application itself as a service of an OSGi framework, installed on a PDA. It controls through the middleware a video recorder present in a home network. This video recorder is connected to a HAVi network, where the management is assumed by another OSGi service, installed on a home desk computer (PC). We have here a typical example of communication between two OSGi gateways.

We describe below the communications steps involved between the remote command and a home HAVi service (video recorder management).

4.1 Service presentation

The HAVi service (video recorder management) is installed with two bundles on an OSGi home gateway:

the video recorder control service;
the remote command relay service.

On the PDA, where we find the remote command, are installed two other bundles:

the remote command with a graphical interface;
the video recorder control relay service.

4.2 Description of the communication mechanism

We assume this application works in scenario "Plug and Play". It is the video recorder control that appears in the home network (either it is just powered on or it is just installed in the framework etc). It will activate the exchange necessary to find a command interface service.

The sequence diagram (in Figure 8.5) presents the synchronous remote method calls between the different application services on the first part: remote command and video recorder, and the infrastructure services on the second part: trading and naming services.

Figure 8.5: Sequence diagram between video recorder (device) and the remote command. The diagram issue is an UML specification

The four steps of the scenario are:

Initialisation: each application service registers itself at the different infrastructure service, address of the naming service is assumed to be known beforehand.
Search of the complementary service of the remote command by the video recorder.
The active steps of the remote command.
Escape of the remote command by the video recorder.

This scenario assumes that the remote command is an available service. If it is not the case, the video recorder service can test steadily its presence or better it can register to the event service so as to be informed about apparition of the remote command service.

Finally all the services are supposed present (but not necessarily running) on their respective frameworks. Now, for reasons of place, updating or flexibility reasons, these services could be loaded on demand. Thus when starting a service it follows : registration at a naming service, then at a trading service and finally at loading service.