Configuring the Data Library on the Server

To deploy your application as a 3-tier distributed application, you need to make your data library on the server available for invocation by clients, to publish it at the DataLibraryUrl location. You can use any remote invocation mechanism supported by .NET Remoting. The most popular one is the Web service, where the published assembly is placed under IIS (Internet Information Server) control and made available by creating an IIS virtual directory. In this case, remoting uses an HTTP channel and the SOAP protocol. Deploying your data library under IIS, you use a configuration file. A configuration file web.configfor IIS deployment can look, for example, as follows:

<configuration>
  <system.runtime.remoting>
    <application>
      <service>
        <wellknown mode="Singleton" type="Northwind.RemoteService, Northwind" objectUri="ThreeTierServer.soap" />
      </service>
    </application>
  </system.runtime.remoting>
</configuration>

Northwind is the name of your data library assembly.

Northwind.RemoteService is the full name of a class in your data library derived from C1.Data.RemoteDataService. The C1DataObjects Data Project Wizard generates this class automatically. This class is necessary for DataObjects for .NET remoting support. By default, it is empty, just derives from C1.Data.RemoteDataService. If necessary, it can be used for configuring DataObjects for .NET remoting on the client, see below.

ThreeTierServer.soap is the URI (arbitrary string) used to form the DataLibraryUrl string, for example, http://www.mycompany.com/mydatalibrary/ThreeTierServer.soap, where mydatalibrary is the IIS virtual directory containing the data library assembly

Although IIS deployment is the most common, it is by no means the only option. You can host the server instance of your data library in any server host available for remote invocation via .NET Remoting. For example, Tutorial 3 shows how to host it in a Windows application running on the server. Instead of HTPP channels used by Web services, Tutorial 3 uses a TCP/IP channel. The flexibility of DataObjects for .NET remoting mechanism is based on the fact that there is nothing DataObjects for .NET-specific in hosting and configuring a data library on the server; it is all based on the standard .NET Remoting. Use whatever server deployment option and configuration you find necessary, as long as it exposes an object derived from C1.Data.RemoteDataService (Northwind.RemoteService in the example above) as a well-known object type in Singleton mode (see .NET Remoting documentation for a detailed description of well-known objects and activation modes). To register an object type, you can call the RemotingConfiguration.RegisterWellKnownServiceType method (namespace System.Runtime.Remoting), or use a configuration file (in IIS deployment configuration file is the only option).

Normally, DataObjects for .NET remoting does not need configuring on the client. However, if you use a custom remoting configuration on the server that requires configuring the client, you can do that using the ConfigureClient method of the C1.Data.RemoteDataService class. As noted above, in order to allow 3-tier deployment, your data assembly needs to derive a class from RemoteDataService. You can override the virtual ConfigureClient method in that class. The method is called once for the client data library, to give you an opportunity to execute whatever code you need to configure remoting on the client. Another RemoteDataService method that can be used for configuring client is ConfigureProxyObject that is called every time the client creates a proxy object for calling the server. Overriding the ConfigureProxyObject virtual method you can configure remoting on a per-call basis, for every proxy object created, if that is necessary.