Jump to: navigation, search

Difference between revisions of "OSGi Remote Management Tool"

(Project Proposal)
Line 1: Line 1:
This is a project proposal for [[Google_Summer_of_Code_2009]]
+
==Project Title==
 +
<b>OSGi Remote Management Tool</b>
  
 +
==Synopsis==
 +
<p>
 +
I will introduce idea of remote monitoring and controlling of external application based on OSGi platform. Its implementation will be a modified Plugin Registry view. At first I will try to present the meaning of OSGi in Eclipse environment and opportunities to use this view. Additionally, I will present the concept of project’s implementation.
 +
</p>
  
== Personal Details ==
+
==Project Idea==
 +
<p>
 +
The main aim of this project is to provide remote management of application based on OSGi platform. I am going to show meaning and main application of it and then I will present importance of this project.
 +
</p>
 +
<p>
 +
Firstly, we should know what is exactly OSGi. So it is a platform which provides an opportunity to us to create modular applications. In this case, module (in OSGi called bundle) is an independent single unit, which is a logical whole entirety and can be installed and uninstalled separately. The main feature of modules is that they should not be concerned with the internal implementation of other modules that it interacts with. It allows us to change the implementation of one module with no need to update all other modules that use it. The standard unit of deployment in Java is the JAR file but OSGi’s bundle has some advantages above it. Mainly, bundles allow us to define explicit dependencies between them. Also we can exactly define in manifest file which version of each library our bundle needs, so more than one version of each library can residence in the same application. Additionally OSGi default makes packages inside one bundle private for others because we only describe in manifest which packages can be imported by others. The crucial thing in OSGi is that it is a dynamic module system for Java. It allows us to install, uninstall and update all modules without restarting or even stopping application for these operations. At once we can think that OSGi is an ideal platform for each application server but it can find implementation in other environments (e.g., handheld devices, IT managed environments). In Eclipse community OSGi is very important because whole Eclipse platform is based on it. It causes that creating new plug - ins and development of all environment are so simple.
 +
</p>
  
Name: Mateusz Matela
+
<p>
 +
In this case we can notice requirement of application which allows monitoring modules within OSGi application. In an Eclipse environment we can use Plugin Registry view. Unfortunately it only allows monitoring modules in Eclipse instance in which it is working.  However, it seems an ideal basis for the project. Generally project will realize communication between an application based on one of the OSGi implementations and monitoring plugin on an Eclipse instance. It will be based on client – server architecture. In this communication external application will be a server and our view in eclipse will be a client. A server provides information about bundles and services which is interpreted by our application (Plug-in Registry view). Additionally it should make available operations on individual bundles, such as starting and stopping them, installing new bundles and uninstalling old ones. This application allows for example remote supervision of servers based on OSGi implementation so we can react immediately on any problem on the server side when it occurs.
 +
</p>
  
E-mail: mateusz.matela@gmail.com
+
==Components of design and functionality==
 +
<p>
 +
All functionality will be provided by modified Plugin Registry view.  Method of presentation will be slightly changed. Bundles and services of each application will be grouped by its name. It should by enough clear and transparent for a user.
 +
</p>
 +
[[Image:Pluginregmod.jpg]]
 +
<p>
 +
Most of the functionality should be realized by additional operation in Plugin Registry view (starting, stopping modules, installing, uninstalling). Of course not all of OSGi implementations provide all of these operations so server application must provide information about OSGi implementation to a client. For example remote installation of bundles on Equinox can by impossible. On the basis of this information it should provide only permitted functionality. View with connected external applications should allow to add new ones, removing and insight into the basic information about them. Whole project will be part of Eclipse SDK, so will seamlessly integrate with it, but will also keep minimum dependencies on it to be possibly bundled as a separate Eclipse RCP application.
 +
</p>
  
IRC nick: mmati
+
==Proposed implementation==
 +
<p>
 +
The first step of implementation should be the choice of the first protocol which will be used to communication with external OSGi applications. It must be enough simply for this phase. The basic method of connecting is a standard socket interface. This solution is partly implemented in bug number 243439. In my opinion this solution should be considered before we decide for other protocol. If we accept this, further development should be focused on its completion. It is very important to choose good format of data which will be send by a socket. We can choose objects serialization and in this case is important to implement good validation of objects because it is crucial. We can also think about some kind of encryption. The Java Cryptography Extension (JCE) provides support for encryption of serialized objects. If we use a XML format, we must choose another way to do this.
 +
</p>
 +
<p>
 +
After that we have to adapt Plugin Registry view to handling remote connection (e.g. making and breaking it). After connection with external application our agent should download information about all bundles and services installed on this one. Supervision should be in real – time (any change of bundle’s state must be seen immediately in monitoring application).  In such case, server must send information about changes to client application. More efficient is to send only description of the change (e.g.  which bundle change its state and what is a new state). Another way is to send whole object. In the second solution update of model in a client is easier. We have to think which solution will be better. 
 +
</p>
 +
<p>
 +
On this phase we achieve functionality of Plugin Registry view but with remote monitoring. At this point, another task would be to add further functionality: remote operation on bundles and even installing new bundles in external application. After this phase we should start implementation of the second universal protocol. Unfortunately on this stage of designing we cannot clearly choose the best one. There are several possibilities. One of them is JMX (e.g. org.eclipse.equinox.monitoring). Another possible solution would be to use the Eclipse Communication Framework (ECF). For example we can choose remote services API which is very similar to classic OSGi services API. After additional protocol/protocols will be added, we will add mechanism of expansibility for new protocols (e.g. from other plugins).
 +
