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.
Subscribe to:
Post Comments (Atom)
6 comments:
OSGi is not a communication technology
Amen!
I'm not sure I have understood this post correctly. Please excuse me if I have misunderstood.
On the one hand it references some of the existing solutions to distributed OSGi, but on the other seems to question the need for a standard for it.
RFC 119, aka Distributed OSGi, is being created by the OSGi Enterprise Expert Group to standardize how existing distributed computing infrastructure can be configured into an OSGi framework. It does not define any new distributed computing infrastructure. This is a common misconception, but we should try to avoid repeating it, since that only makes the misconception worse.
RMI, CORBA, Web services, JINI, ECF, etc. all can be used with the Distributed OSGi standard. What's needed is a common way for everyone to do it, since it's being done anyway (as you mention).
This was also one of the top priorities the OSGi Alliance received for the next revision of the OSGi Specifications. So it also seems fair to say that people adopting OSGi are interested in standardizing this capability.
Maybe I was somewhat unclear when using the term "communication technology". If I understood you correctly, this is the same as "distributed computing infrastructure", like RMI, CORBA, etc. In other words, this is a technology, which main goal is to enable communications between distributed components in the application.
So, I completely agree with you that distributed OSGi should not define any new distributed computing infrastructure. Moreover, it should be agnostic to these technologies.
The main reason for this post is that when I first looked at existing approaches for distribution of OSGi, I saw that the above statement about communication technologies agnosticism is not necessarily true. Especially for R-OSGi. So, I just tried to point out that in this field RFC 119 looks more correct.
However, I feel I maybe missed your thought about relationship of RFC 119 and existing efforts of distributing OSGi, like R-OSGi or Newton. So, it will be very interesting if you can clarify this relationship and explain it in more details.
Thank you.
Thanks for mentioning Newton in your post. It's worth noting that while RMI is the communication protocol offered in Newton currently, it actually offers pluggable SCA bindings and we are working on support for other communication protocols, such as Web Services. The SCA binding API used in Newton is a public API which we encourage others to contribute to if they want to use their own protocols in our environment.
Also Newton and Infiniflow (the commercial product built on top of Newton) offer what we describe as a distributed OSGi runtime and we see this as offering more than what RFC119 offers. We consider a distributed OSGi runtime being something that is able to manage distributed Systems, rather than remoting i.e. point to point connections, which is what RFC119 is providing.
Newton & Infiniflow therefore offer more functionality than just the ability to run across multiple OSGi containers/JVM’s, this includes resilience, scalability and automation via the use of a functional Model based on SCA, which is akin to the DNA or 'functional blueprint', for each System you want to run across the runtime.
RFC119 is therefore complimentary to Newton and Infiniflow and we intend to support this in due course, after it is released in the 4.2 OSGi specification, planned for mid this year.
Regards
Mike (Paremus)
Mike, thank you for you comment. Newton and Infiniflow are indeed very interesting projects and they are worth looking at.
Max,
Thanks for your reply to my comment, and apologies for taking so long to answer.
I had indeed misunderstood the post, and should have read it more carefully. I can see now that you think RFC 119 has taken the right approach, and thanks very much for that. Much appreciated.
WRT to R-OSGi or Infiniflow, I see that Mike has already replied about the Paremus product, and I am similarly pleased to hear him say Paremus intends to provide an implementation of distributed OSGi at some point in the future, and plans to add value to it in the product. That would be one way to describe the relationship I'd like to see. In other words, this is one way to judge the correct place to draw the standardization line - where it gives a vendor room to add value but standardizes an important capability across implementations. It is still early days for this new design and the specification is not yet done, so we will have to wait and see, but this is a good sign.
The Paremus guys helped write the requirements for the current enterprise OSGi effort, which was great, but unfortunately their membership level (and associated additional expense) didn't allow them to contribute to the design. It is an unfortunate side effect of membership fees necessary to maintain an independent organization I suppose. But I can also tell you the OSGi Alliance is about as lean and low budget a consortium as anyone can find.
I am not so familiar with R-OSGi, but I do know some existing solutions require the same "product" libraries on both sides of a connection and therefore may introduce some dependencies. We tried to avoid that.
Eric
Post a Comment