.NET Remoting is an enabler for application communication. It is a generic system for different applications to use to communicate with one another. .NET objects are exposed to remote processes, thus allowing interprocess communication. The applications can be located on the same computer, different computers on the same network, or even computers across separate networks .
Remoting consists out of the following ellements that are needed:
- One or multiple channels to serve objects on
- Objects that implement or inherit from the MarshalByRefObject class
- Marking objects as Serializable
- A class that manages the networking, though not needed it sure helps reduce complexity
.Net Remoting is not the only method that supports interprocess communication and not the most respected one either. Yet when you are using .Net it is good to take a look at it as it has some major advantages compared to other somewhat older methods. To demonstrate that we will compare a few older methods against .Net Remoting.
Distributed COM ojects
Most older applications use distributed COM, also known as DCOM, to communicate between processes. Though DCOM is stable and the performance is acceptable it uses protocol which make communications across networks (Internet) almost impossible. This is due to the fact that DCOM uses a proprietary binary protocol which not all object models support. This hinders the networking of cross platform applications. A second major draw back is the fact that DCOM requires you to open several ports in a firewall, which will decrease the firewalls effectiveness and increase the danger of connecting to the Internet.
.NET Remoting eliminates the difficulties of DCOM by supporting different transport protocol formats and communication protocols. This allows .NET Remoting to be adaptable to the network environment in which it is being used.
Another good implementation of inter process communication is Web Services, and even though it looks very similar to .Net Remoting there are a few important differences. So why does it look so similar, well .Net Remoting includes Web Services as a possible method for communications. Web Services allow you to exchange messages between applications in a way that is platform, object model and programming language independent.
All communications between the applications occur with the Simple Object Access Protocol(SOAP). Important differences between .Net Remoting and Web Services are:
- Web Services require you to use the HTTP protocols, Remoting allows you to use any protocol
- Web Services work in a stateless model where each call creates a new object for the return. Remoting can create one object per process to handle all the calls.
- Remoting does not require the entire object to be expressed in XML for transferring it across the network. Web Services requires this due to limitations in the SOAP protocol.
So how does .Net Remoting do what the other implementations appear to be unable to do, well it has to do with how Microsoft choose to set the communication up. First of you will never directly get involved in the proxy or how this works, they opted for a Transparent Proxy so we don’t have to worry about it. Our remoted object is in fact a Transparent Proxy that pretends to be whatever Marshalled object we wish it to be (it does have to match the object on the server however!). This Transparent Proxy then connects to an actual proxy for communicating with the appropriate sink.
Note: that there can be various sinks that are passed before ever ariving in a channel, and even then it is possible to bundle channel sinks. For the example and the image on the right I’ve kept it relativly simple.