OSGi applications

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 facility enables the same, or different, applications to use different versions of the same third-party libraries without interference.

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 by using IBM® Rational® Application Developer, which enforces OSGi visibility rules so that projects can access packages only from other projects that explicitly declare them as part of the project externals. This process provides environmental support to development best practices.
  • Compose isolated enterprise applications by using multiple, versioned bundles with dynamic lifecycle.
  • 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 existing EJB JAR files as EJB bundles.
  • Deploy web applications that use Version 3.0 of the Java Servlet Specification.
  • Deploy enterprise applications that contain EJB 3.x style enterprise beans.
  • Simultaneously load multiple versions of classes in the same application, by 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. Deploy these applications 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, impacting only those bundles that are affected by the update.
  • Deploy web services applications that use the JAX-WS programming model.
  • Deploy services that follow Representational State Transfer (REST) principles by using JAX-RS.