Services Everywhere: OSGi in Distributed Environments ∗

Jan S. Rellermeyer Gustavo AlonsoDepartment of Computer Science

ETH Zurich8092 Zurich, Switzerland

{rellermeyer, alonso}@inf.ethz.ch

ABSTRACTDistribution is increasingly becoming an important issue inboth enterprise applications and mobile computing. OSGi it-self has only rudimental support for distribution, in forms ofinterfaces for interaction with Jini (R3) or UPnP (R3 + R4)infrastructures. When it comes to interconnecting differentOSGi frameworks, there are only few solutions so far. Inthis paper, we present these existing solutions and comparethe different approaches with our own R-OSGi. The goal ofour open source project is to provide a seamless and non-invasive middleware for accessing remote services in OSGiframeworks. We explain the basic design principles of R-OSGi, such as transparent service access and spontaneousinteraction, and briefly mention the internal structure andtechniques used in R-OSGi, such as service discovery andsmart proxies.

1. INTRODUCTIONThe OSGi framework is nowadays a well-established ap-

proach for solving the problem of modularization of Javaapplications. Software can be modularized into independentbundles interacting through services. Services reduce thecoupling of bundles by defining service interfaces. Whereasthe interface of a service is the shared knowledge between in-teracting bundles, the concrete implementation of a serviceremains a black box. This not only reduces link-level depen-dencies to the types used in the interface but also allows toexchange the implementation of a service at runtime.

In the context of networked environments, the service-oriented design of OSGi is ideal for building distributed ap-plications. The strict distinction between interface and im-plementation and the loose coupling between componentsmake it possible to access services residing on other ma-

∗The work presented in this paper was supported (in part)by the National Competence Center in Research on MobileInformation and Communication Systems (NCCR-MICS), acenter supported by the Swiss National Science Foundationunder grant number 5005-67322.

Some rights reserved.This publication is licensed under a Creative Commons Attribution-NonCommercial 2.5 License; see http://creativecommons.org/licenses/by-nc/2.5/ for further details.EclipseCon 2007 March 5–8, 2007, Santa Clara, CA.

chines if a feasible solution for the integration of remoteservices into the OSGi framework can be achieved.

2. EXISTING APPROACHESTwo ways of dealing with remote devices are already de-

scribed in the OSGi specifications. The R3 specificationsintroduced services for interaction with UPnP and Jini in-frastructures. Although the Jini service is no longer con-tained in the R4 specifications, it is discussed here for thesake of completeness. In the following section, we brieflycharacterize the two technologies and describe the implica-tions in the context of OSGi services.

2.1 JiniThe basic idea behind Jini [13, 10] is to provide a run-

time infrastructure for federating distributed services withina network. The central point in any Jini communication isthe Lookup Service (LUS). In a first step (discovery), peershave to find a LUS. Either they have preconfigured knowl-edge about the LUS or they perform multicast discoveryto find one within their subnet. The discovery returns amarshalled net.jini.core.lookup.ServiceRegistrar ob-ject which is a Java RMI proxy for the LUS. In the secondstep (join), a peer publishes all own services to the LUS. Inthe lookup step, peers can find services that match specificservice interfaces, attributes, or that have a specific knownservice ID.

Although the Jini specifications do not impose a specificprotocol for the communication with the services itself, theSun implementation requires RMI for contacting the LookupServer. In many existing deployments of Jini, people useRMI for all communication. This violates the generality ofthe OSGi Jini Service since RMI is not part of any standardexecution environment. In practice, especially small mobileand embedded devices often don’t have RMI.

The OSGi service described in the R3 specifications de-fined the export of OSGi services to Jini and the import ofJini services into OSGi. However, in practice, implemen-tations of this service turned out to be fairly invasive. Onereason is that the attributes in Jini are arrays of Objects im-plementing the Entry interface whereas in OSGi, attributesare modeled as key/value pairs of arbitrary types. There isno straightforward way of mapping OSGi properties to En-tries and vice versa to preserve the sophisticated matchingcapabilities of OSGi. Additionally, the possibility to publisha service only under specific interfaces is not given in Jini.A service object is always accessible under all its interfaces,there is no way of selectivity. The requirement of a cen-

tral Lookup Server furthermore limits the usability of Jiniin patterns of spontaneous interaction and imposes a signif-icant amount of configuration and managed infrastructure.

2.2 UPnPUPnP [12] is an industry standard for service-oriented in-

