Automatische compositie van medische Web services in WS-BPEL

Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. LAGASSE Vakgroep Inwendige Ziekten Voorzitter: prof. dr. M. DE VOS

Automatische compositie van medische Web services in WS-BPEL door Yannick Beheyt Frederik Debruyne

Promotoren: prof. dr. ir. F. De TURCK & prof. dr. J. DECRUYENAERE Scriptiebegeleiders: K. TAVEIRNE & ir. S. Van HOECKE

Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen

Academiejaar 2007–2008

Voorwoord Wij wensen in de eerst plaats onze twee begeleiders Kristof Taveirne en Sofie Van Hoecke te bedanken voor hun ondersteuning en kritische kijk gedurende het hele jaar. Zij hebben ons bijgestaan zowel voor het praktische werk als bij het nalezen van dit thesisboek. De boeiende discussies tijdens de wekelijkse ontmoetingen hebben steeds tot interessante ideeën geleid. Daarnaast appreciëren wij ook het sturen van de thesis door prof. dr. ir. F. De Turck en de feedback van prof. dr. J. Decruyenaere. Verder gaat nog dank uit naar enkele andere personen: • Bruno Beheyt voor het helpen bij het ontwerpen van de figuren; • Kristof Steurbaut voor de hulp betreffende de medische use case.

Yannick Beheyt & Frederik Debruyne, mei 2008

Toelating tot bruikleen “De auteurs geven de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Yannick Beheyt & Frederik Debruyne, mei 2008

Automatische compositie van medische Web services in WS-BPEL door

Yannick Beheyt & Frederik Debruyne Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2007–2008 Promotoren: prof. dr. ir. F. De TURCK & prof. dr. J. DECRUYENAERE Scriptiebegeleiders: K. TAVEIRNE & ir. S. Van HOECKE Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. LAGASSE Vakgroep Inwendige Ziekten Voorzitter: prof. dr. M. DE VOS

Samenvatting In samenwerking met de afdeling Intensieve Zorgen van UZ Gent is binnen de vakgroep IBCN een architectuur ontworpen voor medische diagnose op basis van patiënt monitoringgegevens. Omdat het onmogelijk is om vooraf alle nodige functionaliteiten te bepalen, moet het platform in staat zijn nieuwe vereiste functionaliteit te leveren door automatisch meerdere Web services samen te stellen. Dit afstudeerwerk breidt deze bestaande architectuur uit met extra componenten om automatische compositie met behulp van WS-BPEL te ondersteunen. Op die manier is de gebruiker gemakkelijk in staat om automatisch nieuwe composities te creëren. Verschillende compositie algoritmes worden ontworpen en de voorgestelde applicatie wordt tenslotte aan prestatietesten onderworpen en geëvalueerd.

Trefwoorden WS-BPEL, automatische compositie, Web services, ICU, SOA

Automatic compositition of medical Web services in WS-BPEL Yannick Beheyt & Frederik Debruyne Supervisor(s): F. De Turck, J. Decruyenaere, K. Taveirne & S. Van Hoecke Abstract— Since the ICU1 is an extremely data intensive environment, information technology can support physicians through medical decision services. In this paper the ICSP2 presented in [1] is expanded, moving from a static to an automatic orchestration of Web services by extending WS-BPEL. The behaviour of the application has been illustrated through a medical use case and performance tests have been done on the different algorithms. Keywords—WS-BPEL, automatic composition, Web services, ICU, SOA

I. I NTRODUCTION

N

OWADAYS everything on the internet is becoming more and more service-oriented. The number of SOA’s is growing fast and there’s an increasing need to orchestrate Web services for making business flows. The orchestration language WS-BPEL is only used in a static way: this means a programmer has to design the whole orchestration himself. In this paper a methodology is presented for automatically making executable orchestrations. However, the application is designed in such way that it is able to support other orchestration languages in future as well. The remaining of the paper is structured as follows: In paragraph II static composition is explained. In the following paragraph III the steps to automatic composition are presented including the application and the used algorithms. A medical use case demonstrates this achievement. Paragraph IV shows the difference in performance between the various algorithms. Finally in section V the major conclusions are highlighted as well as some opportunities for further investigation. II. S TATIC COMPOSITION Currently in the ICU of Ghent University Hospital a platform is running, called the ICSP, for processing patient monitoring data through medical services. Examples of such services are SOFA (Sequential Organ Failure Assessment) service (figure 1), sepsis detection service and service compositions for prescribing antibiotics [2]. By composing multiple services, more advanced medical services can be created. This is done by using WS-BPEL, an industrial and well spread standard for creating workflows. However nowadays WS-BPEL is limited to static composition only. III. F ROM STATIC TO AUTOMATIC COMPOSITION As already stated the focus of this paper concerns the change from static to automatic composition. 1 Intensive 2 Intensive

Care Unit Care Subscription Platform

Fig. 1. SOFA score composite service

A. Semi-automatic composition This has to be seen as a preparation towards automatic composition. The algorithm is rather simple and starts with the given inputs. In this stage the user gives one or more input parameters and the application gives back all those Web services matching the given inputs. The user selects one matching Web service and this way the composition is iteratively built. The user can stop when he thinks he has his wanted functionality. All this results in a WS-BPEL project that will be automatically deployed on the used platform. Afterwards the user can give the needed input values and the result of the WS-BPEL execution will be returned to the user. B. Automatic composition In this phase the WS-BPEL composition is created automatically, i.e. without further interaction of the user. It will also be automatically deployed and being called by the given input values of the user. B.1 Proposed application Figure 2 gives the architecture of the application. The various modules will briefly be explained. WSDL documents are retrieved and stored in a Knowledge Base (A & B). The user gives the wanted functionality (D) and a composition can be created (C & E). After the composition creation it will be transformed to the wanted composition language (WS-BPEL) and a lot of necessary project resources will be created (F). This composition can optionally be visualised (K). The composition will be deployed (G) and called afterwards (H or L) with the input values (I) of the user. The result is then returned (J).

economical, managerial and all kinds of business purposes. IV. P ERFORMANCE TESTS Two main kinds of tests have been done. First the scalability of the different algorithms has been compared and finally the performance of the whole application has been investigated. For scalability each Web service has five local copies.

Fig. 2. Application for automatic composition

B.2 Algorithms Two algorithms have been developed. Both of them start with the given output to find the composition in a backwards way because that’s the most effecient way to do so. The first algorithm does not support QoS. It approaches the problem using depth first search to get a solution as fast as possible. A matching Web service is chosen in a rather random way. The second algorithm takes the QoS of each Web Service into account and does a local optimalisation. Local optimalisations have been chosen because the main goal was to get a solution as fast as possible, so there has been balanced between speed and a suboptimal QoS solution. B.3 Medical use case The basic algorithm has been illustrated with a medical use case to calculate if a patient has sepsis. As output parameter ’HasSepsis’ has been given because that’s the wanted result. A ’PatientID’ has been given as an input parameter in order to calculate the sepsis only for a certain patient. Figure 3 shows the result of the algorithm.

With a predefined and fixed composition and an increasing pool of irrelevant Web services the composition time increases but stays scalable. Next a fixed pool of irrelevant Web services has been taken and different depths of a full composition tree have been considered. With a one-to-one composition the existence of a linear relationship between the depth and the composition time has been proved. With a one-to-more composition and a fixed depth an exponential relationship between the number of local copies and the composition time has been shown for the non-QoS algorithm. Because of a filter system in the QoS algorithm the latter is faster than the non-QoS algorithm from a certain number of local copies and dependent on the kind of tree. In all tests the execution time of the non-QoS algorithm was higher than the QoS algorithm as expected. Considering all the different time intervals running the application there can be concluded that the biggest part involves reading the WSDL documents and creating and deploying the composite application. V. C ONCLUSIONS AND FURTHER WORK It has been proved that it is possible to realize an automatic composition with WS-BPEL using the proposed application. A big advantage is that the Web service composition will fasten the creation of new functionalities on the fly. Nevertheless the application should be further extended. Real semantics should be added to the Web Service descriptions to ameliorate the matching process. Also it’s interesting to evolve from an automatic to a dynamic composition. This means that modifications in the QoS of Web Services can be caught at run-time and the composition will adapt to it while running. ACKNOWLEDGMENTS The authors would like to acknowledge all people who helped them during the research. In particular they would like to thank Sofie Van Hoecke for the many suggestions she gave writing this paper and for her guidance throughout the whole year. They also would like to express their gratitude to Kristof Taveirne who gave them a lot of aid during the implementation of the application. R EFERENCES

Fig. 3. Automatic composition to calculate if a patient has sepsis

In fact, the mechanism of the algorithm is generic and is not limited to medical Web services only. It can also be used for

[1] S. Van Hoecke , J. Decruyenaere, C. Danneels, K. Taveirne, K. Colpaert, E. Hoste, B. Dhoedt, F. De Turck, ’Service-oriented subscription management of medical decision data in the Intensive Care Unit, to be published in Methods of Information in Medicine’, 2008 [2] A. C. Kajdacsy-Balla Amaral, F. M. Andrade, R. Moreno, A. Artigas, F. Cantraine, J. Vincent, “Use of the Sequential Organ Failure Assessment score as a severity score”, Intensive Care Med 31, Volume 31, Number 2, February 2005, 243-249

INHOUDSOPGAVE

i

Inhoudsopgave 1 Inleiding 1.1

1

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Technologie 2.1 2.2

2.3

2 3

Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1

Web Services Description Language . . . . . . . . . . . . . . . . . . . . .

5

Web service compositie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2.1

Web Services Business Process Execution Language . . . . . . . . . . . .

8

2.2.2

Web Ontlogy Languages for Web services . . . . . . . . . . . . . . . . . .

10

2.2.3

Windows Workflow Foundation . . . . . . . . . . . . . . . . . . . . . . . .

12

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3 Statische compositie met behulp van BPEL

15

3.1

Activiteiten in BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.2

Het ICSP platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.3

OpenESB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.4

Use case: SOFA-score . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.5

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4 Automatische compositie

24

4.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.2

Design en requirements van de architectuur voor automatische compositie . . . .

25

4.2.1

Semantische beschrijving van de Web services . . . . . . . . . . . . . . . .

25

4.2.2

Creëren van de compositie . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.2.3

Compositie realiseren en deployen at runtime . . . . . . . . . . . . . . . .

27

4.2.4

Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

INHOUDSOPGAVE

4.3

ii

Fase 1: Architectuur voor semi-automatische compositie . . . . . . . . . . . . . .

28

4.3.1

Informatie verzameling . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.3.2

Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.3.3

Compositie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.3.4

Constructie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.3.5

Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.3.6

Gebruiken van de nieuwe Web service . . . . . . . . . . . . . . . . . . . .

35

4.3.7

Enkele specifieke gegevens van eerste fase . . . . . . . . . . . . . . . . . .

36

Fase 2: Volledig automatische compositie . . . . . . . . . . . . . . . . . . . . . .

36

4.4.1

Compositie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.4.2

Constructie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.4.3

Visualisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

4.4.4

Enkele specifieke gegevens van de tweede fase . . . . . . . . . . . . . . . .

51

4.5

Quality Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

4.6

Ontwerpbeslissingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

4.6.1

Constanten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

4.6.2

Aanmaak van een XML-document . . . . . . . . . . . . . . . . . . . . . .

54

4.6.3

WSDL-documenten aanvullen met onbekende elementen . . . . . . . . . .

54

4.6.4

Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

4.4

4.7

5 Prestatietesten 5.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

5.1.1

WSDL-generatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

5.1.2

Automatische bepaling van de QOS van een compositie . . . . . . . . . .

61

5.1.3

Opmeting tijdsintervallen . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

5.1.4

Testen onafhankelijk maken van volgorde inlezen . . . . . . . . . . . . . .

61

5.2

Specificaties testmachine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

5.3

Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

5.3.1

Schaalbaarheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

5.3.2

Uitzonderlijk geval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

5.3.3

Verhouding tijdsintervallen van de complete applicatie . . . . . . . . . . .

70

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

5.4

Voorbereidingen

58

INHOUDSOPGAVE

6 Besluit en verder onderzoek

iii

72

6.1

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

6.2

Uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

A Gebruikte Software/Libraries

76

B Binding componenten

77

B.1 File binding component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

B.2 SMTP binding component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

C Dynamic Proxy & Dynamic Discovery and Invocation

79

D Testresultaten

81

D.1 Schaalbaarheidstesten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

D.2 Uitzonderlijk geval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

E Installatieprocedure

86

INHOUDSOPGAVE

Afkortingen ICSP

Intensive Care Subscription Platform

IZ

Intensieve Zorgen

IZIS

Intensieve Zorgen Informatie Systeem

JAR

Java Archive

JBI

Java Business Integration

KB

Knowledge Base

MSS

Medical Support Services

OWL-S

Web Ontology Languages for Web services

QA

Quality Attributes

QoS

Quality of Service

RIFLE

Risk, Injury, Failure, Loss and End stage

SOAP

Simple Object Access Protocol

SOFA

Sequential Organ Failure Assessment

WS-BPEL

Web Services Business Process Execution Language

WSDL

Web Services Description Language

WF

Windows Workflow Foundation

XML

Extensible Markup Language

XSD

XML Schema Definition

XSLT

Extensible Stylesheet Language Transformations

iv

INLEIDING

1

Hoofdstuk 1

Inleiding De dienst Intensieve Zorgen (IZ) van een ziekenhuis behandelt patiënten in een kritieke toestand (bv. na een ongeval of na een zware operatie). Het is dus belangrijk deze patiënten goed op te volgen door constante monitoring. In het Universitair Ziekenhuis Gent genereert een patiënt op IZ gemiddeld ongeveer 16000 waarden per dag. Deze waarden worden bijgehouden in een databank, nl. de Intensieve Zorgen Informatie Systeem (IZIS) databank. Vermits de capaciteiten van de mens te beperkt zijn om al deze gegevens te verwerken, wordt dit geautomatiseerd. Ook omwille van het feit dat een mens slechts zes à negen variabelen kan verwerken [1] en er op de dienst IZ per patiënt 236 variabelen zijn. Binnen IBCN is een architectuur ontwikkeld, specifiek voor IZ van UZ Gent, gebaseerd op de Web service technologie. Een belangrijk onderdeel van deze architectuur zijn Medical Support Services (MSS) die op basis van een flow o.a. bepaalde scores berekenen. In deze MSS zaten veel identieke delen. Daarom werd er gekozen om deze MSS op te splitsen in herbruikbare componenten en deze samen te stellen naargelang de gewenste functionaliteit. Deze compositie gebeurt momenteel statisch. Er zijn voor deze statische compositie reeds verschillende technologieën beschikbaar. Het zou echter handiger zijn moest de compositie automatisch gerealiseerd worden, of zelfs dynamisch uitgevoerd kunnen worden waarbij de compositie at runtime herzien wordt indien de QoS in het gedrang komt. Zo kunnen MSS vlotter geconstrueerd worden. Ook de artsen zouden dan in staat zijn zelf MSS te creëren. Automatische compositie echter, staat nog in z’n kinderschoenen. Om helemaal correct te zijn moeten we eigenlijk spreken over de compositie van operaties van Web services. Een Web service kan immers verschillende operaties bezitten en het zijn deze operaties die samengesteld worden. De term Web service compositie is echter algemeen aanvaard en indien er geen verwarring mogelijk is hanteren we deze term.

1.1 Overzicht

1.1

2

Overzicht

Om tot automatische compositie te komen, zal in dit thesisboek eerst statische compositie onderzocht worden. We beginnen in hoofdstuk 2 met wat meer uitleg over Web services en Web service compositie. Enkele technologieën betreffende statische compositie worden besproken en vergeleken. Daarna, in hoofdstuk 3, beschouwen we statische compositie m.b.v. WS-BPEL. Er wordt ook een concreet medisch voorbeeld uitgewerkt. Vervolgens, in hoofdstuk 4, behandelen we enkele aspecten van automatische compositie. Een architectuurstudie levert de basis voor de ontwikkeling van een applicatie voor automatische compositie. Dit gebeurt in twee fases: van een semi-automatische tot een volledig automatische compositie. Het daaropvolgende hoofdstuk (5) onderwerpt de applicatie aan enkele testen. In het laatste hoofdstuk trekken we de belangrijkste besluiten en beschrijven we hoe onze applicatie kan uitgebreid worden om ook dynamische compositie en semantische matching mogelijk te maken.

Hoofdstuk 2 Technologie Welke technologieën bestaan er om Web service compositie te realiseren? Hoofdstuk 3 Statische compositie met behulp van BPEL Hoe wordt statische compositie in BPEL verwezenlijkt? Hoofdstuk 4 Automatische compositie Ontwikkeling van een applicatie voor automatische compositie. Hoofdstuk 5 Prestatietesten Is de ontwikkelde applicatie praktisch toepasbaar? Hoofdstuk 6 Besluit en verder onderzoek Wat kan er in de toekomst ontwikkeld en onderzocht worden?

TECHNOLOGIE

3

Hoofdstuk 2

Technologie Het platform voor IZ moet uitgebreid worden met een automatische compositie (van de MSS) gebaseerd op Web service technologie. Aangezien Web services hierin centraal staan, wordt er in de eerstvolgende paragraaf van dit hoofdstuk een samenvatting gegeven van verschillende aspecten van Web services. Daarna, in paragraaf 2.2, komt Web service compositie aan bod. Er wordt een concreet voorbeeld gegeven van Web service compositie, alsook wat hiermee kan bereikt worden. In deze paragraaf worden ook verschillende technologieën om (statische) compositie te realiseren besproken. Ten slotte, in de afsluitende paragraaf 2.3, worden deze technologieën vergeleken.

2.1

Web services

Web services1 zijn softwarediensten die aangeboden worden via het internet. Iets specifieker is de volgende definitie, nl. Web services zijn applicaties die hun functies beschikbaar stellen via het internet. Doordat ze enkel hun functies beschikbaar stellen, kan hun (afgeschermde) implementatie geoptimaliseerd worden zonder dat dit verdere gevolgen met zich meebrengt. Wat Web services bijzonder interessant maakt is het feit dat deze diensten platformen systeemonafhankelijk zijn. Web services creëren de mogelijkheid om heterogene en gedistribueerde systemen te laten samenwerken, ze zijn immers toegankelijk voor alle systemen die op het internet of een intranet aangesloten zijn. Twee specifieke toepassingen hiervan zijn: • Enterprise Application Integration (EAI): integratie van applicaties binnen een bedrijf. 1

De W3C [2] definitie voor Web service is: A Web service is a software application identified by a URI, whose

interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols.

2.1 Web services

4

Figuur 2.1: Voorstelling van Web services Hiervoor kan ook middleware gebruikt worden. Indien het bedrijf echter over verschillende middleware platformen beschikt, dan kunnen deze interageren m.b.v. Web services. • Business-to-Business (B2B) interactie: samenwerking van applicaties van verschillende bedrijven. Een mogelijke oplossing is dat elk bedrijf per communicatie (met een ander bedrijf) een aparte interface ontwikkelt. Deze oplossing zorgt al snel voor een immens aantal interfaces. Web services, als alternatief, reduceren sterk de complexiteit door het aanbieden van uniform interfaces. Bij B2B is middleware geen alternatief voor Web services. Immers, voor middleware moet er een centrale entiteit (soort message broker) opgericht worden. Dit geeft problemen zowel voor de locatie van deze entiteit, als voor de vertrouwensrelatie die de bedrijven moeten hebben. De interoperabiliteit die wordt verkregen door Web services, steunt op het gebruik van een geheel van XML-gebaseerde open standaarden, nl. WSDL, SOAP en UDDI (zie ook figuur 2.1). WSDL (Web Services Description Language) is een XML-taal voor het beschrijven van Web services. Dit wordt verder besproken in paragraaf 2.1.1. Om te communiceren met Web services wordt meestal SOAP (Simple Object Access Protocol) gebruikt in samenwerking met HTTP. UDDI (Universal Description, Discovery and Integration) is een dienst waar bedrijven Web services zowel kunnen opzoeken als registreren (m.a.w. publiceren). Deze dienst situeert zich in de SOA (Service Oriented Architecture, zie ook figuur 2.2) als een implementatie van de ‘Service registry’. Naast het feit dat Web services gestandaardiseerd zijn, beschikken ze ook over de ondersteuning van talloze grote bedrijven (o.a. IBM, Microsoft, Oracle en Sun Microsystems).

2.1 Web services

5

Figuur 2.2: Service oriented architecture

2.1.1

Web Services Description Language

