DEPARTEMENT TOEGEPASTE INGENIEURSWETENSCHAPPEN CAMPUS SCHOONMEERSEN - GENT
Uitgebreid voorstel Masterproef Informatica Datum: 1/11/2008 Naam student: Pieter Vancoillie Algemene informatie: Naam van het bedrijf: IBCN - INTEC - UGent Is er in het bedrijf inhoudelijke en technische begeleiding beschikbaar? beschikbaar Ja Externe promotor(en): prof. dr. ir. Filip De Turck E-mailadres mailadres externe promotor(en): promotor(en)
[email protected] Interne promotor: Veerle Ongenae
Titel van het project:: Dynamische conformiteitscheck tijdens de uitvoering van een web service choreografie
Bestaande situatie en probleemstelling: In de huidige geïnformatiseerde wereld zou men verwachten dat het eenvoudig is om een samenwerking tussen verschillende bedrijven te implementeren. Niets is minder waar. Momenteel wordt dit nog steeds gedaan via gecentraliseerde bedrijfsprocessen. Recentelijk wordt in dit domein onderzoek gedaan om een dergelijke samenwerking op een gedistribueerde istribueerde manier te implementeren. implementeren Men spreektt bij een gecentraliseerde oplossing over een orkestratie waarin de leidingnemende partij als dirigent fungeert en instructies geeft aan de andere partijen. Bij een gedistribueerde manier heeft men het over een choreografie. In choreografie ziet men de deelnemende lnemende partijen als dansers die een door een choreograaf ontwikkelde dans uitvoeren. Waar in de gecentraliseerde oplossing steeds één partij de leiding zal hebben over het bedrijfsproces, zullen de verschillende deelnemende partijen in een meer gedistribueerde gedist situatie een zekere autonomie vertonen. De dansers voeren de choreografie uit ontwikkeld door de choreograaf, maar deze geeft geen instructies tijdens het uitvoeren ervan in tegenstelling tot de dirigent van het orkest. Maar net dit verschil zorgt zorg voor bijkomende moeilijkheden. Een belangrijk voorbeeld hiervan is dat in de gedistribueerde oplossing de samenwerkende partijen nu nog moeten veronderstellen dat de anderen zich volledig houden aan alle afspraken gemaakt in het gedistribueerde bedrijfsproces. bedrijfsp Elke partij in de gedistribueerde omgeving moet kunnen controleren of de choreografie nog steeds conform de vooraf vastgelegde regels is. Hij moet dus de mogelijkheid hebben een conformiteitscheck uit te voeren. Binnen de onderzoeksgroep is een manier ontwikkeld om deze conformiteitscheck op een statische manier te doen. Deze methode kan gebruikt worden tijdens de ontwikkeling van een choreografie. Maar als de choreografie uitgerold is, kunnen de verschillende partijen misschien wijzigingen doorvoeren oeren aan hun implementatie, waardoor de uitvoering van de choreografie toch niet meer correct verloopt. Daarom is er ook nood aan een dynamische dynamisch conformiteitscheck, één die kan gebeuren tijdens de uitvoering.
1
Doelstelling van het project: In eerste instantie zal moeten onderzocht worden in welke mate de bestaande algoritmen geschikt zijn voor een dynamische conformiteitscheck. Er moet immers rekening gehouden worden met het feit dat de uitvoering van de choreografie niet té veel hinder mag ondervinden van deze testen. Na deze literatuurstudie zullen de bevindingen geïmplementeerd worden. Een belangrijk onderdeel van deze implementatie zal bestaan uit het efficiënt monitoren en onderscheppen van de verzonden en ontvangen berichten. Door middel van de onderzochte algoritmen en aan de hand van deze berichten zal dan moeten uitgemaakt worden of de uitvoering correct verloopt. Er zullen op de implementatie testen uitgevoerd moeten worden om de schaalbaarheid en de overhead van de algoritmen te achterhalen. In een verder stadium van de thesis zal een feedbackmechanisme ingebouwd worden om zo de andere partijen op de hoogte te brengen van een niet-conforme uitvoering van de choreografie. Dit is de eerste stap naar het opbouwen van een conformiteit-trust-netwerk. Het feedbackmechanisme moet mogelijk maken dat een partij een andere partij kan klasseren als vertrouwd of niet vertrouwd. De klassering zorgt voor een vertrouwensrelatie tussen beide partijen. Het conformiteit-trust-netwerk is een netwerk opgebouwd uit deze vertrouwensrelaties. Een bijkomende vereiste van dit feedbackmechanisme is dat alles via web service events moet gebeuren.
Gedetailleerde omschrijving van de opdracht: Het eerste deel van de opdracht bestaat uit een literatuurstudie omtrent de bestaande situatie. Binnen de onderzoeksgroep is een methode ontwikkeld die zorgt voor een statische conformiteitscheck. Deze methode introduceerde het piX-model (∏-eXchange model). Dit model is ontworpen voor het modelleren van webservice interacties beschreven als een WS-CDL (Web Service Choreography Description Language) choreografie. Dit model zal ook gebruikt worden bij de dynamische conformiteitscheck. Een literatuurstudie over dit model en alle aan dit model verwante technologieën, zoals ∏-calculus, de formele basis van het piX-model, is dus noodzakelijk. Webservice choreografieën kunnen formeel beschreven worden gebruik makende van WS-CDL. Uit deze beschrijving kan het piX-model opgesteld worden. Hiervoor is kennis van de WS-CDL en verwante technologieën vereist. Om een choreografie te kunnen uitvoeren zullen de verschillende spelers kennis moeten hebben van elkaars aanwezigheid en mogelijkheden op het netwerk. Hiervoor werd DPWS (Device Profile for Web Services) ontwikkeld. DPWS zorgt voor het veilig uitwisselen van berichten van en naar een webservice, het dynamisch vinden van een webservice, beschrijving van een webservice, de mogelijkheid zich te abonneren bij een webservice en er webservice events van te ontvangen. DPWS bepaalt welke webservice technologieën het netwerk moet ondersteunen. Het bepaalt ook welke de rechten en verantwoordelijkheden zijn van client en server. DPWS voorziet het gebruik van WSDiscovery voor het ontdekken van webservices die aangeboden worden op een netwerk. De dynamische conformiteitscheck zal ontwikkeld worden voor DPWS bewuste netwerken. WS-Eventing wordt gebruikt als standaard van het eventmechanisme. Dit zal gebruikt worden bij het opbouwen van een conformiteit-trust-netwerk. WSA of Web Service Addressing wordt gebruikt als adresseringsmechanisme. Zo weet een ontvanger van waar hij een bericht ontvangen heeft en naar waar het antwoord moet gestuurd worden. WSA voorziet ook de mogelijkheid om aan een bericht een bepaalde actie toe te kennen. De reactie van de ontvanger is specifiek voor een bepaalde actie. Verschillende ontvangers kunnen anders reageren op dezelfde actie. Deze actie zullen we gebruiken als geldende actie van een deelnemer binnen een choreografie. Om de mogelijkheden of beschrijving van een webservice te ontdekken voorziet DPWS Metadata exchange (WSMex). WSMex gebruikt WS-Transfer voor het uitwisselen van deze gegevens,
2
waaronder de webservice description. Kennis van DPWS en de daarin gebruikte webservice-standaarden is noodzakelijk. Er zal een geschikt platform moeten gekozen worden voor de implementatie van de dynamische conformiteitscheck. Dit platform zorgt voor een implementatie van een SOAP server. Zo is het mogelijk om SOAP-berichten te ontvangen en te versturen. Ook moet het instaan voor het hosten van de webservices. Zo kan het platform berichten, ter verwerking, afgeven aan een service. Platformen die in aanmerking komen zijn WS4D en Axis2. Het WS4D (Web Services for Devices) framework wordt ontwikkeld door de universiteit van Rostock, de universiteit van Dortmund en MATERNA. Dit framework verzorgt een DPWS stack voor C en diverse edities van Java. Axis2 van Apache zorgt voor een SOAP-implementatie en gebruikt AXIOM, een xml object model. Dit zorgt voor een krachtige manier om SOAP-berichten te analyseren. Axis2 is uitbreidbaar met modules. Enkele van de door DPWS gevraagde standaarden zijn reeds geïmplementeerd als module. We kunnen Axis2 nog niet DPWS ‘enabled’ noemen. Er zal een keuze moeten gemaakt worden op basis van de ondersteunde ws-* standaarden, op welke manier en in welke mate het analyseren van berichten kan gebeuren en de uitbreidbaarheid van het platform. De eerste stap in de implementatie zal het onderscheppen en monitoren zijn van de berichten. Dit is nodig omdat we willen conclusies trekken uit het berichtverkeer dat door een webservice ontvangen en verstuurd wordt. De methode hiervoor is afhankelijk van het gekozen platform, omdat elk platform het SOAP bericht in een door hem bepaalde objectstructuur zal gieten. Ook verschillen de manipulatiemogelijkheden van dat object per platform. De mogelijkheid om XPath queries te kunnen uitvoeren is hier een grote troef. Dit omdat informatie beschreven in een WS-CDL of WSDL file vaak te vinden is in de attributen van de XML tags. Ook worden onderlinge verbanden tussen XML tags gelegd via attribuutwaarden. Deze informatie opvragen kan eenvoudig via een XPath query. De equivalente oplossing, door te steunen op het DOM van het bericht, zorgt voor een foutgevoelig en een weinig onderhoudsvriendelijk resultaat. We zullen moeten weten over welk soort bericht het gaat om zo te weten welke informatie, relevant voor de dynamische conformiteitscheck zoals bv. de WSA actie, uit het berichten kan gewonnen worden. De informatie uit de berichten zal correct moeten worden aangewend. De kennis opgedaan over WS-CDL, WSDL, DPWS, wordt hier toegepast om informatie over een bepaalde actie in een choreografie bij te houden. Wanneer deze actie optreedt, moet deze informatie beschikbaar zijn. Ook zal moeten duidelijk zijn via de gevonden informatie over welke choreografie-instantie het gaat. Er kunnen namelijk meerdere choreografieën van hetzelfde type tegelijkertijd actief zijn. Het type wordt geïdentificeerd door de choreografiebeschrijving, wanneer deze choreografie wordt uitgevoerd spreekt men van een instantie van deze choreografie. Het is niet voldoende het type choreografie te herkennen; we moeten in staat zijn instanties van een bepaalde choreografie te identificeren. Identificatie is mogelijk doordat een choreografie-instantie zich steeds in een bepaalde staat bevindt. Ook zal een bericht, verstuurd in de context van een choreografie, zich identificeren aan de hand van één of meerdere tokens. Een token kan gezien worden als een naam-waarde paar. De waarde van de tokens correleren het bericht met een bepaalde instantie van een choreografie. Als een bericht niet kan gecorreleerd worden met een bepaalde instantie kan er een nieuwe instantie worden aangemaakt. Dit bericht is dan het eerste bericht binnen deze nieuwe choreografieinstantie. Deze informatie moet ons in staat stellen om de evolutie van een bepaalde choreografieinstantie te volgen. Hiervoor maken we gebruik van het piX-model dat behandeld wordt als een FSM (finite state machine). Hier vindt de dynamische conformiteitscheck letterlijk plaats. Bij het voorkomen van een geldige actie zal de statenmachine van staat
3
veranderen. Bij een ongeldige actie zal het feedbackmechanisme in gang moeten treden om andere deelnemers binnen de choreografie op de hoogte te brengen van deze fout. Voor het feedbackmechanisme maken we gebruik van ws-eventing. Er is de mogelijkheid om de afhandeling van dergelijke berichten buiten de dynamische conformiteitscheck te houden door dit apart in een event manager te implementeren. Dit verhoogt de flexibiliteit. De event-berichten moeten ervoor zorgen dat er een conformiteit-trustnetwerk ontstaat, binnen dit netwerk kunnen alle deelnemers een bepaald vertrouwen in elkaar stellen. Ook kunnen geldige acties leiden tot een event-bericht. Dit bericht bevestigt of verhoogt dan het vertrouwen in een bepaald device. Zo kan men bij het optreden van tegenstrijdige berichten de meest vertouwde partij geloven. Het spreekt voor zich dat dit netwerk pas functioneert als er van elk type device verschillende entiteiten aanwezig zijn. Zo kan men bij het niet meer vertouwen van een bepaald toestel een ander toestel aanspreken van hetzelfde type waarin men wel nog vertrouwen heeft. Een mogelijke uitbreiding is het mogelijk maken dat niet vertrouwde devices, welke niet over een event manager beschikken binnen het conformiteit-trust-netwerk, deelnemen aan choreografieën welke binnen een conformiteit-trust-netwerk worden uitgevoerd. Hiervoor zal een instantie binnen het conformiteit-trust-netwerk moeten instaan voor het controleren van de acties uitgevoerd door het niet vertrouwde device.
Problemen die moeten opgelost worden: • Algemeen probleem geschetst in bestaande situatie en probleemstelling. Problemen binnen het project: • Het kiezen van een geschikt platform aan de hand van de bepaalde criteria. Afhankelijk van de tekortkomingen van het platform zal het platform moeten worden uitgebreid naar een minimum niveau om de dynamische conformiteitscheck en het conformiteit-trust-netwerk mogelijk te maken. • Bepaling architectuur dynamische conformiteitscheck. • Bepaling architectuur conformiteit-trust-netwerk. • Theorie rond choreografie event-berichten. Wanneer wordt een event verstuurd? Welke inhoud ? Wie stuurt er events naar wie?
Technologieën die aan bod komen: • • • • • • • • • • • • • • • •
WS-CDL: Web Service Choreography Description Language WSDL: Web Service Description Language. XML. XML Schema. Xpath. DPWS: Device Profile for Web Services. WSA: Web Service Addressing. WSMex: Web Service Metadata exchange. WS-Transfer: Web Service Transfer. WS-Eventing: Web Service Eventing. WS-Discovery: Web Service Discovery. MEP: Message Exchange Pattern. WS4D: Web Services for Devices. AXIS2. AXIOM. SAVAN: Axis2 module voor WS-Eventing
Mogelijke uitbreidingen en opties: •
Het mogelijk maken dat niet vertrouwde devices deelnemen aan choreografieën welke binnen een conformiteit-trust-netwerk worden uitgevoerd. Hiervoor zal een instantie binnen het conformiteit-trust-netwerk moeten instaan voor het controleren van de acties uitgevoerd door het niet vertrouwde device.
•
De dynamische conformiteitscheck inpassen in een DPWS bewuste omgeving.
4
Vernieuwende aspecten: • • • • •
Het gebruik van WS-CDL, W3C-standaard kandidaat voor het beschrijven van choreografieën, als basis voor de beschreven choreografieën. Een conformiteitscheck tijdens de uitvoering van een choreografie. Het opbouwen van een conformiteit-trust-netwerk. De conformiteitscheck wordt DPWS bewust opgebouwd. De mogelijkheid voor een gedecentraliseerde oplossing voor bedrijfsprocessen. Op dit ogenblik gebeurt dit nog steeds gecentraliseerd, omdat gedecentraliseerd de controle op fouten afwezig is. Dit project wil dit probleem oplossen.
Overzicht van de items die in de scriptietekst zullen behandeld worden: • • • • • • • • • •
Webservice choreografie versus webservice orkestratie (gedistribueerd versus gecentraliseerd bedrijfsproces). Het gebruik van WS-CDL. Bespreking DPWS. Bespreking daarin voorkomende W3C-standaarden. Bespreking van het gebruikte platform. Bespreking aanpassingen aan het platform. Bespreking statische conformiteitscheck. Bespreking architectuur dynamische conformiteitscheck. Bespreking webservice events. Bespreking implementatie webservice events. Bespreking architectuur conformiteit-trust-netwerk.
5
