designing an extension api for bridging ginga idtv applications and home services

V. F. de Lucena Jr. et al.: Designing an Extension API for Bridging Ginga iDTV Applications and Home Services 1077

Contributed Paper Manuscript received 06/27/12 Current version published 09/25/12 Electronic version published 09/25/12. 0098 3063/12/$20.00 © 2012 IEEE

Designing an Extension API for Bridging Ginga iDTV Applications and Home Services

Vicente Ferreira de Lucena Jr., Member, IEEE, Nairon Saraiva Viana, Orlewilson Bentes Maia, João Edgar Chaves Filho and Waldir Sabino da Silva Jr.

Abstract — This paper presents the implementation process

for an API that integrates interactive digital TV (iDTV) applications and home network (HN) services, mainly concerning issues of the Brazilian iDTV model. The research in this field is important because it represents current trends on the use of iDTV opening many business opportunities. With the convergence of service providers, modern communication technologies and consumer electronics devices at home, new iDTV applications have emerged, particularly those that use the set-top-boxes (or digital TV sets) processing power to provide additional services, which extends the possibilities of interaction between the user and the connected home. To implement this platform, a known model, which considers aspects of the Ginga middleware and the Open Services Gateway Initiative (OSGi) framework, was used. The idea behind the API model is to export service objects from one side to another, allowing the development of two types of applications: the first one on the Ginga-J machine and the last one on the Ginga-NCL machine. The main goals of this paper are (i) presenting the use of free tolls to perform such integration and (ii) showing the most relevant aspects in the core of the two models. Finally, a basic step-by-step process is shown in order to build integrated iDTV-HN real applications using this platform.1.

Index Terms — interactive Digital TV, Home Gateway, Ginga Middleware, OSGi.

I. INTRODUCTION

Since the digital TV started providing interactive services, the amount of applications and possible uses for this device have been evolving, following an ever-growing technological convergence and the need for offering innovative services to the home users. This trend has been established throughout recent years, mainly supported by the increasing evolution of high speed and broadband networks as well as the more powerful generation of consumer electronics devices. The role

1 This work was supported by the following funding institutions: CAPES

(Coordenação de Aperfeiçoamento de Pessoal de Nível Superior), CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico) and FAPEAM (Fundação de Amparo à Pesquisa do Estado do Amazonas).

Vicente Ferreira de Lucena Junior, João Edgar Chaves Filho and Waldir Sabino da Silva Junior are with the Electrical Engineering Graduate Program at the Universidade Federal do Amazonas (PPGEE-UFAM), and CETELI, Manaus, Brazil (e-mail: {vicente, jo_edgar, waldirjr}@ufam.edu.br).

Nairon Saraiva Viana and Orlewilson Bentes Maia are Ph.D. students with Universidade Federal de Minas Gerais (PPGEE-UFMG) and also with CETELI-UFAM (email: {nairon_viana, orlewilson_maia}@ufam.edu.br).

of a consumer electronic device is highly expanded when it has some connectivity, either with the outside (through the Internet) or the inside of the user’s home (through the Home Networ - HN) [1].

The Interactive Digital TV (iDTV) evolution, regarding the technological convergence process, started with tests of applications that merged services from various providers in a single interface; after that, the connectivity TV/Internet led to the internet protocol television (IPTV); and finally, the integration with mobile devices improved the potential of the iDTV services [2]. Currently, this trend can be extended considering the strong potential of the digital TV receivers (Set-Top-Boxes, STBs) to provide an automated environment for sharing multimedia content [3], or to perform control and monitoring activities using such devices [4].

This idea of extending the connectivity of iDTV through home has been discussed in several papers lately, which considered some issues for making it possible to converge iDTV and a computing device fit for the purpose of centralizing all the services offered to other devices at home. This key device is commonly named home gateway (HG). The iDTV, whenever used as an HG, brings to the market new services and new business models. It makes possible to use services from several devices or service providers in such a way that the interaction with a device, or a service, becomes a part of the interactive process of the watching TV experience (see Fig. 1). The iDTV-HG integration is implemented by means of some collaboration mechanism, using the standard technologies available for each domain.

Fig. 1. Delivering diverse content to home devices through a single iDTV-HG platform (Adapted from Dixit and Prassad [5]).

1078 IEEE Transactions on Consumer Electronics, Vol. 58, No. 3, August 2012

Several previous works have published studies of such mechanisms [6]-[16], creating new protocols or using existing standards either for iDTV applications (Multimedia Home Platform, MHP [17], Advanced Common Application Platform, ACAP [18], and Ginga Middleware [19]), or for services at home (Open Services Gateway Initiative, OSGi [20], Universal Plug and Play, UPnP [21], Jini framework [22]), providing an environment for creating composed applications that explore the features of those platforms.

A general classification that covered some relevant aspects of the existing works from 2001 to 2009 [13], considered a set of elements: iDTV standard-based; Home Network standard-based; and Collaboration between both platforms. These categories reflect the way an iDTV-HN interaction occurs in the home where an iDTV and an HG could either have separate architectures, communicating through the network or they could be a single device, receiving both the iDTV stream and the requests from service providers to the HG. A similar classification is performed by Lin et al [12], which designed some of these architectures in order to make a qualitative and quantitative comparison among them, considering issues like resources consumption, loading time, startup time, etc.

In face of these known strategies, and considering the current moment being lived in Brazil, i.e., the evaluation and consolidation phases of its middleware specification (named Ginga), it would be useful to consider approaches that use Ginga’s capabilities to provide new mobile and ubiquitous services. Indeed, there are few works that deal with this topic, for example, there is an iDTV-HG isolated communication architecture for monitoring an XML-based sensor’s network that solves some integration problems [23]. Recently, some works have proposed a Ginga-OSGi collaboration approach under the procedural and declarative perspectives [13]-[14].

In the first version of the Ginga specification, the trend was to incorporate a proper support for communicating with other devices. The procedural specification (Ginga-J [24]) pointed out this question, presenting a specific API. Regarding the Ginga-NCL middleware [25], there is a multi-device support API, which is applied mainly for sharing multimedia content between iDTV and mobile devices [26]. Nevertheless, these middleware extensions are still in the evaluation stage.

Finally, Viana and Lucena Jr. [16] proposed improvements in their previous works [13]-[14] presenting a new model and describing the implementation of a collaboration strategy that allowed Ginga-J and Ginga-NCL to exchange service objects with OSGi in an iDTV-HG common environment. These works offer to the developers some mechanisms for deploying services at the home network through procedural and declarative applications.

The present work is an extension of the proposal presented by Lucena et al [15]. Here, the main mechanisms that allow the building of Ginga-OSGi platform are detailed considering the issues of their implementation. Thus, along this paper it will be explained how to join the reference implementations for iDTV and HG software platforms in a single consumer

electronic device, and how to build integrated scenarios on this platform, following a step-by-step method.

This paper is organized as follows: in section II, an overview of the implemented model is presented. In section III details about the used tools and the internal process for constructing the procedural and declarative bridge components are described (based on exchanging service multimedia objects between Ginga and OSGi). Section IV illustrates a simple process for building convergent Ginga-OSGi applications. Finally, in section V, the main characteristics of the platform are reviewed and possible improvements to be undertaken in future works are presented.

II. OVERVIEW OF THE GINGA-OSGI MODEL

In this section the Ginga-OSGi components that make part of the procedural and declarative environments are briefly presented. The main elements of the software integrated environments and their relationship are presented in the Figs. 2 and Fig. 3. The fundamentals that led to this model were previously explained by Lucena Jr. et al [15].

Fig. 2. Components that make part of the GingaJ-OSGi model.

As depicted in Fig. 2, the procedural model provides

components implemented at the iDTV side, the HG side and the bridge elements. XletContextExporter and BundleContextExporter are context exporters for the ContextBridge in their respective domains. The main idea is to define a generic object (WrappedProxyObject) within the bridge API, which represents the two kinds of interfaces to be exchanged between the domains, i.e, an interface from Ginga-J IXC Registry to OSGi Service Registry or an OSGi service to be exported to Ginga-J IXC Registry. The GingaJ-OSGiRegister, GingaJ-OSGiBundle and OSGi-GingaJRegister were constructed for supporting the service objects exchange.

In Fig. 3 is presented a simplification of the declarative GingaNCL-OSGi model. The main feature of this model is allowing the control of home devices using a declarative programming language. As in the case of the procedural model, there are two interaction mechanisms, now supported


by five components (see Fig. 3): ContextBridge for storing context objects of BundleContextExporter and to allow accessing OSGi from a Ginga-NCL request; GingaNCL2OSGiAdapter, which is a Ginga-NCL specific component that was re-implemented in order to parse NCL content that will invoke some OSGi service; and finally, OSGi2GingaNCLBundle and OSGi2GingaNCLAdapter, which are in charge of guaranteeing the access of a Ginga-NCL property by the OSGi side.

Fig. 3. Components that make part of the GingaNCL-OSGi model.

Building these two models brings new possibilities to

deliver useful convergent applications. However, for a better understanding of the whole model, some issues related to the communication mechanisms must be considered. The goal is to show how each platform was modified and in which hardware/software platform they were built. These topics are important, because although the conceptual model is apparently simple, the implementation requires considering technological knowledge. Indeed, one relevant feature is that the bridge API is easily constructed without modifying Ginga or OSGi core components, and the process for building collaboration scenarios is quite simple.

III. DESIGNING THE PLATFORM

The focus of this section is to detail how the infrastructure was built, and how the two extended APIs were designed, regarding the interaction mechanisms between middleware and framework. This basically means: how Ginga-J and/or Ginga-NCL applications are exported to OSGi and how OSGi services are delivered to Ginga-J applications and Ginga-NCL scripts.

For both domains, prototypes were built in a PC-based platform with the following configuration: single processor 1.3GHz, 512MB RAM, 80GB HD, with WiFi, RS-232 serial and USB interfaces. The operating system runs Java 2 SE 1.4.2_17, 1.5.0, and 1.6.0_07. The XleTView 0.3.6 emulator was used to represent Ginga-J environment, in which two main features were added: Inter-Xlet Communication (IXC) support, through the use of the Java CDC Personal Profile [27] and a model for dealing with the listening mechanism for

the registry of service objects on the IXC. The Knopflerfish 3.3.6 was used as the OSGi service manager.

Once registered in the OSGi, the services must be exported to the Ginga-J as Xlet remote objects, (using the platform components in the tvdihn.* package). In the Ginga-J environment, the Application Manager uses the system API (havi, javatv, cdc personal profile, nanoxml) to control the Xlet execution (using microedition.xlet.* components), which can register java.rmi.Remote objects in the IXC Registry (using xlet.ixc.IXCRegistry package). A listening mechanism ensures the exporting of ICX Registry objects to the OSGi. It is important to say that the API’s for graphical interface such as home audio video interoperability (HAVi) and digital audio video council (DAVIC) are not present in the Ginga-J middleware (they were replaced by the JavaDTV model and LWUIT APIs [28]) but they were used in this project because of the MHP nature of the adopted Java iDTV emulated environment (XleTView). In spite of that, as they are graphical components, they do not interfere in the GingaJ-OSGi functional components.

