Introducing the Microsoft Remote Object Invocation Model
Microsoft started its remote invocation technologies with Distributed Component Object Model (DCOM), which extended Component Object Model (COM). Then, .NET introduced technologies such as .NET Remoting and XML web services. We'll now cover these technologies in bit more detail.
Introducing COM and DCOM
Microsoft developed COM to enable applications to interact with each other and to promote reusability. COM is the set of specifications that, when followed, allows software components to communicate with each other. Each component exposes its functionality through an interface and is uniquely identified by global unique identifiers (GUIDs). The advantage of using COM is that different components developed in different languages can write these software components and interact with each other by using IUnknown and other standard COM interfaces. Most of Microsoft's products, including Microsoft Office, SQL Server, and even Windows, are based on COM. Though COM provides the ability to reuse the components locally, it was not designed to work well with remote components.
Few specifications and extensions had been made that were based on COM and that interacted with remote components. However, the need for remote method invocations grew sub-stantially. To solve this concern, Microsoft developed DCOM. This essentially is a combination of COM and the network protocol that allows you to run a COM object on a remote computer. DCOM was a proprietary wire-protocol standard from Microsoft to extend COM so it could work in distributed environments. DCOM provides an opportunity to distribute your component across different locations according to the application requirements. In addition, DCOM provides basic infrastructure support such as reliability, security, location independence, and efficient communication between COM objects that are residing across processes and machines.
|
The following are the problems with DCOM:
DCOM and other distributed technologies such as CORBA, RMI, and so on, are based on several assumptions. One of the key assumptions is that one organization will manage all the components in the systems that are interacting with each other. Another is that the location of a component will not vary from one place to the other. This scenario can work fine within an organization, but as you cross organization boundaries, the limitations of DCOM become more significant.
Microsoft has invested a lot in DCOM to ensure that calling a remote method is as simple as calling the local component by simplifying the low-level network communication requirements. Most of the time this resulted in bad programming practices by programmers, which resulted in increased network traffic and performance bottlenecks.
DCOM, being based on a proprietary standard, was essentially built taking only the Windows operating systems into account, making it not suited for heterogeneous environments.
Another issue with DCOM is that its client is tightly coupled with the server, so any changes done on the client mandate a modification on the server.
DCOM, like other distributed technologies, is based on two-tier architecture and suffers from some of the same flaws of two-tier architecture.yl
DCOM came before the computer world experienced the Internet boom. DCOM was never built with the Internet in mind. System administrators need to compromise the security of the firewall in order to use DCOM across firewalls/locations. DCOM is used to communicate through ports that are generally restricted by firewalls because the ports are susceptible to attacks.
Introducing .NET Remoting
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.