.NET Remoting vs. XML Web Services

XML Web services offer a simpler model for distributed applications than that provided by .NET Remoting. XML Web services are fine-tuned for Internet scenarios and cross-platform use. Although you can apply .NET Remoting in these scenarios, thanks to its SOAP formatter and HTTP channel, .NET Remoting is more suitable as a high-speed solution for binary communication between proprietary .NET components, usually over an internal network. And although XML Web services can't match the communication speed of .NET Remoting over a binary channel, they still lend themselves to high-performance designs thanks to their stateless nature and ASP.NET's multithreaded hosting service.

Here's a quick overview of the major differences between the XML Web service and .NET Remoting technologies:

• XML Web services are more restricted than objects exposed over .NET Remoting. An XML Web service works in a similar way to a SingleCall .NET Remoting object. It isn't possible to create a singleton or a client-activated object.

• Because of the restricted nature of XML Web services, the design issues are simplified. XML Web services are generally easier to create than remotable components (and easier to design well).

• Communication with .NET Remoting can be faster than XML Web service communication if you use a binary formatter. XML Web services support only SOAP message formatting, which uses larger XML text messages.

• XML Web services support open standards that target cross-platform use. For example, each .NET XML Web service has an associated WSDL document that describes how a client can interact with the service. Therefore, any client that can parse an XML message and connect over an HTTP channel can use an XML Web service, even if the client is written in Java and hosted on a UNIX computer.

• XML Web services are designed for use between companies and organizations. They can use a dynamic discovery mechanism or a UDDI registry that "advertises" services to interested parties over the Internet.

• XML Web services don't require a dedicated hosting program because they are always hosted by ASP.NET. That also means that they gain access to some impressive platform services, including data caching, Web farm ready session state management, authentication, and an application collection for global, shareable objects. These features, if required, can be extremely difficult to re-create by hand in a component exposed through .NET Remoting.

• Because XML Web services work through Microsoft Internet Information Services (IIS) and ASP.NET, they can communicate with clients using the default HTTP channel (usually port 80). This means that consumers can use XML Web services just as easily as they can download HTML pages from the Internet. There's no need for an administrator to open additional ports on a firewall.

Note

The underlying technology that supports XML Web services overlaps with portions of the .NET Remoting framework. Part of the reason for this is that these technologies were developed simultaneously, before the .NET team realized the full potential of XML Web services. Chapter 11 examines the similarities a little more closely. For now, it helps to remember a broad distinction: If you are planning to provide functionality to clients over the Internet, XML Web services should be your first choice. If you need different capabilities or faster communication over a closed network, however, .NET Remoting is often a better option.

According to Microsoft architects, .NET Remoting isn't designed to work in interop situations (for example, with Java clients) or when crossing trust boundaries (for example, exposing functionality to third-party clients or another business). These two basic rules of thumb can help you decide when to use .NET Remoting and when to use XML Web services. Incidentally, speculation abounds that XML Web services and .NET Remoting technology will be integrated in some future release of the .NET Framework, although this development isn't on the imminent horizon and it won't help you plan today's generation of distributed applications.