Building, Deploying, and Monitoring DistributedApplications with Eclipse and R-OSGi∗

Jan S. Rellermeyer Gustavo Alonso Timothy RoscoeDepartment of Computer Science

ETH Zurich8092 Zurich, Switzerland

{rellermeyer, alonso, troscoe}@inf.ethz.ch

ABSTRACTDesigning and testing distributed applications is still a dif-

ficult task that requires in-depth knowledge about network-ing issues. Eclipse is, among other things, a powerful andwidely used IDE for the development of complex applications,in particular modular applications for the OSGi framework.Our R-OSGi middleware supports the seamless distributionof OSGi applications along the boundaries of services. Bycombining R-OSGi with Eclipse into the R-OSGi Deploy-ment Tool, we give developers a tool that automatically han-dles distribution in a transparent way and integrates the ca-pabilities of R-OSGi into the Eclipse workflow. With thistool, building, deploying, and monitoring distributed appli-cations is as easy as writing OSGi applications in Eclipseand using a graphical editor to visually create distributed de-ployments of the modules. The tool can also be used to greateffect by researchers to test and benchmark distributed ap-plications and for education purposes.

Categories and Subject DescriptorsC.2.4 [Computer-Communication Networks]: DistributedSystems—Distributed Applications; D.3.3 [ProgrammingLanguages]: Language Constructs and Features—Modules,Packages; K.6.m [Management of Computing and In-formation Systems]: Miscellaneous

General TermsDesign, Management

KeywordsR-OSGi, OSGi, Deployment, Eclipse, Concierge

1. INTRODUCTIONThe Eclipse platform for building, deploying, and manag-

ing software is increasingly based on the OSGi standard [8]for module management in Java: the platform itself is com-posed of a variety of OSGi modules, and is extensible through

∗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.

Copyright is held by the author/owner(s).Eclipse Technology Exchange (ETX) Workshop ’07, October 21–25, 2007,Montréal, Québec, Canada.ACM .

plugins which are themselves OSGi bundles. Unsurprisingly,Eclipse also has built-in support for developing modular Javaapplications based on the OSGi standard. However, Eclipsedoes not currently provide support for remotely deployingan OSGi-based application to a node, or for building dis-tributed applications using OSGi.

In [10] we presented R-OSGi, an extension to OSGi thatallows the user to run modular software in a distributed fash-ion without changing the OSGi framework implementationor the application binaries: remote invocation proxies aretransparently interposed at distribution boundaries betweenmodules, and network or remote node failures are mappedto module unload events. The result is that modular OSGi-based applications can be written using OSGi bundles withlittle extra effort on the part of programmers.

In this paper, we present an Eclipse plugin that allowsdistributed R-OSGi applications to be deployed and man-aged from within Eclipse. When combined with R-OSGiitself, the R-OSGi Deployment Tool (RDT) turns Eclipseinto a powerful tool for developing, deploying, and monitor-ing distributed applications. The result is that developerscan build modular software with little concern for distribu-tion, and then use RDT to transform the resulting applica-tion into a distributed system. The contributions of RDTdescribed in this paper are as follows:

Firstly, RDT can analyze OSGi applications inside Eclipseand generate graphical representation based on Eclipse’sGraphical Editing Framework (GEF) [5]. Users of the toolcan turn this initial centralized deployment into a distributeddeployment by dragging and dropping bundles from one ma-chine to another. The resulting deployment description istransformed into tasks for R-OSGi.

Secondly, RDT exposes R-OSGi’s transparent support forload-balancing and fault-tolerance. Such facilities can beadded to existing applications with a few clicks, and theresulting system immediately deployed from Eclipse.

Thirdly, RDT can be used to visualize the structure andstatus of a running distributed application in real time, in-cluding such issues as node or network failures and concur-rency issues. As well as its use in a software managementcontext, this facility can be used to explore the impacts ofdifferent failure models and decide on appropriate fault tol-erance strategies.

Finally, RDT can capture all network messages and makethem available to the Eclipse user. These traces can beused by developers to for profiling, testing, debugging, andbenchmarking distributed applications throughout the en-tire development cycle.

Figure 1: Example Setup

2. THE DEPLOYMENT TOOLThe R-OSGi Deployment Tool for Eclipse consists of two

different parts: The actual Plugin which extends the EclipseIDE and the Deployment Agent in charge of distributeddeployment. Figure 1 shows an example consisting of the de-velopment machine running the Eclipse instance and threenodes running each an OSGi framework with R-OSGi andthe Agent. The graphical representation of the deploymentis transformed into sets of declarative tasks for each nodes.

