On Plug-ins

and Extensible Architectures

DORIAN BIRSAN, ECLIPSE

40 March 2005 QUEUE rants: [email protected]

 FOCUS
Patch and Deploy

Extensible application In a world of increasingly complex

architectures such as Eclipse computing requirements, we as
software developers are continually
offer many advantages,
searching for that ultimate, univer-
but one must be careful to sal architecture that allows us to
avoid “plug-in hell.” productively develop high-quality
applications. This quest has led to the adoption of many
new abstractions and tools. Some of the most promising
recent developments are the new pure plug-in architectures.
What began as a callback mechanism to extend an
application has become the very foundation of applica-
tions themselves. Plug-ins are no longer just add-ons to
applications; today’s applications are made entirely of
plug-ins. This field has matured quite a bit in the past few
years, with significant contributions from a number of
successful projects.
This article identifies some of the concepts around
the foundation of pure plug-in architectures and how
they affect various stakeholders when taking a plug-in
approach. The intention is to discuss the general issues
involved, but the article also presents some lessons
learned from Eclipse (www.eclipse.org) to better illustrate
some of the concepts.

MOTIVATION FOR PLUG-INS

Customers’ requirements control the creation and deploy-
ment of software. Customers demand more and better
functionality, they want it tailored to their needs, and
they want it “yesterday.” Very often, large shops prefer
to develop their own in-house add-ons, or tweak and
replace existing functions. Nobody wants to reinvent
the wheel, but rather to integrate and build on existing
work, by writing only the specialized code that differenti-

more queue: www.acmqueue.com QUEUE March 2005 41

 FOCUS
Patch and Deploy

hosting application is reduced to a runtime engine for

On Plug-ins
running plug-ins, with no inherent end-user functional-
ity. Without a directive hosting application, what is left
is a universe of federated plug-ins, all playing by the rules

and Extensible Architectures of engagement defined by the framework and/or by the

plug-ins themselves.
To support composing a larger system that is not pre-
ates them from their competition. Newer enterprise-class structured, or to extend it in ways you don’t foresee, the
application suites consist of smaller stand-alone products architecture must support the extensibility of plug-ins by
that must be integrated to produce the expected higher- plug-ins. In the absence of a hosting application, plug-ins
level functions and, at the same time, offer a consistent themselves become hosts to other plug-ins by providing
user experience. The ability to respond quickly to rapid well-defined hook points where other plug-ins can add
changes in requirements, upgradeability, and support functionality. These hook points are commonly known as
for integrating other vendors’ components at any time extension points. When a plug-in contributes an imple-
all create an additional push for flexible and extensible mentation for an extension point, we say that it adds an
applications. extension. Much like defining any contractual obligation,
Down in the trenches, developers must deal with an extension model provides a structured way for plug-ins
complex infrastructures, tools, and code. The last thing to describe the ways they can be extended and for client
they need is to apply more duct tape to an already com- plug-ins to describe the extensions they supply.
plex code base, so that marketing can sell the product In a simplified way, figure 1 illustrates the main
with a straight face. The new plug-in architectures are structural difference between traditional and pure plug-in
very attractive to developers because they can focus on architectures.
providing modular functionality to users. Anyone can
quickly customize applications by mixing and matching PLUG-IN RUNTIME CONSIDERATIONS
the plug-ins they need, or write new plug-ins for missing As already mentioned, plug-ins are not stand-alone
functions. The price to pay for such flexibility is manag- programs; their execution is orchestrated by a runtime
ing these plug-ins. We discuss this and other issues later engine. The plug-in runtime engine—let’s call it the
in the article, and you can decide if it is worth the price. kernel—is the core engine that is started when a user
launches an application. At a minimum, the kernel must
TRADITIONAL PLUG-INS VERSUS PURE PLUG-INS provide runtime support for the basic plug-in infrastruc-
Most people are familiar with traditional plug-ins, down- ture by:
loadable software bundles that extend the functionality • Finding, loading, and running the right plug-in code.
of hosting applications
such as Web browsers or
text and graphical editors. Traditional Plug-ins vs. Pure Plug-ins
They are not compiled into plug-in plug-in plug-in plug-in plug-in
the application, but linked
via well-defined interfaces
and extension mechanisms. plug-in plug-in
Most often, building a
plug-in does not require plug-in plug-in
host application
access to the source code
of the application. Plug-
ins implement functions plug-in engine
that the host application
traditional plug-ins pure plug-in system
can recognize and activate

