2..NET Remoting Versus Web Services
3..NET Remoting Architecture
4.Different Types of Remote Objects
5.Remoting Configuration Files
6.Sample Remoting Program
1. Introduction
.Net Remoting enables communication between applications across separate domains or networks. .Net objects are exposed to remote processes to have interprocess communication. With remoting, we can use TCP or HTTP communications protocols on any port. We can use text or binary formatting. .Net Remoting supports server activated (single call and singleton) as well as client activated objects.
2. NET Remoting Versus Web Services
The following list outlines some of the major differences between .NET Remoting and Web services that will help you to decide when to use one or the other:
1. Web services can only be accessed over HTTP whereas .NET Remoting can be accessed over various protocols like TCP, HTTP etc.
2. Web services operate in a stateless environment since its HTTP, a stateless protocol whereas .NET remoting support state management (as in through Singleton and SingleCall objects)
3. Web services are more reliable than .NET Remoting.
4. Web services are easy to create and use while .NET Remoting are complex to be created.
5. Web services support heterogeneous environments i.e. support interoperability across platforms, on the other hand .NET remoting requires client to be built using .NET, thus it does'nt support heterogeneous environment.
6. Web Services support datatypes defined in the XSD type system while .NET remoting provides support for rich type system using binary communication.
State Management
The ASP.NET Web Services model assumes stateless service architecture by default; it does not inherently correlate multiple calls from the same user. In addition, each time a client invokes an ASP.NET Web service, a new object is created to service the request. The object is destroyed after the method call completes. To maintain state between requests, you can either use the same techniques used by ASP.NET pages, i.e., the Session and Application property bags, or you can implement your own custom solution.
.NET Remoting supports a range of state management options and may or may not correlate multiple calls from the same user, depending on what object lifetime scheme you choose. SingleCall objects are stateless (like the objects used to invoke ASP.NET Web services), Singleton objects share state for all clients, and client-activated objects maintain state on a per-client basis (with all the associated scalability and reliability issues this raises).
Performance
In terms of raw performance, the .NET Remoting plumbing provides the fastest communication when you use the TCP channel and the binary formatter. In almost all the tests that we carried out to compare the relative performance of ASP.NET Web services and .NET Remoting, ASP.NET Web services outperformed .NET Remoting endpoints that used the SOAP formatter with either the HTTP or the TCP channel. More interestingly, ASP.NET and .NET Remoting endpoints that used the binary formatter and the HTTP channel were very similar in performance.
3..NET Remoting Architecture
.Net Remoting allows communication between server and client objects. To facilitate this, when new instance of remote object is created in the client application, the client receives reference (called proxy) to the server object. This proxy object contains references to all the methods and properties of the server object. When the client object calls any method (the call actually on proxy object), which resolves the references and invokes server object, receives the result and pass on to the client application.
The methods that will be called from the client are implemented in a remote object class. In the figure below, we can see an instance of this class as the Remote Object. Because this remote object runs inside a process that is different from the client process – usually also on a different system – the client can't call it directly. Instead, the client uses a proxy. For the client, the proxy looks like the real object with the same public methods. When the methods of the proxy are called, messages will be created. These are serialized using a formatter class, and are sent into a client channel. The client channel communicates with the server part of the channel to transfer the message across the network. The server channel uses a formatter to deserialize the message so that the methods can be dispatched to the remote object:
Channels:
Channels are used to establish communications between a .NET Server and a .NET Client. Channels are a means of message communication between a Server and a Client process in .NET Remoting. Each channel is associated with a specific port. The clients access the Remote objects using channels. Channels can be of the following types:
v Http Channel
v TCP Channel
Formatters:
Formatters are responsible for encoding and decoding messages that are transmitted between the server and the client's application domains using these Channels. There are two formatters:
v Binary Formatter
v SOAP Formatter
The respective formatter classes for the above formatters are:
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
System.Runtime.Serialization.Formatters.Soap.SoapFormatter
Life Time of Remote Object
In typical, for the objects that have object references that are transported outside the application, a lease is created. The lease has a lease time; when the lease reaches zero it expires and the object is disconnected from the .NET Remoting Framework. Once all the references to the object within the AppDomain have been freed, the object will be collected when the next garbage collection occurs. The lease controls the lifetime of the object.
To sum up points:
v .NET Remoting favors the runtime type system and provides a more complex programming model with much more limited reach.
v .NET Remoting gives the flexibility to host remote objects in any type of application including a Windows Form, a managed Windows Service, a console application or the ASP.NET worker process. Both the channels (TCP and HTTP) provide communication between sending and receiving processes using sockets.
v .NET Remoting infrastructure is extensible. It can be possible to filter inbound and outbound message, control aspects of type marshaling and metadata generation. It is possible to implement custom formatters and channels using .NET Remoting.
v .NET Remoting, hosted in IIS with ASP.NET can leverage all the security features available to ASP.NET Web Services. If we use TCP or HTTP channel hosted in processes other than aspnet_wp.exe, we have to implement authentication, authorization and privacy mechanisms by our own.
v .NET Remoting supports a range of state management options (depends on object lifetime scheme SingleCall or Singleton objects).
v In terms of performance .NET Remoting provides the fastest communication when we use TCP channel and the binary formatter.
4. Different Types of Remote Objects
In .NET remoting, the remote object is implemented in a class that derives from System.MarshalByRefObject. The MarshalByRefObject class provides the core foundation for enabling remote access of objects across application domains. A remote object is confined to the application domain where it is created. In .NET remoting, a client doesn't call the methods directly; instead a proxy object is used to invoke methods on the remote object. Every public method that we define in the remote object class is available to be called from clients.
Remoting in action:
In .NET Remoting we have three components, a Server class that extends the class MarshalByRefObject, a client class and a proxy. The client does not call a server’s method directly. Instead, it invokes the method on the proxy. The client channel object actually sends a message to the remote channel object. A formatter on the client’s application domain then encodes the message and passes the same through the transport channel onto the server’s application domain. The message is decoded by a formatter on the server’s application domain and then the appropriate server’s method is called on the object being invoked. After the method completes its execution, the results are returned back to the client.
Passing Objects in Remoting
In Remoting, objects are passed from the server to the client or vice-versa using a process known as Marshalling. Marshalling can be of the following two types:
v Marshal by reference
v Marshal by value
In Marshall by reference, a proxy of the server’s object is created in the client’s application domain. In Marshal by value however, the server creates a copy of the remote object and sends the same to the client. In order to implement Marshal by reference, the class should extend the class MarshalByRefObject. To implement Marshal by value however, you should implement the ISerializable interface or specify the keyword Serializable attribute when declaring the class. Marshal by value classes are also known as unbound classes and do not have a remote identity. The MarshalByRefObjects are also known as application domain-bound or context-bound objects.
Activation:
Remote objects can be activated using the new operator. Of course, there are other ways to activate remote objects like Activator.GetObject(), Activator.Createinstance() etc., which will vary according to the activation type.
Activation Types:
There are two types, mainly, server activated types and client activated types.
1. Client-activated objects:
A client-activated object is a server-side object whose creation and destruction is controlled by the client application. An instance of the remote object is created when the client calls the new operator on the server object. This instance lives as long as the client needs it, and lives across one to many method calls. The object will be subject to garbage collection once it's determined that no other clients need it.
2. Server-activated objects:
A server-activated object's lifetime is managed by the remote server, not the client that instantiates the object. This differs from the client-activated object, where the client governs when the object will be marked for finalization. It is important to understand that the server-activated objects are not created when a client calls New or Activator.GetObject. They are rather created when the client actually invokes a method on the proxy.
There are two types of server activated objects.
They are:
Single call :Single-call objects handle one, and only one, request coming from a client. When the client calls a method on a single call object, the object constructs itself, performs whatever action the method calls for, and the object is then subject to garbage collection. No state is held between calls, and each call (no matter what client it came from) is called on a new object instance.
Singleton : The difference in a singleton and single call lies in lifetime management. While single-call objects are stateless in nature, singletons are stateful objects, meaning that they can be used to retain state across multiple method calls. A singleton object instance serves multiple clients, allowing those clients to share data among themselves.
5. Remoting Configuration Files
Both the server and the client channels can be configured programmatically or by using a configuration file.
Using configuration files for Remoting clients and servers has the advantage that the channel and remote object can be configured without changing a single line of code and without the need to recompile. Another advantage is that the Remoting code we have to write is very short. Specifying the options programmatically has the advantage that we could get to the information during runtime. One way to implement this can be that the client uses a directory service to locate a server that has registered its long running objects there.
The server configuration file will look like this.
Then it is considered remote.
Client Configuration file will look like this.
6. Sample Remoting Program
To accomplish this, we will need:
* Creating a remote object ( a type and a host application domain)
* A client application domain
Creating a Remote Object
To create an object, we must declare a remotable class. It is to note that the class has to inherit the MarshalByRefObject. To do this, Open a new project of Class library type. and write the following code, to calculate product of 2 numbers:
using System;
namespace addsubs
{
///
///
public class addsubs : MarshalByRefObject
{
public int product;
public int multiply(int a, int b)
{
product = a * b;
return product;
}
}
}
Now build the project and you will have a DLL generated.
Now to create object of this class remotely, we must build a host application which registers our created class and a channel for remoting. Create it in the same directory where you have addsubs.dll. And compile it to dll our code will be using host.exe.config, so we will need to create it too in the same directory as host.exe. The host.exe.config is as follows:
using System;
using System.Runtime.Remoting;
namespace host
{
public class host
{
public static int Main(string[] args)
{
RemotingConfiguration.Configure("host.exe.config");
Console.WriteLine("Your requests...... Press Enter to exit");
Console.ReadLine();
}
}
}
A Client application domain
Our application must reside in the client application domain to use .NET Remoting system. For this we will create a client.cs and client.exe.config, as we created for the host domain.
Save the above as client.exe.config. Keep a note on the directory where you save these files. You should save the client.exe and the config file in the same directory.
using System;
using System.Runtime.Remoting ;
namespace client
{
public class client
{
public static int Main(string[] args)
{
RemotingConfiguration.Configure("Client.exe.config");
addsubs var = new addsubs();
Console.WriteLine("Enter a Number");
String x = Console.ReadLine();
Console.WriteLine("Enter another Number");
String y = Console.ReadLine();
String z = var.mutiply(Convert.ToInt32(x), Convert.ToInt32(y)).ToString();
Console.WriteLine(z);
}
}
}
To test your application run the client.exe from the command prompt.
No comments:
Post a Comment