A dynamic Service Delivery Framework based on the ...

A dynamic Service Delivery Framework based on the OSGi model. Johan Vos, Steven Buytaert, Dries Buytaert

Abstract | Many services that were previously oered only on a speci c device, now have become available on a wide range of devices. For example, E-mail is not only checked on a PC anymore, E-mail clients also exist for PDA's, cellular phones and prototypes of in-vehicle Platforms. End Users often switch between dierent devices | e.g. laptop, cellular phone, in-vehicle Platform | but they want to use the same service | perhaps with a dierent look and feel | on many devices. This paper describes a common Service Delivery and Management Model for a wide range of devices and puts emphasis on the usability of this Model in the in-vehicle industry. Keywords | Java, OSGi, ACUNIA, OTF, Telematics

II. Telematics A. Delivering Content

Telematics combines telecommunication with | remote | Service Delivery and execution, providing added value over the traditional telecommunication infrastructure. Although typically used in a vehicle-environment, it is not limited to this environment. From a marketing point, it is clear that "access" alone is not enough to attract customers. End users do not bene t from just being connected to the Internet. The telecommunication infrastructure can be used for sending data to and from vehicles. In a simple I. Introduction approach, an Agent1 running on a vehicle uses the comELIVERING services towards moving vehicles puts munication device to exchange information with an Appliadditional constraints to the Service Delivery model. cation running on a remote host. The Agent-Application The goal of the Service Delivery model is to install the combination is provided by a Service Provider, and a proright service on the right device in the best possible way. prietary application protocol is used for exchanging data. Dierent types of services can be distinguished in the eld An example of this system is on-board navigation, where code executed on a telematics platform in the car will reof telematics. A possible categorization includes quest navigation data from a remote server. When the user  services that are of direct bene t to the end user | e.g. | or the Agent | needs new information, the communia navigation service, cation channel is used to obtain this information.  hidden services that are not visible to the end user but Apart from navigation applications, typical telematics that collect and process information relevant to the platapplications are alarm and security systems, on-board or form or a third entity | e.g remote diagnostics services in remote diagnostic services, location-dependent information a car, and

eet management.  supporting services | e.g. communication services. The end user has only a direct interest in the rst cat- B. Delivering Applications egory of services. As a consequence, services belonging to Apart from sending and receiving data for one particuone of the other categories should be managed without end user interference. But even for end-user services, it is im- lar application, the telecommunication infrastructure can portant that the correct service is delivered, installed and also be used for delivering services. In this case, the comstarted with as less actions as possible from the end user. munication channel is used to obtain an Agent when the Furthermore, especially on constrained platforms, ser- user | or another Agent | requires so. The downloaded vices should leverage each other as much as possible. Since Agents can each run in their own virtual space and execudierent vendors may deliver services to a platform, this tion context. However, doing so requires that each Agent means that there should be an open contract between the also comes with a whole basic infrastructure. Downloading a software Agent from a server2 requires dierent services. A clear separation between interfaces that the software provider knows which executables can and implementations is required. The OSGi Service Platform[2] addresses these require- be run on the remote platform. There are many dierent ments, and provides a powerful yet simple and scalable terminal manufacturers with a favorite Operating System Framework that enables the management of the life-cycle for their platform, and a service provider wants to make of services and resources on execution platforms. New code sure that his service runs on most if not all platforms. This containing services can be downloaded, and the system is is one of the reasons why Java is often used as the language for developing telematics services3 . hardware independent.

D

J. Vos is Director New Technology at ACUNIA, Belgium. E-mail: [email protected] . S. Buytaert is co-CEO and CTO of ACUNIA. E-mail: [email protected] . D. Buytaert is PhD Student at the University of Antwerp and software engineer at ACUNIA.

1 An Agent is a piece of code running on the Telematics Platform and providing a service for users or other Agents. 2 Or pushing an agent towards a Platform 3 ACUNIA has a clean-room open source implementation of a Virtual Machine, named wonka. See http://wonka.acunia.com for information.

III. Device- and Platform independent Services using Java A. Java advantages in telematics

