SingleCall objects act much like typical Web service objects. Each time a client calls a method on a SingleCall object, an object is created specifically to handle that method call. Once the method call is complete, the object is not reused and is garbage collected by the .NET runtime.

SingleCall objects also work the way a JIT (just-in-time) Activated object does in COM+, and matches the way most people use MTS or COM+ objects. In those environments, good developers typically create a server-side object, make a method call, and then release the object.

These objects must inherit from System.MarshalByRefObject, so they are MBROs. This means that they always run in the AppDomain and Windows process where they are created. If they are created on a server in a host process, then that is where they live and run. Clients interact with them across the network.

The most commonly used type of service object in remoting is the SingleCall object. Not only do these objects provide semantics similar to Web services, MTS, and COM+, they also provide the simplest programming model.

Because an object is created for each method call, these objects are inherently stateless. Even if an object tried to keep state between calls, it would fail because the object is destroyed after each method is complete. This helps ensure that no method call can be affected by previous method calls or contaminate subsequent method calls.

Each method call runs on its own thread (from the .NET thread pool, as discussed in Chapter 26). However, because each method call also gets its own object, there's typically no contention between threads. This means you don't need to worry about writing synchronization or locking code in your SingleCall code.

Because of their automatic isolation, statelessness, and threading simplicity, SingleCall objects are the preferred technology for creating server code in remoting.

Singleton objects are quite different from SingleCall objects. Only one Singleton object exists at a time, and it may exist for a long time and maintain state. All client method calls from all users are routed to this one Singleton object. This means that all clients have equal, shared access to any state maintained by the Singleton object.

These objects must inherit from System.MarshalByRefObject, so they are MBROs. This means that they always run in the AppDomain and Windows process where they are created. If they are created on a server in a host process, then that is where they live and run. Clients interact with them across the network.

As with the SingleCall scenario, all method calls are run on threads from the .NET thread pool. This means that multiple simultaneous method calls can be running on different threads at the same time. As discussed in Chapter 26, this can be complex, as you have to write multithreaded synchronization code to ensure that these threads do not collide as they interact with your Singleton object.

Singleton objects have a potentially unpredictable life span. When the first client makes the first method call to the object, it is created. From that point forward, it remains in memory for an indeterminate period of time. As long as it remains in memory, all method calls from all the clients will be handled by this one object. However, if the object is idle for a long time, then remoting may release it to conserve resources. In addition, some remoting hosts may recycle their AppDomain objects, which automatically causes the destruction of all your objects.

Because of this, you can never be certain that the data stored in memory in the object will remain available over time. This means that any long-term state data must be written to a persistent store such as a database.

Due to the complexity of shared memory, thread synchronization, and dealing with object lifetime issues, Singleton objects are more complex to design and code than SingleCall objects. While they can be useful in specialized scenarios, they are not as widely used as SingleCall objects.

Client-activated (or Activated) objects are different from both SingleCall and Singleton objects. Activated objects are created by a client application, and they remain in memory on the server over time. They are associated with just that one client, so they are not shared between clients. They are stateful objects, meaning that they can maintain data in memory during their lifetime.

These objects must inherit from System.MarshalByRefObject, so they are MBROs. This means that they always run in the AppDomain and Windows process where they are created. If they are created on a server in a host process, then that is where they live and run. Clients interact with them across the network.

A client can create multiple Activated objects on the server. The objects remain on the server until the client releases them or the server Appdomain is reset (which can happen with some types of remoting host). In addition, if the client does not contact the server for several minutes, then the server assumes the client abandoned the objects and it will release them.

Activated objects typically do not have any threading issues. The only way multiple threads will be running in the same Activated object is if the client is multithreaded, and multiple client threads simultaneously make method calls to the same server-side Activated object. If this is the case in your application, then you have to deal with shared data and synchronization issues as discussed in Chapter 26.

While long-lived, stateful, per-client objects can be useful in some specialized scenarios; they are not commonly used in most client/server or n-tier application environments. By storing per-client state in an object on the server, this type of design reduces the scalability and fault tolerance of a system.

While SingleCall, Singleton, and Activated objects are always anchored to the Appdomain, Windows process, and machine where they are created, this is not the case with serializable objects.

