Web hosting servers - CHAPTER 18 THE .NET REMOTING LAYER 573
CHAPTER 18 THE .NET REMOTING LAYER 573 WKO objects are MBR types whose lifetimes are directly controlled by the server s application domain. The client-side application activates the remote type using a friendly, well-known string name (hence the term WKO). The server s application domain allocates WKO types when the client makes the first method call on the object (via the transparent proxy), not when the client s code base makes use of the new keyword or via the static Activator.GetObject() method, for example: // Get a proxy to remote object. This line does NOT create the WKO type! object remoteObj = Activator.GetObject( /* params seen later… */ ); // Invoke a method on remote WKO type. This WILL create the WKO object // and invoke the ReturnMessage() method. RemoteMessageObject simple = (RemoteMessageObject)remoteObj; Console.WriteLine(”Server says: {0}”, simple.ReturnMessage()); The rationale for this behavior? This approach saves a network round-trip solely for the purpose of creating the object. As another interesting corollary, WKO types can be created only via the type s default constructor. This should make sense, given that the remote type s constructor is triggered only when the client makes the initial member invocation. Thus, the runtime has no other option than to invoke the type s default constructor. Note Always remember: All WKO types must support a default constructor! If you wish to allow the client to create a remote MBR object using a custom constructor, the server must configure the object as a CAO. CAO objects are entities whose lifetime is controlled by the client s application domain. When accessing a CAO type, a round-trip to the server occurs at the time the client makes use of the new keyword (using any of the type s constructors) or via the Activator type. Stateful Configuration of WKO Types: Singleton or Single Call? The final .NET design choice to consider with regard to MBR types has to do with how the server should handle multiple requests to aWKO type. CAO types need not apply, given that there is always a one-to-one correspondence between a client and a remote CAO type (because they are stateful). Your first option is to configure aWKO type to function as a singleton type. The CLR will create a single instance of the remote type that will take requests from any number of clients, and it is a natural choice if you need to maintain stateful information among multiple remote callers. Given the fact that multiple clients could invoke the same method at the same time, the CLR places each client invocation on a new thread. It is your responsibility, however, to ensure that your objects are thread-safe using the same techniques described in Chapter 14. In contrast, a single call object is aWKO type that exists only during the context of a single method invocation. Thus, if there are 20 clients making use of aWKO type configured with single call semantics, the server will create 20 distinct objects (one for each client), all of which are candidates for garbage collection directly after the method invocation. As you can guess, single call objects are far more scalable than singleton types, given that they are invariably stateless entities. The server is the entity in charge of determining the stateful configuration of a given WKO type. Programmatically, these options are expressed via the System.Runtime.Remoting.WellKnownObjectMode enumeration: public enum WellKnownObjectMode { SingleCall, Singleton
If you are searching for cheap webhost for your web application, please visit MySQL5 Web Hosting services.