Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
.NET ORPC Options
Version 1.1 of the .NET Framework offers three different technologies to invoke methods on remote objects:
DCOM, Enterprise Services' default remote communication protocol
.NET Remoting
Web services (SOAP)
As we'll see, these technologies have very different features in almost any area you can think about: security, flexibility, support for marshaling by reference objects as parameters, etc. This implies that you cannot blindly select one of the options hoping to swap easily to another one later.
Location transparency is provided (at different degrees) by all these protocols. Nevertheless, when you design real-world applications you must not design with location transparency in mind! The way you implement communication among objects running on the same process (chatty, lot of calls) must be different from the communication you set up with a remote object (which requires fewer, chunky calls). There are plenty of reasons why this is crucial—and we'll cover most of them in this article—but I want to mention here the most important one: performance. A remote call is orders of magnitude slower than a local call.
Location transparency is the devil that brings distributed applications to failure.