Prior to .NET, DCOM existed as Microsoft's solution to remote object access. This technology leveraged the successful COM architecture to provide an infrastructure for remote communication. However, DCOM suffered from a variety of drawbacks and difficulties, and it ultimately led to Microsoft's spirited drive to develop Web services and their associated standards.

Unfortunately, in the pre-.NET age even these could be cumbersome and time consuming to develop, deploy, and access. The Remoting framework that .NET has brought (of which Web services can technically be seen as a subset, but will hereafter be dealt with separately) represents a tremendous leap forward in terms of customizability, availability, development speed, and ease of use for distributed communication.

XML Web Services and .NET Remoting are able to provide a solution to most of what one could ask of an RPC infrastructure. Both technologies are significantly easier to develop with, deploy, and consume than DCOM. Both are also able to tunnel through firewalls by relying upon standard protocols. The essential difference between the two lies in their interoperability: .NET (and Visual Studio.NET in particular) provides a superb environment and toolset for building interoperable, standards-based remote methods in the form of Web services. "Surely," one could ask, "we should always choose this option for developing remote components?"

From an initial architectural point of view, the answer is certainly yes. However, when we analyze the underlying technologies of each approach (as we'll do shortly), we begin to understand that this may not be so. The purpose of this article is to answer precisely this question, and to assess the speed costs associated with the Web services and various .NET Remoting configurations. To answer this, we will take both technologies to the racetrack and put them "head to head."

Our Object
To demonstrate the technologies that we'll be using, we will create a very simple object that exposes one method. This method selects a random sample of customers from the Northwind database (yes, I said "random" - we may not, in fact, encounter Alfreds Futterkiste in our results). We could develop a custom business object to pass back to the client, but this effectively undermines the purpose of an open, independent Web service. As a result, we will return our sample of 1000 records in a dataset.

To return a random result, we will use the NewID() T-SQL function, as in the following statement:

Select Top 1000 * From Customers Order By NewID()

The full object code can be seen in Listing 1, and it receives a database connection as its single argument. In addition, the class shall be used as in the Remoting example, with the only addition being that it now inherits from MarshalByRefObject. The full source code can of course be downloaded from http://www.sys-con.com/magazine/source.cfm?id=9. The dataset is returned is already serializable, so the class itself does not need to be specifically marked.

.NET Remoting
Remoting in .NET is remarkably customizable and extensible. The framework provides us with a variety of configuration options at each stage of the development process. A wealth of articles and books has been written on this technology and the references at the end of this article provide some rich resources and tutorials on how to build and implement Remoting. Figure 1 illustrates how the technology fundamentally operates. When a call is made from the client, a proxy is generated. The actual server object may or may not be instantiated at this point depending on whether the object is server- or client-activated. To compare properly to the Web service, our Remoting object will be a server-activated SingleCall (i.e., stateless) class. The call is passed through a formatting layer and a transport layer (referred to as "sinks") as well as additional custom layers. At the server, this process is reversed and the call is received by a host application. This in turn forwards the call to the underlying object. The object's specific method is called, and the resulting output is returned via the same route.

The formatter can serialize the call into either a binary or SOAP format and you can select either raw TCP or HTTP as a transport protocol. In fact, through writing your own sinks you can theoretically use any format or protocol. Finally, Remoting allows the host application to be of any kind of .NET project - a Windows service, a Web service, an ASP.NET application, or a .NET executable (graphical or command line). In our sample, we will develop a command line host as well as an ASP.NET host, to compare most fairly with a Web service. To directly analyze the speed options, the command line host will employ both the TCP-binary and HTTP-SOAP combinations. (Note: To execute the Remoting example, the command line exe must be running.) The ASP.NET option will operate similarly to the Web service and will employ HTTP-SOAP. For illustrative purposes, the various combinations will configure the Remoting settings in code, in an XML configuration file, and using a combination of both.

Web Services? What Are Those?
Web services have received such considerable hype in recent years that even the "if you haven't heard of them you must have been in a cave/up a mountain/down a hole" line is old. Nonetheless, it's worth revisiting their architecture in this comparison. Figure 2 illustrates this and we see that they rely on the arguments and return values serialized as XML within a SOAP message, all travelling aboard HTTP packets. In our sample we will copy the existing code into the Web service and prefix it with a requisite <webmethod()> tag.

Time Out
In attempting to analyze the speed of execution of the code, the first tests simply captured the start and end time of the call and subtracted the former from the latter. However, the results were rather peculiar, and further investigation revealed that this and similar methods would be unable to achieve a resolution below 15 milliseconds. As the final results will show, this was wholly unacceptable. Indeed, this perhaps clarifies why the .NET DateDiff function only supports timing to the second interval and not below. The solution, according to the MSDN library (see HOW TO: Use QueryPerformanceCounter to Time Code in Visual Basic .NET in the references), is the use of the QueryPerformanceCounter Win32 API call, for which an easy-to-use implementation was found on DevX.com (see Stopwatch — a High-Resolution code timer class in the references). This class is included in the sample code.

To The Race Track
We will be performing seven tests in our analysis that among them will assess a variety of remote configurations. For both the Web services and Remoting technologies, a local version running on the same machine as the client was tested, and these hosts were then copied to an empty test server elsewhere on the LAN for the subsequent tests. Also, the database in all of the tests was hosted on a third dedicated SQL Server box. The connection string and the number of calls performed in each test are both stored as constants in the sample app and are thus easy to adjust. However, to overcome any compilation or similar initial delays, the very first call to any object is ignored in calculating the timing. A description of each of the tests follows.

• Figure 1
• Figure 2
• Figure 3
• Table 1
• Source Code