70 513: Windows Communication Foundation Development with Microsoft.Net Framework 4.0. Eaverae s Microsoft Certified Technology Specialist Series

Transcriptie

1 Eaverae s Microsoft Certified Technology Specialist Series : Windows Communication Foundation Development with Microsoft.Net Framework 4.0 Guido Schippers Maart Juni 2012 Driessen HRM_Payroll

2 Voorwoord Na een paar maanden ploeteren, is het vanaf vandaag officieel. Ik heb het examen succesvol afgerond, en mag mezelf MCTS in de WCF noemen. Nu was het in ieder geval mijn bedoeling om alle informatie die ik heb gegeven op mijn blog, te bundelen in een PDF document, met daarbij een aantal bijlagen en code bestanden. Dit document ben je op dit moment aan het lezen, en kan dus concluderen dat je meer wilt weten over de WCF. Nu was het inderdaad zo dat er geen boek beschikbaar was voor dit certificaat, en heb ik dus onze grote vriend Google Bing veel geraadpleegd om een zo helder mogelijk verhaal te creeëren. Alle informatie uit deze PDF is online te vinden op mijn persoonlijke website Eaverae.nl. Als eerste zal je de blogberichten zelf gaan tegenkomen, daarna alle bijlagen (incl. Visio tekeningen). Ik moet er echter bij vermelden dat ik niet weet of alle referenties (qua links) die ik maak in de blogberichten allemaal werken; dit is immers van teveel factoren afhankelijk. Zoals ik in ieder geval al meldde, is alles ook online te lezen, en daar werken ze zeker. Voor nu in ieder geval veel leesplezier (?), en veel succes met het examen. N.B. Ik moet er even bij vermelden dat tijdens de conversie van HTML naar een Word document, de formattering hier en daar eronder heeft geleden. Ik geef Word in ieder geval de schuld. Voor het schrijven van dit document (alhoewel het eigenlijk een klein boek is geworden), heb ik gebruik gemaakt van een tweetal boeken die ik zeker aanraad om door te nemen: Microsoft.NET Framework Windows Communication Foundation, Web Applications Development with Microsoft.NET Framework 4. 2

3 Inhoud Voorwoord maart 2012: Geen informatie beschikbaar... 4 Wat is de WCF?... 4 Hoe maak ik gebruik van de WCF? April 2012: Van gastheer tot consument... 9 Zie er altijd verzorgd uit mei 2012: Verbanden met verbinden, heb ik een (ver)binding? Waar haal ik mijn prik vandaan? mei 2012: Practice makes perfect Start me up! juni 2012: Implementing Alcatraz Security Transportlevel security Messagelevel security Dan heb je je paspoort laten zien, moeten ze het ook nog controleren We zijn er bijna Beter goed gejat dan slecht bedacht juni 2012: Een verdieping van de WCF De enige ziekte binnen de WCF: POX Foutje, bedankt! Instances, Sessions, enigszins verbonden? Eerst je vinger opsteken; dan krijg je de beurt WCF gebruiken als mededingingsautoriteit; het kan, en hier staat hoe Wie pakt de draad weer op? Gefeliciteerd Wat nu Online posts Downloads Niet behandeld Bronnen

4 26 maart 2012: Geen informatie beschikbaar WCF, Windows Communcation Foundation, is een lastig begrip voor ontwikkelaars die hier net mee beginnen. Wat is WCF? Waar gebruik je dit voor? Met andere woorden: Wat heb je er in hemelsnaam aan? In de volgende blog serie ga ik proberen wat meer helderheid te schetsen naarmate ik mezelf een weg baan naar de ultieme proef op de som: Het huidige examen in WCF: : Windows Communication Foundation Development with Microsoft.NET Framework 4. Alle begin is moeilijk. Zo ook in WCF. Ik zal proberen een zo'n helder mogelijke uitleg te geven in deze post over: waar WCF voor dient, hoe je het kan gebruiken, en hoe je je WCF zou moeten voorstellen. Daarnaast zal ik uitleggen welke bronnen ik gebruik om me de techniek eigen te maken. Wat is de WCF? De WCF is in principe een van de zes platformen waarvoor je kan ontwikkelen met het.net Framework 4.0. De WCF onderscheidt zich echter omdat dit het enige platform is wat eigenlijk géén UI (User Interface) heeft. Daardoor is het in de eerste instantie vrij lastig om te bevatten wat dit nu eigenlijk voor iets is. De zes ontwikkelplatformen zijn: - Windows - Web - Silverlight (een hybride van Windows en Web) - Windows Phone (een hybride van Windows en Silverlight) - XNA (een combinatie tussen Windows, XBOX 360 en Windows Phone) - WCF De WCF, oftewel Windows Communication Foundation, is inderdaad wat de naam al zegt: Een communicatie platform tussen verschillende op Windows gebaseerde technologieën. Dus een soort van communicatie van alles wat Windows gebaseerde technologie ondersteunt (dit is een aanname om het wat gemakkelijker te begrijpen; Je kan ook met niet-windows zaken communiceren, maar daar komen we later op terug). De WCF heeft met name te maken met Services. Services zou je je kunnen voorstellen als C# Class Libraries die reageren op verzoeken van 'buitenaf' (dit kan ook op dezelfde machine zijn), te vergelijken met hoe een browser een website aanspreekt. Uiteraard zijn er verschillende typen services, maar daar gaan we momenteel nog niet verder op in. Voor nu is het gemakkelijk te onthouden dat Services eigenlijk dus 'exposed' libraries zijn. Afhankelijk van de verbinding (Binding) die er gebruikt wordt, en de boodschap (Message) die er over (en weer) moet, definieer je een soort template (Contract). Veelal worden hier C# Interfaces voor gebruikt. Zoals je merkt zit ook WCF weer vol met terminologie. Mijn advies is dan ook om alles op te zoeken waar je nog nooit eerder van gehoord hebt, of niet echt begrijpt wat het is/doet. Hoe maak ik gebruik van de WCF? Om de WCF te kunnen gebruiken, heb je, zoals hierboven aangegeven, een Service nodig. Deze Service heeft, naast natuurlijk de functionaliteit die hij uitvoert, één of meerdere ontvangers 4

