Chapter 27: Remoting

Overview

Remoting is the .NET technology that enables code in one application domain (AppDomain) to call into the methods and properties of objects running in another application domain. A major use of remoting is in the classic n-tier desktop approach, where presentation code on the desktop needs to access objects running on a server somewhere on the network. Another primary use for remoting is when code in ASP.NET Web Forms or Web Services needs to call objects running on an application server somewhere else on the network. In short, remoting is the technology to use when your n-tier code needs to talk to the business or data tier running on an application server.

Remoting is conceptually somewhat similar to Web Services. Both remoting and Web Services are TCP/IP-based technologies that allow communication between different machines over an IP network. This means that they both pass through firewalls, and they both provide stateless and connectionless communication between machines. These two technologies share a lot of the same principles.

Important  

It is important to recognize that Microsoft has merged the functionality of remoting, Web Services, enterprise services, and MSMQ (Microsoft Message Queue) into the Windows Communication Foundation (WCF) - the next generation of the technologies. You can find more information on WCF in Chapter 30.

When working with XML Web Services, the biggest problem with SOAP is that it is not lightweight. It’s designed with maximum platform interoperability in mind, which puts certain limits on how data can be transferred. For example, imagine that platform A stores integer variables as a 4-byte block of memory, with the lowest-value byte appearing first. Now imagine that platform B also uses a 4-byte block of memory, but this time the highest-value byte appears first. The encoding of the value is different. Without some form of conversion, if you copy that block of bytes from platform A to platform B, then the platforms won’t agree on what the number actually is. In this scenario, one platform thinks it has the number 4, whereas the other thinks that the number is actually 536870912.

SOAP gets around this problem by representing numbers (and everything else) as strings of ASCII characters - since ASCII is a text-encoding standard that most platforms can understand. However, this means that the native binary representations of the numbers have to be converted to text each time the SOAP document has to be constructed. In addition, the values themselves have to be packaged in something that you can read (with a little bit of effort). This leads to two problems: massive bloat (a 4-byte value starts taking hundreds of bytes to store) and wasted CPU cycles used in converting from native encoding to text encoding and back again.

You can live with all these problems if you only want to run your Web Service on, say, Windows 2000, and have it accessed through a client running on a cell phone. SOAP is designed to do this kind of thing. However, if you have a Windows XP desktop application that wants to use objects hosted on a Windows 2000 server (using the same platform), the bloated network traffic and wastage in terms of conversion is sub-optimal at best and ridiculous at worst.

Remoting lets you enjoy the same power of Web Services but without the downside. If you want, you can connect directly to the server over TCP and send binary data without having to do any conversions. If one Windows computer has a 4-byte block of memory holding a 32-bit integer value, you can safely copy the bit pattern to another Windows computer and both will agree on the number. In effect, network traffic sanity is restored and processor time isn’t wasted doing conversions.