.NET Infrastructure for Distributed Systems

Chapter 7 - Distributed System Design
byAndrew Filevet al.?
Wrox Press ©2002

	Team FLY

Now is time to ask ourselves what support we have from .NET for distributed system development and what issues concerning the design of a distributed system it takes care of. The infrastructure .NET provides for developing distributed programming comprises .NET Remoting and ASP.NET Web services. .NET Remoting is an ORPC implementation similar to DCOM and IIOP/GIOP we mentioned in previous sections. ASP.NET's ancestor ASP (Active Server Pages) was Microsoft's web server-side script engine run by Microsoft IIS (Microsoft Internet Information Service) web server. One of the major improvements ASP.NET has over ASP is its support for Web Services. It is because of this support for Web Services that clients can send SOAP messages to ASP.NET web services to invoke methods on server-side objects in an object-oriented fashion. Below we'll have a whirlwind coverage of .NET Remoting as it is less familiar to most developers and some basic knowledge of it is necessary for later discussion in this chapter. Following the whirlwind coverage of .NET Remoting is a comparison between .NET Remoting and ASP.NET and some guidelines on when to use which.

For more information on ASP.NET, we recommend readers towards 'Professional ASP .NET 1.0', Wrox Press (ISBN 1-86100-703-5).

.NET Remoting

Let's start with a quick tour of some basics of .NET Remoting. We'll briefly go through some concepts and terms in .NET Remoting in this section and set the background for later discussion. For a good introduction to .NET Remoting, see Visual Basic .NET Remoting Handbook, Wrox Press, (ISBN 1-86100-740-X) or Chapter 21 in Professional C# 2nd Edition, Wrox Press (ISBN 1-86100-704-3) for a C# view.

The objective of .NET Remoting is to help develop objects that can be consumed remotely in an object-oriented way. The figure above shows the relationship between a .NET Remoting server and client and how they fit in the big picture. In the above figure, we see that Remoting objects reside in a host server. Depending on how objects are activated, and their states maintained, they can be categorized into three types - Singleton, SingleCall, or ClientActivated.

• SingleCall objects: A SingleCall object is an object that is created for each method call and destroyed when the call is completed. A SingleCall object holds no state information between method calls.

• Singleton objects: A Singleton object is an object that services multiple clients. There can be only one object instance of a Singleton class. The state of a Singleton object is shared among clients. By state we mean values kept by member variables of a class. This type of object is called a Singleton object precisely because it follows the Singleton pattern discussed in Professional Design Patterns in VB.NET: Building Adaptable Applications, Wrox Press (ISBN 1-86100-698-5).

• Client-activated objects: A Client-activated object is quite simply an object that is activated on the client's request. A Client-activated object can hold state information between method calls triggered by the same client. However, you cannot easily share state information among several clients with a Client-activated object.

Objects can reside in an executable host (an EXE file) of their own, or they can have IIS or the .NET Component Service as their host. Communication channels between client and server can be HTTP, SMTP, TCP, etc. When using an HTTP channel, request and response messages are SOAP messages by default. An HTTP channel can use other types of message formatters as well.

The figure above also shows one of the several ways a client can use to generate a proxy of a remote server object. A proxy is a local representation of a remote object. The main purpose of having a proxy at the client side is to make the remote object's location transparent to the client so that a method call on a remote object looks like a method call on a local object. Without proxies, clients of a remote object will have to serialize calls to and deserialize results from remote objects. For a proxy to represent a remote server object on the client side, it needs to have some knowledge about the server object in order to represent it. The knowledge is the server object's type information. .NET provides a utility, soapsuds.exe, which developers can use to get the service description of a Remoting object remotely. The service description contains the server object's type information. If the client has a local copy of the .NET Remoting server assembly, soapsuds.exe can generate a proxy from that too. .NET Remoting is all about exposing remote objects for clients to consume.

.NET Remoting allows you to extract some attributes of server objects and put them into a separate configuration file. In the configuration file, you specify what port and protocol the server object will use to communicate with clients, whether the server object is Singleton, SingleCall, or ClientActivated, and sometimes what formatter to use to serialize objects into streams.

The advantage of this approach is that you can change any of the settings in the object's configuration file without any code change in the object itself, and therefore without recompiling the object source files. This is very helpful at the deployment phase. Usually, (and hopefully!) your software will be sold to several customers. Each customer might have a different deployment scenario. If you put configuration settings such as a remote object's transport protocol plus port number, activation mode (Singleton, SingleCall, or ClientActivated), and serialization formatter in a configuration file, your field engineers can fine tune those parameters according to the customer's production environment with ease.

Remember that we said earlier that Remoting objects can be hosted in IIS, .NET Component Service, or an EXE? Here we'll write a host program, compile it into an EXE file and demonstrate how the host program reads configuration settings from a file at run time. The code for the host program is listed below. Notice the emboldened line in the code list. By calling RemotingConfiguration.Configure (), the host program reads the server.config configuration file, and registers channels and Remoting objects with the .NET Remoting service according to the settings you put in the configuration file. server.config should be in the same folder as the host EXE file.

    using System;    using System.IO;    using System.Runtime.Remoting;    class Host    {       static void Main(string[] args)       {          RemotingConfiguration.Configure("server.config");          Console.WriteLine("Host is ready.");          Console.WriteLine("Press ENTER to exit.");          Console.ReadLlne();          Console.WriteLine("Exit.");       }    } 

A typical configuration file would be something that looks like the following.

     <configuration>       <system.runtime.remoting>         <application name="HelloService">           <service>             <wellknown mode="SingleCall" type="Bank.Account, Bank"                        objectUri="Account.soap" />           </service>           <channels>             <channel ref="http" port="888" />           </channels>         </application>       </system.runtime.remoting>     </configuration> 

	Team FLY