teraction with consumer devices. It is frequently used inubiquitous environments. UPnP is based on well-establishedstandards like HTTP, XML, and SOAP. The UPnP Forumspecifies device profiles for common applications. Each de-vice can specify one or more services which consist of actions(equivalent to service methods in OSGi) and events for asyn-chronous notification of the clients. Furthermore, UPnP de-fines an addressing algorithm derived from Zeroconf [4] toallow spontaneous interaction in unmanaged network envi-ronments and a service discovery based on SSDP [2]. SSDPuses multicast HTTP messages for service advertisementsand searching specific services in the network. Devices andservices are described in description files which are XML-encoded and comply to an UPnP-specific schema. Fromthese descriptions, clients can derive the information aboutthe service interface and invoke actions. The invocation ofactions is based on SOAP messages.

The OSGi specifications define a UPnPDeviceService tofacilitate interaction with UPnP-enabled consumer devices.However, the services created by the UPnP base driver arehighly UPnP-specific and thereby limited. First, UPnP ser-vices can only make use of a subset of the standard SOAPdata types. It is furthermore not possible to pass complexJava objects as arguments for UPnP actions since extensivetype mapping is not supported. Events can be nicely inte-grated into the OSGi EventAdmin service. However, UPnPdoes not allow to subscribe to specific events. Clients al-ways have to subscribe to all events. Additionally, the highverbosity of the XML format and the SOAP envelopes leadto a significantly decreased performance compared to binaryprotocols like Java RMI.

In conclusion, OSGi is an ideal environment for buildingUPnP devices since the UPnPDeviceDriver is much more in-tuitive to use and well-integrated into Java than many otherUPnP stacks. However, UPnP is not ideal for distribut-ing OSGi applications since it severely limits the richness ofOSGi services.

3. DISTRIBUTED OSGIThe experience with UPnP and Jini has shown that none

of the two approaches is ideal when it comes to the federationof distributed OSGi frameworks. The challenge of bridgingindependent OSGi frameworks is to model the interactionbetween the services of the individual peers as well as tak-ing care of module-layer dependencies among the providingbundles. An ideal approach would be to have a middlewarelayer that allows multiple peers with local OSGi frameworksto be federated in such a way that they behave like one largeOSGi framework. For doing so, some key requirements canbe stated:

• Transparency : For each local OSGi framework, thedistributed character of the whole federation shouldbe masked. Remote services should be accessible as ifthey were locally present in the framework.

• Non-Invasiveness: The middleware should not imposeany restrictions on OSGi services. In particular, it

should be possible to use existing bundles and servicesin distributed setups without any need for modifica-tion.

• Consistent Behavior : The default behavior of OSGiservices should not be influenced by the distribution.The perspective of a remote peer on a service has tobe the same as that seen by an entity within the localframework.

• Spontaneous Interaction: It should be possible to fed-erate OSGi-enabled peers in a spontaneous way, avoid-ing any preconfiguration or management.

• Statement of Supply and Demand : To allow for mas-sively distributed setups, for instance, the Internet, ithas to be ensured that a certain level of selectivity forthe interaction is possible. It has to be avoided thata peer is overwhelmed by the number of available ser-vices and thereby rendered inoperable.

• Generality : The OSGi specifications cover a large rangeof computing devices. In particular, the lightweightdesign of the OSGi architecture allows frameworks torun on very resource-constrained devices. Therefore, amiddleware for distribution should not limit the con-figurations where OSGi can be used.

4. R-OSGIWe have started to address these requirements in our on-

going research project R-OSGi1. The following section dis-cusses the fundamental design principles of R-OSGi and howthey are intended to cope with the challenges arising fromdistributed OSGi setups.

4.1 Service DiscoveryAs stated before, spontaneous interactions is a key re-

quirement, especially when it comes to mobile devices in-terconnected by networks with little management, such asad-hoc networks. In such an environment, no preconfiguredknowledge about the location of particular services can beassumed. The same is true for consumer electronic net-works, for instance, in smart home environments. Thesenetworks have to be extensible without requiring an unrea-sonable amount of technical education from the end-user.One possible way out is the use of service discovery proto-cols. This allows peers to explore their environment and finduseful services to extend their own functionality.

