Remoting
.NET remoting is a technology that allows you to invoke or accessing objects on remote server. For those who are familiar with Java technology, it is called RMI (Remote Method Invocation) in java world.
.NET remoting supports accessing your objects by using HTTP,TCP and IPC channels. Similar with Web Services, .NET remoting also support calling your objects via HTTP protocol. However Web Services provide platform independence and you also get loose coupling between your client server objects which means that easier to deal with versioning issues.
Unlike Web Services, .NET remoting requires both of your client and server objects running on the same .NET Framework version. and it has a tight coupling between client and server because the same object types are shared.
Confuse about which one to choose?. Since this article is about .NET Remoting, I will list down why you should choose .NET remoting for your apps over the Web Services.
1. If you develop application only for internal use and not for public use.
2. If you require faster performance with less overhead.
3. If you transfer large data between your client and server application.
4. Web Services is running on Http protocol and you know that http protocol can go timeout if the
processing time is more than 20 minutes. Although you can override this.
5. If you need to access your objects using protocol other than HTTP or HTTPS.
6. If you need richer object oriented model for your client server apps.
Remote Objects, Clients and Servers.
RemoteObjects is the objects being shared by Client and Server application which can be invoked using protocols that you define. .NET remoting support object invocation via HTTP,TCP and IPC protocols.
Developing .NET remoting application consists of 3 steps.
1. Developing the RemoteObjects (consists of method that you like to invoke on the remote server)
2. Developing the Server Application. (listens on certain port and certain protocol)
3. Developing Client Application. (you can use this apps to invoke server objects where the server application is running)
A pinch over Web services Vs Remoting
Browser-based Web applications, in contrast, are loosely coupled and remarkably interoperable. They communicate using HTTP to exchange MIME-typed data in a wide range of formats. Web services adapt the traditional Web programming model for use from all sorts of applications, not just browser based ones. They exchange SOAP messages using HTTP and other Internet protocols. Because web services rely on industry standards, including HTTP, XML, SOAP and WSD, to expose applications functionality on the Internet, they are independent of programming language, platform and device.
Thanks to Microsoft inventing of ASP.NET Web services and .NET Remoting. Web services infrastructure provides a simple API for Web services based on mapping SOAP messages to method invocations. This is achievable by providing a very simple programming model based on mapping SOAP message exchanges to individual method invocations. The clients of Web services do not have to know anything about the platform, object model, or programming language used to build them and vice versa (i.e. the services also unaware of the clients sending them messages). Only thing is both the parties should follow a protocol on the format of the SOAP message being produced and consumed.
Remoting Architecture:
.NET Remoting provides an infrastructure for distributed objects. It exposes full object semantics of .NET to remote processes using plumbing that is both flexible and extensible. .NET Remoting offers much more complex functionality, including support for passing objects by value or by reference, callbacks, and multiple-object activation and lifecycle management policies. In order to use .NET Remoting, a client needs to be built using .NET
To put in simple words using object references to communicate between server objects and clients is the heart of Remoting. The Remoting architecture, however, provides the programmer with an even simpler procedure. If anyone configures the client properly, we need only to create a new instance of the remote object using new keyword, then client receives a reference to the server object and rest of the things are as usual ( like invoking methods) as the object were in your process though it is running on a separate computer.
Data Marshalling:
How the data is getting marshaled. We discuss the same in below:
Serialization and Metadata:
All distributed communication plumbing ultimately does two things:
- Marshals instances of programmatic data types into messages that can be sent across the network is accomplished using some form of serialization engine or marshaled.
- Provides a description of what those messages look like is achieved through some form of metadata.
For instance, for most DCOM interfaces, the serialization engine was the Type Library Marshaler and type libraries provides the metadata.
The key difference between ASP.NET web services and .NET Remoting is in how they serialize data into messages and the format they choose for metadata.
How .NET Remoting Marshals Data
.NET Remoting relies on the pluggable implementations of the IFormat interface used by the System.Runtime.Serialization engine to marshal data to and from messages. .NET Framework provides two standard formatters
- System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
- System.Runtime.Serialization.Formatters.Soap.SoapFormatter
The BinaryFormatter and SoapFormatter as the name suggest marshal types in binary and SOAP format respectively. For metadata .NET Remoting relies on the CLR assemblies, which contain all the relevant information about the data types they implement and expose it via reflection. The reliance on the assemblies for metadata makes it easy to preserve the full runtime type-system reliability. As a result, when the .NET Remoting marshals data, it includes all of a class's public and private members.
However, as we mentioned above relying on runtime metadata for marshalling also limits the reach of a .NET Remoting system - as Client has to understand .NET constructs in order to communicate with a .NET Remoting endpoint.
Channels
As an addition to the flavor, the .NET Remoting layer supports pluggable channels how messages are sent. There are two standard channels for the message transfer, independent of format (i.e. Binary format or Soap format) both TCP Channel and HTTP Channel provides an implementation for a sender-receiver channel that uses the HTTP protocol to transmit messages.
.NET Remoting Objects
As mentioned above in the state management options, there are three types of objects that can be configured to serve as .NET remote objects. Choose the type of object depending on the requirement of the application.
- 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 limited amount of work. Single Call object are not required to store state information, in fact they cannot hold state information between method calls.
- Singleton Objects : These objects 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.
- Client-Activated Objects : These objects are server-side objects that are activated upon request from the client. 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 by using which proxy is then created. These objects can store state information between method calls for its specific client. Each invocation of "new" returns a proxy to an independent instance of the server type.
