WebReference.com - Part 3 of Chapter 6: Professional C# Web Services, from Wrox Press Ltd (1/5)

[next]

Professional C# Web Services

Activation

[The following is a continuation of our series of excerpts from chapter 6 of the Wrox Press title, Professional C# Web Services.]

So far we have seen different object types and how these remote objects can be activated using the new operator and the Activator class. Depending whether the object type is a well-known object or a client-activated object we can use GetObject() or CreateInstance(). Let us look further into the client side to see what happens on the client that we can also make use of.

RemotingServices.Connect

Instead of using the new operator or the Activator class it is also possible to use the static method Connect() of the class RemotingServices for well-known objects. This method doesn't really instantiate the connection as we maybe would assume from its name. A connection is not needed at this point, but all the information passed here will be used to build up the connection when the first method call is made.

In this code example below, we create a proxy by calling RemotingServices.Connect(). This method requires the type of the remote object as we have seen with the Activator class, and the URL string to the remote object:

static void Main(string[] args)
{
   RemotingConfiguration.Configure("SimpleClient.exe.config");
   MyRemoteObject obj = 
      (MyRemoteObject)RemotingServices.Connect(
      typeof(MyRemoteObject),
      "tcp://localhost:9000/SimpleServer/MyRemoteObject");

Error Messages

If the connection string that is used with the Connect() method is wrong, we get an error the first time that a remote method is called.

The possible error messages we can get are listed here:

SocketException: No such host is known.

This error message occurs when the host name cannot be resolved.
SocketException: No connection could be made because the target machine actively refused it.

If the specified port number is incorrect or the server is not started, we will get this error message.
RemotingException: Object <Name> has been disconnected or does not exist at the server.

This error message occurs if the name of the endpoint is incorrectly specified, or when the leasing time has expired when using a client-activated object.

Proxy

RemotingServices.Connect() defines the connection and creates a proxy. No matter which options are used to create remote objects, it is always a proxy that is created and returned by the creation methods. The proxy looks just like the real object as it has the same public methods; but the proxy just converts the method call to a message so that it can be sent across the network.

We actually create two objects in this case: the transparent proxy and the real proxy. The transparent proxy is the one used by the client. It looks like the remote object with the same public methods. This proxy is created dynamically by reading the metadata of the assembly from the remote object. The transparent proxy itself uses the real proxy to create messages from method calls. The transparent proxy is an instance of the class System.Runtime.Remoting.Proxies.__ TransparentProxy. This class is internal to the mscorlib assembly, so we cannot derive custom proxies from it, and we won't find it in the MSDN documentation.

In the picture below we can see that the client uses the __TransparentProxy. The transparent proxy has the method Hello() because this method is available from the remote object. The transparent proxy creates an object that implements the interface IMessage to pass it to the Invoke() method of the RealProxy. IMessage contains the method name and parameters that can be accessed through the property IMessage.Properties. The real proxy transforms this into an IMethodCallMessage and sends it to the remote object through the channel.

client using transparent proxy

With the utility class RemotingServices we can check if the object really is a proxy to the remote object and not the remote object itself with the static method IsTransparentProxy(). The method RemotingServices.GetRealProxy() returns a reference to the RealProxy class:

MyRemoteObject obj = new MyRemoteObject();
if (RemotingServices.IsTransparentProxy(obj))
{
   Console.WriteLine("a transparent proxy!");
   RealProxy proxy = RemotingServices.GetRealProxy(obj);
}

An example where the method IsTransparentProxy() returns false is the case where the remote object is instantiated locally in the application domain. This would be the case if we do a new of the remote object class inside the server application. No proxy is needed for the server, of course, because it won't need to invoke the object on a different system.

Messages

The proxy deals with messages. All message objects implement the interface IMessage. IMessage contains a dictionary of the method name and parameters that can be accessed through the property IMessage.Properties.

In the namespace System.Runtime.Remoting.Messaging more message interfaces and classes are defined. The interfaces are specialized versions for passing and returning methods for example IMethodMessage, IMethodCallMessage, and IMethodReturnMessage. These interfaces have specialized properties that give faster access to method names and parameters. With these interfaces, it is not necessary to deal with the dictionary to access this data.