Dependency Injection und WCF Service Interface

Home » Dev » Dependency Injection und WCF Service Interface

Dependency Injection und WCF Service Interface

1. April 2015

In diesem Beitrag geht es um das Dependency Injection Pattern und die Fallstricke bei der Verwendung eines WCF Services und dessen Interface als abhängige Komponente. Die Nutzung eines WCF Services in einem Programm, nachdem man sich einen Proxy erzeugt hat, folgt in der Regel dem Schema a) Proxy-Klasse erzeugen, b) Service-Methode aufrufen und c) dann den Channel wieder sauber aufräumen.

var client = new SampleWcfServiceReference.SampleWcfServiceClient("tcpEndpoint");
var message = "DirectServiceCall";
try
{
  var result = client.Method(message);
  client.Close();
}
catch (Exception ex)
{
  client.Abort();
}

Zu beachten ist hier, dass die Methoden Close und Abort durch die Proxy-Klasse, die durch svcutil erzeugt wird, implementiert werden, genauer durch die Basis-Klasse ClientBase<T>. Und im Fehlerfall sollte die Methode Abort aufgerufen werden.

Wird nun in einem Projekt auch das DI-Pattern genutzt und dafür das Castle Windsor Framework verwendet, dann ist im Sinne von Abhängigkeiten der WCF Service eine zu injizierende Abhängigkeit für eine Businesskomponente:

public class LocalBusinessService : ILocalBusinessService
{
  ISampleWcfService _service;
 
  public LocalBusinessService(ISampleWcfService service)
  {
    _service = service;
  }
 
  public void Process(string message)
  {
    …
    var result = _service.Method(message);
    …
  }
}

Das Bootstrapping und die Verwendung sehen wie folgt aus:

var container = new Castle.Windsor.WindsorContainer();
container.Register(Component.For<ISampleWcfService>()
  .ImplementedBy<SampleWcfServiceClient>()
  .DependsOn(Dependency.OnValue("endpointConfigurationName", "tcpEndpoint")));
container.Register(Component.For<ILocalBusinessService>()
  .ImplementedBy<LocalBusinessService>());
var localService = container.Resolve<ILocalBusinessService>(); 
try
{
  localService.Process("CastleWindsorCall");
}
catch (Exception ex)
{
  Console.WriteLine(ex.Message);
}
container.Dispose();

Problem an dieser Stelle ist, dass das Interface nicht die Close und Abort Methoden anbietet und der Lifecycle des Proxy vom DI Container gemanaged wird und somit das Aufräumen des Proxy von diesem vorgenommen wird.

Die Basisklasse BaseClient<T> implementiert auch das IDisposable Interface, welches vom Castle Windsor Container genutzt wird, wenn die Komponente aufgeräumt wird, es wird also ClientBase<T>.Dispose aufgerufen. Innerhalb von Dispose wird die Close Methode aufgerufen. Ist jedoch der CommunicationState Faulted, so wirft die ClientBase<T>.Dispose Methode bzw. die CommunicationObject.Close eine CommunicationObjectFaultedException mit der Nachricht "The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state". Um genau zu sein, tritt dieses Szenario ein, wenn die Kommunikation mit dem WCF Service über net.tcp läuft und die Exception in der Methode keine im Contract definierte FaultException ist. Letztendlich ist dies allerdings sehr unschön, da diese Exception an einer Stelle auftritt, die nicht mehr kontrolliert werden kann. Welche Möglichkeiten gibt es nun, dieses Problem einzufangen?

1. Ansatz: Castle Windsor Möglichkeiten

Für den Abbau von Objekten bietet Castle Windsor bei der Registrierung die Hinterlegung einer Funktion über die OnDestroy Methode an. Allerdings heißt es hier auch im Abschnitt zu IDisposable

„Note that if your class implements IDisposable, then Dispose will automatically be called on the object before your custom destroy function is invoked.”

Damit scheidet dieser Ansatz aus.

2. Ansatz: Wrapping des WebServices-Proxies

Es wird nicht die generierte Service-Proxy als Implementierung des WCF-Interfaces genutzt, sondern eine Klasse, die das WCF-Interface, das IDisposible Interface implementiert und intern die generierte Service-Proxy Klasse nutzt. Die WCF-Interface Methoden werden 1:1 an den Proxy weitergeleitet und im Dispose-Fall wird in Abhängigkeit des CommunicationState Abort oder Close am Proxy aufgerufen.

public class SampleWcfServiceWrapper : ISampleWcfService, IDisposable
{
  readonly SampleWcfServiceClient _client;
  
  public SampleWcfServiceWrapper()
  {
    _client = new SampleWcfServiceClient("tcpEndpoint");
  }
  
  ~SampleWcfServiceWrapper()
  {
    Dispose(false);
  }
  
  public string Method (string message)
  {
    return _client.Method(message);
  }
  
  public void Dispose()
  {
    Dispose(true);
    GC.SuppressFinalize(this);
  }
  