WSDL is een XML-formaat voor het beschrijven van Web services. Het WSDL-document (kortweg de WSDL genoemd) bevat o.a. de locatie en de functies (ook methodes of operaties genoemd, dit is m.a.w. de interface van de Web service). Vermits applicaties gebruik maken van de WSDL van een Web service, is het van cruciaal belang dat deze WSDL-interface ongewijzigd blijft. De implementatie van de interface (dus de eigenlijke Web service) kan, zoals reeds eerder vermeld, veranderen (bv. voor optimalisatie). Indien de WSDL toch wijzigt, dan vervallen ook de applicaties die deze WSDL gebruiken, tenzij deze mee aangepast worden. Web service compositie steunt o.a. op de WSDL van een Web service. Bepaalde technologieën passen de WSDL zelfs aan (dit komt later aan bod). Daarom is het interessant de verschillende elementen uit de WSDL te overlopen. Structuur WSDL-document <definitions>

Het WSDL-document is een geheel van definities. <definitions> is dan

ook de root node. Alle nodes die hieronder besproken worden, bevinden zich rechtstreeks onder deze node. Deze node maakt het mogelijk namespaces te importeren. Zo kunnen bepaalde elementen beschreven worden in aparte bestanden die dan overal kunnen ge¨ımporteerd worden (dit principe is analoog aan het import statement in Java of het include statement in C#).

In deze node worden de datatypes gedefinieerd die gebruikt worden in de berichten.

<message> De berichten, die de in- en uitvoer voor de operaties () vormen, worden steeds gedefinieerd als een <message>. Elk bericht bestaat uit een of meerdere <part> nodes. Aan iedere deel wordt een node en een node geassocieerd.

2.1 Web services

6

Iedere <portType> node stelt een Web service eindpunt voor. Dit eindpunt

<portType>

kan een of meerdere operaties () ondersteunen. Elke operatie kan gekoppeld worden aan drie verschillende types van berichten, nl. , & .

Per <portType> node wordt er een binding opgegeven. Deze binding speci-

ficeert het berichtformaat en protocol details voor alle operaties en berichten van een bepaalde <portType>. <service> Een service node definieert een of meerdere gerelateerde poorten (<port>). Iedere poort is een toegangspunt voor de Web service. Ze bestaat uit een naam, een binding en een URL van de Web service. [3, 4] Ruwweg kunnen deze WSDL-elementen opgedeeld worden in twee categorieën: abstracte en concrete elementen. Abstracte elementen beschrijven de functionaliteit van de Web service: de beschikbare operaties, de inputs en outputs van deze operaties en de types van deze inputs en outputs. Dit komt overeen met volgende elementen: , <message>, , <portType>. Abstracte WSDL kan gezien worden als de definitie van een of meerdere functies zonder de implementatie, analoog aan de interface definities en de abstracte klasses met methode definities in Java. Concrete elementen bepalen o.a. hoe de Web service moet aangeroepen worden, volgens welk protocol de communicatie verloopt en de locatie van de Web service. De concrete elementen zijn: en <service> [5]. Extensibility WSDL laat toe dat bepaalde elementen kinderelementen bevatten van een specifieke technologie. Deze kinderelementen worden extensibility elements genoemd. Meestal worden ze gebruikt om binding informatie te verschaffen van bepaalde berichtformaten of protocollen. Het gebruik van deze elementen is echter niet beperkt tot dergelijk informatie. Wel moeten extensibility elements zich in een andere namespace bevinden dan de WSDL-namespace en kunnen ze maar op specifieke plaatsen in het document voorkomen. In de specificatie zijn volgende extensibility elements reeds gedefinieerd: • SOAP 1.1, • HTTP GET / POST,

2.2 Web service compositie

7

• MIME. Extensibility elements laten dus innovatieve uitbreidingen toe zonder de WSDL-standaard te moeten wijzigen [14].

2.2

Web service compositie

Web service compositie is het principe van bestaande Web services samen te voegen tot nieuwe Web services, m.a.w. het opbouwen van Web services door bestaande implementaties te gebruiken om zo nieuwe functionaliteiten te creëren2 . Deze nieuw geconstrueerde Web services kunnen dan weer gekozen worden als onderdeel van een andere samengestelde Web service. De volgorde waarin de Web services mekaar aanspreken wordt de business flow genoemd.

Figuur 2.3: Voorbeeld van Web service compositie Er wordt een concreet voorbeeld beschouwd in figuur 2.3, nl. het boeken van een reis. Er bestaan twee Web services van reisagentschappen (1 en 2), elk met hun Web services voor het boeken van hotels en vliegtuigreizen. Veronderstel nu dat een bepaalde Web service X een dienst wil aanbieden die gebruikers de mogelijkheid biedt een reis te boeken gebaseerd op een bepaald klimaat. Deze Web service X kan bestemmingen, die aan een bepaald klimaat voldoen, 2

Web service compositie kan zowel EAI als B2B interactie (zie paragraaf 2.1) zijn, maar dit hoeft niet het

geval te zijn (bv. een applicatie die bestaat uit de compositie van Web services).


8

vinden door een extra Web service te contacteren die weersvoorspellingen en dergelijke bevat in combinatie met het gebruik van de eerder vermelde Web services van de reisagentschappen. Afhankelijk van de verkregen bestemmingen kan de Web service X op zoek gaan naar een bepaalde reis bij de reisagentschappen (1 en 2). Deze Web services, die rechtstreeks gebruikt worden door Web service X, verkrijgen hun diensten door functionaliteiten te combineren van andere Web services, nl. Web services voor het boeken van hotels en vliegtuigreizen. Ook deze Web services kunnen nog verder opgedeeld worden, bv. hotels die kredietwaardigheid nagaan bij een bepaald instituut of in contact staan met een betaalservice. Zoals het voorbeeld aantoont, biedt Web service compositie verschillende voordelen, o.a.: • Applicaties kunnen modulair opgebouwd worden. De aparte modules kunnen hergebruikt worden voor andere applicaties (zie ook figuur 2.3, de twee reisagentschappen kunnen bij dezelfde hotels boeken). • Het is mogelijk verschillende abstractielagen in de architectuur van een applicatie te brengen. Compositie kan in programmeertalen zoals Java, C#, . . . zelf gerealiseerd worden, maar dit heeft als nadeel dat de programmeur zich meer moet concentreren op het technisch koppelen van de Web services i.p.v. op de business flow zelf. Er zijn echter talen en technologieën ontwikkeld specifiek voor Web service compositie. Een aantal van hen wordt besproken in de volgende paragrafen. Ze hebben allemaal hetzelfde doel, nl.: het beschrijven en implementeren van een business process door te specificeren welke Web services interageren, in welke volgorde ze dat doen (m.a.w. de business flow) en welke tussenliggende handelingen moeten uitgevoerd worden.

2.2.1

Web Services Business Process Execution Language

Web Services Business Process Execution Language (WS-BPEL) [6] is een XML-taal die Web service compositie ondersteunt in de vorm van een orchestratie. Het is een uitwerking gebaseerd op de combinatie van twee oudere technologieën, nl. Microsofts XLANG3 en IBMs Web Services Flow Language4 (WFSL). BPEL – ontwikkeld door o.a. BEA, IBM, Microsoft, SAP en Siebel Systems – wordt gestandaardiseerd door OASIS5 (Organization for the Advancement of Structured Information Standards). 3

Zie ook http://technet.microsoft.com/en-us/library/aa577463.aspx Zie ook http://www.ibm.com/developerworks/library/ws-ref4/index.html 5 Zie ook http://www.oasis-open.org 4


9

Het business process wordt gerealiseerd d.m.v. een BPEL-proces. Wanneer dit BPEL-proces uitgevoerd wordt op een BPEL-server, ontstaat er een samengestelde Web service. Ieder BPELproject bestaat uit: • een bronbestand (.bpel, dit is het eigenlijke proces); • een WSDL-document (nodig omdat de applicatie bij uitvoering ook een Web service is); • een JBI

6

descriptor (beschrijft welke services er geconsumeerd en geleverd worden)

Aangezien BPEL een XML-taal is, is het procesbestand (.bpel) een XML-bestand. Er zijn drie belangrijke delen in een BPEL-proces (het importeren van namespaces laten we buiten beschouwing). Deze delen, die zich rechtstreeks onder de root node (<process>) bevinden, zijn: • de variabelen van het BPEL-proces (); • de partners van het BPEL-proces, dit zijn dus de Web services waarmee samengewerkt wordt (<partnerLinks>); • de activiteiten, deze bepalen samen de business flow (zie ook paragraaf 3.1). De variabelen worden gebruikt om bepaalde logica van het business proces te realiseren (bv. berichten opslaan). De interactie met andere Web services gebeurt d.m.v. ‘partnerLinks’. Iedere ‘partnerLink’ bevat een ‘partnerLinkType’ en één of twee rollen (‘myRole’en ‘partnerRole’). Dit ‘partnerLinkType’ wordt gedefinieerd in de WSDL van de partner. Daar worden ook de rollen, die bij dit ‘partnerLinkType’ horen, aan poorten (<portType>, zie ook de beschrijving van WSDL in paragraaf 2.1.1) gekoppeld. Vermits het niet mogelijk is externe WSDL’s aan te passen, worden deze WSDL’s (van Web services die door het BPEL-proces geconsumeerd worden) lokaal gekopieerd en aangepast. Voor de berichtenuitwisseling met de partners van het BPEL-proces kan enige vorm van toestand bewaard worden d.m.v. van correlatiesets () [7]. Voor meer informatie betreffende BPEL wordt naar [8] verwezen. 6

JBI is een specificatie ontwikkeld binnen de SOA. Ze definieert een standaard manier om inte-

gratie componenten te maken en ze levert een architectuur om deze diensten aan te bieden. http://jcp.org/en/jsr/detail?id=312

Zie ook


2.2.2

10

Web Ontlogy Languages for Web services

Web Ontlogy Languages for Web services OWL-S (voordien gekend als DAML-S7 ) is een service ontologie8 die het automatisch vinden, oproepen, samenstellen en uitvoeren van Web services ondersteunt. De sterke opkomst van dergelijke markup-talen past in het kader van het semantische Web, waar de toegang tot Web resources (bv. Web services, websites) eerder via inhoud dan op sleutelwoord zal gebeuren. Vooraleer applicaties gebruik kunnen maken van deze Web resources, moeten ze een computer interpreteerbare beschrijving hebben en bovendien weten hoe ze benaderd moet worden. OWL-S levert een standaard ontologie voor deze beschrijvingen van Web services. De mechanismen van OWL leveren m.b.v. klassen en eigenschappen een gepast raamwerk waarin deze ontologie kan gerealiseerd worden. De structuur van de ontologie, die te zien is op figuur 2.4, bestaat uit vier klasses (Service, ServiceProfile, ServiceModel, ServiceGrounding) die aan elkaar worden gelinkt door eigenschappen (presents, describedBy, supports) [9]. Deze structuur is ontstaan uit de behoefte aan drie kennistypes over de service: • Service profile: wat levert de service? • Service model: hoe wordt de service gebruikt? • Service grounding: hoe gebeurt de interactie met de service?

Figuur 2.4: Top level van de service ontologie 7 8

DARPA Agent Markup Language Een ontologie definieert de termen die gebruikt worden om een kennisgebied te beschrijven en te vertegen-

woordigen. Ze wordt gebruikt door mensen, databanken en applicaties die informatie over een domein (bv. kennis, medicijnen, . . . ) moeten delen. Ze bevat definities van basisconcepten en hun onderlinge relaties in het domein die door computers kunnen gebruikt worden. Op deze manier wordt de kennis herbruikbaar. [10]


11

We zien dat de Service profile de informatie levert om een service te vinden, terwijl het Service Model en de Service grounding samen genoeg informatie verschaffen om van deze service gebruik te kunnen maken. Service profile Een OWL-S profiel beschrijft een Web service (cf. ‘yellow pages’ van UDDI) zodat leveranciers hun Web services kunnen publiceren en aanvragers deze Web services kunnen opzoeken. Deze beschrijving wordt opgedeeld in drie types van informatie: contactinformatie (welke organisatie levert de service), functionele informatie (wat berekent de service, m.a.w. de IOPE9 ) en een legioen eigenschappen (kenmerken zoals service categorie, kwaliteitslabel, . . . ). Service model Een OWL-S model beschrijft de werking van een Web service door deze te modelleren als een proces (cf. BPEL-proces) m.b.v. de Process klasse, die een subklasse is van ServiceModel. Uit deze beschrijving kan afgeleid worden hoe er met de Web service gewerkt wordt. Een proces, met een bepaalde IOPE, is een specificatie van een bepaalde handeling. Er zijn drie soorten processen10 . Atomische processen corresponderen met acties die in één stap uit te voeren zijn. Ze nemen een input boodschap, verwerken deze en geven een output boodschap terug. Voor elk atomisch proces moet er een grounding voorzien zijn. Eenvoudige processen zijn niet oproepbaar (worden wel beschouwd als uitvoeringen in één stap) en hebben geen grounding. Ze stellen een abstractie voor van het proces waarmee ze geassocieerd worden (een atomisch proces of een samengesteld proces). Samengestelde processen kunnen opgesplitst worden in andere processen (kunnen opnieuw samengestelde processen zijn). De compositie kan worden gespecificeerd door controlestructuren-klasses11 zoals Sequence, If-Then-Else, Perform, . . . (cf. BPEL-activiteiten). Een proces kan tenslotte twee doelen hebben. Ten eerste kan het nieuwe informatie genereren op basis van de inputs, outputs en de huidige toestand. Ten tweede kan het ook een toestandsverandering met zich meebrengen, beschreven door de allereerste voorwaarden en effecten. 9

De IOPE zijn de inputs, outputs, preconditions en effects. Deze worden aan het profiel gekoppeld door de

eigenschappen hasInput, hasOutput, hasPrecondition en hasResult. 10 De OWL-S klasses van deze processen zijn AtomicProcess, SimpleProcess en CompositeProcess. 11 Dit zijn subklasses van ControlConstruct


12

Service grounding De grounding definieert de praktische details hoe de service moet aangesproken worden (bv. de protocollen en de boodschapformaten). De centrale functie van de OWL-S grounding is om te tonen hoe abstracte inputs en outputs van een atomisch proces concreet als boodschappen gerealiseerd moeten worden. Vermits WSDL (zie paragraaf 2.1.1) als industriële standaard goed ingeburgerd is, werd er gekozen om de OWL-S klasses te koppelen aan WSDL-types (zie figuur 2.5). Meer specifiek worden de OWL-S inputs en outputs gemapt op de WSDL message parts (indien nodig m.b.v. XSLT12 transformaties) en de OWL-S atomische processen op de WSDL-operaties [6] [9].

Figuur 2.5: Mapping tussen OWL-S en WSDL

2.2.3

Windows Workflow Foundation

Windows Workflow Foundation (WF) is een belangrijk onderdeel van het .NET 3.0 raamwerk13 (voordien WinFX genoemd). Met WF is het mogelijk flowgebaseerde applicaties te ontwikkelen voor Windows. De workflows kunnen grafisch gecreëerd worden en zijn opgebouwd uit verschillende activiteiten (deze vertonen sterke gelijkenissen met de BPEL-activiteiten). WF is toepasbaar zowel voor SOA (Service Oriented Applications), alsook voor verschillende andere domeinen zoals de opeenvolging van pagina’s van gebruikersinterfaces en document-centric work12 13

Zie ook http://www.w3.org/TR/xslt Andere grote delen van het .NET 3.0 raamwerk zijn Windows Communication Foundation (WCF) en Windows

Presentation Foundation (WPF).

2.3 Besluit

13

flow14 . Gecreëerde workflows kunnen binnen de .NET omgeving hergebruikt worden in andere applicaties. WF is in tegenstelling tot BPEL geen taal, maar een technologie (concept) waarbinnen verschillende programmeertalen kunnen gebruikt worden15 . Daarenboven biedt WF ook de mogelijkheid om BPEL-workflows te construeren (voorlopig zijn enkel de activiteiten van de BPEL 1.1 specificatie ter beschikking). Een van de grootste beperkingen van deze technologie is het feit dat deze enkel voor Windows platformen bestemd is. [11] In [12] worden twee specifieke aspecten behandeld betreffende workflows in .NET. Ten eerste wordt onderzocht hoe workflows at runtime op een betrouwbare manier aangepast kunnen worden. Er is een tool ontwikkeld die voort bouwt op een feature van WF om deze dynamische aanpassingen (en ook instrumentatie) te realiseren. Daarnaast wordt er ook gekeken naar het ontwerp van zogenaamde generieke bouwblokken die het ontwerp van workflows vereenvoudigen.

2.3

Besluit

Web service technologie maakt deel uit van de verzameling van populaire internettechnologieën. Web services maken gebruik van het internet om functionaliteiten beschikbaar te stellen voor andere systemen. Zo wordt het mogelijk o.a. bestaande systemen te laten samenwerken met als doel nieuwe functionaliteiten te creëren, nl. Web service compositie. Van de drie beschouwde technologieën voor Web service compositie, hebben vooral BPEL en WF veel gemeen. Het is zeer belangrijk om te verstaan dat beide technologieën geen semantiek bevatten. Ze kunnen dus in de context van Web service compositie, enkel gebruikt worden voor de compositie ervan. BPEL is een XML-taal die zich specifiek toespitst op Web service compositie, terwijl WF ontwikkeld is voor uiteenlopende domeinen en de mogelijkheid biedt verschillende programmeertalen te gebruiken. De WF technologie is echter niet platformonafhankelijk (enkel bruikbaar voor Windows platformen). BPEL heeft het voordeel dat de compositie automatisch terug een Web service voorstelt, maar moet qua technologische voorzieningen onderdoen voor WF (bv. in WF flows kan rechtstreeks .NET code gebruikt worden). 14

Onder document-centric workflow verstaan we workflow in de context van documentstromen (o.a. in be-

drijven). Documenten ondergaan vaak een vast patroon van handelingen door een of meerdere personen (bv. aanmaak, nalezen, aanpassen verbeteringen, bevestiging afwerking, mailen). Dit proces kan gemodelleerd worden m.b.v. een workflow. 15 Voor samengestelde Web services is er dus geen beperking qua mogelijkheden voor de tussenliggende logica zoals bij BPEL. Hierdoor is deze logica ook gemakkelijker en sneller te produceren dan in de BPEL-mapper van NetBeans.

2.3 Besluit

14

OWL-S is een academische standaard, terwijl BPEL en WF industriële standaarden zijn. OWL-S is ontstaan uit de nood om Web services semantisch te beschrijven. Het ontbreken van semantiek in BPEL en WF kan dus opgevangen worden met OWL-S. Deze technologie kent echter een steilere leercurve. Ondanks het feit dat deze technologie oorspronkelijk een beschrijvende functie als doel had, zijn er reeds initiatieven genomen om OWL-S beschrijvingen uitvoerbaar16 te maken. Met behulp van de samengestelde processen in OWL-S zouden er dan Web service composities kunnen gemaakt worden. De tools voor het maken van OWL-S beschrijvingen zijn echter ontoereikend t.o.v. de IDE’s voor BPEL (o.a. NetBeans en Eclipse) en WF (Microsoft Visual Studio).

16

Zie ook http://www.mindswap.org/2004/owl-s/api/

STATISCHE COMPOSITIE MET BEHULP VAN BPEL

15

Hoofdstuk 3

Statische compositie met behulp van BPEL In dit hoofdstuk gaan we iets dieper in op de toepassing van BPEL voor statische Web service compositie. In de eerste paragraaf komen BPEL-activiteiten aan bod. Deze activiteiten bepalen, zoals eerder vermeld, de business flow. Ze vormen een belangrijk onderdeel van het BPEL-proces, dat ook variabelen en partners bevat. Daarna, in paragraaf 3.2, worden de voornaamste (highlevel) componenten van het ISCP platform besproken. OpenESB1 , dat een belangrijk onderdeel vormt van dit platform, wordt behandeld in de daaropvolgende paragraaf (3.3). Vervolgens wordt een concrete use case uitgewerkt (3.4). Het hoofdstuk eindigt met een aantal besluiten i.v.m. de mogelijkheden en beperkingen van BPEL.

3.1

Activiteiten in BPEL

Hieronder wordt een overzicht gegeven van de basisactiviteiten in BPEL. Deze worden onderverdeeld in vier catergorieën: communicatie, manipulatie, procesvoortgang en structuur [8, 13, 3]. Belangrijk hierbij is dat sommige activiteiten recursief kunnen gebruikt worden (bv. een ‘sequence’ activiteit die een ‘flow’ activiteit, waarvan een onderdeel een ‘sequence’ is, bezit). Na het overzicht wordt er een voorbeeld gegeven met enkele concrete toepassingen van activiteiten. 1. Activiteiten die zorgen voor berichtenuitwisseling met partners (communicatie) • Het ontvangen van een bericht van een partner. 1

Zie ook https://open-esb.dev.java.net

3.1 Activiteiten in BPEL

16

• Het verzenden van een bericht, dat een antwoord is van een synchrone operatie, naar een partner. • Het oproepen van een methode op een partner. 2. Activiteit die toelaat variabelen te bewerken (manipulatie) • Manipulatie van variabelen wordt standaard gedaan door X-Path2 1.0 expressies. Om meer complexere transformaties te doen kan ook gebruik gemaakt worden van XQuery3 . 3. Activiteiten die de voortgang van een BPEL-proces kunnen be¨ınvloeden (procesvoortgang) • <Wait> Deze activiteit specificeert een vertraging, ofwel voor een bepaalde duur, ofwel totdat aan een bepaalde expressie voldaan is. • Deze activiteit zorgt ervoor dat het BPEL-proces stopt. • <Empty> Dit is een activiteit die niets bevat (uitvoert). Dit kan nodig zijn bv. wanneer er in een bepaald deel van het BPEL-proces geen activiteiten plaatsvinden. 4. Activiteiten die de processtructuur bepalen (structuur) • & <ElseIf> Activiteiten die conditioneel gedrag ondersteunen. • <Switch> Deze activiteit laat toe een aantal voorwaarden op te sommen en hieraan acties te verbinden. • <While> Een while activiteit zorgt voor het repetitief uitvoeren van de omsloten activiteiten totdat aan een bepaalde voorwaarde voldaan is. Analoge activiteiten voor lusstructuren zijn & . • <Sequence> Activiteit die de omsloten activiteiten sequentieel uitvoert. • Activiteit die andere activiteiten parallel kan uitvoeren. • Ook deze activiteit ondersteunt conditioneel gedrag. Er zijn twee mogelijke condities: het arriveren van een bericht en een (tijdsgebaseerd) alarm. Enkel de activiteiten die bij de conditie horen die het eerst voldaan is, worden uitgevoerd. 2

X-Path is een taal om informatie te vinden in XML-documenten. Het laat toe om te navigeren in elementen

en attributen van een XML-document. Zie ook http://www.w3schools.com/xpath/ 3 XQuery is ontworpen om XML-data te ondervragen (niet alleen XML-bestanden maar ook databanken). Zie ook http://www.w3schools.com/xquery/

3.1 Activiteiten in BPEL

17

• <Scope> Analoog als het ‘scope’ concept in programmeertalen zoals Java en C#. Dit maakt bv. het gebruik van variabelen of foutafhandeling mogelijk voor een bepaald deel van het proces, nl. de omsloten activiteiten. Naast de vermelde activiteiten bestaan er ook nog andere: , <Exit>, , , , , <ExtensionActivity>, . . . Voor de complete verzameling verwijzen we naar [3].

Figuur 3.1: Voorbeeld van een flowchart van Web service compositie

3.2 Het ICSP platform

18

De basisactiviteiten van BPEL worden ge¨ıllustreerd aan de hand van het reisvoorbeeld uit hoofdstuk 2 (zie figuur 2.3). Er is namelijk een voorbeeldimplementatie uitgewerkt voor de Web service X (zie figuur 3.1). De activiteiten zijn gekleurd weergegeven volgens de categorie waartoe ze behoren: communicatie (blauw), manipulatie (groen), structuur (rood).

3.2

Het ICSP platform

Het ICSP (Intensive Care Subscription Platform) platform dat ontwikkeld wordt voor de dienst IZ is voorgesteld in figuur 3.2. Het bestaat high-level uit verschillende componenten die verder worden toegelicht. De Service Pool bevat het geheel van gedeployde MSS. Deze MSS verwerken de patiëntengegevens van monitoren en labo’s. Ze worden hiervoor op geregelde tijdstippen (bv. de SOFA Web service) of via een trigger (bv. de RIFLE Web service, die een soort alarmscore betreffende de nierfunctionaliteit berekent) geactiveerd (task management). De verschillende profielen, Web service beschrijvingen, configuraties (bv. het doeladres van de gegevens van de Web services), . . . worden bijgehouden in een repository/registry zijnde ebXML (hierover volgt meer informatie). De Service Engines en de Output zijn twee componenten die deel uitmaken van OpenESB4 . De Service Engines verzorgen interne diensten en de Output component zorgt ervoor dat gegevens kunnen verstuurd worden (o.a. via e-mail) naar pda’s, desktops en bedside schermen.

Figuur 3.2: Het ICSP platform 4

De output component bevat immers binding componenten.

3.3 OpenESB

19

ebXML De ebXML component is de opslagplaats voor allerlei gegevens (o.a. Web service beschrijvingen). ebXML (Electronic Business using eXtensible Markup Language) is een ontwerp (of een geheel van specificaties) om de elektronische handel via het internet op een gestandaardiseerde manier mogelijk te maken. Het biedt o.a. de mogelijkheid om berichten uit te wisselen en business processes te definiëren en te registreren [15]. In het platform wordt slecht een deel van de specificatie gebruikt, nl. de ebXML registry. ebXML registry zorgt enkel voor de specificatie, die bij het ICSP platform gerealiseerd wordt door de open source implementatie OMAR

5

(Object Metadata and Repository). Het voordeel van een ebXML registry zoals

OMAR is dat gegevens dynamisch aan elkaar kunnen gelinkt worden. Dit in tegen stelling tot bv. een databank waarbij het ontwerp onder handen genomen wordt bij eventuele wijzigingen op vlak van datastructuur.

3.3

OpenESB

OpenESB (Open Enterprise Service Bus) voorziet een aantal ‘pluggable component containers’: containers groeperen gelijkaardige componenten en worden slechts ingezet indien nodig. Er zijn twee soorten componenten, nl. Service Engines (SE’s) en Binding Components (BC’s). De containers ondersteunen verschillende internettechnologieën en zijn verbonden met elkaar via een Normalized Message Router (NMR, ook JBI-bus genoemd). De communicatie gebeurt d.m.v. XML-berichten in combinatie met gestandaardiseerde uitwisselingspatronen (MEP: Message Exchange Patterns), die gebaseerd zijn op abstracte WSDL. Zo wordt er een service model gerealiseerd waarbinnen enkel met genormaliseerde berichten, die allemaal in standaard abstracte WSDL voorkomen6 , gecommuniceerd wordt. SE’s verzorgen interne diensten en communiceren dus uitsluitend via de genormaliseerde berichten. Voor de communicatie naar de buitenwereld toe worden BC’s gebruikt. Hier is er wel een mapping nodig van de genormaliseerde berichten naar het externe formaat. Het geheel van SE’s, BC’s, applicaties, . . . worden gedeployed op een application server, nl. GlassFish. [16] 5 6

Zie ook http://ebxmlrr.sourceforge.net/index.html Abstracte WSDL wordt gebruikt om de structuur te specificeren van berichten die niet van Web services

afkomstig zijn, er schuilt m.a.w. geen Web service achter de abstracte WSDL.

3.3 OpenESB

20

Binding componenten en service engines Service engines voorzien dus interne diensten en binding componenten diensten die niet tot de OpenESB omgeving behoren. Er zijn verschillende binding componenten uitgetest, nl.: • File binding component De file BC maakt interactie met bestanden mogelijk, bv. voor logging (zie ook bijlage B voor extra technische uitleg). • SMTP binding component Met behulp van de SMTP BC kunnen er e-mails verstuurd worden, bv. voor logging (zie ook bijlage B voor extra technische uitleg). • JDBC binding component Een JDBC BC wordt gebruikt om te connecteren met databanken. Er is ook een service engine uitgeprobeerd, nl. de SQL service engine (kortweg SQL SE). Met behulp van een SQL module (project die uitgevoerd wordt door de SQL SE) kunnen er queries op databanken uitgevoerd worden. Zowel met een JDBC BC als met een SQL SE is interactie met een databank mogelijk. Daarom worden beide alternatieven vergeleken in tabel 3.1. Aspect

JDBC BC

SQL SE

Aanmaak van een Query

Niet handig

Goede ondersteuning

Meerdere Queries

Moeilijk

Makkelijk door verschillende .sql bestanden

Query die inwerkt

Niet mogelijk

Mogelijk

Mogelijk

Niet mogelijk

op meerdere tabellen Polling

Tabel 3.1: Vergelijking JDBC BC en SQL SE

3.4 Use case: SOFA-score

3.4

21

Use case: SOFA-score

De SOFA (Sequential Organ Failure Assessment) Web service is een compositie die bestaat uit enkele MSS. Ze berekent de SOFA-score die een indicatie geeft van de sterfelijkheid van een patiënt [17]. Deze voorspelling is gebaseerd op metingen van de werking van organen (o.a. de ademhaling). De verschillende Web services7 , waarvan de samenwerking geschetst is m.b.v. figuur 3.3 en het sequentiediagram van figuur 3.4, zijn: • GlasgowComaScoreService berekent de Glasgow Coma Score Scale, • CardiovascularDosisService berekent de nodige cumulatieve dosissen voor dopamine, dobutamine, levorenine en levophed, • SQLQueriesSofaScoreService omvat alle nodige SQL-queries voor de SOFA Web service en zijn deelcomponenten, • SMTPModule zorgt ervoor dat resultaten via het SMTP-protocol doorgemaild worden, • SofaScoreService compositie die alle bovenstaande blokken gebruikt, inwendig de deelscores van Renal en Coagulation berekent en uiteindelijk de SOFA-score teruggeeft. De SOFA Web service is in eerste instantie manueel samengesteld uit de MSS. De compositie samen met de logica van de SOFA Web service is volledig ge¨ımplementeerd in BPEL, m.a.w. er is geen Java code gebruikt. Het is echter de bedoeling dat deze Web service automatisch geconstrueerd zal worden. De arts geeft de SOFA-score op als gewenste output parameter samen met enkele gegeven input parameters en op basis van deze gegevens moet het systeem in staat zijn een compositie te realiseren m.b.v. de bestaande MSS. Automatische compositie komt aan bod in het volgend hoofdstuk. Een verdere uitbreiding van het systeem bestaat erin het falen van MSS tijdens de uitvoering op te vangen, m.a.w. evolueren naar een dynamische compositie. Daarvoor wordt verwezen naar hoofdstuk 6. 7

De RespiratoryScoreService wordt hier buiten beschouwing gelaten.

3.5 Besluit

22

Figuur 3.3: De verschillende Web services en hun interactie

3.5

Besluit

BPEL is een XML-taal die specifiek ontwikkeld is voor Web service compositie. Toch kan er ook (eenvoudige) logica gerealiseerd worden m.b.v. BPEL, bv. String-bewerkingen. Zoals uit de creatie van de SOFA Web service blijkt is het echter niet aangeraden complexe logica in BPEL te modelleren. De grafische voorstelling van een wat complexer BPEL-proces wordt namelijk snel onoverzichtelijk. De taalconstructies die BPEL aanbiedt om logica te implementeren zijn vrij beperkt. Een eerste oplossing hiervoor is het toelaten van Java code in het BPEL-proces, nl. BPELJ [18]. Rond dit concept bestaat echter veel controversie, bv. het verwikkelen van twee talen, het minder generiek zijn, . . . Een tweede alternatief is het gebruik van extra Web services om de nodige operaties te implementeren, m.a.w. het creëren van basisblokken voor de compositie. In tegenstelling tot van nul alles in BPEL te implementeren wordt hier het BPEL-proces ontlast met logica en regelt het enkel de samenwerking tussen de Web services (basisblokken) als een intermediaire dienst. Op die manier worden herbruikbare componenten afgescheiden van de flow. Het is aangewezen tijdens het ontwerp van de applicatie rekening te houden met dit aspect, zodat er niet oneindig veel ‘tussenliggende’ Web services moeten ontworpen worden.

3.5 Besluit

23

Figuur 3.4: Sequentiediagram van de SofaScoreService

AUTOMATISCHE COMPOSITIE

24

Hoofdstuk 4

Automatische compositie 4.1

Inleiding

Rond de term automatische compositie kan enige verwarring ontstaan. Daarom wordt er eerst even uitgelegd wat er juist met deze term bedoeld wordt. Ook het verschil met dynamische compositie komt aan bod. Automatische compositie is het samenstellen (combineren) van reeds bestaande (gedeployde) Web services at runtime, m.a.w. Web services worden gecombineerd op het moment dat een bepaalde functionaliteit gewenst is om deze functionaliteit te verkrijgen. Zeer belangrijk is dat bij een (volledige) automatische compositie geen tussenkomst is door de gebruiker. De verschillende Web services worden samengesteld om aan de wensen van de gebruiker te voldoen qua functionaliteit, maar er kunnen ook kwaliteitseisen opgelegd worden door de gebruiker: QoS-parameters zoals prijs, uitvoeringstijd, . . . Dynamische compositie echter, is een uitbreiding van automatische compositie. Er kunnen zich namelijk wijzigingen voordoen tijdens de uitvoering van de compositie. Stel dat een bepaalde Web service van de compositie het laat afweten. Dan kan er beslist worden om bv. onmiddellijk een nieuwe Web service te zoeken of een nieuwe compositie op te bouwen met als doel de fout op te vangen. Een andere mogelijkheid is dat bij het uitvoeren van de compositie QoS-parameters bepalen om al dan niet af te wijken van de compositie. Deze volledige gedachtegang is sterk gelijklopend met deze in [19]. Aan de hand van de literatuurstudie zijn de verschillende componenten (aspecten) ge¨ıdentificeerd die samen een basisarchitectuur omschrijven om automatische compositie te realiseren. Deze componenten worden behandeld in paragraaf 4.2. Daarna, in paragraaf 4.3 wordt een eerste versie van de proof-of-concept besproken. Deze versie verwezenlijkt een semi-automatische com-

4.2 Design en requirements van de architectuur voor automatische compositie

25

positie om dan in 4.4 te komen tot een tweede versie van de proof-of-concept die een volledige automatische compositie ondersteunt. Vervolgens wordt er aandacht besteed aan Quality Attributes van de architectuur (4.5). In paragraaf 4.6, werpen we een blik op enkele specifieke (technische) ontwerpbeslissingen. In paragraaf 4.7 uiteindelijk wordt de GUI besproken die rond de tweede versie van de proof-of-concept gebouwd is en wordt de werking ge¨ıllustreerd met twee medische voorbeelden.

4.2

Design en requirements van de architectuur voor automatische compositie

4.2.1

Semantische beschrijving van de Web services

Het combineren van Web services steunt op het principe van het ‘matchen’ van de input en output parameters van de verschillende Web services. De WSDL van een Web service geeft een functionele beschrijving en kan daardoor gebruikt worden om composities te maken. Aangezien onze toepassing zich binnen een intranet afspeelt, kunnen we de inputs en outputs zo kiezen dat de concrete betekenis kan afgeleid worden uit de naam. Wanneer de applicatie zich niet langer beperkt tot een intranet en de Web services niet langer tot eenzelfde organisatie behoren, is deze techniek te beperkend en niet langer praktisch toepasbaar. De oplossing bestaat er dan in een semantische beschrijving te maken van de verschillende Web services op een abstract niveau waaruit de concrete betekenis van de parameters kan afgeleid worden. Mogelijkheden hiervoor zijn: • OWL-S Dit is reeds eerder besproken in paragraaf 2.2.2. • WSMO Web Service Modeling Ontology1 • WSDL extensions WSDL extensions laten toe de WSDL uit te breiden, bv. met semantische beschrijvingen. Hierbij moet wel opgemerkt worden dat de WSDL’s van de externe Web services niet kunnen aangepast worden, tenzij deze lokaal gekopieerd worden (cf. analoge werkwijze van BPEL). Een specifiek voorbeeld van deze technologie is SAWSDL2 (Semantic Annotations for WSDL Working Group). 1 2

Zie ook http://www.wsmo.org Zie ook http://www.w3.org/2002/ws/sawsdl


26

Deze inputs en outputs, alsook de semantische beschrijvingen moeten in een of andere opslagplaats (vaak Service Repository of Knowledge Base genoemd) bijgehouden worden. Een eerste mogelijkheid is UDDI, een opslagplaats voor WSDL’s, uitbreiden zodat deze ook semantische beschrijvingen kan opslaan. Een alternatief, dat ook omvat is in de architectuur voor IZ, is een ebXML-implementatie.

4.2.2

Cre¨ eren van de compositie

Het doel van Web service compositie is het creëren van nieuwe functionaliteiten ten dienste van gebruikers. Daarom is het noodzakelijk dat de gebruiker op een of ander manier aangeeft welke functionaliteit hij wenst. Afhankelijk van hoe de compositie gebeurt zijn er enkele mogelijkheden: • De gebruiker beschrijft een bepaalde functionaliteit (bv. inputs en outputs, een OWL-S beschrijving, . . . ). • De gebruiker begint bij een bepaalde Web service en kan telkens weer kiezen uit alle mogelijke Web services die matchen met de huidige Web service. • De gebruiker kiest een aantal Web services (bv. grafisch voorgesteld) die hij wenst te combineren. Indien de functionaliteit gekend is, kunnen matching algoritmen trachten een bepaalde flow van Web services te construeren om deze functionaliteit te realiseren. Zoals eerder vermeld, wordt in het (volledig) automatische geval deze flow opgesteld zonder verdere tussenkomst van de gebruiker. Er zijn ook semi-automatische varianten, bv.: • Een selectie aanbieden aan de gebruiker van alle mogelijke Web services die volgen op een bepaalde Web service. Voor deze semi-automatische vorm is reeds een prototype ontwikkeld waarbij OWL en DAML-S de semantiek verzorgen [20]. De gecreëerde composities kunnen gerealiseerd worden in de vorm van DAML-S CompositeProcess zodat ze herbruikbaar zijn. • Voor een bestaande flow alle Web services opzoeken die de nodige functionaliteiten leveren voor bepaalde componenten van de flow. In een vergevorderd stadium kan de herbruikbaarheid van de compositie verhoogd worden door generalisatie van de parameters, daarvoor verwijzen we naar [21].


4.2.3

27

Compositie realiseren en deployen at runtime

De gegenereerde compositie moet omgezet worden naar een uitvoerbaar bestand. Dit kan bv. een BPEL of OWL-S bestandstype zijn. Daarnaast moet er ook een WSDL-document opgesteld worden zodat er uit de compositie effectief een Web service ontstaat. Eenmaal er een uitvoerbaar bestand bestaat van de compositie, moet dit bestand (eventueel met extra configuratie bestanden) op een server gedeployed worden. Het is pas wanneer dit gebeurd is dat men effectief de compositie kan aanspreken. Om de nieuw ontwikkelde (samengestelde) Web services onmiddellijk te kunnen hergebruiken in nieuwe composities, moet er automatisch een (semantische) beschrijving opgemaakt worden van deze Web services. Eenmaal deze beschrijving geregistreerd is in de UDDI of ebXML-registers, wordt de nieuwe Web service door de matching algoritmen behandeld zoals de originele Web services.

4.2.4

Samenvatting

We herhalen alle specifieke aspecten die deel uitmaken van (of invloed hebben op) een complete architectuur voor automatische compositie in het volgende overzicht: • Semantische beschrijving van de Web services Hoe wordt de Web services beschreven? • Opslagplaats voor de beschrijving van de Web services Waar worden de beschrijvingen van de beschikbare Web services bijgehouden? • Interactie met de gebruiker Welke informatie geeft de gebruiker aan de applicatie (en welke wordt verkregen)? • Een compositie genereren at runtime Hoe wordt de compositie opgemaakt? (Deze compositie stelt de nieuwe samengestelde Web service voor.) • De compositie uitvoerbaar maken Hoe wordt de compositie praktisch bruikbaar gemaakt? • Deployen van de uitvoerbare compositie Hoe wordt de compositie gedeployed?

4.3 Fase 1: Architectuur voor semi-automatische compositie

28

• De samengestelde Web service beschrijven Welke beschrijvingen worden er opgemaakt van de nieuwe samengestelde Web service? Er zijn natuurlijk alternatieven voor deze high-level architectuur. Bijvoorbeeld [22] presenteert een zeer abstract schema dat onafhankelijk is van o.a. het gebruikte platform en de compositietaal.

4.3

Fase 1: Architectuur voor semi-automatische compositie

Figuur 4.1: Architectuur voor semi-automatische compositie In figuur 4.1 is de architectuur van de eerste versie van de proof-of-concept te zien3 . Deze is in staat semi-automatische composities (m.b.v. de gebruiker) te realiseren. Er zijn wel enkele vereenvoudigingen, nl.: 1. Er is een eenvoudige semantiek toegepast, nl. de namen van de input en output parameters (t.t.z. WSDL parts) van de WSDL-berichten worden op een zodanige wijze gekozen dat ze interpreteerbaar zijn om Web services te koppelen. Dit principe is voldoende voor een proof-of-concept en de matching van Web services kan later uitgebreid worden met de oplossingen beschreven in sectie 4.2.1. Hierdoor valt bijgevolg ook de semantische beschrijving van de nieuwe Web service weg. 3

Om de figuur gemakkelijk te kunnen vergelijken met uitgebreide/aangepaste versies, blijven de gebruikte

letters geldig voor toekomstige versies.


29

2. Om de herbruikbaarheid van de verschillende MSS zo groot mogelijk te maken, worden alle Web services opgesplitst in functionele basis-services en kunnen we de Web services beperken tot services met één output parameter. Een Web service die bijvoorbeeld zowel RIFLE status teruggeeft als ABDose (advies om huidige dosis te verhogen of te verlagen), zal gesplitst worden in een service die RIFLE berekent en een service die de ABDose teruggeeft. 3. De Web services kunnen maar één op één ‘gematched’ worden. Dit betekent dat de inputs van een bepaalde Web service maar van één andere Web service mogen komen. Samen met de vorige veronderstelling levert deze proof-of-concept dus enkel sequenties van Web services op waarbij slechts een output van de ene Web service doorgegeven wordt aan de andere. Allereerst wordt er informatie gehaald uit een aantal WSDL-documenten (A). Deze documenten worden gezocht in een bepaalde opgegeven directory. De nodige informatie wordt in een Knowledge Base bijgehouden (B). Nu kan er begonnen worden aan de effectieve opbouw van de compositie (C). In iedere iteratie kan de gebruiker kiezen (D) uit één van de mogelijke Web services uit de Knowledge Base (E) die past op de huidige Web service van de compositie. Indien er geen mogelijkheden meer zijn of als de gebruiker wenst de compositie af te ronden, wordt de informatie van de nieuwe compositie doorgegeven aan de constructie module (F). De constructiemodule realiseert de compositie in BPEL, maakt de WSDL van de nieuwe Web service en construeert alle nodige bestanden om de nieuwe Web service te deployen (G). Uiteindelijk wordt de nieuw (gedeployde) Web service geconsumeerd (H) met een of meerdere inputs van de gebruiker (I) en wordt de uitkomst teruggegeven (J). In de eerstvolgende paragrafen wordt dieper ingegaan op enkele specifieke delen van deze architectuur. We eindigen met enkele kerngegevens van deze proof-of-concept.

4.3.1

Informatie verzameling

De allereerste stap haalt de nodige informatie op uit de WSDL-documenten. Deze informatie omvat onder andere de Web services, de porttypes, de operaties, de inputs & outputs. De proof-of-concept moet zowel informatie verkrijgen uit WSDL-documenten (deze stap) alsook een WSDL-document opmaken van de nieuwe Web service (zie 4.3.4 de constructie module). Er is reeds een pakket ontwikkeld specifiek voor deze doeleinden, nl. WSDL4J. WSDL4J is een open source project en voorziet een standaard Java interface voor zowel het aanmaken van


30

nieuwe WSDL-documenten als voor het extraheren van informatie uit WSDL-documenten. Het project heeft als doel een implementatie te leveren voor de JSR 110 (Java Specification Request 110: Java API’s for WSDL) [23]. In deze module wordt WSDL4J enkel toegepast om de WSDL-documenten in te lezen. Dit inlezen gebeurt m.b.v. de WSDLReader klasse, die een Definition object aanmaakt van elk WSDL-document.

4.3.2

Knowledge Base

De Knowledge Base (voortaan KB genoemd) houdt alle informatie over het beschikbare arsenaal van Web services bij. Er zijn verschillende implementatiemogelijkheden hiervoor (databank, XML-bestand, tekstbestand). We hebben echter niet voor een externe opslag gekozen, maar voor een interne array die objecten bevat van het type ServiceImpl uit WSDL4J. De ServiceImpl objecten zijn eenvoudig te verkrijgen uit de ingelezen Definition objecten. De keuze voor de interne array is gebaseerd op het feit dat een externe KB voor deze proof-of-concept geen fundamentele functionaliteiten aanbrengt en toch een (serieuze) tijdsinvestering zou vereisen.

4.3.3

Compositie

De eerder vermelde veronderstellingen maken het niet mogelijk dat inputs van een Web service van verschillende andere Web services komen. Bovendien is de compositie nog semi-automatisch in deze fase. Het algoritme, dat voor de creatie van de compositie gebruikt wordt, is dus vanzelfsprekend niet zo ingewikkeld, maar een goede oefening voor de volgende fase waarin de compositie volledig automatisch zal gebeuren. Het is belangrijk om in te zien dat de gebruiker in deze fase vooraf geen gewenste functionaliteit opgeeft. Hij kiest enkel uit mogelijke operaties (zoals hieronder verder uitgelegd). Algoritme

In de eerste iteratie wordt de gebruiker een lijst aangeboden met alle beschikbare

Web service operaties. Vanaf deze eerste keuze (die wordt toegevoegd aan de compositie), is er een constant patroon dat telkens de mogelijkheden (Web service operaties) aanbiedt die passen met de laatst toegevoegde Web service operatie aan de compositie. De matching vergelijkt de WSDL part van het output bericht van de laatste Web service in de compositie met alle parts van de input berichten van alle Web services in de KB. Indien er geen mogelijkheden meer zijn uit de KB of als de gebruiker de compositie wenst te beëindigen stopt het algoritme. De compositie zelf wordt gemodelleerd a.d.h.v. een array. Deze array bestaat uit objecten van


31

het type SolutionOperationAndWS, dat o.a. een ServiceImpl en OperationImpl object als attributen heeft.

4.3.4

Constructie

Zoals in de basisarchitectuur in 4.2 aangehaald is, moeten er verscheidene zaken geconstrueerd worden: 1. een BPEL-document dat de compositie voorstelt; 2. een WSDL-document dat de nieuwe Web service beschrijft; 3. een geheel van JAR, ZIP- en andere projectbestanden. Al deze zaken kunnen door NetBeans gegenereerd worden. De NetBeans-code is echter niet zomaar over te nemen omdat deze nogal sterk verweven is met de GUI en andere interne klassen. Om tot semi-automatische compositie te komen, was het dus noodzakelijk de constructie van deze zaken volledig zelf te implementeren. Omwille van de eerder vermelde vereenvoudigingen heeft het BPEL-document een structuur in de vorm van figuur 4.2. Ieder BPEL-document bevat standaard een sequence activiteit met daarbinnen een receive en een reply activiteit. Daarenboven zijn er sowieso ook een of meerdere assign en invoke activiteiten vertegenwoordigd. Zoals de figuur aantoont worden in de huidige context assign en invoke activiteiten sequentieel afgewisseld met elkaar. Er zijn twee klasses specifiek ontworpen voor de BPEL-generatie: BpelCreationBySequentialTraject.java en BpelDocument.java (er zijn nog extra klasses voor o.a. BPEL-activiteiten en BPEL-constanten). De constructor van de klasse BpelDocument stelt een basisvorm van een BPEL-document op (zie figuur 4.3). Naast deze constructor zijn de belangrijkste methodes: addImport, addPartnerLink, addVariable en addActivityForSequentialComposition. Met behulp van deze methodes bouwt de klasse BpelCreationBySequentialTraject, op basis van de array van de compositie creatie module, het BPEL-document iteratief op voor de sequentiële compositie. Het WSDL-document wordt met behulp van WSDL4J (zie ook 4.3.1) gegenereerd. WSDL4J bevat klasses voor de verschillende elementen van een WSDL-document, nl.

Definition,

TypesImpl, MessageImpl, PartImpl, OperationImpl, PortTypeImpl, BindingImpl, PortImpl, ServiceImpl, SOAPAddress, . . . Deze klasses bezitten attributen voor alle XML-attributen van


32

Figuur 4.2: Voorbeeld van een mogelijk BPEL-document voor een sequentiële compositie

Figuur 4.3: Opmaak van het basis BPEL-document de WSDL-elementen die ze symboliseren (bv. namespaces). De WSDL-generatie geeft deze attributen de correcte waarden. Daarnaast zorgt ze er ook voor dat de objecten van deze klasses aan mekaar gekoppeld worden zodat de hiërarchische structuur van een WSDL-document verkregen wordt. Het uiteindelijke resultaat is een Definition object dat m.b.v. een WSDLWriter kan weggeschreven worden naar een WSDL-document.


33

En tenslotte, om de nieuwe Web service te deployen is het build proces van NetBeans nagebootst. We creëren namelijk alle bestanden van het build proces van een BPEL-module project en van een composite application project (zie verder). Dit composite application project bevat het BPEL-module project. Er is hiervoor uitbundig gebruik gemaakt van het java.util.jar package, nl. voor de JAR/ZIP-creatie en voor de aanmaak van de manifest bestanden (via Manifest klasse). Uiteindelijk levert dit proces één ZIP-bestand op. Ontleding ZIP-bestand van een composite application, dat een BPEL-module project bevat, uit NetBeans Het resultaat van de ontleding is hieronder te zien (projectnaam van de composite application is “CompositeDummyTravel” en van de BPEL-module “TravelService”). 1. META-INF directory (bevat twee bestanden: MANIFEST.MF & jbi.xml) 2. CompositeDummyTravel.jar • META-INF directory (bevat twee bestanden: MANIFEST.MF & jbi.xml) • Partners directory (bevat de WSDL’s van alle partner Web services in gescheiden directories) • TravelService.bpel • TravelService.wsdl 3. sun-http-binding.jar • META-INF directory (bevat twee bestanden: MANIFEST.MF & jbi.xml) • CompositeDummyTravel directory (bevat een Partners directory zoals deze in CompositeDummyTravel.jar, alsook TravelService.wsdl) • sun-http-binding directory (bevat niets) Het bestand CompositeDummyTravel.jar is het JAR-bestand dat gegenereerd wordt bij de build van de BPEL-module. Enkel de naam is gewijzigd en was oorspronkelijk SEDeployment.jar.

4.3.5

Deployment

Vooraleer we de nieuwe Web service kunnen aanspreken moet deze gedeployed worden (er wordt gewerkt met een GlassFish server van het OpenESB platform, zie ook paragraaf 3.3). Er zijn hiervoor verschillende mogelijkheden:


34

• Het ZIP-bestand uit de constructie module kopiëren naar de autodeploy folder4 van GlassFish. Valide ZIP-bestanden in deze map worden automatisch gedeployed op de GlassFish application server. • ‘Administration Commands’ uitvoeren vanuit de applicatie. De application server bezit over een administration module ‘asadmin’ die toelaat om de application server via commando’s5 te beheren. De interface van deze module is een klassiek commando prompt venster. In plaats van de commando’s in te geven in deze commando prompt, construeren we de gewenste commando Strings in onze applicatie en voeren deze ook uit m.b.v. Java code (via het runtime object dat geassocieerd is met de Java applicatie). • De Sun Java System Application Server gebruikt Application Server Management eXtensions (AMX) [24] die toelaten om de application server te beheren en te controleren. Een application server bestaat uit een aantal beleidsdomeinen. Elk domein bevat op zijn beurt beheerde bronnen zoals de application server instantie of een entiteit hierin. Deze bronnen zijn toegankelijk via JMX6 MBeans (Management Beans) en zijn dus uiteraard aanspreekbaar via de standaard JMX API. Het gebruik van de client mogelijkheden die AMX levert blijkt echter een stuk geschikter te zijn. AMX bestaat dus uit een client en server gedeelte. Het client gedeelte levert dynamische proxies. Op die manier kan de API gebruikt worden zonder dat er kennis nodig is over JMX. Hiervoor moet wel appservext.jar opgenomen worden in het class-path. De volledige AMX API is te vinden in de com.sun.appserv.management package. De implementatie aan de server zijde wordt mogelijk gemaakt door de eerder besproken JMX MBeans. • ANT7 (Another Neat Tool) In NetBeans wordt het deployen uitgevoerd via een ANTscript, omdat door het gebruik van een GUI en de automatische bestandsgeneratie heel wat zaken moeten bijgehouden worden of terug verwijderd. Op die manier moet niet steeds een hercompilatie plaats vinden. 4

Dit pad is afhankelijk van de versie van de OpenESB installatie, bv. “..\openesb\glassfish-v2-ur1-b09d-patch-

20071229\domains\domain1\autodeploy”. 5 Een overzicht van de commando’s van de Sun Java System Application Server 9.1 is te vinden op http://docs.sun.com/app/docs/doc/819-3675/6n5slue6r?l=fr&a=expand 6 Java Management Extensions levert een standaard manier om Java gebaseerde applicaties, systemen en netwerken te beheren http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/ 7 ANT is een programma die het automatiseren van bouwprocessen in software toelaat. http://ant.apache.org/

Zie ook


35

Alle oplossingen zijn onderzocht. De eerste twee alternatieven zijn uitgevoerd. De derde oplossing echter nam teveel tijd in beslag voor deze proof-of-concept en is daarom stopgezet. Een ANT-script is bij ons in eerste instantie ook heel wat minder nuttig. Het ANT-script zou namelijk eerst automatisch door de applicatie moeten gegenereerd en bijgehouden worden en bovendien gebeuren er normaal geen hercompilaties. Bijgevolg hebben we dan ook voor de eerste mogelijkheid gekozen en is deze autodeploy methode in de proof-of-concept ge¨ımplementeerd. Het deployen heeft twee problemen met het gecreëerde ZIP-bestand aan het licht gebracht. Ten eerste is het niet voldoende gewoon het ZIP-bestand aan te maken, er moet namelijk een compressie toegepast worden. Deze compressie kan ingesteld worden m.b.v. de setLevel methode van de JarOutputStream klasse. Het compressie level is ingesteld op niveau 0. Ten tweede moeten de slashes in de JarEntries aangepast worden van backward slaches naar forward slashes.

4.3.6

Gebruiken van de nieuwe Web service

Het allerlaatste dat moet gebeuren is het aanspreken van de nieuwe (gedeployde) Web service. De gebruiker heeft een compositie gekozen en die moet nu met zijn waarden aangeroepen worden (deze worden gevraagd na het deployen). Daarna, als de compositie doorlopen is moet het correcte resultaat aan de gebruiker terugbezorgd worden. Er zijn drie testapplicaties ontwikkeld via verschillende technologieën: 1. Een client applicatie m.b.v. de JAX-WS 2.1 API, nl. een jbiclient. De client code wordt m.b.v. wizards automatisch gegenereerd in NetBeans, dat ook een ‘Web Service Reference’ aangemaakt. Het nadeel is echter dat de ‘Web Service Reference’ maar voor een bepaalde Web service geldt: indien er een nieuwe implementatie is van de Web service moet deze referentie ‘gerefreshed’ worden. Als ook de naam van de Web service wijzigt moet een volledig nieuwe referentie gemaakt worden. 2. Dynamic Proxy technologie m.b.v. de JAX-RPC API (JWSDP 1.6). Bij deze oplossing moet de locatie van de WSDL op het moment van compile time niet bekend zijn, de interface van de Web service (nl. de operaties) echter wel. Er zijn namelijk extra klasses nodig waarvan één de interface van de Web service modelleert. 3. DDI (Dynamic Discovery and Invocation) technologie m.b.v. de JAX-RPC API (JWSDP 1.6). Dit is ongetwijfeld het meest flexibele alternatief. Er moet niets van de Web service bekend zijn at compile time en er moeten ook geen extra klasses gemaakt worden.

4.4 Fase 2: Volledig automatische compositie

36

De enige echt bruikbare oplossing voor de proof-of-concept is het derde alternatief. Met dit alternatief kan de invocatie aangepast worden aan een willekeurige Web service naam en interface. Voor enkele specifieke problemen met de twee laatste alternatieven (o.a. incompatibele JAR-bestanden) verwijzen we naar bijlage C.

4.3.7

Enkele specifieke gegevens van eerste fase

• 44 klasses • Ongeveer 6500 regels code • 10 packages (zonder subpackages, en waarvan 1 voor XSD schema’s)

4.4

Fase 2: Volledig automatische compositie

Figuur 4.4: Architectuur voor volledig automatische compositie De tweede fase maakt het mogelijk composities volledig automatisch op te bouwen. De gebruiker geeft nu een bepaalde output en één of meerdere inputs aan de applicatie. Op basis van deze gegevens wordt er zonder bijkomende interactie van de gebruiker autonoom een (BPEL-) compositie aangemaakt. Net zoals in fase 1 wordt deze samengestelde Web service ook automatisch gedeployed en daarna aangeroepen. Figuur 4.4 toont de architectuur van de tweede fase. De


37

eerste twee veronderstellingen die we gemaakt hebben in de eerste fase (zie paragraaf 4.3) blijven geldig, nl. de eenvoudige semantiek en het feit dat een operatie van een Web service maximum één output kan bezitten. De derde (en laatste) veronderstelling (Web services kunnen maar een-op-een ‘gematched’ worden) is aangepast. Inputs van een bepaalde operatie van een Web service kunnen nu afkomstig zijn van operaties van verschillende Web services. Er is dus een een-op-meer ‘input matching’ mogelijk. In hetgeen volgt worden de belangrijkste aanvullingen en wijzingen t.o.v. fase 1 kort besproken (deze komen later uitvoerig aan bod). Allereerst kan de gecreëerde compositie gevisualiseerd worden (K,L) in de vorm van een graaf (dit is ook ge¨ımplementeerd voor de semi-automatische compositie). Het pad (K,L) is getekend in stippelijnen omdat de visualisatie een optie is. De visualisatie zelf draagt immers niets fundamenteel bij tot de automatische compositie. Daarnaast is er zowel in de compositie creatie module als in de constructie module (t.t.z. enkel voor de BPEL-generatie) een opsplitsing gemaakt voor de twee (hoofd)algoritmes (nl. semi-automatisch en automatisch). De overige modules zijn aangepast zodat ze door beide algoritmes benut worden. De mapping van alle modules (componenten) van dit reference model op software componenten is aangegeven op figuur 4.5. Naast deze packages zijn er ook nog enkele voorzien voor specifieke functies: • main Dient enkel om de configuratie instellingen te laden en de applicatie op te starten. • propertiesObjects Alle properties objects (reeds eerder vermeld) zijn hierin vervat. • tasks Dit package verzorgt een soort overkoepelende laag in onze architectuur. • XmlSchemas Dit package bevat XML-schema’s die nodig zijn voor bv. validatie. Overkoepelende laag in de architectuur d.m.v. taken Om de structuur van de architectuur overzichtelijker te maken hebben we een takkenpakket samengesteld. Deze taken zijn eenvoudigweg functies die een bepaalde sequentie van handelingen uitvoeren. Er worden enkel taken gedefinieerd voor de voornaamste high-level functionaliteiten. Daardoor wordt er een soort overkoepelende laag gecreëerd in de architectuur. Zoals op figuur 4.6 te zien is, zijn er twee hoofdtaken: een voor semi-automatische compositie en een voor automatische compositie. Deze hoofdtaken zijn hiërarch opgebouwd uit subtaken. De figuur toont duidelijk de herbruikbaarheid van verschillende taken aan. Een bijkomend pluspunt van


38

Figuur 4.5: Mapping van de componenten van het reference model op software componenten (packages) deze taken is dat ze een snelle herschikking van de sequentie van handelingen van de applicatie toelaat (tenzij er bepaalde afhankelijkheden zijn natuurlijk). Configuratie instellingen Om geen onnodige argumenten te moeten meegeven aan de applicatie of om niet steeds de code te moeten hercompileren voor nieuwe parameters, maken we gebruik van een XML-bestand om de configuratie instellingen te bewaren. Er bestaan verschillende manieren om configuratie instellingen te gebruiken of te bewaren: runtime command line opties (argumenten aan main meegegeven), hard coderen (vereist de vermelde hercompilatie bij wijziging), een tekstbestand, een XML-bestand (bv. door ANT toegepast), een JDBC Datasource, . . . Vermits de proof-of-concept reeds interactie met XML-bestanden bevat, kan het beheren van de configuratie instellingen gemakkelijk zelf ontwikkeld worden. Er bestaan echter verschillende pakketen


39

Figuur 4.6: Hiërarchie van de taken met uiterst uitgebreide functionaliteiten, o.a. JFig8 en Commons Configuration9 . De proof-of8

JFIG is een open source pakket dat o.a. volgende zaken ondersteunt: het gebruik van variabelen in configu-

ratiebestanden en overerving tussen configuratiebestanden, zie ook http://jfig.sourceforge.net 9 Commons Configurations is een deel van het Apache project Commons, dat zich focust op alle aspecten van herbruikbare Java componenten, zie ook http://commons.apache.org/configuration


40

concept maakt gebruik van het JFig pakket. Dit pakket is eenvoudig te gebruiken en werkt nauw samen met LOG4J. De indeling van het configuratie bestand is te zien in figuur 4.7.

Figuur 4.7: Configuratie bestand van de proof-of-concept

4.4.1

Compositie

De compositie creatie module moet nu d.m.v. een algoritme volledig autonoom een compositie construeren. Vermits het aantal mogelijkheden hiervoor eindeloos is, volgt er eerst een algemene bespreking omtrent dit probleem. Daarna gaan we dieper in op het algoritme dat voor de proofof-concept ontwikkeld is (zowel het basis algoritme als de uitbreiding voor QoS-parameters). Algemene beschouwing automatische compositie Onder automatische compositie verstaan we de constructie van een compositie zonder interactie van de gebruiker. Deze constructie gebeurt volgens een bepaald algoritme waarvoor heel wat mogelijke alternatieven zijn. Ruwweg kunnen we zeggen dat er drie grote categorieën zijn: 1. Algoritmes die beginnen met een of meerdere input parameters en zo van boven naar onder


41

zoeken naar een of meerdere output parameters, zie ook [19]. 2. Algoritmes die beginnen met een of meerdere output parameters en zo van onder naar boven zoeken naar een of meerdere input parameters, zie ook [25, 26, 27]. 3. Een hybride oplossing van de twee vorige categorieën. Bron [28] geeft ook deze categorieën aan en verantwoordt dat de tweede categorie beter presteert dan de eerste. Naast deze categorieën zijn er nog talloze optimalisaties en technieken, we geven er enkele: • Iedere operatie kan ten hoogste eenmaal voorkomen in een bepaalde sequentie van operaties van input tot output, m.a.w. in een graaf kan elke operatie maar eenmaal voorkomen per tak die loopt van een input node tot een output node. Deze optimalisatie heeft tot doel oneindige lussen te vermijden. Een mogelijke uitbreiding is het vermijden van transitieve operaties. Dit zijn een geheel van twee of meerdere operaties in een bepaalde volgorde zodat het begin en einde van de sequentie gelijk zijn en er uiteindelijk dus geen nuttig resultaat is geboekt. Met de eerstgenoemde veronderstelling echter, kan dit probleem ten hoogste eenmaal optreden. • In [25, 27] stopt het algoritme bij een bepaalde diepte, m.a.w. er is een maximum aantal operaties dat na elkaar kan voorkomen in een bepaald pad. • In [26] introduceren ze een ‘chain data structure’ (nl. een ‘Web service chain table’ ), deze wordt gebruikt om relaties tussen de Web services te beschrijven. • De compositie kan geoptimaliseerd worden op basis van niet-functionele eigenschappen van de Web service (of van de operatie). Functionele eigenschappen zijn IOPE en ‘Goals’ van de Web service, bv. de inputs en outputs die we tot nu toe gebruikt hebben voor de matching. Niet-functionele eigenschappen komen maar van pas als er meerdere composities mogelijk zijn, m.a.w. ze kunnen dus enkel gebruikt worden om het aantal mogelijke oplossingen te beperken of hen te rangschikken. Voorbeelden van niet-functionele eigenschappen zijn QoS-parameters zoals cost, security, performance, reliability. Zie ook [27]. Ontwikkeld algoritme voor automatische compositie Voor de proof-of-concept is geopteerd voor een algoritme van categorie 2. Vermits onze operaties (van de Web services) slechts één output kunnen hebben, vertrekken we vanuit deze output


42

parameter. Op vlak van structuur is er zoveel mogelijk hergebruikt van het vorige algoritme (voor semi-automatische compositie) zodat deze gemakkelijk naast elkaar kunnen bestaan en getest worden. Voor het proces van de automatische compositie wordt er intern een graaf opgesteld m.b.v. de JGraphT library. Deze library voorziet de nodige objecten (zoals knopen en takken) en algoritmes om met grafen te kunnen werken. Er wordt een omvangrijk geheel van types grafen ondersteund, o.a. gerichte/niet-gerichte grafen, gewogen/niet-gewogen grafen [29]. De gebruikte graaf modelleert de operaties a.d.h.v. knopen en de takken tussen deze knopen stellen de parameters voor die doorgegeven worden tussen operaties. Voor de gewenste output en de gegeven input(s) worden er ook knopen gecreëerd, nl. ‘dummy output/input nodes’. De werking van het algoritme wordt geschetst in de figuren 4.8 (hoofdalgoritme) en 4.9 (onderdeel van het algoritme). Het algoritme is gebaseerd op de Depth-First (DF) techniek . Er wordt steeds een node beschouwd, nl. de startnode (de eerste maal is dit de dummy output node). Voor elke input van deze startnode wordt er gecontroleerd of deze overeenkomt met een gegeven input. Indien dit niet het geval is wordt er gezocht naar een operatie die deze input als ouput heeft. Deze zoekopdracht beschouwt enkel de verzameling van toegelaten operaties, dit zijn de operaties die nog niet gebruikt zijn in de huidige tak. Is er een match, dan wordt voor de gevonden operatie een kindernode toegevoegd en een verbinding met de startnode geconstrueerd. De verbinding draagt de naam van de parameter als label. Eenmaal deze knoop is toegevoegd aan de graaf, wordt de operatie uit de lijst gehaald van toegelaten operaties. Daarna wordt het algoritme recursief opgeroepen voor alle inputs van de toegevoegde operatie. Zo wordt er dus geleidelijk aan een graaf opgesteld te beginnen bij de output en gaande richting de input. Gedurende het hele proces worden er ook per input van elke knoop twee vlaggen (booleans) bijgehouden: de ene vlag geeft aan of de input al onderzocht is en de andere of er reeds een match is (zowel met een gegeven input als met een ouput parameter van een andere operatie). Het subgedeelte (de cirkel A waarop figuur 4.9 inzoomt) beslist in eerste fase of al dan niet alle mogelijke paden moeten gezocht worden. In de proof-of-concept wordt de optie om alle paden te zoeken niet uitgebuit (bv. voor globale optimalisatie). Er wordt nu gekeken of de kindernode leidt tot minstens één match met de gegeven inputs. Indien dit niet het geval is wordt deze kindernode terug verwijderd. Op die manier ontstaan er geen doodlopende paden. De verschillende inputs van een Web service worden dus wel recursief onderzocht, maar als ze niet leiden tot een gegeven input wordt deze recursieve subgraaf terug verwijderd. Daarna wordt


Figuur 4.8: Algoritme voor automatische compositie

43


44

Figuur 4.9: Deel A van het algoritme voor automatische compositie er gecontroleerd of er een oplossing gevonden is. Onder een mogelijke oplossing verstaan we een graaf waarbij ten minste één gegeven input wordt bereikt. Indien er een oplossing gevonden is stopt het algoritme. Ontwikkeld algoritme automatische compositie met ondersteuning QoS-parameters Het algoritme dat reeds ontwikkeld is kan uitgebreid worden door de strategie van de compositie creatie te baseren op QoS-parameters. Zoals eerder vermeld kunnen niet-functionele eigenschappen slechts een rol spelen als er meerdere composities mogelijk zijn. We maken een onderscheid (voor het gebruik van QoS-parameters) tussen lokale en globale optimalisatie. Onder lokale optimalisatie verstaan we dat er voor gelijkaardige operaties een optimalisatie plaatsvindt die de beste operatie kiest op basis van QoS-parameters. Globale optimalisatie zien we als de verzamel-


45

ing van technieken van optimalisaties die op takniveau werken. Enkele voorbeelden van globale optimalisatie zijn: • De verschillende oplossingen kunnen gerangschikt worden op basis van een totale QoSwaarde per oplossing. • Bij parallelle uitvoering van Web services kan men in beide takken kiezen voor de snelste Web service. Een alternatieve vorm voor deze situatie is mogelijk: als voor de ene tak een bepaalde QoS-waarde geldt, heeft het eigenlijk geen zin om bij de andere tak te zoeken naar een QoS-waarde die veel beter is. Er moet wel opgemerkt worden dat het risico verhoogt. Stel bv. dat de uitvoeringstijd beschouwd wordt. Als de tweede tak minder snel gekozen wordt dan mogelijk, dan is er een grotere kans dat bij vertraging van deze tak de totale uitvoeringstijd vergroot. Het ontworpen algoritme hanteert een techniek die onder de categorie van de lokale optimalisaties valt. Het belangrijkste verschil met het algoritme zonder QoS zit in het begin van het algoritme (zie figuur 4.10). Hier worden eerst alle operaties van de Web services in een lijst gestopt die matchen met de gewenste output. Er wordt ook rekening gehouden met het feit dat de inputs van de Web services verschillend kunnen zijn en dat deze verschillende inputs bijgevolg ook tot andere paden kunnen leiden. We kijken dus welke Web services volledig gelijkaardig zijn qua functionaliteit: dit betekent eenzelfde output en dezelfde inputs voor de geselecteerde operatie. Van al deze gelijke Web services wordt nu telkens deze overgehouden die de beste QoS biedt. Op die manier behouden we een lijst van allemaal verschillende Web services met beste QoS. Vervolgens wordt deze lijst gesorteerd volgens stijgende of dalende QoS-parameter, afhankelijk van wat de QoS-parameter voorstelt. Zo’n QoS-parameter is bijvoorbeeld de uitvoeringstijd en we zullen hier in het vervolg mee verder werken. We rangschikken dus volgens stijgende QoS. Dit betekent dat een Web service met een lagere QoS-parameter prioriteit krijgt. Het vervolg van het algoritme is analoog aan het algoritme zonder QoS (het algoritme gaat nu verder bij de oranje cirkel in figuur 4.8, behalve dat er geen output matching meer gebeurt), behalve dat nu de gerangschikte lijst (van Web services die matchen met de output) wordt overlopen. Op die manier probeert het algoritme een traject te vinden met een Web service met de beste QoS. Indien dit niet lukt, wordt telkens de volgende Web service in de lijst beschouwd. Per operatie moet er nu een QoS-parameter beschikbaar zijn. Deze wordt in het WSDLdocument geplaatst onder het definitions element (alle operaties van eenzelfde Web service


46

hebben dus een gelijke QoS-waarde). Hoe dit concreet ge¨ımplementeerd is wordt uitgelegd in sectie 5.1.1 .

Figuur 4.10: Begin van het algoritme voor automatische compositie met QoS Het algoritme baseert zich dus op één QoS-parameter. Dit kan eenvoudig uitgebreid worden om meerdere QoS-parameters te beschouwen, nl. door een lineaire combinatie van verschillende QoS-parameters te nemen die als resultaat een algemene QoS-parameter geeft. In het specifieke geval waarbij alle parameters even belangrijk zijn, leidt dit tot een minimale som van herschaalde parameters (dit zijn parameters waarvan de waarden zich situeren in het interval [0,1]). Omdat het algoritme een lokale optimalisatie doet, kan het niet weten welke Web service zal leiden tot de beste totale QoS. Dit is immers een eigenschap van lokale optimalisatie. In heel uitzonderlijke gevallen (zie paragraaf 5.3.2) kan het voorkomen dat dit type algoritme (verder QOSSORT genoemd) altijd een slechtere totale QoS zal bekomen dan het basisalgoritme zonder QoS.


47

Om dit euvel op te lossen kan er met een gepermuteerde lijst worden gewerkt in plaats van een gesorteerd lijst. Bijgevolg wordt er dan eigenlijk willekeurig een Web service gekozen uit de eerder opgestelde lijst. Zo laat dit algoritme (verder QOSRANDOM genoemd) toe dat een Web service gekozen wordt met een op het eerste zich slechtere QoS dan de beste QoS-Web service in de lijst maar dat dit toch leidt tot een betere totale QoS. Opmerking betreffende de gegeven inputs aan de algoritmes Doordat de compositiealgoritmen via een diepte eerst techniek een compositie kunnen vinden van zodra er een match is met minstens één input, bestaat de kans dat bepaalde Web services nog andere inputwaarden verwachten van de gebruiker. Het algoritme verwacht dus niet dat de inputs exhaustief zijn. Deze nodige inputs worden eerst op een recursieve manier onderzocht, omdat ze op die manier misschien ook kunnen leiden tot een gegeven input. Indien dit niet het geval is wordt de rechtstreekse inputwaarde aan de gebruiker gevraagd. Zo wordt vermeden dat bij een groot tekort aan gegeven inputs een hele resem inputwaarden zou gevraagd worden aan de gebruiker, omdat – door recursie – de bomen alleen maar groter worden en telkens meer inputs vergen. Figuur 4.11 illustreert het principe. Als output wordt HasSepsisShock gegeven en als input HasSIRS. Bij de gevonden compositie hebben beide Web services van de compositie nog een extra inputwaarde nodig. Naast HasSIRS zullen de inputwaarden voor HasInfection en HasShock bijgevolg ook aan de gebruiker gevraagd worden.

Figuur 4.11: Principe van de inputs die gevraagd worden aan de gebruiker


4.4.2

48

Constructie

In de constructie module moet enkel de BPEL-generatie aangevuld worden. Nu er via een automatisch matching algoritme een volledige graaf opgesteld is die aangeeft hoe de Web services met elkaar gekoppeld zijn, is het nog nodig om deze graaf om te zetten naar de uitvoerbare compositietaal BPEL. Om automatisch BPEL-code te creëren voor de compositie is het noodzakelijk eerst de structuur van de gegeneerde graaf te observeren en daaruit af te leiden door welke BPEL-code dit ondersteund kan worden. Zoals beschreven in 3.1 kunnen sommige activiteiten recursief gebruikt worden. Een flow behoort altijd tot een zekere sequence maar bevat ook altijd een aantal sequences. Op die manier treedt recursie op. Een mogelijk voorbeeld van dit principe van recursie wordt gepresenteerd in figuur 4.12. De verzameling van activiteiten van de eerste fase (assign, invoke, reply, receive en sequence) wordt dus aangevuld met een extra activiteit, nl. flow. Immers, andere activiteiten (bv. if, else, while, . . . ) veronderstellen we vervuld door de beschikbare services en mogen dus buiten beschouwing gelaten worden voor de compositie.

Figuur 4.12: Voorbeeld van een mogelijke BPEL-sequentie die flow’s bevat

Algoritme BPEL-generatie Het algoritme moet dus de bekomen graaf van de compositie creatie module omzetten in een BPEL-document. Er wordt begonnen onderaan in de graaf, namelijk bij de output. Dit biedt het voordeel dat we makkelijk kunnen detecteren wanneer er een nieuwe flow moet gestart worden. Immers, indien een Web service operatie meerdere inputs heeft, zullen we om prestatieredenen


49

altijd proberen deze inputs parallel op te roepen. Bijgevolg is dit punt in de graaf (nl. de huidige operatie) het einde van een flow (indien we kijken van bovenaan richting output). In het andere geval - een operatie met één input - bevinden we ons binnen een sequence. Indien de opgevraagde node dus meerdere inputs bevat voegen we een flow toe aan onze sequence. Vervolgens overlopen we alle inputs van deze node. We controleren eerst of de input toevallig niet één van de inputs is van de samengestelde Web service. Indien dit zo is voegen we een sequence toe aan de flow. Via een assign mappen we ook de variabelen van de samengestelde Web services met de variabelen van de operatie die tot deze node behoort. In het andere geval kijken we welke oudernode in de graaf met deze input verbonden is en vragen we deze node op. We voegen ook een sequence toe aan de graaf. Er moeten bovendien nog heel wat andere zaken ingesteld worden van de oudernode: in de eerste plaats de namespace importeren en de partnerlink en variabelen toevoegen. Vervolgens voegen we de assign toe en verzorgen we de juiste mapping van de variabelen en tenslotte voegen we nog een invoke in. In deze stap is echter de volgorde van toevoegen in de sequence van belang, terwijl dit in de vorige stappen minder het geval was. Van bovenaf gezien wordt een invoke immers opgevolgd door een assign en niet omgekeerd. Behalve in het geval we de input van de samengestelde Web service bereikt hebben, wordt er een extra assign geplaats boven de invoke. Als laatste stap roepen we de methode nu recursief op, waarbij we de oudernode en de huidige ’structured activity’ waarin we ons bevinden meegeven als argumenten. Als de opgevraagde node maximaal één input bevat, controleren we direct of deze input geen input is van de samengestelde Web service. De rest van het verhaal is analoog als bij het geval met meerdere inputs. Een overzicht van het recursieve gedeelte (methode addBpelOperationRecursive) van het algoritme wordt gegeven in figuur 4.13.

4.4.3

Visualisatie

Deze module is in staat de gegenereerde composities (grafen) te visualiseren, zowel voor de semiautomatische als voor de automatische compositie. In het semi-automatische geval moet er eerst nog een graaf gecreëerd worden van de compositie. Deze compositie is dan immers opgeslagen als een array. De automatische compositie werkt intern reeds graafgebaseerd. De visualisatie van composities vormt een belangrijk onderdeel van de GUI (deze komt aan bod in de laatste paragraaf). Voor deze visualisatie is de JGraph library gehanteerd. Dit is een


Figuur 4.13: Algoritme voor BPEL-generatie

50

4.5 Quality Attributes

51

Swing-style graaf component die samen met JGraphT kan aangewend worden. De layout van de graaf kan geoptimaliseerd worden m.b.v. het betalend pakket Layout Pro. Dit pakket kan o.a. de knopen automatisch positioneren [29, 30].

4.4.4

Enkele specifieke gegevens van de tweede fase

De volgende gegevens zijn inclusief de voorbereidingen voor de testen (zie paragraaf 5.1). • 66 klasses • Ongeveer 10100 regels code • 14 packages (zonder subpackages, en waarvan 1 voor XSD schema’s)

4.5

Quality Attributes

Een systeem wordt ontwikkeld om een bepaalde functionaliteit te realiseren. Naast de gewenste functionaliteit kunnen ook kwaliteitseisen belangrijk zijn. Hoofdzakelijk deze eisen bepalen de structuur van de applicatie, m.a.w. de software architectuur in ons geval. Het is immers de wijze waarop aan de gewenste functionaliteit voldaan wordt, dat de kwaliteit van het systeem bepaalt [31]. De kwaliteit wordt beoordeeld a.d.h.v. een zeer uitgebreid pakket van Quality Attributes, o.a.: • usability: de gebruiksvriendelijkheid van het systeem; • testability: hoe gemakkelijk is het systeem te testen; • scalability: de schaalbaarheid van het systeem, bv. van 100 naar 10000 beschikbare Web services; • modifiability: de mogelijkheid tot aanpassen van het systeem; • time to market: tijdsduur om het systeem verkoopsklaar te krijgen; • ... Deze Quality Attributes worden onderverdeeld in verschillende categorieën. Voor software applicaties zijn dit: System Quality Attributes, Architectural Quality Attributes & Business Quality Attributes. We beschouwen enkel System en Architectural Quality Attributes. Business Quality Attributes zijn niet van toepassing voor deze proof-of-concept.


52

System Quality Attributes Het is de bedoeling dat er een proof-of-concept wordt ontwikkeld. Vermits de tijd beperkt is t.o.v. de gewenste functionaliteit kiezen we als voornaamste Quality Attributes (voortaan QA genoemd) modifiability, testability en usability. Modifiability

We wensen dat wijzigingen zo weinig mogelijk invloed hebben op de rest van de

applicatie, m.a.w. dat wijzigingen snel te implementeren zijn. Ten eerste proberen we de grote delen qua functionaliteit (informatie verzameling, compositie opbouw, deployen, . . . ) zoveel mogelijk van mekaar te scheiden: dit zijn de verschillende modules in de architectuur van figuur 4.1. Ten tweede zijn er ook klasses (en enumeraties) bestaande uit constanten gemaakt voor termen die meermaals voorkomen10 (o.a. URL’s, XML tags). Daarbovenop zijn ook enkele specifieke eigenschappen (zoals projectnamen, instellingen) die meermaals voorkomen gegroepeerd in zogenaamde ‘properties’ klasses. Dit zijn enkele specifieke klasses die bijna uitsluitend bestaan uit attributen met de bijhorende getters/setters. Een concreet voorbeeld is de klasse LogProperties met volgende attributen: nameLogfile (de naam van het logbestand), filePattern (het patroon voor de logging naar een bestand), consolePattern (het patroon voor de logging naar de console), fileAppender (object dat nodig is voor de logging naar een bestand) en consoleAppender (object dat nodig is voor de logging naar de console). Testability

Er wordt steeds gezocht naar mogelijkheden om tijdens het ontwikkelen de mod-

ules (en ook de klasses) zonder veel inspanningen te kunnen testen. Bijvoorbeeld om het BPELdocument (van de compositie) en het WSDL-document (van de nieuwe Web service) in eerste instantie te controleren, is een BPEL-module project gemaakt. De beide documenten kunnen over de bestaande bestanden van het project gekopieerd worden en zo wordt de correctheid gegarandeerd. Een BPEL-module project is echter maar bruikbaar voor een specifieke compositie. Dit testproject kan ook dienen om het deployen van het uiteindelijke ZIP-bestand na te gaan. Het belangrijkste aspect qua testability is de implementatie van een flexibel loggingsysteem (zie ook paragraaf 4.6), nl. LOG4J11 . Usability

Om het geheel gebruiksvriendelijk te maken wordt er een eenvoudig te gebruiken

GUI ontwikkeld, zodat de gebruiker niet via een console zou moeten werken. Het toegepaste 10 11

Sommige klasses en enumeraties zijn rechtstreeks overgenomen uit NetBeans en Eclipse. Zie ook http://logging.apache.org/log4j/1.2/index.html


53

MVC pattern zorgt ervoor dat de GUI mooi afgescheiden is van het model. Ze is zo opgevat dat alleen zaken die hoogst noodzakelijk zijn voor het gebruik van de applicatie getoond worden (meer informatie wordt gegeven in sectie 4.7). Architectural Quality Attributes Gedurende het ontwikkelen van de proof-of-concept is het architectuur ontwerp constant bijgeschaafd. Hieronder komen enkele QA aan bod waar we extra nadruk op gelegd hebben. Conceptual Integrity

Er is steeds de intentie geweest om gelijkaardige problemen op een

analoge manier aan te pakken, bv. de constructie van de drie verschillende JBI-bestanden. Deze documenten bezitten een gelijkaardige structuur. De constructie heeft dit benut door alle documenten systematisch op te bouwen, nl. door steeds een bepaald aantal tags toe te voegen aan het XML-document. Bepaalde delen die in verschillende documenten voorkomen worden steeds in dezelfde volgorde toegevoegd en indien mogelijk door dezelfde methode (voor de verschillende documenten). Ten tweede bevatten alle documenten een jbi-element waarvan enkele attributen gelijk zijn. Dit is bijvoorbeeld het geval voor enkele namespaces. Hiervoor is een specifieke volgorde vastgelegd zodat dit overal gelijk is:

Figuur 4.14: Vaste volgorde voor enkele namespaces van het JBI-element

Correctness Door gebruik te maken van WSDL4J kunnen we verzekeren dat de aangemaakte WSDL syntactisch correct is. WSDL4J is namelijk de referentie implementatie van de JSR 110 specificatie12 . De proof-of-concept heeft eveneens enkele extra validatie controles ingebouwd. Zo wordt het BPEL-document en de JBI descriptor van de nieuwe Web service gevalideerd met hun XML Schema. 12

Zie ook http://jcp.org/en/jsr/detail?id=110

4.6 Ontwerpbeslissingen

4.6

54

Ontwerpbeslissingen

4.6.1

Constanten

Constanten kunnen zeer eenvoudig ge¨ımplementeerd worden als attributen van klasses. Een alternatief is het gebruik van een enumeratie (enum klasse). Dit kan handig zijn indien er specifieke functionaliteit voor de constanten nodig is. Beide alternatieven zijn toegepast.

4.6.2

Aanmaak van een XML-document

Er zijn twee alternatieven. Enerzijds kan een XML-document volledig serieel weggeschreven worden m.b.v. een java.io.Writer. Dit gaat zeer snel maar deze methode heeft als nadeel dat het document serieel moet opgebouwd worden. Anderzijds kunnen bepaalde klasses uit het org.w3c.dom package gebruikt worden (bv. de element klasse). Deze klasses stellen onderdelen van een XML-document voor in Java. Dit biedt meer flexibiliteit en laat m.a.w. een modulaire opbouw van het document toe. Er is voor het laatste alternatief gekozen.

4.6.3

WSDL-documenten aanvullen met onbekende elementen

Voor onze applicatie moeten we WSDL-documenten aanvullen met o.a. partnerLinkType en QoS-parameters. Een WSDL-document is een XML-document en dus kan het org.w3c.dom package gebruikt worden. Een betere (maar complexere) oplossing is echter het WSDL4J uit te breiden met enkele ExtensibilityElement’s. Zo wordt het volledige WSDL-document op een consistente manier aangemaakt.

4.6.4

Logging

In NetBeans wordt standaard de JDK logging API van Sun Microsystems (java.util.logging package) toegepast. Toch kunnen ook andere loggingmechanismen ge¨ımplementeerd worden onder de vorm van libraries, bv. LOG4J. Na een eerste test met de standaard logging bleek deze op enkele aspecten niet doordacht. Daarom zijn we overgeschakeld naar LOG4J. Bijkomende voordelen van dit pakket (t.o.v. de standaard logging) zijn: • het is volwassener (het pakket bestaat reeds lang en geniet de voorkeur van een grote groep); • de wijze waarop de output weggeschreven wordt (m.a.w. het patroon) is eenvoudiger in te stellen;

4.7 GUI

55

• de levels van de loggingoutput zijn logischer (bv. bij de standaard logging zijn finer en finest zinloos); • het is zeer flexibel (bv. aparte instellingen per type output zoals console output of output naar een bestand).

4.7

GUI

De GUI werd ontwikkeld via de NetBeans IDE GUI Builder en maakt gebruik van JSwing. Om de basismogelijkheden ervan te illustreren wordt opnieuw een SOFA Web service (zie paragraaf 3.4) gecreërd maar nu op een volledig automatische manier. Het enige verschil is dat er zes volwaardige Web services ter beschikking zijn als basisblokken (in plaats van vier vroeger: de CoagulationScore en de RenalScore werden in hetzelfde basisblok berekend). Figuur 4.15 toont de GUI. Bij de start zijn enkel de bovenste panelen Web service properties en Algorithm properties zichtbaar. Eerst wordt er een naam ingegeven voor de nieuwe samengestelde Web service. Vervolgens worden de gekende inputs en output ingegeven en wordt het type algoritme gekozen. Het zoeken naar een compositie kan nu gestart worden. Indien er een compositie gevonden wordt (dit is het geval voor de figuur), komt het paneel Runtime properties automatisch tevoorschijn. De nodige inputwaarden om de compositie uit te voeren worden aan de gebruiker gevraagd en na het ingeven van de waarden kan het algoritme uitgevoerd worden. Het resultaat is tevens te zien op de figuur. Het is ook mogelijk om de compositie grafisch weer te geven. Na het aanklikken van de visualisatieknop wordt deze dan in een apart tabblad getoond. De grafische compositie van de SOFA Web service is te zien in figuur 4.16a. Figuur 4.16b toont de visualisatie van een compositie van een andere use case met het QoS-algoritme, namelijk voor de berekening van sepsis (bloedvergiftiging). De inputwaarde is in dit geval een PatientID en de gevraagde output is HasSepsis.

4.7 GUI

56

Figuur 4.15: Resultaat na uitvoeren van het algoritme

4.7 GUI

57

(a) SOFA-score berekening

(b) Sepsis berekening

Figuur 4.16: Visualisatie van automatische composities

PRESTATIETESTEN

58

Hoofdstuk 5

Prestatietesten Figuur 5.1 toont de cyclus die doorlopen wordt bij een uitvoering van de applicatie. De onderste reeks woorden in deze figuur benoemt de tijdsintervallen. Tussen het tweede en het derde interval (nl. het ingeven van de gewenste output parameter en de gegeven input parameters door de gebruiker en de automatische compositie creatie), is er nog een kleine overhead om het correcte algoritme (bv. semi-automatisch, automatisch met of zonder QoS) te starten.

Figuur 5.1: Overzicht van de verschillende tijdsintervallen van een volledige uitvoering We focussen ons specifiek op twee tijdsintervallen, nl.: 1. COMPOSITION ALGORITHM De tijdsduur om automatisch een compositie te creëren. Dit wordt ook de compositietijd of algoritmetijd genoemd. 2. QOS EXECUTION TIME De uitvoeringstijd van de nieuwe Web service. Hier dient opgemerkt te worden dat we niet de echte uitvoeringstijd bepalen maar enkel de som nemen van de afzonderlijke uitvoeringstijden. Deze zijn als constanten onder de vorm van een QoS-parameter in de WSDL opgeslagen. De overhead van het doorsturen van de SOAP-

PRESTATIETESTEN

59

berichten van de ene naar de andere Web service wordt hier niet apart beschouwd, m.a.w. er wordt verondersteld dat deze overhead in de QoS-waarde inbegrepen zit. De beschouwde uitvoeringstijd van de compositie wordt automatisch berekend (zie 5.1.2) net na de compositie creatie. De tijd die bij deze berekening verloren gaat wordt niet opgenomen in de tijdsmetingen omdat deze enkel dient voor testdoeleinden. De prestatietesten kunnen door deze beschouwde uitvoeringstijd sneller uitgevoerd worden omdat er niet moet gewacht worden op de effectieve uitvoering van de compositie. Om enkele bijkomende analyses te kunnen maken worden de overige intervallen, samen met enkele andere waarden, ook opgemeten: • WSDL READING De tijd die nodig is om alle WSDL-documenten in te lezen. • CONSTRUCTION & DEPLOYMENT De tijdsduur om alle projectbestanden – deze resulteren uiteindelijk in één ZIP-bestand – te genereren. Ook het kopiëren van dit ZIPbestand naar de autodeploy folder van GlassFish zit hierin vervat. Er wordt geen rekening gehouden met de tijdsduur die de application server nodig heeft om de compositie op te starten. Deze tijd wordt namelijk voor het grootste deel verborgen door de tijd die de gebruiker nodig heeft om de inputwaarden in te geven. • BPEL GENERATION Dit is een deel van het interval (CONSTRUCTION & DEPLOYMENT) en stelt de tijd voor van de opmaak van het BPEL-document. • VISUALISATION De tijd die nodig is om de compositie te visualiseren. • WSDL DOCUMENTS Het aantal WSDL-documenten dat bij de test ingelezen wordt. • GRAPH NODES Het aantal Web service operaties waaruit de gecreëerde compositie bestaat. • COMPARE OPERATIONS De ontworpen applicatie werkt met een vereenvoudigde semantiek waardoor het vergelijken van inputs en ouputs neerkomt op String-vergelijkingen. Dit aantal wordt opgemeten om te zien hoeveel zogenaamde vergelijkingsopdrachten (kortweg vergelijkingen) uitgevoerd worden en wat het verband is met het interval COMPOSITION ALGORITHM. Daarnaast kan met deze waarde een ander soort analyse gemaakt worden. Indien geweten is hoeveel tijd er nodig is om een semantische matching toe te passen, kan met de gemeten waarde de invloed berekend worden van de implementatie van deze semantische matching.

5.1 Voorbereidingen

60

Om de testen te kunnen uitvoeren zijn een aantal voorbereidingen nodig. Deze worden behandeld in de volgende paragraaf. De specificaties van de testmachine worden gegeven in paragraaf 5.2. Daarna worden de effectieve testen besproken (5.3) en in de laatste paragraaf komen we tot enkele algemene besluiten.

5.1

Voorbereidingen

5.1.1

WSDL-generatie

De input voor de testen zijn steeds een geheel van WSDL-documenten. Om de aanmaak van deze documenten te automatiseren is er een applicatie gemaakt. Er zijn twee mogelijkheden. De applicatie kan een WSDL aanmaken op basis van enkele gegevens: naam van de Web service, naam van de operatie, naam van de input parameters en output parameters. Daarnaast is de applicatie in staat een reeks WSDL’s te genereren waarvan de operaties zodanig passen dat er volledige een graaf (compositie) mee kan geconstrueerd worden. Vooraf kunnen een aantal zaken opgegeven worden zoals de diepte van de graaf, het aantal inputs per operatie en het aantal gelijkaardige WSDL’s (enkel de QoS-waarde verschilt). De creatie van de WSDL-documenten is ge¨ımplementeerd m.b.v. WSDL4J zoals in de proof-ofconcept. Deze creatie is aangevuld zodat er ook een QoS-parameter wordt geplaatst onder het definitions element. De QoS-parameter kan rechtstreeks toegevoegd worden aan de WSDL, maar om de WSDL-creatie consistent te houden is er gekozen om de WSDL4J uit te breiden met een eigen QoS-element (zie verder). In [32] wordt het WSDL-model uitgebreid met een volledige set van QoS-klasses (o.a. TimeToRepair, Network, OperationLatency) tot het Q-WSDL (QoSenabled WSDL) model. Dit model is echter te uitgebreid voor de ene QoS-parameter die nodig is voor de testen. Uitbreiding WSDL4J met eigen element Om een nieuw element toe te voegen aan WSDL4J – dit wordt onderliggend gerealiseerd door WSDL extensibility elements (zie paragraaf 2.1.1) – moeten verschillende klasses geschreven worden. Toegepast op het QoS-element geeft dit volgende klasses: • QosExt Dit is de interface die de methodes bevat die mogelijk zijn voor het eigen element. Deze interface moet overerven van ExtensibilityElement en java.io.Serializable. • QosExtImpl Deze klasse implementeert QosExt

5.1 Voorbereidingen

61

• QosExtSerializer Deze klasse implementeert volgende interfaces: ExtensionSerializer, ExtensionDeserializer en Serializable. Het doel ervan is op te geven hoe het element uit de WSDL moet ingelezen worden (unmarshall methode) en weggeschreven worden (marshall methode). Daarbovenop moet het ExtensionRegistry op de hoogte gebracht worden van dit extra element. Het ExtensionRegistry legt immers verbanden tussen enerzijds de extensibility elements en anderzijds de serializers, deserializers en Java types.

5.1.2

Automatische bepaling van de QOS van een compositie

De uitvoeringstijden worden gemodelleerd m.b.v. een QoS-parameter – een lagere QoS-parameter is dus beter dan een hogere – in de WSDL. Dit maakt het mogelijk om op basis van de WSDLdocumenten via een algoritme automatisch de QoS-waarde van de volledige compositie te berekenen. Het ontworpen algoritme beschouwt op een recursieve wijze alle mogelijke (parallelle) paden van de output naar de inputs. Eigenlijk is één zo’n pad dus een sequentie van Web services. Uiteindelijk wordt het pad met de hoogste QoS-parameter – en dus de langste uitvoeringstijd – behouden. Dit pad zal immers bepalend zijn voor de totale uitvoeringstijd.

5.1.3

Opmeting tijdsintervallen

De intervallen worden berekend als het verschil van het begin- en eindtijdstip. Deze tijdstippen zijn vastgelegd via de System.currentTimeMillis() methode. Er moet wel opgemerkt worden dat deze methode maar nauwkeurig is tot op 15 á 16 ms. Hierdoor worden tijden naar beneden afgerond op de veelvouden hiervan (inclusief 0). Om deze afronding, alsook het onregelmatig optreden van specifieke handelingen (zoals context switches), uit te middelen worden alle testen tien keer uitgevoerd. Om de waarden snel in Excel te kunnen laden, worden deze weggeschreven naar een tekstbestand.

5.1.4

Testen onafhankelijk maken van volgorde inlezen

Omdat de WSDL-documenten steeds sequentieel (volgens alfabetische volgorde) ingelezen worden, passen we de shuffle operatie (uit de Java SDK) toe op de array die de KB voorstelt. Zo is de informatie waarop de automatische compositie creatie zich baseert niet gestructureerd maar willekeurig. Een alternatieve mogelijkheid is het willekeurig inlezen van de WSDL-documenten.

5.2 Specificaties testmachine

5.2

62

Specificaties testmachine

Tabel 5.1 geeft een overzicht van de kenmerken van de gebruikte testmachine. Het besturingssysteem van de testmachine is Windows XP Professional (met SP2 ge¨ınstalleerd). Voor de softwareversies wordt verwezen naar bijlage A. Onderdeel

Type

CPU

Intel Core 2 Duo E6600 (2 * 2,4 GHz) s775 - Boxed

Moederbord

ASUS P5B Intel P965/775 ICH8 PCI-Ex 16 GA

Werkgeheugen

2 * DDR2 1GB PC6400 CL5.0 - Apacer

Harde schijf

Seagate Barracuda 7200.10 - 320 Gb 7200 16Mb SATA2

Beeldkaart

Asus EN7900GS 2DHT - 256 Mb 2DVI - PCI-E

Case + Voeding

Antec Sonata II MidiTower 450W Ultra Quiet - Black Tabel 5.1: Specificaties testmachine

5.3

Testen

Voor elke Web service van de bestudeerde composities bestaan er telkens vijf gelijkaardige kopieën met QoS-waarden van 10 t.e.m. 50. Enkel in 5.3.2 wordt er van deze QoS-waarden afgeweken. Eerst beschouwen we enkele schaalbaarheidstesten. Daarna bekijken we een uitzonderlijk geval en we eindigen met enkele analyses betreffende de hele applicatie. Voor een overzicht van alle resultaten verwijzen we naar bijlage D.

5.3.1

Schaalbaarheid

We delen de schaalbaarheidstesten op in twee categorieën: een categorie waarbij de pool van extra Web services varieert bij een constante compositie en een categorie waarbij de compositie varieert bij een constante pool van extra Web services. Constante compositie, variatie in pool van extra Web services In deze testen houden we de compositie (zie figuur 5.2) constant. We laten het aantal extra Web services, die geen invloed hebben op de compositie, toenemen. De compositie vereist drie inputs. Afhankelijk van het feit dat één of meerdere van deze inputs gegeven is, zal de tijd die nodig is om de compositie te creëren (COMPOSITION ALGORITHM) variëren.

5.3 Testen

63

Figuur 5.2: Compositie 1 voor het testen van de schaalbaarheid De resultaten geven aan dat beide algoritmes een stijgende trend vertonen voor de compositietijd (zie figuur 5.3a). Beide algoritmes blijven perfect schaalbaar (< 25ms) tot 2000 extra Web services. NOQOS presteert beter dan QOSSORT op vlak van compositietijd (zie figuur 5.3b). Daartegenover staat wel dat QOSSORT steeds de beste oplossing vindt qua uitvoeringstijd. Het verschil in deze figuur tussen de uitvoeringstijden van NOQOS en QOSSORT hangt wel af van de keuze van de waarden van de QoS-parameters (in ons geval is dit van 10 t.e.m. 50). Als we het aantal vergelijkingsopdrachten bekijken van de verschillende testen (zie figuur 5.3c), zien we dat QOSSORT er sowieso meer uitvoert dan NOQOS. Het aantal gegeven inputs speelt ook een rol bij het aantal vergelijkingen: hoe meer (nuttige) inputs gegeven, hoe minder vergelijkingen. Zoals te verwachten zien we een lineair verband tussen het aantal vergelijkingsopdrachten en het aantal extra Web services. De vergelijkingsopdrachten maken deel uit van de compositietijd. Het verband ertussen wordt echter niet perfect weerspiegelt. De oorzaak is dat deze vergelijkingen slechts een deel uitmaken van de compositietijd en dat ze ontzettend snel uitgevoerd worden. Indien de matching zou uitgebreid worden tot een semantische versie, dan zou de invloed van de vergelijkingen groter zijn. Het opgeven van inputs die geen nut hebben voor de compositie heeft om dezelfde reden weinig invloed. Het aantal vergelijkingen zal beperkt stijgen (afhankelijk van de grootte van de compositie) zodat de compositietijd nauwelijks be¨ınvloed wordt.

5.3 Testen

64

(a) Compositietijd

(b) Uitvoeringstijd

(c) Vergelijkingsopdrachten

Figuur 5.3: Resultaten van de testen in het geval van een variërende pool

5.3 Testen

65

Variatie in compositie, constante pool van extra Web services De compositie wordt steeds uitgebreid en de pool van extra Web services wordt constant gehouden op 1000. Er wordt een onderscheid gemaakt tussen twee scenario’s: • Scenario A De Web services van de composities bezitten een input (een een-op-een matching). • Scenario B De Web services van de composities bezitten twee inputs (een een-op-meer matching). In scenario A zijn de composities puur sequentieel, m.a.w. de composities zijn telkens een keten van Web services die één op één matchen. Figuur 5.4 toont aan dat het verband tussen de diepte (m.a.w. het aantal opeenvolgende Web services) en de uitvoeringstijd van het algoritme lineair is. Dit is logisch aangezien het algoritme voor ieder extra niveau in de compositie de pool van mogelijke Web services – dit zijn alle beschikbare Web services exclusief deze die reeds gebruikt zijn in de compositie – overloopt tot er een match is. Gemiddeld gezien zullen (in iedere stap) steeds de helft van de Web services onderzocht worden.

Figuur 5.4: Resultaten een-op-een matching: algoritmetijd i.f.v. compositiediepte De situatie van scenario B is geschetst in figuur 5.5. We geven steeds maar één input op, dus de boom wordt niet steeds volledig opgebouwd. Ook hier laten we de diepte van de graaf variëren. Per extra eenheid van de diepte komen er 2diepteniveau ∗ 5 Web services bij1 . 1

De vermenigvuldiging met 5 in de formule geeft het aantal lokale kopieën per Web service weer.

5.3 Testen

66

Figuur 5.5: Compositie 2 voor het testen van de schaalbaarheid Het resultaat van de testen is te zien in figuur 5.6. Als we de grens voor de schaalbaarheid op 0,5 ms leggen voor de compositietijd, dan valt enkel de test van NOQOS voor een diepte van 5 uit de boot (5.6a). We merken dat de compositietijd van NOQOS bij de overgang van diepte 4 naar 5 NOQOS plots zeer snel stijgt. De oorzaak van de betere prestatie van QOSSORT bij een diepte van 5, ligt bij de filtering van gelijkaardige Web service door QOSSORT. Deze filtering zorgt niet alleen voor een beter resultaat qua uitvoeringstijd2 (5.6c), maar vanaf een bepaalde grootte van de compositie zorgt dit zelf voor een snellere compositietijd t.o.v. NOQOS. De tijd die bij de filtering verloren gaat3 wordt bij een bepaalde grootte van de compositie teruggewonnen door de inperking van het aantal mogelijke trajecten (dus ook een inperking van het aantal vergelijkingen (5.6b)). We voeren enkele bijkomende testen uit om het overgangspunt (voor de beschouwde compositie) te vinden tussen NOQOS en QOSSORT. We gebruiken de compositie met diepte 5 en laten het aantal lokale kopieën variëren (5.6d). De grafiek toont duidelijk dat er voor NOQOS een exponentieel verband is tussen de compositietijd en het aantal lokale kopieën. Dit is ook logisch aangezien de boom ook exponentieel groter wordt als het aantal lokale kopieën toeneemt. Het overgangspunt voor de compositietijd blijkt (ongeveer) op het punt te liggen waar het aantal lokale kopieën twee is. Het aantal vergelijkingsopdrachten voor de bijkomende testen worden ook weergegeven in figuur 5.6e 4 . 2

De lineaire stijging met de diepte is te verwachten vermits alle Web services analoge uitvoeringstijden hebben. De volledige lijst met Web services wordt doorzocht naar gelijkaardige Web services. 4 Tussen deze grafiek en degene van de compositietijd is een correlatie van 0,999906675. 3

5.3 Testen

67

(a) Compositietijd

(b) Vergelijkingsopdrachten

(c) Uitvoeringstijd

(d) Compositietijd, diepte 5 en variatie lokale kopieën (e) Vergelijkingsopdrachten, diepte 5 en variatie lokale kopieën

Figuur 5.6: Resultaten een-op-meer matching

5.3 Testen

5.3.2

68

Uitzonderlijk geval

In zeer uitzonderlijke gevallen is het mogelijk dat de uitvoeringstijd van het QoS-algoritme slechter is dan het niet-QOS (NOQOS) algoritme. Zo een geval wordt ge¨ıllustreerd in figuur 5.7. Er zijn twee mogelijke paden van de input naar de output en we hebben zoals steeds vijf gelijkaardige Web services per node. In dit speciaal geval wordt er wel met andere QoS-waarden gewerkt. Twee QoS-algoritmen zullen vergeleken worden: het standaard QoS-algoritme (QOSSORT) en een mogelijke variant (QOSRANDOM) die het probleem zou moeten oplossen (zie paragraaf 4.4.1). Een perfecte oplossing is het toepassen van een globale optimalisatie. Dit zou op zijn beurt dan weer leiden tot veel grotere algoritmetijden.

Figuur 5.7: De compositie voor het testen van het uitzonderlijk geval Figuur 5.8a toont de gemiddelde algoritmetijd voor de drie mogelijke algoritmes. We kunnen besluiten dat er geen significant verschil is tussen de algoritmetijden van de twee QoS-algoritmen. Het NOQOS algoritme is wel duidelijk sneller. De uitvoeringstijden van de gecreëerde composities (door de algoritmes) zijn te zien in figuur 5.8b (deze tijden zijn sterk afhankelijk van de gekozen QoS-waarden). De boxplot toont het minimum, het eerste kwartiel, de mediaan, het gemiddelde, het derde kwartiel en het maximum aan. Op die manier kunnen ook de beste en slechtste prestaties van de verschillende algoritmen gemakkelijk met elkaar vergeleken worden. We zien dat de QoS-algoritmen gemiddeld duidelijk beter presteren dan het NOQOS algoritme. Het QOSSORT algoritme selecteert altijd het slechtste

5.3 Testen

69

(a) Compositietijd

(b) Boxplot van de uitvoeringstijd

Figuur 5.8: Resultaten van het uitzonderlijk geval pad (globaal gezien) omdat de Web services die lokaal de beste oplossing bieden altijd hiertoe leiden. Bij het QOSRANDOM algoritme is er in het opgesteld geval 50 % kans dat het beste pad gekozen wordt. Binnen ieder gekozen pad selecteren de QoS-algoritmes Web services met de laagste uitvoeringstijd en geven daardoor betere uitvoeringstijden dan het NOQOS algoritme. In iets minder dan 25 % van de gevallen presteert het NOQOS algoritme gemiddeld beter dan het QOSSORT algoritme en het minimum van het NOQOS algoritme ligt duidelijk heel wat lager dan het gemiddelde (en ook minimum) van het QOSSORT algoritme. Dit is niet het geval

5.3 Testen

70

met het QOSRANDOM algoritme, waar het gemiddelde lager ligt dan de eerste kwartielgrens van het NOQOS algoritme. Een andere interessante vaststelling is dat de beste prestatie van het QOSSORT algoritme overeenkomt met de slechtste prestatie van het QOSRANDOM algoritme. Het QOSRANDOM algoritme presteert in dit uitzonderlijk geval dus altijd even goed of beter dan het QOSSORT algoritme en gemiddeld ook beter dan het NOQOS algoritme. In algemene gevallen zal het QOSSORT algoritme beter presteren dan het QOSRANDOM algoritme maar deze laatste zal wel nog altijd beter zijn dan het NOQOS algoritme.

5.3.3

Verhouding tijdsintervallen van de complete applicatie

In deze sectie beschouwen we de verhouding van de verschillende tijdsintervallen die samen het volledige traject van de applicatie vormen (met uitzondering van het oproepen van de Web service). Voor elke uitgevoerde test zijn deze verhoudingen berekend en het resultaat (nl. de gemiddelden van al deze berekeningen) is te zien in figuur 5.9.

Figuur 5.9: Overzicht van de verhoudingen van de tijdsintervallen Er zijn twee intervallen die het grootste deel van de totale tijd opnemen (ongeveer 94 %): 1. WSDL READING De tijd die verloren gaat bij het inlezen van de WSDL-documenten kan drastisch ingeperkt worden door de WSDL-documenten eenmalig in te lezen in combinatie met een monitoring die nieuwe of aangepaste WSDL-documenten detecteert.

5.4 Besluit

71

2. CONSTRUCTION & DEPLOYMENT Het aandeel van de BPEL-generatie (BPEL GENERATION) bedraagt 7,73 %. Hier kan slechts een gedeeltelijke optimalisatie gebeuren. Het overkopiëren en het jarren en zippen kan immers niet versneld worden vanuit de applicatie. Bepaalde zaken kunnen parallel uitgevoerd worden (o.a. het aanmaken van de JBI-descriptors). Bijkomend kan nog snelheidswinst geboekt worden door de aan te maken XML-bestanden serieel weg te schrijven.

5.4

Besluit

De testen hebben aangetoond dat de applicatie is z’n geheel goed presteert. Voornamelijk het algoritme om de compositie op te stellen is goed schaalbaar met uitzondering van het geval van zeer grote composities. De doorlooptijd kan door een beperkte ingreep sterk verminderd worden, nl. het vermijden dat de WSDL-documenten meermaals worden ingelezen. Wat het gebruikt van de applicatie betreft, kunnen we stellen dat het ingeven van correcte inputs de compositietijd kan verminderen (tenzij er zeer weinig extra Web services beschikbaar zijn). Het geven van nutteloze inputs heeft een verwaarloosbare invloed.

BESLUIT EN VERDER ONDERZOEK

72

Hoofdstuk 6

Besluit en verder onderzoek 6.1

Besluit

Omdat de ICU een vrij data intensieve omgeving is, worden artsen bij beslissingen ondersteund met medische Web services. De voorgestelde applicatie breidt het bestaande ICSP uit en laat zo de evolutie toe van statische naar automatische orchestratie van Web services. Automatische Web service compositie is een concept dat verder bouwt op SOA, die door een toenemende differentiatie van computersystemen aan belang wint. Een eerste voornaam voordeel is het feit dat men automatisch nieuwe en herbruikbare functionaliteit kan creëren wanneer ze nodig is. Men kan immers vooraf onmogelijk weten welke composities er allemaal nodig zullen zijn. Een tweede belangrijk voordeel is dat er geen ontwikkelaars moeten ingeschakeld worden om composities te creëren. Samen tonen deze voordelen het aanzienlijke potentieel van automatische Web service compositie aan. De gerealiseerde applicatie demonstreert dat een automatische compositie realiseerbaar is met behulp van WS-BPEL. De werking wordt ge¨ıllustreerd via een aantal medische use cases en de applicatie wordt onderworpen aan prestatietesten. Deze tonen de schaalbaarheid van zowel de volledige applicatie als van de algoritmes aan. Daarenboven blijkt dat er door een beperkte ingreep veel tijdswinst kan geboekt worden, nl. door het inlezen van de WSDL-documenten eenmalig uit te voeren. De applicatie is zo opgebouwd dat het talrijke nuttige uitbreidingen toelaat. De belangrijkste worden in volgende paragrafen besproken.

6.2 Uitbreidingen

6.2

73

Uitbreidingen

In deze paragraaf werpen we een blik op de mogelijke uitbreidingen en verbeteringen. Een eerste nuttige uitbreiding is het maken van een Web service front end voor de applicatie. De twee meest uitdagende uitbreidingen zullen ongetwijfeld een volwaardige semantische matching en de overstap naar een dynamische compositie zijn. We eindigen deze paragraaf met enkele kleine (minder belangrijke) uitbreidingen en verbeteringen. Web service front end Omdat de applicatie in staat is automatische composities te genereren en uit te voeren zou het zeer handig zijn om voor de applicatie een Web service front end te bouwen. Op die manier kan de applicatie eigenlijk als Web service in een andere WS-BPEL-compositie aangesproken worden. Bovendien kan zo de applicatie ook onafhankelijk van het platform aangeroepen worden. Dynamische compositie Onder dynamische compositie verstaan we dat er zich wijzigingen kunnen voordoen tijdens het uitvoeren van de compositie. Dit in tegen stelling tot automatische compositie waarbij de vooraf gecreëerde compositie ongewijzigd uitgevoerd wordt en indien er iets misloopt niets ondernomen wordt. Hier wordt meteen de eerste aanleiding gegeven voor een vorm van dynamische compositie, nl. het opvangen van fouten tijdens de uitvoering. Het voornaamste aspect is het niet beschikbaar zijn of het uitvallen van Web services. Er zijn meerdere oplossingen hiervoor: • Er kan gezocht worden naar een gelijkaardige Web service (dus met gelijke inputs en outputs). • Er kan een volledig nieuwe compositie samengesteld worden. • Het deel van de compositie dat reeds uitgevoerd was tot het optreden van de fout, kan behouden worden. Vanaf dit punt wordt er naar een nieuwe compositie gezocht. Dit alternatief is niet bruikbaar indien de absoluut recentste waarden nodig zijn (zoals bij real-time applicaties). In de huidige implementatie wordt de compositie gedeployed door dit bestand te kopiëren naar de autodeploy folder van GlassFish. Na het overkopiëren hebben we geen controle meer over deze applicatie. Daarom zou het beter zijn om dit te vervangen door een systeem die ervoor

6.2 Uitbreidingen

74

zorgt dat de applicatie controleerbaar blijft. Dit is mogelijk door het beheren van de application server via AMX. Op die manier kan bijvoorbeeld het uitvallen van Web services gedetecteerd worden. Een tweede vorm van dynamische compositie is het aanpassen van de uitvoering van de compositie op basis van QoS-parameters van de Web services. Deze QoS-parameters kunnen uiteenlopende eigenschappen voorstellen zoals prijs, uitvoeringstijd, beschikbaarheid, . . . We vermelden kort twee mogelijke scenario’s. Een eerste geval beschouwd de (orthogonale) parameters prijs en uitvoeringstijd. Indien een compositie niet de beoogde tijdsduur haalt kan er gekozen worden voor Web services die sneller maar duurder zijn (en omgekeerd). Een ander scenario kan zijn dat men steeds voor de meest beschikbare Web services kiest zodat er een vorm van load balancing wordt toegepast. Een mogelijkheid om de QoS van een Web service in de praktijk te meten wordt uitgelegd in [33].

Volwaardige semantische matching De ge¨ımplementeerde vorm van semantiek is nuttig voor een proof-of-concept, maar kan bij de evolutie naar een concrete applicatie niet blijven bestaan. In de architectuur-analyse zijn reeds enkele alternatieven aangegeven (zie 4.2.1). Een voordeel bij gebruik van een ontologie gebaseerde semantiek zoals OWL-S, is dat ‘niet perfecte matches’ mogelijk zijn. Hiermee wordt bedoeld dat indien voor de input en output parameters geen match gevonden wordt, er kan gezocht worden naar subklasses van de gewenste parameters. Dit wordt ook aangekaart in [20] waar men spreekt van een ‘exact match’ en een ‘generic match’. De uitbreiding in de architectuur situeert zich in de compositie creatie module. Om generiek verschillende matching technologieën naast elkaar te kunnen gebruiken, wordt de matching van de compositie functionaliteit afgesplitst (zie figuur 6.1). Tijdens de constructie van de compositie wordt de matching module dan geraadpleegd (M). De afsplitsing kan er ook voor zorgen dat de herbruikbaarheid tussen de verschillende algoritmes (semi-automatisch en automatisch) bevorderd wordt. Beide algoritmes passen immers bepaalde vormen van matching toe zoals het vergelijken van inputs en/of outputs. Tijdens de testen zijn het aantal vergelijkingsopdrachten (dit zijn de vergelijkingen van input en output parameters) opgenomen om de invloed van een semantische matching implementatie te kunnen berekenen. Zoals eerder vermeld is dit mogelijk indien er geweten is hoeveel tijd er nodig is om een enkele semantische matching toe te passen.

6.2 Uitbreidingen

75

Figuur 6.1: Uitbreiding architectuur voor (generieke) matching Overige uitbreidingen en verbeteringen Momenteel wordt er voor de inputs en outputs (nl. de parts van de input en de output message) steeds met String types gewerkt. Via castings kunnen deze Strings wel andere types voorstellen. Het zou handig zijn indien er ook andere basistypes (bv. Integers) of zelfs complexe (XML-) types rechtstreeks kunnen gebruikt worden. Er kan een nieuw algoritme ontwikkeld worden waarbij ook Web services met meerdere outputs (onder de vorm van een complex type) ondersteund worden. Indien mogelijk kan dit misschien gerealiseerd worden door het bestaande algoritme voor automatische compositie uit te breiden. Ook op vlak van optimalisatie van algoritmes is er nog veel ruimte voor onderzoek (o.a. enkele niet-ge¨ımplementeerde optimalisaties van sectie 4.4.1). Naast de bestaande BPEL-implementatie kan de applicatie uitgebreid worden met andere compositietalen. Indien er hierbij opnieuw een Web service gecreëerd wordt, kan de uitbreiding gerealiseerd worden door enkel de constructie & de deployment modules aan te vullen. Uiteindelijk kan ook de interne KB vervangen of aangevuld worden door een externe KB zoals een ebXML-implementatie.

GEBRUIKTE SOFTWARE/LIBRARIES

76

Bijlage A

Gebruikte Software/Libraries Er zijn twee OpenESB installaties gebruikt (waarvan de eerste voor de testmachine): 1. openesb-installer-windows-20071230.exe Deze bevat: • NetBeans (Build 20071228165830) • GlassFish (glassfish-v2-ur1-b09d-patch-20071229) 2. openesb-installer-windows-20080214.exe Deze bevat: • NetBeans (Build 200802121221) • GlassFish (glassfish-v2-ur1-b09d-patch-20080214) Tabel A.1 geeft een overzicht van de gebruikte libraries. Java Libraries

doel

versie

JAX-RPC

Verzorgt de communicatie via SOAP-berichten

JWSDP 1.6

JFig

Configuratie

1.5.2

JGraph

Visualistatie van grafen

5.12

JGraphT

Modellering en bewerking van grafen

1.5

LOG4J

Logging voor Java

1.2.15

WSDL4J

Creatie en extractie van WSDL-documenten

2003

Tabel A.1: Gebruikte software

BINDING COMPONENTEN

77

Bijlage B

Binding componenten B.1

File binding component

Voor het aanmaken van een File BC zijn de volgende stappen nodig in NetBeans: 1. Maak een nieuwe WSDL aan in de BPEL-module. 2. Kies, bij ‘Abstract Configuration’, ‘One-Way Operation’ als ‘Operation Type’. 3. Kies, bij ‘Concrete Configuration’, ‘FILE’ als ‘Binding Type’. 4. In het BPEL-proces kan deze File BC gebruikt worden door een ‘invoke’ activiteit. Enkele handige instellingen van de File BC zijn te vinden in de WSDL ervan: • Services/servicenaam/serviceport/file:address Hier kan de locatie van het bestand gekozen worden. • Bindings/bindingnaam/operatienaam/inputbericht/file:message De belangrijkste instellingen zijn : – FileName Definieer de bestandsnaam relatief ten opzichte van de locatie van de map. – ‘MultipleRecordsPerFile’ Indien je de File BC meermaals wenst te gebruiken, bv. logging vanuit verschillende activiteiten, dan moet deze parameter ‘true’ zijn. – ‘addEOL’ Om de verschillende berichten telkens op een nieuwe lijn te beginnen, moet deze parameter ‘true’ zijn.

B.2 SMTP binding component

B.2

78

SMTP binding component

Om een linefeed en carriage return in een e-mail toe te voegen gaan we best als volgt te werk. Maak in het BPEL-proces een variabele aan (bij de gemaakte Web service van paragraaf 3.4 is dit ‘LF’) en geef deze de waarde . Telkens wanneer er een nieuwe regel gewenst is, concateneren we de betreffende String en onze variabele. Controleer de waarde van de variabele in de broncode. Indien deze waarde door NetBeans aangepast is (bv. in &#10 i.p.v. ), verander dan de waarde opnieuw naar de oorspronkelijke waarde.

DYNAMIC PROXY & DYNAMIC DISCOVERY AND INVOCATION

79

Bijlage C

Dynamic Proxy & Dynamic Discovery and Invocation In deze bijlage bespreken we enkele problemen bij het gebruik van Dynamic Proxy & Dynamic Discovery and Invocation en geven we de bijhorende oplossingen. We geven telkens de error die in NetBeans verschijnt bij het compileren.

1) com.sun.xml.internal.messaging.saaj.soap.ver1 1.Message1 1Impl cannot be cast to com.sun.xml.messaging.saaj.soap.MessageImpl Het gebruik van de standaard JAX-RPC library in NetBeans werkt niet. Er zou namelijk een compatibiliteitsprobleem zijn tussen 2 JAR-bestanden van de JAX-RPC en de java JDK 61 . Het probleem wordt opgelost door de twee bestanden (saaj-api.jar & saaj-impl.jar) in de JAX-RPC library te vervangen (de nieuwe JAR-bestanden zijn te vinden op https://saaj.dev.java.net/). Het resultaat van deze operatie, nl. een aantal JAR-bestanden die samen de JAX-RPC library voorstellen, moet dan toegevoegd worden aan de ‘Libraries’ van het project. De twee JARbestanden vervangen in de broncode van zowel NetBeans als OpenESB heeft geen effect.

2) java.rmi.ServerException: javax.jbi.messaging.MessagingException: HTTPBCE00798: Message normalization failed Het probleem kan liggen aan het feit dat een term van het SOAP-bericht niet overeenkomt met de verwachte term, bv. in ons geval lag dit aan de naam van een part die verkeerd was. 1

Zie ook http://www.basis.com/products/bbj/relnotes620.htm

DYNAMIC PROXY & DYNAMIC DISCOVERY AND INVOCATION

80

3) unexpected encoding style: expected=http://schemas.xmlsoap.org/soap/encoding/, actual= . . . We geven eerst de oorspronkelijke code die de fout veroorzaakt en daarna de oplossing2 . Oorzaak String uriEncoding="http://schemas.xmlsoap.org/soap/encoding/"; ... Call call = service.createCall( portQNname ); call.setProperty( Call.ENCODINGSTYLE_URI_PROPERTY, uriEncoding )

