Best practices for developing and working with OSGI applications

Brief introduction

OSGi modularity provides a standard mechanism for meeting common challenges with Java applications. In 2007, the OSGi Alliance Enterprise Expert Group (EEG) was established to introduce the OSGI infrastructure to business application developers in the form of a business Java programming model. The OSGi application and IBM WebSphere Application Server Enterprise-class quality of service together provide the most complete and robust business servers for modular WEB applications. You can use the WebSphere application Server Feature Pack for OSGi applications and JPA 2 deploy and manage WEB applications as a set of versions of OSGi bundle. You can also configure one or more bundle repositories as part of the provisioning technology facility to host common bundle used by multiple applications and to simplify application deployments that use these common bundle. The WebSphere application Server V7 Feature Pack for SCA V1.0.1.5 upgrade adds support for OSGi applications composed of heterogeneous assets to support service-oriented architecture (SOA) concepts.

For any new technology, there are some things to do and not to do, which is also known as best practice for architects, developers, and deployment personnel. OSGi technology has been in use for more than 10 of years, and there have been many best practices at that time. This article describes the authoring of OSGi applications and Integration Service Component Architecture (SCA)-related master for OSGi applications feature of WebSphere application Server To best practice. Some of these are common OSGi best practices, some of which are dedicated to support in the WebSphere application Server, and for clarity, the best practices that belong to the latter are indicated.

Best practices

This article describes the following best practices:

Using Blueprint

Using Blueprint to enable service-based provisioning

Using Blueprint to enable SCA integration

The version is controllable

Detach the API from the implementation

Sharing services rather than implementing

Good bundle are like good structured classes: loose coupling, high aggregation

Avoid packet and require-bundle separation

List what is contained in the Application-content header

Using WAB rather than WAR

Use only use-bundle if necessary

Use persistent bundle to share your persistence unit

Take full advantage of the provided component model

Let the container take up the responsibility

Each best practice is described in detail in the following sections.

1. Use of Blueprint

Generally speaking, using Blueprint is a best practice. Some of the Blueprint provided by Blueprint support a simple POJO development and support the fact that test models, simple assembly assembly, and based on development standards. Using Blueprint in WebSphere application Server OSGi Applications is an additional recommendation because it enhances container integration, Service Component architecture (SCA) integration, and service based provisioning Support.

Reasons are as follows

Blueprint is a simple assembly model based on the Spring Framework, which is standardized by R4 in the Enterprise OSGi V4.2 SpringSource specification by SGi Alliance. As a standardized Spring, it supports the same dependency injection pattern, enabling simple Java components to be developed without the framework APIs and easy to unit test.

Developing an enterprise-class OSGi application for WebSphere Application Server lists the reasons why the WebSphere application Server supports the Blueprint component model, which is motivated by customer requirements. OSGi applications supported in WebSphere application Serve, most of which rely on the use of Blueprint to enable a single feature, such as service based configuration and SCA integration. Although using Blueprint is usually a good idea, there are even more reasons to do this when developing a WebSphere application Server OSGi application.