Why Do We Need .NET Remoting? | The .NET and COM Interoperability Handbook (Integrated .Net)


Team-Fly

	.NET and COM Interoperability Handbook, The By Alan Gordon
	Table of Contents

	Chapter Eleven. .NET Remoting

Why Do We Need .NET Remoting?

There are two technologies in the .NET Framework for facilitating distributed application development: (1) XML Web services and (2) .NET remoting. The first question that people might ask when they find out that these two technologies exist is, why two technologies? After Microsoft adds security, transactions, and reliable messaging to its Web services infrastructure (as it is feverishly doing), one could argue there is no need for another distributed application development technology. So why are there two technologies? The answer in two words is flexibility and type fidelity.

Flexibility

At a fundamental level, .NET remoting is about making method calls across app domain (and process and machine) boundaries. In that respect, it is no different than XML Web services. However, .NET remoting gives you more choices as to how method calls are serialized into a network-transportable format. It also provides choices about which protocol is used to transport method calls from client app domain to server app domain. With .NET remoting, you can serialize your method calls using SOAP or a proprietary binary format, or you can define your own format. You can use HTTP or TCP as your network protocol, or you can create your own channel and choose other protocols. You can also define whether your remotable types (the classes that you expose using .NET remoting) are created by the server, as needed, to service requests or are client created with the client having a dedicated connection to a particular object with the object's lifetime controlled by a lease. With .NET remoting, you can either define your own host executable for your server, or you can use IIS as the host process for your server.

All of these choices give you an enormous amount of flexibility. If you use SOAP as your serialization format, use HTTP as your network protocol, specify server-created single-call objects, and host your process in IIS, you have effectively created an XML Web service that can be easily called from clients running on other platforms in a heterogeneous environment. If you're running in a pure .NET environment, you can choose a binary serialization format, use TCP as your network protocol, use client-created objects, and build your own server executable (perhaps with thread pooling provided by the System.Threading.ThreadPool class) to create a high-performance server that more closely approximates both the performance and functionality of DCOM. The true beauty of .NET remoting is that, if you build your client and your server properly (and I show you how to do that in this chapter), you can switch from one configuration to another without changing your source code. You only need to edit the entries in an XML configuration file.

Type Fidelity

One of the major design goals of XML Web services was to facilitate application integration in a heterogeneous environment. Unfortunately, this places some limitations on the types that you can expose through an XML Web service. The type system for XML Web services is the set of types that can be exposed through SOAP, which isn't nearly as rich as the CTS in the .NET Framework. For an example of this limitation, refer back to Chapter 10 when I used a Payment class to return the Amortization table information from the Financial Web service. Remember that the client could see all of the data (fields) in the Payment class, but custom methods that I added to the Payment class or interfaces that I implemented in the class were not visible to the client. With .NET remoting, you can get full CTS type fidelity across a network boundary as long as the client is also a .NET Framework-based application. In other words, a .NET (managed) client has access to all of the public members of the remote type including parameterized constructors, methods, interfaces, properties, public fields, events, and delegates. To get full CTS fidelity, you will have to use the binary serialization format and to reference the assembly that contains the remote types from the client, but it is still possible.

Therefore, to answer the original question posed at the beginning of this section, why should you use .NET remoting? The answer is that XML Web services implemented with ASP.NET give you maximum interoperability and ease of development. .NET remoting gives you maximum flexibility and performance as well as full CTS type fidelity, but it is intended for a homogenous .NET environment. The choice of which one to use depends on your needs and operating environment.

Note

The choice between XML Web services and .NET remoting is not unlike the choice you have on the Java platform between CORBA (which is cross-platform) and Remote Method Invocation (RMI), which was designed for a Java-only environment.


Team-Fly

Top