In R-OSGi, we make use of the Service Location Protocol(SLP) described in RFC 2608 [5, 3]. This protocol is well-established in the area of system administration and hasseveral advantages over comparable approaches. First, it isa binary protocol with a small message size, thereby makingit suitable for setups with restricted network bandwidth andresource-constrained devices. Second, it can operate with acentral service broker (DA, Directory Agent) and in peer-to-peer setups by using a multicast convergence strategy. Lastand most important, the notion of services in SLP is veryclose to the one used in OSGi. SLP services are describedby a ServiceURL, consisting of a service type and a URLaddress. Furthermore, SLP services can have key/value at-tributes and requests support LDAP-style filter predicates

1http://www.iks.inf.ethz.ch/projects/

on these attributes. It is hence possible to create an un-ambiguous one-to-one mapping from OSGi services to SLPservices.

R-OSGi uses such a mapping to announce OSGi servicesto surrounding peers. To avoid scalability and security is-sues, some entity within the framework has to explicitlymark a service to be released for remote access. This isdone by setting a specific remote property in the serviceproperties. To preserve a non-invasive character, it is notrequired that this is done by the service providing bundleitself. R-OSGi also facilitates adapter bundles to make sur-rogate remote registrations. The registration of services forremote access is referred to as statement of supply.

Bundles can register Discovery Listeners to express theirdemand for services implementing a certain interface and/ormatching a specific filter predicate. This fully complies withthe known patterns from OSGi frameworks. The registra-tion of discovery listeners forms the statement of demand.

R-OSGi is in charge of exploring the environment by theuse of the SLP protocol and to match supply and demand.If such a match is detected, the corresponding discoverylistener that has stated the demand is called and the ap-plication can explicitly decide whether a connection to thesupplying peer should be established.

4.2 Network ChannelsConnections in R-OSGi are implemented by network chan-

nels. Each channel is a one-to-one connection between twopeers, as shown in Figure 1. Upon establishment of a net-work channel, the two peers exchange symmetric leases thatcontain their statements of supply in terms of offered ser-vices and their demands in terms of event topics the peer isinterested in. The details about remote events are discussedin section 4.6. Different to Jini, leases in R-OSGi have nobuilt-in expiration. By design, they only have to be unilat-erally renewed when either the supply or the demand hasundergone a change. Otherwise, leases are valid unless thechannel is closed, either intentionally or due to a permanentnetwork failure. Besides service discovery, peers can alsodirectly connect to known service providers. One possibleapplication is wide-area distribution over the Internet whereservice discovery is not feasible.

By default, network channels are implemented as persis-tent TCP connections. This allows maximum performancefor service invocation and event delivery since the overheadof the TCP handshake is only required once. The extensibledesign of R-OSGi, however, facilitates to plug in alterna-tive protocols and network transport. One example for thisis the implemented HTTP(S) network channel discussed inSection 4.8.

ChannelEndpoint ChannelEndpoint

R−OSGi R−OSGi

TCPChannelTCPChannel

Ser

vice

A

Ser

vice

B

Ser

vice

1

Pro

xy 1

Pro

xy A

TCP

Peer Peer

Figure 1: R-OSGi Network Channels

4.3 Proxy GenerationOnce the application has established a network channel

to a peer, it can decide to fetch the service matching its re-quirements. The fetching basically involves the transmissionof the service interface and the service attributes. This isthe minimum amount of information required to access a re-mote service by building a service proxy. Proxy generationis implemented using bytecode manipulation based on thelightweight ASM library [1]. The service interface is takenand a class is created on the fly which implements everymethod described in the interface as a remote method invo-cation. Additionally, the class implements BundleActivatorto integrate into the OSGi lifecycle management. Duringregistration of the remote service, the type injections havebeen determined. These are described by the minimal setof types that have to be injected in order to make a ser-vice proxy operable, providing that the proxy is allowed toimport any package that is also imported by the originalservice. The injections are transmitted as part of the fetch-ing and materialized together with the proxy class into aproxy bundle. This proxy bundle now provides the remoteservice to the framework and redirects every method call tothe original service.

On a first view, it might appear eligible to overcome thelimitation that under certain conditions, the proxy bundlehas to import some packages to make the service interfaceresolvable. Instead, it would be possible to additionally in-ject all imported packages to make the proxy bundle self-contained. However, for real applications, this potentiallyinvolves a large number of classes and packages. Since tooextensive injection can significantly increase both the net-work bandwidth consumption and the footprint of the proxybundle, this strategy is not followed by R-OSGi.

