David Bosschaert, Progress Fellow and one of the drivers behind the Distributed OSGi/RFC 119 design and implementation, has posted a couple of good tutorials about it on his blog.
Here's his simple example to get started using the Distributed OSGi Reference Implementation and a more complex example using an Ajax client for a service invocation from an external source.
When we initially wrote the requirements for Distributed OSGi to start the EEG process of designing a solution that could be included in the next rev of the OSGi Specifications, we focused not only on the use case in which an OSGi service is able to invoke another OSGi service in a different (potentially remote) JVM, but also on the use cases in which an OSGi service might be invoked by an object external to an OSGi Framework.
David will be at the OSGi Dev Con in March (co-located with EclipseCon) and will be giving a presentation and demo about Distributed OSGi/RFC 119 along with Scott Lewis and others. ECF will be supporting Distributed OSGi/RFC 119, and there's note to the bottom of this page (and a comment to a previous post) that seem to indicate that Eclipse Riena also will, and apparently Paremus InfiniFlow too (if I have understood this interview correctly). So it looks like we are well on our way toward our goal of completing this work during the next few months.
In any case, please be sure to take a look and let us know what you think of Distributed OSGi/RFC 119, either in response to the blog posts or in person at OSGi Con.
6 years ago
Posts
Eric
ReplyDeleteYou have interpreted the interview correctly. To confirm we see RFC119 as complimentary to our distributed OSGi runtime product (Infiniflow) and the open source foundations (Newton). These are more about the idea of managing distributed Systems across a distributed OSGi runtime rather than just interconnecting multiple OSGi containers (which of course we have to do as well!). I can confirm that we will support RFC119 in due course once it gets released in the 4.2 specification. We intend to always support the OSGi specification to ensure interoperability within OSGi containers and no lock-in for OSGi bundles being used with Infiniflow and Newton.
Regards
Mike (Paremus)
Mike,
ReplyDeleteThanks very much for the confirmation. Paremus was one of the early contributors to many of the requirements that helped set the direction for the 4.2 release, and I am pleased to hear the positive feedback on the follow on design efforts. As many of us have often said it would be great to have Paremus more involved in the current activities, although I understand the issues around the additional fees to join the OSGi Alliance at the full membership level. But if you pass along any feedback on these initial designs, including RFC 119, it will be gladly received.
Of course if it's all great, that's fine too ;-)
Eric
Mike,
ReplyDeleteOne of the best additional tool of newton is the jar travelling and the service fabric. No need to deploy an api in the service client.
I updated an example about sca and hessain : http://www.jroller.com/ouertani/entry/hessian_declarative_extender_as_sca
but without jar travelling :)
Regards
slim ouertani
Eric,
ReplyDeleteHave you considered adding less transparent levels to the RFC? For example, where a client can obtain a direct reference to a proxy, generated by distribution software. Or when a service is exposed directly through the chosen distribution software instead hiding it with OSGi. (You may find more detailed description here: http://mcsimm.blogspot.com/2009/02/distributed-osgi-levels-of-transparency.html)
It will be interesting to hear your opinion about whether these models are valuable at all. Or if all described use cases can be implemented using existing transparency levels, could you please clarify how exactly this can be done.
Max,
ReplyDeleteThanks very much for the comment. We have not been thinking exposing proxies to services directly because we have been drawing the line between what's standardized in the OSGi Specification and what's done in the "distribution software" environment basically at the interface/properties level.
It is true that putting the line there implies some constraints on protocol-specific features, or at least doesn't define how they should be used. However, I also think the design does not prevent their use, including what you describe on your blog entry. That is, under the current design of RFC 119 it should be possible to create an OSGi service that creates a proxy to a remote service.
We also decided to postpone work on asynchronous protocols until the next version, mostly due to time constraints. It took a lot of discussion and work to get RFC 119 to the current point, and we decided the best thing to do in order to get the release out was finish the synchronous design.
I can imagine that there is some value to a "less transparent" design. Software design is always a balance between abstraction and control - abstraction making thing easier for people but typically at the expense of some flexibility and fine-grained control.
I think you did say in the blog that the current design seems to meet the majority of distributed computing requirements. If so, that would be consistent with our goals.
I can easily imagine that the design does not meet every possible requirement. However the question remains where to draw the standardization line, and we have so far hesitated to try to include anything specific to a given distribution software system. If I understand your suggestion correctly, it would involve standardizing the way in which proxies are created for various distribution software types.
In summary, we have the consideration of what to standardize (and by the same token what best to leave for implementers to decide), whether our design does not prevent the use of protocol specific features, and whether the level of abstraction in the current design is sufficient for the majority of applications.
We expect another version of this design in the release of another version of the OSGi Specification - and perhaps this question of direct access to proxies is something to be investigated further, along with the already postponed investigation into asynchronous protocols. In other words this would be the time to discuss extensions to the design to meet additional requirements, starting with new RFPs etc.
In the meantime if there is any issue with the current design we have some chance to fix problems during the specification writing phase of the current release.
Eric
Eric,
ReplyDeleteThank you for the information, it indeed helps to better understand the present and the future of OSGi.
With your permission, I would also want to clarify a bit my vision of "less transparent" models. I completely agree with the statement that DOSGi standard should not be messed with details of distribution software. But in my opinion, introducing less transparent levels doesn't break this statement.
Let me give an example of the least transparent model (pic.3). Lets assume that developer has already implemented RMI server and RMI client, but wants to use DOSGi features, like lifecycle management and discovery service, etc. In the OSGi implementation, where such transparency level is possible, the process will look like the following.
When the developer registers this service, she just includes one additional property to indicate that this service is an not OSGi service, so, no OSGi proxies should be created on client side to simulate locality of the service. Another property, added to the service registration, contains sufficient connection information for the client. In case of RMI, it will be address of rmiregistry.
When the client wants to use this service, it searches for it in service registry, obtains reference if any, or tracks for a service using the service tracker. When client obtains a service reference, client code doesn't instantiate it, because the service is not an OSGi service. It just reads connection information, which is sufficient to establish RMI connection, and obtains RMI proxy.
So, DOSGi framework doesn't know anything about distribution software. It just works with some abstract non-OSGI service. On the other side, for the developer, communication is completely not transparent, because she exposes and uses service through RMI.
Actually, I do not expect such things to be included in current RFC, because it is already excellent. It is a huge improvement for OSGi and it indeed covers most of topics required for applications. To a greater extent, these ideas can be considered as just some food for thought.
Max,
ReplyDeleteSorry for the delay in replying. I have read your comment again just now, and first want to thank you for the compliment. I am very glad you like the current draft of RFC 119.
I am wondering about the part of your suggestion which says we should allow registration of non OSGi services... If they are not OSGi services why would they be registered?
You said it was because non-OSGi services wanted to take advantage of some OSGi capabilities, but I am confused about this because if a service knows about OSGi then it seems like it must be an OSGi service, even if it doesn't use all of OSGi.
It sounds like the point is that you would like to code directly to a distributed software interface to take advantage of some protocol-specific features (perhaps serializing executable code), but I think you can do this anyway in the current design.
Also i think what you have described is very similar to the RFC 119 design, except the property you suggest indicates that the service is not an OSGi service (but if it isn't how does OSGi know anything about it?). The RFC 119 design adds a property to indicate a service is a remote service, or potentially remote.
Are you suggesting another property to indicate that a service is not remotable? And in this case the developer will take responsibility for the distributed computing mechanism?
Thanks again,
Eric
Eric,
ReplyDeleteThank you for the answer, a common understanding has been achieved. To a some extent, yes, I am suggesting to add another property to a service to allow developers to take responsibility for the distributed computing mechanism. However, this property will indicate that the service is remotable. The only difference is that in this case service will say to DOSGi: "Please, do not create proxy for me on the client side, I need only distributed service registry".
I suppose, the term "non-OSGi" was too confusing. I used this term for the services, which look like a black box for OSGi. Specifically, DOSGi doesn't care about remote invocation of methods of these services. To a some extent, they are still OSGi services indeed, because they use DOSGi service registry and their bundles uses lifecycle management capabilities.
You are also correct that the proposal I have described is very similar to RFC 119. It is just a new transparency level with less transparency. So, the only difference from the existing model is the possibility for a service and client to communicate directly through preimplemented distribution software and to refuse using distribution software provided by DOSGi.