OSGi Monitoring

This is a project proposal for Google_Summer_of_Code_2009

Personal Details

Name: Mateusz Matela

E-mail: mateusz.matela@gmail.com

IRC nick: mmati

Project Summary

The main goal of this project is to provide a tool for easy monitoring and management of OSGi systems from within Eclipse Workbench. It will be able to connect to any remote system that has a special agent bundle installed, or loop back to the same instance of Eclipse. It will allow user to view currently installed bundles, their properties, and registered/used services. Management, that is starting/stopping and installing/updating/uninstalling bundles, will also be possible. All these features will be put in a view very similar to plug-in related views currently available in Eclipse.

The OSGi Remote Management Tool will make life easier to the developers of RCP applications and Eclipse plug-ins. It will no longer be necessary to wait for the whole Eclipse application to start when testing a little feature that is currently being developed. Instead, the testing environment can run nonstop with all the necessary plug-ins updated dynamically. Another group who might benefit from this tool are administrators of OSGi systems who like to work with Eclipse, as it's going to be a convenient way to perform the most common administration tasks.

Project Proposal

The architecture of the OSGi Remote Management Tool is pretty straightforward and consists of two parts:

1. An agent bundle that has to be installed on a managed system. It waits for connections from the outside world. When connection is established, it sends out the current state of bundles in the system. Then it uses listeners to keep track of changes in the system and immediately sends out information about them. At the same time it waits for commands coming through the connection and passes them to the OSGi framework.

2. An Eclipse plug-in that provides GUI and connects to the agent bundle on a remote system. The view provided by the tool will be very similar to Plug-in Registry view (actually, all the functionality might be added to Plug-in Registry view itself, but it's too early to decide on that matter). It will be possible to add many remote locations and connect/disconnect to them independently. The locations will be displayed as roots of the tree view, with subtrees containing lists of bundles or services in given location, depending on the user's choice (Plug-in Registry can also list extension points - they are not part of OSGi, but it might be worth showing them in this tool as well, as a special case - I'll have to investigate more on this subject).

A very important matter is the protocol used for communication between Eclipse and the agent bundle. The most obvious solution is to use RMI, because of its simplicity. However, if the tool is going to be useful for management of real OSGi systems, it should provide appropriate security features:

• authentication - not everybody can have access to the system
• authorization - some can fully manage the system while others can only monitor its state
• confidentiality - in some cases transmitted data should be encrypted to keep it secret

These features are not provided by RMI itself, so other mechanisms must be found. One idea is to use SSL connection. It would ensure great security, but would be not efficient and probably complicated to use. Another option is to implement the security layer from scratch. It would have to be simple as providing a decent level of security and flexibility is a challenge on its own. Next, the JMX technology might be the right answer, but I'm not familiar with it yet and I'm not sure what features it provides. Also, when using JMX with J2SE 1.4, additional libraries are required, which might be a problem. I'll also take time to look for other solutions used in open-source project with similar functionality. I hope to receive some ideas from the community as well. All in all, it will probably be necessary to provide several communication protocols for different purposes, so I'm going to implement just a few of them and make sure that new protocols can be easily added in the future. On the Eclipse side the communication will be configured at the stage of defining a remote location. In the remote OSGi system it can be done with OSGi bundle configuration mechanism. I plan to devote the first phase of the project to investigate possible ways of communication and selecting those worth implementing.

When the above functionality is implemented, there are several possible features using it that can make RCP/PDT/OSGi development faster and easier:

• a new type of run/debug configuration (or a switch in existing configurations) that automatically connects to created Eclipse instance and manages its bundles. Just like JDT debugger reacts to file save action by recompiling the code and instantly switching it in running application, this feature can automatically update modified bundles.
• easy installing/updating bundles from workspace right into remote application with drag&drop
• ordering the agent bundle to register a service in the remote system (may be useful for testing purposes)
• ...

Possible mentors

Jacek Pospychała

Chris Aniszczyk

Comments, suggestions, ideas...

Feel free to add your thoughts:)