Friday, June 24, 2011

Ease of Use and Spring

Things should be as simple as possible, but not simpler.

As true as this is, the boundary between simple and simplistic is unfortunately highly subjective. If something works for you, don't change it. Unfortunately, many developers are in a situation where the environment and problems are highly complex and OSGi can simplify such situations.

The primary value that OSGi brings to the table is when you have to maintain a large code base over long periods of time, you have many external dependencies, you need to provide middleware, if you work with multiple developers, or if your development is spread over multiple locations. For those situations OSGi provides a type safe module extension to Java that can significantly reduce your development complexity.

So what is the usability issue? Unfortunately, both the modularity and type safety are at odds with prevailing class loading patterns in Java. OSGi is often the messenger telling you that your baby is neither modular nor really type safe. For example, Dependency Injection in Spring requires access to implementation classes from the configuration, exactly the classes you should really keep private. Worse, dynamic loading is only type safe if there is a single namespace in the universe. A single namespace causes DLL hell aka JAR hell that OSGi prevents by managing multiple class name spaces in a type safe way.

These are not OSGi problems, if Jigsaw one day will be modular and type safe it will have exactly the same issues!

To get the many benefits of modularity and type safety you must therefore change the way you think about Java ... If something is inside your module everything works as before but if you want to work with other modules you need to consider type safety and module boundaries. Object Oriented Design forced you to consider inheritance, encapsulation, and object identity, things that did not exist in Structured Design. Java modularity requires just such a paradigm shift. What we need is an inter module communication mechanism that truly hides implementation classes and enforces the type safety across modules. OSGi services are such a mechanism.

As Spring heavily relies on dynamic class loading it ran head on into the module boundaries and multiple name spaces. The resulting mess is what causes the negativity. Though Spring DM included OSGi services the problem was that they were more supported than embraced, resulting in many Spring DM/Blueprint modules to use the existing dynamic class loading model. However, this results in the import/export of large numbers of implementation classes. Exporting/Importing implementation classes increases the public space, the opposite of modularity. The history would be very different if the Spring libraries had embraced services, setting an example for true modularity.

There are only two solutions to this problem: Change OSGi or change the world. As I do believe there is no value in a little bit of modularity I can only see false advertising value in punching convenient holes in the modularity story of OSGi.  I do believe it is worth keep strong modularity and its enforcement. Very large applications like Eclipse, Websphere, JDeveloper, and others demonstrate that at certain scales OSGi becomes a necessity. And as more and more open source projects start to embrace OSGi it will become easier and easier to build OSGi based systems.

That said, as Rod justly points out, there are lots of people that are happy with Tomcat and depend on hard core dynamic class loaders. The OSGi service based programming model could provide benefits to these applications even if it did not enforce the boundaries. We're therefore thinking about a version of OSGi that inherits the class loading architecture of whatever environment it runs in; a JAR on the class path is then treated as a bundle. For example, in a WAR all entries in the WEB-INF/lib directory would be available as bundles. Karl Pauls tested this and it is a testament to modularity that many existing bundles actually worked out of the box. Though this solution obviously does not help when you are in JAR hell, it does provide many of the benefits of OSGi in your own familiar environment. And one day, when JAR hell finally arrives, the OSGi Service Platform is there to serve you.

Peter Kriens

3 comments:

  1. Ha ha, to me it's really funny with the answer from Rob...

    Can we use Spring for powerful embedded system? No of course! Spring is too heavy... and OSGi can be used from embedded system to middleware to... unlimitted purpose.

    Why they have Spring DM? because they think one day OSGi will replace them...

    Why Above has turned to use OSGi as core framework for their SW suites? JDeveloper has supported OSGi bundles? Because OSGi is going to be widely used than ever.

    We have used OSGi for several years in Public Transportation domain.. with hundreds of SW modules we see it's really simple to manage and maintain...

    WE LOVE MODULARITY!

    ReplyDelete
  2. The power of Spring is its consistent support for many common Enterprise patterns that make the myriad of standards and implementations easier to use. This is not in OSGi's domain as we're more into the plumbing. Therefore, putting a service face on these libraries would therefore combine the best of both world imho.

    As usual it is the middle-ground where we can use the best of different technologies to find the optimum. Therefore hoping that others will fail is not very useful.

    ReplyDelete
  3. Hey Peter.

    I just wanted to apologize on behalf of our SPAM filter which seems to have taken a strong disliking to you. I found your posts in the filter and released them. Real sorry about that. I might ping you for some extra insights. I think it's a topic I'm goign to follow up on. Not sure if you noticed, but even Rod himself posted a bit of a clarification to the article as well.

    ReplyDelete

Blog Archive