FIG 1
when needed.
In the new pure plug-in
architectures, everything is
a plug-in. The role of the

42 March 2005 QUEUE rants: [email protected]

• Maintaining a registry of installed plug-ins and the 2. An applications extension must provide a concrete
functions they provide. implementation for the extension point’s callback
• Managing the plug-in extension model and inter-plug- interface, IPlatformRunnable.
in dependencies. 3. Eclipse’s default applications extension is contributed
Optionally, the kernel can supply other utility services, by the IDE plug-in, by providing a concrete implemen-
such as logging, tracing, or security. The user should also tation class that, when called by the extension point
be able to turn off or remove parts of the application, or handling code, creates the workbench graphical user
dynamically install new functions. For obvious reasons, interface and runs the event loop until it exits.
it is desirable for the kernel to be small and simple, yet This workbench window looks like any standard appli-
robust enough to build industrial-strength functionality cation: it has menus, toolbars, views, and editors, and you
on top of it, without many (or any) hacks. can launch wizards, open preference dialogs, and so on.
To illustrate the basic workings of a plug-in environ- The basic workbench by itself, however, is just a frame for
ment, let’s take a behind-the-scenes look at the Eclipse displaying visual parts and other user interface elements.
plug-in runtime structure and control flow. While mostly Its power comes from the extension points (e.g., views,
known as a powerful Java integrated development envi- wizards, editors, action sets, help support) it defines, to
ronment, Eclipse is actually a universal plug-in architec- which other plug-ins, or the workbench plug-in itself, can
ture for creating “anything, but nothing in particular.” contribute extensions.
The runtime engine itself is implemented as a number of In general, the plug-in that defines an extension point
core plug-ins, except for a tiny bootstrap code. This code is responsible for looking up its extenders (using the
starts the core plug-ins to initialize the plug-in registry extension registry), instantiating the associated callback
and the extension model and to resolve plug-in depen- class, and invoking the appropriate interface methods.
dencies. Other than the core plug-ins, no other plug-in Under the covers, the runtime kernel is responsible for
code is run at this time. All the needed plug-in metadata providing the extension registry lookup functionality,
is read from the plug-in manifest files (plugin.xml and/or creating a class loader for the extender plug-in, loading it,
manifest.mf). and starting it. This ensures the extender plug-in is initial-
Once the initialization is complete, the runtime kernel ized and active before its classes are created and run.
is ready to run applications. The extension mechanism, Finally, it is worth noting that some extension points
shown in figure 2, kicks in and an entire application is may require more than one callback interface and others
built progressively, from inside out, as follows: do not require any. For example, the help system exten-
1. The runtime core plug-in defines an applications exten- sion point toc is used for contributing documentation
sion point so that any plug-in can declare itself an tables of contents and does not require any callbacks.
application by contributing an extension to it. When help is invoked, the help plug-in processes the toc
extensions by creating a
larger, integrated table of
Eclipse Plug-in Extension Mechanism contents from all contribut-
runtime core plug-in IDE plug-in ing plug-ins.

applications contributes workbench

extension point extension CONFIGURING AND
DISCOVERING PLUG-INS
An important consideration
implements
IPlatformRunnable IDEApplication when deploying a plug-in
interface class
system is configuring and
discovering the plug-ins.
Unlike monolithic appli-
instantiates IDEApplication, then calls its run() method cations that are typically
installed in one folder on

FIG 2
a user’s machine, plug-in-
based applications may
have a higher degree of
freedom for installation

more queue: www.acmqueue.com QUEUE March 2005 43

 FOCUS
Patch and Deploy

CHALLENGING ISSUES

On Plug-ins
Pressured by time, budgets, or slick marketing claims,
you may be tempted to adopt a pure plug-in architecture
without being aware of its potential pitfalls. Alternatively,

and Extensible Architectures you might truly believe in Murphy’s law and therefore
won’t use plug-ins because they’re doomed to fail, any-
way. I tend to follow those who walk the middle road: if
layout and plug-in discovery. This flexibility can also be something can fail, then it first should be understood and
a source of major headaches for installers and plug-in then fixed. The rest of the article presents issues that are
management. likely to pose some challenges when you employ plug-ins,
Consider a multiuser shared installation where the and that will help you ask questions or provide answers
entire product is installed by the central administrator when evaluating a plug-in architecture.
on behalf of a community of users. The individual users Installing and updating. Many modern products auto-
do not need to perform any installation. They are simply matically detect when they are out of date with respect
given a local “shortcut” to invoke the shared installation to available service or product version. Either on start-up,
(the shortcut can be in the form of a command-line invo- or as a result of an explicit update action, the products
cation or a true desktop shortcut encapsulating the com- compare the current installation level against some
mand-line invocation). If you’re like most users, you will network-based baseline. The product then automatically
want to install some other cool new features, especially downloads required fixes or upgrades and applies them,
when the third-party plug-in offerings are plentiful (and often as part of the product execution. Additionally, users
often free). Obviously, the new plug-ins, private to that can, and most often will, install additional plug-ins from
user, cannot be installed in the read-only, shared install various sources to extend the functionality provided by
location, so the product should allow users to install and their current application.
configure extra plug-ins in a location where they have For plug-in-based applications, the installation and
more privileges. update process can be a real nightmare: on the one hand,
Configuring only a subset of plug-ins for a particular there are the traditional installation issues that arise in
user based on access criteria, such as user roles, adds more any application—ability to roll back changes, migrate
challenges. Other configuration issues arise in scenarios existing program data and preferences, or ensure the
where a common set of plug-ins is shared by many appli- installation is not corrupted. On the other hand, because
cations running on the same machine, or where some plug-ins may originate from various providers that are
plug-ins are not installed locally but run from a remote not related to each other, the resulting configuration has
location (e.g., an application server provider). likely never been tested. This poses a number of interest-
In theory, the platform must find the available plug- ing challenges that we address in the context of the other
ins on its own and gracefully cope with missing plug- issues discussed in the next sections.
ins or those that are dynamically coming and going. Security. Systems can never be too secure, and you
In practice, many solutions for these problems involve need to pay particular attention to securing a sys-
predefined files and directory locations for key configura- tem based on plug-ins. Since arbitrary plug-ins can be
tion files or for the plug-ins themselves. More advanced installed—for example, by downloading them from the
plug-in systems offer pluggable configuration and plug-in Web—and are allowed unlimited access to the system
discovery mechanisms. Usually some basic bootstrap they plug into, security in a plug-in environment must be
code is run to start a configurator plug-in, which will then carefully planned. On top of this, some plug-ins require
discover the other plug-ins based on its own strategy. For support for executing custom install code during instal-
example, Eclipse provides an Update Manager configura- lation, so they can have control over some parts of their
tor plug-in that picks up plug-ins from the eclipse/plugins installation. To prevent software security accidents or
folder, as well as from other local plug-in folders linked failures, the plug-in framework must address the issues of
from the eclipse/links folder or dynamically added when downloading from third parties and controlling a plug-
users install new plug-ins to locations of their choice. in’s access to other code and data. Supporting digitally
Because the configurator is pluggable, anyone can plug in signed plug-ins or secure connections helps, but it still
another configurator, which can provision and configure relies on trusting the download source or the plug-in
the plug-ins from a remote server. provider. Some programming environments, such as Java,

