How big should OSGi bundles be?

Question

Or more completely "What are the trade-offs and questions that should be raised when trying to decide the bundle structure of an OSGi application?"

Our existing OSGi bundles have tended to be quite fat: basically an API bundle and an implementation bundle, but with a lot of functionality. That has advantages in terms of project and build complexity, but maybe doesn't give us all the reusability and flexibility we desire.

So in a recent project, we intentionally made quite thin bundles. We did a walkthrough this AM and we wondered if we'd gone too far. In this quite-small service we had 7 bundles, several of which only had 1 domain class. The question raised was "This is almost like we're driving towards a bundle per package. But we have classes and packages already in the language, are we going too far with our bundle granularity?"

To make it concrete, this is a Web Service that performs a calculation on the aggregate results of other Web queries (specifically, we query a bunch of astronomical databases for objects in a given area and then we filter the results based on our own criteria and then we estimate a probability of an adequate observation based on the filtered results). We ended up with 7 bundles, which seems like a lot for what is essentially "a servlet that performs a calculation."

Is such very-fine granularity good (lots of flexibility at runtime) or bad (overly complicated)? How can we develop our intuition about the "just right" granularity of our OSGi bundles?

Answer 1

Since there hasn't been any answer so far, let me just give you an impression of how I usually approach this matter. To me, OSGi bundles roughly correspond to components in software architecture and the most important factor in whether or not to turn something into its own bundle is the value of being able to exchange it.

Whenever you can imagine that a future version of your product may want to rely on a different component that performs the same tasks (i.e., same interface), but does it in a different way, turning it into an OSGi bundle certainly isn't the worst way.

Another (albeit obvious) point is when you are writing software that can be extended by others via adding their own bundles.

As all of this sounds rather abstract, let's make it more concrete based on your example:

• you aggregate results of web queries. I wouldn't mind bundling up aggregators for each database. Chances are that you may have to add in another database someway down the road and you should be able to easily delegate that task to others by giving them an existing bundle for another database and ask them to add the new one in the monkey-see monkey-do way.

• you filter results. Filters are one of the things that tend to change quite often, and hence, are a natural fit for bundling so you can easily exchange them.

As for the calculations I do not know enough about it, but generally I do not think 7 bundles are too much for what you're describing.

There is one thing to keep in mind though: the effort of creating so many bundles only really pays when you have a product that is continually being worked on. If in the following weeks/months/years you will be adding new bundles all over the place, having a fine granularity makes it easier to fit the new functionalities in and replace old ones.

If on the other hand you are going to have to rewrite almost everything anyways, because your product only ever receives major upgrades that seem like new products, then you do not gain much anyways.

Answer 2

Keep it as simple as possible until you need the complexity. Ie: Do not engineer the bundles until there is a clear value in having them. As simple as possible but no simpler.

You are unlikely to predict exactly where your bundles should be split in the future and where you will want to extend now. By over-bundling, you are creating a maintenance headache for the future, once you do have a requirement for bundle swapping.

Answer 3

One of the biggest benefits of OSGi is that it creates really loose dependencies between your components or services. This lets you do hot deployment in production environments. If you view this as a key reason for using OSGi, then it makes sense to bundle packages that you think will need to change together. If it can be changed independent of the rest of the application, you should probably put it in its own bundle. The overhead of creating a new bundle is reasonably low, so you shouldn't worry too much about over-complicating your system with multiple bundles.