5 (endpoints) nodig. Eigenlijk zijn deze ontvangers geen ontvangers, maar zenders, die een actie vragen van de Service. De Service geeft, op zijn beurt uiteraard weer een Response aan de Endpoint (client). Tot dusver voor mensen met een web-achtergrond vrij bekend terrein. De Service heeft uiteraard configuratie nodig, zoals praktisch alles binnen de ict wereld. De hoofd-configuratie die er opgenomen dient te worden is te definiëren als het ABC van de Endpoints: - A = Address: Wáár staat de Service? - B = Binding: Wat voor type connectie heeft hij nodig? - C = Contract: Hoe zien de documenten eruit die hij ontvangt/verzendt (welke interface(s))? Adres Het adres lijkt me vrij eenvoudig. Dit is gewoon de fysieke locatie waar de service staat. Deze dient echter aangeroepen te worden via een URL (Unique Resource Locator) die gebruik maakt van de zogenaamde 'Web Service Addressing Standard'. Deze is als volgt opgebouwd: Schema (NIET het protocol)://machinenaam:poortnummer/pad naar de service Bijvoorbeeld: net.tcp://localhost:8001/orderservice Binding De Binding is een type connectie, althans, zo zie ik het. Elk type heeft zijn eigen eigenschappen over hoe de communicatie met de Service verloopt. Denk hierbij aan encryptie, welk protocol (hier dus wel), welk medium etc. Ik ben momenteel bezig met een schema wat voor eigenschappen deze verschillende Bindings allemaal hebben, welke standaarden ze volgen, en hoe deze geïmplementeerd dienen te worden. Contracts De Contracts zijn in principe vrij eenvoudig. Allereerst de Message. De Message (niet het message contract) is de 'brief' die verzonden wordt van de zender naar de ontvanger (de client-service relatie, Service-client relatie, of zelfs client-service-client relatie). Het contract is dan de 'formattering' van die brief die heen en weer gestuurd wordt. Vaak is dit dus een C# Interface. Er zijn verschillende typen Contracts, die het gedrag/lot bepalen van de 'brief'. Denk niet te veel over de hiërarchie na. Deze komt hieronder in code terug. Daarnaast zou ik nog even willen vermelden dat een MessageContract niet verplicht is om mee te geven. De Message kan immers ook gevuld zijn met alleen een DataContract. Onthoud dit even, we komen ook hier later op terug. 5

6 - Service Contract o Operation Contract o Data Contract o Message Contract Goed. Dat was een mooie, enigszins summiere, visuele interpretatie van de uitleg die nu komen gaat. Om aan te geven dat je daadwerkelijk met een (Service) Contract te maken hebt, definieer je in je Interface declaratie het ServiceContract Attribute. Nu, dat was vrij eenvoudig. Om aan te geven welke Methods (je operaties) het ServiceContract bevat, markeer je de Methods met een OperationContract Attribute. Dit was dus ook niet al te moeilijk. Daarnaast dien je natuurlijk parameters mee te geven met je Methods. Dit kan je doen middels (je raadt het waarschijnlijk al) Data- en Message Contacts. Die laatste twee zijn eigenlijk gewoon POCO (Properties - Constructor) classes, die in het geval van een Data Contract: - bevatten welke data er meegestuurd moet worden van/naar Endpoints. en in het geval van een Message Contract: - die data bevat die over de 'brief' zelf gaat. Denk hierbij aan bijvoorbeeld authorisatietokens, wachtwoorden, en andere configuratie-instellingen. Alles draait om de inhoud Het gemakkelijkste is momenteel om even een code voorbeeld te tonen, van een volledige service, waarna we deze stap voor stap doorlopen. We beginnen met de definitie van het Data Contract, dus de data die tussen de verschillende Endpoints rondgestuurd gaat worden. Stel je hebt een Service voor het ophalen van contactinformatie van klanten. Je definieert dan normaliter een class, met daarin de gewenste members. Zo ook in dit geval: [DataContract()] public class ContactInfo [DataMember()] public string PhoneNumber; [DataMember()] public string Address; Je ziet dat ik door middel van de DataContract en DataMember attributen de class geschikt heb gemaakt voor het gebruik binnen een Service Contract. Nadat dit gebeurd is, dien je een Message Contract te bepalen. In combinatie met je Data Contract vormt dit de daadwerkelijke inhoud van je 'brief'. Het Message Contract maakt uiteraard gebruik van je Data Contract, om aan te kunnen geven welke data er mee moet. Dit komt er dan als volgt uit te zien. Let erop dat ik zowel voor de Request als de Response een Message Contract opzet. 6

7 [MessageContract(IsWrapped = false)] public class ContactInfoRequestMessage [MessageHeader()] public string LicenseKey; Bovenstaande class is de RequestMessage. In principe is het dus zo dat het enige wat de client hier moet doen is een licentiesleutel meegeven, zodat de service het verzoek kan authenticeren, en een ResponseMessage kan terugsturen, met daarin de verzochte data. Deze Response Message ziet er dan als volgt uit. [MesssageContract(IsWrapped = false)] public class ContactInfoResponseMessage //This is the actual Data Contract [MessageBodyMember()] public ContactInfo ProviderContactInfo; Zoals je kan zien, heeft de ResponseMessage straks alle data die we nodig hebben. Je bent nu klaar met het optuigen van de Data- en MessageContracts. Nu kunnen we beginnen met de daadwerkelijke Service, die een Service Contract (de interface) nodig heeft, zodat alle Endpoints weten welke Members er allemaal beschikbaar zijn. Nog even over bovenstaande code: de IsWrapped property dient voor de daadwerkelijke data die over de lijn heen en weer gestuurd wordt. Ik ga hier verder nu niet op in. [ServiceContract()] public interface ISomeService //Note that the MessageContract is given as a parameter //And the ResponseMessage is the returntype [OperationContract()] [FaultContract(typeof(string))] public ContactInfoResponseMessage GetProviderContactInfo(ContactInfoRequestMessage reqmsg); Wat hieraan opvalt is dat de enige beschikbare Member een method is, die als parameter de RequestMessage vraagt, en als returntype een ResponseMessage geeft. Er rest ons dus slechts nog één ding te doen: het daadwerkelijk schrijven van de uit te voeren code. Deze code is de implementatie van de ISomeService interface, die we zojuist gemaakt hebben. Visual Studio zal, bij het toevoegen van deze service als Service Reference, zelf een Proxy class maken die vervolgens kan communiceren met deze Service. Hij maakt dan gebruik van de interface die we hierboven hebben gedefinieerd. 7

