.NET Remoting vs. ASP.NET Web Services | Performance Tuning and Optimizing ASP.NET Applications

The .NET Framework provides the infrastructure for remote object invocation across application domains, otherwise known as .NET remoting . This technology is a successor to the Distributed Component Object Model (DCOM) technology, which has traditionally handled distributed application logic. .NET remoting is a powerful technology because it encapsulates many of the complex infrastructure (a.k.a. plumbing ) details required for remote object invocation. The .NET Framework classes for remoting simplify the implementation with a straightforward application programming interface (API). This capability naturally raises the question of whether .NET remoting is a viable alternative to ASP.NET Web services. To answer this question, you need to examine the similarities and differences between each technology.

ASP.NET Web Services

The highlights of this technology are as follows :

ASP.NET integrates with Internet Information Server (IIS) to provide an infrastructure for Web services that is based on industry standard technologies, including HTTP, XML, SOAP, and WSDL.
ASP.NET Web services are interoperable across any platform that provides support for WSDL, SOAP, and HTTP. The Web service consumer does not need to be running on a platform that supports the .NET Framework.
ASP.NET integrates with IIS to provide authentication for all incoming requests , including for Web services. IIS supports a number of authentication mechanisms, including Basic, Digest, .NET Passport, and digital certificates.
ASP.NET Web services use HTTP as the exclusive transport protocol and can therefore use SSL to secure transmissions over the wire.
ASP.NET Web services are stateless, so they will not maintain client state information between requests.
ASP.NET Web services are easy to create, configure, and consume .
ASP.NET Web services are robust because they execute in the ASP.NET worker process (which will restart automatically if it is terminated ).

.NET Remoting

The highlights of this technology are as follows:

.NET remoting supports several transport protocols, including TCP, HTTP, and custom protocols.
.NET remoting supports several serialization formats, including binary, SOAP, and custom formats.
.NET remoting requires a host process, which can be a .NET executable or IIS.
.NET remoting provides the fastest communication using binary formatting over a TCP channel. The TCP channel is more efficient than HTTP because it uses raw sockets to transmit data. This design provides high performance but is not interoperable across different platforms unless they are running the .NET Framework.
.NET remoting provides several modes for creating objects and specifying their lifetime. These modes are as follows:
- SingleCall: Objects are created for single requests from individual clients . The objects are stateless, so they will not persist state between requests and they will not share information between multiple client requests.
- Singleton: Objects are persisted for multiple client requests. This enables the objects to share state between multiple client requests. This mode is useful for sharing data between clients and for invoking objects that are expensive to create.
- Client-Activated: Objects are invoked using an intermediate proxy object on the client. This proxy enables the objects to maintain state on a per-client basis.
.NET remoting is more complicated to configure than ASP.NET Web services, depending on the host process.
.NET remoting may be less robust than ASP.NET Web services, depending on the host process.

Choosing .NET Remoting over ASP.NET Web Services

.NET remoting can only be compared to ASP.NET Web services in a restricted sense because .NET remoting provides a wider level of functionality than ASP.NET Web services. For example, .NET remoting allows you to invoke objects in Singleton mode so that they persist between multiple client requests. However, ASP.NET Web services are not designed to even address this scenario. In absolute terms, there is no faster invocation design than using .NET remoting with binary formatting over a TCP channel. However, this design requires that both the object and the client be installed on a platform that runs the .NET Framework. This lack of interoperability means that it is not even useful to compare Web services against .NET remoting using binary-TCP.

ASP.NET clients can in fact use .NET remoting (with SOAP over HTTP) almost as easily as they can use Web services, although the client-side code is more involved. ASP.NET clients can only use the SingleCall .NET remoting mode, which in a sense approximates the stateless nature of Web service calls. ASP.NET clients cannot use the Client-Activated mode; however, they can approximate this mode with separate ASP.NET session management in conjunction with the SingleCall mode. In terms of performance, you may be surprised to learn that standard Web service calls actually outperform .NET remoting calls using SOAP over HTTP. The reason is that ASP.NET is more efficient at serializing SOAP compared to .NET remoting. (Serialization in .NET remoting is handled by dedicated serialization formatters.) In addition, standard Web service calls have comparable performance to .NET remoting calls using binary over HTTP.

Note	For more information on performance issues, see the MSDN Architectural Topics article entitled "Performance Comparison: .NET Remoting vs. ASP.NET Web services" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch14.asp .

In theory, you can use .NET remoting to expose an object as an XML Web service if it is hosted in IIS and if it uses SOAP formatting over an HTTP channel. In reality, this is not equivalent to a standard ASP.NET Web service, mainly because .NET remoting does not generate the same kind of WSDL descriptions as Web services. Web service WSDL relates all interface information to XSD schemas. In contrast, .NET remoting WSDL encodes interface details purely as SOAP, without reference to XSD schema information. This will not be a problem if the object supports simple data types. But for complex data types, such as the DataSet object, this lack of schema information can prevent some clients from communicating with the object. For example, ASP.NET clients that interact with a Web service will expect the WSDL to contain XSD schema references for all data types. On the other hand, a .NET remoting client will not need these XSD schema references when it interacts with a Web service that is also built on .NET remoting infrastructure.

In a roundabout way, you thus come to a set of simple answers to the question of how to choose between ASP.NET Web services and .NET remoting. If you require interoperability with different platforms, then you should expose your components as ASP.NET Web services. If you do not require this level of interoperability, then you can invoke your components using .NET remoting. ASP.NET clients can invoke IIS-hosted components using .NET remoting as long as the WSDL provides enough descriptive information for all of the object's data types. Finally, if you have an ASP.NET client and you must use SOAP formatting, then you should use standard Web services rather than using .NET remoting with SOAP.

Note	For more information on .NET remoting, refer to Advanced .NET Remoting (VB .NET Edition) by Ingo Rammer (Apress, 2002). C# developers should refer to Advanced .NET Remoting (C# Edition) by Ingo Rammer (Apress, 2002).