Have you ever wondered why it seems so hard to come up the OSGi or RCP learning curve? Or, if you're already an OSGi expert, why beginners seem to have so much trouble “getting it”?
I believe one reason is that there is an impedance mismatch between the way OSGi applications are built and the way the Eclipse IDE works. More importantly, I believe that understanding this impedance mismatch illuminates a very fundamental architectural pattern in OSGi development that I call the OSGi Building Block pattern.
In this blog article, I will discuss the OSGi Building Block pattern in the abstract.
Next week at EclipseCon, Patrick Paulin and I will deliver real code showing how to leverage this pattern to make Eclipse RCP and server-side OSGi application development much easier (Architecture Patterns and Code Templates for Enterprise RCP Applications).
Consider this thought:
Eclipse works in terms of projects and dependencies. But no single project can fully define a production-quality OSGi application.
Why?
Let's use Eclipse RCP as an example:
An RCP developer might first use the “RCP Application with a View” wizard to create her initial RCP application. This wizard generates a single project defining a single OSGi Bundle.
Then the average beginner clicks the “Run” button to launch the platform and to see the wizard's result.
But in order to deploy the application, an RCP developer must create at least the following extra artifact(s):
and normally for an enterprise-class project:
And there is nowhere that I am aware that documents all of these steps in one place. So a beginning RCP developer may flounder for months before he realizes what the minimal ingredients are in a production-ready Eclipse RCP application.
For a Feature-based RCP product, the minimal building-block for a production-quality application can be represented by the following quad:
(Bundle+, Feature+, Product, Releng)
[The trailing plus sign signifies “one or more”, just like in a grammar.]
In other words, for production purposes, the *minimal* RCP application is:
But Eclipse provides no wizards to create all of these things at once. Eclipse provides no refactorings to keep all of these things in sync as they change over time.
The Eclipse RCP wizard and the Eclipse IDE want us to think in projects. But OSGi wants us to think in terms of deployable bundles. Eclipse requires the OSGi (RCP, server-side) developer to keep this entire model in his head, and to manage it manually.
(I think I mentioned that we will deliver simple code illustrating all of this next week? )
Wait! There's more!
The same principle applies for server-side OSGi, just with different names for the parts! For example, Virgo has the following minimal building-block:
(Bundle+, Plan+, ContainerConfig, Releng)
(Okay, I know you can deploy bundles to a WAR, but my understanding is that Plan files are the “new and approved” way to work with Virgo.)
And an OSGi bundle, deployed via P2 is the following minimal set of things:
(Bundle+, Feature+, P2RepoProject, Releng)
Viewing OSGi this way has helped me think about RCP applications much more clearly, because the number of distinct concepts I have to keep track of suddenly just went to 4.
It has also helped me understand how to design my builds in a modular way, because as Nick Boldt blogged, a build's target platform can be composed of multiple P2 repositories, which can be the result of prior builds. In other words, my build can consume its own output.
I call this OSGi quad the “OSGi Building Block” pattern because it comes up frequently in one form or another in nearly all flavors of OSGi software development. The general form can be described as:
(Bundle+, Packaging+, Deployment, Release engineering)
I believe there are two powerful ramifications to this:
Following this second point, I would like to issue the following challenge and invitation to the OSGi community:
To facilitate these discussions, I would like to invite all of the OSGi stakeholders to a BoF session this coming week at EclipseCon.
I think that OSGi's future is bright, and I think that by driving concrete plans to improve developers' lives using the OSGi Building Block pattern, we can help.
(And one final plug for Patrick and my session next week:)
If you're wondering why and how this makes OSGi development simple, come to our tutorial next week at EclipseCon: Architecture Patterns and Code Templates for Enterprise RCP Applications. Next week Patrick Paulin and I will make all of these abstract ideas concrete with real code you can take with you and use as the basis for your next project.
~~LINKBACK~~ ~~DISCUSSION:closed~~