nServiceBus: de servicebus voor puristen?

Sectie: .Net
Auteur(s): Roy Cornelissen
Publicatiedatum: 4-3-2010
Keywords: nServiceBus, service bus, SOA, .NET, Publish/Subscribe
Type bijdrage: Artikel
Taal: Nederlands
Rating:

Currently 4/5 Stars.
1
2
3
4
5

nServiceBus: de servicebus voor puristen?

In een Service Oriented Architecture (SOA) speelt de Service Bus een belangrijke rol. Voor de invulling van die Service Bus zijn uiteenlopende oplossingsrichtingen mogelijk. In dit artikel ga ik in op de oplossing die nServiceBus biedt. nServiceBus is een open source initiatief van de Israelische architect Udi Dahan, die aan de slag is gegaan met zijn ideaalbeeld voor een SOA in een .NET wereld. Inmiddels hebben anderen zich bij hem aangesloten om het product verder uit te bouwen. nServiceBus is gratis en kan worden gedownload vanaf http://www.nServiceBus.com.

Het begrip SOA is veelomvattend en te groot om in dit artikel te behandelen. Ik ga in dit artikel uit van de interpretatie van SOA die is gehanteerd bij het maken van nServiceBus. Aan het eind van dit artikel vind je een link naar de architectuurprincipes van nServiceBus en de interpretatie van SOA dat Udi Dahan hierbij voor ogen heeft.

De Service Bus

Wat is eigenlijk een service bus? Waar men het in ieder geval over eens is, is dat de Service Bus ervoor zorgt dat alle services in een architectuur met elkaar kunnen communiceren op een eenduidige en gestructureerde manier. In Figuur 1 zien we een traditionele weergave van de Service Bus in een voorbeeldarchitectuurplaatje: een centrale eenheid waaraan alle services zijn verbonden en waarmee ze communiceren. De architectuur in Figuur 1 is die van een fictieve verzekeraar.

Figuur 1: De Service Bus speelt een centrale rol in een SOA

De invulling van het begrip blijkt in de praktijk voor vele interpretaties vatbaar, uiteenlopend van een compleet product tot slechts een concept.

Een Service Bus als product, vaak “ESB” of “Enterprise Service Bus” genoemd, heeft het imago van een magische doos, die door dure consultants moet worden geïnstalleerd en geconfigureerd. Zo’n ESB vervult vaak ook een rol als process engine, waarbij processturing (workflow, BPM) en routering allemaal door het product worden ingevuld. Het gevaar ligt op de loer om bij een ESB als eerste te denken aan een dergelijk product.

Een Service Bus als product, vaak “ESB” of “Enterprise Service Bus” genoemd, heeft het imago van een magische doos

In mijn ervaring en optiek is dit niet wat een Service Bus zou moeten zijn. Met name als er ook aan processturing en routering wordt gedaan, dan komt er ineens wel heel veel business logica en kennis in die bus te liggen. Services zijn dan ook ineens erg afhankelijk van de bus om dingen gedaan te krijgen. Liever spreken we in deze gevallen van een Broker in plaats van een Bus. Zo’n Broker kan een volstrekt valide pattern zijn in bepaalde architecturen, maar niet per sé in een SOA.

Aan de andere kant van het spectrum wordt de Service Bus slechts als concept gehanteerd. Dat klinkt ongrijpbaar maar dergelijke uitwerkingen zijn vaak vrij pragmatisch: services communiceren onderling via peer-to-peer verbindingen (bijvoorbeeld WCF), waarbij de Service Bus diensten als locatietransparantie (het “Locator” pattern) en een gedeeld en gemeenschappelijk schema (“Canonical Schema”) invult. Een Service Bus als concept betekent dan dat er enkele bouwblokken en principes worden gehanteerd en dat daaromheen de SOA applicatie wordt gebouwd. Deze interpretatie van de Service Bus is er een die ikzelf al meerdere malen heb toegepast in SOA implementaties en die mijns inziens prima werkt doordat de bus geen doel op zich is en je je kunt focussen op het realiseren van de services en de processen die de services aansturen.

nServiceBus zit ook in die laatste categorie: de Service Bus is vooral een concept en biedt een paar diensten en vooral principes die het mogelijk maken om een SOA op te bouwen uit zelfstandig opererende services. Ironisch genoeg is nServiceBus wel een “product” dat je moet downloaden en het biedt ook de nodige infrastructurele zaken voor de onderlinge communicatie van de services.

Communicatie tussen services

In een SOA hebben we te maken met verschillende communicatiepatronen waarin services met elkaar communiceren. Grofweg zijn dat er drie:

Request/Response: een client (eindgebruikersapplicatie of service) geeft een opdracht aan een service, of vraagt om gegevens en de service geeft daarop antwoord. Een pure Request/Response implementatie werkt vaak op een RPC-achtige (Remote Procedure Call) manier: je roept functionaliteit aan op een service en je wacht op het antwoord of totdat de operatie klaar is. nServiceBus geeft hier een eigen draai aan, zoals we zullen zien.
Fire/Forget: een client stuurt gericht een bericht naar een bepaalde service, maar is niet geïnteresseerd in het antwoord daarop. Bijvoorbeeld: in een geautomatiseerd offerteproces wordt een offerte naar een printstraat gestuurd.
Publish/Subscribe: ook hier verstuurt (publiceert) een service een bericht terwijl het niet geïnteresseerd is in een antwoord. Het verschil met Fire/Forget is dat het hier gaat om een bericht dat op een centrale plek wordt gepubliceerd en door meerdere subscribers kan worden afgenomen. Het is dus niet gericht aan één specifieke ontvanger. Het dient om een gebeurtenis (business events) kenbaar te maken aan iedereen die daarin is geïnteresseerd.

Bij Fire/Forget en Publish/Subscribe praten we over éénrichtingsverkeer ofwel zogenaamde One Way Messaging. Bij Request/Response komt er ook een antwoord terug.

In een gemiddelde SOA-implementatie zijn over het algemeen alledrie de genoemde communicatiepatronen wel vertegenwoordigd.

Bij one way messaging kunnen we te maken hebben met twee verschillende scenario’s, namelijk dat een verzender en ontvanger allebei online zijn en er een directe verbinding is, of dat de ontvanger op het moment van versturen niet online is. In het laaste geval vindt de verwerking dus later (asynchroon) plaats. Om deze situatie te kunnen opvangen hebben we op de service bus een dienst nodig: Store & Forward. De gedachte achter Store & Forward is dat het bericht wordt afgeleverd op een betrouwbare plek (store) en dat het daadwerkelijk afleveren van het bericht (forward) los daarvan plaatsvindt. Dit geeft een ontkoppeling van de verzender en ontvanger. Dit concept kennen we ook wel als een Queue.

Ontkoppeling van Verzender en Ontvanger, concept heet ook wel Queue

nServiceBus is geheel gebaseerd op het principe van One Way Messaging, waarbij Store & Forward een belangrijke rol speelt. nServiceBus is hier behoorlijk puristisch in. Udi Dahan heeft dit gedaan om verschillende redenen:

Beschikbaarheid: als de ontvanger van het bericht langzaam is, of gecrasht is, dan heeft dat geen effect op de snelheid en stabiliteit van de verzender. In de praktijk: een website kan ’s nachts nog wel gegevens ontvangen en publiceren naar de back-end services, terwijl die misschien in onderhoud zijn of druk met batchverwerkingen. De applicatie als geheel is nog wel beschikbaar terwijl enkele onderdelen dat niet hoeven te zijn.
Performance: de gedachte hierbij is dat het afleveren van een bericht in een queue zeer snel gebeurt omdat het een goedkope actie is. Zodra het bericht gedropt is in de queue, heeft de verzender alle resources weer beschikbaar voor verdere verwerking en hoeft het niet te wachten tot het bericht daadwerkelijk de ontvanger heeft bereikt.
Betrouwbaarheid: het schrijven naar en lezen uit een queue kun je transactioneel maken. Dit heeft een belangrijk effect: als de transactie voor het verwerken van een bericht niet lukt en wordt teruggedraaid, dan kun je ook het bericht weer terug in de queue plaatsen om het later nog eens te proberen. Met andere woorden: er gaan geen gegevens verloren doordat een service de fout in gaat. In een “traditionele” web service implementatie zal je er zelf voor moeten zorgen dat een mislukte aanroep opnieuw wordt geprobeerd, of dat er in de logging voldoende informatie beschikbaar is om het proces weer op gang te helpen zonder dat er data verloren gaat.

Dat met nServiceBus alleen One Way Messaging mogelijk is, betekent wel dat je met een bepaalde mindset je implementatie moet vormgeven. De services moet je dan beschouwen als zelfstandig draaiende procesjes waar volledig asynchroon berichten uitgaan en binnenkomen. Een bedrijfsproces voltrekt zich dan door een opeenvolging van berichten en de verwerking daarvan door de diverse services.

Hoe dit vorm krijgt met nServiceBus zal ik in de volgende paragrafen laten zien.

One Way Messaging met nServiceBus

In nServiceBus is het communicatiemechanisme geïmplementeerd met het concept van een message queue. Ik noem het bewust een concept, want het daadwerkelijke transportmechanisme is zelf te kiezen. Standaard is dit Microsoft Message Queueing (MSMQ), maar er is bijvoorbeeld ook een implementatie op basis van een WCF netTcpBinding beschikbaar. In feite is deze queue de Service Bus in het land van nServiceBus: een plek waar de berichten worden opgeslagen om verder te worden opgepakt.