The Java language[1] was designed to be portable between both hardware architectures and operating systems. Therefore Java is said to be architecture neutral which is especially important in the telematics industry where dierent services supplied by various vendors and service providers have to coexist on a wide range of terminals. For years, Java developers can select from a large set of development tools and well documented APIs that specify and support an extensive set of libraries and that greatly simplify the development of applications. Furthermore, Java represents an object-oriented programming language which encourages good program design and reuse of software components. A number of integral features or properties of the Java's run-time environment eliminate situations that are error prone and eectively render Java a secure and robust execution environment.  Java supports automatic garbage collection, thereby simplifying the memory management and eliminating the risk to corrupt memory (no dangling pointers).  Java supports dynamic loading of classes; new software components can be remotely installed and upgraded, be it for bug xes or feature enhancements, while the program is running.  Since Java's inception, a lot of emphasis has been placed on correctness and security: the bytecode veri er, the classloader, the security manager and the sandbox model cooperate to strengthen Java's security and prevent programs or software components from performing unauthorized actions. B. Access control

Java can be used for downloading services on a telematics platform with a Java Virtual Machine, but it does not de ne whether all downloaded services should each run in a separate environment or not. In the following discussion, it is assumed that three Agents, called A, B and C are installed on the telematics platform. At this point, it is irrelevant whether the Agents were present on the platform from the beginning or whether they are downloaded in the lifetime of the platform. In Figure 1, the three Agents are clearly separated from each other. Although it is possible and even likely that they share the same CPU, code from Agent A is never able to access code from Agents B or C. This approach has some advantages. It is possible to protect resources and assign them to the most important services4 . Also, the system is virus-proof: an error in one of the services cannot corrupt any other service. Note however, that if the services share the same CPU, it is still possible that one malicious service locks the CPU. 4 An alarm service will probably have a higher priority than a game service

A

B

C

Fig. 1. Three services are clearly separated from each other on the execution platform. The thick lines indicate that code from one service can not be accessed by any other service.

A clear disadvantage of this model is that there will be lots of duplicated code. Many telematics services have some pieces of code in common, e.g. for obtaining information about the car or for communicating with remote hosts. The opposite of the rst approach is shown in Figure 2.

A C B

Fig. 2. The three services now share the same execution environment. All code from any service is accessible by any other service.

In this case, all code from one service is accessible by all code from the other services. This allows us to solve the problem of the the duplicated code, but creates new problems in turn. In order to use code from another service, a service should know the semantics of the other service. Moreover, a strong dependency between the two services will exist, and if one of the services is ever upgraded, it is not guaranteed that the other one will continue to work. Apart from that, this system is anything but secure. Parts of the code should really be protected from being accessed by any other code. Especially code that is downloaded from untrusted service providers cannot be granted the same access rights as code from, for instance, the manufacturer of the telematics platform itself.

A better solution is shown in Figure 3. In this approach, Bundle-Name: MyBundle Export-Package: com.acunia.foo

Manifest File gif Class

jar A

B

C

Fig. 3. The three services now partly share the same execution environment. The services themselves de ne which parts of their code can be accessed by other services.

Fig. 4. The concept of an OSGi Bundle. The Bundle is a jar- le containing a Manifest File, class- les, additional jar- les and resources (e.g. images).

of java.io.InputStream. The Virtual Machine is responsome parts of the service are accessible by the other ser- sible for mapping Java InputStreams to native streams. vices, while other parts are private to the service. The Consequently, neither the Agent nor the Application needs services themselves de ne which parts they want to share to worry about the underlying communication mechanism. The life-cycle operations associated with a Bundle are with other services. The OSGi model that is used in ACU install: the Bundle code is installed on the Service NIA's telematics products uses the latter approach. Platform (either from a local lesystem or from a remote host). IV. The OSGi model  uninstall: the Bundle code is removed from the Service The Open Services Gateway Initiative was formed in Platform 1999 in order to de ne an open standard for the delivery of  start: the Bundle is started. If the Manifest- le conservices in networked environments, e.g. vehicles, homes, tains an entry Bundle-Activator pointing to a class- le, PDA's,... . OSGi currently counts about 70 companies in the start() method of this Bundle-Activator is executed. dierent industries5 . The rst version of the OSGi spec-  stop: the Bundle is stopped. If the Manifest- le contains i cation was released in May 2000, followed by a second an entry Bundle-Activator pointing to a class- le, the public release in October 2001. The speci cations can be stop() method of this Bundle-Activator is executed. accessed by non-members on http://www.osgi.org.  update: the Bundle code is updated. The new code can The core of the set of OSGi speci cations is the Service originate from the same location or host as the old code, Platform. This is a set of Java APIs that describes the or from a new location. life-cycle management of services on an execution platform | e.g. a telematics platform. Although the APIs are com- B. Services pletely written in Java, it is allowed that services contain When a Bundle wants to make available some functionalnative code. ity, it registers a Service. A Service8 is an implementation of a Java Interface. An example of such an Interface is A. Bundles One of the key concepts in the OSGi Service Platform is given below: the Bundle6 . A Bundle is a collection of (Java) class les, native code, additional resources7 and a Bundle Manifest interface FogLightService { le describing the contents and meta-information about the Bundle | see Figure 4. Bundles can be installed from a boolean fogLightsOn (); local le system or from the network. The latter is not dependent on the communication device present on the platvoid setFogLights (boolean value); form, since the Bundle information is read from an instance 5 Telecommunications,

