The OSGi Applications support in WebSphere® Application Server helps you develop
and deploy modular applications that use both Java EE and OSGi technologies. You can design
and build applications and suites of applications from coherent, versioned,
reusable OSGi modules that are accessed only through well-defined
interfaces. This enables the same, or different, applications to use
different versions of the same third party libraries without interference.
OSGi technology has long been associated with solving application
development challenges around complexity, extensibility and maintenance.
Since WebSphere Application
Server Version 6.1, OSGi technologies have been used internally as
an infrastructure foundation to build the application server product
as a componentized runtime. To bring OSGi infrastructure benefits
to enterprise application developers in the form of an enterprise Java programming model, the OSGi
Alliance Enterprise Expert Group (EEG) was formed in 2007. The EEG
has focused on the specification of common web applications technologies
for an OSGi environment, including the Blueprint component model.
This model standardizes many of the simplicity and unit test benefits
of dependency injection frameworks such as the Spring Framework, and
is now part of the OSGi Service Platform Release 4 Version 4.2 Enterprise
Specification.
Apache Aries is an open community project that brings the modularity,
dynamism, and versioning of the OSGi service platform to enterprise
application developers by implementing key EEG specifications. Apache
Aries delivers a simple to use and lightweight programming model for
web applications that combines the standard Blueprint component model
with familiar Java enterprise
technologies. Apache Aries includes an implementation of the OSGi
service platform Version 4.2 Blueprint component model for fine-grained
assembly, and provides an assembly model for applications that consist
of multiple modules.
The OSGi Applications support in
WebSphere Application Server includes the following
major features:
- Use the OSGi Service Platform Release 4 Version 4.2 Enterprise
Specification Blueprint Container for declarative assembly of components.
This simplifies unit test outside of the application server.
- Use extensions to the Blueprint component model for declarative
transactions and container-managed Java Persistence
API (JPA).
- Develop OSGi application projects using IBM® Rational® Application
Developer, which enforces OSGi visibility rules so that projects can
only access packages from other projects that explicitly declare them
as part of the project externals. This provides environmental support
to development best practices.
- Compose isolated enterprise applications using multiple, versioned
bundles with dynamic life cycle.
- Deploy applications in archive files that contain only application-specific
content and metadata that points to shared bundles. This means that
application archive files can be smaller. It also means that, when
a library is shared by several OSGi applications, only one copy of
the library is loaded into memory.
- Use an integrated bundle repository, and configure the locations
of external repositories, to support the provisioning of bundles to
applications.
- Deploy existing web application archive (WAR) files as web application
bundles (WABs). This allows web applications to use the OSGi module
system.
- Deploy web applications that use Version 3.0 of the Java Servlet Specification.
- Simultaneously load multiple versions of classes in the same application,
using standard OSGi mechanisms.
- Administratively update deployed applications in a modular fashion,
at the bundle-level.
- Deploy applications that use their own versions of common utility
classes, distinct from the versions that are used by the server runtime
environment. Do this without needing to configure application Java EE class loader policies, such
as PARENT_LAST mode.
- Use federated lookup mechanisms between the local Java Naming and Directory Interface (JNDI) and
the OSGi service registry.
- Extend and scale running applications, as business needs change,
without changing the underlying application.
- Update a running application, only impacting those bundles affected
by the update.