Met nServiceBus gebruik je doorgaans meerdere queues waarnaar messages worden gepubliceerd en waarop je je kunt abonneren. Een nServiceBus implementatie is dus meestal een stelsel van queues. De service definieert zelf met welke queues hij interacteert. Naast de queues voor berichtuitwisseling hebben we nog een aantal infrastructurele queues, zoals de error queue, waar berichten naartoe worden verplaatst die – na een aantal keren opnieuw proberen – niet kunnen worden verwerkt.

Een nServiceBus-oplossing gebruikt voornamelijk Publish/Subscribe. Maar ook Fire/Forget en Request/Reply zijn mogelijk, zij het met een nServiceBus smaakje. Ik zal nog laten zien hoe dat werkt. De belangrijkste gedachte achter nServiceBus is dat RPC-achtige communicatie teveel blokkerende service-calls oplevert en de performance en stabiliteit negatief beïnvloedt. Om deze reden is gekozen voor een non-blocking, one way communicatie via een queue.

De belangrijkste gedachte achter nServiceBus is dat RPC-achtige communicatie de performance en stabiliteit negatief beïnvloedt.

Een subscriber meldt zich bij een publisher om aan te geven dat het geïnteresseerd is in een bepaald bericht. Zodra de publisher een bericht publiceert, raadpleegt de nServiceBus infrastructuur de abonnementen en wordt het bericht bij alle subscribers afgeleverd. Lukt dit niet, dan kan het bericht worden vastgehouden in een “outgoing” queue, vanwaaruit nServiceBus zal blijven proberen om het bericht af te leveren. Hoe vaak dat opnieuw wordt geprobeerd kun je configureren. Ondertussen gaat de publisher door met de verwerking. Subscribers kunnen zich at runtime aan- en afmelden.

Abonnementen voor publish/subscribe kunnen binnen nServiceBus op verschillende manieren worden bijgehouden: in memory, via een durable MSMQ queue of in een database. De storage zelf wordt geabstraheerd door het framework. De durable queue is de standaardkeuze voor opslag als je zelf niets anders kiest.

Door de nadruk op Publish/Subscribe en asynchrone verwerking gaat een nServiceBus oplossing al snel richting een bijzondere vorm van SOA: een Event Driven Architecture (EDA).

nServiceBus gebruiken

Om nServiceBus te kunnen gebruiken zullen we een aantal dingen moeten regelen:

Definieer berichten
Onderken en implementeer de publishers: welke service produceert welke berichten?
Onderken en implementeer de subscribers: welke services nemen ook berichten af en welke berichten zijn dat?

Het is gangbaar dat een service zowel berichten consumeert als produceert.

Laten we deze stappen nader bekijken door verder de techniek in te duiken.. Om de voorbeelden te kunnen gebruiken moet je nServiceBus downloaden vanaf de website. Je krijgt dan de sources, scripts om de sources te compileren, documentatie en voorbeelden. Met een batch file richt je je machine in zodat deze geschikt is om nServiceBus te gebruiken. Dit bestaat uit het aanmaken van enkele message queues en het configureren van de Distributed Transaction Coordinator (DTC). Vervolgens is er een batch file waarmee je de sources van nServiceBus kunt compileren. Dit levert een keurige folder op met alle binaries die je nodig hebt. De DTC wordt o.a. gebruikt bij operaties op de subscription store als je daarvoor een database gebruikt.

Om berichten te definiëren moet je een referentie zetten naar NServiceBus.dll en voor het implementeren van een publisher of een subscriber moet je daarnaast nog een referentie zetten naar NServiceBus.Core.dll en NServiceBus.Host.exe. Deze laatste is een executable, waarin de generic host is geïmplementeerd en waarin wat hosting logica is opgenomen die je kunt gebruiken. Ik kom hier later op terug.

Berichten definiëren

Berichten definiëren we in een aparte class library, waarnaar we later in de publisher / subscriber implementatie laten verwijzen. Het definiëren van de berichten in nServiceBus kun je op twee manieren doen.

1: Maak een class en markeer deze met de IMessage interface, zoals in Listing 1.

[Serializable]
public class AanvraagOfferteIngediend: IMessage
{
public Guid EventId { get; set; }
public DateTime Tijdstip { get; set; }
public string Achternaam { get; set; }
public string ProductVorm { get; set; }
}

Listing 1: Definitie van een bericht als class

Het bericht in het voorbeeld is simpel, maar je kunt er ook complexere structuren mee maken.

De class is gemarkeerd met het Serializable attribuut. Dit is nodig zodat nServiceBus de berichten kan serialiseren en in de queue kan plaatsen. Hiervoor wordt niet de DataContractSerializer van WCF gebruikt, maar een custom XML Serializer die kan omgaan met classes, interfaces en dictionaries. Ik heb echter gemerkt dat classes die zijn gedecoreerd met DataContract en DataMember attributen ook netjes worden geserialiseerd.

Een werkwijze die ik vaak hanteer is dat messages worden gemodelleerd in XSD en dat daarvan C# classes worden gegenereerd. Over services heen deel je dan alleen de XSD’s bij wijze van Canonical Schema. Deze werkwijze kan ook bij nServiceBus worden toegepast, als je er maar voor zorgt dat de IMessage interface op die classes wordt gezet. Eenmaal geserialiseerd is het bericht uitwisselbaar tussen services. Bijna conform een van de basisprincipes van SOA: “services delen contract en schema, maar geen types”, met als aanmerking dat er wel een interface uit de nServiceBus DLL’s wordt gedeeld (IMessage).

Basisprincipes van SOA: “services delen contract en schema, maar geen types”

IMessage is slechts een marker interface. Je hoeft er geen methods of properties voor te implementeren, maar het dient voor nServiceBus om generiek met messages om te kunnen gaan. De reden waarom het geen base class is, heeft te maken met de tweede manier waarop we messages kunnen definiëren, namelijk:

2: Definieer een interface en leid deze af van IMessage, zie Listing 2.

public interface IAanvraagOfferteIngediend: IMessage
{
Guid EventId { get; set; }
DateTime Tijdstip { get; set; }
string Achternaam { get; set; }
string ProductVorm { get; set; }
}

Listing 2: Definitie van een bericht als interface

Met deze interface hebben we ook een bericht gedefinieerd. De reden om te kiezen voor een interface heeft te maken met de extra mogelijkheden die je hiermee krijgt. Door interfaces te gebruiken krijg je een soort “multiple inheritance” cadeau, wat handig kan zijn bij versioning van berichten, of het samenstellen van nieuwe berichten uit meerdere bestaande berichtdefinities.

Als je gebruik maakt van interfaces als berichtdefinities, dan kun je voor het genereren van de berichtinstanties gebruik maken een IoC container (IoC = Inversion Of Control). Net zoals je kunt kiezen voor het transportmechanisme voor berichten is nServiceBus is zo opgebouwd dat de IoC container naar keuze kan worden verwisseld. Standaard wordt Unity gebruikt, maar evengoed kun je er bijvoorbeeld Autofac of Structuremap onder schuiven. Wat een IoC container is, valt buiten het bereik van dit artikel.

De Publisher implementeren

Nu we een bericht hebben gedefinieerd, willen we deze kunnen publiceren. Hiervoor gaan we een publisher maken.

Om een publisher te maken moeten we een zogenaamd MessageEndpoint implementeren. We moeten nServiceBus dan wel vertellen dat het gaat om een publisher. Dit doen we door een EndpointConfig class te implementeren. Zie Listing 3 voor een simpel voorbeeld.

class EndpointConfig : IConfigureThisEndpoint,
    AsA_Publisher,
    ISpecify.ToUseXmlSerialization,
    ISpecify.ToRun<VerkoopEndpoint>
{
}

Listing 3: Configuratie van een endpoint

Let eens op de syntax waarmee dit gebeurt. De naamgeving van de interfaces die we op deze class zetten is zodanig gemaakt dat dit eruit ziet als natuurlijke taal. Achtereenvolgens lezen we: “I configure this endpoint as a publisher, I specifiy to use XML serialization and I specify to run VerkoopEndpoint”. Ofwel: dit endpoint is een publisher die XML serialization gebruikt voor de berichten en het endpoint is de class VerkoopEndpoint.

nServiceBus heeft hieraan genoeg om te weten welk endpoint moet worden geïnstantieerd en aangeroepen. De configuratie in het voorbeeld is zo’n beetje het minimale dat je moet configureren. Hier heb je echter nog veel meer geavanceerde opties. Dit gaat voorbij aan de scope van dit artikel.

De VerkoopEndpoint class is te zien in Listing 4.

public class VerkoopEndpoint : IWantToRunAtStartup
{
public IBus Bus { get; set; }

public void Run()
{
Console.WriteLine("VerkoopEndpoint started.");
Console.WriteLine("Press 'Enter' to publish a message.To exit, Ctrl + C");

    bool useInterface = true;
    while (Console.ReadLine() != null)
    {
      var eventMessage = useInterface ?
          Bus.CreateInstance<IAanvraagOfferteIngediend>() :
         (IAanvraagOfferteIngediend) new AanvraagOfferteIngediend();

      eventMessage.EventId = Guid.NewGuid();
      eventMessage.Tijdstip = DateTime.Now;
      eventMessage.Achternaam = "de Vries";
      eventMessage.ProductVorm = "ZorgverzekeringPlus";

Bus.Publish(eventMessage);

      Console.WriteLine("Published event with Id {0}.", eventMessage.EventId);
      useInterface = !useInterface;
    }
}

public void Stop()
{
}
}

