OSGi applications
OSGi application support in WAS traditional is deprecated because OSGi applications depend on a technology that is no longer included in Equinox 4.4.0 and later. There is no strategic alternative in WAS traditional. To continue to use OSGi applications, migrate the applications to Liberty.
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 WAS 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 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 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, 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 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 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 JAX-WS.
- Deploy services that follow Representational State Transfer (REST) principles using JAX-RS.
Subtopics
- An introduction to OSGi Applications
- The Blueprint Container
- OSGi bundles and bundle archives
- Manifest files
- Provisioning for OSGi applications
- Java 2 security and OSGi Applications
- JMS and OSGi Applications
- JPA and OSGi Applications
- Transactions and OSGi Applications
- Blueprint security and OSGi applications
- Enterprise JavaBeans and OSGi Applications
Developing an OSGi application Administer OSGi applications OSGi Service Platform Release 4 Version 4.2 Enterprise Specification Innovations within reach: Are we ready for enterprise OSGi?
File name: was304.html
prettyPrint();