software, hardware, automotive OEM's, domotica suppliers, service companies,... 6A Bundle is an instance of the Java class org.osgi.framework.Bundle. 7 Images,

Bundle

Sound les, HTML code,... can be included in an OSGi

} 8 Note that in this paper the term service is used to denote a general service, while the notation Service is used to indicate an OSGi-speci c service.

This interface only de nes a contract between a provider should be described in the Manifest File, using the key of a FogLightService and a consumer that wants to use Export-Package: the FogLightService. An implementation of this service Export-Package: com.acunia.foo might be The Bundle should contain this exported package. Only one Bundle can export a given package at the same time. If two or more Bundles oer to export the same package, the framework decides which Bundle can actively export the package. The other oering Bundles have to use the package oered by the actively exporting Bundle instead of using their own version of the package. This is to ensure that only one version of a class is installed at a given moment. However, if a Bundle exporting package com.acunia.foo is uninstalled and it does not export any packages anymore, the Framework will choose another Bundle for exporting the package com.acunia.foo | if one is available. Bundles that want to use code from other Bundles can | apart from asking for Services | import packages. This should be described in the Manifest le, using the key Import-Package as follows:

class FogLightServiceImpl implements FogLightService { private boolean status; public boolean fogLightsOn () { return this.status; } public void setFogLights (boolean value) { this.status = value; } }

Each Bundle running on a Service Platform has an associated BundleContext Object9 . The BundleContext is the link between the Bundle and the Framework. When a Bundle wants to make a Service available to other Bundles, it does so by registering the Service with the Framework, by means of the BundleContext. Registering a Service can be done with the method BundleContext.registerService (String[] clazzes, Object service, Dictionary properties);

Import-Package: com.acunia.foo

Before a Bundle can be started, the Framework should resolve the Bundle's dependencies. One of the steps in this resolving operation is to check whether all packages the considered Bundle wants to import are exported | through the Export-Package key from this or another Bundle10 . D. Permissions

Using the model described in the previous paragraph, it is possible to share Services and code amongst Bundles. In Registering a Service includes handing over the Ob- many cases, Bundles want to make available some of their ject implementing the Service | in this case the resources to certain other Bundles. Also, not all Bundles FogLightServiceImpl class | to the Framework. While are probably allowed to register any Service. In a vehicleregistering a Service, it should be speci ed under which in- environment, only trusted Bundles can register code for terfaces the Service needs to be registered. One service can e.g. obtaining vehicle-speci c information. implement more than one interface. On the other hand, a In the OSGi model, this can be done by using the right Service implementing two interfaces may choose to make Permissions11. When a Bundle wants to register a Service, itself available only as the implementor of one of the inter- it must hold ServicePermission 12 with the action "regfaces. ister". When a Bundle wants to obtain a Service, it must A Service can be registered with an additional set of have ServicePermission with the action "get". properties, describing some implementation-speci c de- Similarly, a Bundle that wants to export a package should tails. When some code in a Bundle wants to obtain a Ser- have PackagePermission13 with the action "EXPORT" vice, it asks the Framework for an implementation of the and a Bundle that wants to import a package should have required Service | e.g. the FogLightService. The Frame- PackagePermission with the action "IMPORT". work will then look through the list of registered services Operations that are important for the Service Platform and nd the Services that are registered under the required itself | e.g. these operations that are related to the lifeinterface. The requester of the Service may supply addi- cycle of Bundles | can only be called when the requester tional properties that need to be matched by the provider has AdminPermission14. of the Service. A simple LDAP-based model is used for 10 The OSGi speci cations allow the use of a simple versioning sysspecifying the syntax of the queries on properties. C. Sharing packages

Apart from registering Services, a Bundle can also offer a Java package it contains to the Framework. This 9A

BundleContext

is

an

instance

org.osgi.framework.BundleContext

of

the

Java

class

