Microsoft has made a tremendous amount of noise about building applications with Web services, and its .NET Framework simplifies the task of working with them. But while Web services represent a great way to build applications, they are ideally suited for clients outside the firewall calling components on your server over the Internet.

If both your clients and components are inside the firewall, Web services may work fine; however, all of your data travels through a Web server, which can slow performance. To speed things up, Microsoft provides a binary mechanism called remoting.

Let’s take a look at how remoting works, and I’ll share some code examples that show you how to set it up in a sample Web service.

How Web services work with .NET

For a brief explanation on how Web services work, and specifically how they work in .NET, check out this sidebar.

.NET remoting
While Web services are arguably the best way for clients outside of your organization to access components, what about components within your organization? Many companies are building Web services and using them internally. There is nothing wrong with this approach, but it doesn’t provide the best performance. If components are created in .NET and the client applications are .NET, you can place components on shared servers and access them via remoting.

Remoting is the .NET technology that replaces DCOM allowing you to communicate between a client application and components in a binary format. As a result, remotable components are faster than Web services. However, creating remotable components is more difficult because you must add additional code to your components. This code isn’t much more complicated than its Web service counterpart, but you cannot directly instantiate a remote component. Instead, you must create a host application that instantiates the component and listens for requests. The good news is that this host can be a Windows service, a Windows application, a console application, or anything that can run and hold the object open.

Not only do you have to create a host application, you must also make several decisions about the remotable object, such as which channel to use. .NET supports both HTTP and TCP channels. The HTTP channel actually uses the SOAP protocol to transport messages to and from remotable objects; this means all messages are serialized to XML. The TCP channel uses a binary stream to transport the messages.

Next, you must choose between two activation modes: Singleton and SingleCall. Singleton types have only one instance of an object at any time. All client requests are serviced by that single instance. This allows you to “share” data between requests or, more likely, maintain state between requests. SingleCall types, on the other hand, create a new instance of the object for each client request. SingleCall objects are more like Web services because they are stateless and are created and destroyed for each request.

.NET is architected in such a way that remotable components can change channels without being recompiled. You can place the channel information in a configuration file and change from TCP to HTTP or vice versa without recompiling the application. Similarly, you can change a configuration file for the client to match the channel that the host is using.

Quick code comparisons
To see some quick examples of a Web service and a remotable object with host, I’ll use the example I used in a previous article in which I created a simple Web service. The entire code for the Web service follows:
 
<%@ WebService Language=”VB” Class=”ConvertMoney” %>
Imports System.Web.Services
<WebService()>Public Class ConvertMoney
Inherits WebService
<WebMethod()>Public Function _
PoundsToDollars(BritishPounds As Double) As Double
Return BritishPounds * 1.44
End Function
End Class
 

Here is the code to implement the same thing with a remotable component:
 
Public Class ConvertMoney
Inherits System.MarshalByRefObject
Public Function _
PoundsToDollars(ByVal BritishPounds As Double) As Double
Return BritishPounds * 1.44
End Function
End Class
 

The component looks simpler. In fact, the only difference is that it inherits from System.MarshalByRefObject. But remember, you need to build a host application that instantiates the object and listens for requests. The code for the host object could look like this:
 
Imports System.Runtime.Remoting
Imports System.Runtime.Remoting.Channels
Imports System.Runtime.Remoting.Channels.Tcp
Imports RemoteConvertMoney
Module Module1
Sub Main()
Dim tcpChannel As New TcpChannel(7777)
ChannelServices.RegisterChannel(tcpChannel)
Dim ChangeMoney As New ConvertMoney
RemotingServices.Marshal(ChangeMoney, “ConvertMoney”)
Console.ReadLine()
End Sub
End Module
 

In this case, the host application is a console application. You start the application and it launches a console application and creates the object. The console application runs until someone presses the [Enter] key, and the object is available until needed.

As you can see, the amount of work required to create the remotable component is more than the Web service.

Make the choice
There is no absolute answer to whether you should choose Web services or remoting in most cases. If your entire distributed application is inside your organization firewall and performance is critical, remoting via the TCP channel is the best choice. If the entire application is inside the firewall and performance isn’t as critical, or if you want to keep things as simple as possible, Web services is a better choice.

But, if you need to allow access to clients other than .NET, you’ll need to use Web services regardless of whether or not the client is inside or outside the firewall. In the end, the choice is left to the developer, so you’ll need thorough knowledge of both technologies to make a proper decision.