44 March 2005 QUEUE rants: [email protected]

offer built-in runtime security mechanisms that can be The install/update process may need to abort installation
used effectively to close some of the security gaps. of plug-ins that leads to an unresolved dependency, or
The cold reality is that, unless you are careful about search for and install the missing plug-ins. Either way, it
what you install, it is almost impossible to be confident is possible to end up with multiple versions of the same
that the installed plug-ins are not ill-intentioned. Of plug-in, so we’re back to the problem of managing con-
course, a pure plug-in architecture also means that even current versions.
a well-intentioned plug-in with serious bugs can do as There is no simple, general solution to managing
much damage as an ill-intentioned one when installed. concurrent versions of plug-ins. Eclipse has adopted a
Concurrent plug-in version support. Without a doubt, reasonable trade-off convention for concurrent plug-in
managing concurrent plug-in versions and dependen- versions: only versions of plug-ins that contribute code
cies is one of those problems that can keep architects, libraries but no plug-in extensions (no user interface
developers, and installation folks awake at night. Most of contributions, no documentation, and so on) are allowed
you have probably experienced “DLL hell” at some point to coexist in the same runtime instance. For all the other
and will look with suspicion on something that has the plug-ins, the latest version is usually picked up, unless a
potential of being a “plug-in hell.”
Any serious plug-in model defines some versioning
scheme, but allowing multiple versions of a plug-in to be Managing concurrent plug-in
concurrently installed and executed is an issue that must versions can keep architects,
be considered early on in the design, and it must be prop- developers, and installation folks
erly enforced by the install and update processes.
To illustrate the complexity of this area, let’s start
awake at night.
by considering the scenario of an application suite
that integrates two stand-alone plug-in products, each
installed in a separate location. It is possible to have the
same plug-in, at the same version or at different versions,
installed in two locations. The runtime kernel must deal configuration file precisely defines what to run. The main
with the two plug-in instances by either running them advantage of this approach is that it still allows various
both or dropping one. When both versions are running, levels of the same code to coexist at runtime, but hidden
and the plug-ins contribute user interface elements such to the end users, who will get a consistent user interface.
as menus or preference pages, the result may be a very The downside is that this will not cover all user scenarios,
confusing interface, with duplicate menu entries or pref- and that plug-ins are not treated uniformly as elsewhere
erence pages. There is more trouble: would the user need in Eclipse. This special treatment of plug-ins is not just a
to be exposed to this anomaly? How would you update or runtime/install issue, but also something that developers
uninstall these plug-ins? and product packagers must consider.
The difficulty of the problem is amplified by the other Scalability, up and down. Another challenge of work-
important role plug-in versions play here: they are part ing with plug-in architectures is scalability. Just as the
of plug-in dependency specifications. Typically, a plug-in problems associated with multiple versions and depen-
requires the functionality provided by other plug-ins, and dencies can quickly escalate, so too can the sheer number
very often there are strict criteria about what versions are of interacting plug-ins quickly become a problem. For
required. For example, a plug-in may require a certain example, when Eclipse was first designed, it was thought
level of an XML parser contributed by another plug-in, or that a product, a large one for that matter, would consist
it may need to contribute an extension to a particular ver- of a few hundred plug-ins. A few releases later, some
sion of an extension point only. Version dependency can enterprise-class products built on Eclipse are known to
be in the form of a fixed version number such as 3.0.1, have passed the thousand plug-in mark, so the platform
or as a range of versions—say, 3.0.1 or newer. Properly goal has been revisited to support scaling between 5,000
resolving plug-in dependencies at runtime is critical to and10,000 plug-ins.
the correct functioning of the application. Managing When designing a plug-in system for scalability,
plug-in dependency graphs is also critical to ensure a developers must consider various mechanisms that make
consistent configuration state after installing or updat- start-up faster and have a smaller memory footprint. A
ing plug-ins, as well as for properly rolling back changes. general principle of runtime is that the end user should