8 //The SomeService Service actually inherits from the ISomeService interface public class SomeService : ISomeService //Since the interface should be implemented, the only available member is the following method public ContactInfoResponseMessage GetProviderContactInfo(ContactInfoRequestMessage reqmsg) if (reqmsg.licensekey!= validlicensekey) //Throw an exception here. We can do this, since the interface implements a FaultContract Attribute const string msg = "Invalid License Key."; throw new FaultException<string>(msg); //Setup the responsemessage ContactInfoResponseMessage respmsg = new ContactInfoResponseMessage(); respmsg.contactinfo = new ContactInfo(); respmsg.contactinfo. address = "sample@ address.com"; respmsg.contactinfo.phonenumber = " "; return respmsg; //Setup our license key private const string validlicensekey = "abc-1234-alpha"; Zoals je in bovenstaande code kan zien, vallen nu alle puzzelstukken op hun plaats. Er worden hier en daar wat attributen gebruikt welke ik nog niet nader heb toegelicht, maar dat laat ik ook helemaal aan jezelf over. Dit is in ieder geval in een notendop hoe de verschillende Endpoints met mekaar kunnen communiceren via de WCF. Beginnen met de WCF; wat nu? De WCF is een ingewikkeld platform wat niet onder de knie te krijgen is. Het is een verwarrend concept waar ook bij mij de nodige uren research voor nodig waren. Het mooie van alles is, is dat Microsoft Press géén boek beschikbaar heeft voor het examen Ik hoop dus dat deze serie een wat duidelijker beeld geeft, en als hulpmiddel kan dienen voor het behalen van dit examen. Ik heb de volledige lijst met bronnen die ik voor deze post gebruikt heb nog even opgesomd. Ik verwacht dat de volgende post over een week of twee a drie beschikbaar zal zijn. Mocht je in de tussentijd nog vragen hebben, reageer dan op deze post, of stuur mij even een . 8

9 26 April 2012: Van gastheer tot consument In mijn vorige post heb ik omschreven wat de WCF nu eigenlijk is, en waar het voor dient. Daarnaast heb ik uitlegt dat de WCF met name met Services werkt, en hoe je een Service kan opzetten. Zoals je je wellicht kan herinneren, heeft een Service een bepaalde Endpoint configuratie nodig; Endpoints zijn verschillende applicaties die de Service aanspreken en Messages geven. Ik ben inmiddels weer wat verder gevorderd met het boek, en heb ook weer het een en ander aan ervaring opgedaan, wat ik met jullie in deze blogpost ga delen. Deze post gaat over het hosten van je Service, en het 'consumeren' (gebruiken) van de Service in client applicaties. Allereerst de gastheer, de Host. Een host kan, van alles zijn (gelukkig). Je kan gebruik maken van IIS om je Service te hosten, WAS (Windows Process Activation Service, een feature binnen IIS (vanaf 7.0)), of een ASP.Net webapplicatie om je Service via het internet beschikbaar te maken. Daarnaast kan je de service ook nog beschikbaar maken binnen diverse andere.net applicaties, zoals WPF, Windows Forms of Console (deze doen dit via praktisch dezelfde manier). En als laatste optie heb je ook nog de mogelijkheid om je Service voor zowel het internet, als op de lokale machine beschikbaar te maken via een Windows Service (de services die dus draaien onder de MMC services.msc). Het is dus even afhankelijk van de situatie via welke manier je je Service wilt hosten. Zie er altijd verzorgd uit Als gastheer zie je er doorgaans verzorgd uit. Je hebt nette kleren aan, je kapsel in model, etc. Zo dient dit ook het geval te zijn bij het hosten van je Service. Het hosten van een Service lijkt misschien ingewikkelder dan een geslaagd feest geven, maar dit is niet per se zo. We lopen in het eerste gedeelte eerst de web varianten door, en zullen daarna de 'lokale' varianten van hosting bekijken. Let op: Het configureren van een Binding (wat ik aangaf in de vorige post) heeft, zoals je wellicht nog kan herinneren, ook te maken welk schema en protocol je Host ondersteund. Een standaard Service die via een basichttpbinding gehost wordt door IIS, heeft bijvoorbeeld geen ondersteuning voor TCP/IP, waar WAS dat wél heeft. Je Endpoint dient dan dus deze Binding te definiëren. Hosten via IIS, WAS & ASP.Net IIS, de webserver van Microsoft, wordt doorgaans gebruikt om websites en webapplicaties te hosten. Nu kan IIS veel meer dan dat, mits uiteraard de correcte configuratie is toegepast. Het gemakkelijkste is om je Service te hosten via een ASP.Net website. Je Service wordt dan geïntegreerd met de website, waardoor er toch enigszins iets van een User Interface (UI) beschikbaar is. Visual Studio kan dit prima voor je doen door middel van het New Website menu. Daarnaast bestaat de mogelijkheid je Service 'kaal' te hosten. De benodigdheden zijn als volgt: IIS, een virtual directory, een subdirectory App_Code met daarin je code óf een subdirectory bin met daarin je gecompileerde Service, een.svc bestand (je Service) en een Web.Config voor de configuratie van de Service. Ditzelfde geldt voor het hosten via WAS. Hosten via WPF, Windows Forms en Console applicaties Heerlijk vind ik deze optie. Stel je eens voor: je bent bezig met een applicatie voor Windows, en je wilt gedurende de tijd dat je de applicatie aan het gebruiken bent een log beschikbaar stellen voor mensen op internet. Een beta-versie van een game of iets dergelijks (Een prangende vraag kwam er in mij naar boven tijdens het lezen/bestuderen van deze sectie in het boek: Kan een Service ook gehost worden 9

10 door XNA/Silverlight/Windows Phone (of misschien zelfs je XBOX360)?), en mensen moeten weten welke acties je uithaalt in het programma. Dit kan je doen via een zogenaamde ServiceHost. Het implementeren van deze class is echt doodeenvoudig, en gebeurt op de volgende manier. Onderstaand voorbeeld is een Console Application, om de code zo beknopt mogelijk te houden. We gaan even verder met onze SomeService, die we in de vorige post gebruikten. static void Main(string[] args) using (ServiceHost host = new ServiceHost(typeof(SomeService))) //Open the host host.open(); Console.WriteLine("The service is ready.\npress any key to exit."); Console.Readkey(true); host.close(); En dat was het! Heel eenvoudig dus. Let erop dat de daadwerkelijke Service binnen dezelfde Solution aanwezig dient te zijn, en de configuratie-instellingen van de Service ook aanwezig zijn binnen de App.Config van je Host applicatie. Hosten via een Windows Service Mijn persoonlijke favoriet, en de reden waarom je in de eerste instantie Services wil schrijven. Je wil dat je pc automatisch zaken voor je regelt, zonder dat je daar hinder van ondervindt. Dan kan dat heel erg mooi met de Windows Service als host. Om even te zien wat een Windows Service precies is, daag ik je uit om even naar Start > Uitvoeren te gaan, en 'services.msc' in te typen, gevolgd door een [ENTER]. Je ziet nu een overzicht van alle Windows Services op je pc. Sommige staan te draaien, andere niet, etc. Erg chique lijkt het me om er daar een aan toe te kunnen voegen. En dat kan nu. Het is zo eenvoudig als een Word-document schrijven (al is dat voor sommigen ook nog vrij ingewikkeld). Open je Service in Visual Studio, en voeg een nieuw project aan de Solution toe. Kies hier voor het Windows Service template (zie screenshot op de volgende pagina). 10

