Java Reference
In-Depth Information
way to determine dependencies ahead of time; there's no possibility of a resolution
phase, so whether your application can run is a crapshoot.
In summary:
Karaf features are simple
XML
files and so don't provide any mechanism to
allow bundles to be provided within the archive. Bundles are expected to be
retrieved from a Maven repository, or a repository available to the rest of the
server runtime.
■
Karaf features offer no real concept of scoping; applications share the same
OSG
i framework for all their bundles, allowing for unforeseen interactions
when new applications are deployed.
■
Like a plan file, a Karaf feature provides no guarantees that missing dependen-
cies will be satisfied when it's installed and you must encode the name of the
bundle that provides your dependency. Adding wrappered
JAR
files provides yet
further uncertainty because it isn't clear what packages are needed or exported.
■
We believe that as implementations of the subsystems specification become available,
the amount of fragmentation in the area of
OSG
i application packaging will reduce.
But it may take a while because technologies are a bit like genies—it's hard to make
them go away once they've been released! Although we think subsystems are the
future of
OSG
i applications, we expect you want to try something out now. At the time
of writing, Apache Aries is working on a subsystems implementation, but none have
been released. But
EBA
s provide a good alternative. We hope it's clear to you what the
advantages of an
EBA
are over the other models we've discussed, primarily around
flexibility of management. Although the names have changed round,
EBA
s are also
the starting point for subsystems, so time spent understanding
EBA
concepts won't be
wasted. For now, we've spent enough time discussing what an
EBA
is, and we're ready
to package our superstore application as an
EBA
.
4.5
Developing an enterprise OSGi application
Having learned about application packaging, and particularly about the
EBA
packaging
model for enterprise
OSG
i applications, it's time to build an application from the bun-
dles that you've been playing with so far. By the end of this section, you should have an
EBA
that can be deployed on your development stack or on top of an application server
that supports
EBA
-packaged
OSG
i applications. The
EBA
you produce will, broadly
speaking, follow the best practices for application packaging; however, at one or two
points you'll have to make allowances for the limitations of the development platform.
The limitations of the development stack
The main limitation you face is that the development platform doesn't offer any way
to configure bundle repositories to use for remote provisioning. As a result, although
you could add an OSGi Bundle Repository (OBR) -based resolver to your platform,
there wouldn't be much point!
