IBM WebSphere Application Server

How can we satisfy a programmer’s need to develop software using new technologies as well as the need for saving application server versions within the systems sector? IBM has the solution: WebSphere Application Server Feature Packs. Feature packs, more commonly known as modernization packs, extend the lifespan of versions of the application servers and result in the necessary technological upgrades. For example, many companies still use the WAS 6.1, which is a four year-old version. In the world of software, this is a very long period of time which would not be possible otherwise without modernization through the feature packs. Meanwhile, the correct 7.0 version has acquired several interesting modernization packs. Much has been done over the last two years since the release of the 7.0 version. Firstly, a few standards have been completed, each one in its own way, which have made the development easier and which present the best programming practices. The standards that will be discussed include: OSGi Service Platform Enterprise Specification Release 4 version 4.2, JPA 2.0 i XML standards XSLT 2.0, XPath 2.0 i XQuery 1.0. Support for all of the aforementioned standards can be found in the two modernization packs which will be presented in this document.

Feature Pack for OSGi Applications and Java Persistence API (JPA) 2.0

OSGI
Most of today’s software solutions are used by a number of libraries for fulfilling business needs. This method of implementation is considered good practice. However, new obstacles are presented. Third party libraries are grouped together with a well-developed executable code in the archive which is sent for deployment. Since, in most cases, we have more copies of the same library, this results in suboptimal use of application server resources. Duplicates use up OCCUPY expensive working memory and disc space. In an attempt to resolve this problem, we can deploy two applications as three separate modules: two modules with executable codes and one with shared libraries. In other words, this is the conceptualized idea of OSGI specifications.

Differences in terminology are present; thus, in the OSGI environment, we refer to these modules as bundles. Bundles describe interdependence through the packs that they import and which are exported to the OSGI environment. In this way, our two applications are installed as three bundles, while detection and linkage of mutual dependence is left to the OSGI environment. This mechanism (and others involved) has to a great extent solved the problems commonly known as JAR hell. In fact, aside from its name, the OSGI bundle also specifies the library versions that are required for the functionality of the module. This enables the deployment of more versions of the same library without the problem perpetrated by interdependence.

Service registry

Aside from the library, the OSGI environment enables the functional linkage of servers. Registration, detection and consumption of Plain Old Java Objects (POJO) services from the second bundle is possible through the service registry. Given that OSGI enables the installation, linkage, and activation of the bundles without reactivating the container alone, it is evident that this mechanism allows for component development of software solutions. It is up to the programmer to note the code and pack it in one software solution bundle (data, integration, or presentation) while the OSGI executable environment is responsible for linking the bundles with the necessary libraries and services.

EAR Conversion in the OSGI bundle

You will be happy to know that the standard (JEE) web-application can be converted into web application bundles (WEB) in quite a simple way. Changing the file extension from .ear to .eba and importing it as an Asset into the WebSphere® Application Server is sufficient. This is enough to start with, but for full utilization of the OSGI container’s capabilities it is necessary to design a software solution through interconnected modules.

JPA 2.0

Mapping projects in a relational model (database) is one of the first tasks facing a Java enterprise application. Traditionally, this task is done with the help of JDBC specifications which abstract differences in relational database implementation. In cases where there is a greater demand for productivity and flexibility, incurring less control over SQL inquiries, JDBC is not sufficient. A more modern and increasingly popular way of working with databases is by using programming tools for project-relational mapping. The Java standard programming environment for mapping is defined by the specification JSR 220, while the standard known as Java Persistence API (JPA 1.0) WAS 7 comes with implementation specifications. Because the first specification version does not cover all instances of use, a supplement (NADOGRADNJA) to version 2.0 was recently created. The modernization pack WAS-a 7 and OSGI support create JPA 2.0 support, which is not unintentional. In fact, as a part of the OSGI enterprise specifications, a special kind of Persistence and Client bundle i defined. This allows for the implementation of the Persistence bundle using JPA 2 technology and its deployment in the OSGI container so that other (Client) bundles are able to use them in situations requiring work with the database.

New Functionality of JPA 2.0
For projects that already use JPA or for those that are in the design phase, switching to the 2.0 version should be considered for the following reasons:

1. Improved support for complicated situations like embeddable objects and arranged primary keys.
2. API Criteria query—Enables Java and all other benefits of the development environment to be used instead of entering free text searches.

Feature Pack for XML

Can you recall any new applications, whose development you contributed to, and which do not use XML in any segment? I cannot. Today, in the world of SOA, XML is actually a standard for the exchange of data via wire format. You will, as a result, agree that it is vital to be able to use the latest W3C XML specification standards. The Feature Pack for XML in WAS 7 provides support for the following standards:

1. Extensible Stylesheet Language Transformations (XSLT) 2.0
2. XML Path Language (XPath) 2.0
3. XML Query Language (XQuery) 1.0

These three standards are inter-connected. XPath is used in XSLT 2.0 transformations, with a XQuery 1.0 subset specification. Given this, support for these three specifications is provided in the pack. Support for all built-in types of XML Schemes and a larger number of new operators and functions is also provided with the XSLT 2.0 support. Regardless of whether or not we want to transform a document using user-defined functions or into multiple output documents, this is now possible. XPath is a standard method used for extracting specified elements from XML documents. This is a rather common task today. Version 2.0 gives access to a larger number of operators and functions. In this way, operations that were made difficult using XPath 1.0 or that were impossible using Version 2.0 are now made simple. For more complicated scenarios, which have been difficult to resolve without Java programming, the feature pack provides implementation of XQuery 1.0 specifications. XQuery is a syntax language which includes XPath and similar SQL’s. It will be used frequently as a language for extracting data from the XML repository, just like SQL’s work with a relational database. Actually, DB2 v) supports XML-type data together with XQuery as a language for manipulating information. As a result, support for XQuery and WAS is welcome since it makes working with information in XML format easier.

Tools must also be noted. The development of solutions to be used by the Feature Pack for XML is furthermore supported in RAD 7.5.5.1. It is also possible to debug XSLT 2.0 transformation, which RAD places before similar tools. Support for OSGI and JPA 2.0 is accessible through beta Rational Application Developer 8.0.

The aim of this short summary of the modernization packet for WAS 7.0 was to familiarize you with the technologies that are becoming available and which will hopefully speed up software development solutions. This is the time OSGI, JPA 2.0 and XQuery technologies. All you need to do to be able to use them today is download the feature pack archives from IBM’s website and install them on your already-installed WAS 7.