Introduction to Remoting
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction to Remoting
More and more applications are distributed, and for good reason. Distributed applications have the potential to be more scalable, more available, and more robust. A traditional "monolithic" application could typically only be scaled by scaling the underlying hardware (faster CPU, more memory, etc.). Similarly traditional non-distributed applications had a single point of failure, if either the computer running the application or the connection to the computer failed the application was no longer available. With a distributed application it is possible for portions of the application to pick up the slack left by failed or busy portions of the application. Of course it is important to note that not all distributed applications have these features. But, if making an application distributed gives it the potential for these benefits why are not all applications distributed? The simple answer is that it is still hard to build, debug, and maintain a good distributed application. Microsoft recognized the difficulty in building a distributed application and has designed remoting to help ease some of the problems in implementation.
Just as not all distributed applications are not scalable, available, and robust not all remoting applications are distributed. Indeed the examples that I set forth in this brief article don't pretend to be distributed. It is hoped that you will be able to build upon the concepts in this article to implement a truly distributed application.
Before you can implement a remoting application you need to make some decisions. First, you need to decide on the transport mechanism and you need to decide the data format. By default the .NET Framework provides you with two choices for each. For the transport there is either TCP or HTTP, for the data format there is either binary or SOAP.
A TCP connection is much like a standard TCP/IP socket connection. There is very little overhead for a TCP connection. HTTP is the protocol that is used for serving up Web pages. HTTP follows a command and response model and has more overhead than is required for processing a functionally equivalent TCP command.
The binary data format used by the .NET Framework is very much proprietary to Microsoft and hence can only be considered when both the sender and the receiver of the message are on a platform that supports the .NET Framework. The binary data format is very compact and efficient. SOAP on the other hand is a general purpose XML message protocol that transfers messages and commands via character streams. SOAP messages require more bytes to represent the same data but are more universally understood than binary formatted data.
So there are two transfer mechanisms and two data formats which make four possible combinations to choose from.
As can be seen from the table there is a sort of inverse relationship between compatibility and performance. If you have a strict requirement for speed and throughput then choosing TCP as a transfer mechanism and a binary format makes sense, but you need to be aware that you are limiting the number and types of clients that can easily exchange data with your application.
The next decision that needs to be made before you implement your remoting application is how the remoting application will be activated and how long should it remain active (lifetime). There are two types of remoting applications when it comes to activation, well-known or server activated and client activated.
As the name implies a server activated application is started up by the server. These types of applications are further divided into SingleCall and Singleton applications. A SingleCall application or object is instantiated at the server with each client connection or call and terminated when the call is completed. There is not state maintained between calls to a SingleCall object because the object is built up and torn down with each call. The building of a SingleCall object cannot be controlled with arguments to the constructor, every object is built using the parameter less or default constructor. A Singleton object is only slightly different in that this object is constructed or instantiated at the server upon the first invocation of a method on the object and persists on the server after the method call completes. Thus with a Singleton object it is possible to maintain state between method calls. As with a SingleCall object no arguments or parameters are allowed for the constructor of a Singleton object. A Singleton object by default self-regulates its lifetime by destroying itself after there has been no activity on the object of a configurable length of time.
Finally there is the client activated application or object. These types of objects are instantiated at the server through a proxy object on the client. As long as the client holds reference to the proxy object the object persists on the server and as such can maintain state between method calls. Also the construction of a client activated object is totally controlled by the client and as such parameter less constructors as well as constructors with parameters are allowed. If the client "forgets" to release the proxy object then the lifetime of a client activated object is controlled by the same rules as for a Singleton object.
As can be seen from the table there is sort of an inverse relationship between each object types flexibility and scalability. For this table an object is more "flexible" if it has more options available to it for construction and use. An object is more "scalable" if it does not or it be easily assumed that it does not maintain state and is thus more suited for server-farm type of applications.