Listing 4: Implementatie van een MessageEndpoint

De class VerkoopEndpoint implementeert IWantToRunAtStartup. Voor deze interface moet je twee methods implementeren: Run en Stop. Deze methods worden aangeroepen door nServiceBus op het moment dat de service in de lucht komt en weer wordt gestopt. Doorgaans zal je hier alleen wat initialisatie en opruimwerk in doen, zoals het subscriben en unsubscriben van message handlers. In het voorbeeld heb ik alle logica van de service in de Run method gestopt.

In de voorbeeldcode zijn de twee manieren om met messages om te gaan ook gedemonstreerd: afwisselend wordt een zelf geïnstantieerd bericht verstuurd (AanvraagOfferteIngediend) of een bericht gegenereerd door nServiceBus (Bus.CreateInstance<T>()). Deze laatste maakt gebruik van de IoC container van jouw keuze.

Het publiceren van het bericht is zo simpel als het aanroepen van Bus.Publish(). De VerkoopEndpoint class heeft een public property van het type IBus. In OnStart wordt deze gebruikt, maar hij wordt nergens geïnitialiseerd. Dat ziet eruit als magie, maar dat valt mee. Dit doet namelijk het nServiceBus framework voor je via Dependency Injection.

Het implementeren van een Subscriber

Nu we een publisher hebben gemaakt, kunnen we een service gaan bouwen die het bericht OfferteAanvraagIngediend wil afnemen. Hier moeten we hetzelfde paradigma volgen. Eerst maken we een EndpointConfig, zie Listing 5.

class EndpointConfig : IConfigureThisEndpoint,
AsA_Server,
ISpecify.ToUseXmlSerialization
{
}

Listing 5: Subscriber endpoint configuratie

Dit endpoint wordt als een server geconfigureerd. Er is nog een derde optie en dat is AsA_Client. Het verschil in configuratie zit hem in de manier waarop de queue wordt geconfigureerd: een server en een publisher krijgen een transactional queue en gebruiken impersonation, een client niet.

Daarnaast zien we in dit voorbeeld dat we niet per se een MessageEndpoint hoeven op te geven. Dit endpoint zal automatisch alle gevonden message handlers subscriben. Je kunt dit ook handmatig doen. In de lijst van interfaces op de EndpointConfig geef je dan op: IDontWant.ToSubscribeAutomatically, om aan te geven dat je dit zelf wilt regelen. Met Bus.Subscribe() en Bus.Unsubscribe() meld je een subscriber aan en af.

In Listing 6 laat ik zien hoe je een MessageHandler implementeert. Een MessageHandler is een class die wordt aangeroepen zodra NserviceBus een bericht oppikt waarop deze handler is geabboneerd. De OfferteMessageHandler implementeert de IHandleMessages<T> interface, waarbij het typeargument aangeeft welk bericht deze handler afhandelt. De handler moet een Handle() method implementeren. Hier zou je het bericht kunnen opvangen, misschien wat vertalingen kunnen doen en vervolgens de interne service logica aanroepen. In het voorbeeld tonen we in de Trace informatie enkele velden uit het bericht. Hiermee hebben we een simpele subscriber geïmplementeerd.

public class OfferteMessageHandler :
    IHandleMessages<AanvraagOfferteIngediend>
{
public void Handle(AanvraagOfferteIngediend message)
{
    Trace.WriteLine(string.Format("Subscriber 1 received AanvraagOfferteIngediend message with Id {0}.", message.EventId));
    Trace.WriteLine(string.Format("Message time: {0}.", message.Tijdstip));
    Trace.WriteLine(string.Format("Client name: {0}.", message.Achternaam));
}
}

Listing 6: Implementatie van een message handler

In de message handler van Listing 6 wordt als af te handelen berichttype een specifieke class opgegeven. Als je echter werkt op basis van interfaces voor messages, dan kun je meer generieke message handlers maken. Je kunt ook meerdere handlers in een service hebben en je kunt nServiceBus vertellen in welke volgorde deze handlers moeten worden aangeroepen. In Listing 7 is te zien hoe je dat doet.

public class EndpointConfig : IConfigureThisEndpoint,
ISpecify.MessageHandlerOrdering
{
public void SpecifyOrder(Order order)
{
order.Specify(First<H1>.Then<H2>().AndThen<H3>().AndThen<H4>()); // etc.
}
}

Listing 7: Message handler volgorde opgeven

