While this may all sound pretty clear cut, there is a lot going on under the covers. How do you instantiate a remote object? How do you transfer data to it? How do you know when it's done and the results are ready? Until fairly recently the answer to all these questions involved creating your own protocol and API set to hook up the two computers. Besides being just plain hard, it is extremely tedious and unrewarding work because you have two different development models to work with: one for local objects and another for remote objects. Worse still, the two applications invariably ended up being extremely tightly coupled, so if you made even the slightest change on one end you would have to tweak the other end.

With the release of Microsoft Windows NT� 4.0 and the introduction of DCOM (Distributed Component Object Model), developing network applications became much easier. Because DCOM simply extended COM to the network, it abstracted out all the yuckiness of connecting to and instantiating remote objects and passing data back and forth. Better yet, it allowed developers to work with remote objects in the same manner that they interacted with local objects.

While it was a great step forward, because DCOM was designed and developed before the Internet really took off, some parts of its architecture made it challenging to deploy in many enterprise environments. Chief among these was that it took some effort to configure your objects so that they could pass data across firewalls. Also, because it passed data between objects in a binary format, it was difficult to integrate DCOM applications with applications built on top of other object brokers. Even accessing DCOM-based objects on non-Microsoft Windows� platforms was often difficult. Finally, because it was built on COM, versioning was often, well, a great opportunity to demonstrate your change and configuration management skills.
 

With .NET Remoting, you get all the benefits of DCOM with none of the drawbacks. To address the firewall issue, .NET Remoting can communicate using either standard HTTP or a specific TCP channel. On the interoperability front, .NET Remoting allows you to transfer data using SOAP ( Simple Object Access Protocol), which allows you to easily interact with any object that supports the SOAP standard. This means that where DCOM only abstracts the location of the object, .NET Remoting abstracts both the location and the platform that is hosting it. From your application running on a Microsoft Windows box you can use .NET Remoting to invoke a method on an object running on FreeBSD just as easily as you could were that object running in your own process space.

Finally, for versioning, just like any other application built on the Microsoft .NET Framework, assemblies using .NET Remoting support side-by-side installs where you can have two completely different versions of the same application installed at the same time; in fact, with a little effort you can even run the two versions concurrently.

Where DCOM gave you only one way of communicating with remote objects, .NET supports a host of different options out of the box and has a great extensibility model if your particular situation is such that you need more controls (for example, calling an �object� on a propriety device with no connection other than a serial port). While options are always good, they introduce trade offs (performance vs. interoperability, security vs. flexibility, and so on) that you really need to understand before designing solutions. Fortunately, in Building XML Web Services for the Microsoft .NET Platform, Scott Short walks you through the pros and cons of each approach so that you will know exactly what to do in your specific situation.

If you are like me, when you need to learn how to do something you go directly to the index (or search engine), look for the exact piece of information you need, and skip all the introductory junk. Often this means jumping in the middle of a discussion and having to backtrack a bit to figure out what terms mean and what the architecture looks like. Well, when it comes to remote object access, the terminology is often daunting if you are new to it. In this section, I will cover some of the key terms so that when you jump into the documentation, you will understand the framework.

• Proxy�One of the first terms you will run across is proxy. Most texts either don't bother to define the term at all or give such a complex, overly exact definition that it's hard to follow. In a nutshell, when an application requests a remote object, .NET will hand it a local proxy that represents the remote object, and the application will make its calls directly against the proxy. When it comes time to actually pass the call across the wire to the remote object, the proxy makes that call, retrieves the results, and passes them back to the calling app. In coding terms, think of it as a stub. It is this concept of a proxy that allows us developers to interact with remote objects as if they were local because it hides all the complexity of sending data back and forth to the remote object.
• Marshaling�Marshaling is a fancy way of talking about passing objects by reference (ByRef) or by value (ByVal). More specifically, it refers to the process of getting the information (either the method call and the arguments if it is ByRef or the entire object if it is ByVal) from one process to another. Let's be clear; if you are passing by values, you are not doing Remoting. While this confuses some people, it makes sense. If you request a remote object by value and execute a method against it, the local application is performing the work because the object now exists in your process space. Don't get me wrong; there is nothing wrong with requesting remote objects by value (in fact, it gives the best performance in some cases), and it is a valid approach for distributed applications�it is just not Remoting.
• Serialization�First off, for those of you with a transactional processing background, this has nothing to do with isolation levels. Now that that bit of potential confusion has been dispelled, let's look at what serialization means for .NET Remoting. Say you have decided to marshal by value. The process of packaging it in an object and preparing it to be put on the wire is called serialization. While not directly pertaining to Remoting, in other situations serialization can refer to persisting an object out to permanent storage for later retrieval. When you think about it, serialization is the same process, just that in the .NET remoting case, the �permanent� storage is the network connecting the two machines.

