Shared libraries

You might want to develop a set of common resources and make them available to multiple applications. If you want to deploy and manage just one copy of those common resources, use a shared library.

A shared library can be deployed directly to an integration server. Any application can reference the resources in that deployed shared library. If that shared library is updated, the changes are immediately picked up by all referencing applications. The libraries that were introduced in WebSphere® Message Broker Version 8.0 are static libraries. If you use a static library to contain resources, each application that references that static library is deployed with its own private copy of that library. If a static library is updated, each application that references it must be repackaged and redeployed with the updated static library.

A shared library must be deployed with or before an application that references it. If you deploy resources by dragging them onto an integration server, deploy the shared library first. If you deploy resources by adding them to a BAR file, ensure that you include any shared libraries that your application references. Similarly, you cannot remove a deployed shared library while deployed applications are referencing it.

The following conditions apply to the referencing of shared libraries:
  • Shared libraries can reference other shared libraries but cannot reference static libraries.
  • Static libraries and integration projects cannot reference shared libraries.
  • If an application references more than one shared library, the application has visibility of the resources in all of the shared libraries, but each shared library does not automatically have visibility of the resources in the other shared libraries.
  • If a shared library (A) references another shared library (B), shared library A has visibility of the resources in shared library B, but shared library B does not have visibility of the resources in shared library A.
  • If a shared library (A) references another shared library (B), shared library B cannot create a reference to shared library A.
The shared library hierarchy is preserved across development, deployment, and operational management processes. For example, you can see the shared library hierarchy in the IBM® Integration Toolkit and the BAR File editor. You can also view deployed libraries by using the IBM Integration API or the mqsilist command, for example:
mqsilist integrationNodeName -e integrationServerName -y sharedLibraryName
In this example, the command lists the resources that are deployed in a shared library, the integration server

The following examples demonstrate when you might use shared libraries.

Example 1: Sharing common logging code

You build a shared library that contains subflows and ESQL code that provides common logging functions. Multiple applications explicitly reference the shared library so that they can use the common logging functions. These applications are built and deployed.

You then update the shared library to ensure that additional information is recorded to the log. When you redeploy the shared library, all the deployed applications that explicitly reference this shared library pick up the changes automatically and start to log the additional information.
The graphic is described in the surrounding text.

Example 2: Sharing a set of XML or DFDL schema files

You build a shared library that contains a logical set of complex DFDL or XML schema files, such as those for the Health Level Seven (HL7) standard. Multiple applications explicitly reference this shared library so that they can use the HL7 schema files for Mapping nodes or XMLNSC validation. These applications are built and deployed.

When the shared library is deployed, memory usage can be affected because the complex schema files must be compiled into a model. However, you reduce this memory usage when you update and redeploy the applications that reference the shared library because the schema files do not need to be recompiled.

Example 3: Mapping between clashing XML or DFDL schema files

You might want to map between different versions of an XML or DFDL schema. Both versions might declare the same elements and types, which cannot coexist in one application.

You can build one shared library that contains version 1 of a schema file, and another shared library that contains version 2. You can then build a map that references the schema files in the shared libraries and maps between the two versions.

At deployment time, separate models are built for each of the shared libraries. Therefore, no clash results from the duplicated elements and types.

Resources that are not supported in a shared library

The following resources are not supported in shared libraries:
  • Message flows
  • CORBARequest node and IDL files
  • DecisionService node and decision services
  • SCA nodes
  • WebSphere Adapters nodes
  • XSLTransform node
  • MRM message sets
  • XML files
  • XSL files
The following sections describe how to use supported resources in shared libraries:

XML or DFDL schema files

When you validate against deployed XMLor DFDL schema files in shared libraries, you must specify the name of the shared library that contains the appropriate compiled model. For example, when you create a message flow, you can configure the input node to validate against the message model for a shared library that is called HL7.

For more information, see Shared libraries and XML or DFDL schema files.

WSDL files

When you validate against deployed WSDL files in shared libraries, you must specify the name of the shared library that contains the appropriate compiled model. You can use a WSDL file in a shared library to configure a SOAPInput, SOAPRequest, or SOAPAsyncRequest node. When you drag a WSDL file from a shared library onto one of these nodes, the WSDL file name property specifies the name of shared library; for example:
CurrentAccount.wsdl in Shared Library Shlib1
The Message model field is also set to the name of the top-level shared library that contains the WSDL file inside braces {}; for example: {Shlib1}. The WSDL might be contained in this specific shared library, but might be contained in one of the shared libraries that is referenced by this library. To drag a WSDL file from a shared library onto a SOAP node, the container of the message flow must reference the shared library that contains the WSDL file.

Multiple applications can access the same WSDL file in a single shared library. The shared library that contains the WSDL file must be deployed with or before the applications that refer to it. If you update the WSDL file and redeploy the shared library, those changes are immediately available to all referring applications.

A WSDL file of the same name can exist in multiple containers. For example, WSDL files with the same name can exist in an application and a shared library that is referenced by that application. You can also use multiple SOAPInput nodes in a message flow that reference different WSDL files with the same name in referenced shared libraries. A WSDL file in one shared library can use a schema file in another referenced shared library.

ESQL files

To avoid clashes between ESQL files in an application and its referenced shared libraries, the broker schema for the ESQL files is used. When you store ESQL files in a shared library, you must place the ESQL files inside a schema that is not the default empty schema.

Each shared library can have one or more ESQL files in one or more ESQL schemas. However, no two libraries in the same scope can have ESQL files in the same schema.
The graphic shows the representation of shared libraries 1 and 2 in the Application Development view of the IBM Integration Toolkit. Under each shared library is an ESQLs folder. The ESQLs folder for shared library 1 contains two ESQL files: Auditing.esql and Logging.esql. The ESQLs folder for shared library 2 contains one ESQL file: Auditing.esql.

ESQL code in applications or shared libraries can also call static Java™ methods in referenced shared libraries by using the shared library qualifier in the CLASSLOADER clause. For more information, see Java routine example 4 in CREATE PROCEDURE statement.

Java files

You can store Java files in shared libraries. JAR files are packaged inside shared libraries. Java classes that are deployed in a shared library are not available to the integration server wide class loader. When you deploy a shared library that contains Java files, a new classloader is created for that shared library.

Java classes in the integration server wide classloader are isolated from the Java classes in any shared library classloaders. Similarly, Java classes in shared library classloaders are isolated from Java classes in the integration server wide classloader.

Java classes in applications, static libraries, or independent projects cannot access Java classes in shared libraries.

For more information about storing Java files in shared libraries, see Shared libraries and Java files.

Subflows

When you store subflows in a shared library, you must place the subflows inside a schema that is not the default empty schema.

When an application or shared library references other shared libraries, all the subflows for a broker schema must be in a single container. Subflows for a broker schema must not be in both an application (or shared library) and a shared library that is referenced by that application (or shared library). Subflows for a broker schema must not be in two or more shared libraries that are referenced by a single application or shared library. All the subflows in a broker schema must be either in the main application or shared library, or in a single referenced shared library.

Example 1: All subflows in the same broker schema are stored in the main application.
The graphic is described in the surrounding text.
Example 2: All subflows in the same broker schema are stored in a referenced shared library.
The graphic is described in the surrounding text.