The GingaNCL-OSGi API uses, besides the OSGi Knopflerfish, the Ginga-NCL emulator, a Java-based Ginga-NCL reference implementation. In this environment, it is possible to parse NCL scripts for media presentation (audio, video, html, etc.) and to execute procedural content based on the LUA language. Despite other available tools for Ginga-NCL programming, the Ginga-NCL emulator was specially chosen because it makes the integration with the OSGi environment easier, both executing on a single Java virtual machine (JVM).

A. Designing the GingaJ-OSGi API

The seven components of the GingaJ-OSGi platform can be organized according to their functions: four are common core components, which means they are part of the two interaction mechanisms; one provides the support for exporting OSGi services to the Ginga-J IXC Registry (the Ginga-J-OSGi way) and the last two are in charge of guaranteeing the use of Ginga-J entities (interfaces in the IXC Registry) in the OSGi domain (the OSGi-Ginga-J way). They are described, in this order, in the following.

Common Core Components

The components of the procedural platform are placed in the tvdihn.* package. In the main group is found the ContextBridge, which exports context objects to the environment. When accessing a ContextBridge, an Xlet can retrieve a service in the OSGi Service Registry and a Bundle can access a remote object in the IXC Registry. In the entire system there is only one instance of ContextBridge. The XletContextExporter is an Xlet installed on the platform that passes its context to the ContextBridge, and BundleContext is an OSGi Bundle that when started, passes its context to the ContextBridge. The ContextBridge initialization is done when invoked by startXlet and start methods from XletContextExporter and BundleContextExporter respectively.


In the functional group tvdihn.wrapped, the central components of the model are the WrappedProxyObject and WrappedInterface. The former represents a service defined as a generic object to be exported between the two domains: it could be a service from OSGi to Ginga-J or a Ginga-J functionality to be registered as an OSGi service. The main function of this generic object is to protect the direct access to the object it represents. Thus, WrappedProxyObject is an implementation of the Proxy and Decorator design patterns [29]. The later component is an interface for the generic object.

The WrappedProxyObject uses three additional components to store service object information: java.lang.Object object (related to the service object), java.reflect.Method method (an object that represents a method to be invoked in the service object) and java.lang.object.Object methodObject (the result of the invocation of method). These components work together in order to guarantee the protection of the service object. For example, consider a service object passed to the WrappedProxyObject as an OSGi printing service, represented by a Printer object with the method java.lang.String print (String filename). In the WrappedProxyObject, the object is associated with Printer; method is associated with String print and methodObject is the returned object.

The last group of common components is located in the tvdihn.listeners package, which presents classes for creating a listening mechanism for events in the IXC. This choice is important because it allows registering Ginga-J remote objects from the IXC Registry to the OSGi Service Registry. The main classes of this group are IXCEvent, which represents three types of events: BIND (when an Xlet registers a remote object), UNBIND (when an Xlet unregisters a remote object) and REBIND (when the remote object is updated); IXCListener, which in fact is a listener to IXC events; and IXCListeners, responsible for storing all existing IXCListener objects.

GingaJ-OSGi Component

The OSGiGingaJ-Register (see Fig. 2) is the only component related to this way of interaction. It is implemented as one OSGiGingaJRegister class in tvdihn package. To implement its function, the OSGiGingaJRegister has a listening mechanism for service events on the Service Registry, using the org.osgi.framework.ServiceListener component. Once a service registration is detected, the related object is passed to Ginga-J through ContextBridge and WrappedProxyObject, following the WrappedProxyObject mechanism.

OSGiGingaJRegister has three main functions: catch OSGi service objects, register these objects in the Ginga-J IXC and remove the objects from the IXC. The first function is carried out using a standard OSGi element, the ServiceEvent, which represents three types of service events in the Service Registry: REGISTERED (one service has been registered), UNREGISTERING (one service has been removed) and MODIFIED (some service properties were changed).

When the service object is retrieved, the OSGiGingaJRegister checks the following service properties through a LDAP [30] query: SERVICE_ALIAS = "HOME_NETWORK_ALIAS" and SERVICE_TYPE = "HOME_NETWORK_SERVICE". If it does not match, the service is invalid and it will not be exported to the IXC Registry; otherwise, the OSGiGingaJRegister will execute the second function, i.e., register the object in the IXC. To do so, the service object is initialized (using a Bundle context from ContextBridge), passed to WrappedProxyObject, and then the IXC Registry is invoked (using an Xlet context from ContextBridge) through the IXCRegistry.bind operation. An alias for identifying the object is retrieved from the OSGi service, using the SERVICE_IXC_ALIAS property. This process is illustrated in Fig. 4.

Fig. 4. OSGiGingaJRegister: code for registering an OSGi service as a Ginga-J remote object.

The last function of the OSGiGingaJRegister is the reverse

process, i.e., removing the IXC remote object from IXC Registry, when a service is uninstalled from the Service Registry. This is done by verifying the UNREGISTERING event, using the service properties to search for the corresponding object in IXC and then performing an IXCRegistry.unbind operation.

OSGi-Ginga-J Components

