Forget the DCOM Pain and Use Remoting or Web Services - Questions
(Page 2 of 4 )
Why is DCOM a Pain?
- It is difficult to control format or channel in DCOM
- Trace or log DCOM messages are not an easy practice
- Component technologies are not inter-operating
- There is no quick way to change configuration settings, such as channels or Ports
What are the Similarities and Differences Between .NET Remoting and DCOM?
Both technologies are from two different technology time zones. COM, DCOM and COM+ are based on the COM architecture (VB6, ATL, C++, MFC), and available in the pre–. NET era, while .NET Remoting is primarily based on .NET Frameworks.
DCOM has drawbacks in the internet connected world because DCOM depends on proprietary binary protocol, which is not supported by all object models and compromises with interoperability across platforms and on the internet, an area where DCOM has severe problems. However, DCOM works well when application systems of similar types exist on the same network. Moreover, DCOM is hard to learn and complicated to deploy, to maintain and to explore.
.NET Remoting supports a set of transport and communication protocols and is more adaptable and easy to deploy to network environments and relatively easy to learn and achieve mastery.
DCOM relies on frequent pinging of clients to manage remote object lifetime, where .NET Remoting relies on simple and more efficient leasing mechanisms to maintain object lifetime. DCOM is a closed system, offering little in the way of extensibility, .NET Remoting architecture is much easier to use and extend than DCOM.
Finally, until the arrival of .NET Frameworks, Microsoft's primary protocol for intelligent inter-process communication across systems was Distributed COM. Certainly, DCOM has had some success through pain, and had its day; distributed computing in the Microsoft world will depend on .NET Remoting and Web Services.
When Should One Consider Using .NET Remoting?
When object distance is near. The distance between caller and called must not be considered in the strict geographical sense, however. Here's a list of what makes an object near.
- You're on closely related machines and
- You're in the same organization and
- You're connected reliably and
- You're in the same trust domain and
- You're not interoperating
So the answer is actually quite easy, just remember to ask yourself: Is the remote endpoint near or far? Read this interesting article by Enrico Sabbadin.
How Does Marshalling Work in .NET Remoting?
The process of packing data into a message buffer, prior to transmitting that message buffer over a communication channel (wire) is called Marshalling. There are two different ways to marshal objects: Marshal by value and Marshall by reference.
| Marshal by Value | Marshal by reference |
| The server creates a copy of the object’s state and passes (structure as a method parameter) the copy to the client, which makes a new object based on that state. | The client creates a proxy for the object and then uses proxy to access the object |
| Any changes in the server object will not affect the structure of client. | Any changes made on the remote server side will affect the client's copy |
| To implement Marshal by value, you must either implement the ISerializable interface in your classes, or mark them with the <serializable ()> attribute. | To implement Marshall by reference a class must extend the System.MarshalByRefObject class. |
Next: Questions >>
More Web Services Articles
More By Ahm Asaduzzaman
/ 13 
