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 following topic 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. For example, the growth of the Internet has made XML Web services an appealing 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. The architecture of .NET remoting 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:
Of the three programming models, Enterprise Services has the richest set of security features and works with the 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 make remoting endpoints available through secure channels. Never display insecure remoting endpoints to the Internet.
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.
If speed is 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.
Hosting your application inside IIS gives you the scalability you need. Self-hosting .NET remoting requires 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.
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:
Type fidelity between the client and server applications.
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.
- Object references to remoted objects.
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.
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 other applications 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.
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 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 provides the tools for many comprehensive communication scenarios that include XML Web services. Using .NET remoting, you can:
Publish or access 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.