Regarding the process of registering remote objects from the IXC Registry (in the WrappedProxyObject format) to the OSGi Service Registry, the following components are involved: GingaJ-OSGiRegister and GingaJ-OSGiBundle, both configured in a single Bundle, BundleGingaJOSGiRegister, in the tvdihn package.

The component GingaJOSGiRegisterActivator activates the BundleGingaJOSGiRegister. It implements a listener for events on the IXC Registry (through the IXCListener object in tvdihn.listeners). The main functions of GingaJOSGiRegisterActivator are capturing the IXC remote object, registering and removing this object from the Service Registry. The GingaJOSGiRegisterActivator deals with registering/unregistering of service objects in a different way from OSGiGingaJRegister; in the OSGi domain, there is only


one service, GingaJOSGiService, which maintains an object repository related to all IXC remote objects from Ginga-J. The GingaJOSGiService can be accessed by Bundles that need to use functions of an IXC remote object. For each IXC remote object there is a corresponding WrappedProxyObject stored in the GingaJOSGiService repository.

The fact of registering only one service through GingaJOSGiService demanded a mechanism to store all the references to the WrappedProxyObject that came from Ginga-J. In the absence of such a repository managed by GingaJOSGiService, every time a WrappedProxyObject was registered, it would overwrite the previous object, thus losing its reference. To overcome this difficulty a service repository was added to BundleGingaJOSGiRegister.

The mechanism begins when GingaJOSGiRegisterActivator detects an IXCListener.BINDED event. After that, the instance of the IXC remote object is retrieved (using the IXCEvent component) and passed to the initialization of a WrappedProxyObject. Then, a GingaJOSGiService instance is created to store the WrappedProxyObject. After that, an String identification of the IXC object is retrieved from the IXCEvent and registered as an alias property of the OSGiGingaJRegister (SERVICE_IXC_ALIAS). Through this alias, an OSGi Bundle is able to access the OSGi service related to the WrappedProxyObject. Finally, the GingaJOSGiService is used to initialize two more objects; a ServiceReference and a ServiceRegistration (both in osgi.framework). The pair <ServiceReference, ServiceRegistration> guarantees the unique identification of the IXC object and is added to the repository.

Another event that can happen on GingaJOSGiRegisterActivator is IXCListener.UNBINDED, which indicates that an object was removed from IXC and its corresponding reference in OSGi must also be removed. Thus an alias for the IXC object is used in order to find the <ServiceReference, ServiceRegistration> pair and remove it from the repository.

B. Designing the GingaNCL-OSGi API

In this approach, the system architecture was designed in order to allow the programmer of NCL scripts to find and interact with OSGi services in the home network, while the presentation of media elements (such as audio, video and data) is occurring. Thus, the components must allow the exchange of OSGi services and NCL objects (the so-called Adapters).

The main structure of the GingaNCL-OSGi project is the basis for presenting multimedia content on iDTV, where the Adapters are located. An Adapter is responsible for enabling the execution of media in the environment. It is associated to a Player object, which creates a direct link with the media. This way, for each content treated by the middleware, there is a corresponding <Adapter, Player> pair. Some examples are the HTMLPlayerAdapter and HTMLPlayer, Adapter and Player related to the presentation of HTML content on the middleware. Another important example is the pair <LuaPlayer, LuaPlayerAdapter>, which interprets LUA-based procedural content.

To make possible the association of Adapter and Player objects with the media that will be played on the system, the PlayerAdapterManager keeps this association stored in two property-based files. In the ./gingaNclConfig.Players directory the crtldefs.ini file creates an identifier for each Adapter in the emulator and the mimidefs.ini file associates each identifier to a media type (audio, video, HTML, LUA, etc).

Common Core Components

There are five main components of the GingaNCL-OSGi model: two Adapters (GingaNCL2OSGiAdapter and OSGi2GingaNCLAdapter), one Bridge (ContextBridge) and two Bundles (BundleContextExporter and OSGi2GingaNCLBundle). The Bundle components are visible in the whole platform because they are directly installed on Knopflerfish. The Adapter components and the Bridge were organized in a different way, in order to be accessible in both Ginga-NCL and Knopflerfish environments. To do so, these components were allocated in a library (GingaNCLOSGiExt.jar) installed in a standard directory ./lib/ext-osgi. Hence, the Bridge and the Adapters are compiled with other standard components, composing the GingaNCL-Knopflerfish integrated environment.

The idtvhn.ncl package contains the ContextBridge component. It implements a similar function of storing context objects as performed by the procedural ContextBridge. Therefore, the context objects are only from OSGi Knopflerfish. When GingaNCL2OSGiAdapter and OSGi2GingaNCLAdapter need to access the Knopflerfish, they retrieve a context object from ContextBridge that is related to a BundleContextExporter component.

GingaNCL-OSGi Components

In the bridge-components library GingaNCLOSGiExt.jar, the components that allow configuring the access of OSGi services through NCL scripts are packaged in the group idtvhn.ncl.gingancl2osgi. The GingaNCL2OSGiAdapter, GingaNCL2OSGiPlayer and ContextBridge components support this process.

The Adapter of the model has functions to initialize the GingaNCL2OSGiPlayer object, which is in charge of the management of the media presentation. To do so, the GingaNCL2OSGiPlayer (which extends the DefaultPlayerImplementation interface) must perform four functions: initialize the container for the exhibition of the media related to the information of the OSGi service; manage the media presentation (start, pause, stop); handle events on the media (for example, capture some key that is pressed on the remote control while the media is being presented), which allows an interactive control of the service; and access and invoke the OSGi service (using ContextBridge).