De voorbeelden in de Listings bestaat nu uit niet meer dan enkele losse classes die wat interfaces implementeren. Om dit allemaal met elkaar te laten werken hebben we een host nodig. Hiervoor zijn verschillende opties: zelf een host schrijven, hosten in IIS/WAS of de hosting logica van nServiceBus zelf. De nServiceBus host heet de Generic Host.

De Generic Host

De Generic Host is een executable die deel uitmaakt van de nServiceBus binaries: NServiceBus.Host.exe. Zoals de naam al aangeeft, is dit een generiek hostproces dat publisher- of subscriberlogica kan hosten. Alle infrastructuur voor het subscriben op queues, communiceren van berichten, etc. wordt door deze host afgehandeld.

Je kunt hem als losse executable starten, maar hij kan ook als Windows Service worden geregistreerd op het systeem. Business services die op deze manier zijn geïmplementeerd kunnen dan via de Service Control Manager van Windows worden gestart, gestopt en gemonitord.

Het draaien van onze publisher of subscriber in de generic host doen we door NServiceBus.Host.exe bij de library van de service te deployen en vervolgens via configuratie aan de host te laten weten wat hij moet doen. De Host is zelf zo slim om op zoek te gaan naar libraries met implementaties van interfaces zoals IConfigureThisEndpoint, IHandleMessages, enzovoort.

Voor een publisher zou een config file eruit kunnen zien zoals in Listing 8.

Listing 8: Configuratie van een publisher

We zien een config file waarin is aangegeven dat we gebruik maken van MSMQ als transportprotocol. Berichten die deze publisher genereert worden op een queue genaamd “messagebus” gepubliceerd. We zien ook dat er in nServiceBus een stukje fouttolerantie is ingebouwd. Mocht er iets misgaan bij het afleveren van een bericht, dan zal dit tot 5 keer opnieuw worden geprobeerd. Lukt het dan nog niet, dan wordt het bericht op de “error” queue gepubliceerd. Gegevens gaan daardoor nooit verloren. Verder kun je nog invloed uitoefenen op het aantal worker threads dat de generic host gebruikt. Voor subscribers zou je kunnen denken aan meerdere threads voor de verwerking ervan.

De configuratie van de subscriber is in Listing 9 te zien.

Listing 9: Configuratie van een subscriber

Hier zie je dat er twee queues zijn geconfigureerd. De “worker” queue is de queue waar deze subscriber eventueel zelf berichten op zou kunnen publiceren.
In de sectie UnicastBusConfig is gedefinieerd dat er berichten binnenkomen op de “messagebus” queue. Daarbij geven we aan dat de berichten die daarop binnenkomen zich bevinden in de Messages DLL. Deze informatie is voldoende voor de generic host om zijn werk te kunnen doen.

Nu kun je ervoor kiezen om zelf alle benodigde queues aan te maken. Dat is misschien ook verstandig in een productieomgeving omdat je dan maximale controle hebt over de security en wat er precies wordt aangemaakt. Maar zelfs dat kan de generic host voor je uit handen nemen bij het opstarten. Op deze manier ben je bij het ontwikkelen en testen van nieuwe services heel snel up-and-running.

Een stapje verder

We hebben nu een simpele publisher en subscriber geïmplementeerd en gehost in de generic host. De berichtuitwisseling tussen deze twee is ook erg basaal. Bedrijfsprocessen zijn complexer dan dat. In deze paragraaf laat ik een aantal zaken de revue passeren die je met nServiceBus kunt doen om wat complexere scenario’s te realiseren.

Security

Een publisher kan zelf bepalen welke subscribers zich wel of niet mogen abonneren op berichten. Hiervoor moet je de interface IAuthorizeSubscriptions implementeren. In Listing 10 zie je hier een voorbeeld van.

public class SubscriptionAuthorizer : IAuthorizeSubscriptions
{
public bool AuthorizeSubscribe(string messageType,
                                 string clientEndpoint,
                                 string clientWindowsIdentity,
                                 IDictionary<string, string> headers)
{
    // raadpleeg een autorisatie store
    return true; // true = toegestaan, false = niet toegestaan
}

  public bool AuthorizeUnsubscribe(string messageType,
                                   string clientEndpoint,
                                   string clientWindowsIdentity,
                                   IDictionary<string, string> headers)
{
    // raadpleeg een autorisatie store
    return true; // true = toegestaan, false = niet toegestaan
}
}

Listing 10: Autoriseren van een subscriber door een publisher

Er is geen manier om vanuit code controles te doen of de publisher van een bericht wel authentiek is. Dit zal je moeten inregelen met strikte security op de message queues. Wel zijn er onderdelen in de nServiceBus infrastructuur die automatisch een hash van een bericht kunnen valideren om message tampering te voorkomen.

Request/Reply