11 Afbeelding 1: Een nieuw Windows Service project in Visual Studio 2010 Voeg vervolgens de volgende Assembly References toe: System.ServiceModel en System.Configuration.Install. Open vervolgens je C# bestand van je service, en voeg de using statements toe (als ze er nog niet staan uiteraard). using System.ServiceModel; using System.ComponentModel; using System.Configuration.Install; using System.ServiceProcess; Zorg ervoor dat je vervolgens een Property aanmaakt, welke het ServiceHost object voorstelt, wat hierboven ook gebruikt werd. public ServiceHost servicehost = null; Binnen de Constructor van de class kan je vervolgens een property ServiceName zetten, welke straks gebruikt wordt binnen Windows zelf om de host als Windows Service te herkennen. Binnen de Main() method van de Windows Service wordt de Windows Service vervolgens gestart. 11

12 public SomeWindowsService() ServiceName = "Sample Windows Service"; public static void Main() ServiceBase.Run(new SomeWindowsService()); Je ziet dat de Windows Service standaard al twee methods implementeert, OnStart en OnStop. Deze gaan we nu uiteraard vullen met code. Deze methods zorgen voor de daadwerkelijke activering van je WCF Service. protected override void OnStart(string[] args) if (servicehost!= null) servicehost.close(); servicehost = new ServiceHost(typeof(SomeService)); servicehost.open(); protected override void OnStop() if (servicehost!= null) servicehost.close(); servicehost = null; Nu heb je in principe de implementatie van je Windows Service gereed. Wat er nu echter nog moet gebeuren is het daadwerkelijk installeren van de Windows Service binnen Windows zelf. Dit is dus waar de System.Configuration.Install assembly bij komt kijken. We maken (binnen hetzelfde bestand, vandaar het using statement) een Installer class aan, die onze Windows Service beschikbaar maakt voor Windows (code staat op de volgende pagina). 12

13 [RunInstaller(true)] public class ProjectInstaller : Installer private ServiceProcessInstaller process; private ServiceInstaller service; public ProjectInstaller() process = new ServiceProcessInstaller(); process.account = ServiceAccount.LocalSystem; service = new ServiceInstaller(); service.servicename = "Sample Windows Service"; //Note that this name must match with the Windows Service ServiceName given above Installers.Add(process); Installers.Add(service); Als laatste stap dien je de zaak te configureren in de App.Config. Dit kan in principe op dezelfde manier als dat je WCF Service staat geconfigureerd. Daarnaast dien je er rekening mee te houden dat alle Endpoints opgenomen dienen te zijn in de App.Config. Wanneer dat gebeurd is, kan je de Windows Service compileren in een Service Executable. Gebruik vervolgens het installutil commando om de Windows Service te installeren. Bijvoorbeeld als volgt: installutil c:\users\guidos\desktop\someservice\bin\somewindowsservice.exe Daarna is je service beschikbaar binnen services.msc, en kan je deze naar hartelust activeren / deactiveren. Kom altijd met honger naar het feest Wanneer je al gegeten hebt, en je gaat naar een feest, dan is dat altijd zuur. Meestal is het namelijk zo dat de gastheer ervoor gezorgd heeft dat er genoeg versnaperingen (liquide (zowel alcoholisch als non-alcoholisch) als vaste) aanwezig zijn. Zo is het ook met het consumeren (gebruiken / implementeren) van WCF Services. Er zijn meer dan genoeg smaken voor iedereen. Naast dat je natuurlijk op vele verschillende wijzen je Service (WCF of niet-wcf) kan aanbieden, kan je hem ook op verschillende manieren gebruiken in je client applicaties. Het is uiteraard ook hier weer afhankelijk van verschillende factoren voor welke manier je kiest. In de basis komt het er op neer dat je een Proxy class wilt hebben voor je Service, waarmee je kan communiceren in code. Het maken van een Proxy class kan op verschillende manieren. Het boek start met een commandline tool van Visual Studio, omdat je daar de meeste 'vrijheid' in hebt. Deze behandel ik echter maar kort, omdat we (althans ik) deze in de praktijk nauwelijks gebruiken om verbinding te maken met een Service. De tool in kwestie heet 'svcutil', waar je een heel batterij aan parameters aan mee kan geven, om vervolgens tot de conclusie te komen dat de 'Add Service Reference' menu-optie in het 13

14 contextmenu van je Project in de Solution Explorer van Visual Studio hetzelfde doet, alleen dan met een UI. Welke van de twee je ook kiest, je dient voor beide hetzelfde op te geven: een outputfile, een namespace en een adres. Wanneer je deze parameters allemaal kan vullen, heb je in principe genoeg om je Proxy class te maken. Je kan eventueel ook nog aangeven of de tool de asynchrone methods ook moet genereren voor je (hier komen we zo op terug). Natuurlijk heb je ook de optie om zelf een Proxy class te maken. Als we van onze Service uitgaan die we eerder hebben gemaakt, kunnen we deze Proxy class als volgt definiëren. public class SomeServiceProxy : ClientBase, ISomeService public SomeServiceProxy(Binding binding, EndpointAddress epaddr) : base(binding, epaddr) public SomeServiceProxy(string endpointconfigurationname) : base (endpointconfigurationname)) //The actual implementation of the Service's Interface public ContactInfoResponseMessage GetProviderContactInfo(ContactInfoRequestMessage reqmsg) return this.channel.getprovidercontactinfo(reqmsg); Zoals je ziet is ook dit niet heel lastig. Let erop dat als je members hebt die een Duplex Message Exchange Pattern (MEP) gebruiken, voor twee-wegs communicatie, je de Proxy class van de DuplexClientBase moet laten afstammen. Let er tevens op dat je de configuratie van je Service goed moet hebben in je.config bestand. Naast dat we op deze manier handmatig een Proxy class kunnen maken, kunnen we dit ook dynamisch doen, wat inhoudt dat we dit in-memory doen, en dus geen fysiek bestand schrijven. Dit doen we met de zogenaamde ChannelFactory class (zoals je wellicht al in bovenstaande code zag, implementeert de ClientBase/DuplexClientBase al een instantie van de ChannelFactory class met de property Channel). De implementatie is als volgt (Console Application). 14

