Distributed OSGi: Levels of Transparency

At the moment, RFC 119 contains 4 levels of transparency of Distributed OSGi for a developer. They range from completely transparent behavior, where no code should be changed to use remote OSGi container, to possibility of handling distribution software specific exceptions. All of them, if I understood them correctly, can be described in the following way:

Picture 1. Transparency levels 1-4

There is no doubt that in most cases these levels will satisfy all developer needs. However, since the distributed communication technology is hidden from the developer, such model may have a number of limitations. For example, it will be hard to make asynchronous method calls or to use communication technology-specific features.

So, it may be worth considering to support less transparent models. For example, when the client can obtain an remote endpoint or a reference to the proxy, created by distribution software:

Picture 2. Transparency level 5

This model can also be extended to the level, where the OSGi proxy on the client side is created by OSGi service developer, not framework. Current version of Riena may serve as an example of this case. Upd.: Newton, and, hence, Infiniflow also support writing a kind of custom proxies.

Moreover, fully non-transparent model can also be useful:

Picture 3. Transparency level 7

In this model, the service is exposed not through OSGi, but through the chosen distributed communication technology, like RMI. This service can also be registered in the OSGi service registry, but can't be used as an OSGi service. Every client, which wants to use it, can track this service, and when it comes online, can extract required data establish direct connection to the service using communication framework-specific proxy.

This model can suite either legacy applications, where components already exist and communicate with each other using some distributed communication framework. Also, the model can be useful when developer wants to use some communication framework-specific features and doesn't want to refuse OSGi convinience in the field of module management and service tracking.

P.S. It worth noting that similar ideas have already appeared in the comments on Riena project goals. However, I am not sure about exact levels of transparency mentioned there.

Traps on the Way from OSGi to Distributed OSGi

OSGi is a powerful technology for an application life cycle management. It deals with configuration and change management and helps to build quality service oriented systems. OSGi is pretty popular framework with broad applicability and many mature implementations. Eclipse IDE is maybe the most commonly used example of application build with OSGi.

This sounds very good, but current OSGi standard deals only applications running in the single JVM. It is obvious that the latest trends with scaling everything out diminish the value of this great technology to a large degree. So, there is no surprise that third party frameworks, built on top of OSGi, appeared on the horizon. Newton and R-OSGi are maybe the most well-known ones. From the OSGi side, latest drafts of the standard include specification of Distributed OSGi also known as RFC 119. As far as I know, there is no production-ready implementation of this RFC, but there were successful demos, and the RFC itself is very mature at the moment. All of these approaches to distribute OSGi are really interesting and worth discussing, but for now I am not going to dive deep into them.

The thing I am aware of at the moment is that OSGi is essentially just a framework for module (or component) management. When it deals with components in one JVM, everything is good. But moving to distribute environment will bring many new problems, like the need of communication medium between components. The desire (or need) to implement yet another RMI as a part of OSGi can be very strong. However, in my opinion, this should be avoided soever. OSGi is not a communication technology - there are lot of them on the market, covering different areas and created for different purposes. Implementing a new one, which will cover all required ways of communication, is hard. Distributed OSGi, on the opposite, should not cover this topic at all, dealing only with what OSGi deals the best - managing modules lifecycle, but in a distribute fashion. In the ideal situation , developers should have free choice of communication medium between modules, according to the requirements of the project.

This problem touches not only me, but the good news are that it seems creators of RFC 119 are on the right way. Other technologies for distributing OSGi are not so good from this point of view: R-OSGi introduces custom communication medium, and Newton makes use of Jini and RMI. It is not exactly bad for them, because they maybe can solve other problems better and they are ready to use right now, unlike RFC 119.

Actually, to correctly and objectively compare these technologies, additional research is required and it is not the goal of this post. If somebody is interested in the topic, Hal Hildebrand's blog can be used as a great source of an interesting information about RFC 119, OSGi in general, and in particularly, comparison of R-OSGi and Distributed OSGi.

Problems with Manifest in JAR

It is widely known that JAR files are built on the ZIP file format. So any jar file can be opened with zip archiver, and, to create jar file, zip tools can be used. The only major difference is that jar files may have optional META-INF directory with MANIFEST.MF and other files related with meta-information.

Everything looks very simple. However, today I have faced one problem with finding manifest file in the jar. I have created zip file from the directory with the simple structure:
-META-INF
--MANIFEST.MF
-A.class
-B.class

After extension was changed to jar, this file was used by an external application, which tried to locate manifest in the file. This was a great surprise when the application was not able to find it. I tried to use jar util to prepare the package. When I pushed the result file to the application, it successfully found the manifest.

The situation was pretty strange - contents of both archives was identical and I knew that JAR files should not store any additional metainformation about manifests, but the experience showed the opposite. There were some doubts about possibly buggy logic in the client application, which read my jars. I looked through its source codes and found that it just uses standand JarInputStream from java.util.jar.

However, when I investigated this class, I noticed one thing that could be the cause of such behavior: logic responsible for finding manifest in the JAR assumes that META-INF directory should be located in the beginning of the archive. I investigated both my archives and it turned out that the one, created with zip tool placed this directory in the end. But the archive created with jar stored META-INF in the beginning, as it is expected.

So, if somebody still wants to create jar files with zip tools, do not forget to place META-INF in the beginning of the archive. Do not also forget to add two empty lines in the end of the manifest file, just in case.