more queue: www.acmqueue.com QUEUE March 2005 45

 FOCUS
Patch and Deploy

OVERCOMING THE BUMPS

On Plug-ins
General discussion about plug-in architecture and design
issues may not mean much for you or your company’s
bottom line unless you’re a participant or plan to be

and Extensible Architectures one—either by creating a plug-in framework or develop-

ing plug-ins for fun and profit, or by using a plug-in-
based application. Employing a plug-in framework is not
not pay a memory or performance penalty for plug-ins without bumps, but they can be overcome with proper
that are installed but not used. A plug-in can be installed preparation.
and added to the registry, but the plug-in will not be While traditional plug-ins have been around for some
activated unless a function provided by the plug-in has time, the pure plug-in models have only recently emerged
been requested according to the user’s activity. In general, as robust, enterprise-level quality application develop-
this requires support for plug-in declarative functionality. ment environments. As many major industry players are
It is often realized in practice via plug-in manifest files, so rapidly adopting plug-in technologies for their software
no code has to be loaded for obtaining the function con- lines, we can expect further research and development
tributed by plug-ins. Caching of the plug-in registry and into improving the current architectures. Some of the
the plug-in manifests/declarations can reduce process- areas that will receive increased focus will be:
ing during start-up in subsequent application launches, • Security at all levels, including installation, update, and
improving response time. What is gained in performance runtime.
and memory footprint, however, is lost in code complex- • Performance: speed and low resource usage.
ity: more code needs to be written to cache the data and • Improved tools for development, testing, packaging,
to synchronize the cache with changes in the installation and deployment of plug-ins.
configuration. • Improved installation and updates, especially by merg-
Scalability problems almost always surface during ing changes without taking the system down.
plug-in install/update operations. The larger the product, • Remote management of various processes (provisioning,
the larger the download size of patches and upgrades. For configuration, and so on).
product upgrades, the download time can be improved • Convergence, compatibility, or interoperability of vari-
by simply downloading only the plug-ins that changed. ous plug-in frameworks.
Another installation scalability problem can arise dur- • Wider range of deployment platforms (from desktop
ing an interactive install/update operation. Quite often PCs and high-end servers to digital mobile phones and
plug-in boundaries are established for development embedded devices).
reasons (such as function reuse) and present the wrong Increasingly, much of this effort will be happening in
level of granularity in terms of what the user sees as the the open source domain or standards bodies. Q
unit of function, and therefore as an installation unit.
Considering that enterprise-level applications can scale LOVE IT, HATE IT? LET US KNOW
up to hundreds and thousands of plug-ins, with complex [email protected] or www.acmqueue.com/forums
dependencies, the user can be overwhelmed by various
installation choices. A possible solution is to introduce DORIAN BIRSAN has been working at the IBM Toronto Labs
a packaging and installation component that groups a for almost 10 years, leading a range of technical projects on
number of plug-ins to offer a higher level of function. application development tools and writing a number of pat-
For example, in Eclipse, Update Manager does not install ents in the field. He has played an active role in Eclipse since
plug-ins directly; it processes features. Features are bundles its inception, leading the user assistance and the update/
of plug-ins and are considered deployment units with install teams. Mathematician at heart, turned computer
install/update semantics. scientist, and later husband and father, he holds a B.Math. in
The other side of scalability is scaling down, so prod- computer science and combinatorics and optimization from
ucts can run on devices with limited resources, such as the University of Waterloo, as well as an M.Sc. in computer
cellphones and PDAs. This usually means rethinking the science from the University of British Columbia, where he
core framework plug-ins to refactor them into smaller was a National Science and Engineering Research Council of
plug-ins, some of them optionally deployable, so that one Canada Fellow.
can run with a minimal configuration. © 2005 ACM 1542-7730/05/0300 $5.00

46 March 2005 QUEUE rants: [email protected]