15 Binding binding = new NetTcpBinding(); ChannelFactory factory = new ChannelFactory(binding, "net.tcp://localhost:8001/someservice"); try ISomeService proxy = factory.createchannel(); ContactInfoRequestMessage reqmsg = new ContactInfoRequestMessage(); reqmsg.licensekey = "abc-1234-alpha"; ContactInfoResponseMessage respmsg = proxy.getprovidercontactinfo(reqmsg); Console.WriteLine("Contactinformation retrieved: Address: 0", respmsg.contactinfo. address); catch(exception ex) Console.WriteLine("Error: 0", ex.message); Je kan uiteraard variëren met de constructors van de Proxy class (er zijn immers twee standaard constructors) om te kijken hoe je de Proxy aanspreekt. Ik geef persoonlijk de voorkeur aan het laten genereren van de Proxy class door Visual Studio zelf. Deze kan je vervolgens eenvoudig implementeren binnen je applicatie om de Service aan te spreken..net 4.5 maakt het straks nóg gemakkelijker Een Service is over het algemeen altijd beschikbaar, maar net zoals bij alle 'externe' applicaties, kan ook deze hinder ondervinden (storingen in een netwerk, veel simultane processen, etc.). Daarnaast is het verstandig om je UI thread in je applicatie niet te laten wachten op resultaat van de Service. Dit is veelal storend voor de gebruiker, omdat deze dan het idee kan hebben dat de applicatie is vastgelopen (en dat gebeurt uiteraard zelden). Denk aan.net Framework 4.5! Het implementeren van asynchrone methods is straks heerlijk om te doen. Maar voor nu, eerst nog de vervelende implementatie zoals we hem nog even moeten kennen. Zoals ik al eerder vertelde, kan je aangeven binnen het "Add Service Reference" dialog of de svcutil commandline tool of de asynchrone methods ook gegenereerd dienen te worden. Dit wil je (bijna) altijd. Asynchroon werken is fantastisch. Nu onze Proxy class dus asynchrone methods (de asynchrone methods beginnen met een prefix, resp. Begin- en End-) bevat, gaan we deze zo implementeren dat het ophalen van de data nu ook asynchroon verloopt. Dit kan wederom vrij eenvoudig, op de volgende manier (Console Application). 15

16 static void Main(string[] args) SomeServiceClient proxy = new SomeServiceClient(); ContactInfoRequestMessage reqmsg = new ContactInfoRequestMessage(); reqmsg.licensekey = "abc-1234-alpha"; AsyncCallback cb = new AsyncCallback(HandleCallback); proxy.begingetprovidercontactinfo(reqmsg); Console.WriteLine("Requestmessage submitted asynchroniously. Awaiting callback."); static void HandleCallback(IAsyncResult result) SomeServiceClient proxy = (result.asyncstate as SomeServiceClient); ContactInfoResponseMessage respmessage = proxy.endgetprovidercontactinfo(result); Console.WriteLine("Contactinformation retrieved: Address: 0", respmsg.contactinfo. address); Dus. Zo eenvoudig kan het zijn. Nu is het altijd een goed idee om je Proxy classes te 'closen' (de Close() method callen dus), en beter nog om ze te disposen (de Dispose() method callen). Zo Duplex Channels. Als je Service gebruik maakt van de Duplex Message Exchange Patterns (kortom: hij verstuurd ook uit zichzelf informatie), dan kan je deze ook binnen je Proxy class integreren. Dit is echter wel een vrij tricky geheel. Allereerst, zoals al aangegeven, dient je Proxy class van de DuplexClientBase af te stammen. Binnen de interface ISomeService dient een CallbackContract gedefinieerd te worden. Dit is het ServiceContract wat de Callback methods bevat. Je maakt dus om te beginnen een nieuw ServiceContract (interface) aan welke de methods bevat welke aangeroepen dienen te worden door je Service. //This interface is the interface which holds the callback methods //Inherit your custom class from this interface, and pass the instance //as a parameter of the InstanceContext Type to the constructor of the //Proxy class. [ServiceContract()] public interface ICallbackHandler //This is the method that will be called by the Service [OperationContract()] void InsertNewUsers(); 16

17 Vervolgens geef je binnen het ServiceContract van je Service aan welke interface het CallbackContract is. Dit doe je door het Type mee te geven aan de CallbackContract attribuut constructor, in de constructor van je ServiceContact. //Note that the CallbackContract holds a new interface //which will contain the methods that will be called by the Service [ServiceContract(CallbackContract(typeof(ICallbackHandler)))] public interface ISomeService [OperationContract()] [FaultContract(typeof(string))] public ContactInfoResponseMessage GetProviderContactInfo(ContactInfoRequestMessage reqmsg); Om deze vervolgens te kunnen gebruiken binnen je applicatie, maak je een class aan die van de CallbackContract interface afstamt. public class SomeClass : ICallbackHandler public void InsertNewUsers() //Handles the callback from the service; En als laatste geef je de Proxy een extra parameter in zijn constructors, en laat je deze afstammen van de DuplexClientBase. public class SomeServiceProxy : DuplexClientBase, ISomeService public SomeServiceProxy(InstaceContext instancecontext, Binding binding, EndpointAddress epaddr) : base(instancecontext, binding, epaddr) public SomeServiceProxy(InstaceContext instancecontext, string endpointconfigurationname) : base (instancecontext, endpointconfigurationname)) //The actual implementation of the Service's Interface public ContactInfoResponseMessage GetProviderContactInfo(ContactInfoRequestMessage reqmsg) return this.channel.getprovidercontactinfo(reqmsg); 17

18 Binnen je applicatie kan je de Service dan vervolgens aan je CallbackContract class (SomeClass) koppelen, op de volgende manier. static void Main(string[] args) SomeClass someclass = new SomeClass(); InstanceContext context = new IntanceContext(someClass); SomeServiceClient proxy = new SomeServiceClient(context, "net.tcp://localhost:8001/someservice"); //No need to call the callback method; The service does this for us //So implement the rest of the proxy here in a regular way (mentioned above) Zo. Dat was een intensief stuk code. Wat je hier ziet is dat het nog een vrij ingewikkeld proces is om een Duplex Proxy op te zetten. Eerlijk is eerlijk, ik heb (nog) geen idee of dit via de UI van het "Add Service Reference" dialoog venster kan of via de svcutil commandline tool. Excuseer, U bent niet van hier? Om te kunnen communiceren met een niet-wcf Service, hoef je alleen maar in de gaten te houden dat je alleen maar gebruik kan maken van de commandline tool en het dialoogvenster. Een eigen Proxy gaat nu eenmaal niet, omdat er wellicht zaken ontbreken die voor de Service benodigd zijn. Deze niet-wcf Services dienen aan bepaalde standaarden te voldoen uiteraard, maar de makers van de niet-wcf Service hun eigen definities aan de standaard hebben toegevoegd. De primaire standaarden zijn door de Web Services Interoperability Organization (WS-I) gemaakt. In principe is het van belang om je bindings altijd zo te configureren dat ze gebruik maken van de WS-I Basic Profile, welke standaard in de BasicHttpBinding zit. Configureer deze simpelweg in je EndPoints om hier gebruik van te maken. Over de rest zegt Microsoft: dat moet per geval even bekeken worden welke binding het meest geschikt is voor welke standaarden. Daar hou ik mezelf dus ook aan. De rest van de profiles valt in ieder geval onder de noemer WS-*. Weer een hele lap tekst, maar het valt ook niet mee om zaken summier uit te leggen, in nog enigszins begrijpelijke taal. WCF blijft een lastig begrip, maar mede door het schrijven van dit blog, ook weer voor mij een stuk helderder. We weten dus nu hoe we Services kunnen maken, hosten en gebruiken. Een van de volgende keren focust zich weer op het maken van een Service, welke gebruik maakt van het Entity Framework. Dit is geen examenstof, maar hiermee leg ik wel weer meer verbanden bloot tussen de verschillende examens. Bij vragen kan je uiteraard altijd mailen. 18