Serializable objects can move from machine to machine as needed. The classic example of this is the ADO.NET DataSet, which can be returned as a result of a function on a server. The DataSet physically moves to the client machine, where it can be used by client code. When the client wants to update the DataSet, it simply passes the object to the server as a parameter, causing the DataSet to physically move to the server machine.

These objects do not inherit from System.MarshalByRefObject. Instead, they are decorated with the < Serializable() > attribute and may optionally implement the ISerializable interface. The following is a very basic implementation of a < Serializable() > object:

<Serializable()> _
Public Class Customer
  Private mName As String = ""

  Public Property Name() As String
    Get
      Return mName
    End Get
    Set(ByVal value As String)
      mName = value
    End Set

    Public Sub Load()
      ' Load data here.
    End Sub
End Class

<Serializable()> objects are not anchored to the Appdomain or Windows process where they were created. The remoting subsystem automatically serializes the data of these objects and transfers it across the network to another machine. On that other machine, a new instance of the objects is created and loaded with the data, effectively cloning the objects across the network.

When working with serializable objects, it's typically a good idea to use a SingleCall object on the server to create the serializable object and call any server-side methods (such as ones to load the object with data from a database). The SingleCall object will then return the serializable object to the client as a function result, so the client can then interact with the object. The SingleCall object's method might look like the following:

Public Function GetCustomer(ByVal ID As Integer) As Customer

  Dim cust As New Customer()
  cust.Load(ID)
  Return cust

End Function

The client code might look as follows:

Dim cust As Customer

cust = myService.GetCustomer(123)
TextBox1.Text = cust.Name()

Note that both server and client code have direct, local access to the Customer object, because it is automatically copied from the server to the client as a result of the GetCustomer method call.

Serializable objects can be very useful in many client/server scenarios, especially if the application is created using object-oriented application design principles.

To begin, create the library DLL. This is just a regular Class Library project, so open Visual Studio .NET (Visual Studio) and create a new class library named SimpleLibrary. Remove Class1.vb and add a new class named Calculator.vb. Because you are creating a well-known remoting object, it must inherit from MarshalByRefObject:

Public Class Calculator
  Inherits MarshalByRefObject
End Class

That's really all there is to it. At this point, the Calculator class is ready to be exposed from a server via remoting. Of course, you need to add some methods that clients can call.

Any and all Public methods written in the Calculator class will be available to clients. How you design the methods depends entirely on whether you plan to expose this class as SingleCall, Singleton, or Activated. For SingleCall you know that an instance of Calculator will be created for each method call, so there is absolutely no point in using any class-level variables. After all, they will be destroyed along with the object when each method call is complete.

It also means that you cannot have the client call a sequence of methods on your object. Each method call gets its own object, so each method call is entirely isolated from any previous or subsequent method calls. In short, each method must stand alone.

For illustration purposes, you need to prove that the server-side code is running in a different process from the client code. The easiest way to prove this is to return the thread ID where the code is running. You can compare this thread ID to the thread ID of the client process. If they are different, then you know that the server-side code is actually running on the server (or at least in another process on your machine).

Add the following method:

Public Function GetThreadID() As Integer

  Return Threading.Thread.CurrentThread.ManagedThreadId

End Function

You can add other Public methods as well if you would like, such as the following:

Public Function Add(ByVal a As Integer, ByVal b As Integer) As Integer

  Return a + b

End Function

As this is a Calculator class, it seems appropriate that it should do some calculations. At this point, you have a simple but functional Calculator class. Build the solution to create the DLL. Your remoting host application will use this DLL to provide the calculator functionality to clients.

With the server-side library complete, you can create a remoting host. It is recommended that you use IIS as a remoting host, but it is possible to create a custom host as well. You will use IIS later in the chapter, but for now let's see how you can create a custom host in a Console Application for testing.

The advantage to a custom host is that you can host a remoting server on any machine that supports the .NET Framework. This includes Windows 98 and later. If you use IIS as a host, then you can only host on Windows 2000 and later, which is a bit more restrictive (but not much).

The drawback to a custom host is that it is not as robust and capable as IIS, at least not without a lot of work. For this chapter's example, you are not going to attempt to make your host as powerful as IIS. You will just stick with the basic process of creating a custom host.

Setting Up the Project

Create a new solution in Visual Studio, with a console application named SimpleServer. Because the remoting host will be interacting with remoting, you need to reference the appropriate framework DLL. Use the Add Reference dialog box to add a reference to System.Runtime.Remoting, as shown in Figure 29-3.

