Developing Distributed Applications Using .NET Remoting
| A typical large-scale application developed today is often distributed across a set of computers to achieve scalability, reliability, high availability, and efficient usage of resources. Over the past years , a number of protocols and mechanisms have emerged to develop distributed applications. What started as Remote Procedure Calls (RPC) has matured to DCOM (Distributed COM). DCOM allowed COM objects to be "distributed," essentially allowing applications and components across their process and machine boundaries to communicate with each other. Other methods of distribution include CORBA (Common Object Request Broker Architecture), a platform- and language-independent standard for distributed objects and Java RMI (Remote Method Invocation). Microsoft .NET Remoting takes the ease of developing and deploying distributed objects to the next level. Developers will find the new mechanisms for defining and configuring remote objects very straightforward and as simple as it can get; administrators will enjoy the firewall-friendly aspect of .NET Remoting. .NET Remoting provides a pluggable protocol communication layer through the notion of communication channels. Two ready-to-use channels are predefined by the .NET Framework: TCP and HTTP. Apart from that, developers have the flexibility to define their own channels based on their own sets of requirements. .NET Remoting is provided by the System.Runtime.Remoting namespace. It is also important to understand that .NET Remoting is not the only distribution mechanism available in .NET. At the core is the core networking library (provided by the System.Net namespace, reviewed earlier in the chapter), which provides a low-level socket-based interface as a mechanism for distribution. Then, as you will explore in the later part of the book, ASP.NET Web services provide distribution through the use of SOAP/HTTP Web services. .NET Remoting is particularly useful when both the client and server are in your own controlfor instance, within a corporate network. The use of standards-based Web services is typically encouraged when you are interested in extended-enterprise communications. Creating Remote ObjectsTo understand the steps required to create a simple Remote object, first create a class that extends MarshallByRefObject (Listing 4.33). Listing 4.33 Creating a Remote Object using System; namespace hks { public class Hello : MarshalByRefObject { public Hello() { } public String SayHello() { Console.WriteLine("Call made to the Remote Object"); return "Hello .NET Remoting"; } } } Compile the preceding class as a shared library: csc /target:library Hello.cs Hosting Remote ObjectsThe next step is really where most of the work is involved and key remoting concepts are highlighted. To allow remote clients to connect with your object, you need to set up a host environment for the remote object (Listing 4.34). The .NET Framework provides this capability either through the use of XML-based configuration files or by using a set of class libraries. Listing 4.34 Hosting Remote Objects using System; using System.Runtime.Remoting; namespace hks { public class HelloServer { public static void Main() { RemotingConfiguration.Configure("HelloServer.exe.config"); Console.WriteLine("HelloServer Started"); Console.ReadLine(); } } } Listing 4.35 is what the configuration file for this host application looks like. Basically, you define a service that identifies the instantiation mode (Singleton), the remote class (hks.Hello), Assembly (Hello), and a URI to address the remote object (hks.Hello.rem). Next, you define a channel for the distributed communication (in this scenario, HTTP Channel on Port 4444). A complete description of the configuration file's syntax is available at http://msdn.microsoft.com/library/en-us/dndotnet/html/remotingconfig.asp. Listing 4.35 Remoting Configuration File<configuration> <system.runtime.remoting> <application> <service> <wellknown mode="Singleton" type="hks.Hello, Hello" objectUri="hks.Hello.soap" /> </service> <channels> <channel ref="http" port="4444"/> </channels> </application> </system.runtime.remoting> </configuration> After you define the Remoting configuration file, you can start the Remote Server host application. csc HelloServer.cs /r:Hello.dll HelloServer.exe When you start HelloServer you should see a message similar to this: HelloServer Started Accessing Remote ObjectsNow that your remote object is hosted and is ready to use, you need to set up a client that can use this. Similar to the server/host application, remote objects can be created through using the class libraries or again by specifying the remote object locations in a configuration file. Using a configuration file makes it easier to change the channel configuration after the remote objects have been developed. Listing 4.36 is a simple HelloClient that loads the configuration from the HelloClient.exe.config file. Note that after the remote object configuration has been loaded, the object calls can be made to the Remote object, like a local object: Listing 4.36 Accessing Remote Objects using System; using System.Runtime.Remoting; using hks; public class HelloClient { public static void Main() { RemotingConfiguration.Configure("HelloClient.exe.config"); Hello hello = new Hello(); Console.WriteLine(hello.SayHello()); } } Shown in Listing 4.37 is the Remoting Client configuration file that specifies the Remote objects referenced and their associated URLs. Listing 4.37 Remoting Client Configuration File<configuration> <system.runtime.remoting> <application> <client> <wellknown type="hks.Hello, Hello" url="http://localhost:4444/hks.Hello.soap" /> </client> </application> </system.runtime.remoting> </configuration> Note that to compile your Remote Client, you still need to refer to the shared library that provided the definition of the hks.Hello class. (You will take a look at how you can use a utility to dynamically generate the stub in the section that follows .) csc HelloClient.cs /r:Hello.dll Now if you run the HelloClient application, you should see the text "Hello .NET Remoting" displayed. E:\hks\DotNet\Chapter 4\Client>HelloClient Hello .NET Remoting If you look at your HelloServer window, you should see the text "Call was made to the Remote object." This shows that the SayHello call was actually done remotely through the .NET Remoting runtime. E:\hks\DotNet\Chapter 4\Server>HelloServer HelloServer Started Call made to the Remote Object Essentially what happens is that a proxy object is used by the client to connect with the remote object. Even though the proxy object lives at the client, it behaves like a remote object. Using SOAPSuds Utility to Dynamically Create ProxiesMicrosoft provides a utility called SOAPSuds, which helps to compile .NET Remoting Client applications by creating runtime assemblies for the .NET Remote objects. For instance, instead of using the Hello.dll, you can use the SOAPSuds utility to dynamically generate the assembly, which can then be used to link the final client application. soapsuds NoWrappedProxy url:http://localhost:4444/hks.Hello.soap?wsdl outputAssemblyFile:HelloInterfaces.dll After the new assembly is generated, the HelloClient.exe.config file needs to be updated with the new assembly name : <configuration> ... <wellknown type="hks.Hello, HelloInterfaces" url="http://localhost:4444/hks.Hello.soap" /> ... </configuration> Use IIS to Host .NET Remoting ObjectsA key component to using the .NET Remoting functionality is a host application that hosts the remote objects. The .NET Remoting Framework provides the flexibility of hosting Remote objects by managed application, Windows services, COM+ Enterprise Services, and Microsoft IIS (Internet Information Services) Web application server. IIS is typically used to host ASP.NET Web applications and services. However, if HTTP Channel is used as a communication channel for .NET Remoting, IIS can be used as a host for remote objects. Using IIS as the host provides additional capabilities, such as using HTTPS and digital certificates for security as well as centralized management of Remote objects. It also removes the requirement of running separate managed executable hosts for hosting remote objects. To host your remote object in IIS, a couple of simple steps are required:
For instance, for your remote Hello object, Listing 4.38 can be used as the configuration file: Listing 4.38 Using IIS to Host Remote Objects<configuration> <system.runtime.remoting> <application> <service> <wellknown mode="Singleton" type="hks.Hello, Hello" objectUri="hks.Hello.soap" /> </service> <channels> <channel name="MyChannel" ref="http"/> </channels> </application> </system.runtime.remoting> </configuration> Note the obvious omission of the port in the channel specification because the Remote object will use the port associated with the IIS Web server. To use the IIS hosted object, change the Remoting configuration file to point to the IIS URL (Listing 4.39). Listing 4.39 Using Remote Objects Hosted in IIS<configuration> <system.runtime.remoting> <application> <client> <wellknown type="hks.Hello, HelloInterface" url="http://localhost/RemoteHello/hks.Hello.soap" /> </client> </application> </system.runtime.remoting> </configuration> |
