Visual Studio Samples: Fitch and Mather 7.0
.NET Remoting

Fitch and Mather 7.0 uses .NET Remoting for its distributed deployment scenarios. Microsoft .NET Remoting technology provides a framework for distributing objects across process boundaries and machine boundaries. The .NET Remoting technology offers a powerful yet simple programming model and runtime support that make these interactions transparent.

You should be familiar with the following .NET Remoting concepts before proceeding:

  • Channels

    Typical .NET applications and application domains communicate with each other using messages. For more information, see What is an application domain? in Microsoft .NET Framework FAQ (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/faq111700.asp). The .NET Channel Services provide the underlying transport mechanism for this communication.

    The .NET Framework supplies the HTTP and TCP channels but third parties can write and plug in their own channels. The HTTP channel uses SOAP by default to communicate, whereas the TCP channel uses Binary payload by default.

  • Formatters

    The .NET serialization formatters encode and decode the messages between .NET applications and application domains. There are two native formatters in the .NET runtime, namely Binary (System.Runtime.Serialization.Formatters.Binary) and SOAP (System.Runtime.Serialization.Formatters.Soap).

  • Remoting context

    A context is a boundary that contains objects that share common runtime properties. Any call from an object in one context to an object in another context passes through a context proxy and be affected by the policy that the combined context properties enforce. The context of a new object is generally based on metadata attributes on the class.

    Classes that can be bound to a context are called context-bound classes. Context-bound classes can be attributed with specialized custom attributes known as context attributes. Since context attributes are completely extensible, you can create and attach these attributes to your class. Objects that are bound to a context derive from System.ContextBoundObject.

  • .NET Remoting Metadata

    The .NET Remoting technology uses metadata to dynamically create proxy objects. The proxy objects that the client creates have the same members as the original class. The implementation of the proxy object just forwards all requests through the .NET Remoting runtime to the original object. The serialization formatter uses metadata to convert method calls to payload stream and back.

  • Configuration Files

    Configuration files (.Config) specify the remoting-specific information for a given object. Usually each application domain has its own configuration file. Configuration files help to achieve location transparency. Details specified in the configuration files can also be set programmatically. The main advantage of using configuration files is that configuration information is separate from the code. Consequently, future changes to the configuration file do not require a recompilation of the source file. Configuration files are used both by .NET Remoting client and server objects.

To explore samples demonstrating remoting, see Remoting.

For security information about .NET Remoting, see Security.

The following table displays some of the combinations of formatters and channels:

Formatter Channel Used in Fitch and Mather 7.0
SOAP HTTP No
Binary HTTP Yes
Binary TCP No
Network Data Representation (NDR) DCOM Yes

Key Points

Fitch and Mather 7.0 uses the Binary/HTTP combination due to its superior performance over SOAP/HTTP.

Note   The TCP channel uses the binary formatter by default. This formatter serializes data in binary form and uses raw sockets to transmit data across the network. This method is ideal if your object is deployed in a closed environment within the confines of a firewall. This approach is more optimized than HTTP or DCOM since it uses sockets to communicate binary data between objects. Using the TCP channel to expose your object gives you the advantage of low overhead in closed environments. However, using TCP channel over the Internet would require opening certain ports in the firewall and could lead to security breaches. Fitch and Mather 7.0 does not use the TCP channel because it would require development of an extra listener to process the request that enters the TCP channel. The HTTP channel does not require a custom-written listener because IIS provides the listening functionality. Advantages of using IIS as the HTTP listener include: ease of configuration, scalability, and process recycling.

HTTP allows you to host your objects in IIS (using a robust HTTP server) and use ASP.NET features such as security and process recycling.

Before continuing, familiarize yourself with the use of the following terminology in Fitch and Mather 7.0:

  • Application Server

    The machine in which the BLL and/or the GAM run. The Web Server makes Remoting requests of the Application Server.

  • Web and Application Server

    The machine that runs all Fitch and Mather 7.0 components in a non-distributed scenario. For more information, see Non Distributed Deployment Scenario.