tem for imported or exported package, but this is not described in this paper. The interested user is referred to the OSGi speci cation document. 11 A Permission is an instance of java.security.Permission or one of its subclasses. 12 see org.osgi.framework.ServicePermission. 13 see org.osgi.framework.PackagePermission 14 see org.osgi.framework.AdminPermission

to be installed. This can be done manually by the user, but The OSGi Framework maintains a list of all Bundles, it complicates the management of the Service Platform. The OTF can be con gured depending on the market registered Services, Service usage, imported and exported and policy requirements. In some use cases, millions of packages. Because of the dynamic aspects of the Frameplatforms have to be managed. This management may work, these lists will vary over time. Bundles can be ininclude the remote installation of new services, or the upstalled and uninstalled, Services can be registered and ungrade of existing services. The management system should registered. One of the design goals of the OSGi Framework have a perfect knowledge of which services are installed on is to minimize dependencies between dierent Bundles from every platform. When a new version of a service becomes dierent vendors. The Framework keeps track of the usavailable, it should not blindly be sent to every platform age of the Services, and it knows when a Service is still in that has an older version of the service. Indeed, it is possiuse by a Bundle. This frees the Service Developer from ble that the new version has additional requirements (CPU maintaining a list of Service users. power, screen size,...) that can not be met by a platform. It is the task of the OTF to guarantee that all platforms V. Beyond OSGi: the Open Telematics are equipped with the correct services. Framework r The OSGi Service Platforms manages the life-cycle of B. Value-added information Services on a platform. Using the Permissions, it is possiA Remote Management System as the OTF puts the ble to develop a ne-grained access model. However, OSGi control over the managed Service Platform in the hands of does not describe any policy. One of the reasons for this the Operator of the Remote Management System. Apart is the market-independence of OSGi. The Service Delivery from the above-mentioned technical simpli cations for the Model is applicable to dierent markets, e.g. vehicle marend user, this enables a convenient business model. Usage ket, PDA's, domotica,... and any restriction or pre-de ned of services can be logged in the OSGi Framework, and the policy may make it more diÆcult to accept the OSGi model OTF pre-processes and transfers these logs to the OTF in a speci c market. Business Server, the central part in the OTF. Remote Management Systems enable the management This information can be used by the Operator, e.g. to of a range of Service Platforms. An example of a Remote generate bills. Some services can be used for free, while Management System that leverages the features oered others require a one-time license or a fee per usage. Apart by OSGi enabled Service Platforms is the ACUNIA Open from that, it is very likely that the end user will have to pay Telematics Framework r (OTF). This system is shown in for the air-time in the case where a wireless connection is Figure 5 and explained below. used for sending data or services to or from the Platform. The OTF Business Server interacts with legacy applications | e.g. databases, CRM systems, billing systems {, allowing the Operator to de ne the business model of his choice. SP A SP B SP C E. The OSGi Framework



VI. Conclusions

In this paper, two models are explained: the life-cycle and resource management of Services runDatabase ning on a variety of Platforms, OTF Business Server Billing System  the Remote Administration that facilitates the life-cycle and resource management and that allows the Operator to ... de ne a policy and a business model. These two models are extremely important in a networked world where users expect that services and information are C1 C2 C3 available everywhere and are always working. Information Fig. 5. The OTF. The central entity is the OTF Business should ow through a network of services to the end users. Server, where Service Providers can register Services. Three Service It turns out that the Java language oers an excellent baProviders are shown: SP A, SP B and SP C. Services and data can be sic platform for running services. The life-cycle of these pushed to or pulled from Service Platforms or Clients. Three Clients are shown: C 1, C 2 and C 3. Information about Users and Platforms services can very well be managed by an OSGi Service can be processed by the OTF Business Server and made available for Platform, and the Remote Management of many Service further usage to legacy applications. Platforms can be taken care of by the OTF. 

References A. Managing the services

For the end user, it is important that he obtains the right service at the right moment. Often, a Service that is of particular interest to another user requires another Service

[1] Gosling, et al, The Java Language Speci cation, second edition, Sun Microsystems, 1999 [2] The Open Service Gateway Initiative The OSGi Speci cation http://www.osgi.org, 2001

Copyright 2002. ACUNIA N.V., Philips-site 5 box 3, 3001 Leuven, Belgium. All rights reserved. ACUNIA and ACUNIA Open Telematics Framework (OTF) are trademarks and registered trademarks of ACUNIA N.V. in the Benelux and/or other countries. All other brand names and/or product names are the trademarks and/or registered trademarks of their respective owners.