The purpose of the Plugin is to add support to Eclipsefor creating deployment graphs from an existing OSGi ap-plication, allowing the user to modify the graph, and to vi-sualize the resulting application once it is deployed. TheDeployment Agent is the primary communication chan-nel between the Eclipse instance and the OSGi frameworksrunning on the nodes. It mainly features remote manage-ment commands and processes the tasks disseminated by thePlugin during the deploying step. Once the application isrunning, is also gives feedback about the application stateand the network traffic.

2.1 Code Analysis and Graph GenerationThe manifest of OSGi bundles explicitly declares package

imports and exports but does not give any information aboutthe services provided and consumed by a bundle. There-fore, the service dependency structure can be normally de-termined only from the running bundles of an application.In the R-OSGi Deployment Tool, we use code analysis toreason about the services used by bundles. Since the sourcecode of the application bundles is usually available when de-veloped in Eclipse, our tool uses the Abstract Syntax Tree(AST) maintained by Eclipse for every Java source code re-source.

As an initial step, the user specifies the main (root) bun-dle of the application through a wizard. Starting from thisbundle, an AST node visitor traverses the syntax trees of allsource files belonging to the bundle project to identify whichservices are registered (through context.registerService(...))and consumed (context.getServiceReference(...) and con-

text.getService(...)). For binary resources, the same could beachieved through bytecode analysis (e.g., using the ASM [1]library, also internally used by R-OSGi). The code analysisrecurses over all bundle dependencies of the root bundle.

The result of the analysis is the complete set of bundlesmaking up the application, together with information aboutthe registered and consumed services for each bundle. Inthe next step, the tool creates an initial deployment graphdepicting the structure of the application if it was launchedon a single OSGi framework.

2.2 Creating a Distributed DeploymentThis initial graph can be manipulated by the user to turn

the centralized application into a distributed one. New nodesrunning OSGi frameworks can be added to the graph. Thebundles of the application can be dragged and dropped fromone node to another, thereby changing the structure of thedeployment. Dependencies between the bundles on the levelof services are illustrated by connection arrows. The amountof connections between frameworks gives the developer al-ready a coarse estimation on how much network activity aspecific distribution setup might involve. Figure 2 showsthe Deployment Editor with an opened deployment of anapplication on three different nodes.

For each service which is accessed by remote frameworks,the R-OSGi middleware transparently creates a service proxyon the consumer peers which calls the original remote ser-vice. Dependencies on the level of package imports and ex-ports are automatically resolved by R-OSGi. Events raisedthrough the OSGi EventAdmin service are transparentlyforwarded to those nodes that have a corresponding Even-tHandler registered.

2.3 Advanced FeaturesThe Deployment Tool does not only facilitate the creation

of distributed applications out of software modules, it alsooffers to add advanced features such replicating modules forload balancing, or failover redundancy. The user can createredundant copies of bundles through the visual interface bydragging a bundle to a different node with the control keypressed. By default, these copies are unbound. With differ-ent GEF connection tools, the user can (graphically) bindthe services of this copy to consuming bundles and therebyspecify for which purpose the copy should be used. With ourtool, the implications of distributed failures can be testedand their impact on the running application evaluated. Foreducation purposes, different failure scenarios can be simu-lated by disabling nodes of the deployment, or by creatingnew channel implementations which simulate network fail-ures.

R-OSGi supports binding service proxies to a single pri-mary service and adding redundant remote services. If thefailover policy is defined for these additional bindings, R-OSGi will switch to the next service whenever the invoca-tion of the primary service fails due to unavailability or net-work failures. Two different load balancing strategies areselectable. The ONE strategy selects the best available ser-vice on the first invocation (the one with the least serviceproxies bound to it). The ANY strategy is intended to beused with stateless, idempotent services. With this strat-egy, the best available service is reselected with every newinvocation.

Figure 2: Deployment Editor

3. INTEGRATION INTO ECLIPSE

3.1 Task StructureIn a traditional OSGi application, the start order of bun-

dles does not depend on package imports and exports butis affected by the services that bundles exchange. If bundleB consumes a service provided by bundle A, A has to bestarted before B in the general case so that B will find theservice when it starts. Some bundles are designed to handlemissing services (e.g., leaving out certain features or delayingthe startup until the service is present) but this behavior isnot mandatory and depends on the degree of dynamics thatthe author of the bundle has taken into account.

In a distributed setting, these constraints cross the bound-aries of a single VM. The naive approach to start the lo-cal bundles, register every local service for remote accessand building a proxy for every remote service on each peer(thereby making the deployment a fully connected graph)does not work. If a bundle requires a service provided by aremote machine, the remote service bundle has to be startedprior to the start of the local bundle. In general, it has to beassured that not only the total order of bundle installationis preserved among the peers but also that the remote accessof services is established in the right order.