Figure 29.3. Figure 29-3

Then, in Module1 you need to import the appropriate namespace:

Imports System.Runtime.Remoting

At this point, you can configure and use remoting. However, before you do that, you need to have access to the DLL containing the classes you plan to expose via remoting — in this case, SimpleLibrary.dll.

Referencing the Library DLL

There are two ways to configure remoting: via a configuration file or via code. If you opt for the configuration file approach, then the only requirement is that SimpleLibrary.dll be in the same directory as your host application. You don't even need to reference SimpleLibrary.dll from the host. However, if you opt to configure remoting via code, then your host must reference SimpleLibrary.dll.

Even if you go with the configuration file approach, referencing SimpleLibrary.dll from the host project enables Visual Studio to automatically keep the DLL updated in your project directory, and any setup project you might create will automatically include SimpleLibrary.dll. In general, it is a good idea to reference the library DLL from the host, and that is what you will do here.

Add a reference to SimpleLibrary.dll by clicking the Browse button in the Add References dialog box and navigating to the SimpleLibraryinRelease directory, as shown in Figure 29-4. Note that if you are running in Debug mode, then you will find the DLL in the Debug folder, rather than the Release folder.

Figure 29.4. Figure 29-4

All that remains now is to configure remoting.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.runtime.remoting>
    <application>
      <!-- The following section defines the classes you're
            exposing to clients from this host. -->
      <service>
        <wellknown mode="SingleCall"
             objectUri="Calculator.rem"
             type="SimpleLibrary.Calculator, SimpleLibrary" />
      </service>

      <channels>
        <channel ref="tcp" port="49341" />
      </channels>

</application>
  </system.runtime.remoting>
</configuration>

<wellknown mode="SingleCall"
     objectUri="Calculator.rem"
     type="SimpleLibrary.Calculator, SimpleLibrary" />

tcp://localhost:49341/Calculator.rem

http://localhost:49341/Calculator.rem

<channels>
  <channel ref="tcp" port="49341" />
</channels>

Sub Main()
  RemotingConfiguration.Configure( _
    AppDomain.CurrentDomain.SetupInformation.ConfigurationFile, False)
  Console.Write("Press <enter> to exit")
  Console.Read()
 End Sub

RemotingConfiguration.Configure( _
  AppDomain.CurrentDomain.SetupInformation.ConfigurationFile)

Sub Main()

  RemotingConfiguration.RegisterWellKnownServiceType( _
    GetType(SimpleLibrary.Calculator), _
    "Calculator.rem", _
    WellKnownObjectMode.SingleCall)

  System.Runtime.Remoting.Channels.ChannelServices.RegisterChannel( _
    New System.Runtime.Remoting.Channels.Tcp.TcpServerChannel(49341), False)
  Console.Write("Press <enter> to exit")
  Console.Read()
End Sub

The final piece of the puzzle is to create a client application that calls the server.

Setting Up the Project

Here is how to create a new Visual Studio solution with a Windows Application named SimpleClient. As discussed earlier, the client needs access to the type information for the classes it wants to call on the server. The easiest way to get this type information is to have it reference SimpleLibrary.dll. Because you will be configuring remoting, you also need to reference the remoting DLL. Then import the remoting namespace in Form1:

Imports System.Runtime.Remoting

Now you can write code to interact with the Calculator class. Add controls to the form as shown in Figure 29-5.

Figure 29.5. Figure 29-5

Name the controls (in order): ConfigureButton, CodeConfigureButton, LocalThreadButton, LocalThread, RemoteThreadButton, and RemoteThread. First, write the code to get the thread ID values for each object:

Private Sub LocalThreadButton_Click( _
  ByVal sender As System.Object, ByVal e As System.EventArgs) _
  Handles LocalThreadButton.Click

LocalThread.Text = CStr(Threading.Thread.CurrentThread.ManagedThreadId)

End Sub

Private Sub RemoteThreadButton_Click( _
    ByVal sender As System.Object, ByVal e As System.EventArgs) _
    Handles RemoteThreadButton.Click

 Dim calc As New SimpleLibrary.Calculator

 RemoteThread.Text = CStr(calc.GetThreadID)

End Sub

