WebSphere Message Broker, Version 8.0.0.7
Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS
See information about the latest product version
See information about the latest product version
Identifying the .NET assembly at run time
The rules that govern how the .NET assembly is loaded from the broker file system if it is not packaged in the BAR file.
The .NET configuration for a broker is controlled by properties
on the .NET node or the ESQL Procedure signature. Optionally a DotNetAppDomain configurable
service can also be defined for further configuration options. A message
flow can invoke assemblies that run within the execution group of
a broker using the Microsoft Common
Language Runtime (CLR). Flow developers can control the .NET framework
assemblies that are loaded, and the .NET application domains which
are used. Assemblies are invoked either from a .NET node in a message
flow, or by calling an ESQL procedure.
Application domains
The .NET framework separates application assemblies to run
in a particular application domain that provides a scope for the resources
for an application. In WebSphere® Message
Broker,
the execution group operating system process (DataFlowEngine) hosts
the CLR. Within this process, .NET assemblies can be executed within
multiple application domains if required.
- The AppDomain name property of a .NET node specifies the application domain in which the assembly is to be loaded. If a DotNetAppDomain configurable service is defined with the same name as the AppDomain name of the node, the configurable service properties take precedence when the assembly is loaded. Such properties include the Application Base directory property.
- When an ESQL procedure invokes a .NET assembly, the signature of the procedure can specify the application domain in which the assembly must be loaded. If a DotNetAppDomain configurable service is defined with the name which is specified for the application domain in the signature of the ESQL procedure, the configurable service properties (for example the Application Base directory) take precedence when the assembly is loaded.
- The name of the application, if deployed within a WebSphere Message Broker application
- The name of the execution group, if deployed in a flow which is not defined within a WebSphere Message Broker application
Application base directory
To understand which copy of an assembly will be loaded, first
determine the Application Base directory.
- If the Application domain property refers to a configurable service,
the ApplicationBase property of the configurable
service is used. Use this approach in production environments. Note: The configurable service properties, including ApplicationBase, always take precedence even if you have deployed a .NET application domain containing the assemblies to the run time. In this situation, to ensure that the .NET assembly is loaded from the .appdomainzip and not from the Application Base directory, ensure that the configurable service ApplicationBase property is blank.
- If the Assembly name property of the .NET node (or equivalent part of the ESQL procedure signature) specifies an absolute location in the file system, this full directory path is used as the Application Base directory.
- If the Assembly name property of the .NET node (or equivalent part of the ESQL procedure signature) specifies just the name of the .dll file with no path, the broker uses a subdirectory of the runtime broker's work path for the Application Base directory. This directory might change; consider using one of the alternative approaches.
Assembly loading and the Global Assembly Cache
The broker expects to find the required .NET assembly in
the Application Base directory. However, you can place assemblies
in a machine-wide cache, which is known as the Global Assembly Cache
(GAC). To place an assembly into the GAC, it must be Strong-Named:
when it is compiled, the assembly is given the properties of a version,
a culture, and a public key token. When configuring the .NET node
or an invocation from ESQL, you can specify the version, culture,
and public key token of the Strong-Named assembly to
be used.
You have to restart the execution group if you want to reload or update a Strong-Named assembly.