Distributed object technologies allow objects running on a certain machine to be accessed from applications or objects running on other machines. Just as RPC(Remote Procedure Call) makes remote procedures seem like local ones, distributed object technologies make remote objects appear local. DCOM, CORBA, Java RMI .
Though, DCOM is well-equipped to solve complex distributed application problems, it requires significant expertise. We can’t always solve these sorts of problems with wizards and naïve development concepts, but we can do a lot to simplify and consolidate the configuration, programming model, and extensibility of DCOM. This is .NET Remoting’s greatest strength. .NET Remoting greatly simplifies—or better yet, organizes—the approach to creating and extending distributed applications .
Remoting is the process of programs or components interacting across certain boundaries. These contexts will normally resemble either different processes or machines.
In other words, Remoting begins with the class or classes we want to remote. A conventional class can be used only by clients running in the same application domain. A remotable class can be used by clients in other application domains, which can mean other application domains in the client’s process, application domains in other processes, or application domains on other machines.
Why Should We Use .net Remoting ?
Therefore in true sense DCOM is the Predecessor Of .net Remoting .Thus, Let’s have a glance on Advantages of .Net Remoting over DCOM , So far building Distributed Applications are concern , which can be discussed in the following way :
• DCOM is subject to the same limitations of COM’s type system and object-oriented feature constraints. With COM, there’s no implementation inheritance except through constructs such as aggregation and containment. Error handling is limited to return codes because COM doesn’t support exceptions. In Addition to that , COM doesn’t support a number of object-oriented features, such as static modifiers, virtual functions, and overloaded methods. Where as , NET Remoting can use the full power of .NET’s object-oriented features, it supports full implementation inheritance; properties; and static, virtual, and overloaded methods.
• The security model for .NET Remoting systems has changed quite a bit from the complex and highly configurable model of DCOM.
• .NET Remoting is more flexible in terms of activation and deployment options than DCOM.
• DCOM’s reference-counting model is simple in concept, it can be complex, error prone, and poorly configurable in practice. .NET leases and sponsors are easy to use, and they customize both clients and servers and allow them to participate in server lifetime management if desired. As with other .NET Remoting parameters, we can configure object lifetimes both programmatically and via configuration files.
• Remoting can be easily configured by using XML-based files. Using an open standard such as XML for configuration data is a big improvement over using the Windows registry.This ease of configuration simply isn’t possible when using the registry-based configuration of COM objects.
• .NET Remoting meets the interoperability goal by supporting open standards such as HTTP, SOAP, Web Service Description Language (WSDL), and XML. To pass through firewalls, we can plug in an HTTP channel. To communicate with non-.NET clients and servers, a developer can plug in a SOAP formatter. Remoting objects can be exposed as Web Services,. The .NET Remoting Framework and IIS generate Web Service descriptions that we can provide to developers of non-.NET clients so that they can interoperate over the Internet with the .NET remote objects.
Though,we should keep in mind that, .NET Remoting performance differs from DCOM performance when the client and server are on the same machine. The DCOM/COM infrastructure detects that the processes are local and falls back to a pure COM (more optimized communication) method. .NET Remoting will still use the network protocol that it was configured to use (such as TCP) when communicating among application domains on the same machine.
Defining Remoting Architecture
The .NET remoting infrastructure is an abstract approach to interprocess communication. The above figure is an attempt to describe .net remoting as a generic system of Inter process Communication with a high level overview of the Remoting Process. The whole process which is depicted by above diagram can be elucidated in the following manner :
I. If both sides(Server and Client- Side) of the relationship are configured properly, a client merely creates a new instance of the server class. The remoting system creates a proxy object that represents the class and returns to the client object a reference to the proxy.
II. When a client calls a method, the remoting infrastructure handles the call, checks the type information, and sends the call over the channel to the server process.
III. A listening channel picks up the request and forwards it to the server remoting system, which locates (or creates, if necessary) and calls the requested object.
IV. The process is then reversed, as the server remoting system bundles the response into a message that the server channel sends to the client channel.
V. Finally, the client remoting system returns the result of the call to the client object through the proxy.
|
No responses found. Be the first to respond and make money from revenue sharing program.
|