Displaying the thread ID of the local process is easily accomplished. More interesting, though, is that your code to interact with the Calculator class does not look special in any way. Where is the remoting code?

This example reflects the idea of location transparency, whereby it is possible to write "normal" code that interacts with an object whether it is running locally or remotely. This is an important and desirable trait for distributed technologies, and remoting supports the concept. Looking at the code you've written, you can't tell whether the Calculator object is local or remoting; its location is transparent.

All that remains is to configure remoting so that it knows that the Calculator object should, in fact, be created remotely. As with the server, you can configure clients either via a config file or through code.

Before you configure remoting, note something important: If remoting is not configured before the first usage of SimpleLibrary.Calculator, then the Calculator object will be created locally. If that happens, then configuring remoting will not help, and you'll never create remote Calculator objects.

To prevent this from happening, you need to ensure that you cannot interact with the class until after remoting is configured. Typically, this is done by configuring remoting as the application starts up, either in Sub Main or in the first form's Load event. In this case, however, you are going to configure remoting behind some buttons, so a different approach is required.

In Form_Load, add the following code:

Private Sub Form1_Load( _
  ByVal sender As System.Object, ByVal e As System.EventArgs) _
  Handles MyBase.Load

  RemoteThreadButton.Enabled = False

End Sub

This prevents you from requesting the remote thread. You won't enable this button until after remoting has been configured through either the config file or code.

Configuring Remoting

To configure remoting via a config file, you first need to add a config file to the project. Use the Project

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.runtime.remoting>
    <application>
      <!-- The following section defines the classes you're
            getting from the remote host. -->
      <client>
        <wellknown mode="SingleCall"
            type="SimpleLibrary.Calculator, SimpleLibrary"
            url="tcp://localhost:49341/Calculator.rem" />
       </client>
    </application>
  </system.runtime.remoting>
</configuration>

In this case, you are using the <client> element, telling remoting that you are configuring a client. Within the <client> block, you define the classes that should be run on a remote server, both wellknown and Activated. In your case, you have a wellknown class:

<wellknown
     type="SimpleLibrary.Calculator, SimpleLibrary"
     url="tcp://localhost:49341/Calculator.rem" />

On the client, you only need to provide two bits of information. You need to tell remoting the class and assembly that should be run remotely. This is done with the type attribute, which specifies the full type name and assembly name for the class, just as you did on the server. You also need to provide the full URL for the class on the server.

You defined this URL when you created the server, though it might not have been clear that you did so. When you defined the class for remoting on the server, you specified an objectUri value (Calculator.rem). In addition, on the server you specified the channel (TCP) and port (49341) on which the server will listen for client requests. Combined with the server name itself, you have a URL:

tcp://localhost:49341/Calculator.rem

The channel is tcp://, the server name is localhost (or whatever the server name might be), the port is 49341, and the object's URI is Calculator.rem. This is the unique address of your SimpleLibrary.Calculator class on the remote server.

As with the server configuration, you might have multiple elements in the .config file, one for each server-side object you wish to use. These can be a mix of <wellknown> and <activated> elements.

With the configuration set up, you just need to tell remoting to read the file. You'll do this behind the ConfigureButton control:

Private Sub ConfigureButton_Click( _
  ByVal sender As System.Object, ByVal e As System.EventArgs) _

Handles ConfigureButton.Click

  RemotingConfiguration.Configure( _
    AppDomain.CurrentDomain.SetupInformation.ConfigurationFile, True)

  ConfigureButton.Enabled = False
  CodeConfigureButton.Enabled = False
  RemoteThreadButton.Enabled = True

End Sub

Once remoting is configured in an application, you cannot configure it again, so you're disabling the two configuration buttons. In addition, you're enabling the button to retrieve the remote thread ID. Now that remoting has been configured, it is safe to interact with SimpleLibrary.Calculator.

The line of code that configures remoting is the same as it was in the server:

RemotingConfiguration.Configure( _
  AppDomain.CurrentDomain.SetupInformation.ConfigurationFile)

Again, you are telling remoting to read your application configuration file to find the < system.runtime.remoting > element and process it.

Configuring Remoting via Code

Another option for configuring remoting is to do it via code. You must provide the same information in your code as you did in the .config file. Put this behind the CodeConfigureButton control:

Private Sub CodeConfigureButton_Click( _
  ByVal sender As System.Object, ByVal e As System.EventArgs) _
  Handles CodeConfigureButton.Click
  RemotingConfiguration.RegisterWellKnownClientType( _
    GetType(SimpleLibrary.Calculator), "tcp://localhost:49341/Calculator.rem")

  ConfigureButton.Enabled = False
  CodeConfigureButton.Enabled = False
  RemoteThreadButton.Enabled = True

End Sub

The RegisterWellKnownClientType method requires that you specify the type of the class to be run remotely, in this case SimpleLibrary.Calculator. It also requires that you provide the URL for the class on the remote server, just as you did in the .config file.

Regardless of whether you do the configuration via code or the .config file, the result is that the .NET runtime now knows that any attempt to create a SimpleLibrary.Calculator object should be routed through remoting, so the object will be created on the server.

Compile and run the application. Try configuring remoting both ways. In either case, you should discover that the local thread ID and the remote thread ID are different, proving that the Calculator code is running on the server, not locally in the Windows application, as shown in Figure 29-6.

Figure 29.6. Figure 29-6

Of course, your specific thread ID values will be different from those shown here. The important point is that they are different from each other, establishing that the local code and remote code are running in different places.

Using IIS as a host is a straightforward exercise. First, create a web project. To do this, create a new solution in Visual Studio with an Empty Web Site template, as shown in Figure 29-7. Name it SimpleHost. When you click OK, Visual Studio will properly create and configure the virtual root on your server.

Figure 29.7. Figure 29-7

The next task is to ensure that the SimpleLibrary.dll is in the bin directory under the virtual root. While you could copy the DLL there by hand, it is often easier to simply add a reference to the DLL from the website. This enables Visual Studio to automatically copy the DLL to the right location, and it has the added benefit that if you create a deployment project, then the DLL will be automatically included as part of the setup.

Add a reference to SimpleLibrary.dll using the Add References dialog box as you did previously in the SimpleServer and SimpleClient projects. This way, Visual Studio will ensure that the DLL is available as needed.

All that remains now is to configure remoting. Within an IIS host, add the < system.runtime.remoting > section to the web.config file. Remoting is automatically configured based on web.config by ASP.NET.

Use the Project

More important, however, add the remoting configuration to the file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.runtime.remoting>
    <application>
      <!-- The following section defines the classes you're
            exposing to clients from this host. -->
      <service>
        <wellknown mode="SingleCall"
             objectUri="Calculator.rem"
             type="SimpleLibrary.Calculator, SimpleLibrary" />
      </service>

    </application>
  </system.runtime.remoting>
</configuration>

An IIS host can only support the HTTP channel. In addition, the port on which the host listens is defined by IIS, not by your configuration file. This means that all you need to do here is define the classes you want to expose to clients. This is done within the <service> element, just like with a custom host. Again, you use a <wellknown> element to define your class:

<wellknown mode="SingleCall"
     objectUri="Calculator.rem"
     type="SimpleLibrary.Calculator, SimpleLibrary" />

The <wellknown> element shown here is the exact same definition used with the custom host, and you'll get the same result.

The primary difference between your custom host and the IIS host is that IIS cannot use the TCP channel, but only uses the HTTP channel. This means that the URL for your server-side class is different:

http://localhost/SimpleHost/Calculator.rem

The channel defines the protocol, which is http://. The server name is localhost (or whatever your server name might be). The virtual root within IIS is SimpleHost, named just as it is with any Web project. Finally, the objectUri value for your class (Calculator.rem) rounds out the URL.

Again, the .rem extension is important. This extension (or the equivalent .soap extension) tells IIS to route the client request to ASP.NET, and it tells ASP.NET to route the request to remoting so it can be properly handled by invoking your Calculator class.

At this point, the remoting host is done and ready to go. Because it is using the HTTP protocol, you can test it with the browser by navigating to the following URL:

http://localhost/SimpleHost/Calculator.rem?wsdl

This should return an XML description of the host service and all the classes exposed from the host.

With a new host set up, you can change the client application to use this IIS host instead of the custom host. To do this, all you need to do is change the URL for the object when you configure remoting.

If you were using the .config file to configure remoting, you would make the following change:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.runtime.remoting>
    <application>
      <!- the following section defines the classes you're
            getting from the remote host ->
      <client>
        <wellknown
             type="SimpleLibrary.Calculator, SimpleLibrary"
             url="http://localhost/SimpleHost/Calculator.rem" />
       </client>
    </application>
  </system.runtime.remoting>