4.4 Method InvocationMethod invocation in R-OSGi uses its own message-based

protocol. The R-OSGi service features a generic methodwhich is called by every proxy method in a reflective style.This successively leads to the transmission of a specific mes-sage that transfers the description of the called method (ser-vice URL and method signature) together with the argu-ments of the call to the remote peer. On the service providerside, the original service method is then called. This eithersucceeds and possibly results in a return value, or an excep-tion might be thrown. In either case, a response messageis generated and sent back to the calling peer. The proxymethod now either returns the result or throws the deserial-ized exception object. This models the exact behavior thata local service method would have.

One obvious limitation is that the formal parameter ofremote services have to be serializable. This is known frommany other remote invocation mechanisms and can cur-rently not be easily avoided in R-OSGi. Under some circum-stances, it is, however, possible to add the serializability toexisting classes by applying load-time AOP.

Since Java already contains RMI for remote invocation, ithas to be justified not to make use of it in R-OSGi. Severalreasons have led to this design decision. RMI is not availableon every CDC platform. Even if it is available, the perfor-mance of these implementations is often unsatisfying. Differ-ent to ordinary remote objects, service objects in OSGi havea well-defined lifecycle, thereby not requiring the overheadof mechanisms like distributed garbage collection (DGC).

Furthermore, the well-defined lifecycle allows to keep thepersistent connection open for a longer period, thereby re-ducing the overhead of additional TCP handshakes. In ourpreliminary experiments, the remote invocation of R-OSGiis in average faster and scales better than the highly opti-mized RMI implementation in Java 5.

4.5 Smart ProxiesBy using service proxies, the major load of the service re-

mains on the service providing peer. This is sometimes notthe favored behavior, especially when the service provider is,for instance, a resource-constrained ubiquitous device offer-ing services to a potentially large number of clients. R-OSGiallows to use smart proxies to overcome this and ship partsof the service code to the client. In the properties of theservice registration used to publish the remote service, anadditional abstract class implementing the service interfacecan be defined to be the smart proxy. This smart proxyclass is transferred to the client. All implemented methodsremain untouched, whereas the abstract methods are imple-mented as remote invocations in the usual manner. Withan elaborated design, it is possible to solve complex prob-lems where services perform parts of the tasks locally usingthe resources and configurations of the clients. A simpleexample for this pattern can be seen in Listing 1.

Listing 1: Smart Proxy Examplepackage sample . s e r v i c e ;

import sample . ap i . S e r v i c e I n t e r f a c e ;

public abstract class SmartServiceimplements S e r v i c e I n t e r f a c e {

public void l o c a l ( S t r ing s ) {// do some l o c a l opera t i onsSystem . out . p r i n t l n ( ”Local opera t i on ” ) ;remote ( s ) ;

}

public abstract void remote ( S t r ing s ) ;

}

4.6 Remote EventsEvents are a known technique from the UPnP world to

allow for asynchronous notification. Since OSGi R4 featuresa standard way of handling events, R-OSGi has been inte-grated to make use of the EventAdmin service. On eachpeer, the topic space is determined from the intersectionof all registered EventHandlers. As part of each channelendpoint, an additional event handler is registered whichforwards all topics matching the topic interest of the otherside of the channel. Thus, bundles making use of the eventhandling infrastructure of OSGi can be transparently dis-tributed. The registration of a new event handler on anR-OSGi enabled peer that extends the topic space leads toan update of the leases and to a modification of the eventhandler registered by the channel endpoint.

4.7 PresentationsAn additional feature of R-OSGi is the transmission of

presentations. The idea of a presentation is to ship a userinterface together with the service. This user interface canbe displayed using the R-OSGi ServiceUI bundle. The usecase for presentations is the controlling of smart devices.Instead of requiring the user to install a device driver on eachcontroller device, R-OSGi and presentations can be used tolet the device itself provide a user interface for interaction.In spontaneous setups, e.g., a PDA can be used to controlan arbitrary number of previously unknown devices that aredynamically discovered. The IKS Lego Mindstorms Robotsdescribed in section 5.1 are an example for this idea.

Currently, presentations are transmitted as prefactoredAWT Panels. However, the diversity of end devices and thedifferent capabilities, for instance, in terms of display sizesand resolutions let this approach appear not really feasiblefor the general purpose. As part of future work, we intendto address this issue and come up with a more declarativeway of describing user interfaces that can be rendered onthe client device with respect to the particular capabilitiesof the hardware.

