What does the term application mean in the context of modular software development (and OSGi in particular). It seems to me that the concept of an application starts to break down. For instance, is an OSGi application just the set of bundles known to the framework?
Well, here’s my take on what a modular application might mean.
Going beyond the steady state
When an OSGi framework fires up, some bundles may be activated, others may not. Some activators may perform logic, others may not. But what arises from this activity? Is this the equivalent of launching an application? It can be, but its more often the case that the framework arrives at a steady state, waiting for an input that triggers some behavior.
This can be confusing when we start using OSGi because this doesn’t look like an application. What we need is an entry point. Just as throwing a rock into a pond causes waves to form, we need to launch a thread of execution that takes us beyond the steady state. So how do we accomplish this?
The Eclipse platform provides us with one answer in the form of an Eclipse application. An Eclipse application is defined through the
org.eclipse.core.runtime.applications extension point and is represented by an
IApplication instance at runtime. And this mechanism can easily be added to Equinox by installing some additional bundles.
This is how, for example, Eclipse RCP applications are launched in the context of an OSGi framework. But it’s interesting to note that one set of bundles may support multiple applications. So a good way to look at an application is that it is merely a specific entry point into the functionality provided by a community of bundles.
The OSGi Application Admin service
We can take the concept of an OSGi application one step further by utilizing the OSGi Application Admin service. This service recognizes the concept of an application in the abstract (specific providers can define what an application means in each case), and allows an application to provide an entry point that will launch a thread of execution.
Equinox, for instance, provides an application descriptor for Eclipse applications. This means that you can use the Application Admin service to start and stop Eclipse applications from the OSGi console. The available console commands are:
apps– list currently available applications
activeApps– list currently active applications
startApp [app id]– start an application
stopApp [app id]– stop an application
These commands can be used to launch most types of Eclipse applications, including those with an SWT user interface. Unfortunately, they cannot yet be used to launch Eclipse RCP applications because of the way in which singletons are used. This is scheduled to be fixed as part of the e4 work.
I think all of this is pretty exciting because it allows us to reimagine the relationship between applications, modules and running platforms (JVMs and OSGi frameworks). For example, imagine being able to deploy an Eclipse RCP application into a running OSGi-based ESB. The application would allow you to manipulate the ESB in container and it could then be undeployed when no longer needed. All of this could be done without restarting the ESB.
It’s going to be fascinating to see how of all this plays out in the next few years. The possibilities are endless!