Using Remoting to Build and Consume Web Services

Remoting vs. ASP.NET

You should consider using Remoting over ASP.NET in at least three scenarios:

• When you need to use a transport protocol other than HTTP ASP.NET is tightly coupled to the HTTP transport protocol, but Remoting is transport protocol agnostic.

• When you need to host a Web server in a process other than IIS ASP.NET is tightly coupled to IIS, but Remoting can host a Web service in any .NET process.

• When you need strong support for .NET types The primary responsibility of the Remoting framework is to serve as the distributed object infrastructure for .NET, so Remoting provides the necessary extensions to facilitate this.

Let's discuss each of these scenarios in more detail.

HTTP is the most widely supported transport protocol used by Web services, but it might not be ideal in some situations. For example, a queuing application might find asynchronous protocols such as SMTP more appropriate. A Web service hosted by a satellite might not support the HTTP protocol at all.

Remoting allows a client to communicate with a remote object over a wide variety of transport protocols, including HTTP and raw TCP/IP. If a particular transport protocol is not supported out of the box, you can extend the Remoting framework to use the desired transport protocol.

Remoting also supports an extensible means of specifying the format of the message that is shipped between the client and the server. Remoting supports two message formats, binary and SOAP. Binary is more efficient and less verbose than SOAP. However, because it is not based on industry standards, it does not offer the same degree of interoperability that is provided by its SOAP counterpart. Therefore in this chapter, I limit my discussion to the SOAP message format.

I anticipate that Remoting will support the SOAP 1.2 specification as a new message format type. If this proves to be the case, the Remoting framework's support of pluggable message formats should dramatically simplify the task of maintaining SOAP 1.1 versions of Remoting Web services for backward compatibility.

You can alter which message format and transport an application uses by changing a configuration setting. This is ideal for distributed .NET applications that reside in a mixed environment. A .NET client residing on the same corporate network as a .NET server can use the more performant binary message format rather than TCP/IP. But the same .NET application can use the SOAP message format over HTTP if it needs to communicate through a firewall or an HTTP proxy server.

In Chapter 3, I described some of the limitations of the current SOAP specification relating to features typically supported by a distributed object infrastructure. For example, SOAP does not define a means of passing an object by reference between the client and the remote object. To fulfill its role, Remoting provides its own implementation to overcome these limitations.

Remoting provides a set of features for Web services in addition to the ones defined by industry-standard specifications. The value-added services Remoting provides include

• Activation Remoting provides the ability to remotely activate an object, including full support for parameterized constructors.

• Lifetime support When a remote object is activated on behalf of a client, this mechanism ensures that the remote object is freed when it is no longer needed by the client.

• Passing objects by reference Remoting provides the ability for a client to pass objects by reference. The SOAP specification defines only a means of passing objects by value between the client and a Web service.

• Full fidelity for .NET types A Web service built on top of the Remoting framework exposes additional metadata about its types. This information is necessary to maintain full fidelity of the .NET types exposed by the Web service.

To support these features, the Remoting team had to define a proprietary set of extensions. If interoperability is a priority, be sure to not leverage these features within your Web service.