.NET Remoting

Remoting enables software components to interact across application domains. The components interacting with each other can be in different processes and systems. This enables us to create n-tier Distributed applications. For more details on N-tier Applications see the article on n-tier Applications in this series. In this article we try to explain .NET Remoting in a clear and concise manner

The .NET Remoting Architecture: Here is a simplified illustration of the .NET Remoting Architecture.

The Key Players are:
………..– Client Object
………..– Server (Remote) Object
………..– Proxy Object
………..– Formatter
………..– Channel

Client Object is the object or component that needs to communicate with(call) a remote object.

The Server (Remote) Object receives the request from the client object and responds.

Proxy Object:

When the client object needs to call a method from the Remote Object it uses a proxy object to do this. Every public method that defined in the remote object class can be made available in the proxy and thus can be called from clients. The proxy object acts as a representative of the remote object. It ensures that all calls made on the proxy are forwarded to the correct remote object instance. There are two types of proxies transparent and real proxy

The TransparentProxy contains a list of all classes, as well as interface methods of the remote object. It examines if the call made by the client object is a valid method of the remote object and if an instance of the remote object resides in the same application domain as the proxy. If this is true, a simple method call is routed to the remote object.

If the object is in a different application domain, the call (call parameters on the stack are packaged into an IMessage object) is forwarded to a RealProxy class by calling its Invoke method.
This class is then responsible for forwarding messages to the remote object.

Formatter

The formatting can be done be done in three ways –
………..a) Binary
………..b) SOAP or
………..c) Custom.

The remoting framework comes with two formatters: the binary and SOAP formatters. The binary formatter is extremely fast, and encodes method calls in a proprietary, binary format. The SOAP formatter is slower. Developers can also write their own Custom Formatter and have the ability to use that.

Channels

Channels are used to transport messages to and from remote objects. You can choose a TcpChannel or a HttpChannel or extend one of these to suit your requirements.

HTTP channel : The HTTP channel transports messages to and from remote objects using the SOAP protocol. However, All messages are passed through the SOAP formatter, where the message is changed into XML and serialized, and the required SOAP headers are added to the stream. The resulting data stream is then transported to the target URI using the HTTP protocol.

TCP Channel : The TCP channel uses a binary formatter to serialize all messages to a binary stream and transport the stream to the target URI using the TCP protocol. It is also possible to configure the TCP channel to the SOAP formatter.

Understanding .NET Remoting

.NET Remoting enables software components to interact across application domains. Previously Inter-process Communication between various apps on the Microsoft Platform was widely handled using DCOM. DCOM has its limitations as it relies on proprietary format. Also the difficulty of communication between COM objects spread across firewalls. .NET Remoting eliminates these difficulties as it supports various transport and communication protocols and is adaptable to diverse network environments. It supports state management options. It can correlate multiple calls from the same client and support callbacks. However it relies on the existence of the common language runtime assemblies. Needless to say, it requires the clients be built using .NET. With this background let us explore what it takes to implement .NET Remoting

Implementing .NET Remoting:

Step 1: Create a Remote Object (Server)
There are three types of objects that can be configured to serve as .NET remote objects.

· Single Call
Single Call objects service one and only one request coming in. Single Call objects are useful in scenarios where the objects are required to do a finite amount of work. Single Call objects are usually not required to store state information, and they cannot hold state information between method calls. However, Single Call objects can be configured in a load-balanced fashion.

· Singleton Objects
Singleton objects are those objects that service multiple clients and hence share data by storing state information between client invocations. They are useful in cases in which data needs to be shared explicitly between clients and also in which the overhead of creating and maintaining objects is substantial.

· Client-Activated Objects (CAO)
Client-activated objects (CAO) are server-side objects that are activated upon request from the client. This way of activating server objects is very similar to the classic COM coclass activation. When the client submits a request for a server object using "new" operator, an activation request message is sent to the remote application. The server then creates an instance of the requested class and returns an ObjRef back to the client application that invoked it. A proxy is then created on the client side using the ObjRef. The client’s method calls will be executed on the proxy. Client-activated objects can store state information between method calls for its specific client and not across different client objects. Each invocation of "new" returns a proxy to an independent instance of the server type.

Example:
The following code shows a simple remotable class:

……………………………………………………………………
using System; ……………………………………………………….
namespace RemoteClassLib ……………………………………………..
{ ………………………………………………………………….
…..public class MyRemoteObject : System.MarshalByRefObject ……………..
……….{ …………………………………………………………
……….public MyRemoteObject() ……………………………………..
……….{ …………………………………………………………
……………Console.WriteLine("Constructor called"); ………………….
……….} …………………………………………………………
……………………………………………………………………
……….public string Hello(string name) ……………………………..
……….{ …………………………………………………………
……………Console.WriteLine("Hello Called"); ………………………;
……………return "Hello " + name; ……………………………..;;;;
……….} ……………………………………………………..;;;;
…..} ……………………………………………………..;;;;;;;;;
} ………………………………………………………………….
……………………………………………………………………

Step 1b: Create Remote Config File

……………………………………………………………………
< ?xml version="1.0" encoding="utf-8" ? > ………………………………
…< configuration > …………………………………………………
……< system.runtime.remoting > ……………………………………;;
………< application name="RemoteClassLibServer" > …………………;;;;
…………< service > ……………………………………;;;;;;;;;;;;
……………< wellknown mode="SingleCall" …………………;;;;;;;;;;;;
………………type="RemoteClassLib.MyRemoteObject,ConsoleApplication2" ;;;
………………objectUri="MyRemoteObject" > …………………;;;;;;;;;;
……………< /wellknown > ……………………………………;;;;;;
…………< /service > ……………………………………;;;;;;;;;;;
………< channels > ……………………………………;;;;;;;;;;;;;;
…………< channel ref="tcp server" port="9900"/ > …………………;;;
………< /channels > ……………………………………………..;;
……< /application > ……………………………………………….
…< /system.runtime.remoting > ……………………………………;;;;
…< /configuration >……………………………………………….;;
……………………………………………………………………

Step1 c: Create a host application that hosts the remote object

……………………………………………………………………
using System; ……………………………………………………….
using System.Runtime.Remoting; ………………………………………..
……………………………………………………………………
namespace RemoteClassLibServer ………………………………………..
{ ………………………………………………………………….
…..class RemoteServer ………………………………………………
…..{ ……………………………………………………………..
……….[STAThread] ………………………………………………..
……….static void Main(string[] args) ……………………………..;
………{ ………………………………………………………….
………RemotingConfiguration.Configure( ………………………………
………"RemoteClassLibServer.exe.config"); ……………………………
………Console.WriteLine("Press return to Exit"); ……………………..
………Console.ReadLine(); ………………………..;……………….
………} ………………….;………………….;.;……………….
…..} .;………………..;……………………..;.;……………….
}…….;.;………………………………………;.;……………….
……………………………………………………………………

Step 2: Create a Client Object

……………………………………………………………………
using System; ……………………………………………………….
using System.Runtime.Remoting; ………………………………………..
using System.Runtime.Remoting.Channels; ………………………………..
using System.Runtime.Remoting.Channels.Tcp; …………………………….
……………………………………………………………………
namespace RemoteClassLib ……………………………………………..
{ ………………………………………………………………….
…..public class Client ……………………………………………..
…..{ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
……….public static int Main(string [] args) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
……….{ ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
……………TcpChannel chan = new TcpChannel(); ;;;;;;;;;;;;;;;;;;;;;;;;;;;
……………ChannelServices.RegisterChannel(chan); ;;;;;;;;;;;;;;;;;;;;;;;;
……………MyRemoteObject obj = ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
……………(MyRemoteObject)Activator.GetObject(typeof(MyRemoteObject) ;;;;
……………, "tcp://localhost:9900/MyRemoteObject"); ……………;;;;;;
……………if (obj == null) ………………………………….;;;;;;
……………System.Console.WriteLine("Could not locate server"); ……….
……………else Console.WriteLine(obj.Hello("Developer")); ……………
……………return 0; ……………………………………………..
……….} …………………………………………………………
…..} ……………………………………………………………..
} ………………………………………………………………….
……………………………………………………………………

Passing Objects in Remote Methods & Properties:

1) Objects can be passed from one application to another as parameters in Remote method calls
public int getCustomerInfoRemoteMethod ( Object myObj)
2) Remote Methods can have a return Value as an object
public CustomerObject getCustomerInfoRemoteMethod (int Key)
3) Objects could be passed as values resulting from property or field access of a .NET component
CustomerObject.getAddressObj

Using .NET REMOTING, Objects that are passed between the applications fall into two categories:
……..1) Marshal By Value
……..2) Marshal By reference

