.NET application domains

A .NET application domain is a run time container for .NET assemblies and associated resources used by the .NET code in your message flows.

You can call .NET assemblies in your message flows from the .NETCompute node, .NETInput node or from an ESQL procedure. You can also include .NET assemblies as dependencies of a library. These assemblies run in a .NET application domain and can be packaged in a BAR file. Application domains are shown in the navigator view as peers of applications and libraries.

A named .NET application domain can be associated with IBM® Integration Bus applications. Assemblies, or associated resources, contained in the .NET application domain are deployed along with the referencing message flow or application. You can associate more than one application with the same .NET application domain. This means that data and other resources can be shared at run time between multiple applications.

Implicit application domains

Creating a .NET application domain in the IBM Integration Toolkit allows you to package your .NET assemblies and associated resources as desired to run on the CLR (Common Language Runtime). However, you do not have to explicitly create a .NET application domain in the IBM Integration Toolkit.

If you do not explicitly create a .NET application domain, and do not set a value for the AppDomain property on the .NET node, .NET assemblies can also be contained in an implicit .NET application domain. If you do not set the AppDomain node property, an implicit application domain is shown in the navigator when a message flow in your workspace calls a .NET assembly, or when a library in your workspace includes .NET assemblies. At run time the implicit application domain is automatically created by the integration node and takes the name of the referencing application, or the name of the integration server if the message flow is not contained in an application.

This means that the name of the application domain at run time is dependent on the name of the owning application or integration server, and changes if the application or integration server is renamed. Additionally, if an assembly is included in one library that is referenced by two different applications, the application domain under which that assembly runs has a different name dependent on the owning application.

Consider the following example: A library MyLib includes a .NET assembly and is referenced from application App1. When App1 is deployed, a copy of the library is made and the .NET assembly runs in a .NET application domain that takes the name of the application: App1. However, If MyLib is also referenced from application App2, a separate copy of the library is made, and the application domain in which the second copy of the assembly runs takes the name App2.

Deploying .NET code

When you deploy a message flow or application that uses .NET assemblies, there are two ways of working with the assemblies. These typically correspond with the application development, and test or production stages of the software development life cycle:
  • You can choose to not package the .NET application domain in the BAR file. In this case, the .NET assembly is loaded directly from your integration node file system. This means that you do not have to redeploy the message flow when the assembly is rebuilt on the file system, because the integration node reloads the application domain with the rebuilt assembly. However, the assembly must always be available on the integration node file system. Use this method for application development systems.
  • You can package the .NET application domain in the BAR file. This allows greater portability of message flows on different integration nodes and servers, but means that you must redeploy the BAR file if the .NET assembly is rebuilt. Use this method for test and production systems.