HowTo: WCF ClientChannel über Windsor Castle erstellen–WCF & IoC…
Mit WCF zu arbeiten ist einerseits schön, auf der anderen Seite aber auch etwas frustrierend. Positiv ist, dass man durch die ServiceContracts die Services “fast” so behandeln kann wie normale .NET Aufrufe. Es wird aber etwas knifflig, wenn man es nun sich den Proxy für den WCF Aufruf über einen DI (Was ist eigentlich “Dependency Injection/DI”?) Container aufbauen lassen möchte. In diesem Beispiel wird der DI Container Windsor Castle benutzt um diese ServiceContracts richtig aufzulösen..
Anmerkung: Wir hatten in einem Projekt das Problem, dass wir zwar WCF Channels über die ChannelFactory und Windsor Castle aufbauen konnten, diese allerdings nicht wieder sauber schließen konnten. Ein Großteil der Erkenntnisse hier beruhen auf der Arbeit von meinen Kollegen Rico Fritzsche und Oliver Guhr.
Szenario
Dies ist unser Demoprojekt. Es gibt eine Assembly, welche den Contract des Service enthält und die entsprechende Implementierung.
Unser Ziel war es nun den “IService1” in unserem Client Projekt über Windsor Castle nutzbar zu machen.
Der Contract selbst enthält nur eine Methode und die Implementierung ist auch nicht der Rede wert bzw. müsste sogar das WCF Start Template sein.
Client – Projekt: Den WCF Service konsumieren
In meinem Client Projekt gibt es diese Testklasse (samt Interface), welche den IService1 konsumieren möchte.
public interface IFoo
{
void Do();
}
public class Foo : IFoo
{
public IService1 Service1 { get; set; }
public Foo(IService1 srv)
{
this.Service1 = srv;
}
public void Do()
{
Console.WriteLine(this.Service1.GetData(999));
}
}
Die Klasse “Foo” nimmt im Konstruktor den IService1 entgegen. Diese Abhängigkeit wollen wir nun über Windsor Castle reingeben lassen.
Das Problem mit WCF…
An dieser Stelle möchte ich nochmal unser eigentliches Problem erläutern: Da ich hier nur mit dem Interface arbeite, habe ich in der Klasse “Foo” eigentlich auch gar keine Ahnung davon, dass ich überhaupt mit einem WCF Service rede. Das ist besonders dann toll, wenn man Unit-Tests schreiben will.
ABER: Natürlich muss man bei WCF ein paar Sachen beachten. Dazu zählt unter anderem auch die Verbindung, welche ich über mein IoC aufbauen muss, auch wieder abzubauen sollte. Ansonsten bleiben Kanäle offen und irgendwie ist das unschön und auch nicht wirklich sauber.
Die Lösung: Windsor Castle Interceptors für den WCF Channel
Kurzes Vorwort, was eigentlich Interceptors sind: Über Interceptors kann ich bestimmte Aspekte an eine Komponente zusätzlich dran “heften”. Sofern ich es richtig verstanden habe, passiert dies meist über eine Art “Proxy”, welcher sich um die eigentliche Komponente legt. Es gibt allerdings verschiedene Arten. Hier in diesem Blogpost gibt es noch zusätzliche Informationen darüber.
Der Interceptor Code sieht so aus:
public class WcfProxyInterceptor<TService> : IInterceptor
{
public void Intercept(IInvocation invocation)
{
var backendWsHttpBinding = new BasicHttpBinding();
var address = new EndpointAddress("http://localhost:64013/Service1.svc");
var channelFactory = new ChannelFactory<TService>(backendWsHttpBinding, address);
IClientChannel channel = channelFactory.CreateChannel() as IClientChannel;
if (channel != null)
{
try
{
var response = invocation.Method.Invoke(channel, invocation.Arguments);
invocation.ReturnValue = response;
channel.Close();
}
catch (Exception e )
{
channel.Abort();
Console.WriteLine("Error...");
}
}
}
}
Wenn der Interceptor aufgerufen wird, dann wird über die ChannelFactory der WCF Channel für unseren Service geöffnet und die Methode wird über “invocation.Method.Invoke” aufgerufen und am Ende wieder geschlossen. In einem Fehlerfall schließen wir auch die Verbindung entsprechend. Das Ergebnis des Aufrufs wird natürlich als “ReturnValue” sich auch gemerkt.
Castle Windsor Registrierung
Dies registrieren wir nun alles im Windsor Castle Container und schon ist die WCF & IoC Welt wieder im Lot.
IWindsorContainer container = new WindsorContainer(); // Den Interceptor im Container registrieren container.Register(Component.For(typeof(WcfProxyInterceptor<IService1>))); // IFoo samt Implementierung hinterlegen container.Register(Component.For(typeof (IFoo)).ImplementedBy(typeof (Foo))); // Nun dem Container sagen, dass wenn IService1 aufgerufen wird der Interceptor genutzt werden soll container.Register(Component.For<IService1>().Interceptors(InterceptorReference.ForType<WcfProxyInterceptor<IService1>>()).Anywhere);
Resultat
Bei jedem Call des Services wird der Channel neu aufgebaut und wieder geschlossen. Wenn man jedoch viele Service Calls hintereinander macht, bewirkt dies, dass der Channel immer wieder neu aufgebaut werden muss – was in der Regel ca. 10-15ms dauert. Bei jedem “Do()” Aufruf wird der Interceptor neu ausgeführt. Dies kann je nach gebrauch evtl. auf die Performance größte Auswirkungen haben. Hat uns aber (noch) nicht gestört.
var test = (IFoo)container.Resolve(typeof (IFoo));
test.Do();
test.Do();
test.Do();
test.Do();
test.Do();
Gesamter Client Code:
Nochmal der gesamte Code aus dem Client Projekt (+ einer zusätzlichen Dummyklasse zum “Testen”)
namespace Client
{
using System;
using System.ServiceModel;
using System.Threading;
using Castle.Core;
using Castle.DynamicProxy;
using System.Reflection;
using Castle.Facilities.WcfIntegration;
using Castle.MicroKernel.Registration;
using Castle.Windsor;
using Contracts;
class Program
{
static void Main(string[] args)
{
IWindsorContainer container = new WindsorContainer();
container.Register(Component.For(typeof(WcfProxyInterceptor<IService1>)));
container.Register(Component.For(typeof (IFoo)).ImplementedBy(typeof (Foo)));
container.Register(Component.For(typeof(IBar)).ImplementedBy(typeof(Bar)));
container.Register(Component.For<IService1>().Interceptors(InterceptorReference.ForType<WcfProxyInterceptor<IService1>>()).Anywhere);
var test = (IFoo)container.Resolve(typeof (IFoo));
test.Do();
test.Do();
test.Do();
test.Do();
test.Do();
var testBar = (IBar)container.Resolve(typeof(IBar));
testBar.Do();
Console.ReadLine();
}
}
public interface IFoo
{
void Do();
}
public interface IBar
{
void Do();
}
public class Bar : IBar
{
public IService1 Service1 { get; set; }
public Bar(IService1 srv)
{
this.Service1 = srv;
}
public void Do()
{
Console.WriteLine(this.Service1.GetData(999));
}
}
public class Foo : IFoo
{
public IService1 Service1 { get; set; }
public Foo(IService1 srv)
{
this.Service1 = srv;
}
public void Do()
{
Console.WriteLine(this.Service1.GetData(999));
}
}
public class WcfProxyInterceptor<TService> : IInterceptor
{
public void Intercept(IInvocation invocation)
{
var backendWsHttpBinding = new BasicHttpBinding();
var address = new EndpointAddress("http://localhost:64013/Service1.svc");
var channelFactory = new ChannelFactory<TService>(backendWsHttpBinding, address);
IClientChannel channel = channelFactory.CreateChannel() as IClientChannel;
if (channel != null)
{
try
{
var response = invocation.Method.Invoke(channel, invocation.Arguments);
invocation.ReturnValue = response;
channel.Close();
}
catch (Exception e )
{
channel.Abort();
Console.WriteLine("Error...");
}
}
}
}
}
Fazit
Das Ansprechen des Service funktioniert und die Kanäle werden ordentlich wieder geschlossen. Damit sollte Windsor Castle und WCF auch Freunde werden. Natürlich geht ähnliches auch mit Unity und co., solange sie solche “Interceptors” unterstützen.
About the author
Written by Robert Mühsig
Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.
Daniel
8. August 2011
Ihc würde von der Ferne ein “using” oder wenigstens ein try/atch/finally für den channel empfehlen?
Robert Mühsig
9. August 2011
Ein using um WCF Calls soll wohl nicht empfehlenswert sein: http://www.danrigsby.com/blog/index.php/2008/02/26/dont-wrap-wcf-service-hosts-or-clients-in-a-using-statement/.
Ein anderer Post zu dem Thema: http://geekswithblogs.net/SoftwareDoneRight/archive/2008/05/23/clean-up-wcf-clients–the-right-way.aspx