Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "OSGi Monitoring"

(New page: ==Project Title== <b>OSGi Monitoring</b> ==Synopsis== <p> I will introduce idea of remote monitoring and controlling of external application based on OSGi platform. Its implementation wil...)
 
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Project Title==
+
This is a project proposal for [[Google_Summer_of_Code_2009]]
<b>OSGi Monitoring</b>
+
  
==Synopsis==
 
<p>
 
I will introduce idea of remote monitoring and controlling of external application based on OSGi platform. Its implementation will be an application based on Eclipse platform. At first I will try to present the meaning of OSGi in Eclipse environment and opportunities to use this application. Additionally, I will present the concept of project’s implementation.
 
</p>
 
  
==Project Idea==
+
== Personal Details ==
<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>
+
  
<p>
+
Name: Mateusz Matela
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 the project will realize communication between server side application based on one of the OSGi implementations and client side application based on Plugin Registry view using selected protocol. A server provides information about bundles which are interpreted by client side (Plugin Registry). Additionally it should make available operations on individual modules, such as starting and stopping them, installing new modules and uninstalling old ones. For example this type of application allows to remote supervision of servers based on OSGi implementation so we can react immediately for each problem on the server side when it occurs.
+
</p>
+
  
==Components of design and functionality==
+
E-mail: mateusz.matela@gmail.com
<p>
+
Main feature of the application is possibility to connect with more than one external application. In this situation one of the views should present a list of actual connected applications and should allow to choose of them. After that in Plugin Registry we would see all modules belonging to it. The third optional view should provide graphical presentation of dependencies between individual modules on chosen external machine (it may be Graph Plug-in Dependencies which is part of the Equinox Incubator). Most of the functionality should be realized by additional operation in Plugin Registry view (starting, stopping modules, installing, uninstalling). Of course not each of OSGi implementations provides all of these operations so server application must provide information about it to client. 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. Above all application should be an independent application based on Eclipse or/and additional perspective for Eclipse.
+
</p>
+
  
==Proposed implementation==
+
IRC nick: mmati
<p>
+
The first step of implementation should be the choice of the appropriate protocol which will be used to communication with external OSGi applications. Unfortunately on this stage of designing we cannot clearly choose the best one. There are several possibilities. The basic method of connecting to them is to use 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. In the other case, we should test all the other 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. However, in this case we restrict only to Equinox implementation of OSGi. I think that it is not the best way because we want to connect to the other ones, e.g. Felix or Knopflerfish. After we choose the best way to communicate between applications the second step is to implement all functionality. After connection with external application our agent should download information about all bundles installed on this one.  Supervision should be in real – time (any change of bundle’s state must be seen immediately in monitoring application). On this stage 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. In the second case we should consider installing only bundles which exist on the external application but are not be installed and bundles which we have to send to it before they will be installed. I think that the second option should be considered as optional. In conclusion our client should offer following functionality:
+
* connect with external OSGi application
+
* present all basic information about bundles working on it
+
* allow to start and stop installed bundles
+
* allow to uninstall each installed bundle
+
* allow to install new bundles
+
* show dependencies tree of bundles for each observed application
+
  
</p>
+
== 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:)

Latest revision as of 14:16, 24 April 2009

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:)

Back to the top