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 support 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 method simplifies unit tests 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 containing only application-specific content and metadata that points to shared bundles. This method 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 WAR files as web application bundles (WABs). This method 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 containing 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 used by the server runtime environment. Do this application deployment 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. For more information, see Web Services.
- Deploy services that follow Representational State Transfer (REST) principles by using JAX-RS. For more information, see Overview of JAX-RS.
Subtopics
- An introduction to OSGi Applications
The OSGi Applications feature of WAS integrates Apache Aries technologies, including the Blueprint Container and OSGi application assembly model, into WebSphere Application Server. The integration of Apache Aries into WebSphere Application Server addresses many of the challenges of developing and maintaining extensible web applications.
- The Blueprint Container
The Blueprint Container specification defines a dependency injection framework for OSGi and is an OSGi Alliance standard. It provides a simple programming model to create dynamic applications in the OSGi environment.
- OSGi bundles and bundle archives
Applications can be deployed as versioned OSGi bundles, with each bundle typically having the granularity of an enterprise application module (for example, a webapplication). A bundle is a JAR or web application archive (WAR) file with standard OSGi metadata that describes aspects of the bundle, including the Java packages that the bundle exports, the Java packages that the bundle requires, and the bundle version.
- Manifest files
The metadata for an OSGi application is defined in manifest files. An OSGi bundle contains a bundle manifest; a composite bundle archive (CBA) contains a composite bundle manifest; an enterprise bundle archive (EBA) contains an application manifest; an EBA asset contains a deployment manifest. The deployment manifest is generated automatically when the EBA file is imported as an asset. We create the other manifest files when creating the bundles or application.
- Provisioning for OSGi applications
When you import an enterprise bundle archive (EBA) file as an asset, or update an asset to use new bundle versions, or add a composite bundle as an extension to a composition unit, provisioning ensures that all the required OSGi bundles are available. An OSGi application can use bundles from external repositories, bundles from nternal repository, and bundles that are included in an EBA file or a composite bundle archive (CBA) file.
- OSGi application isolation and sharing
At run time, OSGi applications are isolated from each other, but their dependencies are shared.
- Java 2 security and OSGi Applications
You can use Java 2 security in OSGi applications in a similar way to Java 2 security in Java EE applications. This topic describes the aspects that are specific to using Java 2 security in an OSGi application.
- JMS and OSGi Applications
An OSGi application can send and receive Java Message Service (JMS) messages. OSGi applications can use JMS resources that are configured within WebSphere Application Server, in a similar way to using JMS resources with Java EE applications. For OSGi applications, each reference to a JMS resource is declared in a Blueprint XML file.
- JPA and OSGi Applications
You can use Java Persistence API (JPA) in OSGi Applications in a similar way to JPA in Java EE applications. This topic describes the differences when you use JPA with persistence bundles in an OSGi application.
- SCA and OSGi Applications
You can use OSGi applications as component implementations in Service Component Architecture (SCA) composite applications. You can use SCA to link between OSGi applications, and between an OSGi application and another component type such as a Java EE application, a Java Message Service (JMS) resource, or a web service.
- Transactions and OSGi Applications
You can use transactions in OSGi Applications in a similar way to transactions in Java EE applications. This topic describes the differences when you use transactions with an OSGi application.
- Blueprint security and OSGi applications
You can configure bean security so that the methods of the bean can be accessed only by users assigned a specified role.
- Enterprise JavaBeans and OSGi Applications
An OSGi application can contain Enterprise JavaBeans (EJBs). OSGi applications can access and invoke an enterprise bean directly.
Related tasks
Develop 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?