Understanding Package for Microsoft .NET

The Package for Microsoft .NET provides .NET integration and management services within webMethods products in a tightly coupled implementation. The Package for Microsoft .NET is an umbrella of solutions that encompasses several functional areas. Package for Microsoft .NET enables you to do the following:

• Expose .NET assemblies as integration services

  The Package for Microsoft .NET exposes, as integration services, the services provided by .NET assemblies operating in a service provider role. Those integration services can be exposed to the outside world as Web services just like any other webMethods service. This feature simplifies integration of business logic developed on the Microsoft .NET platform into applications external to the Microsoft environment. Additionally, it simplifies the development of integration logic using a .NET language of choice.

• Allow .NET assemblies to invoke integration services

  Microsoft .NET assemblies operating in a client role can invoke services exposed by Integration Server. The Package for Microsoft .NET provides a native .NET API to Integration Server for this purpose. The API simplifies the integration of legacy or new business logic into Microsoft .NET applications.

• Host .NET executable assemblies

  The Package for Microsoft .NET provides hosting of .NET executable assemblies or applications that may be operating in an Integration Server client role or in a role unrelated to Integration Server.

• Manage .NET assembly lifetimes

  The Package for Microsoft .NET provides management of .NET assembly lifetimes for assemblies operating in a service provider role where multiple invocations of one or more methods on a given assembly instance is required.

• Manage the .NET environment

  The Package for Microsoft .NET allows you to manage the .NET environment and view metrics pertaining to its operation and the operation of assemblies executing in the .NET environment.

• Generate code in Microsoft Visual Studio to invoke services

  The IBM webMethods Add-In for Microsoft Visual Studio provides the ability to enumerate services on Integration Server and generate code within Visual Studio to invoke those services. Installation of the add-in is separate from the rest of the Package for Microsoft .NET. For information on installing the add-in, see Installing the IBM webMethods Add-In for Microsoft Visual Studio.

• Integrate with existing COM objects

  The Primary Interop Assemblies generated by TLBIMP are .NET assemblies and can therefore be exposed as integration services just like any other .NET assembly. Once exposed as integration services, they can also be exposed to the outside world as Web services if required.

Components designed to operate within the .NET environment are referred to as assemblies. Assemblies are of two types, DLLs (dynamically-linked library) and executables. The primary difference between DLLs and executables in the .NET environment, and the equivalent components in previous versions of Windows, is that the .NET components require the CLR to execute. Microsoft .NET assemblies, like components of other programming models, generally operate in one of two roles: a service provider or a service consumer.

Service providers provide services to external components using the public methods and properties they expose. Service providers are generally (though not necessarily) DLLs.

Service consumers consume the services provided by service provider components. Service consumers are generally (though not necessarily) executables.

An application domain is a boundary between objects in the same application scope, which is established by the CLR. Application domains provide the ability to isolate multiple applications running within a process. You can have multiple application domains loaded onto the CLR and destroy each of them independently without stopping and restarting Integration Server.

For information on managing application domains in Integration Server, see The Manage Application Domains Page.

The Package for Microsoft .NET uses wmSystem as the primary domain internally to facilitate the infrastructure. For running any DLL, Package for Microsoft .NET provides a default application domain with the domain name webmDomain. When you run a DLL in any application domain, it becomes locked, meaning that you cannot rename, modify, or delete it at the file system level. If the DLL is in the default webmDomain, you have to stop and restart the CLR from Integration Server Administrator to unlock it. By creating a separate application domain running a .NET service in it, you can unlock the DLL by destroying the application domain rather than stopping the CLR.

When you create a .NET service from a DLL using Designer, Designer creates a domain named IntrospectionDomain to introspect this DLL. This implies that the DLL is referenced by the IntrospectionDomain. Now, when you run this created .NET service by giving a custom application domain name, this DLL is also referenced by the custom application domain. To rename, modify, or delete this DLL, you must first destroy the custom application domain, and then also destroy the IntrospectionDomain. If you had not specified a custom application domain to invoke this DLL, DLL is invoked under the default application domain named webmDomain, and you must restart the CLR to modify this DLL.

The Integration Server provides an execution container for the .NET assemblies. After the CLR is loaded, the DotNetHost assumes control over it, providing access to the .NET environment from Integration Server.

The following procedures outline the basic steps to get started with Package for Microsoft .NET.

1. Install Package for Microsoft .NET. For more information about this step, see Installing the Package for Microsoft .NET.
2. Configure basic settings for Package for Microsoft .NET. After completing the installation, set the required configuration properties. For details, see Configuring Package for Microsoft .NET.
3. To use Designer with Package for Microsoft .NET, import the required .NET methods into IBM webMethods Designer. For more information about this step, see Using Designer with the Package for Microsoft .NET.
4. To use Microsoft Visual Studio to invoke integration services with Package for Microsoft .NET, see Using the IBM webMethods Add-In for Microsoft Visual Studio.