A dynamic Architecture for Pervasive Computing

Andreas Frei, Gustavo AlonsoDepartment of Computer Science

Swiss Federal Institute of Technology ZurichCH-8092 Zurich, Switzerland{frei, alonso}@inf.ethz.ch

Abstract

Pervasive Computing infrastructures have become widespread and sensors are getting in-creasingly smaller. PDAs or mobile phones are already used everywhere. But many applicationshave not yet taken mobility and pervasiveness into account. Due to teh lack of an appropri-ate supporting infrastructure. At ETHZ we have developed a new infrastructure for pervasivecomputing - Jadabs. Jadabs has a small footprint core layer and a modularized pluggable dis-tributed architecture. It builds upon the service oriented architecture of OSGi and combines itwith a dynamic Aspect Oriented Programming approach. The combination allows designers todynamically plugin and adapt distributed applications.

1 Introduction

Devices used in Pervasive Computing range from small sensors to laptops and PDAs [12]. Togetherwith mobile phones and other wearable devices, they can be combined to form a Personal AreaNetwork (PAN) (Figure 1). PANs are affected by resource constraint devices, frequent connectionloss, or high heterogeneity in devices, systems, and programming paradigms. Moreover, adaptabil-ity to changes (bandwidth, peers, network conditions, services) and the constant change from oneenvironment to another (different base stations, different domains, ad hoc networks, etc.) is one ofthe biggest challenges that PANs face today.

To address these problems, we have developed a new architecture for small devices which bor-rows concepts already known from enterprise environments. In such environments, J2EE containerslike JBoss [10] or Weblogic [2] play an important role. They support the deployment of new JavaEnterprise Beans without restarting the whole container. These containers are now being extendedwith Aspect Oriented Programming (AOP) functionality [7, 3] to allow already running applicationsto be extended with new functionality. The combination of container architecture and dynamicAOP has already been used in infrastructure environments [22]. Yet, all of these solutions are basedon enterprise computing and lack the possibility to be run on small devices. In order to create adynamic architecture for resource constrained devices, we have created a dynamic lightweight con-tainer for such devices. In addition, to be able to deploy new components in an ad hoc environment,a peer to peer architecture is used for the container. Figure 2 shows the architecture with a localapplication on the left side and a distributed application stack on the right. Since applicationsare dynamically assembled out of components placed in the container, at run time, we call ourarchitecture Java ADhoc Application BootStrap - Jadabs.

By using this architecture we are able to dynamically adapt an application to the device’scapabilities and to changes in the computing environment.

This extended abstract is organized as follows. In section 2 we describe the architecture ofJadabs and the implementation for the core layer. Section 4 concludes the paper with a summaryand future work.

1

Internet

Sensor/Activator

Network

PAN/Gateway

Local Network

Remote Network

GSM

IEEE 802.11x

IEEE 802.15.4/

ZigBee

Gateway

Figure 1: Pervasive Computing Infrastructure

2 System Architecture

Currently our architecture targets devices ranging from mobile phones to PDAs to Laptops. Thatis, the layers on top of the sensor/activator framework shown in Figure 1. We must therefore meetthe following requirements: reduced footprint, dynamic adaptation, flexible architecture.

Hosting SystemJ2ME/JRE

Core/Container

dynamic Resources

Messaging-API/XML

Event System/Types

dAOP/NanningOSGi/Knopflerfish

UDP TCPBT ...Dispatcher

Discovery

Messenger/Application

Distributed InfrastructureLocal Application

AspectComponent

App.GUI

ManagerServiceImpl

Service

Registry

Service Provider

Service

Client

1. Register a service

description2. Lookup a

service

3. Bind to the

service

Figure 2 Jadabs layers and dynamic

Resources

Figure 3 Service Oriented Architecture (SOA)

Figure 2 shows the architecture of Jadabs. On the base layer we support currently J2ME andthe normal Java Runtime Environment. J2ME is a subset of the JRE and can be further dividedinto the Connected Limited Device Configuration (CLDC) and the more enhanced CDC. Whereasthe CDC VM runs on a PDA, the CLDC can be run on mobile phones.

The architecture has been divided into a core layer and a set of dynamic resources. The corelayer acts as container for the dynamic resources. The resource layer contains applications whichare dynamically built out of components. This layer is able to load and unload components atruntime without disrupting the applications.

The core layer supports both a Service Oriented Architecture and a dynamic Aspect OrientedProgramming environment. The Service Oriented Architecture (SOA) (Figure 3) allows to developcomponents independently of each other. A Service Provider component registers the visible partof its component, the Service, in its local registry (Figure 3, 1). A Service Client component is

2

