IBM BPM, V8.0.1, All platforms > Installing, deploying, and undeploying applications in the runtime environment > Deploying service modules

Libraries and JAR files overview

Modules often use artifacts that are located in libraries, which are special projects in Integration Designer used for storing shared resources. At deployment time, Integration Designer libraries are transformed into utility JAR files and packaged in the applications to be run.

While developing a module, you might identify certain resources or components that could be used by other modules. These artifacts can be shared by using a library.


What is a library?

A library is a special project in Integration Designer that is used for the development, version management, and organization of shared resources, such as those resources that are typically shared between modules. Only a subset of artifact types can be created and stored in a library, including:

At deployment time, these Integration Designer libraries are transformed into utility JAR files in the applications to be run.

When a module needs an artifact, the server locates the artifact from the EAR class path and loads the artifact, if it is not already loaded, into memory. Figure 1.shows how an application contains components and related libraries.

Figure 1. Relationships among module, component, and library


What are JAR, RAR, and WAR files?

There are a number of files that can contain components of a module. These files are fully described in the Java™ Platform, Enterprise Edition specification. Details about JAR files can be found in the JAR specification.

In IBM BPM, a JAR file also contains an application, which is the assembled version of the module with all the supporting references and interfaces to any other service components used by the module. To completely install the application, you need this JAR file, any other dependent JAR, web services archive (WAR), resource archive (RAR), staging libraries (Enterprise JavaBeans) JAR files, and any other archives. You then create an installable EAR file using the serviceDeploy command (see Installing a module on a production server).


Naming conventions for staging modules

Within the library, there are requirements for the names of the staging modules. These names are unique for a specific module. Name any other modules required to deploy the application so that conflicts with the staging module names do not occur. For a module named myService, the staging module names are:

The myServiceEJB and myServiceEJBClient staging modules no longer get created by serviceDeploy. However, those file names should not be used, because they could still be deleted by the serviceDeploy command.


Considerations when using libraries

Using libraries provides consistency of business objects and consistency of processing amongst modules because each calling module has its own copy of a specific component. To prevent inconsistencies and failures it is important to make sure that changes to components and business objects used by calling modules are coordinated with all of the calling modules. Update the calling modules by:

  1. Copying the module and the latest copy of the libraries to the production server
  2. Rebuilding the installable EAR file using the serviceDeploy command
  3. Stopping the running application containing the calling module and reinstalling it
  4. Restarting the application containing the calling module

Deploying service modules