In case of Marshal By Value (MBV), a complete copy of the object is made when the object is passed from one application to another. If Marshal By Reference (MBR) is used, then a reference to the object is made when passed from one application to another. When the client application receives object reference (ObjRef), it is turned into a "proxy" back to the original object.

Security Considerations in Serialized objects

.NET remoting infrastructure uses the serialization to pass objects between remote Applications. If left unchecked, this process could be subject to malicious attacks. It is possible to inject a serialized data stream and cause harmful/malicious effects. For example, malicious client-side code can initialize an object that, when de-serialized on the server, causes the server to consume server resources or execute malicious code. To prevent such attacks

1) Remote Objects should not be exposed to the World Wide Web. Expose Remote Objects if the server is accessible from trusted sources only
2) Similarly, Do not use TCPChannel for servers exposed to the internet as this does not have built in authentication mechanisms
3) Use SSL and IIS AUTHENTICATION features of IIS and ASP.NET

Lifetime Management, Lease Configuration:

The period of time that a particular object will be active in memory is defined as a lease. After this the .NET remoting system begins the process of deleting it and reclaiming the memory (i.e. garbage collection). Each application contains a Lease Manager. The lease manager in the server application domain determines when the remote object is marked for garbage collection. The sponsor object can request a new a lease for a particular object by registering itself with the lease manager. Leases can be effectively used to utilize the available resources efficiently. For example, if the resources are scarce you might want to have short leases. If enough resources are available you can have long-term leases and multiple clients can use the object efficiently.

The five main properties of a lease are:
a) Initial Lease: Specifies the initial time span. Default is 5 minutes. Zero indicates an infinite time.
b) CurrentLeaseTime: Indicates the time left on the lease
c) RenewOnCallTime: After each call to the remote object Currentleasetime is set to this figure.
d) SponsorshipTimeout: If the Sponsor object does not respond in this time span it is removed and another sponsor is called. If there are no sponsors the object is marked for deletion.
e) LeaseManagerPollTime: Default value is 10 seconds. By Default, The object manager checks for expired leases every 10 seconds.

To modify these properties you configure the application or machine configuration file as follows:

……………………………………………………………………
< lifetime ………………………………………………………….
…..leaseTime="5M" ………………………………………………….
…..sponsorshipTimeOut="2M" ………………………………………….
…..renewOnCallTime="2M" …………………………………………….
…..leaseManagerPollTime="10S" ……………………………………….
/ >………………………………………………………………..
……………………………………………………………………

The second method to modify these is by overriding the method InitializeLifetimeService

…………………………………………………………………… public class MyObject: MarshalByRefObject { …………………………….
public override Object InitializeLifetimeService() ………………………
…..{ ……………………………………………………………..
……….ILease lease = (ILease)base.InitializeLifetimeService(); ………..
……….if (lease.CurrentState == LeaseState.Initial) { ………………;;
……………lease.InitialLeaseTime = TimeSpan.FromMinutes(1); …….;;;;;;
……………lease.SponsorshipTimeout = TimeSpan.FromMinutes(2); …….;;;;
……………lease.RenewOnCallTime = TimeSpan.FromSeconds(2); …………..
……….} …………………………………………………………
…..return lease; …………………………………………………..
…..} ……………………………………………………………..
}…………………………………………………………………..
……………………………………………………………………

Hosting .NET Remoting Objects

They can be hosted in three different ways
1) Managed Executable: This method implies that you have created .NET EXE or a Service to host the Remote Object
2) IIS: IIS can be used to host the Remote Objects. Configuration needs to be done to set this up.
3) .NET Component Services can also be used to host Remote objects. This would be done to take advantage of the COM+ Services.

Soapsuds:

“Soapsuds.exe” is a tool that helps us compile client applications that communicate with XML Web services using remoting. Soapsuds performs the following functions:
1) It creates XML schemas describing services exposed in an assembly
2) It creates runtime assemblies to access services described by XML schemas
3) A schema definition can be a local file or it can be dynamically downloaded from the Internet.

Examples:
The following command downloads a schema from a URL, generates code, compiles, and generates an assembly.
soapsuds -url:http://localhost/ListService/SomeService.soap?wsdl
-oa:InsuranceQuote.dll

The following command converts a type to a schema, saves it to a file, and generates code. soapsuds -types:MySpecificClass.SomeMethod,SomeService -os:SomeService.xml -gc

Summary:

In this article we studied the .NET Remoting techniques.