then able to lookup the registered service (2) and bind to the Service Implementation (3). Bindingand lookup are done locally and no registry service is needed. A SOA significantly improves thedecoupling of components. On the other hand it does not fully solve dynamic adaptation. A servicewhich is going to be adapted with new functionality has to be stopped and restarted. This leadsto state loss. Another disadvantage is the need to check at the service client side if the service isstill available before a call is made. Therefore we propose a combination with a second conceptknown as dynamic Aspect Oriented Programming (dAOP). For the Service Oriented Architecturewe chose the Open Service Gateway Infrastructure (OSGi) [19] implementation of Knopflerfish [14].Knopflerfish has then been integrated with Nanning [18], a dAOP implementation. By using thiscombination we are now able to dynamically adapt the behavior of registered services at runtime.By registering the service interface as a potential AOP service an appropriate proxy is generatedat run time. This allows later on to extend the service interface with AOP crosscutting and doadvice calls like before, after, or around.

With the core layer as a basis, the dynamic resource layer is now capable of dynamicallychanging the application or the distributed infrastructure. Such change may be, e.g., loading a newcomponent or adapting one with new behavior. Figure 2 shows two application stacks. On the leftside a local application is shown. Applications are incrementally built out of different components.The core layer can therefore be very well used for only local applications to take advantage of theSOA and dAOP concepts. By including a manager component the local applications can then beconfigured. To use our dynamic container in a mobile environment a distributed infrastructureis required (Figure 2 right application stack). This solves our third requirement of a flexiblearchitecture. The infrastructure itself may be adapted to the computing environment.

The two application stacks shown are just two examples. It is for example possible to transformthe application stack into a distributed infrastructure at runtime.

2.1 Distributed Infrastructure

The proposed dynamic lightweight container can now be used to build applications out of differentcomponents. Our main target is the distributed mobile infrastructure, shown on the right side ofFigure 2. Adding new components or changing the behavior of running services are then performedtransparently to the user.

The peer to peer implementation takes over concepts from JXTA [4, 13]. By disassemblingtheir layers and taking over the core functionality we get, instead of one big package, many smallercomponents which can be plugged together as required. This flexible architecture allows to uselarger distributed concepts in resource constraint devices.

The first layer of the distributed infrastructure of Jadabs is a basic messaging module to allownodes to communicate with each other through a simple message interface. The interface is relatedto JXTA’s JXME which implements a proxy-less messaging layer for small devices running onJ2ME/CLDC. As this layer is very general and independent of an RPC communication layercommunication can be set up in an ad hoc manner also with platforms other than Java. So farewe have implemented this layer for different communication interfaces. For normal LANs, a TCPconnection is used. For wireless LANs an UDP connection is chosen. Devices with Bluetooth, e.g.,a mobile phone, are also supported.

The message layer which only operates on simple messages has been extended with the eventsystem layer. This additional module adds a type system on top of the messaging layer and allowsto publish and subscribe to events. The publish and subscribe model is based on the concepts of[5, 6, 11] and the type- and attribute-based subscription model of [21, 1]. The event system hasbeen designed as a dynamic AOP service and is registered at activation time through the proxy.This allows to change the event system API at run time depending on new requirements.

3

3 Related Work

The trend to smaller component containers then J2EE have already started by many projects. Bybuilding up a container on a micro kernel the middleware can get much smaller and has to activateonly those components needed. Merlin [16], JBoss [10], and Spring [23] are going in this direction.Even though their micro kernel is getting smaller, in case of JBoss about 650 KBytes and Spring300 KBytes, they still rely on services available only in large infrastructures like JNDI in JBoss orheavy use of XML in Merlin and J2EE services in Spring. Spring includes a similar dynamic AOPapproach as proposed in Jadabs.

Micro-kernel architectures which also fit into smaller devices are available from OSGi [19],the Open Service Gateway infrastructure, or Fractal [8] from ObjectWeb. Fractal and OSGi aresimilar in the service binding concept whereas OSGi defines more services for an ad hoc serviceinfrastructure like Jini and UPnP. OSGi has been chosen due to its wider acceptance in bothindustry as well as in the open source community.

ReMMoC [9, 20] is a reconfigurable reflective middleware to support mobile application develop-ment. It uses OpenCOM [15] as its underlying component technology. OpenCOM is implementedin C++ and available for a few platforms. An upcoming new release should support more plat-forms based on XPCOM [17]. ReMMoC is a similar platform for mobile devices as proposed in thispaper, but based on C++. Whereas Java has become a de facto standard, no dynamic lightweightplatform exists to such a large extend as proposed. By using Java a large pool of already existingapplications and components can be run on top of the core layer. Furthermore, we propose adistributed infrastructure based on JXTA which enables peer to peer concept independently of theunderlying technology.

4 Conclusion