We hebben het nu wel telkens over publish/subscribe, maar er zullen situaties zijn dat we ook een antwoord willen op een bericht. In dat geval spreken we niet echt van een event, maar van een Request. Het antwoord daarop is een Reply. Een request is niet iets dat je publiceert, maar verstuurt naar een specifieke ontvanger. Dat onderscheid is ook aangebracht in de nServiceBus implementatie. Een request message verstuur je met de volgende code:

Bus.Send(requestMessage);

Het bericht wordt dan verstuurd naar het endpoint (de queue) die is opgegeven in de configuratie voor dat berichttype. Request/Reply is in nServiceBus nog wel steeds opgelost met one way messaging. Om ervoor te zorgen dat een antwoord terugkomt in de client, moeten we dus nog iets extra doen, namelijk het registreren van een callback om het retourbericht af te handelen:

Bus.Send(request).Register(asyncCallback, state);

Een geregistreerde callback handler kan geen crash of herstart van de machine overleven. Het reply bericht zal dan echter nog in de queue staan, dus als je een alternatieve methode hebt om die reply alsnog af te handelen (MessageHandler), dan verlies je in ieder geval geen waardevolle data.

Request/ Reply berichtuitwisseling zal vooral veel voorkomen in eindgebruikersapplicaties, waarin gegevens moeten worden opgehaald en getoond. Voor webapplicaties heeft nServiceBus een speciale vorm voor het registreren van callbacks. Gebruik in dat geval RegisterWebCallback in plaats van Register. Zie Listing 11 voor een voorbeeld hiervan.

Aan de serverkant kun je op een verzoek antwoorden met de volgende code:

Bus.Reply<MyResponse>();

Je kunt deze Reply methode in een service meerdere malen aanroepen. Dit is handig als je grote hoeveelheden data moet versturen. Het versturen gebeurt dan op een “streaming” manier.

Dit Request/Reply pattern kun je goed gebruiken als je opdrachten wilt geven aan een back-end proces ter verwerking en daarop ooit een antwoord wilt. Voor het opvragen van gegevens is die asynchroniteit misschien niet wenselijk. Liever wil je dan direct antwoord. Hiervoor zijn een WCF service of een RESTful API misschien beter geschikt.

Alternatieve hosting

Het gebruiken van de generic host is geen verplichting. De declaratieve manier om een endpoint te maken en toegang te krijgen tot de nServiceBus infrastructuur die ik heb laten zien is niet de enige manier om met nServiceBus te werken. Je kunt dit ook zelf met programmacode aanroepen en zo nServiceBus integreren in een applicatie die in een custom host of bijvoorbeeld in IIS (Internet Information Server) draait.

In Listing 11 is te zien hoe je via programmacode de nServiceBus configureert en start op een manier die equivalent is aan de IConfigureThisEndpoint interfaces.

// In een web applicatie, in Global.asax public class Global : HttpApplication
{
public static IBus Bus { get; private set; }

protected void Application_Start(object sender, EventArgs e)
{
    Bus = NServiceBus.Configure.WithWeb()
            .SpringBuilder()
            .XmlSerializer()
            .MsmqTransport()
              .IsTransactional(false)
              .PurgeOnStartup(false)
            .UnicastBus()
              .ImpersonateSender(false)
            .CreateBus()
            .Start();
}
}

// Gebruik van de bus:

// Een request versturen en het resultaat opvangen in een WebCallback.
Global.Bus.Send(message)
          .RegisterWebCallback<Result>(result =>
                                       Label1.Text = result.ToString());

Listing 11: nServiceBus in een ASP.NET applicatie

Zelf een host implementeren is niet iets dat je snel zelf wilt doen. De robuustheid, stabiliteit, performance en mogelijkheden voor monitoring en logging die je doorgaans nodig hebt zijn niet gemakkelijk om zelf te realiseren. Liever kies je dan voor een host als IIS of de generic host. Het hosten van een subscriber voor events in IIS is niet eenvoudig, het publiceren of versturen van berichten wel, zoals in Listing 11 te zien is.

WCF integratie

Het is mogelijk om nServiceBus te integreren met WCF. Het resultaat hiervan is dat de implementatie van een service gewoon bestaat uit een message handler. De integratie bestaat uit het definiëren van een class die afleidt van de WcfService base class. Zie Listing 12.

public class MyService : WcfService<RequestType, ResultType>
{
// geen implementatie
}

Listing 12: nServiceBus/WCF integratie

De interface die deze WCF service beschikbaar stelt ziet er altijd hetzelfde uit: er zit één operatie op met de naam Process, die een bericht van het type RequestType ontvangt en een bericht van het type ResultType retourneert. RequestType en ResultType zijn de typeparameters van de generic WcfService, zoals in het voorbeeld in Listing 12. De SOAP Action en ReplyAction definitie hebben ook een vast formaat. Zie Listing 13 voor een voorbeeld.

