OSGi as a Java standard

[Karthik Shiraly]

Hi Jeff, Paul and Simon,

I've a few questions...

About making OSGi a JavaSE and JavaEE standard:
OSGi seems to be a good solution to common deployment problems like jar hell and how to add class dependencies dynamically.
It also seems to be a good solution to standardize the currently non-standard class loading strategies of different web server and application server products.
It seems something like OSGi is what Sun should have integrated into Java development right from the start.

I also feel this kind of standardization can improve certain businesses - publicly hosted shared JavaEE application servers, for instance. Right now, such services provide only minimal set of frameworks and framework versions. Any additional framework needs to be included in every subscriber's jar/war/ear, even if it's a commonly used framework like Spring. In some cases, subscribers may see this as a drawback and not choose that provider. By standardizing OSGi at the JavaEE API level and with its powerful versioning capabilities, I feel both the provider and the subscribers benefit - more storage space available for the provider to get more subscribers, more freedom to choose an application server product, coexistence of multiple versions of the same framework, and less maintenance work for every subscriber.

So are there any initiatives by OSGi backers to promote OSGi into an "official" Java API, and do you think it's a good idea to do so?

About OSGi integration best practices:
Every example I've seen on OSGi involves a call to OSGi API for looking up a service. But I see it as a deployment aspect (a side concern) and I feel an application should not include any kind of direct interaction with OSGi, except to be aware that there may be temporary unavailability of certain services. I feel it's better for OSGi to be used external to the application - more like an installer and internet aware updater.
Is there any framework / tool / approach to integrate OSGi in this manner? Does Equinox help in any way here?

About OSGi problems in Eclipse:
I use Eclipse Galileo but don't update regularly - only about once in 3 months. When I try to update certain components, I'm informed that the request can't be completed, because one component A requires a certain older/newer version of another component B. Attempts to update component B results in similar errors at another level. Is this indicative of some deployment problem even OSGi cannot solve? What should be done to avoid such problems in my OSGi-aware applications?

Why Equinox:
There are many competing OSGi container implementations. Where does Equinox score better? When would you not recommend Equinox? Does your book throw light on these topics?

Thanks for your time,
Karthik

[Paul VanderLei]

Karthik Shiraly wrote:Hi Jeff, Paul and Simon,

About OSGi integration best practices:
Every example I've seen on OSGi involves a call to OSGi API for looking up a service. But I see it as a deployment aspect (a side concern) and I feel an application should not include any kind of direct interaction with OSGi, except to be aware that there may be temporary unavailability of certain services. I feel it's better for OSGi to be used external to the application - more like an installer and internet aware updater.
Is there any framework / tool / approach to integrate OSGi in this manner? Does Equinox help in any way here?

Thanks for your time,
Karthik

Karthik, you have hit the nail on the head here. We say over and over in our book (as well as our training and our conference presentations) that if you are calling OSGi APIs in your application code, then you are doing it wrong. We recommend using Declarative Services to isolate the bundle dependency and lifecycle concerns. This helps simplify deployment, it aids in testability, and it even makes it easier to deploy your application on non-OSGi dependency injection frameworks or with no framework at all. So to answer your question: Yes. Use Declarative Services.

[Jeff McAffer]

Karthik Shiraly wrote:
About making OSGi a JavaSE and JavaEE standard:
So are there any initiatives by OSGi backers to promote OSGi into an "official" Java API, and do you think it's a good idea to do so?

OSGi actually is already standardized at the JCP in the SE and ME spaces (JSRs 291 and 232 respectively). It is a little hard to tell what will happen with the direction of Java past the next releases in SE and EE space. Within OSGi proper there is quite a bit of effort to standardize in the EE space. The Enterprise Expert Group is focused very much on these topics. Eclipse (and in particular the Eclipse Runtime initiative http://eclipse.org/eclipsert) are moving strongly as well. We host the JPA2 reference implementation (EclipseLink), the OSGi Blueprint Services reference implementation (Virgo, formerly Spring dm Server) and various other standard implementations. Whether or not these make it into JSRs and in the JEE distro is AFAICT not known or an explicit goal.

Karthik Shiraly wrote:
About OSGi integration best practices:
Every example I've seen on OSGi involves a call to OSGi API for looking up a service.
...
Is there any framework / tool / approach to integrate OSGi in this manner? Does Equinox help in any way here?

Best practice for programming OSGi is to not program OSGi. As Paul says, if you find yourself calling OSGi all the time, you are likely doing something wrong. Dependency injection in various forms is the order of the day. Declarative Services, Blueprint, Guice/Peaberry, ...

Karthik Shiraly wrote:
About OSGi problems in Eclipse:
I use Eclipse Galileo but don't update regularly - only about once in 3 months. When I try to update certain components, I'm informed that the request can't be completed, because one component A requires a certain older/newer version of another component B. Attempts to update component B results in similar errors at another level. Is this indicative of some deployment problem even OSGi cannot solve? What should be done to avoid such problems in my OSGi-aware applications?

Just throwing thousands of components to the wind does not make for a solution. Producers need to coordinate the things they make available to their consumers. If you stick to the Galileo release repo for example then you should not have any problems updating. When you go broader there is less coordination in the version ranges and dependencies. Conflicts naturally occur. OSGi does not inherently cause or resolve these conflicts. The real value is that it makes them explicit so that a) they are discovered b) they can be processed and c) they can be avoided/fixed. Systems like Yoxos OnDemand (http://ondemand.yoxos.com/geteclipse/start) manage the vast arrays of bundles in a single repo and provide consumers with "slices" that are internally self-consistent. You are free to consume anything in the slice and be confident that the dependencies will resolve.

Karthik Shiraly wrote:
Why Equinox:
There are many competing OSGi container implementations. Where does Equinox score better? When would you not recommend Equinox? Does your book throw light on these topics?

We don't go into great detail about the various framework implementations. Everyone has different requirements and ways of looking at the framework characteristics. We do tend to see Equinox used in more industrial settings where performance, scalability and robustness are key drivers. WAS, Spring dm, SAP Netweaver, ... are all using Equinox. On the client you really can't beat Equinox and Eclipse RCP for user apps. On the embedded side it depends on how embedded you are talking. Concierge is tiny but also OSGi R3 (old) and not fully compliant. The Prosyst commercial implementations are small and performant in the embedded space. Equinox is larger but still used in significant embedded deployments. You have to weigh in the full spectrum of support, performance, development experience, ...

[Karthik Shiraly]

Thank you very much, Paul and Jeff, for clearing my doubts. Thanks to all three of you, for your website link and the resources therein.