With Jadabs we propose a dynamic architecture for pervasive computing for resource constraintdevices. By combining the service oriented architecture of Knopflerfish, an OSGi implementation,and a dynamic AOP approach, Nanning, Jadabs acts as a dynamic lightweight container. Jadabshas a footprint of about 300 KBytes. For the distributed infrastructure we took over conceptsfrom JXTA a peer to peer infrastructure. As JXTA is to big for small devices our goal has beento integrate their concept with pluggable services to download and activate them when required.This leads to smaller distributed infrastructure which can be run on small devices. The dynamiclightweight container is therefore the core to bootstrap the distributed architecture.

We are now in the progress of integrating a sensor and activator network into a completepervasive infrastructure scenario. As shown in Figure 1 a gateway acts as an intermediate node.This allows other nodes from higher layers or the Personal Area Network to interact with the sensorand activator network. The gateway with about the same functionality as an iPAQ runs then ourJadabs architecture. This integrates the gateway and therefore its controlled sensor and activatornetwork into the pervasive infrastructure.

References

[1] Sebastien Baehni, Patrick Th. Eugster, and Rachid Guerraoui. OS Support for P2P Program-ming: a Case for TPS. In Proceedings of the 22 nd International Conference on DistributedComputing Systems (ICDCS’02), Vienna, Austria, July 2002.

[2] BEA. WebLogic. http://www.bea.com.

[3] Jonas Boner and Alexandre Vasseur. AspectWerkz. http://aspectwerkz.codehaus.org.

[4] Daniel Brookshier, Darren Govoni, and Navaneeth Krishnan. JXTA: Java P2P Programming.SAMS, March 2002.

4

[5] G. Cugola, E. Di Nitto, and A. Fuggetta. The JEDI event-based infrastructure and its appli-cation to the development of the OPSS WFMS. IEEE Transactions on Software Engineering,27(9), 2001.

[6] Ludger Fiege, Mira Mezini, Gero Muhl, and Alejandro P. Buchmann. Engineering event-based systems with scopes. In B. Magnusson, editor, Proceedings of the European Conferenceon Object-Oriented Programming (ECOOP), volume 2374 of LNCS, pages 309–333, Malaga,Spain, June 2002. Springer-Verlag.

[7] Marc Fleury and Francisco Reverbel. The JBoss Extension Server. In Proceedings of the 4thACM/IFIP/USENIX International Middleware Conference, pages 343–373. Springer-Verlag,June 2003.

[8] Fractal. ObjectWeb, Open Source Middleware, 2004. http://fractal.objectweb.org/.

[9] Paul Grace, Gordon S. Blair, and Sam Samuel. Middleware Awareness in Mobile Comput-ing. In Proceedings of the 23rd International Conference on Distributed Computing SystemsWorkshops (ICDCSW’03).

[10] JBoss Group. Jboss. http://www.jboss.org.

[11] M. Haupt, M. Mezini, M. Cilia, and A. P. Buchmann. Towards Event-Based Aspect-OrientedRuntime Environments. Technical Report TUD-ST-2002-01, Software Technology Group,Darmstadt University of Technology, Alexanderstrasse 10, 64289 Darmstadt, Germany, 2002.

[12] Jason Hill, Mike Horton, Ralph Kling, and Lakshman Krishnamurthy. The platforms enablingwireless sensor networks. Commun. ACM, 47(6):41–46, 2004.

[13] JXTA Project. http://www.jxta.org.

[14] Knopflerfish OSGi. http://www.knopflerfish.org.

[15] G. Coulson N.Parlavantzas M. Clarke, G. Blair. An Efficient Component Model for the Con-struction of Adaptive Middleware. In Proceedings of Middleware 2001, November 2001.

[16] Merlin. The Apache Avalon Project, 2004. http://avalon.apache.org/merlin.

[17] Mozilla . XPCOM. http://www.mozilla.org/projects/xpcom/.

[18] Nanning Aspects. http://nanning.codehaus.org.

[19] OSGi, Open Service Gateway Initiative. OSGi Service-Platform. IOS Press, release 3 edition,March 2003.

[20] S. Samuel P. Grance, G. Blair. Interoperation with Servies in a Mobile Environment. TechnicalReport MPG-03-01, Lancaster University, 2003.

[21] P. Pietzuch and J. Bacon. Hermes: A Distributed Event-Based Middleware Architecture.In Proceedings of the 22 nd International Conference on Distributed Computing Systems(ICDCS’02), Vienna, Austria, July 2002.

[22] Andrei Popovici, Gustavo Alonso, and Thomas Gross. Spontaneous Container Services. InProceedings of the 17th Europeean Conference for Object-Oriented Programming, pages 29–53.Springer-Verlag, July 2003.

[23] Spring. Java/J2EE Application Framework, 2004. http://www.springframework.org.

5