The R-OSGi Deployment Tool addresses this challengeby maintaining a global task queue which is processed insequential order. This mirrors the behavior of a local frame-work where the starting of bundles is also sequential. Thetotal order of bundle installation is not relevant; therefore itis performed in parallel on all frameworks and prior to theapplication startup phase. For each bundle, the service de-pendencies are determined and a BUNDLE START TASKis enqueued in such a way that the dependency structure isproperly reflected. If a bundle has any dependencies to ser-vices of a remote bundle, the system inserts a TASK GROUP

instead that consists of three phases:

1. Importing all remote services that are consumed bythe bundle

2. Starting the bundle

3. Exporting all services that are consumed by remotebundles

Through this structure, the resulting startup regime is guar-anteed to be identical to that of a centralized OSGi frame-work. Since the installation is done in parallel, only lit-tle communication overhead is incurred for coordinating thestartup order. To minimize the overhead of dependencyanalysis, the Deployment Editor keeps an up-to-date taskqueue which is initialized with the tasks required for a cen-tralized application (only tasks to install and start each bun-dle) and modifies the task queue in response to changes onthe structure of the deployment.

3.2 Deploying the Bundles and Starting theApplication

When the user triggers the deployment of a application,the bundles are generated from the referenced Eclipse projects.The current prototype implementation of the tool inter-acts with the Concierge [9] Eclipse Plugin to create highlyportable OSGi R3 bundles which also run on very resource-constrained devices.

Each framework involved in a deployment is expected torun a Deployment Agent bundle offering a Deployment Ser-vice. The services from all frameworks are transparentlyimported through R-OSGi to the Equinox OSGi frameworkon which Eclipse and the Deployment Tool run on. As a re-sult, the tool can use the services of the remote frameworks(through R-OSGi service proxies) as if they were local ser-vices making the deployment and all further interaction eas-ier. The Deployment Service offers methods to control the

Figure 3: Monitoring View

framework remotely, e.g., to install and start bundles or toestablish a connection to another remote framework in orderto import a service required for the application. Since thebundles involved in the deployment remain unmodified, theregistration of the services for remote access cannot happenby the bundles themselves (since they were not designed tosupport distribution through R-OSGi). However, R-OSGiallows surrogate registration by a third bundle. In the caseof the R-OSGi Deployment Tool, the surrogate registrationsare performed by the Distribution Services.

3.3 Monitoring the Running ApplicationAs soon as the application is running in the network, the

Deployment Tool opens the Monitoring View for this specificapplication (Figure 3). The view shows the actual state ofthe OSGi framework on each involved node, i.e., the bundlesand services. Once again, the Agents on the frameworksare contacted to get this information. Changes in the stateof bundles and services are propagated to the Plugin viaEventAdmin events which are transparently forwarded bythe R-OSGi middleware.

Furthermore, the system determines which pairs of frame-works communicate through channels. A channel is estab-lished if there are remote accesses to services from one frame-work to the other. R-OSGi offers an extensible model forchannels through NetworkChannelFactories. The tool takesadvantage of this and registers its own channel type for theprotocol “r-osgi+managed”. These channels provide feed-back about activity and exchanged messages. This infor-mation is as well propagated to the Plugin through eventsand visualized in the Monitoring View. The developer cannot only supervise the network activities of the deployment

through visual feedback but also inspect the messages in thestyle of tools like Ethereal/Wireshark[12].

4. RELATED WORKSeveral approaches have proposed the partitioning of ex-

isting applications in order to create distributed applica-tions. The Coign [6] project uses instrumentation of COMcomponents through binary rewriting, analyzes the depen-dencies between the components and calculates a graph-cutting based on a cost model for introducing network com-munication between the subgraphs. Similarly, JOrchestra [11]partitions a Java program by rewriting bytecode to replacelocal methods with remote invocations, and object refer-ences with proxy references. However, JOrchestra requiresin-depth knowledge of the source program in order to dothe fine-granular distribution of the mobile classes througha distribution plan. The high number of classes in modernJava applications can make this procedure time-consumingand error-prone. In the Eclipse-R-OSGi Deployment Tool,we exploit existing modularization and use the visualiza-tion capabilities of Eclipse to allow the developer to createdeployments in a more intuitive way. Furthermore, parti-tioning of existing applications is an iterative process thathas to be revised from time to time in order to adapt tothe changing environment or to optimize for performance.Hence, we support monitoring of the deployments and ad-vanced features like load-balancing.

Visualization of distributed systems for testing and ed-ucation purposes has been proposed by projects like Pa-rade [7], PVaniM [2], or ConcurrentMentor [3]. However,these projects describe standalone tools which operate on