The FMS.exe utility, which configures Fitch and Mather 7.0 in a distributed fashion, performs the following logical steps:

  • Creates a directory in the Application Server to install the assemblies and configuration files. (For example: c:\fmstocks7_App).
  • Creates an IIS virtual directory that points to c:\fmstocks7_app\web.
  • Copies all the required assemblies to the Application Server.
  • Generates client (remotinclient.cfg on Web Server) and server (Web.config on Application Server) configuration files.
  • Registers the GAM COM+ application with the component services catalog of the Application Server.
    Note   For an explanation of how the process is automated, see Deployment and Configuration. For more information on .NET Remoting, see .NET Remoting.

When the application starts and the Application_OnStart function of Global.asax is executed, the Application_OnStart function calls the System.Runtime.Remoting.RemotingConfiguration.Configure method to configure remoting based on the remoting client configuration file:

string path = Path.Combine(Context.Server.MapPath( Context.Request.ApplicationPath ),"remotingclient.cfg");
      if(File.Exists(path))
         RemotingConfiguration.Configure(path);

Among the deployment scenarios, which Fitch and Mather 7.0 supports, two distributed deployment scenarios use .NET Remoting technology. For more information, see Multiple Machine Deployment Scenarios. These scenarios are:

  • .NET to Legacy Interop

    The Business Logic Layer (BLL), Data Access Layer (DAL), and General Accounting Module (GAM) components run on a remote machine. In this scenario, the User Services Layer (USL), which runs on the Web server (IIS machine), makes remote calls to the BLL on the remote machine (Application Server). For more information, see Scenario: Legacy Interop.

  • Legacy Integration

    The GAM runs on a remote machine. In this scenario, the DAL, which runs on the Web server (Web Server machine), makes remote calls to the GAM on the remote machine (Application Server). For more information, see Scenario: .NET to Legacy Integration.

Both these scenarios use .NET Remoting configuration files. The following are sample configuration files that would be generated for the Legacy Integration scenario:

Web.config file on the Application Server

<configuration>
   <system.runtime.remoting>
      <application>
         <service>
            <wellknown mode="Singleton" type="FMStocks7.GAM.GAMClass, FMStocks7.GAM" objectUri="GAM.rem"/>
         </service>
      </application>
   </system.runtime.remoting>
</configuration>

remotingclient.cfg file on the Web Server

<configuration>
   <system.runtime.remoting>
      <application>
         <channels>
            <channel type="System.Runtime.Remoting.Channels.Http.HttpChannel, System.Runtime.Remoting" clientConnectionLimit="200">
               <clientProviders>
                  <formatter type="System.Runtime.Remoting.Channels.BinaryClientFormatterSinkProvider, System.Runtime.Remoting"/>
               </clientProviders>
            </channel>
         </channels>
         <client url="HTTP://MachineX:80/FMStocks7_GAM">
            <wellknown type="FMStocks7.GAM.GAMClass, FMStocks7.GAM" url="HTTP://MachineX:80/FMStocks7_GAM/GAM.rem"/>
         </client>
      </application>
   </system.runtime.remoting>
</configuration>

Both of these distributed scenarios share the following characteristics:

  • An ASP.NET application (through IIS) hosts the remote components to leverage features such as process recycling and application configuration.
  • The remote calls are done through the HTTP channel using a binary formatter. Using the HTTP channel enables the use of IIS to host the components, while the binary formatter has performance advantages over the SOAP formatter.
  • Both the GAM and BLL objects are stateless, which allows them to be hosted in an Application Center cluster.
  • Although the GAM and BLL objects are stateless, Fitch and Mather 7.0 uses instance methods (as opposed to static methods) to be able to remote the method calls. Static methods are always executed locally, that is, in the same AppDomain class as the caller. For more information, see Programming with Application Domains.

Key Points

To receive remoting requests, the remote server must listen for incoming requests. Remote server objects can be hosted in IIS or in a managed executable that is either manually started or hosted as a Windows component service. IIS will listen on HTTP or HTTPS ports and offers the advantages of high availability, secure communications, and ASP.NET services. A managed exe using Binary/TCP would offer higher performance due to the more compact binary formatting.

See Also

Architectural Overview | Distributed Deployment Scenarios | .NET Remoting Overview | Application Domains Overview | ASP.NET Configuration | Hosting Remote Objects in Internet Information Services (IIS)

Page view tracker