Applied XML Programming for Microsoft .NET.pdf - Csbdu.in

SingleCall ObjectsA well-known type declared as a SingleCall object has a new instance of it createdwhenever a request arrives. The host application creates a new instance of theSingleCall object, executes the requested method, and then routes any return valuesback to the client. After that, the object goes out of scope and is left to the garbagecollector.Although it's not completely impossible, preserving state from one call to the next isrealistically a bit impractical for SingleCall objects. In this case, the lifetime of the objectinstance is extremely short and barely covers the duration of the method call. You cantry either storing information in a database (or any sort of persistent storage medium) orparking data in other objects with a different lifetime scheme.Client-Side ActivationClient-activated objects are instantiated on the client as the result of a call to the newoperator or to the System.Activator object. Each remoting client runs its own copy of theobject and can control it at will. For example, the client can use any of the availableconstructors. In addition, persisting the state during the session is straightforward anddoes not require any special coding. On the down side, sharing state between clients isdifficult, and to do so, you must resort to a database, a disk file, or any other globalobject in the current AppDomain.The following code snippet shows how to change the contents of the tag toreflect a client-activated object. Instead of the tag, you use the tag. This tag supports only the type attribute. No object URI is necessarywith client-activated objects. More precisely, the URI is still necessary, but because theactivation occurs on the client and at a very specific moment in time, the URI can besilently generated by the .NET Remoting infrastructure and attached to each call.As with Singleton objects, the lifetime of a client-activated object is controlled by theLM. The instance of the object remains active until the proxy is destroyed.Choosing the Activation Mode That FitsTheoretically, all the working modes examined up to now don't affect in any shape orfashion the way in which you code your remotable classes. For example, a clientactivatedobject is in no way different from a Singleton object. All options can be setdeclaratively and, again speaking theoretically, each object can be configured to workin different ways simply by changing a few entries in the server's configuration file.Intriguing as this possibility is, such flexibility is not realistic in practice because a realworldobject might want to exploit in depth the specific features of a working mode. Inother words, you should thoughtfully and carefully choose the configuration options foryour remote object and then stick to that configuration as long as the user'srequirements are stable. For example, if you determine that the Singleton mode isappropriate for your component, you will probably want to implement an internal statemanagement engine to share some variables. When at a later time you decide to setthe object to work—say, in SingleCall mode—the state management engine issomewhat useless.Let's analyze our ServiceSalesProvider class to determine the most appropriateoptions. To begin, the object needs to query a back-end database (Northwind). Even445