OSGi-Ginga-NCL Components

The components of the functional group idtvhn.ncl.osgi2gingancl from the bridge components library (GingaNCL2OSGiExt.jar) enable to export a Ginga-NCL


interface to OSGi. This feature is useful when, for example, an OSGi Bundle needs to exhibit information coming from the Ginga-NCL. Besides the components in GingaNCL2OSGiExt.jar (OSGi2GingaNCLAdapter, OSGi2GingaNCLPlayer, ServiceObject and ServiceObjectImpl), the OSGi2GingaNCLBundle is installed in OSGi to support the process. Considering that NCL applications do not make part of the OSGi domain, they have no authorization to access Bundle context objects and register service objects. This access is ensured by the OSGi2Ginga NCLBundle, which enables the OSGi2GingaNCLAdapter to export a ServiceObject to the OSGi.

IV. BUILDING CONVERGENT SCENARIOS WITH THE

PROPOSED PLATFORM

In this section is presented a step-by-step process to build the four possible types of applications in the Ginga-OSGi integrated environments (XleTView-Knopflerfish and Ginga-NCL-Knopflerfish). Each process is explained by means of an elementary scenario.

A. Scenario 1: From OSGi to Ginga-J

Consider the following application: to export a service object related to a simplified printer service from OSGi, allowing Xlet applications to change some configuration properties of the service. To do so, the process will consist of four steps:

Step 1 – configuring the Bundle and the service. The Bundle and the service objects were created to be exported to the framework. A typical structure of a Bundle project, illustrated in Fig. 5, contains the activator group, which has methods for managing all the states of the Bundle (osgi.printer); service group, which contains the interface to be registered on Service Registry; the implementation group, which contains the implementation of the service. Besides, in this structure, there are libraries from the JRE standard and the GingaJ-OSGi (knopflerfish-xletview_ixc_lib, which is composed by xletview.jar and knopflerfish.jar). The Bundle structure also has some standard files and directories for HTML documentation (/doc); additional APIs used by the Bundle (/embeddedlib); the manifest file (/META-INF/MANIFEST.MF); and files for configuring properties of the building (build.properties) and automating the generation of the Bundle (a script configured in build.xml).

Step 2 – installing the Bundle on the platform. The exported service (osgi.printer.service.Printer) is then passed to the Bundle activator. After that, some properties of the service (SERVICE_ALIAS and SERVICE_TYPE, as explained in section III.A.2) must be configured in order to make the registered OSGi service visible to the Ginga-J domain. Also it is necessary to explicitly define an alias for the corresponding IXC object (setting the OSGiGingaJRegister.SERVICE_IXC_ALIAS property). All this configuring process occurs in the Activator.start method.

Step 3 – automatically exporting the Printer service to the Ginga-J. When the Printer service is registered, it is detected

by the OSGiGingaJRegister listener, which performs the process detailed in section III.A.2. First, OSGiGingaJRegister detects the Printer service object and registers it in the IXC Registry of Ginga-J. After that, BundleGingaJOSGiRegister detects the registered object (as detailed in III.A.3), but because it is not an object from IXC, it does not need to be exported back to OSGi. At this point, the process is complete. The Printer service is available to both, the Ginga-J Xlets and the OSGi Bundles.

Step 4 – configuring the Xlet application to use the printer service. For a Ginga-J Xlet, there is no difference between an OSGi service object and a Ginga-J remote object on the IXC. To obtain each of them, the Xlet simply looks up in the registry using the appropriate alias. To access the methods provided by the Printer service the Xlet retrieves a remote object as a WrappedProxyObject from the IXC Registry using the same alias as defined at the time of the Service Registry in OSGi. After that, the Xlet uses the invoke method from WrappedProxyObject to access getPrinterType and setPrinterType from Printer. This way the Xlet is able to modify the properties of the service and these changes will have some effect on the OSGi environment.

Fig. 5. Common structure for a project of a Bundle to be deployed on the GingaJ-OSGi.

B. Scenario 2: From Ginga-J to OSGi

The following problem was considered for this kind of collaboration: to export an IXC remote object from Ginga-J to the OSGi Service Registry. As an illustration, consider the scenario where a Ginga-J Xlet needs to export an area of the iDTV screen as an element of an OSGi service, in order to make available receiving image objects from OSGi. It could happen, for instance, when a Bundle that manages a camera in a security system needs to automatically send a video frame to the iDTV screen. Besides the image area, the Xlet must also export a text area to receive text data from OSGi. The overall process also consists of four steps:

Step 1 – defining the remote objects in the IXC. As an OSGi service, a remote object from IXC Registry is a standard type of Java interface. For the IXC, remote objects must


always extend rmi.Remote, and all the object methods have to throw one rmi.RemoteException exception. In the Xlet project the main objects to be exported are RemoteObj and RemoteObjImpl, both in the idtvh.remoteixc package. These objects have methods for receiving image and text from OSGi.

Step 2 – register these objects in the IXC Registry. When registering the objects in the IXC (in the startXlet method), an alias for the remote object is defined and the IXCRegistry.bind is called. The bridge components come into action at this point.

Step 3 – using the bridge components to export the IXC remote object to OSGi. In the moment that the RemoteObj object is registered, it is detected by the listener of the BundleGingaJOSGiRegister. After that, the components of BundleGingaJOSGiRegister initialize a WrappedProxyObject, passing the RemoteObj as a parameter (as detailed in III.A.3). This registry operation is detected by the OSGiGingaJRegister, but it does not make any changes in the object, because it is not a service coming from OSGi. In the last step the WrappedProxyObject is passed to the GingaJOSGiService which adds it to the repository.

