Door Dik Bijl, Enterprise Architect, Microsoft Nederland
In dit zesde en voorlaatste artikel komen we (eindelijk) toe aan de Microsoft technologieën voor SOA en webservices. Het vorige artikel gaf een overzicht van het complete platform en daarbij werd duidelijk dat Microsoft een ‘big bet' heeft gezet op het welslagen van webservices door het op de nemen in de kern van zijn softwarestrategie. Die keuze voor webservices lijkt nu misschien evident, maar een jaar of zeven terug was dat nog zeker niet het geval.
De strategie die Microsoft hanteert voor web services is steeds de volgende:
- werk samen met andere ICT-leveranciers om de specificaties vast te leggen en te laten standaardiseren
- probeer zelfstandig de beste implementatie te maken van webservices zowel in kwaliteit als op het vlak van eenvoud in gebruik en prijs/prestatie
En die implementatiestrijd is niet alleen Microsoft aangegaan, maar ook de competitie. Het is een strijd waar in elk geval een zekere winnaar is: de klant, want die is gebaat bij én standaardisatie én bij competitie. Maar natuurlijk hoopt en verwacht Microsoft ook tot de winnaars te behoren.
In dit artikel kijk ik naar wat Microsoft te bieden heeft op SOA/webservicesvlak. Het voert te ver om alle producten en technologieën te bespreken; ik beperk me dan ook tot de voornaamste technologieën en daarbinnen weer tot waar die technologieën SOA en webservices ondersteunen. Aan het eind van het artikel is een aantal links opgenomen waar u meer informatie over de afzonderlijke producten en technologieën kunt krijgen.
Ik ga een en ander als volgt bespreken: allereerst is er het onderscheid tussen het aanbieden van webservices en het consumeren van webservices. Ik begin met de eerste categorie en daarbinnen is weer een driedeling te zien: het maken van webservices van scratch af aan, het inkapselen van bestaande applicaties als webservices, en het orkestreren van webservices tot samengestelde applicaties die business-processen uitvoeren of ondersteunen.
Het maken van nieuwe webservices: .NET Framework, ASP.NET en VS.NET
.NET Framework is Microsoft's primaire ontwikkel- en runtime-omgeving waarmee iemand Windows-gebaseerde applicaties kan maken die relatief eenvoudig te bouwen, te implementeren, te beheren en te integreren zijn met andere ‘network aware'-systemen. Uit artikel 5 bleek dat het .NET Framework samen met het Windows-besturingssysteem de kern van Microsoft's softwaretechnologie is.
Figuur 1: Het .NET Framework
Het .NET Framework (zie figuur1) bestaat uit:
- The Common Language Runtime (CLR)
- De runtime omgeving waarbinnen .NET applicaties uitgevoerd en bestuurd worden zoals het laden, JIT-compileren, uitvoeren van beveiligingscontroles en ‘garbage collection'
- The Framework Class Libraries (FCL)
- Een rijke, consistente, object georiënteerde bibliotheek van functies/klassen
Microsoft onderscheidt zich van de concurrentie - met name het Java-kamp - door een aantal aspecten; ik noem er twee. Microsoft .NET ondersteunt niet één maar meerdere programmeertalen. Sommige van die talen worden geleverd en ondersteund door Microsoft, zoals C# (spreek uit: C-sharp) en VB.NET, maar andere talen worden aangeboden door derde partijen zoals bijvoorbeeld Cobol, Perl, RPG en Smalltalk.
De truc zit hem daar in dat al die talen compileren naar een intermediate language (IL) die dan door de CLR wordt gecompileerd tot een executable en uitgevoerd. Dus een derde partij kan een willekeurige taal naar .NET brengen door een compiler te maken die de taal omzet naar IL. De lijst met ondersteunde talen loopt inmiddels in de tientallen.
Het tweede aspect dat ik wil noemen is de ondersteuning voor XML en webservices. Die ondersteuning is er niet - zoals bij Java - in de loop der tijd aangeplakt, maar zat in het ontwerp van .NET vanaf het begin; kijk maar naar figuur 1. De set van klassen die daarbij in het oog springt is .ASP.NET. Dat is het onderdeel van de bibliotheek dat gebruikt wordt om webapplicaties te bouwen die in de omgeving van Microsoft's webserver - Internet Information Services; onderdeel van het Windows besturingssysteem - geplaatst en uitgevoerd worden.
Er zijn twee soorten webapplicaties. Allereerst Web Forms die vanuit een browser aangeroepen worden: de traditionele webapplicaties zal ik maar zeggen met een HTML user interface. Daarnaast heb je webwervices die je ook zou kunnen omschrijven als applicaties die ‘SOAP callable methods' bieden. Het zijn webapplicaties zonder user interface, want de consument van een webservice is een softwareprogramma en geen mens, maar met een webservice interface, namelijk SOAP-methoden.
Als we deze zaken combineren: het maken van nieuwe applicaties in een taal naar keuze en het ‘exposeren' van applicaties als webservices via ASP.NET, dan is daarmee direct duidelijk hoe je binnen de .NET omgeving heel eenvoudig nieuwe webservice applicaties kunt maken.
De ontwikkeling gaat door: Web Service Enhancements (WSE)
Toen het .NET Framework in 2000 gelanceerd werd en later in 2003 er een tweede versie kwam (versie 1.1), was de ondersteuning van webservices heel ‘basic': SOAP en WSDL. De hogere niveaus van de webservicesarchitectuur werden daarin nog niet ondersteund, eenvoudig omdat die toen nog niet beschikbaar waren.
In artikel 4 is de webservicesarchitectuur besproken en aangegeven dat die in de loop der jaren steeds verder uitgebreid is en nog wordt. Zodra een specificatie uit die architectuur volwassen genoeg is en bijna standaard, beginnen de diverse leveranciers het te ondersteunen in hun technologie; vaak door het bieden van toevoegingen op de bestaande technologie. Zo komt er geleidelijk meer en meer ondersteuning voor de webservicesarchitectuur beschikbaar. Zo ook bij Microsoft.
Microsoft noemt deze uitbreidingen: Web Services Enhancements (WSE). Microsoft positioneert WSE vooral als experimenteel. Architecten en ontwikkelaars kunnen daarmee rijkere webservices produceren, maar de webservices ontwikkeling en verandering gaat door. Daardoor kan Microsoft bijvoorbeeld geen terugwaartse compatibiliteit garanderen voor WSE. Dus een latere WSE versie kan een herschrijven van een webservice gebaseerd op een eerdere versie betekenen; iets wat je in een bedrijfskritische omgeving niet wilt.
Op het moment van schrijven is WSE 2.0 de laatste versie (zie ook link aan het eind van het artikel). WSE2.0 ondersteunt bijvoorbeeld de specificaties ws-security, ws-policy en ws-adressing.
WSE kan mooi worden toegevoegd aan het bestaande .NET Framework vooral vanwege de in artikel 4 beschreven ‘composability' van webservices. De nieuw ondersteunde specificaties worden met name aan de header van het SOAP-bericht toegevoegd en die zijn onfahankelijk van de body (de inhoud) van het SOAP-bericht maar ook onafhankelijk van de andere headers. Figuur 2 toont aan dat die headers dan door een pipeline-mechanisme (dit is een beproefd ‘design pattern') worden verwerkt en dat dat mechanisme bovenop het bestaande .NET Framework wordt toegevoegd.
Figuur 2: WSE input pipeline
De naaste toekomst: Indigo
De kans is groot dat u al eens de term Indigo hebt horen vallen. Waar WSE een tijdelijke, bijna ‘wegwerp'-uitbreiding is op het .NET Framework en vooral bedoelt om vingeroefeningen met geavanceerde webservices te doen, daar is Indigo de realisatie van de visie van een nieuwe communicatie-infrastructuur die gebaseerd is op een volledig servicegeoriënteerd programmeermodel en de volledige webservices architectuur implementeert. En dat leidt tot het ontwikkelen van veilige, betrouwbare en transactiegestuurde webservices.
Indigo is echter meer dan dat: het is ook de samenvoeging van voorheen verschillende manieren om gedistribueerd te programmeren. Het is de samenvoeging van verschillende technologieën zoals webservices, .NET remoting, asynchroon messaging (met MSMQ) en .NET enterprise services (security, transactions, etc) tot een enkel programmeer (en denk) model. Indigo betekent een enorme vereenvoudiging voor de ontwikkelaar en deze is daarmee veel beter in staat robuuste, betrouwbare servicegebaseerde applicaties te ontwikkelen.
Figuur 3: samenvoeging van gedistribueerde technieken bij Indigo
Indigo zal beschikbaar zijn in het Longhorn timeframe voor Windows Longhorn, maar ook voor Windows Server 2003 en Windows XP.
Inkapselen en Orkestratie van webservices: BizTalk Server
Waar het .NET Framework met WSE en op termijn Indigo belangrijk is voor het ontwikkelen van nieuwe webservices, daar is BizTalk Server dé technologie voor het inkapselen van bestaande toepassingen - legacy - als webservices, maar ook voor het orkestreren van losse webservices tot samengestelde of ‘composite' applicaties. Die samengestelde applicaties ondersteunen business-processen, vandaar dat je BizTalk mag rekenen tot de categorie BPM-servers (Business Process Management Servers).
BizTalk Server is heel groot en omvangrijk. Ik ga er voor dit artikel slechts wat aspecten voor webservices uitlichten en doe dat aan de hand van de twee plaatjes die hieronder zijn afgebeeld. Het eerste plaatje laat de architectuur van BizTalk server zien; het tweede plaatje toont een orkestratie, met andere woorden een samengestelde applicatie, een stukje business proces.
Figuur 4: BizTalk Server Architectuur
Figuur 5: BizTalk Server Orkestratie
De architectuur laat zien dat BizTalk Server op de een of andere manier berichten (‘documenten') binnenkrijgt, daar iets mee doet en vervolgens weer berichten uitstuurt. Het ontvangt die berichten van externe applicaties en stuurt die berichten naar externe applicaties. Daartussenin bestuurt BizTalk het business-proces.
Een binnenkomend bericht kan een webservice zijn, maar dat hoeft niet. Het kan een IDE bericht zijn, een e-mail, een bestand, een bericht uit SAP of wat dan ook. Het bericht komt links binnen (inbound) en wordt door een adapter opgepakt en via de pipeline (zie eerder; een design pattern om onafhankelijke bewerkingen uit te voeren op een bericht/dcument) gedecodeerd, op security gechecked, vertaalt en omgezet naar een XML-bericht. BizTalk werkt intern namelijk uitsluitend met XML-berichten. De adapter ‘spreekt' de taal van het externe systeem dat het bericht verstuurde. Zo'n adapter kan SOAP spreken, maar ook HTML, SAP, Peoplesoft, SMTP of wat dan ook; er bestaan vele tientallen adapters voor BizTalk en een developer kit om zelf adapters te maken.
Het XML-bericht komt in de message store (een SQL Server database) terecht en triggert een orkestratie die op dit type bericht staat te wachten. De orkestratie kijkt wat de volgende stap is in het business-proces, leidt het door eventuele beslismomenten en bedrijfsregels, werkt de status van het proces bij en stuurt het bericht na uit naar een ‘outbound' port waar het XML-bericht op omgekeerde wijze als bij het binnenkomende bericht wordt getransformeerd: vertaalt, security attributen erbij, eventueel gecodeerd en dan via de juiste adapter uitgestuurd naar een externe applicatie in de taal van die applicatie.
De afgebeelde, uiterst eenvoudige orkestratie laat zien dat het business proces geïnitieerd wordt door een verzoek (‘request') dat binnenkomt. Van dat binnenkomende verzoek wordt het aantal bepaald en op basis van het aantal wordt het verzoek afgewezen en of geaccepteerd. Wordt het afgewezen dan wordt een afwijzing geconstrueerd en verzonden naar een externe applicatie, bijvoorbeeld een mail server. Wordt het geaccepteerd, dan wordt er een bericht naar een ERP systeem verzonden; einde orkestratie.
Deze orkestratie kan als een webservice worden aangeboden en daarmee is het achterliggende ERP systeem meteen ingekapseld als webservice; indirect wel te verstaan, namelijk verborgen in de orkestratie. Omdat de orkestratie als webservice wordt aangeboden kan in principe iedere bevoegde deelnemer aan het business-proces een webservice-request (SOAP-bericht) samenstellen en sturen naar het adres (URL) waarop de orkestratie als webservice geplaatst is.
Met andere woorden: BizTalk ‘tovert' de bestaande legacy om in een SOA door orkestratie en inkapseling (via adapters) van bestaande systemen. Evenzo kan BizTalk nieuw ontwikkelde webservices opnemen in een orkestratie; immers een van de adapters is een webservices adapter (gebaseerd op ASP.NET en WSE).
Over BizTalk valt zeer veel te vertellen en dat valt helaas buiten de scope van dit artikel: bijvoorbeeld over Business Activity Monitoring (BAM), Human Workflow Services, de schaalbaarheid/beschikbaarheid en de management tools. Onderin is een aantal links opgenomen waarin u meer over BizTalk te weten kunt komen.
Ik beschouw BizTalk zelf als het belangrijkste SOA-instrument dat Microsoft rijk is en dat straks in combinatie met Indigo helemaal een ijzersterk koppel gaat vormen.
Het consumeren van webservices
We hebben nu technologieën genoemd waarmee webservices kunnen worden gemaakt en aangeboden. Het aanbieden van een webservice heeft natuurlijk pas zin als deze ook geconsumeerd wordt.
Voor een deel zit de consumptie van webservices in het model van samengestelde applicaties of samengestelde webservices. Zo is BizTalk Orchestrator veelal een consument van webservices en kan iedere webservice kan zelf weer een of meerder webservices aanroepen.
Maar in dit stukje wil ik software bespreken die webservices consumeren en de interactie aangaan met eindgebruikers zoals u en ik. Ik maak daarbij een onderscheid in thin client consumers en smart client consumers.
Het consumeren van webservices (A): thin client
Bij thin client web services consumers gaat het om oplossingen waarbij de client meestal een browser applicatie is: het gaat dan in de regel om wat we web applicaties noemen. Het voordeel daarvan is dat een web applicatie weinig resources veronderstelt op het client platform en deze dus voor een breed scala aan platforms geschikt is. Maar er kleven ook nadelen aan. De applicatie kan vaak alleen online benaderd worden, het client platform wordt niet optimaal benut en er kan moeizamer gebruik gemaakt worden van randapparaten als scanners, printers, barcode-lezers, opslagsystemen en wat dies meer zij.
ASP.NET is de eerst aangewezen technologie om webapplicaties mee te maken. Dan gaat het niet om de webservices technologie van ASP.NET (met extensie .asmx) maar de web forms technologie (met extensie .aspx). Vanuit zo'n web form applicatie kan dan een webservice worden aangeroepen. De webservice retourneert een SOAP bericht en de web form presenteert de informatie op het scherm aan de gebruiker, of vice versa: vanaf het web form wordt een SOAP request opgebouwd en de achterliggende web service aangeroepen.
Het gaat hierbij om ‘platte' web forms. Een andere oplossing is het gebruik van een Enterprise Information Portal zoals Microsoft SharePoint Portal Server. In zo'n portal wordt gewerkt met ‘web parts' die je kunt zien als een window op achterliggende applicaties, waaronder web services. Onderstaande figuur toont een pagina met 4 web parts (rood omlijnd).
Die web parts kunnen worden onderling gesynchroniseerd dat wil zeggen de ene web part haalt zijn informatie uit een web service die klantinformatie ophaalt, de tweede web part haalt voor die klant uit een andere web service de uitstaande bestellingen op, de derde web part de klachten van die klant etcetera. Overigens worden die web parts zelf weer geprogrammeerd met ASP.NET technologie.
Figuur 6: SharePoint Portal Server met web parts
Het consumeren van web services (B): smart client
Een smart client applicatie maakt wel optimaal gebruik van de resources van het client platform, het kan de randapparaten goed aansturen en de applicatie kan offline beschikbaar zijn. Microsoft heeft hard gewerkt om de nadelen van de vroegere fat clients te ondervangen - zoals het problematische beheer van fat client applicaties - en is daarin goed geslaagd. Het beheren van en smart client is nagenoeg zo simpel als het beheren van een thin client applicatie, terwijl de user experience veel beter is.
Volgens Microsoft is er ruimte voor beide technologieën en is het afhankelijk van de situatie - de business case - welke technologie de voorkeur krijgt.
Smart client applicaties worden ook met het .NET Framework gebouwd en wel met Window Forms library (zie weer figuur 1). Ook van daaruit kan men webservices aanroepen en de informatie daarvan - net als bij ASP.NET web forms - op het scherm aan de gebruiker tonen; maar men kan ook een lokale cache gebruiken en die vullen met informatie uit webservices.
Die cache blijft dan offline bewaard als men dat wil en wordt in de achtergrond gesynchroniseerd met de webservices zodra er weer een connectie is met het internet. Smart client applicaties zijn dus niet alleen rijker in gebruik, maar ook flexibeler te gebruiken in online/offline scenario's.
Een ander vorm van smart client applicaties vind je bij Microsoft Office. Office begint zich meer en meer te ontwikkelen van een set van losse productiviteit-applicaties tot een ‘smart' en connected platform. Heel veel gebruikers ‘leven' binnen Office en doen de hele dag weinig anders dan Outlook, Word en Excel gebruiken. Maar zodra ze informatie van back office applicaties nodig hebben moeten ze SAP, Siebel of hun eigen homegrown applicatie opstarten, daar de gegevens uit opzoeken en die weer overbrengen in een brief, een spreadsheet of een email. Zou het niet veel handiger zijn als ze die back office gegevens direct vanuit hun Word, Excel of Outlook applicatie konden halen?
Dat is precies wat een relatief nieuwe technologie genaamd Information Bridge Framework (IBF) beoogd en het maakt daarvan uitsluitend gebruik van webservices. Het ‘tovert' Office om tot een smart client connected platform. Hoe werkt het?
Binnen een Office product zoals Word of Outlook wordt gebruik gemaakt van smart tags. Deze tags ‘sensen' dat een bepaalde lettercombinatie een betekenis heeft zoals een klantnaam, een klantnummer, een ordernummer of zoiets. Klikt men op dat woord dan komt er een pop up window en kan men voor die klantnaam de bijbehorende gegevens ophalen uit een of meer achterliggende systemen (ingekapseld als webservices) en tonen in een schermpje of in het document plaatsen.
Figuur 7: Information Bridge Framework at work
Het ontwikkelplatform: Visual Studio
Of het nu gaat om het maken van nieuwe webservices, het inkapselen van bestaande toepassingen als webservices, het orkestreren van webservices of het maken van ‘smart' of ‘thin' client toepassingen die webservices consumeren: het wordt allemaal ontwikkeld in Visual Studio.
Zoals in het vorige artikel betoogd is Visual Studio zich aan het ontwikkelen van “Integrated Development Environment" (IDE) naar een full blown “Application Lifecycle Management” (ALM) platform. Daarin is veel aandacht voor service georiënteerd ontwerp, ontwikkeling, test en beheer. Een van de nieuwe onderdelen van Visual Studio 2005 dat later dit jaar beschikbaar komt, is een aantal modelleer-tools waarbij een architect (web)services kan modelleren, deze kan koppelen aan andere (web)services en mappen (‘deployment') naar ook al gemodelleerde infrastructuur servers.
Figuur 8: VS.NET Modelleer omgeving
Tot slot
In dit relatief lange artikel heb ik toch maar heel summier en in vogelvlucht aandacht kunnen besteden aan de voornaamste SOA en webservices gebaseerde technologieën en producten van Microsoft. Onderaan vindt u een aantal links waarbij u zich wat verder kunt oriënteren en verdiepen. Ik denk dat een en ander aangeeft hoe diep SOA en webservices verankerd liggen in onze strategie en daarmee in onze technologie. En dat komt omdat Microsoft er al een jaar of zeven a acht mee bezig is. Veel langer dus dan de markt er rijp voor is; die marktrijpheid begint eigenlijk nu pas te komen.
Het zevende en laatste artikel gaat in op de ‘architectural guidance' en ‘best practices' die Microsoft biedt bij het opzetten en implementeren van op SOA gebaseerde oplossingen. En ook kijk ik naar een aantal praktijkvoorbeelden van het gebruik van SOA op basis van Microsoft technologie.
En met een korte terugblik zal ik (eindelijk) een punt zetten achter deze serie voor de Executive Circle website; en tegelijkertijd zal ik een nieuwe serie aankondigen. | 