</configuration>

After making this change to App.config, be sure to rebuild the project so Visual Studio copies the new .config file to the bin directory and renames it SimpleClient.exe.config.

When configuring remoting via code, change the code to the following:

Private Sub CodeConfigureButton_Click( _
  ByVal sender As System.Object, ByVal e As System.EventArgs) _
  Handles CodeConfigureButton.Click

  RemotingConfiguration.RegisterWellKnownClientType( _
    GetType(SimpleLibrary.Calculator), _
    "http://localhost/SimpleHost/Calculator.rem")
  ConfigureButton.Enabled = False
  CodeConfigureButton.Enabled = False
  RemoteThreadButton.Enabled = True

End Sub

In either case, you are simply changing the URL, so remoting now routes your calls to the IIS host instead of your custom host.

One thing to note about using IIS as a host is that it always uses the HTTP channel. The HTTP channel defaults to using the SoapFormatter instead of the BinaryFormatter to encode the data sent across the network. While SOAP is a fine format, it is extremely verbose. The BinaryFormatter generates about one-third the number of bytes as the SoapFormatter to send the same data.

As stated, the SoapFormatter class is the default formatter when using an HTTP channel with .NET remoting, and this class serializes any objects that it receives into a SOAP 1.1-compliant text format. The HTTP channel uses the SoapFormatter to serialize the objects that it sends through the channel. After the object is received and serialized into XML, this formatter also adds any appropriate SOAP headers to the message before it is sent through the channel.

Besides the SoapFormatter, the BinaryFormatter class is typically used when sending an object through a TCP network protocol. When objects are sent using the BinaryFormatter, these objects are more compact and therefore require less network utilization.

For production code, it is good practice to use the BinaryFormatter to reduce the amount of data sent across the network and to improve performance. The formatter is controlled by the client, so you need to update the client configuration of remoting.

Change the .config file as follows:

<?xml version="1.0" encoding="utf-8" ?>
     <configuration>
       <system.runtime.remoting>
         <application>
           <!- the following section defines the classes you're
                 getting from the remote host ->
           <client>
             <wellknown
                 type="SimpleLibrary.Calculator, SimpleLibrary"
                 url="http://localhost/SimpleHost/Calculator.rem" />
            </client>
      <!-- use the binary formatter over the
             http channel ->
      <channels>
         <channel ref="http">
          <clientProviders>
            <formatter ref="binary" />
          </clientProviders>
        </channel>
      </channels>
    </application>
  </system.runtime.remoting>
</configuration>

The highlighted XML configures remoting, so when it initializes the HTTP channel, it does so with a BinaryFormatter instead of the default SoapFormatter.

To do the equivalent to the XML configuration in code, you'll want to import two namespaces into Form1:

Imports System.Runtime.Remoting.Channels
Imports System.Runtime.Remoting.Channels.Http

This also requires that the SimpleClient project reference the System.Runtime.Remoting.dll assembly. Do this using the Add References dialog as you did earlier in the SimpleLibrary project.

Then add the following when configuring remoting:

Private Sub CodeConfigureButton_Click( _
  ByVal sender As System.Object, ByVal e As System.EventArgs) _
  Handles CodeConfigureButton.Click

  RemotingConfiguration.RegisterWellKnownClientType( _
    GetType(SimpleLibrary.Calculator), _
    "http://localhost/SimpleHost/Calculator.rem")


  ' Use the binary formatter with the
  ' HTTP channel.
  Dim clientFormatter As New BinaryClientFormatterSinkProvider
  Dim channel As New HttpChannel(Nothing, clientFormatter, Nothing)
  ChannelServices.RegisterChannel(channel)
  ConfigureButton.Enabled = False
  CodeConfigureButton.Enabled = False
  RemoteThreadButton.Enabled = True

End Sub

As with the .config file approach, you're specifically creating the HttpChannel object, specifying that it should use a BinaryFormatter, rather than the default.

At this point, you have explored the basic use of remoting. You have created a library DLL, a client that uses the library DLL, and two different types of remoting hosts, so the library DLL can run on the server.

There are many other facets of remoting to explore, more than what can fit into this single chapter. The remainder of the chapter explores some of the more common features that you might encounter or use in your applications. You will have to take them pretty fast, but the complete code for each is available in the code download for the book, so you can get the complete picture there.