Step 4 – setting the Bundle to access and use Ginga-J remote objects. For a Bundle to access methods from RemoteObj, exporting image and text to the iDTV screen, it is necessary to first find GingaJOSGiService. After that, the Bundle needs to look up the desired service object in the GingaJOSGiService repository. This object is indexed by the alias used at the moment of the registry in IXC Registry. Since the alias is unique, the retrieved object is exactly the desired one, which is in a WrappedProxyObject form. Thus, the methods can be invoked in the same way as in the printing scenario.

C. Scenario 3: From Ginga-NCL to OSGi

In a common interaction sequence among these components, in order to allow Ginga-NCL elements to access OSGi services, three steps will be needed:

Step 1 – configuring the Bundle and the service. This step is similar to the corresponding procedural model, where a service Bundle is installed on Knopflerfish. An advantage of this is that the OSGi service can be accessed by an Xlet or an NCL script.

Step 2 – configuring the bridge components. In this step there are the GingaNCL2OSGiAdapter and the GingaNCL2OSGiPlayer. The former is accessed by the middleware (through the configuration files) and the later defines a play method that is automatically invoked and starts presenting the NCL media containing information related to the OSGi service. GingaNCL2OSGiPlayer directly access the ContextBridge to invoke the related service from OSGi.

Step 3 – setting the NCL script. In the NCL application (a .NCL file) standard options for the media presentation are configured. Examples of these options are the region of the screen and the related media (through the media and region tags). This way, the information of the service invoked by GingaNCL2OSGiPlayer is presented on the screen and the user can interact with the service using a remote control.

D. Scenario 4: From OSGi to Ginga-NCL

As an example illustrating the use of components for this case, consider the following: an NCL application presents one media component (an HTML page related to HTMLPlayerAdaper) and an OSGi Bundle needs to obtain information about this component. In the same way as in the previous case, the process is composed of three steps:

Step 1 – setting the NCL script. In this step the NCL file is configured and the same tags (region and media) are used for presenting the media content. In this case, the object to be shown is a media related to an OSGi2GingaNCLAdapter. Also, some properties for this media are set in order to define the moment the Adapter will be available to the OSGi.

Step 2 – configuring the Ginga-NCL and OSGi Bridge components. In this step, the OSGi2GingaNCLAdapter exports a generic service (OSGi2GingaNCLService) that contains methods for accessing the properties of the HTMLPlayerAdapter. After that, the media is started and the OSGi2GingaNCLAdapter accesses the ContextBridge to find a BundleContext in order to export OSGi2GingaNCLService to OSGi using the OSGi2GingaNCLBundle.

Step 3 – configuring the OSGi Bundle to access the OSGi2GingaNCLService. In this final step, a Knopflerfish Bundle gets a service reference to the service from OSGi2GingaNCLBundle, accessing the Ginga-NCL OSGi2GingaNCLService object. Thus, when the Bundle invokes a method from the service it can visualize the properties of the HTMLPlayerAdapter.

V. DEVELOPING TEST APPLICATIONS

The design and implementation of use-case scenarios that can become useful applications to the user of the connected home are presented in this section. For each one, the overall description and obtained results are shown. The first application is a camera monitoring system using the procedural components, and the second one is a iDTV printing system using declarative components.

A. Application 1 – Remote camera monitoring.

This application uses image capturing devices to create a camera monitoring environment in an iDTV-centered network. According to this scenario, when a user interacts with the iDTV interface, he/she can access remote services of OSGi devices located in different parts of the residence. The GingaJ-OSGi platform ensures that iDTV applications are able to find services from image devices in the TCP/IP network and perform remote operations on each device (such as connect, initialize, start, pause, stop and get picture frame).

At the OSGi perspective, there are two main services, EthernetService (in BundleEthernetClient), which allow connecting the iDTV-HG with other devices in the network; and WebCamService, which is directly associated with the image capture device. The first one is installed on GingaJ-OSGi and the second one is deployed in a separate OSGi implementation (the camera access gateway) in which the


image device is connected. In other words, the system has a client-server base with several OSGi camera servers and one GingaJ-OSGi client.

Considering the iDTV perspective, an HAVi-based interface was created, allowing the user to browse through the available image devices, performing useful operations. In this scenario there is only one way of interaction with GingaJ-OSGi (accessing the Ginga-J remote object from OSGi, described in III.A). The WebCamService is exported from the camera access gateway to the GingaJ-OSGi through the network. The BundleWebCamServiceManager receives the WebCamService and looks up the OSGi Service Registry in order to find a service GingaJOSGiService related to a WrappedProxyObject from Ginga-J with which the BundleWebCamServiceManager will access a graphical area from the iDTV and show the information of each device through the corresponding WebCamService.

Fig. 6 presents the final interface for the iDTV in which the information retrieved from the WebCamService is showed.

Fig.6. iDTV screen showing information of the cameras.

B. Application 2 – Synchronizing video with the printing of a document.

This declarative scenario uses Ginga-NCL resources to synchronize a document printing application with the video media presentation. An important feature here is the possibility of defining the exact moment in which the application will be shown (when, for example, in a cooking show, the program suggests the user to print the recipe at that right moment and all available printers of the network are evaluated).

