Using Service Binder components is an ideal way to create
dynamically
extensible (i.e., "plug-in") systems. Plug-ins typically extend the
functionality of an application core and do so by implementing a
well-defined interface. Dynamically extensible systems require that the
plugins can be incorporated into the system after the system has been
installed. This is normally achieved through a late linking
mechanism. Examples of this kind of applications are abundant, they
range from web browsers, such as Mozilla, to platforms such as NetBeans
or Eclipse. An advantage of building this kind of applications out of
Service Binder components deployed in OSGi bundles is that plugins can
be incorporated or removed
during execution thanks to the OSGi platform deployment mechanisms. The
following sections discusses briefly the approaches that can be
followed to build this kind of applications.
There are two different approaches to implement a plug-in system.
They are called extensible
application core and service
provider application core.

Figure 1. An extensible core

In traditional OSGi programming, the first approach would be
preferable as service dependency management logic would be centralized
in the core while in the second case this logic would have to be
replicated inside every plug-in. This, however, is not a concern when
using the Service Binder as no service dependency management logic has
to be written. Finally, a combined approach can also be followed.
The extensible system can be launched by starting an OSGi framework
where the bundles containing the core, the plugins and the
Service Binder bundle are installed. The applications is dynamically
assembled as services become available. As soon as the core component
instance is activated, the application begins its execution. The core
can be notified of its activation by implementing the Lifecycle
interface.
A big advantage of building extensible systems based on
Service Binder components are that the OSGi platform provides
mechanisms that allow plugins to be installed, removed or updated from
an URL while
the system is being executed. If service dependencies are defined as
being
dynamic, then the resulting application is capable of incorporating,
releasing or updating the plugins as it is being executed.

The people at Ascert have
developped an application based on the principles exposed above (see
screenshot in Figure 3). Their system allows multiple visualisation
tools to be incorporated into a service providing core. The core
provides services that allow, among other things, the tools to add new
entries in the toolbar menu. We are very grateful to them for providing
us with
this example, and for being active testers and contributors of OSCAR
and the Service Binder.