Runtime isolation and resource sharing with applications and libraries

You can use applications to encapsulate resources for a solution or to provide runtime isolation. You can use libraries to group common resources or share routines and definitions between teams, projects, or integration nodes.

Applications provide runtime isolation whereby resources inside the application are not visible to other resources, such as message flows, libraries, or other applications that are running outside the application. Consider using applications if you need to ensure that updates to one group of deployed resources do not affect another group. For example, use an application when you want to control which flows pick up the latest version of an ESQL module.

The following example illustrates how you can use applications to contain separate solutions, and libraries to contain shared error-handing code.

The graphic shows the resources that are described in the preceding text.

The ClothesOrderApp application contains the following resources:

A message flow called ClothesOrderFlow
A reference to a static library called ClothesOrderLibrary, which contains XSD schema files that are specific to the order type
A reference to a shared library called CommonErrorHandling, which contains some common error-handling ESQL code

The HomewareOrderApp application contains the following resources:

A message flow called HomewareOrderFlow
A reference to a static library called HomewareOrderLibrary, which contains XSD schema files that are specific to the order type
A reference to a shared library called CommonErrorHandling, which contains some common error-handling ESQL code

The following diagram shows the resources in the Integration Nodes view after they are deployed. The shared library is deployed with or before the applications that reference it.

The graphic shows the deployed applications in the Integration Nodes view. The ClothesOrderApp application has as child resources the ClothesOrderFlow and ClothesOrderLibrary. The HomewareOrderApp application has as child resources the HomewareOrderFlow and HomewareOrderLibrary. The CommonErrorHandling shared library is deployed at the same level as the applications that reference it.

The shared library appears at the same level as the applications that reference it. The static libraries are shown nested under the applications that reference them. Resources in the applications and their referenced static libraries are not visible to other resources outside those applications.

Applications provide this isolation at run time. This isolation also applies if a resource that is contained in an application is also deployed separately to the same integration server.

Assume that a static library is deployed to an integration server with a message flow that references that library. The same static library is also contained in an application that is deployed to the same integration server. If that static library is updated in the IBM® Integration Toolkit and redeployed, the message flow that is deployed to the integration server can see the changes. However, the application cannot see the changes. For the application to pick up the updated static library, you would need to rebuild and redeploy the BAR file that contains the application.