The Baker’s Dozen: 13 Productivity Tips for Remoting in Visual Studio 2005

This installment of the Baker’s Dozen presents an introduction to remoting and remoting interfaces. Remoting is an ideal approach for executing code that resides on another domain: remoting interfaces allow developers to program against a strongly-typed model of code outside the current project. Building a remoting solution requires more code and may initially appear more complicated than Web services, so this article de-mystifies remoting by presenting a walk-through of a simple remoting project. The article begins with an overview of remoting architecture and the different ways to use remoting, then you’ll delve into the fundamental aspects of remoting. The article also presents some of the new capabilities for remoting in Visual Studio 2005. At the end, I provide a number of links for reading about more advanced remoting topics.

Beginning with the End in Mind

I’d been planning an article on remoting in Visual Studio 2005 for several months now. In the last few weeks, I’ve read different online questions that related directly to remoting. First, someone asked about practical uses for interfaces. Next, someone asked about the value of generics. Finally, someone asked why remoting is preferable to Web services. Those questions provided the inspiration for this article.

For the last year and a half, I’ve tried to target specific skill and experience levels for the Baker’s Dozen articles. This time around, I’ll preface by saying that this is an introductory article for those who want to see the following fundamentals of a remoting application, and how interfaces can help:

• An overview of a remoting architecture
• Different remoting implementations (TCP and HTTP)
• Defining remoting interfaces
• Defining the business object to be accessed through remoting
• Defining the client piece
• Defining the server (listener)
• Improving DataSet remoting performance in Visual Studio 2005
• Building a Windows service
• New security enhancements for TCP remoting in Visual Studio 2005
• An overview of generics in Visual Studio 2005
• Using generics to simplify remoting interfaces
• Creating a remoting object factory
• Using the remoting object factory

Many of these tips also apply to Visual Studio 2003, unless specifically indicated as Visual Studio 2005. At the end of this article I’ll provide some good references for remoting. Here we go!

Tip 1: An Overview of Remoting Architecture

I’ll start with a very simple example. Let’s say that you have a local class (client class) that needs to call another class in the middle-tier (external method). The external method retrieves customer data based on a customer key. The client class and remote method reside on different application boundaries, so the client class neither sees the external method that retrieves the data as a project file nor as a reference. When the client class executes the external method, the code in the external method must execute on the domain where the external method resides.

Your first inclination might be to dynamically search and load the external method through reflection. Although that’s possible, the approach relies on assumptions, such as availability of the module, name and location, etc.

Solve the problem by defining a strongly-typed remoting interface that both the calling project and external method can use. Use TCP remoting to communicate across application boundaries and access the external method. A strongly-typed approach is more efficient and less likely to introduce runtime errors.

As an overview, the steps to accomplish this are as follows:

• Create a strongly typed interface (ICustomer) that contains a definition for a GetCustomer method.
• Create a base business object (BaseBzObject) class from which the external method inherits. The base business object itself inherits from System.MarshalByRefObject, which is required for remoting.
• Create a Customer Business object (CustomerBzObject) that does three things: inherits from BaseBzObject, implements ICustomer, and contains a GetCustomer method.
• Build a “listener,” a remoting server that registers CustomerBzObject. The client class can access and activate registered classes through a TCP port.
• Create a simple client form that activates an object using a type reference to the ICustomer interface through the same TCP port that the remoting server/listener monitors.

These five steps represent the “what.” Tips three through seven cover the “how” and “why.”

Tip 2: Understanding the Different Options in Remoting

There are two flavors of remoting: TCP and HTTP. That gives us a grand total of three different options for distributed computing when you add .NET Web services into the mix. Note that they’re not mutually exclusive: an application might use Web services between the client and application tiers and remoting inside the application tiers.

So let’s take a moment and look at the three, and common reasons that they’re used:

• ASP.NET Web services are the way to go when you must support SOAP over HTTP, and/or you have non-.NET applications accessing the application.
• HTTP remoting is an option for installations that always use .NET for all layers, but also must make use of HTTP. You can set up your remoting components under IIS to use authentication and security features.
• TCP remoting in Visual Studio 2003 was an excellent choice for internal applications that didn’t require security. TCP remoting is generally (and in some instances, significantly) the fastest of the three. Visual Studio 2005 also extends TCP remoting by offering security capabilities (see Tip 9). This makes TCP remoting even more attractive for applications beyond internal ones.

Visual Studio 2005 enhances remoting even further by allowing developers to serialize datasets across application boundaries in a binary format (see Tip 7). This eliminates the need to programmatically convert DataSets to or from XML strings, and reduces the size of the dataset when you pass it across physical boundaries.

Tip 3: Building Remoting Interfaces

As stated in Tip 1, the first step is to create an interface. The external class that you wish to access implements this interface. The client piece accesses the external class by means of this interface.

Note that the interface contains no actual code for GetCustomer. The only significance is that any class implementing this interface must have a method called GetCustomer that receives an account ID and returns a DataSet. As you’ll see later, that’s all the client side needs.

By: Kevin S Goff

Kevin S. Goff, a Microsoft MVP award recipient for 2007, is the founder and principal consultant of Common Ground Solutions, a consulting group that provides custom Web and desktop software solutions in .NET, VFP, SQL Server, and Crystal Reports. Kevin is the author of Pro VS 2005 Reporting using SQL Server and Crystal Reports, published by Apress. Kevin has been building software applications since 1988. He has received several awards from the U.S. Department of Agriculture for systems automation. He has also received special citations from Fortune 500 Companies for solutions that yielded six-figure returns on investment. He has worked in such industries as insurance, accounting, public health, real estate, publishing, advertising, manufacturing, finance, consumer packaged goods, and trade promotion. In addition, Kevin provides many forms of custom training. Contact Kevin at kgoff@commongroundsolutions.net

kgoff@commongroundsolutions.net