This link has been bookmarked by 24 people . It was first bookmarked on 21 Mar 2007, by cwalltx.
-
12 Aug 11
-
13 Dec 10
-
27 Oct 10
-
08 May 09
-
22 Apr 09
-
Until very recently, the choice for Eclipse developers has been very clear: the Extension Registry is still used in almost all plugins and RCP applications, to the exclusion of OSGi Services. This is reinforced by the tooling that is available in Eclipse PDE, which provides lots of support for extensions and none for services.
-
An extension point is a declaration made by a plug-in to say that it is open to being extended with new functionality in a particular way.
-
the only time that all of the plug-ins are scanned is when Eclipse is started for the first time, or when your run it with the -clean command line switch.
-
The key thing to notice here is that no Java classes in the extension plug-in have yet been loaded. We have merely loaded some XML data; this takes far less time and memory than creating a ClassLoader and using it to load code.
-
So it is up to the definer of the extension point to decide when the code in the extensions is loaded.
-
No code is loaded until the user has expressed an interest in the button
-
-
they needn’t result in any code being loaded at all. It is entirely up to the definer of the extension point. There are many extension points in the core RCP plug-ins that do not require a
classattribute. -
all of the Help documentation in Eclipse is contributed through extensions, and there is no Java code involved — just HTML files.
-
This is slightly harder because the service layer in OSGi is implicitly dynamic — we have to be prepared for the fact that services can come and go at any time.
-
ServiceTracker -
Doing this with the lower level APIs such as
ServiceListenercan be quite error-prone, so it is recommended to always useServiceTrackerto consume services. -
the
BundleContextinterface is the only way for bundles to interact with the facilities of the OSGi runtime. -
until the bundle is loaded, there can be no services registered. Suppose, then, that all the functionality of our application is implemented as OSGi services. Which bundles do we start?
-
The third option is to know in advance which bundles need to be started, and only start those. This option is very hard to achieve when services are registered by programmatic code
-
they are very much better at dealing with dynamic installation and uninstallation than extensions
-
we might as well start all bundles when the server comes up
-
an extension is explicitly intended for consumption by one particular plug-in
-
Another key difference is in the way that services and extensions interact with their consumers.
-
implicitly dynamic like services, but loaded “on demand” like extensions.
-
Service Binder, together with some input from the Eclipse developers (who by this point had become heavily involved in OSGi) evolved into a framework called Declarative Services (DS), developed within the scope of OSGi Release 4. An implementation of Declarative Services can be found in the Equinox project. Equinox is an implementation of OSGi Release 4 and it has been at the core of Eclipse since version 3.0.
-
there are actually two separate responsibilities involved in offering a service. Firstly somebody has to create an implementation of a service. Secondly somebody has to publish the service in the service registry.
-
the responsibility for registering services is subsumed by a special bundle called the Service Component Runtime or SCR.
-
As opposed to extensions (where there is a single XML file per bundle and it is always called
plugin.xml), there can be an arbitrary number of XML files per bundle, with arbitrary names. -
in the bundle manifest under a new
Service-Componentin order for SCR to find them. -
When the SCR registers a delayed service, it creates a proxy object to act as a placeholder, and registers that in the service registry.
-
what happens if service A goes away
-
Next, what happens when there are twenty instances of A?
-
- Optional vs mandatory.
- Unary vs multiple.
- Static vs dynamic.
-
A dependency is dynamic if it can be hot-swapped
-
If service C has a static, mandatory dependency on B, and service B has a static, mandatory dependency on A, then every time an instance of A goes away we find that both B and C must be stopped and restarted. When the graph is large, we find that a single service restart can cause an avalanche of restarts across the system. However the avalanche stops when it hits an optional or dynamic dependency. So for the most scalable solution, it is good practice to make your dependencies optional and dynamic whenever possible.
-
DS is built on services
-
Two alternatives from Apache Felix are the Felix Dependency Manager, and a library called iPOJO. However I believe that the stiffest competition will come from the Spring Framework.
-
They reckoned that if Spring and OSGi could work together, then the resulting platform would benefit from OSGi’s strength in dynamics and Spring’s strength in simplified programming models and reduced boilerplate.
-
recent suggestions from Peter Kriens (the OSGi Evangelist) indicate that he is in favour of Spring-OSGi becoming part of the OSGi specification in Release 5.
-
The Extension Registry is implemented by the bundle
org.eclipse.equinox.registry, which depends onorg.eclipse.equinox.common. These bundles are implemented with pure OSGi code.
-
-
13 Feb 09
-
07 Nov 08
-
28 Jul 08
-
18 Jul 08
-
23 Apr 08
-
20 Dec 07
-
03 Oct 07
Hendy IrawanIn this article I have described in general terms some of the strengths and weaknesses of Eclipse-style extensions and OSGi-style services. However I would not wish my readers to take away a simplistic message that “extensions aren’t dynamic” or “
article articles build code design dev eclipse development spring programming service plugin extension java osgi
-
03 Aug 07
-
09 Jul 07
-
04 Jun 07
-
An extension point ID, which consists of a “namespace” and suffix. The namespace is usually the ID of the plugin in which the extension point is defined, but it need not be. This is different from an “XML namespace”.
A human-readable name.
An XML schema document, which defines the structure of the meta-data that extensions are required to supply.
The ID of the extension point.
An XML node, which must comply with the schema specified by the extension point.
The Extension Registry is a place where extension points are matched up with extensions. An extension point is a declaration made by a plug-in to say that it is open to being extended with new functionality in a particular way. It is found in the
plugin.xmlfile for the plug-in, and it consists of:An extension is the flip-side of the coin. It is a declaration by a plug-in to say that it provides functionality to extend another plug-in. It is also found in the
plugin.xmland it specifies: -
You could think of the registry as being just like a pair of
HashMaps, that allow Eclipse to lookup either extensions or extension points by their ID -
The registry API provides the plug-in with a snapshot of all the currently installed extensions for the ID that was queried, as an array of data structures that closely resemble the actual XML nodes given by the extension.
-
The key thing to notice here is that no Java classes in the extension plug-in have yet been loaded. We have merely loaded some XML data; this takes far less time and memory than creating a ClassLoader and using it to load code
-
up to the definer of the extension point to decide when the code in the extensions is loaded.
-
extensions are declarations
plug-ins consult extensions to create placeholders for functionality
the functionality behind the placeholder is realized when the extension point definer chooses, which enables lazy loading and smaller memory usage
extensions need not be associated with executable Java code
The points to take away from this are:
-
To register a service, a bundle must first create an object, and then it must make a call to the OSGi API to register the object as a service.
-
ServiceTrackeralso makes other types of interaction with services easier, such as keeping track of when the service is registered and unregistered -
When the bundle is started, the runtime calls the
start()method of ourBundleActivatorand supplies aBundleContextinstance. Before our bundle can be started, it must be loaded. Therefore, until the bundle is loaded, there can be no services registered. -
the API for working with services is inherently dynamic.
-
The extension model is essentially “one-to-many”, meaning that an extension is explicitly intended for consumption by one particular plug-in; i.e. the definer of the extension point. On the other hand services use a “many-to-many” model, meaning that a single service can have many consumers.
-
however the responsibility for registering services is subsumed by a special bundle called the Service Component Runtime or SCR
-
A bundle containing services that it wants the SCR to manage on its behalf contains one or more XML files, with each file representing a “Service Component”
-
To support lazy registration, Declarative Services has the notion of “delayed” services. When the SCR registers a delayed service, it creates a proxy object to act as a placeholder, and registers that in the service registry. From the point of view of a consumer, the service is now available for use, however the bundle containing the real service implementation has not been started yet. Then when a consumer tries to actually use the service, the SCR detects this, and asks the OSGi runtime to fully load and activate the bundle. It then subtitutes the proxy for the real service. A key difference between extensions and Declarative Services is that, for the consumer, DS implements laziness transparently, i.e. the code that uses a service need not know or care that the service is temporarily only represented as a placeholder. In contrast, the consumer of an extension must create and manage the placeholder explicitly, and choose when to swap the placeholder for the real implementation.
-
In the XML file for service B, we simply create a
referenceto service A – then SCR will wire up the dependency whenever it can be satisfied. -
dependency is optional or mandatory
-
- Optional vs mandatory.
- Unary vs multiple.
- Static vs dynamic.
These are all valid questions, and the answer in each case is that it depends on our requirements. Therefore DS provides control in the three dimensions involved:
Combining the first two axes gives the familar four choices of
0..1(optional + unary),1..1(mandatory + unary),1..n(mandatory + multiple) and0..n(optional + multiple). The third axis is less familiar. A dependency is dynamic if it can be hot-swapped, i.e. if service B can be supplied subtitute instances of A. Sometime this isn’t possible; for example A might be stateful, or B may simply not be able to handle substitution because of the way it was programmed. We say that the dependency is static – we must destroy B and create a new instance of it.
-
-
27 Apr 07
-
13 Mar 07
-
12 Feb 07
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.