</p>
 +
<p>
 +
In conclusion our client should offer following functionality:
 +
* connect with external OSGi application
 +
* present all basic information about bundles and services working on it
 +
* allow to start and stop installed bundles
 +
* allow to uninstall each installed bundle
 +
* allow to install new bundles
  
== Project Summary ==
+
</p>
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:)
+

Revision as of 13:16, 24 April 2009

Project Title

OSGi Remote Management Tool

Synopsis

I will introduce idea of remote monitoring and controlling of external application based on OSGi platform. Its implementation will be a modified Plugin Registry view. At first I will try to present the meaning of OSGi in Eclipse environment and opportunities to use this view. Additionally, I will present the concept of project’s implementation.

Project Idea

The main aim of this project is to provide remote management of application based on OSGi platform. I am going to show meaning and main application of it and then I will present importance of this project.

Firstly, we should know what is exactly OSGi. So it is a platform which provides an opportunity to us to create modular applications. In this case, module (in OSGi called bundle) is an independent single unit, which is a logical whole entirety and can be installed and uninstalled separately. The main feature of modules is that they should not be concerned with the internal implementation of other modules that it interacts with. It allows us to change the implementation of one module with no need to update all other modules that use it. The standard unit of deployment in Java is the JAR file but OSGi’s bundle has some advantages above it. Mainly, bundles allow us to define explicit dependencies between them. Also we can exactly define in manifest file which version of each library our bundle needs, so more than one version of each library can residence in the same application. Additionally OSGi default makes packages inside one bundle private for others because we only describe in manifest which packages can be imported by others. The crucial thing in OSGi is that it is a dynamic module system for Java. It allows us to install, uninstall and update all modules without restarting or even stopping application for these operations. At once we can think that OSGi is an ideal platform for each application server but it can find implementation in other environments (e.g., handheld devices, IT managed environments). In Eclipse community OSGi is very important because whole Eclipse platform is based on it. It causes that creating new plug - ins and development of all environment are so simple.

In this case we can notice requirement of application which allows monitoring modules within OSGi application. In an Eclipse environment we can use Plugin Registry view. Unfortunately it only allows monitoring modules in Eclipse instance in which it is working. However, it seems an ideal basis for the project. Generally project will realize communication between an application based on one of the OSGi implementations and monitoring plugin on an Eclipse instance. It will be based on client – server architecture. In this communication external application will be a server and our view in eclipse will be a client. A server provides information about bundles and services which is interpreted by our application (Plug-in Registry view). Additionally it should make available operations on individual bundles, such as starting and stopping them, installing new bundles and uninstalling old ones. This application allows for example remote supervision of servers based on OSGi implementation so we can react immediately on any problem on the server side when it occurs.

Components of design and functionality

All functionality will be provided by modified Plugin Registry view. Method of presentation will be slightly changed. Bundles and services of each application will be grouped by its name. It should by enough clear and transparent for a user.

Pluginregmod.jpg

Most of the functionality should be realized by additional operation in Plugin Registry view (starting, stopping modules, installing, uninstalling). Of course not all of OSGi implementations provide all of these operations so server application must provide information about OSGi implementation to a client. For example remote installation of bundles on Equinox can by impossible. On the basis of this information it should provide only permitted functionality. View with connected external applications should allow to add new ones, removing and insight into the basic information about them. Whole project will be part of Eclipse SDK, so will seamlessly integrate with it, but will also keep minimum dependencies on it to be possibly bundled as a separate Eclipse RCP application.

Proposed implementation

The first step of implementation should be the choice of the first protocol which will be used to communication with external OSGi applications. It must be enough simply for this phase. The basic method of connecting is a standard socket interface. This solution is partly implemented in bug number 243439. In my opinion this solution should be considered before we decide for other protocol. If we accept this, further development should be focused on its completion. It is very important to choose good format of data which will be send by a socket. We can choose objects serialization and in this case is important to implement good validation of objects because it is crucial. We can also think about some kind of encryption. The Java Cryptography Extension (JCE) provides support for encryption of serialized objects. If we use a XML format, we must choose another way to do this.

After that we have to adapt Plugin Registry view to handling remote connection (e.g. making and breaking it). After connection with external application our agent should download information about all bundles and services installed on this one. Supervision should be in real – time (any change of bundle’s state must be seen immediately in monitoring application). In such case, server must send information about changes to client application. More efficient is to send only description of the change (e.g. which bundle change its state and what is a new state). Another way is to send whole object. In the second solution update of model in a client is easier. We have to think which solution will be better.

On this phase we achieve functionality of Plugin Registry view but with remote monitoring. At this point, another task would be to add further functionality: remote operation on bundles and even installing new bundles in external application. After this phase we should start implementation of the second universal protocol. Unfortunately on this stage of designing we cannot clearly choose the best one. There are several possibilities. One of them is JMX (e.g. org.eclipse.equinox.monitoring). Another possible solution would be to use the Eclipse Communication Framework (ECF). For example we can choose remote services API which is very similar to classic OSGi services API. After additional protocol/protocols will be added, we will add mechanism of expansibility for new protocols (e.g. from other plugins).

In conclusion our client should offer following functionality:

  • connect with external OSGi application
  • present all basic information about bundles and services working on it
  • allow to start and stop installed bundles
  • allow to uninstall each installed bundle
  • allow to install new bundles