Figure 2: R-OSGi Presentation of a Smart Device

4.8 Alternative network channelsIn massively distributed setups and in wide area networks,

it is sometimes a requirement that the network protocol isable to pass firewalls. R-OSGi therefore allows to plugin al-ternative channel implementations which piggyback the na-tive R-OSGi messages. As part of our research project, wehave implemented such a channel for HTTP(S). The ideais to provide NetworkChannelFactories that can be regis-tered in a whiteboard manner to be responsible for a spe-cific set of protocols. Whenever a connection using a non-standard protocol is requested, the corresponding externalfactory is called to return a custom NetworkChannel object.It is even possible to transparently wrap completely differ-ent (e.g. non-IP-based) ways of network transport like, forinstance, Bluetooth. Service providers have to additionallyprovide a bridge which accepts incoming connections of thecustom protocol or transport type and forwards the piggy-backed R-OSGi message to the R-OSGi service. An example

setup is given in Figure 3 A simple API allows to rewriteall ServiceURLs appearing in R-OSGi messages to restampthem to the address and port of the bridge.

TCPChannelHttpService

ChannelEndpoint

HttpChannel

Service Client

ChannelEndpointBridgeServlet

Service ProviderClient

Http TCP

R−OSGi R−OSGi

Service

TCPChannel

Figure 3: R-OSGi over HTTP

The interesting property of the HTTP(S) integration isthe constraint that the protocol is entirely based on a re-quest/response pattern whereas R-OSGi allows asynchronouscallbacks by the server-side-equivalent through events. Thisproblem is known from web services and typically solved byrequiring the client-side-equivalent to also provide a serverpart that handles the callback. In R-OSGi, we have solvedthe problem differently. The bridge servlet on the serviceprovider side catches the lease message and replies witha multipart-encoded response that is not closed unless thelease expires. This delayed response allows to send follow-ing events as new chunks of the response. This solution iscompliant with the standard and works with both firewallsand client-side NAT.

4.9 Alternative policiesAlthough the use of proxy bundles in some flavor is the

default behavior of the system, it also supports alternativeways of distributing services. Currently, also whole bun-dles can be migrated to remote peers. For the moment, thisonly involves stateless migration of bundles but it is partof future work to integrate this policy with the Configura-tionAdmin to allow for stateful migration of OSGi bundles.One possible use case for this is adaptive load balancing forapplications of server-side OSGi.

5. EXAMPLESTo further explain the powerful features of R-OSGi, the

following section discusses some example applications thathave been implemented using distributed OSGi.

5.1 IKS Lego Mindstorms RobotsThe Lego Mindstorms Robots (Figure 4) are an ongo-

ing student lab project which is running for several yearsnow. The robots are controlled by either an iPAQ, or themost recent version by a Linksys NSLU2 (Slug). The con-troller device communicates with the Lego RCX and trans-mits macros which are then executed. The robots can followthe lines painted on the floor and execute simple tasks likemoving to the next junction, turning, etc. In our recentsetup, the Slug runs Java, the Concierge [9] OSGi frame-work and the R-OSGi service. All controlling is performedby a RobotDevice service (Listing 2) which can be trans-parently accessed by end devices connected through 802.11WLAN. The service has an attached presentation which canbe displayed by the ServiceUI. We use PDA devices to spon-taneously discover robots, connect to the robots, and remote

control them. Each PDA can control multiple robots andenqueue tasks that they perform in sequential order.

Figure 4: IKS Lego Mindstorms Robot

Listing 2: Robot Service Interfacepackage ch . ethz . i k s . robot . ap i ;

public interface RobotDevice {

public stat ic f ina l St r ing ROBOT TOPIC =”ch/ ethz / i k s / robot /” ;

public void turnRight ( ) ;

public void turnLe f t ( ) ;

public void goForward ( int un i t s ) ;

public St r ing getQueue ( ) ;

}

5.2 Sensor NetworksThe SwissQM project [6, 7] is a novel approach for wire-

less sensor networks based on the idea of having a virtualmachine on each node. A gateway device connected to thesensor network generates bytecode programs from declara-tive queries on a gateway to allow users to gather data in amore intuitive and flexible way. The programs are dissemi-nated in the network and return the data required to answerthe queries. By having bytecode programs, processing canbe pushed down into the network, thereby reducing the mes-sage complexity. One of the unique features of SwissQM isthe possibility to include user defined functions (UDFs) inqueries, similar to relational database systems.

