CHAPTER 18 THE (Medical web site) .NET REMOTING LAYER 597
CHAPTER 18 THE .NET REMOTING LAYER 597 In either case, if a client or server wishes to revoke sponsorship, it may do so using the ILease. Unregister() method, for example: // Remove the sponsor for a given object. itfLeaseInfo.Unregister(mySponsor); Note Client-side sponsored objects, in addition to implementing ISponsor, must also derive from MarshalByRefObject, given that the client must pass the sponsor to the remote application domain! So, as you can see, the lifetime management of stateful MBR types is a bit more complex than a standard garbage collection. On the plus side, you have a ton of control regarding when a remote type is destined to meet its maker. However, as you may have gathered, there is the chance that a remote type may be removed from memory without the client s knowledge. Should a client attempt to invoke members on a type that has already been removed from memory, the runtime will throw a System.Runtime.Remoting.RemotingException, at which point the client may create a brand-new instance of the remote type or simply take an alternative course of action. Source Code The CAOCarGeneralAsmLease, CAOCarProviderServerLease, and CAOCarProviderClientLease projects are located under the Chapter 18 subdirectory. Alternative Hosts for Remote Objects Over the course of this chapter, you have constructed numerous console-based server hosts, which provide access to some set of remote objects. If you have a background in the classic Distributed Component Object Model (DCOM), this step may have seemed a bit odd. In the world of DCOM, it was not unusual to build a single server-side COM server that contained the remote objects and was also in charge of receiving incoming requests from some remote client. This single *.exe DCOM application would quietly load in the background without presenting a looming command window. When you are building a .NET server assembly, the chances are quite good that the remote machine does not need to display any sort of UI. Rather, all you really wish to do is build a server-side entity that opens the correct channel(s) and registers the remote object(s) for client-side access. Moreover, when you build a simple console host, you (or someone) is required to manually run the server-side *.exe assembly, due to the fact that .NET remoting will not automatically run a server-side *.exe when called by a remote client. Given these two issues, the question then becomes, how can you build an invisible listener that loads automatically? .NET programmers have two major choices at their disposal when they wish to build a transparent host for various remote objects: Build a .NET Windows service application to host the remote objects. Allow IIS to host the remote objects. Hosting Remote Objects Using a Windows Service Perhaps the ideal host for remote objects is aWindows service, given that it Can be configured to load automatically on system startup Runs as an invisible background process Can be run under specific user accounts
We recommend cheap and reliable webhost to host and run your web applications: Coldfusion Web Hosting services.