  private void Dispose(bool isDisposing)
  {
    if (isDisposing)
    {
      if (_client.State == System.ServiceModel.CommunicationState.Faulted)
        _client.Abort();
      else
        _client.Close();
    }
  }
}

Das Bootstrapping sieht dann wie folgt aus:

var container = new Castle.Windsor.WindsorContainer();
container.Register(Component.For<ISampleWcfService>()
  .ImplementedBy<SampleWcfServiceWrapper>());
container.Register(Component.For<ILocalBusinessService>()
  .ImplementedBy<LocalBusinessService>());
  
var localService = container.Resolve<ILocalBusinessService>();
try
{
  localService.Process("CastleWindsorCallWithWrapper");
}
catch (FaultException<SampleWcfServiceReference.FaultInformation> ex)
{
  Console.WriteLine(ex.Detail.Message);
}
catch (Exception ex)
{
  Console.WriteLine(ex.Message);
}
  
container.Dispose();

Dieser Ansatz funktioniert wunderbar, doch ist es allerdings mühevoll hier ein Klasse anlegen zu müssen, die mehr oder weniger eine 1:1 Kopie der Proxy-Klasse ist.

3. Ansatz: Bridging Ansatz

Um weniger Code schreiben zu müssen und trotzdem die Sicherheit zu haben, kann ein Bridge Ansatz gewählt werden. Zunächst kann ein generisches Interface definiert werden, welches das WCF-Interface als generischen Parameter hat, dieses Interface als einzige Property anbietet und von IDisposable ableitet.

public interface IWcfServiceBridge<T> : IDisposable
{
    T Interface { get; }
}

Die Implementierung des Interfaces sieht dann wie folgt aus

public class WcfServiceBrigde<T> : IWcfServiceBridge<T> where T : class
{
  private System.ServiceModel.ClientBase<T> _client;
  
  public WcfServiceBrigde(System.ServiceModel.ClientBase<T> client)
  {
    _client = client;
  }
  
  ~WcfServiceBrigde()
  {
    Dispose(false);
  }
  
  public T Interface
  {
    get { return _client as T; }
  }
  
  public void Dispose()
  {
    Dispose(true);
    GC.SuppressFinalize(this);
  }
  
  private void Dispose(bool isDisposing)
  {
    if (isDisposing)
    {
      if (_client.State == System.ServiceModel.CommunicationState.Faulted)
        _client.Abort();
      else
        _client.Close();
    }
  }
}

Zu beachten ist hier, dass im Konstruktor die Basisklasse ClientBase<T> als Parameter erwartet wird, also eine Service-Proxy Klasse. Das Interface wird über die Proxy-Klasse geliefert und die Dispose Methode des IDisposable Interfaces kann auf den CommunicationState des Proxy reagieren. Eine weitere Anpassung ist am lokalen BusinessService noch notwendig, damit dieser nicht mehr das WCF-Interface als Abhängigkeit erwartet, sondern das Bridge-Interface.

public class LocalBusinessServiceUsingBridge : ILocalBusinessService
{
  ISampleWcfService _service;
  
  public LocalBusinessServiceUsingBridge(IWcfServiceBridge<ISampleWcfService> service)
  {
    _service = service.Interface;
  }
  
  public void Process(string message, bool callFaultException)
  {
    …
    var result = _service.Method(message);
    …
  }
}

Bootstrapping und Verwendung dieses Ansatzes sieht wie folgt aus

var container = new Castle.Windsor.WindsorContainer();
container.Register(Component.For<ISampleWcfService>()
  .ImplementedBy<SampleWcfServiceClient>()
  .DependsOn(Dependency.OnValue("endpointConfigurationName", "tcpEndpoint"))
  .Named("SampleService"));
container.Register(Component.For<IWcfServiceBridge<ISampleWcfService>>()
  .ImplementedBy<WcfServiceBrigde<ISampleWcfService>>()
  .DependsOn(Property.ForKey<ClientBase<ISampleWcfService>>().Is("SampleService")));
container.Register(Component.For<ILocalBusinessService>()
  .ImplementedBy<LocalBusinessServiceUsingBridge>());
  
var localService = container.Resolve<ILocalBusinessService>();
try
{
  localService.Process("CastleWindsorCallWithBridge");
}
catch (FaultException<SampleWcfServiceReference.FaultInformation> ex)
{
  Console.WriteLine(ex.Message);
  Console.WriteLine(ex.Detail.Message);
}
catch (Exception ex)
{
  Console.WriteLine(ex.Message);
}
  
container.Dispose();

Fazit

Bei der Verwendung von WCF-Services und dem DI-Pattern ist das Lifecycle Management des DI-Containers zu beachten. Probleme können beim Aufräumen der Komponenten im Container entstehen. Wie sie umgangen werden können, wurde hier gezeigt. Persönlich würde ich den Bridging Ansatz wählen, weil damit kein Nachbau des WCF-Interfaces notwendig ist und dieser Ansatz somit auch stabil gegenüber Änderungen am Interface in der Entwicklungsphase ist.