In a development branch of SwissQM, we have used R-OSGi to integrate the gateway functionality into Eclipse.The high flexibility of the system required development sup-port by a commonly used and intuitive IDE. An Eclipse plu-gin allows to write user defined functions and store querieson an arbitrary machine and interact with a remote SwissQMgateway. Furthermore, the gateway returns the result tuplesto the development machine and the Eclipse plugin is able

to visualize the data (Figure 5). This facilitates rapid proto-typing and debugging of queries and functions. R-OSGi is incharge of handling the communication between the Eclipseenvironment and the gateway machine, as shown in Figure 6.For the plugin, the gateway appears as an ordinary OSGiservice. In this branch, SwissQM is able to be extended bysupport for parsing arbitrary high-level languages and com-piles OSGi bundles from the queries and function code con-taining language-independent intermediate representations.This additionally allows to explicitly influence the lifecy-cle of individual queries and functions remotely through theEclipse Plugin. To offer access from firewalled networks, theSwissQM Plugin uses R-OSGi over HTTP.

Figure 5: SwissQM Eclipse Plugin

Gateway Service Proxy

QueryBundle B QueryBundle A

SQL Language Handler

UDF Bundle

C UDF Handler

MoteCom Inteface

Platform Bundle

SwissQM Eclipse Plugin

R−OSGi

Gateway

Peer

Gateway Service

Bytecode Generation

Query Merging

Dissamination

uses

generates

executed by

generates

uses

uses

sends to sends to

Optimization Optimizer Implementation

Sensor Network

Figure 6: Architectural Overview

5.3 Fluid ComputingTraditional systems have a strong locality of data. Dis-

tributed applications typically store the shared data at well-defined locations, such as an application server or a database.The idea of fluid computing is to allow data to flow throughthe network. If a peer is disconnected, offline operationsare recorded and reconciled with the global state if the peerreturns to the network. In the flowSGi project [8, 11], weexplore the possibilities to extend this kind of flexibility towhole applications. What goes far beyond previous projectsin this area is the idea that also the application should befluid, thereby allowing to start the work on one device andthen seamlessly migrate the whole application together withits state and data to a different peer. Furthermore, it is pos-sible to work concurrently from many peers on the same datawith federated devices. In such a setup, each device providesits unique capabilities to perform a specific part of the ap-plication. R-OSGi is one of the key technologies required toachieve this. It is used to handle the communication on themiddleware layer and to make the different peers interactand behave like one single entity.

6. REFERENCES[1] E. Bruneton, R. Lenglet, and T. Coupaye. ASM: A

Code Manipulation Tool to Implement AdaptableSystems. Technical report, France Telecom R&D,November 2002.

[2] Y. Y. Goland, T. Cai, P. Leach, Y. Gu, andS. Albright. Simple Service Discovery Protocol(Expired Internet Draft). IETF, October 1999.

[3] E. Guttman. Service Location Protocol: AutomaticDiscovery of IP Network Services. IEEE InternetComputing, 3(4):71–80, 1999.

[4] E. Guttman. Autoconfiguration for IP networking:enabling local communication. Internet Computing,IEEE, 5(3):81–86, 2001.

[5] E. Guttman, C. Perkins, and J. Veizades. RFC 2608:Service Location Protocol v2. IETF, June 1999.

[6] R. Muller and G. Alonso. Efficient Sharing of SensorNetworks. In MASS, 2006.

[7] R. Muller, G. Alonso, and D. Kossmann. SwissQM:Next generation data processing in sensor networks. InCIDR, 2007.

[8] J. S. Rellermeyer. flowSGi - a Framework for DynamicFluid Applications. Master’s thesis, ETH Zurich, 2006.

[9] J. S. Rellermeyer and G. Alonso. Concierge: A ServicePlatform for Resource-Constrained Devices. InProceedings of the EuroSys 2007 Conference, 2007.

[10] Sun Microsystems. Jini Specifications v2.1, October2005.

[11] The flowSGi Project.http://www.flowsgi.inf.ethz.ch.

[12] UPnP Forum. Universal Plug and Play DeviceArchitecture, June 2000.

[13] J. Waldo. The Jini architecture for network-centriccomputing. Communications of the ACM, 42(7):76–82,1999.