Using .NET Remoting for Connectivity

In Chapter 2, “Understanding Enterprise Platforms,” you learned that .NET Remoting is Microsoft’s communication and data transfer mechanism for distributed applications built on the .NET Framework. While primarily designed for communication between .NET Framework applications, .NET Remoting provides an extensible communication framework that you can build on and customize to enable connectivity with Java applications.

To use .NET Remoting for interoperability with Java applications, you must implement a runtime bridge, and you look at two of these, Ja.NET from Intrinsyc and JNBridgePro from JNBridge, Inc. later in this chapter. Before you learn about runtime bridges, you need to have a solid understanding of .NET Remoting.

Understanding .NET Remoting

At its fundamental level, .NET Remoting allows two processes within the same or different application domains to communicate with each other in a client-server relationship. In this basic scenario, the server component is a remotable object.

.NET Remoting implements interprocess communication by separating the remotable object from a specific client, server application domain, or particular communication mechanism. As a result, .NET Remoting is flexible and easily customizable.

This abstraction works through the use of two main concepts:

• Channels — Channels provide the transport between remote components. The default channels are TCP and HTTP.

• Formatters — Formatters convert (serialize) objects into a common format the other process (or, in the case of interoperability, platform) can understand. The default formatters are binary and SOAP.

  Note

  Later sections in this chapter discuss SOAP.

In Chapter 3, “Interoperability Fundamentals,” you learned about binary serialization and XML serialization. The binary formatter performs binary serialization on data objects; the SOAP formatter performs XML serialization on data objects. However, the SOAP formatter wraps the serialized XML document with extra SOAP-related XML tags.

By specifying a channel and a formatter, you can define how you establish communications between a remotable object and its client. The channels specify the communication protocol. The formatters then act as serializers, serializing and de serializing the data objects that pass between the remotable object and the client. The ability to customize these channels and formatters is what allows you to use .NET Remoting for connectivity between .NET Framework applications and Java applications.

.NET Remoting provides more than just communication between processes; you can also use it for links between two or more application components that are in different application domains. To do this, just change the configuration of .NET Remoting to exchange data between the separate application domains. This gives you flexibility to build an application that runs on just one computer but that you can then extend to run in a distributed environment with minimal adjustment to the code.

.NET Remoting also supports two ways for passing data between application components. These are:

• Pass by value (PBV)

• Pass by reference (PBR)

Pass by value involves returning of the data from a remote system call to the client. Pass by reference returns a pointer or reference to the data and the remote server maintains the data’s state.

Each method has advantages and disadvantages. The method you choose depends on the type of application you are developing, the data that you want to pass, and the network environment the application must function in.

Passing by reference can offer performance benefits when exchanging large data objects or with distributed systems where network latency slows down pass by value communication. However, if you pass a data object by reference, this makes a remote call to the referenced data object on the server each time the client accesses another field on the object.

For example, if you pass a CustomerData object, named custData, to a client by reference, each time the client accesses a field, such as custData.Name or custData.Address, this makes a remote call to the server. This can result a tightly coupled and chatty application.

Note

In service oriented applications, loose coupling between application components is more desirable, and you should use pass by value.

Implementing .NET Remoting

A typical .NET Remoting implementation, in which two components communicate directly, consists of the following items:

• A remotable application object or server component.

• A host application that listens for client requests to the remotable application component.

• A client application component that makes requests to the remotable application component.

Figure 4.1 shows an example of a .NET Remoting framework connection between a client and server.

Figure 4.1: A typical .NET Remoting implementation

Implementing .NET Remoting involves the following phases:

• Determining the host application or environment.

• Creating the server component.

• Creating the client.

• Editing the configuration files.

The following sections provide an overview of the steps necessary to implement .NET Remoting. For more information about .NET Remoting, see the References section at the end of this chapter. For coding examples in the XBikes sample application, see Chapters 7 to 9.

Determining the Host Application or Environment

.NET Remoting server components require hosting in an application domain that can listen for incoming requests for that object. You have four choices for hosting a remoting server component:

• ASP.NET on IIS

• Component Services (COM+)

• A Windows system service

• A Windows application (console or Windows forms based)

