Runtime isolation and resource sharing with applications and libraries

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 HomewareOrderApp application contains the following resources: A message flow called HomewareOrderFlow A reference to a library called HomewareOrderLibrary, which contains XSD schema that are specific to the order type A reference to a library called CommonErrorHandling, which contains some common error-handling ESQL code The ClothesOrderApp application contains the following resources: A message flow called ClothesOrderFlow A reference to a library called ClothesOrderLibrary, which contains XSD schema that are specific to the order type A reference to a 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.

Notice how both applications reference the same common library, CommonErrorHandling. In the Application Development view of the IBM® Integration Toolkit, changes that are made to the CommonErrorHandling library are visible to both applications. But when an application is deployed, that application contains a copy of the library. In the example, some changes are made to the ESQL code in the library, CommonErrorHandling. When the BAR file that contains the application HomewareOrderApp is rebuilt and deployed, the message flow HomeWareOrderFlow in that application sees the changes to the ESQL routine in library CommonErrorHandling.

Applications are isolated, therefore the flow ClothesOrderFlow in application ClothesOrderApp does not see the changes to the ESQL routine. This application has its own copy of the CommonErrorHandling library, which has not yet been updated in the Broker environment. When the BAR file for the ClothesOrderApp application is rebuilt, it picks up the updated version of the CommonErrorHandling library. When the rebuilt BAR file is deployed, the ClothesOrderFlow flow in application ClothesOrderApp sees the ESQL updates in the CommonErrorHandling library.

Only 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 library is deployed to an integration server with a message flow that references that library. The same library is also contained in an application that is deployed to the same integration server. If that 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 library, you would need to rebuild and redeploy the BAR file that contains the application.