Forget the DCOM Pain and Use Remoting or Web Services (Page 1 of 4 )
Microsoft has been singing chore for last few years about building applications with Web Services, and introduced the .NET framework to simplify the show. In this article we will explore the features of .NET Remoting and will explore when Remoting is a better approach over its big brother Web Services and wild sister DCOM. We will keep our discussion as simple as possible. A very basic knowledge of the .NET framework is very important for a better understanding of the topic. The article is developed in a cookbook fashion while the logical sequences of discussion are kept.
What is Remoting?
Microsoft called it DCOM; Object Management Group called it CORBA, Sun named it RMI in Java. So Remoting is nothing but the .NET version of Microsoft’s wild child DCOM. In any operating system processes are isolated by design for security and stability reasons, meaning, one process cannot access code and data of another process. The .NET framework introduced an additional level of this isolation, which is called Application Domains that allow two or more programs to run within the same process, maintaining the same level of isolation, as if they were in separate processes.
So, what is Remoting? Remoting makes available an object in one process to code in another process, these two processes may reside in the same computer, or on two different computers across a LAN, WAN or the internet.
The fact of the matter is .NET framework allows us to easily build Web Services or .NET Remoting applications to communicate across an Application Domain, which has caused a little confusion. Which technology do you need to use? Why not DCOM? Why Remoting? And when do we use Web Services? To really answer these questions, we have to understand how these technologies work.