19 1 mei 2012: Verbanden met verbinden, heb ik een (ver)binding? Zo. Vorige keer waren we geëindigd met de conclusie dat we onze Service nu konden hosten, en weer consumeren. Daarnaast heb ik ergens in de eerste post vermeld dat ik bezig was met een overzicht van alle Bindings, in welke situatie deze het beste toepasbaar waren, welke eigenschappen ze hadden etc. Dames en heren, het moment is daar: we gaan dit schema in deze post behandelen. Wellicht dat ik het in toekomstige posts nog uitbreid. Wees gerust: ik update elke keer hetzelfde bestand, zo mis je (ook in deze post niet) geen enkele keer het overzicht compleet. Normaliter is het zo dat ik een tweetal hoofdstukken behandel (we zijn nu bij hoofdstuk 5 aanbeland), en ondanks dat dit een vrij beknopt hoofdstuk is, ga ik er toch heel diep op in, omdat de stof an sich verschrikkelijk lastig is om te bevatten. Tenminste, dat had ik. Het is enorm veel theorie, en het overzicht laat qua gemak ook wat te wensen over voor de leek, maar ik ga in ieder geval een poging wagen. Waar haal ik mijn prik vandaan? Zoals je wellicht nog kan herinneren, heb ik het al eerder gehad over het ABC van de Endpoints. Je dient hierbij in acht te nemen dat je zowel een Service-zijde (dus niet serverzijde!) als Client-zijde hebt. Deze worden echter aan beide kanten van de WCF ingericht; daarmee krijg je twee identieke configuraties, en kunnen de Service en de Client met mekander overweg. Als metafoor zou je de Service-zijde als een stopcontact kunnen zien, en de Client-zijde als de stekker. Bij dezen een schematisch overzicht hoe de configuratie in mekaar steekt (zie volgende pagina). 19

20 Afbeelding 2: Configuratie overzicht van de WCF Uit bovenstaande afbeelding kan je een aantal zaken die we al behandeld hebben aflezen, waardoor wellicht de structuur van de WCF wat duidelijker wordt. Zoals je ziet is dit een Service met meerdere Endpoints, en voor elk Endpoint een eigen Client. Daarnaast zie je de ServiceHost configuration staan. Dit is de host waar we het de vorige keer over hebben gehad. Zoals je begrijpt dien je dus voor de Client ook een ABC op te geven. We kunnen de A, het Address, als gegeven beschouwen, want als je dat niet weet, ben je in principe nergens. Ook hier is dit de locatie van de Service, in een URI vorm. Vervolgens kan je middels de Binding (het type verbinding) definiëren hoe de client dient te verbinden met de Service, en als laatste het Contract. Het Contract bepalen hebben we de vorige keer behandeld (het genereren van een Proxy is hier het gemakkelijkst). In mijn vorige post zei ik dus ook dat je voor het gemak de configuratie-instellingen van de Service over kon nemen. In principe is dat nu niet anders, maar het grote verschil is dat je ook natuurlijk dient te weten hoe je het e.e.a. kan configureren wanneer je dus tegen een Service praat die je zelf niet gemaakt hebt. Ik ben net snel over de Bindings heen gegaan, maar deze staan echter centraal in deze post. Een Binding is dus het type verbinding wat je gebruikt. Deze heeft natuurlijk een grote bak aan eigenschappen en configuraties, die je helemaal naar hartelust kan instellen. Je kan in principe ervan uitgaan dat alle bindings Custom Bindings zijn, maar Microsoft heeft een aantal shortcuts toegevoegd voor de meest gebruikte Bindings. Deze zijn dus al van te voren gedefinieerd, en daar gaan ze met 100% zekerheid vragen over stellen op het examen. 20

21 Allereerst het volgende. Een Binding kan je onderscheiden door een aantal eigenschappen naast elkaar te leggen, denk hierbij aan de ondersteuning voor Duplex (twee-wegs Binding), veiligheid, en bijvoorbeeld protocol (http, https, tcp, etc.). Ik heb voor het gemak een (engelstalig) overzicht gemaakt, met daarin alle voorafgedefinieerde Bindings van.net 4.0. Een volledige lijst van bronnen is te vinden onder de tabel (en het is echt de moeite waard deze te bestuderen). Afbeelding 3: Bindings overzicht (zie bijlage) Een vrij intimiderende tabel (welke gaandeweg nog uitgebreid gaat worden) op het eerste gezicht, maar na enige studie vrij helder. Maar hoe ziet nu een configuratie eruit in code? We kunnen dit (zoals eigenlijk bij alle configuratie van de WCF) zowel doen in XML als in C#. Allereerst de XML van de Service, en daarna die van een Client. We proberen zo veel mogelijk het schema van aan te houden. Je definieert de configuratie uiteraard in je.config bestand. <System.ServiceModel> <services> <host> <baseaddresses> <add baseaddress=" /> <add baseaddress="net.tcp://localhost:8000/" /> </baseaddresses> </host> <endpoint address="someservice" binding="wshttpbinding" contract="isomeservice" /> <endpoint address="someservice" binding="nettcpbinding" contract="isomeservice" /> </services> </System.ServiceModel> 21

