Remoting provides you with a number of choices as to the method and configuration of communication used. Configuration areas are the choice of channel, type of hosting application, the activation model, the configuration method, and the method of exposing server metadata to the client application.
The channel is the means of communication used by an application to call to a remote object; the selection is between HTTP and TCP (SMTP doesn't appear to be ready in Beta 2).The HTTP channel is mostly used for Internet communication where firewalls need to be negotiated.The TCP channel has a performance gain by using direct socket connections over an arbitrary port selected by the developer. Both channels use SOAP for communication; the TCP channel defaults to use a faster (but proprietary) binary representation of the SOAP message, whereas the HTTP channel defaults to use the XML standard.The TCP channel can also use the normal XML-formatted SOAP messaging format.
The selection of the hosting application for the remote object is the next choice.A hosting application must be configured to listen on a channel and create the requested object in its own AppDomain when required. In Visual Basic 6, developers often used IIS or COM+ services to host remote objects-the mysterious dllhost.exe that you may see running in your Windows 2000 Task Manager is the hosting application used by COM+.With the .NET Framework, you can still use these hosting services, but you can gain more control by writing your own hosting applications.When creating your own hosting application, as we do in the first example, you may choose from a Console application, Windows Service, or Windows Forms application.
Choice number three is the activation model for the remote object. SingleCall objects are stateless in that they handle only single calls from clients and do not hold state between calls. After the call is handled, the object is discarded. Singleton objects can be shared between multiple clients.They are often used when the resources needed to initialize the object are large and the object's state needs to be preserved between method calls.You need to remember that Singleton objects do have a default lifetime and may be recycled-we'll see later how developers
can control the object's lifetime to suit their needs. Client Activated Objects (CAOs) allows a client application to create a remote instance of the object for exclusive use and to preserve state between remote method calls.
Choice number four is the method of configuring the remote server.The host application can programmatically configure itself on startup or a configuration file can be used. Of course, using an external file to hold remoting configuration data enables changes to be made without a recompile of the source code. The configuration information contains the channel, port, activation model, type name, and assembly name of the object. A Uniform Resource Identifier (URI), which clients use to identify the object, is also specified.
The final choice is how the client obtains the remote object's metadata. Again comparing with Visual Basic 6, a server object's interface definition had to be on the client, either as a type library or an exported MTS package, to enable the client VB code to make the call over DCOM.With remoting, the situation is similar but improved by the .NET Framework's use of metadata.The first method is to set a reference to the remote object's DLL in the client project so that the compiler can extract the metadata.The second method, but only if using the HTTP channel, is to use the soapsuds.exe utility to generate a "proxy" class from the remote object's URI.This proxy class can then be included in the client project and used as if it is a local .NET type. Internally, the proxy class will route the call to the remote object.