You can host .NET Remoting objects as ASP.NET components running on IIS. This brings many advantages, including built-in support for security and easy scalability. With this configuration, you can use either the binary or SOAP formatter but you can only use the HTTP channel, which is slower than TCP.

You can host a remoting object in Component Services as a COM+ Serviced Component on either Windows XP Professional SP1 or Windows Server 2003. This configuration provides the enterprise features of Component Services such as integrated security, transactions, pooling, and activation.

You can host remoting objects in any managed Windows service. Hosting a remoting object in a Windows service provides the flexibility to use any channel or formatter configuration you choose, including the highest performing combination of binary over TCP. However, .NET Remoting does not have a built-in security model. Hence if you host a remotable object in a Windows service, you need to build your own authentication and authorization mechanisms.

Finally, you can host a remoting server component in a Windows application. However, applications run in the context of the logged on user, and therefore require user logon to execute. They also run in the security context of that user, which might not be appropriate for your environment. It is preferable to host the remote server component in a Windows service.

Note

When hosting a component in a Windows Forms application, a Windows Service or some other application type, it is up to the programmer to specify the port. For non-ASP.NET hosts, remoting can listen on any unused port.

In general, you should use IIS to host your remoting objects because of the security and performance advantages it provides. For more information about hosting a remotable object in IIS, see the References section at the end of this chapter. For examples of using Ja.NET in conjunction with .NET Remoting in the XBikes sample application, see Chapters 7 and 8.

Creating the Server Component

The server component is the service provider, providing methods that client applications call by reference or data that clients send and receive by value. Server component classes need to inherit from the MarshalByRefObject class to communicate over .NET Remoting. Any data that the server component passes by value must be serializable.

Creating the Client Component

To enable .NET Remoting on the client, you do not need to implement any additional interfaces. However, the client must have a reference to the server component or interface. The client uses this reference to interrogate the server component for any methods or data types that the server component exposes. The client also needs to load the remoting configuration, either from its own code or from a configuration file.

Editing the Configuration Files

The following .NET Remoting items are configurable:

• References to remote systems

• Channels

• Formatters

You can configure each of these items through settings that you can either store in the application code or access them at run time from a configuration file. It is recommended that you store your configuration settings in a configuration file so that you can change them without having to recompile the application. This method is much more flexible in production systems, allowing you to implement changes without recompiling and redeploying the application.

Both the server component and the client component in a .NET Remoting scenario must have access to configuration information. Assuming you have stored the configuration settings a file, the contents and locations of these files differ for the server and client.

.NET Remoting configuration files are XML formatted text files. You can edit these in Notepad or the text editor of your choice.

Server Component Configuration

On the server side, you must register all remote objects with the .NET Remoting environment before clients can access them. During this registration process, you must provide the .NET Remoting framework with all the information required to activate and manage the lifetime of the object. The most important pieces of information required for registration are:

• Object type

• Object location (URL)

• Activation requirements for managing the object lifetime

• Channels for connecting to the object

The location of the remoting configuration file for the server depends on the host application you use. For example:

• For IIS-hosted applications, you store the remoting configuration in the Web.config file located in the application virtual root.

• For Component Services hosted applications, the remoting configuration would be in a file that you create named Dllhost.exe.config file in the \System32 directory. This is because the server component runs as part of the COM+ process, Dllhost.exe.

• For a Windows service, the remoting configuration information is in the application configuration file of the Windows service. For example, if the Windows service is named Myservice.exe, the remoting configuration is in the file Myservice.exe.config.

Client Component Configuration

The client side must also have the same configuration settings loaded as the server. You store client configuration settings in a file that you create named, for example, Remoting.config. The client application loads this file by calling RemotingConfiguration.Configure with the configuration file name as a parameter. The location of the Remoting.config file depends on the type of application the client component belongs to. For example:

• For ASP.NET-based clients, the Remoting.config file lives in the application’s virtual root. These configuration settings must load in the Application_Start method of the Global.asax file.

• For COM+ Serviced Components clients, the Remoting.config file lives in the \system32 directory.

• With any other client, the Remoting.config file should be in the same directory as the client executable file.

Now that you understand the basics of .NET Remoting, the next section looks at how you can use this technology to connect to Java applications.