Application management, including deployment, has remained mostly unchanged since WAS 5.

WAS 7, however, introduced a new concept — “Business Level Applications” (BLA). It would be more accurate to use the term “composite application” because this is what BLAs are — it’s a composition of Java EE applications (WARs or EARs) or other “assets”.

Unfortunately, the term “composite application” is already used in a “different context”: by IBM.

The word “asset” is another confusing and terribly overused term. In WAS7 it’s a “catch all” word for any kind of artifact, including jar, zip, and, with the introduction of OSGi support, an OSGi bundle (you need to have a “beta OSGI feature pack”: installed to be able to use OSGi).

BLAs are created by combining applications and assets together either using admin console or scripting. BLA configuration is saved under $profile_root/config/cells/$cell_name/blas. Assets are saved under $profile_root/config/cells/$cell_name/assets.

I can see two use cases for BLAs:

* BLAs can be used to start and stop multiple Java EE applications at once. This might be useful if operationally several applications have to be treated together or if there are run-time dependencies between applications. This is especially the case if scripting is used; AdminTask.startBLA and AdminTask.startBLA provide an easy way to restart several “regular” applications.

* BLAs can be used to manage shared libraries. There is no way to deploy “traditional” shared libraries (“Environment/Shared Libraries”) using Deployment Manager; you have to use scp or ftp to copy binaries to target servers. With BLA you can simply import “assets” (e.g., a jar file) using AdminTask.importAsset command. You can then reference the jar file using “SharedLibRelationship” option of AdminApp install/update commands. This will automatically create a classloader for this library (note–this might require server restart, at least for me it did). Being able to use regular administration APIs for managing shared libraries is certainly a welcome feature.

Unfortunately, BLAs also have limitations:

* I was not able to find a way to create an asset consisting of multiple jars. This severely limits the usefulness of utilizing BLAs for managing shared libraries since a library will almost always consist of multiple jars. It is possible to import jars individually, but this is tedious and difficult to manage.

* It is not possible to deploy multiple Java EE applications using BLAs. You still have to deploy applications individually.

* There is no support for version information in BLA assets. This is unfortunate. I wish IBM though about integrating BLA assets with Maven repositories and supporting true dependency management (e.g., version resolution, transitive dependencies, etc.). As of right now the only way to import multiple version of the same asset is to append a version number to the asset’s file name.

To summarize, the BLA idea has some promise but its current implementation is too limited to be truly useful. I’m sure IBM will be evolving BLA in future WAS releases.

You can find more information about BLA in “this article”: .

This post is part of the series on WebSphere Application Server administration. Please subscribe to our blog if you’d like to receive updates.

Note: We offer professional services in the area of WebSphere architecture, implementation and operations. If you’re looking for help with any of these tasks, please let us know.