Oplossing Call call = service.createCall( portQNname ); call.setProperty( Call.ENCODINGSTYLE_URI_PROPERTY, "" );

2

Zie ook http://forum.java.sun.com/thread.jspa?threadID=343638&messageID=1843474

TESTRESULTATEN

81

Bijlage D

Testresultaten In deze bijlage worden alle testresultaten gepubliceerd. Zoals eerder vermeld zijn alle waarden in deze tabellen reeds gemiddelden van 10 metingen. Om de tabellen beter te kunnen presenteren zijn volgende afkortingen gehanteerd: WR

WSDL READING

CA

COMPOSITION ALGORITHM

C&D

CONSTRUCTION & DEPLOYMENT

BG

BPEL GENERATION

V

VISUALISATION

QET

QOS EXECUTION TIME

WD

WSDL DOCUMENTS

GN

GRAPH NODES

CO

COMPARE OPERATIONS

EWS

EXTRA WEB SERVICES (POOL OF EXTRA WSDL DOCUMENTS)

D

DEPTH

GI

GIVEN INPUTS

LC

LOCAL COPIES (PER WEB SERVICE)

D.1 Schaalbaarheidstesten

D.1

82

Schaalbaarheidstesten WR

CA

C&D

BG

V

QET

WD

GN

CO