[ServiceContract]
public interface ICancelOrderService
{
[OperationContract(
Action= "http://tempuri.org/IWcfServiceOf_RequestType_ResultType/Process",
ReplyAction=
"http://tempuri.org/IWcfServiceOf_RequestType_ResultType/ProcessResponse")] ResultType Process(RequestType request);
}

Listing 13: ServiceContract definitie van de generieke WCF interface

Deze WCF integratie biedt je de mogelijkheid om snel een nServiceBus endpoint via WCF beschikbaar te stellen. Je hebt echter geen controle over hoe de interface eruit ziet. Wil je een intuïtievere interface door duidelijke operatienamen (Process() is wel erg algemeen) of wil je meer controle over de Action en ReplyAction headers, dan kun je beter de WCF service zelf implementeren op een traditionele manier en de integratie met nServiceBus regelen door het binnenkomende bericht te publiceren op de bus met Bus.Publish(). De WCF service fungeert dan als een soort proxy die een op RPC gebaseerde wereld verbindt met de asynchrone wereld van nServiceBus.

Sagas

Een Saga is een manier om met nServiceBus long running processen te implementeren. Dit onderwerp is omvangrijk genoeg om er een heel artikel aan te wijden. Ik zal hier in een volgend artikel op terugkomen.

Distributor, Timeout Manager, Proxy en Gateway

Buiten de infrastructurele onderdelen van nServiceBus die ik heb beschreven, zijn er nog vier zelfstandige processen die met nServiceBus meekomen en die je naar wens kunt inzetten. Dit zijn de Distributor, de Timeout Manager, de Proxy en de Gateway. Deze onderdelen zal ik ook toelichten in een vervolgartikel.

Conclusie

In dit artikel heb ik uitgelegd wat er zoal wordt verstaan onder het begrip Service Bus in de wereld van Service Oriented Architecture. Er zijn verschillende interpretaties mogelijk. nServiceBus beschouwt de Service Bus vooral als concept, maar levert wel infrastructurele zaken om communicatie tussen services te realiseren. nServiceBus is gemaakt vanuit de gedachte dat RPC-achtige communicatie teveel blocking service-aanroepen opleveren en daarmee de stabiliteit, performance en beschikbaarheid van een SOA geweld wordt aangedaan.

Of die bewering waar is, is de vraag. Ook met een WCF oplossing, gecombineerd met Windows Workflow Foundation (WF) kun je schaalbare en robuuste SOA’s bouwen. Asynchrone communicatie, achtergrondverwerking en retry voor fault tolerance kun je ook met deze technologieën realiseren. In sommige gevallen helpt nServiceBus je snel op weg met bijvoorbeeld de Generic Host, maar van WCF en WF krijg je ook het een en ander cadeau.

Ook gaf ik aan dat in een gemiddelde SOA implementatie alle drie de genoemde communicatiepatronen wel aanwezig zullen zijn. Het ophalen van data, zoals referentiedata, zal je vanuit de client applicatie doorgaans het gemakkelijkst met (synchrone) Request/Reply kunnen oplossen. Ook voor communicatie met de buitenwereld is het gangbaar om met SOAP services te werken. Als je voor nServiceBus kiest, dan zal je dat mijns inziens altijd doen in combinatie met andere technieken. Ik vind dat nServiceBus een aantal zaken fraai oplost, maar ik heb het product nog niet genoeg in grote praktijkprojecten toegepast om een oordeel te vellen over de kwaliteit als geheel of over de productiviteit bij het ontwikkelen.

De belangrijkste overweging bij het wel of niet inzetten van nServiceBus is of de tamelijk puristische benadering van SOA (geen blocking calls, alleen one-way messaging) past in de architectuur die je aan het realiseren bent en de architectuurstandaarden binnen je bedrijf. Het is ook deels een kwestie van vertrouwen. Durf je het aan om nServiceBus in te zetten, wetende dat het een open source project is van enkele enthousiastelingen versus technologie van een gevestigde leverancier als Microsoft? De mensen achter nServiceBus zijn wel gevestigde namen en nServiceBus werkt inmiddels wel aan een aardige reputatie met praktijkimplementaties.

Wil je je verder in nServiceBus verdiepen, dan raad ik je aan nServiceBus te downloaden en de meegeleverde samples te bekijken. De samples geven je een goed beeld van de verschillende aspecten van nServiceBus. Ik ga in een vervolgartikel verder in op een aantal meer geavanceerde aspecten van nServiceBus.

Dit artikel is gebaseerd op de 2.0 Release Candidate van nServiceBus.

Links
nServiceBus website: http://www.nservicebus.com
nServiceBus Architectuurprincipes: http://www.nservicebus.com/ArchitecturalPrinciples.aspx
Weblog Udi Dahan: http://www.udidahan.com