The exact process of serialization is best described by walking through an example. In .NET, the default serialization format is XML. Therefore, let's look at a very simple class named Person. 

// C#
public class Person
{
     public string FirstName;
     public string LastName;
}

'-- VB
Public Class Person
     Public FirstName As String
     Public LastName As String
End Class

When you serialize this, you get something like this:

<Person>
     <FirstName>Scott</FirstName>
     <LastName>Mauvais<LastName>
</Person>

Pretty cool. I can get an XML representation of my class (yes, it supports class hierarchies too) with absolutely no effort on my part. Hmmm, I wonder if I could use this for something besides just remoting. Say I want to persist an object's data on one machine, dump it to a floppy, and transfer it to another machine.

On the one hand, this looks pretty useful. On the other hand, I will often want the data in a format that does not match the serialization format that .NET uses by default. This is where it gets really cool. By simply adding an attribute to my code, I can control the shape of the XML that the Microsoft .NET Framework serializes.
Sticking with the same Person class, say instead of FirstName and LastName I want givenName and surName. Easy, just add an attribute to my code:

//C#
public class Person
{
     [XmlElement(ElementName = "givenName")]
     public string FirstName;

     <XmlElement(ElementName = "surName")>
     Public LastName As String
End Class

Now the serialized output will look like this:

<Person>
     <givenName>Scott</givenName>
     <surName>Mauvais</surName>
</Person>

For more information on serialization see Controlling XML Serialization Using Attributes, which will give you an overview of the process, and Attributes that Control XML Serialization, which provides details on how each attribute affects the output generated by the XmlSerializer.

If you ever need even more flexibility, you can write your own serializer by implementing the ISerializable interface.
 

Now that you have an overview of developing distributed applications with .NET Remoting, you should be ready to dive in and start developing your own real applications. I started off this article by describing some of the challenges of building distributed applications with traditional tools. Next I showed the features in the Microsoft .NET Framework, such as SOAP and side-by-side assemblies, that make distributed development much easier. Finally, I covered some of the basic terminology of Remoting and walked you through some sample code to serialize an object.

To see exactly how easy it is to develop distributed applications, you should get a copy of Building XML Web Services for the Microsoft .NET Platform, by Scott Short. This book covers everything from architecture and protocols to the best practices you need to know to build Web-ready, distributed-object applications.

Microsoft Press� provides in-depth documentation for these and all the other issues related to developing for .NET. For a complete list of .NET titles from Microsoft Press, see the Inside Information About Microsoft .NET page.

To learn more about building network-aware, distributed applications see Network Programming for Microsoft Windows, Second Edition by Anthony Jones and Jim Ohlund. This book provides great insight into networking APIs in Windows XP and shows you how to utilize them from your .NET applications.

If you are new to Microsoft Visual Basic�, you will probably be interested in Microsoft Visual Basic .NET Step by Step by Michael Halvorson. This is a great guide that quickly shows you how to build both Windows Forms and XML Web Services applications the right way. This book covers everything from upgrading from Microsoft Visual Basic 6.0 to optimization techniques to deploying your application.

Another great book for more experienced Visual Basic developers is Coding Techniques for Visual Basic .NET by John Connell. This book goes beyond simple examples designed to teach you the language; it focuses on demonstrating key techniques to help you ship professional-level code. You might also find John Connell's author interview interesting.

For books and information on Web Services and Microsoft Visual Studio� .NET, check out the following resources:

Books about .NET XML Web Services

Information about Visual Studio .NET