To use this approach, you need to create a new DLL containing interface definitions for your server-side classes and their methods. For instance, in the SimpleInterface project, you have the following interface defined:

Public Interface <code> ICalculator
  Function GetThreadID() As Integer
  Function Add(ByVal a As Integer, ByVal b As Integer) As Integer
End Interface

This interface defines the methods on your Calculator class. You need to update the Calculator class to implement this interface. The SimpleLibrary project must reference the SimpleInterface DLL; then you can do the following in your Calculator class:

Public Class Calculator
  Inherits MarshalByRefObject

 Implements SimpleInterface.ICalculator
 Public Function GetThreadID() As Integer _
   Implements SimpleInterface.ICalculator.GetThreadID

   Return AppDomain.GetCurrentThreadId

 End Function

 Public Function Add(ByVal a As Integer, ByVal b As Integer) As Integer _
   Implements SimpleInterface.ICalculator.Add

      Return a + b

  End Function

End Class

At this point, the SimpleLibrary.Calculator class can be invoked either directly or via the ICalculator interface.

Be sure to rebuild the custom and IIS host projects so that the new SimpleLibrary and the SimpleInterface DLLs are both copied to the host directories. Note that because SimpleLibrary.Calculator is still available natively, your existing client applications (SimpleClient and ActivatorClient) will continue to run just fine.

The InterfaceClient project only references SimpleInterface.dll, not SimpleLibrary.dll. This means that the client machine doesn't need to install SimpleLibrary.dll for the client to run, which means the client has no access to the actual server-side code.

Because you don't have access to the types in SimpleLibrary, you can't use them in your code. The only types you can use come from SimpleInterface. This means that your code to retrieve the remote thread ID is a bit different. To use the custom host, you do the following:

Private Sub RemoteThreadButton_Click( _
  ByVal sender As System.Object, ByVal e As System.EventArgs) _
  Handles RemoteThreadButton.Click

  Dim calc As SimpleInterface.ICalculator

  calc = CType(Activator.GetObject( _
    GetType(SimpleInterface.ICalculator), _
    "tcp://localhost:49341/Calculator.rem"), _
    SimpleInterface.ICalculator)

  RemoteThread.Text = CStr(calc.GetThreadID)

End Sub

Note that the calc variable is now declared as type ICalculator, rather than Calculator. Notice too that you're using Activator.GetType. This is required when using interfaces, because you can't use the New keyword at all. That is, you can't do the following:

calc = New SimpleInterface.ICalculator()

The result is a compiler error because it isn't possible to create an instance of an interface. Therefore, you can't just configure remoting and use location transparency; you must use Activator.GetObject to have remoting create an instance of the object on the server.

Remoting knows how and where to create the object based on the URL you provide. It then converts the object to the right type (SimpleInterface.ICalculator) based on the type you provide in the GetObject call. If the remote object doesn't implement this interface, then you'll get a runtime exception.

To create the proxy DLL, you just run the soapsuds.exe utility with the following command line:

> soapsuds -url:http://localhost/SimpleHost/Calculator.rem?wsdl -oa:SimpleProxy.dll

Note that you are going against the IIS host here because it uses the HTTP protocol. This won't work against your current custom host, as the soapsuds.exe utility doesn't understand the tcp:// prefix. To use this against a custom host, you would have to ensure that the custom host used the HTTP protocol.

The code download includes a ProxyClient project, which is a Windows application that references only SimpleProxy.dll. There is no reference to SimpleLibrary.dll or SimpleInterface.dll — this client relies entirely on the generated proxy assembly to interact with the server.

The best part of this is that the generated proxy contains the same namespace and class names as the service on the server. In other words, it appears that you are working with SimpleLibrary.Calculator because the proxy is set up with that same namespace and class name. To get the remote thread ID, write the following code:

Private Sub RemoteThreadButton_Click( _
  ByVal sender As System.Object, ByVal e As System.EventArgs) _
  Handles RemoteThreadButton.Click

  Dim calc As New SimpleLibrary.Calculator()
  RemoteThread.Text = CStr(calc.GetThreadID)

End Sub

Note that this is the same code used in the original simple example. You've come full circle at this point, but now the client application doesn't directly reference your library DLL.