existing deployments and do not help to actually developand deploy distributed application. Since the R-OSGi De-ployment Tool is based on Eclipse, visualization can be easilyapplied to any of the intermediate steps during the designphase. The OverView [4] project has proposed a comparableextension to visualize distributed applications developed inEclipse. However, they achieve the high level abstractionsthrough explicit modeling in their own Entity SpecificationLanguage. In contrast, the R-OSGi Deployment Tool usesexisting abstractions of the application based on OSGi bun-dles and services and does not require any further modelingefforts. Thereby, it provides a more rapid and intuitive wayof designing and visualizing distributed applications.

5. CURRENT LIMITATIONS AND FUTUREWORK

The main limitation of the current implementation is thesimplifying assumption that all services provided by a bun-dle will be registered within the startup of the bundle (andnot in response to an interaction with the bundle) and un-conditionally. Although reasonable for a large amount ofbundles, this assumption does not hold for every bundlesince the OSGi specifications allow the bundle to registerservices at any time.

Since the plugin already does source code analysis, it wouldbe possible to do symbolic processing of the code and reasonabout the environmental settings that cause the bundle toregister a specific required service. This information couldthen be used to create exactly the environment for a bundlethat causes the service to be registered.

Furthermore, it is currently assumed that all bundles areavailable as Eclipse projects. Binary dependencies are nothandled in the current prototype. As discussed before, thesame algorithm implemented on the AST of the source codecould as well be implemented as bytecode analysis, therebyallowing binary-only bundle resources to participate in thedeployment.

In the current state of the system, the visualization oper-ates purely online. If combined with a data lineage facility,the feedback generated by the monitored deployment couldbe used to replay certain situations and thereby allowingin-depth post-mortem analysis. In addition, the main focusof the prototype implementation is to support the develop-ment, testing, and monitoring inside Eclipse. For productivesystems, a headless deployment facility would be required.Nothing in the described setup prevents to build such a fa-cility and using the saved state of a deployment graph todeploy applications without user interaction.

As part of future work, we will turn the static deploymenttool currently created into a dynamic deployment platformthat can autonomously relocate bundles to optimize the per-formance of the application, depending on cost metrics spec-ified by the developer.

6. CONCLUSIONSWith the R-OSGi Deployment Tool for Eclipse, we present

a solution for effectively turning modular into distributedapplications. Since this process is inherently difficult for thedeveloper, we needed an environment in which programmersfeel familiar and which has support for visualizing the differ-ent steps of creating a deployment. With the Eclipse IDE,we found this platform and could use several of its feature

to implement our system.On the other hand, our tool adds the capability to de-

velop, deploy and monitor distributed systems directly inEclipse and as part of one coherent design process, in whichthe developer can focus on the application rather than thedistribution aspects. It embeds into the typical look-and-feeland the workflows of Eclipse and allows to observe the re-sults of the program even though it is running in a network.The ease of use and the visualization capabilities of the R-OSGi Deployment Tool facilitates simulation, testing, andbenchmarking of distributed systems throughout the wholedesign process. The tool is an ideal choice for exploring thebehavior of distributed system in research and education.

7. 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] C. D. Carothers, B. Topol, R. M. Fujimoto, J. T.Stasko, and V. Sunderam. Visualizing ParallelSimulations in Network Computing Environments: ACase Study. In WSC ’97: Proceedings of the 29thconference on Winter simulation, pages 110–117, 1997.

[3] S. Carr, C. Fang, T. Jozwowski, J. Mayo, and C.-K.Shene. ConcurrentMentor: A Visualization System forDistributed Programming Education. In Proceedingsof the 2003 International Conference on Parallel andDistributed Processing Techniques and Applications,2003.

[4] T. Desell, H. N. Iyer, C. Varela, and A. Stephens.OverView: A Framework for Generic OnlineVisualization of Distributed Systems. In Proceedings ofthe Second Eclipse Technology Exchange: ETX and theEclipse Phenomenon (ETX 2004), pages 87–101, 2004.

[5] Eclipse Graphical Editing Framework.http://www.eclipse.org/gef.

[6] G. C. Hunt and M. L. Scott. The Coign AutomaticDistributed Partitioning System. In Proceedings of the3rd Symposium on Operating Systems Design andImplementation (OSDI 1999), 1999.

[7] T. L. Naps and E. E. Chan. Using Visualization toTeach Parallel Algorithms. SIGCSE Bulletin,31(1):232–236, 1999.

[8] Open Service Gateway Initiative.http://www.osgi.org.

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

[10] J. S. Rellermeyer, G. Alonso, and T. Roscoe. R-OSGi:Distributed Applications Through SoftwareModularization. In Proceedings of theACM/IFIP/USENIX 8th International MiddlewareConference, 2007.

[11] E. Tilevich and Y. Smaragdakis. J-Orchestra:Automatic Java Application Partitioning. InProceedings of the 16th European Conference onObject-Oriented Programming (ECOOP 2002), pages178–204, 2002.

[12] The Wireshark Project. http://www.wireshark.org.