EWS

GI

(ms)

(ms)

(ms)

(ms)

(ms)

(ms)

(#)

(#)

(#)

(#)

(#)

NOQOS

173,4

4,8

1618,7

134,6

200,0

100

25

6

69,4

0

1

NOQOS

175,0

9,2

1454,7

126,6

206,3

95

25

7

55,9

0

2

NOQOS

178,3

9,4

1553,1

148,3

201,5

103

25

9

41,3

0

3

QOSSORT

171,9

15,5

1892,3

132,8

195,3

30

25

6

260,3

0

1

QOSSORT

171,9

15,4

1661,2

134,6

221,7

30

25

7

246,0

0

2

QOSSORT

178,8

10,2

2069,4

149,2

200,0

30

25

9

225,7

0

3

NOQOS

435,8

7,9

1481,3

151,7

207,8

98

100

6

278,0

75

1

NOQOS

392,4

7,9

1939,1

140,5

198,4

85

100

7

189,8

75

2

NOQOS

392,1

9,5

1732,9

156,2

201,4

97

100

9

103,5

75

3

QOSSORT

453,0

15,7

1665,6

156,2

214,1

30

100

6

782,4

75

1

QOSSORT

390,8

12,6

1557,8

157,9

196,8

30

100

7

694,1

75

2

QOSSORT

393,7

14,1

1807,7

150,0

218,9

30

100

9

614,2

75

3

NOQOS

679,8

11,1

2046,8

140,7

218,7

95

200

6

563,4

175

1

NOQOS

690,7

8,0

2274,8

139,1

195,3

95

200

7

376,2

175

2

NOQOS

678,3

7,8

1673,4

154,6

201,5

98

200

9

188,9

175

3

QOSSORT

684,5

12,7

1551,5

141,0

201,5

30

200

6

1484,9

175

1

QOSSORT

676,7

15,7

2204,6

139,0

195,5

30

200

7

1297,1

175

2

QOSSORT

678,1

15,6

1942,3

156,5

203,0

30

200

9

1109,7

175

3

NOQOS

2087,5

12,4

1782,8

134,4

195,3

93

500

6

1453,5

475

1

NOQOS

2100,2

7,7

1993,9

129,8

203,1

98

500

7

872,7

475

2

NOQOS

2085,9

10,8

1611,0

162,6

201,7

97

500

9

390,6

475

3

QOSSORT

2095,3

15,9

2326,5

134,3

201,7

30

500

6

3585,1

475

1

QOSSORT

2084,3

17,0

1737,7

136,0

201,6

30

500

7

3094,1

475

2

QOSSORT

2098,3

15,6

1733,0

161,0

201,4

30

500

9

2607,0

475

3

Het vervolg van de tabel bevindt zich op de volgende bladzijde

D.1 Schaalbaarheidstesten

83

Vervolg tabel WR

CA

C&D

BG

V

QET

WD

GN

CO

EWS

GI

(ms)

(ms)

(ms)

(ms)

(ms)

(ms)

(#)

(#)

(#)

(#)

(#)

NOQOS

6190,7

12,6

1956,2

140,7

204,6

87

1000

6

2832,7

975

1

NOQOS

6246,8

9,4

1464,1

150,1

201,5

90

1000

7

1746,9

975

2

NOQOS

6248,4

11,1

1514,0

167,2

198,4

102

1000

9

828,6

975

3

QOSSORT

6229,9

17,0

1468,9

159,4

196,8

30

1000

6

7083,7

975

1

QOSSORT

6226,7

23,5

1726,6

121,9

199,8

30

1000

7

6096,0

975

2

QOSSORT

6249,9

19,8

1521,4

169,8

195,3

30

1000

9

5116,8

975

3

NOQOS

23929,7

17,4

1653,0

118,6

195,3

97

2000

6

5842,7

1975

1

NOQOS

23943,7

15,5

1503,1

126,5

200,0

100

2000

7

3807,2

1975

2

NOQOS

23509,5

14,1

1479,5

136,1

200,1

90

2000

9

1786,9

1975

3

QOSSORT

23917,2

24,9

1540,7

121,8

198,5

30

2000

6

14085,3

1975

1

QOSSORT

23950,0

23,5

1735,9

128,1

200,0

30

2000

7

12094,0

1975

2

QOSSORT

23943,8

23,2

2082,9

139,1

196,8

30

2000

9

10116,8

1975

3

Tabel D.1: Resultaten van de testen in het geval van een variërende pool van extra Web services WR

CA

C&D

BG

V

QET

WD

GN

CO

EWS

D

(ms)

(ms)

(ms)

(ms)

(ms)

(ms)

(#)

(#)

(#)

(#)

(#)

NOQOS

6107,7

12,5

1604,6

52,9

198,6

28

1000

3

1136,3

1000

1

QOSSORT

6087,5

10,8

1571,9

64,2

189,3

10

1000

3

2028,2

1000

1

NOQOS

6220,2

9,4

1379,7

95,4

196,9

58

1010

4

3428,2

1000

2

QOSSORT

6204,6

17,3

1407,7

100,2

197,0

20

1010

4

6140,0

1000

2

NOQOS

6770,2

118,9

1524,8

98,6

234,4

101

1030

5

126553,9

1000

3

QOSSORT

6751,6

39,0

1468,7

101,6

201,6

28

1030

5

23240,0

1000

3

NOQOS

7217,0

121,9

1532,9

118,6

197,0

123

1070

6

131820,3

1000

4

QOSSORT

7209,4

75,1

1567,3

121,9

200,0

51

1070

6

62025,5

1000

4

NOQOS

8254,6

8998,4

1493,9

151,3

196,8

152

1150

7

14046196,8

1000

5

QOSSORT

8195,2

410,8

1517,3

151,5

198,2

50

1150

7

513898,6

1000

5

Tabel D.2: Resultaten van de testen in het geval een-op-meer

D.2 Uitzonderlijk geval

84

WR

CA

C&D

BG

V

QET

WD

GN

CO

EWS

D

(ms)

(ms)

(ms)

(ms)

(ms)

(ms)

(#)

(#)

(#)

(#)

(#)

NOQOS

5986,1

3,1

1587,7

50,1

198,5

33

1005

3

180,1

1000

1

QOSSORT

6090,7

12,4

1414,2

51,6

195,1

10

1005

3

1011,8

1000

1

NOQOS

6111,0

7,8

1433,0

65,4

206,1

66

1010

4

210,3

1000

2

QOSSORT

6139,1

12,5

1529,6

69,0

201,8

20

1010

4

2034,8

1000

2

NOQOS

6139,2

9,4

1350,2

82,7

203,0

95

1015

5

454,1

1000

3

QOSSORT

6182,8

15,5

3604,8

78,1

198,4

30

1015

5

3065,5

1000

3

NOQOS

6262,4

11,0

1636,0

106,3

223,2

126

1020

6

893,7

1000

4

QOSSORT

6287,4

15,9

2626,5

122,0

196,8

40

1020

6

4104,2

1000

4

NOQOS

6663,7

9,4

2390,6

106,3

195,2

156

1025

7

969,8

1000

5

QOSSORT

6651,5

15,7

1732,8

107,5

198,3

50

1025

7

5150,1

1000

5

NOQOS

6943,8

12,6

1676,4

215,5

203,2

286

1050

12

1572,9

1000

10

QOSSORT

6971,8

36,0

1712,4

214,1

199,8

100

1050

12

10528,9

1000

10

NOQOS

7498,3

28,2

2154,7

398,6

239,3

590

1100

22

3763,6

1000

20

QOSSORT

7479,5

60,8

1972,0

386,0

234,4

200

1100

22

21960,3

1000

20

Tabel D.3: Resultaten van de testen in het geval een-op-een WR

CA

C&D

BG

V

QET

WD

GN

CO

EWS

LC

(ms)

(ms)

(ms)

(ms)

(ms)

(ms)

(#)

(#)

(#)

(#)

(#)

NOQOS

7948,3

3926,7

11781,1

163,9

206,5

136

1119

7

5928689,1

1000

4

NOQOS

7575,0

1393,9

1659,3

170,7

200,1

112

1088

7

2011421,2

1000

3

NOQOS

7070,2

359,6

2345,1

170,5

215,7

74

1057

7

475304,1

1000

2

NOQOS

6797,1

64,2

1584,2

159,6

193,6

50

1026

7

60449,1

1000

1

Tabel D.4: Resultaten van de testen in het geval een-op-meer bij constante diepte van 5

D.2

Uitzonderlijk geval

D.2 Uitzonderlijk geval

85

WR

CA

C&D

BG

V

QET

WD

GN

CO

EWS

(ms)

(ms)

(ms)

(ms)

(ms)

(#)

(#)

(#)

(#)

(#)

NOQOS

159,3

8,0

1403,0

87,6

192,2

337

25

5

10,5

0

QOSSORT

160,9

12,4

1861,2

84,2

188,9

220

25

5

109,8

0

QOSRANDOM

159,4

12,6

1898,4

86,0

189,0

122

25

5

108,7

0

Tabel D.5: Resultaten van de testen van het speciaal geval

INSTALLATIEPROCEDURE

86

Bijlage E

Installatieprocedure 1. Installatie applicatie: Plaats volgende zaken in eenzelfde map: • Matcher.jar (applicatie) • \lib (directory die de gebruikte JAR’s bevat) • ApplicationConfigurationsYF.xml (configuratiebestand) De applicatie kan gestart worden door te dubbel klikken op Matcher.jar 2. Configuratie: Instellingen bevinden zich in het bestand ApplicationConfigurationsYF.xml. De applicatie verwacht standaard dat de map: C:\test\ aanwezig is. Deze map kan gewijzigd worden.

BIBLIOGRAFIE

87

Bibliografie [1] A.H. Morris, R.M. Gardner, “Principles of Critical Care”, chapter on Computer applications, in J. Hall, G. Schmidt, L. Wood (eds), Mc Graw-Hill, New York (1992), 500-514 [2] Jeffrey

C.

Schlimmer,

W3C,

Web

Services

Description

Requirements,

http://www.w3.org/TR/ws-desc-reqs/, Oktober 2002, last visited May 2008 [3] Diane Jordan, John Evdemon et al, “Web Services Business Process Execution Language Version 2.0”, April 2007, 1-264 [4] B. Dhoedt, F. D. Turck, “Design of Distributed Software”, lecture notes: chapter Webservices, 2007, 14-15 [5] Shivanand Kini,

Understanding WSDL and How the WSDL Editor in Net-

Beans Enterprise Pack Simplifies WSDL Development,

Sun Developers Network,

http://developers.sun.com/jsenterprise/nb enterprise pack/reference/techart/understandingwsdl.html, Oktober 2006, last visited May 2008 [6] N. Milanovic, M. Malek, “Current Solutions for Web Service Composition”, Humboldt University, Berlin, IEEE INTERNET COMPUTING, december 2004, 51-59 [7] F. Curbera, R. Khalaf, N. Mukhi, S. Tai, S. Weerawarana, “The next step in Web services”, Communications Of The ACM, Volume 46, Number 10, October 2003, 29-34 [8] J.M. van Ginkel, “Service compositie met BPEL4WS”, Universiteit Twente, 2004, 3-18 [9] David Martin et al,

W3C, OWL-S: Semantic Markup for Web Services,

http://www.w3.org/Submission/OWL-S/, Oktober 2002, last visited May 2008 [10] Jeff Heflin,

W3C, OWL Web Ontology Language,

req/#onto-def, February 2004, last visited May 2008

http://www.w3.org/TR/webont-

BIBLIOGRAFIE

[11] Windows

88

Workflow

Foundation

(WF),

http://msdn.microsoft.com/en-

us/netframework/aa663328.aspx, 2007, last visited May 2008 [12] B. De Smet, “Dynamic and generic workflows in .NET”, Universiteit Gent, Faculteit Ingenieurswetenschappen, 2007 [13] The ActiveBPEL Community Edition Engine,

http://www.activevos.com/community-

open-source.php, 2008, last visited May 2008 [14] Erik Christensen, Francisco Curbera, Greg Meredith, Sanjiva Weerawarana, Web Services Description Language (WSDL) 1.1, http://www.w3.org/TR/wsdl, March 2001, last visited May 2008 [15] Enabling A Global Electronic Market, http://www.ebxml.org, 2006, last visited May 2008 [16] Open ESB, The Open Enterprise Service Bus, https://open-esb.dev.java.net, last visited May 2008 [17] A. C. Kajdacsy-Balla Amaral, F. M. Andrade, R. Moreno, A. Artigas, F. Cantraine, J. Vincent, “Use of the Sequential Organ Failure Assessment score as a severity score”, Intensive Care Med 31, Volume 31, Number 2, February 2005, 243-249 [18] BPEL for Java technology, http://www.ibm.com/developerworks/library/specification/wsbpelj, March 2004, last visited May 2008 [19] R. Zhang, I. Budak Arpinar, B. Aleman-Meza, “Automatic Composition of Semantic Web Services”,Intl. Conf. on Web Services Las Vegas NV, University of Georgia Athens, 2003, 1-4 [20] E. Sirin, J. Hendler, B. Parsia, “Semi-automatic Composition of Web Services using Semantic Descriptions”, Modeling, Architecture and Infrastructure (WSMAI-2003), University of Maryland, Computer Science Department, April 2003, 1-9 [21] S. Thakkar, C. A. Knoblock, J. Luis Ambite, “A View Integration Approach to Dynamic Composition of Web Services”, The 13th International Conference on Automated Planning & Scheduling (ICAPS 2003), Trento, Italy, University of Southern California, 2003, 1-7 [22] J. Rao, X. Su, S. Thakkar, “A Survey of Automated Web Service Composition Methods”, Norwegian University of Science and Technology, Department of Computer and Information Science, 2004, 1-12

BIBLIOGRAFIE

[23] Peter

Brittenham,

89

Understanding

WSDL

http://www.ibm.com/developerworks/library/ws-wsdl3,

in

a

UDDI

November 2001,

registry, last visited

May 2008 [24] GlassFish Project - AMX, https://glassfish.dev.java.net/nonav/javaee5/amx, 2006, last visited May 2008 [25] S. Bleul, T. Weise, K. Geihs, “Large-Scale Service Composition in Semantic Service Discovery”, University of Kassel, Germany, 2006, 1-3 [26] L. Li, M. Jun, C. ZhuMin, S. Ling, “An Efficient Algorithm for Web Services Composition with a Chain Data Structure”,Proceedings of the 2006 IEEE Asia-Pacific Conference on Services Computing, December 2006, 64-69 [27] E. Silva, L. Ferreira Pires, M. van Sinderen, “An Algorithm for Automatic Service Composition”,1st International Workshop on Architectures, Concepts and Technologies for Service Oriented Computing, ICSOFT 2007, July 2007, 65-74 [28] S. Huang, X. Wang, A. Zhou, “Efficient Web Service Composition Based on Syntactical Matching”, IEEE Computer Society, 2005, 782-783 [29] JGraphT, http://jgrapht.sourceforge.net, 2008, last visited May 2008 [30] Java Graph Visualization and Layout, http://www.jgraph.com, 2007, last visited May 2008 [31] L. Bass, P. Clements, R. Kazman, “Software Architecture in Practice”, Addison-Wesley, chapter 4, 2003 [32] A. DAmbrogio, “A Model-driven WSDL Extension for Describing the QoS ofWeb Services”, University of Roma TorVergata, Department of Computer Science Systems and Production, IEEE International Conference on Web Services (ICWS’06), 2006, 789-796 [33] Understanding quality of service for Web services, http://www.ibm.com/developerworks/library/ ws-quality.html, January 2002, last visited May 2008

LIJST VAN FIGUREN

90

Lijst van figuren 2.1

Voorstelling van Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2

Service oriented architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.3

Voorbeeld van Web service compositie . . . . . . . . . . . . . . . . . . . . . . . .

7

2.4

Top level van de service ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.5

Mapping tussen OWL-S en WSDL . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.1

Voorbeeld van een flowchart van Web service compositie . . . . . . . . . . . . . .

17

3.2

Het ICSP platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.3

De verschillende Web services en hun interactie . . . . . . . . . . . . . . . . . . .

22

3.4

Sequentiediagram van de SofaScoreService . . . . . . . . . . . . . . . . . . . . . .

23

4.1

Architectuur voor semi-automatische compositie . . . . . . . . . . . . . . . . . .

28

4.2

Voorbeeld van een mogelijk BPEL-document voor een sequentiële compositie . .

32

4.3

Opmaak van het basis BPEL-document . . . . . . . . . . . . . . . . . . . . . . .

32

4.4

Architectuur voor volledig automatische compositie . . . . . . . . . . . . . . . . .

36

4.5

Mapping van de componenten van het reference model op software componenten (packages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

4.6

Hiërarchie van de taken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

4.7

Configuratie bestand van de proof-of-concept . . . . . . . . . . . . . . . . . . . .

40

4.8

Algoritme voor automatische compositie . . . . . . . . . . . . . . . . . . . . . . .

43

4.9

Deel A van het algoritme voor automatische compositie . . . . . . . . . . . . . .

44

4.10 Begin van het algoritme voor automatische compositie met QoS . . . . . . . . . .

46

4.11 Principe van de inputs die gevraagd worden aan de gebruiker . . . . . . . . . . .

47

4.12 Voorbeeld van een mogelijke BPEL-sequentie die flow’s bevat . . . . . . . . . . .

48

4.13 Algoritme voor BPEL-generatie . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

LIJST VAN FIGUREN

91

4.14 Vaste volgorde voor enkele namespaces van het JBI-element . . . . . . . . . . . .

53

4.15 Resultaat na uitvoeren van het algoritme . . . . . . . . . . . . . . . . . . . . . .

56

4.16 Visualisatie van automatische composities . . . . . . . . . . . . . . . . . . . . . .

57

5.1

Overzicht van de verschillende tijdsintervallen van een volledige uitvoering . . . .

58

5.2

Compositie 1 voor het testen van de schaalbaarheid . . . . . . . . . . . . . . . . .

63

5.3

Resultaten van de testen in het geval van een variërende pool . . . . . . . . . . .

64

5.4

Resultaten een-op-een matching: algoritmetijd i.f.v. compositiediepte . . . . . . .

65

5.5

Compositie 2 voor het testen van de schaalbaarheid . . . . . . . . . . . . . . . . .

66

5.6

Resultaten een-op-meer matching . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

5.7

De compositie voor het testen van het uitzonderlijk geval . . . . . . . . . . . . .

68

5.8

Resultaten van het uitzonderlijk geval . . . . . . . . . . . . . . . . . . . . . . . .

69

5.9

Overzicht van de verhoudingen van de tijdsintervallen . . . . . . . . . . . . . . .

70

6.1

Uitbreiding architectuur voor (generieke) matching . . . . . . . . . . . . . . . . .

75

Automatische compositie van medische Web services in WS-BPEL

Recommend Documents