Choosing Communication Options in .NET

With the introduction of the .NET Framework 3.0 and the Windows Communication Foundation (WCF), a number of different technologies have been brought together in a unified programming model. WCF serves as the next version of Enterprise Services, ASMX Web Services, WSE, MSMQ, and .Net Remoting. The text that follows applies to the .NET Framework 2.0. For more information about WCF and the .NET Framework 3.0, see: Windows Communication Foundation.

The .NET Framework provides several ways to communicate with objects in different application domains, each designed with a particular level of expertise and flexibility in mind. For example, the growth of the Internet has made XML Web services an attractive method of communication because XML Web services are built on the common infrastructure of the HTTP protocol and SOAP formatting, which uses XML. These are public standards and can be used immediately with current Web infrastructures without worrying about additional proxy or firewall issues.

Because many applications require functionality that Web Services created by using ASP.NET does not support, some applications cannot use ASP.NET Web Services. Use the following section to help you decide which type of distributed application support you want for your application.

ASP.NET, Enterprise Services, or .NET Remoting

ASP.NET, Enterprise Services, and .NET remoting are inter-process communication (IPC) implementations. ASP.NET provides an infrastructure, hosted by Internet Information Services (IIS), that handles basic types well, supports some advanced Web service protocols (when used with Web Service Extensions (WSE)), and is familiar to Web application developers. Enterprise Services is a managed implementation of COM+ and provides all the flexibility and richness of the COM+ architecture. .NET remoting is a generic and extensible IPC system that can be self-hosted or hosted in IIS to develop and deploy distributed object-oriented applications. .NET remoting's pluggable architecture allows for custom protocols and wire formats.

Your choice between the programming models should be driven by three main criteria: business requirements, integration requirements, and the programming model you are familiar with. In addition, the following criteria (listed in order of priority) can help you choose the appropriate type of distributed application technology:

1. Security requirements

   Of the three programming models, Enterprise Services has the richest set of security features and satisfies most scenarios. ASP.NET provides authentication through IIS and encryption through SSL and is useful for securing Internet scale applications. The security of .NET remoting has been increased with the latest release of the .NET Framework. In earlier versions of .NET remoting, if you needed to encrypt your calls or authenticate your client, you had to use an HTTP-based application hosted in IIS, whether it was an ASP.NET application or a remoting application. In the current version, the TcpChannel and the HttpChannel support SSPI encryption and Windows Integrated Authentication. The IpcChannel also supports Windows authentication and direct setting of the access control list (ACL) on the named pipe. Because it is not recommended to use remote objects across the Internet, there are now few scenarios that require HttpChannel. If you must communicate across the Internet, it is recommended that you use ASP.NET to create XML Web services.

   Note
   For security reasons, it is strongly recommended to expose remoting endpoints through secure channels. Never expose insecure remoting endpoints to the Internet.

2. Interoperation

   If you must interoperate between different operating systems, you should use XML Web services created by ASP.NET. ASP.NET files give you considerably more flexibility in defining the shape and style of SOAP communication than .NET remoting. This flexibility can make interoperating with different platforms and clients easier. .NET remoting is not intended for interoperation with platforms other than .NET.

   .NET Framework remoting is not intended to interoperate with Web services. For more information about choosing between Web services and remoting, see "How to choose between Web services, remoting, and Enterprise Services" in Performance Best Practices at a Glance, and "Prescriptive Guidance for Choosing Web Services, Enterprise Services, and .NET Remoting" in Improving .NET Application Performance and Scalability.

3. Speed

   If speed is truly a driving factor, Enterprise Services provides the best performance for distributed applications. There is very little difference in performance between .NET remoting and ASP.NET files after an application requires real-world processing. If you use .NET remoting, the TcpChannel with the BinaryFormatter has the best performance across machines. On the same machine, the IpcChannel with the BinaryFormatter should be used.

4. Scalability

   Hosting your application inside IIS gives you the scalability you need. Self-hosting .NET remoting would require you to build your own scaling infrastructure. If you are considering using IIS with .NET remoting to gain scalability, you should consider Web services created by using ASP.NET instead.

5. Use of common language runtime features

   Both Enterprise Services and .NET remoting take better advantage of .NET clients, so that you can use the .NET features in your application that are unavailable to an XML Web service created by using ASP.NET, including:

   • Interfaces.

   • CallContext.

   • Properties.

   • Indexers.

   • C++.

   • Type fidelity between the client and server applications.

   • If these features are critical, choose Enterprise Services, if possible, and then .NET remoting.

6. Object-oriented application design

   Both Enterprise Services and .NET remoting objects are objects and can be treated as such. As a result, you can use the following object-oriented features in your application that are unavailable to ASP.NET.

   • Object references to remoted objects.

   • Several object activation options.

   • Object-oriented state management.

   • Distributed object lifetime management.

   • If these features are critical, choose Enterprise Services, if possible, and then .NET remoting.

7. Custom transports or wire formats

   If you need to support custom transports (for example, User Datagram Protocol (UDP)) or custom wire formats (for example, CSV), .NET remoting is the only pluggable architecture that can meet these requirements.

8. Cross-application domain communications

   If you need to support communication between objects in different application domains within the same process, you must use .NET remoting.

The following sections include a brief summary of some of the differences between XML Web services created by using ASP.NET, the System.Net namespace, Enterprise Services, and .NET remoting.

XML Web Services

XML Web services created by using ASP.NET work well if you build Active Server Pages (ASP) applications by using the Web application model and the ASP.NET HTTP runtime, including strong support in Microsoft Visual Studio .NET. With the XML Web service infrastructure, you can easily create components for other applications to use or use components that others have created by using protocols, formats, and data types most appropriate to Web-based applications. Exact type fidelity between computers is not supported, and only some types of arguments can be passed. For more information, see XML Web Services Created Using ASP.NET and XML Web Service Clients.

System.Net Namespace

You can use the classes in the System.Net namespace to build an entire communication structure from the socket level. You can also use the System.Net classes to implement communication protocols and serialization formats that you can plug into the remoting architecture. For more information, see Network Programming.

Enterprise Services

Enterprise Services builds on the .NET remoting infrastructure to provide all the richness and flexibility of the COM+ distributed object model, including support for widely-distributed transactions.

.NET Remoting

.NET remoting provides the tools for any number of comprehensive communication scenarios that include XML Web services. Using .NET remoting, you can:

• Publish or consume services in any type of application domain, whether that domain is a console application, Windows Form, IIS, XML Web service, or Windows Service.

• Preserve full managed code type system fidelity in binary formatted communications, including support for generic types.

  Note
  XML Web services use SOAP formatting, which does not preserve all type details.

• Pass objects by reference and return to a particular object in a particular application domain.

• Control activation characteristics and object lifetimes directly.

• Implement and use third-party channels or protocols to extend communication to meet your specific requirements.

• Participate directly in the communication process to create the functionality you need.

See Also

Other Resources

.NET Remoting
.NET Framework Remoting Overview
Remoting Examples
Advanced Remoting
Windows Communication Foundation