22 static void Main(string[] args) using (ServiceHost host = new ServiceHost(typeof(SomeService))) WsHttpBinding wsbinding = new WsHttpBinding(); NetTcpBinding nettcpbinding = new NetTcpBinding(); host.addserviceendpoint(typeof(isomeservice), wsbinding, " //Everything in the following endpoint configuration can //differ from the one mentioned above. host.addserviceendpoint(typeof(isomeservice), nettcpbinding, "net.tcp://localhost:8000/someservice"); host.open(); En nu de Client Endpoint configuraties in XML. Allereerst Endpoint 1, die de wshttpbinding gebruikt (het volledige adres van de Service is dan Als 'localhost' niet van toepassing is (de Service draait op een externe machine), dan dien je dit natuurlijk te vervangen door de DNS naam of het ip-adres van de Servicehost (bijv. <System.ServiceModel> <client> <endpoint address=" binding="wshttpbinding" contract="someserviceproxy.isomeservice" name="someserviceproxy" /> </client> </System.ServiceModel> static void Main(string[] args) EndpointAddress endpoint = new EndpointAddress(" //Please note that an actual Service Reference in your application IS REQUIRED, //Otherwise defining a Proxy in code is impossible SomeServiceProxy proxy = new SomeServiceProxy(new WsHttpBinding(), endpoint); En nu het tweede Endpoint (code staat op de volgende pagina). 22

23 <System.ServiceModel> <client> <endpoint address="net.tcp:// :8000/someservice" binding="nettcpbinding" contract="someserviceproxy.isomeservice" name="someserviceproxy" /> </client> </System.ServiceModel> static void Main(string[] args) EndpointAddress endpoint = new EndpointAddress("net.tcp:// :8000/SomeService"); //Please note that an actual Service Reference in your application IS REQUIRED, //Otherwise defining a Proxy in code is impossible SomeServiceProxy proxy = new SomeServiceProxy(new NetTcpBinding(), endpoint); Naast dat je uiteraard de standaard configuraties zoals hierboven kan definiëren, kan je deze ook uitbreiden met specifieke functionaliteit. Zo kan je bijvoorbeeld via de MetaData property binnen de configuratie van de client classes opgeven die aanpassingen doen op de zichtbare WSDL, en dus de beschikbare members van de Service aan kunnen passen. Deze classes worden dan eerst uitgevoerd alvorens je Proxy gegenereerd wordt. Let er dus op dat je je Proxy class opnieuw laat genereren wanneer je hier een aanpassing in gedaan hebt. Helemaal uit verband getrokken Configuratie is nooit leuk. Zo ook niet met WCF. Al hoop ik wel dat deze post weer verhelderend is geweest in het beter begrijpen van de WCF. Mijn advies is in ieder geval om de Binding tabel en het overzicht goed te bestuderen. Ik breid deze gaandeweg nog uit met nieuwe informatie. Volgende keer hoop ik een beetje off-topic te kunnen: WCF i.c.m. het Entity Framework & experimentele hosts (Windows Phone en XBOX 360). Bij vragen kan je uiteraard altijd mailen. 23

24 3 mei 2012: Practice makes perfect.. Goed, na veel geblogd te hebben over WCF, is het nu tijd om te kijken wat mijn vergaarde kennis allemaal in de praktijk oplevert. Wat ik in deze post ga doen, is iets wat ik al heel lang van plan was, namelijk het koppelen van het Entity Framework (voor winnaars) aan WCF. We beginnen natuurlijk met enkele vereisten. Voor het Entity Framework heb je (uiteraard) SQL Server 2008 nodig. Je kan hiervoor gewoon de Express variant van Microsoft zelf downloaden, helemaal gratis. Daarnaast krijg je van mij de omstreden Northwind database, welke je hier kan downloaden, of onderaan bij de Source Files. Zoals je wellicht weet wordt het Entity Framework behandeld in het MCTS : Microsoft Certified Technology Specialist.Net Framework 4, Web Applications certificaat alsmede het MCTS : Microsoft Certified Technology Specialist.Net Framework 4 Accessing Data certificaat. In mijn optiek is dit Framework een briljant stuk programmatuur, wat enorm veel zaken voor je uit handen neemt m.b.t. het maken van de basis CRUD operaties. Uiteraard zijn er weer diverse methodieken beschikbaar om dit uit te breiden etc., maar daar kom ik t.z.t. wel weer op terug (wanneer ik daadwerkelijk bezig ben met ). Je dient dus basiskennis te hebben van het Entity Framework. Start me up! Goed, laten we dan nu beginnen, met een verschrikkelijk eenvoudige opzet. Wat we willen gaan maken is een Service die me gewoon een paar records teruggeeft uit de database. Echter dienen we die Service nog te hosten, en een client applicatie te schrijven die communiceert met de Service. We beginnen met het maken van de Service. Kopieer om te beginnen de (eventueel gedownloade) database naar een eenvoudige map, en Attach deze binnen SQL Server. Start vervolgens Visual Studio* op, en kies voor een nieuw Project. We kiezen voor een WCF Service Library, geven het beest een naam, en gaan verder. Visual Studio zal nu alvast een basis Service opzetten, welke je kan testen door simpelweg op F5 te knallen. Kies vervolgens binnen je Solution Explorer onder het contextmenu voor 'Add > New Item..'. Kies voor 'ADO.Net Entity Model'. Ga vervolgens op zoek via de wizard naar je database server (meestal is dit.\sqlexpress) en je database. Selecteer vervolgens welke items je wilt hebben (over het algemeen alle tabellen en views), en druk op 'OK'. Visual Studio zal nu het Entity Model maken op basis van je database. De kracht zit hem in het feit dat je dus nu zelf geen code meer hoeft te schrijven die communiceert met de database. We hebben nu dus een Service, welke een Entity Model in zich heeft. We moeten alleen nog tegen onze Service vertellen dat hij members van dit Entity Model moet exposen. Dit doen we dus gewoon heel simpel, door een [OperationMember] toe te voegen aan het Contract (zoals ik in de eerste post uit deze serie vertelde). Implementeer deze in de class(es) die het Contract implementeren. Dit kan bijvoorbeeld op de volgende manier. 24

25 public string GetCategoryName() NorthwindEntities e = new NorthwindEntities(); Console.WriteLine("Retrieving Categories"); string returncat = e.categories.first().categoryname; Console.WriteLine("Category 0 retrieved", returncat); return returncat; public Region GetFirstRegion() Region returnregion = null; Console.WriteLine("Retrieving Region"); using (NorthwindEntities e = new NorthwindEntities()) // This is an essential line of code. // Otherwise no object from the // Entity Model can be returned. e.contextoptions.lazyloadingenabled = false; returnregion = e.region.first(); // Write to the console. This is a little logging feature, // so we can keep track of our code while the service is hosted Console.WriteLine("Region 0 retrieved", returnregion.regiondescription); return returnregion; Voeg nadat je dit gedaan hebt, en je 'solution' buildt, een Console Application toe. Zoals ik al eerder vermeld heb, is het mogelijk om een Service te hosten vanuit Console Applications. Voeg een 'gewone' referentie toe aan je project*, zodat je deze kan gaan hosten. Om het zo simpel mogelijk te houden, maken we een implementatie, waarbij we de Endpoints configureren in code. Ik vind dit persoonlijk eenvoudiger om te doen, maar je kan ze uiteraard ook gewoon in je app.config configureren (al dien je deze wel eerst even toe te voegen aan je Console Application). 25

26 static void Main(string[] args) Uri baseaddress = new Uri(" using (ServiceHost host = new ServiceHost(typeof(NorthwindTestService.Service1), baseaddress)) // Enable metadata publishing. ServiceMetadataBehavior smb = host.description.behaviors.find(); if (smb == null) smb = new ServiceMetadataBehavior(); smb.httpgetenabled = true; host.description.behaviors.add(smb); host.addserviceendpoint(typeof(northwindtestservice.iservice1), new WSHttpBinding(), ""); host.addserviceendpoint(servicemetadatabehavior.mexcontractname, MetadataExchangeBindings.CreateMexHttpBinding(), "mex"); // Open the ServiceHost to start listening for messages // on the configured endpoints. host.open(); Console.WriteLine("The service is ready at 0", baseaddress); Console.WriteLine("Press <Enter> to stop the service."); Console.ReadLine(); // Close the ServiceHost. host.close(); Als het goed is, buildt en runt je solution nu. Run deze nu ook, en laat hem even staan draaien, we hebben hem direct nodig. We zijn nu al een heel eind gekomen, en dienen alleen nog 'de andere kant van de lijn' op te zetten. Start een nieuwe instantie van Visual Studio, en maak een nieuwe Console Application aan. Als het goed is staat je Servicehost nu te draaien, dus voeg een Service Reference toe in je nieuwe Client naar de Service (die je dan dus kan vinden op Wat mij opviel is dat het erg gaaf is dat objecten nu 'over de lijn' gaan. Zo kan je binnen je Client Endpoint praten met het Region object, en je hebt dus ook alle members beschikbaar van dat object. In onderstaande code laat ik een simpele Client implementatie zien. 26

27 static void Main(string[] args) // The ServiceReference1 namespace can be chosen when adding the Service Reference to the // solution. Please remind yourself that any time you make an adjustment in your service, // you need to update the service reference. using (ServiceReference1.Service1Client proxy = new ServiceReference1.Service1Client()) Console.WriteLine("Retrieved categoryname: 0", proxy.getcategoryname()); Console.WriteLine("Retrieved region: 0", proxy.getfirstregion().regiondescription); Console.ReadKey(true); Als je Servicehost nog aan het draaien is, kan je nu simpelweg deze Console Application ook starten. Als het goed is zie je nu het volgende resultaat. Mocht dit niet zo zijn, dan kan je de app.config even bekijken, en in principe de configuratie van je Endpoint (deze is gegenereerd door Visual Studio) vervangen door de volgende configuratie (deze is wat beknopter, en daardoor meteen wat overzichtelijker). <system.servicemodel> <client> <endpoint address=" binding="wshttpbinding" contract="servicereference1.iservice1"> </endpoint> </client> </system.servicemodel> En dat was het! Redelijk eenvoudig dus. Wat me opviel was in ieder geval het volgende. Het Entity Framework maakt binnen je EntityModel gebruik van [DataMemberAttribute] in plaats van bijvoorbeeld [DataMember]. Heb even wat research gedaan, en wees gerust: dit is hetzelfde. Je kan alle members van je Contract in principe ook voorzien van de 'Attribute' postfix. Dat maakt verder geen verschil. Vergeet in ieder geval niet de Source te downloaden mocht je er niet uitkomen. Bij vragen kan je in ieder geval altijd even een sturen of een bericht achterlaten op Facebook. Nog even wat anders: heb dus geprobeerd om een Service te hosten via Windows Phone, maar dat kreeg ik niet voor mekaar. Daarnaast nog geprobeerd om via de XBOX360 een Service te hosten, en codetechnisch gezien doet alles het, de solution buildt ook, maar ik kon deze alleen niet testen wegens het gebrek aan een XBOX360 op kantoor. *Een restrictie van Visual C# Express Edition is dat je alleen maar met single-project solutions kan werken. Je kan nog steeds de opzet zoals hierboven aangegeven volgen, maar dan dien je wel een extra instantie van Visual C# te openen, en de referentie niet naar het Service Project te leggen, maar naar de bin\debug.dll assembly. 27

28 4 juni 2012: Implementing Alcatraz Het (grootste) gevaar van computervirussen, malware en spyware is dat dit ontwikkeld en gebruikt wordt zonder dat mensen dit in de gaten hebben. Ik heb zojuist een interview gelezen met een van de heren bij Kaspersky, over hoe ze achter een van de grootste, meest uitgebreide en best geïmplementeerde virussen zijn gekomen. Hij vertelt in dit interview hoe het virus in mekaar zit, wat het doet, en waarvoor het gebruikt zou kunnen worden. Er wordt gespeculeerd dat dit virus niet van 'simpele' criminelen (die eigenlijk alleen achter geld aan gaan) en activisten (de 'Greenpeace' organisaties zoals bijv. Anonymous), maar dat dit ontwikkeld is door een land. Daarom is het van essentieel belang dat alle software die je maakt goed beveiligd moet zijn. Uiteraard is het niet zo dat je je software voor alles kan beschermen, maar je kan het virussen, malware en spyware applicaties wel heel lastig maken bij je data te komen. En daarom dus nu een post gewijd aan het implementeren van Security, Authentication en Authorization in de WCF. Security Binnen de WCF zijn er twee soorten van security: transport- en messagesecurity. Bij Transportsecurity komt het er eigenlijk op neer dat de Binding, dus de verbinding ('the wire') wordt beveiligd, waar het bij Messagesecurity draait om de boodschap die er overgedragen wordt. We zullen eerst kijken hoe een verbinding beveiligd kan worden, waarna we vervolgens gaan zien hoe we onze boodschap kunnen beveiligen. Transportlevel security Het vervoeren van een delicate vracht gebeurt in het echte leven via bewaakte routes, en soms met een politie/leger escorte. Zo is het ook in de WCF het geval. De bindings die je kan gebruiken binnen de WCF om het transport van je message te beveiligen hebben onder water een set aan binding elements die maken dat de binding de transport security ondersteunt. Daarnaast is het mede afhankelijk van het protocol wat de binding gebruikt of dit type beveiliging beschikbaar is. Als laatste factor dien je de client-endpoints in gedachten te houden, aangezien je in sommige gevallen met je Service met niet-wcf endpoints kan communiceren. Het configureren van Transportlevel security kan verbazingwekkend eenvoudig (mits je van de 'out-ofthe-box' bindings gebruik maakt). Binnen de binding declareer je een <security> element, waarbij je het mode attribuut op 'Transport' zet. Binnen dit element kan je dan vervolgens het type beveiliging aangeven. In onderstaand voorbeeld maken we gebruik van een simpele basichttpbinding. <basichttpbinding> <binding name="transportsecuritybinding"> <security mode="transport"> <transport clientcredentialtype="basic" proxycredentialtype="basic" realm="contoso" /> </security> </binding> < /basichttpbinding> Let er op dat de waarden van het clientcredentialtype attribuut afhankelijk zijn van het type binding wat je gebruikt, wat voor EndPoints je hebt, etc. Tevens heeft dit te maken met het Protocol 28