Choosing Communication Options in .NET
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.
Not all applications should be built using some form of XML Web service, however, if only because of the performance issues related to using SOAP serialization over an HTTP connection. Use this section to help you decide which form of interobject communication you want for your application.
ASP.NET or Remoting?
Both ASP.NET and .NET remoting are interprocess communication implementations. ASP.NET provides an infrastructure, hosted by Internet Information Services (IIS), that handles basic types well and is familiar to Web application developers. .NET remoting is a generic and extensible interprocess communication system that you can use to create XML Web services hosted in IIS (and have all the security, scalability, and session and application state of ASP.NET and IIS), or applications that use any other type of communication protocol or serialization format.
The type of communication you need and the programming model you are familiar with are the two main criteria that should drive your choice between the two programming models. You must choose the type of interprocess communication and the programming model that enables you to implement your decisions in the easiest way. Here are some criteria (in order of priority) for choosing the type of interprocess communication you need, along with a comparison between XML Web services built with ASP.NET and XML Web services built with .NET remoting:
Security needs.
If you need to encrypt your calls or authenticate your client, you must use an HTTP-based application hosted in IIS, whether that is an ASP.NET application or a remoting application. This is because ASP.NET and .NET remoting use the security services provided by IIS. .NET remoting does not provide any security services when hosted outside IIS (for example, in a Windows Service). Although you can use .NET remoting in any application domain (unlike XML Web services built with ASP.NET, which must be hosted in IIS), you must provide the security features you require when you use .NET remoting outside IIS. You do not need to use the SOAP encoding format when using an HTTP connection; you can use the binary encoding to increase speed.
Speed.
.NET remoting has a potential performance advantage over XML Web services built with ASP.NET because it gives you the option of using binary encoding and the default TcpChannel, which offers the best interprocess communication performance. You can specify binary encoding even if you do not use the default TcpChannel by using the binary formatter with the HttpChannel class which uses POST communication with IIS (or any remoting HttpChannel listener application). Using binary formatting alone will increase call performance in remoting dramatically, even if you use the HttpChannel. If you do not have any security issues (for example, if you are building a small application that runs entirely inside a firewall), the default TcpChannel with binary formatting will perform best. XML Web services built with ASP.NET always use SOAP encoding, which generally performs less well than binary encoding. However, in situations where .NET remoting features are not required, but the HTTP protocol with SOAP messages are required, XML Web services built with ASP.NET provide better performance.
Interoperation.
If you need to interoperate between different operating systems, you will typically use the SOAP formatting protocol, whether you use .NET remoting or ASP.NET. XML Web services built with ASP.NET give you considerably more flexibility in defining the shape and style of SOAP communication than .NET remoting. This can make interoperating with different platforms and clients easier. .NET remoting is optimized for communication with .NET clients, although you can interoperate between different operating systems using a remoting application.
Scalability.
Hosting your application inside IIS gives you the scalability you need, whether you use .NET remoting or ASP.NET.
Use of common language runtime features.
Because .NET remoting can take better advantage of .NET clients, you can use .NET features in a remoting application that are unavailable to an XML Web service built with ASP.NET. Some of these features are:
- interfaces.
- CallContext.
- properties.
- indexers.
- Managed Extensions for C++.
- Type fidelity between the client and server applications.
- delegates.
Object-oriented application design.
XML Web services built with ASP.NET do not represent an object-oriented design paradigm. They are essentially stateless Web resources, much as Web pages are, although IIS and the ASP.NET infrastructure provides some state services. .NET remoting objects are objects and can be treated as such. As a result, you can use the following object-oriented .NET features that are unavailable to ASP.NET:
- Object references to remoted objects.
- Several object activation options.
- Object-oriented state management.
- Distributed object lifetime management.
The following is a brief summary of some of the differences between XML Web services built using ASP.NET, the System.Net namespace, and .NET remoting.
XML Web Services
If you build ASP applications using the Web application model and have the power of the ASP.NET HTTP runtime, including strong support in Microsoft Visual Studio. NET, XML Web services built using ASP.NET are for you. With the XML Web service infrastructure, you can easily create components for other applications to use, or use components that others have created 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 ground up. 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 Accessing the Internet.
.NET Remoting
.NET remoting provides the tools for any number of comprehensive communication scenarios that include, but are not limited to, 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, a Windows Form, Internet Information Services (IIS), an XML Web service, or a Windows Service.
Preserve full managed code type system fidelity in binary formatted communications.
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 needs.
Participate directly in the communication process to create the functionality you need.
See Also
Accessing Objects in Other Application Domains Using .NET Remoting | .NET Remoting Overview | Remoting Examples | Advanced Remoting