A short story to illustrate my musings. In the eighties, I worked on a page-makeup terminal for the newspaper industry. Petr van Blokland, a graphic designer turned computer specialist, introduced me to the layout grid. This grid had columns and between the columns there was a small gutter. Text and pictures were placed on this grid, usually encompassing multiple columns and gutters. Like:
The OSGi always reminds me of this grid. Why? Because they both restrict you severely but in return they provide simplicity. Instead of having infinite freedom to do whatever you feel like, you must obey some pretty basic rules, which some people find upsetting. But what you get back is that the elements work together as a whole, instead of fighting with each other.
Layouts done with this grid almost invariably look good with no effort (try working with the average layout manager in Swing or SWT!). The advantage is that elements always line up and there is always the same space between elements. Without a grid, it is very hard to avoid unwanted visual effects.
Genuine OSGi bundles almost invariably collaborate with each other without much effort (anybody saw the combination Eclipse and Spring coming?) because modules are self-contained and can only export packages and communicate via services instead of the myriad of ways people have devised in Java.
Interestingly, both are achieved by restricting ones freedom, the opposite of providing more features. But neither OSGi nor this grid is simplistic. A simplistic grid would be a square 8x8 grid, and they just do not work. A simplistic OSGi would be some Class.forName based system without handling versions and dependencies. Both OSGi and the grid seem to be in a sweet spot: simple but not simplistic, providing maximum bang for the buck.
However, legacy code seems to be forcing us to add more and more mechanisms to the OSGi specification. Unfortunately, these mechanisms are often also then used for new OSGi applications because the legacy concepts they represent feel familiar to people. See how many people use Require-Bundle and fragments.
If we add all these freedoms to the next generation, will we not pollute the original model and become in the end much less attractive? Or, if we do not make it easier to use legacy code, will people turn away because they feel affronted that their direct needs are not addressed? Should we leave these issues to framework implementations making legacy code not really portable?
The current popularity of OSGi seems to allow the OSGi to make a stand. What do you think?
Peter Kriens
There will never be a way to please everyone but maintaining simplicity and staying true to OSGi's original model (which works!) will have the most long term benefits. Remember, it is the original model that is behind OSGi's current momentum and success.
ReplyDeleteI was personally attracted to OSGi because of its simplicity -- to me, it just makes sense. It does what it needs to and nothing else. If OSGi was that unfriendly to legacy code, it would have never made it this far, particularly on the server side.
-r.brown
I've been developing OSGi applications through the Eclipse RCP for about 4 years now. Its mostly been a very pleasant experience.
ReplyDeleteI agree with keeping OSGi feature-simple (as in, removing Require-Bundle). However, the functionality of Require-Bundle is what keeps Eclipse so easy to develop for. Since there is a one-to-one relationship between your plugin requirements and the plugin satisfying the requirements, its easy to look up code while developing and deploy required bundles while distributing.
Eclipse does a very good job of helping the developer through the development and distribution process by detecting required bundles at launch-time and at build-and-assembly time. I hope that some standards could be included for these crucial points so that developers can have a common experience across containers.
Keep up the good work, OSGi is a great model!
-Heath
OSGi is great. Require-Bundle is a perfect example of a feature which could be easily avoided if the tooling would have been ready earlier. Maybe tooling is also an answer for getting legacy code to work?
ReplyDeleteAnyway, even if you get legacy code to work there is no guarantee for any success. Some (most?) legacy code is what it is no matter if it runs on OSGi or on any other container - a legacy of static stuff.
Frankly, OSGi already has a model which supports legacy code very well. Just put everything into one bundle. Once you come over regretting bygone times you can start splitting the bundle and make it modular.
please stay simple ! this is the most attractive part of OSGI for me.
ReplyDeleteI'm developing an OSGI client/server ERP solution (Eclipse RCP, Eclipse Riena, Easybeans,...)
alone the steps to combine some OSGI-based frameworks is hard because of
* using require-bundle for common used bundles
* fighting with "core" bundles including 20 or more jars
the best is to keep it simple:
* use import/export whereever possible
* use required-bundle (if really neded) only inside the scope of a framework, but never for 'standard' open source jars
tooling is the key to help developers to build a good OSGI architecture, so from my opinion use tooling to help integrating legacy code or as gunnar said: put it into a bundle
ekke
Please keep things as simple as possible (in the core). It's the main thing that is attractive about OSGi...
ReplyDeleteFor example, keep those JEE guys at bay and not introducing scoped classloaders... and other crazy things that aren't needed.
My company is seriously looking at OSGi for our next-generation product architecture. I love the ability to expose only API packages, and to explicitly declare bundle dependencies. We do, however, have the requirement to be able to have "application bundles" contribute classes and configuration to a "persistence bundle" that uses Hibernate. Without Require-Bundle, what is the proposed mechanism to allow the application bundles to access Hibernate CG proxy classes (as described in another blog post)? It is complex enough to use Hibernate with OSGi, but if you make it impossible by removing Require-Bundle, then OSGi will no longer be a candidate technology for our product.... I wish there were a way to keep developers from abusing Require-Bundle, but completely removing it would not be the way if it is still necessary for Hibernate support, for example.
ReplyDeletePlease get one thing straight: we will not remove anything. Backward compatibility is very important for the OSGi.
ReplyDeleteInterestingly, you illustrate the problem quite well. There is no intrinsic need for a Object-Relational mapping tool to require Require-Bundle. The problem is that hibernate was build with a linear class path in mind. It is perfectly possible to create a much more modular (imho therefore better) solution to the ORM problem that does NOT require all the hoops and tricks needed to run hibernate (and many other linear classpath based solutions) on OSGi.
People are attracted to OSGi because it addresses many of the problems with Java's linear class path. We have been able to keep it lean and mean as well (27 classes, which are mostly small interfaces). Should we change the spec (for the worse, at least will become significantly more complex and less safe) to accommodate Hibernate or will Hibernate (or a competitor) make a version that leverages OSGi's strengths? I guess that is the $1000 question :-(
About application bundles ... watch this space. People are pressuring me to outline my view about this.
Kind regards,
Peter Kriens
Richard, an alternative to Hibernate which is already OSGi friendly is EclipseLink. It was born out of Oracle's TopLink product and open-sourced to the community. It just hit its 1.0 release so you may want to evaluate it if you're in the need of a persistence solution for OSGi.
ReplyDelete