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.