Building a Basic .NET Remoting Application 之五 Basic Remoting Task List

.NET remoting is one of several ways to establish communication between application domains using the .NET Framework. You must decide which features your application requires and consider the resources you have at your disposal before choosing a particular development model for your distributed application. For guidance, see Choosing Communication Options in .NET . The following task lists describe the fundamental steps required to build a basic .NET remoting application.

Host Tasks

The following steps are required to publish any service for use from outside your application domain:

1. Design your service.
   1. Choose a host application domain.
   2. Choose an activation model.
   3. Choose a channel and port.
   4. Decide how the client will obtain your service's metadata.
2. Implement your host application domain. Remoting hosts might be Windows Services, console applications, Windows Forms applications, Internet Information Services (IIS) processes, or ASP.NET applications. Requirements for each type of application vary, so you should read the documentation describing how to build the type of application you want to use. For more information, see Building Applications.
3. In the host, configure the remoting system for activation mode and other information, such as application name and endpoint. If you want to programmatically configure the system, you do not need to use a configuration file. If you use a configuration file, you must load that file into the system by calling RemotingConfiguration.Configure.
4. In the host, create the appropriate channel and register it with the system by calling ChannelServices.RegisterChannel. If you use a configuration file, you must load that file into the system by calling RemotingConfiguration.Configure.
5. The host cannot run without the published class, but the way you build your host environment with your service's implementation depends on how you want to share the public interface of your service.

   If you are implementing an XML Web service (using an HttpChannel with the default SOAP serialization), your client can obtain the information in three ways:

   • Using the Soapsuds tool (Soapsuds.exe) to extract the information from the endpoint.
   • Downloading an assembly that contains the metadata.
   • Downloading the source code for an interface.

     Note   Using source code will work in two cases. When using server activation, you can use the source code of an implementation, an abstract class, or an interface only if you compile this code into an assembly that is of the same name as the actual implementation on the server. (Type identity is based on both type name and assembly name.) When using client activation, you must build a class that is outwardly identical with the actual server implementation. Specifically, the client class must be in an assembly of the same name, have the same class declaration, and have members with the same signatures as those on the server. The implementation of the stand-in client class does not matter; if the metadata matches, the remote server will be invoked. Soapsuds.exe builds a stand-in class for your client to save you this work.

   If you are implementing another type of service (for example, using a TcpChannel object) your client can obtain the information in two ways:

   • Downloading an assembly that contains the metadata.
   • Downloading the source code for an interface.

     Note   Using source code will work in two cases. When using server activation, you can use the source code of an implementation, an abstract class, or an interface only if you compile this code into an assembly that is of the same name as the actual implementation on the server, including any versioning information. (Type identity is based on both type name and assembly name information.) When using client activation, you must build a class that is outwardly identical with the actual server implementation. Specifically, the client class must be in an assembly of the same name, have the same class declaration, and have members with the same signatures as those on the server. The implementation of the stand-in client class does not matter; if the metadata matches, the remote server will be invoked.

   In either case, the way you package your service in your own hosting application domain will depend on how you want to publish the metadata necessary for others to consume the service.

Client Tasks

The following basic steps are required to consume any service for use from outside your application domain:

1. Design your client.
   1. Choose a client application domain.
   2. Determine the activation mode and either the client activation URL or the well-known object URL of the remote type.
   3. Consider whether you need to register a channel and port.
   4. Obtain the remote type's metadata.
2. Implement your client application domain. Remoting hosts might be Windows Services, console applications, Windows Forms applications, Internet Information Services (IIS) processes, or ASP.NET applications. Requirements for each type of application vary, so you should read the documentation describing how to build the type of application you want to use. For more information, see Building Applications.
3. Configure the client remoting system with the activation mode and other type information, such as application name and object Uniform Resource Identifier (URI). If you want to programmatically configure the system, you do not need to use a configuration file. If you use a configuration file, you must load that file into the system by calling RemotingConfiguration.Configure.
4. Create the appropriate channel and register it with the system by calling ChannelServices.RegisterChannel. If you use a configuration file, you must load that file into the system by calling RemotingConfiguration.Configure.