Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

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

Remoting is a powerful technology for implementing distributed applications. Interfaces make it possible to access external code in a strongly-typed manner. Generics in Visual Studio 2005 simplify the process even further.


advertisement
his installment of the Baker's Dozen presents an introduction to remoting and remoting interfaces. Using .NET remoting you can call and execute code running outside your machine's physical boundaries, such as a Web service accessing classes on an application server, or a client application accessing the middle tier in a client-server environment. The code is executed on the domain that stores the code.

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.

Remember to add a .NET reference to System.Runtime.Remoting any time you write code that directly accesses the remoting namespaces.
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:

  1. Create a strongly typed interface (ICustomer) that contains a definition for a GetCustomer method.
  2. 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.
  3. Create a Customer Business object (CustomerBzObject) that does three things: inherits from BaseBzObject, implements ICustomer, and contains a GetCustomer method.
  4. Build a "listener," a remoting server that registers CustomerBzObject. The client class can access and activate registered classes through a TCP port.
  5. 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."


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap