Though COM and DCOM are able to provide reusability and a distributed platform, they also suffer from problems of versioning, reference counting, and so on. Microsoft .NET came up with a vision to be more connected than ever. It wanted to deliver software as a “service” and also resolve issues related to COM. The release of .NET was termed as the biggest revolution ever on the Microsoft platform after the introduction of Windows. .NET Remoting is one of the ways to create distributed applications in .NET. Developers now have additional options such as XML web services and service components. Essentially, .NET Remoting takes a lot of lessons from DCOM. It replaces DCOM as the preferred technology for building distributed applications. It addresses problems that have wounded distributed applications for many years (that is, interoperability support, extensibility support, efficient lifetime management, custom hosts, and an easy configuration process).
.NET Remoting delivers on the promises of easy distributed computing by providing a simple, extensible programming model, without compromising flexibility, scalability, and robustness. It comes with a default implementation of components such as channels and protocols, but all of them are pluggable and can be replaced with better options without much code modification. Earlier, processes were used to isolate applications from each other. Each process had its own virtual address space, and the code that ran in one process could not access the code or data of another process. In .NET, one process can now run multiple applications in a separate application domain and thereby avoid cross-process communication in many scenarios. In normal situations, an object cannot access the data outside its application domain. Anything that crosses an application domain is marshaled by the .NET runtime. Not only does .NET Remoting enable communication between application domains, but it also can be extended across processes, machines, and networks. It is flexible in the channels and formatters that can be used and has a wide variety of options to maintain state. Though .NET Remoting provides the best performance and flexibility, it too suffers from some vital pitfalls.
The following are the problems with .NET Remoting:
• .NET Remoting works best when assemblies that define the types that are used to integrate are shared. .NET Remoting works fairly well if there is full control over both ends of the wire. Therefore, it works well in an intranet where you have complete control of the deployment, the versioning, and the testing.
• Practically, .NET Remoting is proprietary to .NET and works seamlessly to exchange data between two .NET applications. It is deeply rooted in the common language runtime (CLR) and relies on the CLR to obtain metadata. This metadata means the client must understand .NET in order to communicate with endpoints exposed by .NET Remoting.
• .NET Remoting requires a big leap between programming at a high level and dropping down into the infrastructure. It’s pretty easy to code .NET Remoting with the available components, but if you want to start learning about adding your own transports, the level of complexity increases. .NET Remoting gives you finer-grained control on each architectural component but also requires a deep knowledge of its architecture.
• .NET Remoting suffers from the issues of load balancing because it is not intelligent enough to shift a request from a busy application server to one that is not as busy.
Source of Information : Apress Pro WCF Practical Microsoft SOA Implementation
.NET Remoting delivers on the promises of easy distributed computing by providing a simple, extensible programming model, without compromising flexibility, scalability, and robustness. It comes with a default implementation of components such as channels and protocols, but all of them are pluggable and can be replaced with better options without much code modification. Earlier, processes were used to isolate applications from each other. Each process had its own virtual address space, and the code that ran in one process could not access the code or data of another process. In .NET, one process can now run multiple applications in a separate application domain and thereby avoid cross-process communication in many scenarios. In normal situations, an object cannot access the data outside its application domain. Anything that crosses an application domain is marshaled by the .NET runtime. Not only does .NET Remoting enable communication between application domains, but it also can be extended across processes, machines, and networks. It is flexible in the channels and formatters that can be used and has a wide variety of options to maintain state. Though .NET Remoting provides the best performance and flexibility, it too suffers from some vital pitfalls.
The following are the problems with .NET Remoting:
• .NET Remoting works best when assemblies that define the types that are used to integrate are shared. .NET Remoting works fairly well if there is full control over both ends of the wire. Therefore, it works well in an intranet where you have complete control of the deployment, the versioning, and the testing.
• Practically, .NET Remoting is proprietary to .NET and works seamlessly to exchange data between two .NET applications. It is deeply rooted in the common language runtime (CLR) and relies on the CLR to obtain metadata. This metadata means the client must understand .NET in order to communicate with endpoints exposed by .NET Remoting.
• .NET Remoting requires a big leap between programming at a high level and dropping down into the infrastructure. It’s pretty easy to code .NET Remoting with the available components, but if you want to start learning about adding your own transports, the level of complexity increases. .NET Remoting gives you finer-grained control on each architectural component but also requires a deep knowledge of its architecture.
• .NET Remoting suffers from the issues of load balancing because it is not intelligent enough to shift a request from a busy application server to one that is not as busy.
Source of Information : Apress Pro WCF Practical Microsoft SOA Implementation
|
|
0 comments
Post a Comment