Section 10.7. .NET and Location Transparency

10.7. .NET and Location Transparency

As explained in Chapter 1, a core principle of component-oriented programming is location transparency. Location transparency means that the same client-side code can interact both with local objects and with remote objects, and ideally, the same component can be used either locally or remotely (see Figure 10-3). Put differently, if a component works locally, it should work remotely, and if a client can use a component locally, it should be able to use the component remotely. There should be nothing in the client code pertaining to location. DCOM supported location transparencyas long as the Registry contained the right settings, location transparency was a reality in DCOM. Thus, after dozens of pages analyzing .NET remoting, it's time to ask: does .NET support location transparency, and if so, to what degree?

This section examines location transparency with regard to marshal-by-reference objects only. Both DCOM and .NET allow marshal-by-value objects (although not with the same ease), but marshal-by-value objects clearly don't comply with location transparency in DCOM or in .NET. I also don't think that the location transparency principle on the component side is relevant to singleton or single-call objects. These server-activated components are different by design: a single-call object must manage its state, and a singleton object is bound to a particular single resource. However, the client of a server-activated object can still benefit from location transparency.

As you've seen, there are many ways to achieve the same result in .NET remoting, and the differences are usually a trade-off between flexibility and ease of use. To maximize compliance with location transparency, the host and the client should use configuration files and always load them, even if they don't contain a remoting section. This allows you to modify the component locations and make changes only in the configuration files, similar to making changes in the Registry to modify the locations of DCOM components. The client and the host should avoid explicit channel and object registration, and the client should use new to create remote objects. The result on both the client side and the host side is a single line of code (loading the configuration file):

     RemotingConfigurationEx.Configure( ); 

However, even if the host and the client use configuration files, there are still unavoidable deviations from full compliance with location transparency:

• The remote component must derive from MarshalByRefObject. In .NET (unlike in DCOM), you can't take any component the client uses and access it remotely.

• The remote host must be running before the clients try to connect to it. DCOM, on the other hand, could launch the remote process automatically.

• The client has to provide a sponsor for client-activated objects. DCOM used reference counting instead.

With these constraints in mind, if I were to grade it, I'd give .NET a C in absolute terms on compliance with location transparency.