|
|
| Line 1: |
Line 1: |
| − | ==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 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==
| |
| − | <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>
| |
| − | 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==
| |
| − | <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==
| |
| − | <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>
| |
