Announcement Announcement Module
No announcement yet.
OSGI - when is it appropriate? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • OSGI - when is it appropriate?


    This is quite a general question (perhaps to general) but I am wondering in what type/size of application/system would a OSGI based solution be appropriate and where would it be not ?

    From the OSGI we have a general statement of the advantages of using an OSGI framework:

    "OSGi technology is the dynamic module system for Java™. The OSGi Service Platform provides functionality to Java that makes Java the premier environment for software integration and thus for development. Java provides the portability that is required to support products on many different platforms. The OSGi technology provides the standardized primitives that allow applications to be constructed from small, reusable and collaborative components. These components can be composed into an application and deployed.

    The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring restarts. To minimize the coupling, as well as make these couplings managed, the OSGi technology provides a service-oriented architecture that enables these components to dynamically discover each other for collaboration. The OSGi Alliance has developed many standard component interfaces for common functions like HTTP servers, configuration, logging, security, user administration, XML and many more. Plug-compatible implementations of these components can be obtained from different vendors with different optimizations and costs. However, service interfaces can also be developed on a proprietary basis.

    OSGi technology adopters benefit from improved time-to-market and reduced development costs because OSGi technology provides for the integration of pre-built and pre-tested component subsystems. The technology also reduces maintenance costs and enables unique new aftermarket opportunities because components can be dynamically delivered to devices in the field."

    Now apart from the dynamic nature that OSGI faciltates most of what is stated above is what I would consider to be deliverable via a well architected non-OSGI solution (using Spring ). What isn't stated is the cost of introducing another layer/platform/framework/concept into the implementation. If I don't particularly require the ability to dynamically introduce modules into a live environment and am quite happy to do a standard versioned release/deploy of an application would using OSGI constitute 'over-engineering'?

    Any thoughts appreciated.

  • #2

    I think the dynamic nature is what separates OSGi technology from other frameworks but it is not its most important advantage. Its key advantage is that it forces you to work modular. As BEA said. we thought we worked modular until we started working with OSGi, then we found out we had not. You will not know if you work modular until you start using OSGi.

    Why is modular important? Well, if there is one consistent lesson in all our technology trends over the past 50 years then it is high cohesion and low coupling. Structured programming advocated this, OO forgot it for some time but rediscovered this in the end, and POJOs are all about decoupling. OSGi technology is not just about promoting setting boundaries, but is about enforcing those boundaries. OSGi bundles (modules) have clearly defined dependencies on their environment and these dependencies are enforced in runtime.

    When you work with Spring in a traditional environment you build an application where the class path is a global variable. This is probably the simplest solution for small simple applications but when over time the application becomes more complex and evolves, and independently of its dependent evolving libraries, you will run into many modularity problems.
    • You will find out that developers used private API from other parts of your system, and that private API just changed in a non backward compatible way, wreaking havoc in your code. OSGi bundles must explicitly export the packages they want to share with others.
    • You run into the version incompatibility problem. Library A depends on library B version 1, but you also need library C that needs library B version 2. This situation is impossible to handle with a global classpath. However, an OSGi service platform can have multiple versions of the same package or bundle resident. Great are is taking to keep the resulting class spaces consistent so you will not run into Class Cast Exceptions.
    • You find out that the same package names are used in different JARs causing weird problems depending on the ordering of the classpath. Note that the class path is quite complex today in Java with extensions and the many frameworks that just add stuff to it from directories. The OSGi service platform is well defined in all cases and the private packages make this problem non-existent.
    • Over time you usually find out that not all your customers/deployments are the same. Almost invariably, you find you have to make different Spring configuration files to support these needs, this can become a maintenance problem when the Spring files become big (as they likely do over time). With OSGi technology, here is a tendency to make smaller units that are stand alone and reusable. Linking these modules with OSGi services allows you to configure the runtime through the set of installed bundles. This model makes it trivial to plug-in functionality to your system that is discovered in runtime. I have seen many demos where people provide large functional blocks to their web application by installing new bundles (the fact that you can do this dynamicly is not crucial, but oh man, it is cool to see).
    • Small is beautiful! If there is one thing I have seen happening with people that start to use OSGi technology is that their modules become smaller, less coupled, and more cohesive. This effect makes code more reusable over time, easier to understand, easier to test, and easier to refactor. I fully understand that a disciplined developer can do the same thing, but knowing that your little hack does not work in runtime keeps most of us more honest.
    • Using OSGi is like have an X-ray machine on your application. There exists many shells for OSGi frameworks that allow you to inspect the wiring of your bundles, disable bundles, remove bundles, check consistency, and provide updated versions. This X-ray machine works on a much higher level than a debugger, with which it works very nicely together. When I teach people OSGi, the students always love what they can do with a running framework. And you can do all this remotely as well with the many remote management systems for OSGi on the market.
    I think (and as the OSGi evangelist I guess I should) that using OSGi to develop your applications brings many of the listed advantages out of the box. When you use Spring, you see little of the hard work the OSGi framework is doing for you under the covers. However, as you can see on the Spring-OSGi list, it is not always without pain.

    A key issue is that many of us have not been working very modular. As BEA said at the last EclipseCon, modularizing your applications can be very painful, and I see others having similar problems. Usually the best solution is to port an existing application as one or a few bundles and then over time carve out the functionality that can be done separately.

    However, the other issues is the lack of OSGi based bundles, most open source projects do not support OSGi (yet!). In many cases versions are not well maintained and lets face it, plain Java does not give us the tools to modularize. The OSGi specifications provide the tools but many projects do not feel enough push yet to add this metadata to their artifacts. It is improving, but it has some way to go. What we need now is pressure from the industry on open source projects and vendors to provide the additional metadata so we do not need projects like felix commons or Eclipse Orbit to wrap existing libraries. Fortunately, the Spring framework will exert a lot of pressure on the industry, and in the new version they turned all their code into bundles.

    My dream through my professional life is reusability. I thought objects would bring real reusability but the high coupling in OO applications made it fail in most cases. I think the OSGi components with services model is one of the most promising attempts to bring us closer to the grail of building software with pluggable components. But we need your help!

    Kind regards,

    Peter Kriens
    (OSGi evangelist)