Introduction
There was a time in the industry of software when the concept "reusability" was often echoed. People began source-level reuse of code. This caused the problem of naming collisions in a lengthy program. The same code was copied and used in several parts of the world. This is where Windows allowed users to share code at the binary level using DLLs making it developer-friendly. An example from what I read from a Microsoft site (long ago and do not ask me for a reference), we use a Microsoft Word document, copy some contents from it and paste it into the Excel document. These are two different Windows applications and programmatically if you have never thought of how it is done before, think about it now. Interesting, isn't it? If you search for it in Google, you will come to understand something about COM components. COM is a three-letter acronym for Component Object Model used in the world of Windows, where binary levels of code are shared in the form of DLLs. Thus, Microsoft paved the way for two different applications in developing nature for the use of the same code when they are converted into binary files. Ok, let us not deviate from the topic, we need to discuss .NET Remoting and web services.
Clear the air and focus here: .NET Remoting
Older operating systems achieved multi-tasking by running processes in parallel without collision. This means that each process will run independently without any collision. This was when .NET Framework was not invented. With the advent of the .NET Framework, we had a tremendous change in technology and Rapid Application Development (RAD). Recent operating systems have processes that combine application domains. An application domain is a runtime representation of a logical process within a physical process. Each process has application domains running in it. In the same way, two Windows applications interact using COM, there is the possibility for these app domains to interact with each other in the same process or different processes. So, how do we do it then? This is where .NET Remoting comes into the picture. .NET Remoting allows two independent application domains to interact among themselves. These interactions are done using two common types of protocols, namely, TCP and HTTP. In TCP the interaction is done in the form of binary files and HTTP makes the interaction to be done in the form of a SOAP stream.
What is .NET Remoting exactly?
.NET Remoting is a framework where you can invoke or consume methods or objects in a remote computer named the server from your computer, the client. We can also perform asynchronous calls in .NET Remoting using callback delegates. These are the advanced concepts from DCOM, COM, and so on.
How to do .NET Remoting
In order to do .NET Remoting, we need to have a server that holds the instance of the Remoting service object and a client that connects to the server to use the Remoting object. There may be more than one client using objects remotely from a server. More than one server cannot be started since there is a common port to listen to remote client applications. The client will not understand the objects in the remote without the use of a proxy class. The proxy classes are used in web services as well. We use a transparent proxy class. When we invoke methods of this proxy, the proxy redirects these calls to a .NET Remoting server. All the .NET Remoting classes inherit from a common class named MarshalByRefObject. All Remoting objects must be inherited from this class. Then, in the server-side classes, we need to use the following keywords: All the Remoting classes and methods are from the namespace system.runtime.Remoting. We need to use RemoteConfiguration.Configure to configure a Remoting server. This configuration is done in the form of an XML file. For example:
RemotingConfiguration.Configure(“severconfigureationfile.config”);
In the configuration XML file, we need to set the type, object URI, and mode of the service call. All these should be included inside a tag and described in the well-known section.
The client-side will be the same with minor changes. This is listed below:
Here, the problem of creating objects is clarified and we must look at how these objects are activated. These objects are activated using server-side activation and client-side activation.
The server-side activation has two steps, namely, singleton and singlecall.
Using a singleton, you can create only one instance of the server object and all other objects created on the client will just be a reference of the single server object. This is useful if you want your application to have state maintenance.
Using singlecall, you can create any number of instances from the server. We can create several instances of the Remoting server easily.
The client activation of objects can also be done as you can create any number of instances from the client and the same will be done in the server. Simply, we can create several instances of the Remoting server.
So far, we have discussed how to create a server object, client object and .NET Remoting works.
We communicate between the client and a remote server. The client will access the server on demand and once it is accessed there is no guarantee that the server object will be released. When you have finished using an object in your .NET application, the .NET Framework runs daemon threads for garbage collection. Here we are using the objects in a remote server. How will the server know that the object from the other application has finished using it? This is a problem and .NET Remoting solves this problem using leasetime, sponsershiptime, renewoncalltime, and leasemanagerpolltime.
Every .NET Remoting object has a lease time of 10 minutes. If the Remoting client is not connected to the server object for more than 10 minutes then the connection between the server and the client will not be maintained. If the client communicates with the server within 10 minutes then a renewal time of two minutes is added for disconnection. In other words, it will wait for 2 minutes extra for each request. We can also set a sponsershiptime, in other words, we can change the 10 minute default time to the time you want to use sponsershiptime. We can also set this time in the server configuration XML file in the tag.
We can hide the implementations of these techniques using interfaces and they will be discussed later or Google for more. This is interesting.
Karthik Muthu KaruppanPosted Apr 23, 2015, 11:23 AM
good
Krishnanand SivarajPosted Apr 21, 2015, 3:31 PM
Thank you :)
Santhakumar MunuswamyPosted Apr 21, 2015, 3:26 PM
Good work
Krishnanand SivarajPosted Apr 21, 2015, 2:31 AM
" IBM COBOL compiler had a dynamic linking feature before Windows existed" I did not know that :(. Thank you Sam for letting me know that. I read more about Microsoft. I appreciate your comments as they are valuable. Thank you all.
NitinPosted Apr 21, 2015, 1:57 AM
Nice
Manoj KulkarniPosted Apr 21, 2015, 1:38 AM
good one
Shubham KumarPosted Apr 21, 2015, 1:17 AM
good explanation
Gowtham RajamanickamPosted Apr 21, 2015, 1:05 AM
goood one
Sam HobbsPosted Apr 21, 2015, 12:47 AM
I suppose it does not matter who paved the way for dynamic linking, which can also be described as multiple applications using the same code as binary files, but I know that the IBM COBOL compiler had a dynamic linking feature before Windows existed. I think young developers do not realize how advanced software was before Windows.