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 substantially. 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.
• 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.
Source of Information : Apress Pro WCF Practical Microsoft SOA Implementation
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 substantially. 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.
• 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.
Source of Information : Apress Pro WCF Practical Microsoft SOA Implementation
|
|
0 comments
Post a Comment