The main task for this application is to find the printing services, which will be performed by the Ginga-NCL environment through the NCL script. This task begins when an object related to an NCL document activates a GingaNCL2OSGiAdapter, which requests the service invocation from the GingaNCL2OSGiPlayer. The retrieved service uses the resources of a standard printing API and executes a print operation, receiving a status response. The response is passed on to the OSGi2GingaNCLPlayer and from this, to the OSGi2GingaNCLAdapter that updates the status on the iDTV screen.

Fig. 7 illustrates a screenshot of the system for the printing confirmation option.

Fig.7. Confirmation screen of the Ginga-NCL printing scenario.

VI. FINAL REMARKS

This paper presented the project and the implementation of an API built under a model that uses a strategy for collaboration between software components of the Ginga middleware and the OSGi framework. The API is an extension of the functionalities of the two systems since it presents components that work as a bridge for exporting the key elements of each specification (the Service Registry services and the IXC Registry remote objects). While the analysis and description of the model had already been provided in previous work [15], here the focus was on the design of the components with an implementation point of view, i.e., the description of how the related technologies available for iDTV and home networks were used to support the model. More importantly, some implementation details for the core of the model were presented, such as the role of each component and a step-by-step process for building several convergent Ginga-OSGi applications.

The main contributions of this work is in presenting an innovative idea to make a common use of software platforms for iDTV and Home Networks, thus allowing the emergence of several scenarios which, in a real situation, could be part of the next generation of services offered to the future connected home. As a future work, a commercial iDTV-HG hardware/software solution is being developed to support real life tests and to improve the presented platform.

ACKNOWLEDGMENT

The authors would like to thank the students that contributed with the tests and debugging of the developed software, as well as with the enhancement of the application`s users interfaces. We also would like to express our gratitude to the administrative and technical support team from CETELI – Center for Research and Development of Electronic Devices, Telecommunication Systems, and Information Systems – from the Federal University of Amazonas in Manaus.


REFERENCES [1] K. Gill, S.-H. Yang, F. Yao, and X. Lu, "A ZigBee-based home

automation system," IEEE Trans. Consumer Electron., vol. 55, no. 2, pp. 422-430, May 2009.

[2] E. Tsekleves, J. Cosmas, A. Aggoun, and J. Loo, "Converged digital TV services: the role of middleware and future directions of interactive television," Int. Journal of Digital Multimedia Broadcasting, article ID 643680, vol. 2009, pp. 1-19, 2009.

[3] C. Ge, Y. Li, X. Zhi, and W. Tong, "The intelligent STB - implementation of next generation of residential gateway in digital home," Proc. of the 2nd International Conference on Pervasive Computing and Applications, vol. 1, pp. 256-261, July 2007.

[4] F. T. H. den Hartog, M. Balm, C. M. de Jong, and J. J. B. Kwaaitaai, "Convergence of residential gateway technology," IEEE Trans. Communications Magazine, vol. 42, no. 5, pp. 138-143, May 2004.

[5] S. Dixit and R. Prassad, "Technologies for home networking," John Wiley & Sons, New York, pp. 27-50, 2008.

[6] D. Tkachenko, N. Kornet, A. Dodson, L. Luyang, and R. Khandelwal, "A framework supporting interaction of iDTV applications and CE devices in home network," Proc. of the IEEE Consumer Communications and Networking Conference, vol. 1, pp. 605-607, Jan. 2005.

[7] M. Cabrer, R. Redondo, A. Vilas, J. Arias, and J. Duque, "Controlling the smart home from TV," IEEE Trans. Consumer Electron., vol. 52, no. 2, pp. 421-429, May 2006.

[8] R. P. D. Redondo, A. F. Vilas, M. R. Cabrer, and J. J. P. Arias, "Exploiting OSGi capabilities from MHP applications," Journal of Virtual Reality and Broadcasting - EuroITV 2006 Special Issue, vol. 4, no. 16, pp. 1-12, July 2007.

[9] Y.-S. Bae, B.-J. Oh, K.-D. Moon, and S.-W. Kim, "Architecture for interoperability of services between an ACAP receiver and home networked devices," IEEE Trans. Consumer Electron., vol. 52, no. 1, pp. 123-128, Feb. 2006.

[10] M.-C. Yang, N. Sheng, B. Huang, and J. Tu, "Interoperability between set-top box and residential gateway platforms," Proc. of the IEEE Int. Symposium on Communications and Information Technologies, vol. 1, pp. 1286-1290, Oct. 2007.

[11] C.-L. Lin, P.-C. Wang, and T.-W. Hou, "A wrapper and broker model for collaboration between a set-top box and home service gateway," IEEE Trans. Consumer Electron., vol. 54, no. 3, pp. 1123-1129, Aug. 2008.

[12] C.-L. Lin, P.-C. Wang, and T.-W. Hou, "Classification and evaluation of middleware collaboration architectures for covering MHP and OSGi in a smart home," Journal of Information and Systems Engineering, vol. 2009, pp. 1337-1356, 2009.

[13] N. S. Viana and V. F. de Lucena Jr., "A software model supporting the management of home network services through the Brazilian iDTV," Proc. of the 7th European Interactive TV Conference, vol. 1, pp. 101-110, July 2009.

[14] O. B. Maia and V. F. de Lucena Jr., "A communication infrastructure between the Brazilian middleware for DTV and residential devices," Proc. of the 7th European Interactive TV Conference, vol. 1, pp. 116-120, July 2009.

[15] V. F. de Lucena Jr., J. E. Chaves Filho, N. S. Viana, and O. B. Maia, "A home automation proposal built on the Ginga middleware and the OSGi framework," IEEE Trans. Consumer Electron., vol. 55, no. 3, pp. 1254-1262, Aug. 2009.

[16] N. S. Viana and V. F. de Lucena Jr., "iDTV home gateway convergence: an open software model integrating the Ginga middleware and the OSGi framework," Multimedia Systems Journal, vol. 16, no. 5, pp. 1-15, Aug. 2010.

[17] DVB-MHP, “Digital video broadcasting and multimedia home platform specification 1.2.2”, European Telecommunications Standards Institute, ETSI Doc. No. TS 102 727 V1.1.1, pp. 17-42, 2010.

[18] DTS – ATSC, “Digital television standard: part 1 – digital television system,” Advanced Television Systems Committee, Document A/53 Part 1:2009, pp. 1-24, Aug. 2009.

[19] ITU-T, “Telecommunication standardization sector, series H: audiovisual and multimedia systems, consented recommendation H.761 – nested context language (NCL) and Ginga-NCL for IPTV services,” International Telecommunication Union, pp. 12-73, 2009.

[20] OSGi, “OSGi service platform core specification,” OSGi Alliance, Release 4, Version 4.2, pp. 25-40, June 2009.

[21] UPnP, “UPnP device architecture – part 1: version 1.0,” UPnP Forum, Document ISO/IEC 29341-1:2008, pp. 12-70, 2008.

[22] J. Newmarch, "Foundation of Jini 2 programming," Apress, New York, pp. 123-170, 2006.

[23] N.S. Viana, O.B. Maia, V.F. de Lucena and L.C. Pinto, "A convergence proposal between the Brazilian middleware for iDTV and home network platforms," Proc. of the 6th IEEE Consumer Communications and Networking Conference, vol. 1, pp. 1-5, Jan. 2009.

[24] G. L. de Souza Filho, L. E. C. Leite, and C. E. C. F. Batista, "Ginga-J: the procedural middleware for the Brazilian digital TV system," Journal of the Brazilian Computer Society, vol. 13, pp. 47-57, March 2007.

[25] L. F. G. Soares, R. F. Rodrigues, and M. F. Moreno, "Ginga-NCL: the declarative environment of the Brazilian digital TV system," Journal of the Brazilian Computer Society, vol. 13, no. 1, pp. 37-46, March 2007.

[26] L. F. G. Soares, R. M. R. Costa, and M. F. Moreno, "Multiple exhibition devices in DTV systems," Proc. of the 17th ACM Int. Conf. on Multimedia, vol. 1, pp. 281-290, Oct. 2009.

[27] H. Schildt,” Java the complete reference,” The McGraw-Hill Companies, 8th Edition, pp. 712-845, 2011.

[28] NBR 15606-4, “Digital terrestrial television – data coding and transmission specification for digital broadcasting – part 4: Ginga-J - the environment for the execution of procedural applications,” ABNT, pp. 1-97, 2010.

[29] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, "Design patterns: elements of reusable object-oriented software," Addison-Wesley, New York, pp. 216-350, 1995.

[30] T. Hows, “The string representation of LDAP search filters”, Netscape Communications Corp., Document RFC 2254, pp. 1-9, Dec. 1997.

BIOGRAPHIES

Vicente Ferreira de Lucena Jr. (M’94) received his Ph.D. degree (Dr.-Ing) in 2002 from the University of Stuttgart – Germany. Since 1991, he has been a Faculty Member with the Electrical Engineering Department at the UFAM. He is also with the CETELI, a research center that works with consumer electronics, embedded systems and software engineering. His research interests include the development of automation systems, new software engineering approaches, and the development of embedded systems. Nairon Saraiva Viana received his graduate degree in Technology in Information Systems in 2006 from the Instituto Federal de Educação Tecnológica do Piauí (IFPI), Brazil. He received the M.Sc. degree in Electrical Engineering from UFAM, in 2009. He is currently a Ph.D. student in Electrical Engineering at Universidade Federal do Minas Gerais (UFMG). His interest areas are related to automation systems, home networking, and multimedia systems. Orlewilson Bentes Maia received his B.Sc. degree in Computer Science from the Centro de Ensino Superior FUCAPI (CESF), Amazonas, Brazil, in 2005. He received the M.Sc. degree in Electrical Engineering from UFAM in 2009. From 2007 to 2011 he has worked in CETELI as software developer in Manaus. He is currently a Ph.D. student in Electrical Engineering at Universidade Federal do Minas Gerais (UFMG). His research interests include Digital TV, software engineering, and IPTV. João Edgar Chaves Filho received his Ph.D. degree in Electrical Engineering in 1997 from the Universidade Federal de Campina Grande (UFCG), Paraíba, Brazil. His M.Sc. was also obtained from UFCG in 1991. Since 1980, he has been a Faculty Member with the Electrical Engineering Department at UFAM. His research interests include new home and industrial automation proposals, artificial intelligence, development of new electrical drives, and system identification. Waldir Sabino da Silva Jr. received his Ph.D. degree in Electrical Engineering in 2011 from the Universidade Federal do Rio de Janeiro (COPPE – UFRJ), Brazil. His M.Sc. was also obtained from COPPE in 2003. Since 2005, he has been a Faculty Member with the Electrical Engineering Department at UFAM. His research interests include signal processing, artificial intelligence, development of new electronic devices, and pattern recognition.

designing an extension api for bridging ginga idtv applications and home services

Documents