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:

+

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

* connect with external OSGi application

−

* present all basic information about bundles working on it

+

* present all basic information about bundles and services working on it

−

* allow to start and stop installed bundles

+

* allow to start and stop installed bundles and services

−

* allow to uninstall each installed bundle

+

* allow to uninstall each installed bundle and service

−

* allow to install new bundles

+

* allow to install new bund les and services

−

* show dependencies tree of bundles for each observed application

+

</p>

</p>

Revision as of 21:08, 1 April 2009

Contents

Project Title

OSGi Monitoring

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