Dynamic insertion of a client channel sink provider

• Download source files - 27 Kb

Introduction

The .NET remoting architecture is world-famous for its flexibility and versatility with
limitations rarely found.

Here is one limitation that I want to point out. Then I will show a workaround, exploiting
the fabulous flexibility of the remoting architecture, by dynamically inserting a client channel sink provider.

The problem: I have two remote services named Knossos and Zakros with channel configuration entries

for Knossos: 

  <channel ref="tcp" port="9000" name = "Two way binary tcp channel">
   <clientProviders>
    <formatter ref="binary"/>
   </clientProviders>
   <serverProviders>
    <formatter ref="binary"/>
   </serverProviders>
  </channel>

and for Zacros:

  <channel ref="tcp" port="9000" name = "Two way soap tcp channel">
   <clientProviders>
    <formatter ref="soap"/>
   </clientProviders>
   <serverProviders>
    <formatter ref="soap"/>
   </serverProviders>
  </channel>

Note that the transport is TCP for either service but the formatting is 'binary' for Knossos and 'soap' for Zakros.

Next comes a client app that can communicate with both Zakros and Knossos. Here is
the channel configuration for the client app,

for Knossos:

  <channel ref="tcp" port="8000" name="Two way binary client tcp channel">
   <clientProviders>
    <formatter ref="binary"/>
   </clientProviders>
   <serverProviders>
    <formatter ref="binary"/>
   </serverProviders>
  </channel>

and for Zakros:

  <channel ref="tcp" port="8080" name="Two way soap client tcp channel">
   <clientProviders>
    <formatter ref="soap"/>
   </clientProviders>
   <serverProviders>
    <formatter ref="soap"/>
   </serverProviders>
  </channel>

Note again that the transport is TCP for either but formatting is binary and SOAP.

There is a single client app that must communicate with Knossos using the TCP-binary channel and with Zakros using the TCP-soap channel. That is the problem. The comunication with Knossos over the TCP-binary channel will work just fine. However, the communication with Zakros over the TCP-soap channel will not work. The reason for this is that the remoting system will pick the first TCP channel from the list of registered channels without
regard to the formatter sink. So, the connection to Zakros does not work because the first TCP channel uses a binary formatter whereas the connection to Zakros requires a soap formatter.

Everything would work just fine if the connection to Zakros was configured as an HTTP-soap channel. But that is not the desired configuartion.

One possible workaround is to dynamically insert the appropriate formatters. We can do this with the help of a custom client sink provider. Here is the class definition.

public class AbstractClientFormatterSinkProvider 
 : IClientFormatterSinkProvider {
 public AbstractClientFormatterSinkProvider() { }
 public AbstractClientFormatterSinkProvider(IDictionary props, 
                                            ICollection providerData) { }

 IClientChannelSinkProvider _nextSinkProvider;
 public IClientChannelSinkProvider Next {
  get { return _nextSinkProvider; }
  set { _nextSinkProvider = value; }
 }

 IClientChannelSinkProvider _transportSinkProvider;
 public IClientChannelSink CreateSink(
  IChannelSender channel,
  String URL,
  Object remoteChannelData) {

  // first save the transport sink provider
  if(_transportSinkProvider == null)
   _transportSinkProvider = _nextSinkProvider;

  String format = remoteChannelData as String;
  if(format == null)
   throw new Exception("Client formatter specification required.");

  // create the appropriate formatter sink provider
  IClientChannelSinkProvider  formatterSinkProvider= null;
  if(String.Compare(format,"binary", true) == 0)
   formatterSinkProvider = new BinaryClientFormatterSinkProvider();
  else
  if(String.Compare(format,"soap", true) == 0)
   formatterSinkProvider = new SoapClientFormatterSinkProvider();
  else
   throw new Exception("Channel data required.");

  // insert it between this provider and the transport provider
  formatterSinkProvider.Next = _transportSinkProvider;
  _nextSinkProvider = formatterSinkProvider;

  return formatterSinkProvider.CreateSink(channel, URL, null);
 }
}

For the remoting system to accept this client channel sink provider the client's config file must be changed like so:

<clientProviders>
 <formatter type="RemotingHelper.AbstractClientFormatterSinkProvider, 
            RemotingHelper"/>
</clientProviders>

This reflects that the assembly 'RemotingHelper.dll' contains the class 'RemotingHelper.AbstractClientFormatterSinkProvider'.

And inside the client app the code connecting to the servers Knossos and Zakros is as follows:

String urlKnossos = "tcp://knossos:9000/KnossosObject.rem";
KnossosObject objKnossos = (KnossosObject)RemotingServices.Connect(
 typeof(KnossosObject), urlKnossos, "binary");
 
String urlZakros = "tcp://zakros:9000/ZakrosObject.soap";
ZakrosObject objZakros = (ZakrosObject)RemotingServices.Connect(
 typeof(ZakrosObject), urlZakros, "soap"); 

The third parameters 'binary' and 'soap' are passed to the provider's CreateSink method as remoteChannelData, providing the necessary information to dynamically insert the appropriate formatter sink provider.