Remoting is the process of programs or components interacting across certain boundaries. These boundaries will often be different processes, different machines, or different contexts within a single process. .NET Remoting provides the foundation for distributed applications. .NET Remoting simply replaces DCOM.
.NET Remoting generally differentiates between remote objects and mobile objects:
Initially, client / server architecture was mostly used for accessing the resources of a remote server. Nowadays, the building of distributed applications has become a lot easier where business applications are distributed across several machines to improve performance, maintainability, and scalability. The following are some of the scenarios where .NET Remoting can be used:
One of the key scenarios for using remoting is the concentration of business logic on one or more centralized servers. This considerably simplifies the maintainability and operability of large scale applications. Changes in the business logic does not mean you have to distribute 1000 copies to all your corporate users; just update the server(s) where business logic is installed.
Security of a corporate database is often of prime importance. This general concept of database security goes directly against connecting the database to a Web server because it would allow hackers easy access to critical data once they seize control of the Web server.
Remoting comes to the help by its ability to introduce a separate middle layer to interact between the Web server and the database. Often, this middle layer is located in the DMZ between two firewalls. Firewall 1 only allows connections from the Web Server to the Application Server (where the middle layer is installed). Firewall 2 only allows connections form the Application Server to the Database Server. A connection from the App Server to the Database Server is secure because the middle layer does not allow the execution of random SQL as it provides an object-oriented access to business logic.
It is not uncommon to find large-scale applications implemented using different platforms, frameworks, and programming languages. For example, ASP, JSP and PHP for Web Applications, VB or JAVA for in-house applications, C++ for server-side logic, and scripting languages for scripts.
Remoting architectures can make integrating these different applications much less difficult. In fact, remoting architectures like CORBA, DCOM, Web Services and .NET Remoting will be an absolute necessity in large-scale enterprise application integration
The following provides a chronological list of the most common remoting architectures used to this day:
Technically, Web Services offer stateless calls to remote components via HTTP with a payload encoded in XML. But contrary to Web Services, .NET Remoting allows you to work with stateful objects. This single fact allows it to be the base for future distributed applications. In addition to the management of stateful object, .NET Remoting offers a flexible and extensible .NET Framework that allows for different transfer mechanisms such as HTTP and TCP, different encodings such as SOAP and binary, and security setting such as IIS and SSL. For example, you can choose SOAP over HTTP for Internet applications, and binary over TCP for intranet applications by literally changing a single line in a configuration file.
Also note that interface description does not have to be encoded in any way (unlike COM), even though it is supported if you like to design your applications that way. Instead, metadata can be extracted from running servers, where the WSDL is automatically generated, or from any .NET assembly.
The .NET Framework provides several options for communication across application domains and process/machine boundaries. This sections discusses some of the options for inter-object communication and in the process shows where .NET Remoting fits. Which option to chooses usually depends on the type of communication you need and which programming model a developer is most familiar with. Here are some criteria to help in choosing the type of communication required:
If you want to secure your calls then you must use an HTTP-based application hosted in IIS, whether it is an ASP.NET application or a Remoting application. In IIS, both ASP.NET and Remoting have all the security features you might need. Using any other protocol, or using the HttpChannel outside IIS will require you to do your security work yourself. Also note that you need not use the SOAP encoding format when using an HTTP connection; you can easily use a binary encoding.
If efficiency of each call is critical, then use binary encoding, even if the default TcpChannel was not used (In Remoting you can use a binary formatter with HttpChannel, and in ASP.NET you can use POST). If you do not have any security issues, then using TcpChannel with binary encoding will be the best option. Else if security and speed is critical, then use a binary encoding with HttpChannel.
If you want to interoperate between different operating systems, you should use the SOAP formatting protocol whether you use ASP.NET or .NET Remoting.
Hosting the application inside IIS gives you the required scalability, whether you use ASP.NET or .NET Remoting
There are several other issues that might be related:
If you build ASP applications and want to the the Web application model and the power of the ASP.NET HTTP runtime, then use XML Web Services build with ASP.NET.
The classes in System.Net can be used to build an entire communication infrastructure from the ground up. You can also use this namespace to build your own protocols and serialization formats that you plug into the remoting infrastructure.
.NET Remoting provides the tools for a number of comprehensive communication scenarios. Using .NET Remoting you can: