The term object remote procedure call (ORPC) identifies those technologies (protocols, API, and so on) that let you create objects on remote computers and invoke methods on them. The .NET Framework offers three distinct ORPC technologies whose functionalities partially overlap, at least at first sight. In this tip, I'll illustrate what these three options are about.
Version 1.1 of the .NET Framework offers three different technologies to invoke methods on remote objects:
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... 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.
DCOM was the only Microsoft ORPC available in the pre–.NET era, available first with Windows NT 4. DCOM enabled remote communication among COM objects. Microsoft Transaction Server (MTS) and COM+ showed up later, MTS with the Windows Option Pack and COM+ with Windows 2000. MTS and COM+ introduced a new set of interception-based services that programmers could use when developing enterprise applications: object pooling, declarative transactions, and queued components, to name a few. To gain access to such services, COM comp
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
onents had to be deployed in COM+ applications (or MTS packages when running on Windows NT 4). COM+ applications came in two flavors: Library and Server applications. COM components deployed in a Server application can be created and invoked remotely using DCOM; all you need to do is run the Server application proxy MSI package on the client machine.
.NET components gain access to COM+ services if they inherit from the Framework-provided class named ServicedComponent, but they have to be registered in a COM+ Server or Library application as well to enable the required services (specified via .NET attributes). When the .NET component is deployed in a Server COM+ application, you can reach it remotely via DCOM by following the same export procedure required for COM-based components. Note, however, that you can use COM+ services (renamed Enterprise Services in .NET terminology) without bringing DCOM into the scene. This happens if you don't need interprocess/intermachine communication or if you choose .NET Remoting to make the ServicedComponent-derived object available across machine boundaries.
.NET Remoting is the new .NET remote protocol. Classes that must be made accessible over the network via .NET Remoting must inherit from the MarshalByRef class. The ServicedComponent class inherits from MarshalByRefObject. This is why you can expose a ServicedComponent class via Remoting. In this case, you obviously deploy the ServicedComponent in a Library application.
Web services use the Simple Object Access Protocol (SOAP) to invoke objects remotely. SOAP packages the messages going back and forth between the client and the server using XML. SOAP doesn't mandate a specific transport protocol, but the preferred one is HTTP 1.1. SOAP also doesn't cover issues such as security or transactions. Such specs are currently being developed by the W3C and WS-I.
To read the rest of the article from which this tip is excerpted, click over to InformIT. No registration required, no fuss, no muss. Just good info.
