Een servicegeoriënteerde architectuur voor Customer Relationship Management Strategieën voor verbeterde schaalbaarheid en flexibiliteit

Een servicegeoriënteerde architectuur voor Customer Relationship Management Strategieën voor verbeterde schaalbaarheid en flexibiliteit

Student: Student nr: Opleiding:

Wolfgang Al 9801448 Informatica

Datum:

20 augustus 2004

Een servicegeoriënteerde architectuur voor Customer Relationship Management

I N L E I D I N G

Voorwoord Dit verslag is het resultaat van mijn afstudeerstage in het kader van mijn opleiding Informatica aan de Universiteit Twente. Deze afstudeeropdracht heeft plaatsgevonden van 17 februari tot 1 september 2003 bij Windex Software BV te Meerssen. Graag zou ik hier Aart van Halteren willen bedanken voor zijn constructieve en waardevolle commentaar, hints en tips die hij mij gaf in zijn rol als afstudeerbegeleider. Ook wil ik Frank Adriaenssen van Windex Software BV bedanken voor het bieden van een afstudeerplaats. Mark Schmeits, ook van Windex Software BV, wil ik graag bedanken. Hij wist op de juiste momenten vragen te stellen waardoor ik mijn werk kon verbeteren en was zo een goede sparringpartner. Tenslotte zou ik graag Mirièl Troeman willen bedanken, steun en toeverlaat in de donkere tijden wanneer ik het niet meer zag zitten. Haar nuchtere kijk op de zaken is een onmisbaar goed geweest. Meerssen, 20 augustus 2004 Wolfgang Ingmar Al

ii

Inleiding: Samenvatting

I N L E I D I N G

Samenvatting De veranderde eisen aan de ICT vergen een nieuwe manier van omgaan met de ontwikkeling van software. Het inwilligen van eisen van stakeholders is een kritieke succes factor geworden van softwareprojecten. Daarnaast zijn softwaresystemen steeds groter en complexer geworden, waardoor software ontwikkelaars geen overzicht meer hebben. Software architectuur is een nieuw abstractieniveau dat de software architect in staat stelt stakeholder-eisen expliciet te documenteren in de systeemdefinitie en een abstract overzicht van het systeem te creëren. Hierdoor blijft het overzicht bestaan en is het reeds vroeg mogelijk systeemanalyses uit te voeren. Daarnaast garandeert het expliciet maken van de stakeholder-eisen dat het uiteindelijke systeem hieraan voldoet. In deze opdracht is software architectuur gebruikt als hoogste redenatieniveau van systemen, om te komen tot een antwoord op het centrale probleem: “Hoe kan het .NET platform binnen Windex Software BV ingezet worden om te komen tot een schaalbaar en flexibel, Internet-enabled framework voor de volgende generatie van de Windex Customer Relationship Management software?”. Specifiek is de Service Oriented Architecture, met het centrale begrip service als een eenheid van informatie, gedrag en verwerking, bestudeerd. De Service Oriented Architecture heeft aan de wieg gestaan van XML Web Services en het .NET platform. XML Web Services bieden een universele, open, en gestandaardiseerde omgeving voor services en de integratie van services. Er zijn twee belangrijke ondersteunende architecturen: de Web Services Conceptual Architecture van IBM en de Global XML Web Service Architecture van Microsoft. Deze laatste vormt de basis voor .NET. In deze opdracht is een architectuur opgesteld ter ondersteuning van het framework voor de volgende generatie Customer Relationship Management software van Windex Software BV. Deze architectuur tracht de mogelijkheden voor het verbeteren van schaalbaarheid en flexibiliteit te maximaliseren. Om dit te testen, is een tweetal prototypes gemaakt. Op deze prototypes is een aantal tests en metingen uitgevoerd om tot uitspraken ten aanzien van de schaalbaarheid en de flexibiliteit te komen. Hieruit is gebleken dat hoewel de doelstellingen ten aanzien van flexibiliteit zeker haalbaar zijn, er meer onderzoek nodig is voordat concrete uitspraken gedaan kunnen worden ten aanzien van de schaalbaarheid. Met name de invloed van de .NET Common Language Runtime en Windows op zaken als het geheugengebruik zijn nog onvoldoende duidelijk.

iii


I N L E I D I N G

Inhoudsopgave Inleiding

1

Probleemdefinitie en aanpak

3

1 1.1 1.2 2 Stand van de technologie 1

Probleemdefinitie ............................................................. 3 Doel 3 Onderzoeksvragen 3 Aanpak ............................................................................. 4 6

5.1 5.2 5.3

Software architecturen ..................................................... 6 Vooraf: andere vormen van architectuur 6 Inleiding tot software architectuur 7 Context en motivatie 8 Model 9 Voordelen 10 Gegarandeerde basis 10 Analyse 10 Hergebruik 11 Tiers ............................................................................... 11 2-tier architecturen 11 3-tier architecturen 11 Meer tiers 13 Kwaliteit van software architecturen .............................. 13 Service Oriented Architecture........................................ 14 Services en architectuur 14 Interfaces 14 Karakteristieken van services 15 Gedrag 15 Servicegeoriënteerd ontwerpen 16 Voor- en nadelen 17 XML Web Services ........................................................ 18 Het ontstaan van XML Web Services 18 Dynamische e-business 19 Architecturen voor XML Web Services 19

Opdrachtkader

21

1.1 1.2 1.3 1.4 1.5 1.5.1 1.5.2 1.5.3 2 2.1 2.2 2.3 3 4 4.1 4.2 4.3 4.4 4.5 4.6 5

1 2 2.1 2.2 2.3 2.4 3 4 4.1

iv

Het .NET framework ...................................................... 21 Richtlijnen vanuit .NET................................................... 22 Algemene richtlijnen 22 Services, componenten en tiers 23 Business tiers 24 Service interfaces 24 Flexibiliteit ...................................................................... 25 Schaalbaarheid .............................................................. 26 Richtlijnen 26

Inleiding: Inhoudsopgave

5 6 7 7.1 7.2 7.3 7.4 8

Beveiliging ......................................................................27 Betrouwbaarheid.............................................................29 Ontwerpkeuzes...............................................................30 Scheiding van de lagen 30 Communicatie tussen lagen 31 Abstracties 32 Berichtenuitwisseling 32 Conclusie ........................................................................33

Architectuur 1 2 3 3.1 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.3 4 4.1 4.2 4.3 4.4 5

34 Uitdagingen.....................................................................34 Uitgangspunten...............................................................35 Referentie-architectuur ...................................................36 Tiers 36 Hoofdfuncties 36 Data tier 36 Platform tier 37 Business logic tier 37 Presentation tier 38 Rollen en actoren 38 Verfijning.........................................................................40 Data tier 40 Platform tier 41 Business Logic tier 43 Presentatie tier 44 Conclusie ........................................................................44

Prototype

45 e

1 1.1 1.2 1.3 1.4 2 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.2 2.2.1 2.2.2 2.2.3 3

1 Prototype ....................................................................45 Reflection.Emit 45 Information Object Factory 45 TestSuite 47 Vervolg 48 2e Prototype ....................................................................48 Specificatie 49 Data tier 49 Platform tier 52 Business Logic 54 Presentatie 58 Beperkingen 58 Data tier beperkingen 58 Platform tier beperkingen 59 Business Logic tier beperkingen 59 Conclusie ........................................................................59

Tests en metingen aan het prototype 1 1.1 1.2 1.3 2 2.1 2.2 3

61

Aandachtspunten............................................................61 Schaalbaarheid 61 Flexibiliteit 62 Overzicht aandachtspunten 63 Doelstellingen .................................................................64 Schaalbaarheid 65 Flexibiliteit 66 Wenselijke eigenschappen.............................................66

v


3.1 3.1.1 3.1.2 3.2 4 4.1 4.1.1 4.1.2 4.2 5 5.1 5.2 5.3 6 Conclusies en aanbevelingen 1 2 3 4 5 6 7

Schaalbaarheid 66 Scale-up en scale-out uitgelegd 67 Wensen ten aanzien van WindexVIJF 67 Flexibiliteit 67 Metingen en tests........................................................... 68 Schaalbaarheid 68 Memory Adapter 69 File System Adapter 70 Flexibiliteit 70 Technieken .................................................................... 72 Schaalbaarheid 72 Flexibiliteit 73 Schaalbaarheid en flexibiliteit combineren 74 Conclusies en aanbevelingen........................................ 75 77 Archituur, abstractie en architect ................................... 77 Services ......................................................................... 78 Strategieën..................................................................... 78 Voorstel architectuur ...................................................... 79 Prototypes...................................................................... 79 Metingen en tests........................................................... 80 Afsluiting ........................................................................ 80

Reflectie

82

Literatuur

85

Gerelateerde literatuur

88

Afkortingen

89

Begrippenlijst

91

Appendices

I

Opdracht

I

Meetresultaten Memory Adapter

II

1 2 3 4 5 6 Meetresultaten File System Adapter 1 2 3

vi

Working Set ..................................................................... II Geheugen ........................................................................ II Delta Working Set ............................................................ II Delta Geheugen.............................................................. III Processortijd ................................................................... III Delta Processortijd.......................................................... III IV Working Set ....................................................................IV Geheugen .......................................................................IV Delta Working Set ...........................................................IV

Inleiding: Inhoudsopgave

4 5 6

Delta Geheugen............................................................... V Processortijd .................................................................... V Delta Processortijd........................................................... V

Data Interface Quality-of-Service aware Broker 1 1.1 1.2 1.3 1.4 2 3 4

VI VIII De Broker Architectural Framework ............................. VIII Beschrijving VIII Structuur VIII Voor- en nadelen IX Varianten X Brokering for quality........................................................ XI Uitdagingen voor de QoS aware Broker......................... XI De QoS aware Broker en schaalbaarheid en flexibiliteitXII

vii

Hoofdstuk 1: Inleiding

H O O F D S T U K

1

Inleiding VERLEDEN

Pas in de jaren ’80 begonnen bedrijven hun bedrijfsprocessen op grote schaal te automatiseren. De eerste stappen waren voorzichtige verkenningen van het nieuwe terrein van de ICT (Informatie- & CommunicatieTechnologie). Slechts weinigen gebruikten ooit een computer voor hun werkzaamheden. Deden ze dit wel, dan werkten ze of voor de ICT-afdeling, of ze deden hun werk daar.

NU

Tegenwoordig zijn computers en automatisering niet meer weg te denken uit de dagelijkse werkzaamheden; veel is geautomatiseerd of op zijn minst gekoppeld aan een computer en veel mensen vertrouwen op de ICT faciliteiten voor hun werkzaamheden. Als de ICT faciliteiten niet beschikbaar zijn, of niet goed functioneren, heeft dit een grote negatieve impact op de productiviteit.

NIEUWE EISEN

Het veranderde gebruik van ICT heeft ervoor gezorgd dat andere eisen gesteld worden aan de ICT. Gebruikers verwachten flexibiliteit; ze willen de ICT faciliteiten zo kunnen inrichten, dat hun productiviteit gemaximaliseerd wordt. Daarnaast verwachten ze betrouwbaarheid: de ICT faciliteiten moeten voldoende beschikbaar zijn en er mogen geen storende fouten optreden. Een andere eis is schaalbaarheid: onder toenemende belasting moeten de ICT faciliteiten hetzelfde niveau van service blijven bieden. Beveiliging is ook een nieuwe eis: ICT faciliteiten moeten beschermd worden tegen oneigenlijk gebruik, tegen ongeautoriseerd gebruik en tegen andere vormen van misbruik. Ook moeten ze beschermd worden tegen pogingen om het systeem in een inconsistente toestand te brengen, of de dienstverlening onmogelijk te maken. Tenslotte moeten nieuwe ICT faciliteiten in grote mate beheersbaar zijn; ICT faciliteiten moeten beschikken over uitgebreide mogelijkheden voor sturing en beheer.

WINDEX SOFTWARE BV

Windex Software BV te Meerssen is een Independent Software Vendor (ISV) van Customer Relationship Management (CRM) software voor brancheorganisaties. De huidige versie van het CRMpakket, versie 4, is aan vervanging toe omdat het niet langer mogelijk is versie 4 aan te passen aan de wensen van de klant. Windex Software BV wil een volledig nieuwe basis voor haar CRM pakket ontwikkelen om wijzigingen nu en in de toekomst te ondersteunen, om gebruik te kunnen maken van nieuwe technologieën zoals XML Web Services (XML = eXtensible Markup Language) en het Internet en om weer een aantal jaar vooruit te kunnen.

CONTEXT

Het Internet groeit nog altijd en wordt steeds meer alomtegenwoordig. Internettoegang is goedkoop en vrijwel overal beschikbaar. Mede daarom wil Windex Software BV versie 5 geschikt maken voor het Web. Hierbij wordt gedacht aan gegevensbeheer op afstand door zowel eindgebruikers als personen en instanties waarvan gegevens worden bijgehouden, het bieden van een grafische interface die toegankelijk is via een browser en de ondersteuning van content management activiteiten (zoals Web sites, Internet Portals, et cetera).

1


Vanwege de ervaring die Windex Software BV heeft met Microsoft en haar producten is gekozen voor het .NET framework van Microsoft als basis voor de nieuwe versie. .NET FRAMEWORK

Microsoft zegt over het .NET framework: “Microsoft .NET is een set software technologieën ontworpen om je wereld van informatie, mensen, systemen en apparaten te verbinden”. Dit lijkt goed te passen bij de visie van CRM en lijkt daarmee een goede basis voor de nieuwe versie.

SOA/XML WEB SERVICES

Het .NET framework ondersteunt het applicatiegericht gebruik van het Internet en vloeit voort uit de ontwikkeling van Service Oriented Architectures (SOA) en XML Web Services. Deze gebieden zullen daarom ook bestudeerd worden.

OPDRACHT

Tijdens deze doctoraalopdracht is gekeken naar mogelijkheden voor het verbeteren van flexibiliteit en schaalbaarheid van een Customer Relationship Management software pakket, dat herontworpen is vanuit een servicegeoriënteerd oogpunt. Dit zal worden toegepast op de situatie binnen Windex Software BV, in het .NET framework. De volledige tekst van de opdracht is opgenomen in Appendix I.

2

Hoofdstuk 2: Probleemdefinitie en aanpak

H O O F D S T U K

2

Probleemdefinitie en aanpak In dit hoofdstuk wordt het domein van deze doctoraalopdracht besproken. Allereerst zal de probleemdefinitie gegeven worden en het doel van de opdracht. Aan de hand hiervan zal een aantal onderzoeksvragen gepresenteerd worden. Tenslotte is de aanpak besproken.

1

Probleemdefinitie Het Internet wordt steeds meer gebruikt als hulpmiddel in de ontwikkeling van applicaties. Applicaties gebruiken niet alleen het Internet zelf (bijvoorbeeld als communicatiemedium), maar ook technologieën die voortkomen uit de ontwikkeling van het Internet. Bestaande Business-to-Business (B2B) en Enterprise Application Integration (eAi) oplossingen zoals Electronic Data Interchange (EDI) leiden tot onvrede, vanwege het gebrek aan uniformiteit en universele acceptatie en de vaak hoge kosten. Bestaande middleware zoals Distributed COM (DCOM), Jini en Common Object Request Broker Architecture (CORBA) slagen er niet in de beloftes van platformonafhankelijkheid, universele communicatie tussen objecten en componenten en transparantie van communicatie waar te maken. Nieuwe concepten, zoals de Service Oriented Architecture (SOA), XML Web Services en het .NET platform worden en zijn ontwikkeld met het doel in te springen op deze ontwikkelingen en problemen. In deze doctoraalopdracht is gekeken hoe deze nieuwe ontwikkelingen toegepast kunnen worden bij Windex Software BV om te komen tot een schaalbaar, flexibel, Internet-enabled raamwerk voor Customer Relationship Management (CRM) activiteiten, dat dient als basis voor het herontwerp van de applicatie van Windex Software BV. Hieruit volgt de volgende probleemdefinitie: “Hoe kan het .NET platform binnen Windex Software BV ingezet worden om te komen tot een schaalbaar en flexibel, Internet-enabled framework voor de volgende generatie van de Windex Customer Relationship Management software?”

1.1 Doel Het doel van deze doctoraalopdracht is te komen tot een advies inzake methoden en technieken voor het verbeteren van flexibiliteit en schaalbaarheid van de Windex CRM software in een gedistribueerde omgeving als het Internet, met gebruikmaking van het .NET platform van Microsoft.

1.2 Onderzoeksvragen De probleemdefinitie spreekt van een “framework voor de volgende generatie van de Windex CRM software”. Dit wijst op een applicatie-

3


overstijgend niveau van redeneren. Dit niveau is het niveau van software architecturen. Daarmee kan de eerste onderzoeksvraag opgesteld worden: “Wat zijn software architecturen?”. De probleemdefinitie spreekt ook van het .NET platform. Het .NET platform van Microsoft vloeit voort uit de filosofie van services: eenheden van informatie en verwerking met een contract in de vorm van een interface. Dit relatief nieuwe paradigma wordt ondersteund door een speciale architectuur, de Service Oriented Architecture (SOA). Dat leidt tot de tweede onderzoeksvraag: “Wat is de Service Oriented Architecture, en hoe is deze ontstaan?”. Specifiek richt het .NET platform zich op XML Web Services: services die beschreven en gedefinieerd worden met XML en ook via een op XML gebaseerd protocol communiceren, via het Internet. Dit leidt tot de derde onderzoeksvraag: “Wat zijn XML Web Services, en hoe zijn deze ontstaan?”. De probleemdefinitie spreekt verder van “een schaalbaar en flexibel […] framework”. Dit leidt tot de vierde onderzoeksvraag: “Hoe kunnen flexibiliteit en schaalbaarheid worden meegenomen in de ontwikkeling van een architectuur?”. Tenslotte noemt de probleemdefinitie nog Windex Software BV. De onderzoeksvragen moeten toegepast worden binnen het domein van Windex Software BV. Dit leidt tot de vijfde en laatste onderzoeksvraag: “Hoe zou het framework voor Windex Software BV eruit moeten zien, met inachtneming van de verzamelde adviezen?”. Samengevat worden de volgende onderzoeksvragen opgesteld: • Wat zijn software architecturen? • Wat is de Service Oriented Architecture, en hoe is deze ontstaan? • Wat zijn XML Web Services, en hoe zijn deze ontstaan? • Hoe kunnen flexibiliteit en schaalbaarheid worden meegenomen in de ontwikkeling van een architectuur? • Hoe zou het framework voor Windex Software BV eruit moeten zien, met inachtneming van de verzamelde adviezen?

2

Aanpak Om deze onderzoeksvragen te kunnen beantwoorden, is gekozen voor de volgende aanpak: 1. Er is een literatuuronderzoek gedaan en de resultaten hiervan zijn samengebracht in een State-of-the-Art (SOTA) report over het onderzoeksgebied; 2. Op basis van het SOTA is een voorstel voor een raamwerk ontworpen voor WindexVIJF; 3. Met dit raamwerk is op een iteratieve manier een prototype ontwikkeld in 2 slagen: a. Het 1e prototype is ontwikkeld om aan te tonen dat het raamwerk te realiseren is; b. Het 2e prototype is ontwikkeld om experimenten op het gebied van schaalbaarheid uit te voeren, en om in

4

Hoofdstuk 2: Probleemdefinitie en aanpak

te kunnen schatten waar het raamwerk flexibeler is dan Windex 4; 4. Er is een aantal metingen gedaan aan de schaalbaarheid van het prototype; 5. De flexibiliteit van het prototype ten opzichte van Windex 4 is beoordeeld; 6. De vergaarde ervaring en kennis is omgezet in adviezen en strategieën voor het ontwerp en de implementatie van WindexVIJF. Voor deze aanpak is gekozen omdat dit een gestructureerde, evolutionaire aanpak is. Iedere stap vormt een afgesloten geheel, welke in een volgende stap uitgebreid wordt. Dit zorgt ervoor dat zaken die pas in een later stadium spelen, ook voor dat latere stadium bewaard kunnen worden. Het is vaak makkelijker een aantal kleine stappen te zetten, dan één grote.

5


H O O F D S T U K

3

Stand van de technologie Dit hoofdstuk geeft een overzicht van de huidige stand van de technologie en beschrijft een aantal concepten die ten grondslag liggen aan de volgende hoofdstukken. Allereerst zal in paragraaf 1 het concept van “software architectuur” behandeld worden. Hiermee wordt de onderzoeksvraag “Wat zijn software architecturen?” beantwoord. Vervolgens zullen tiers behandeld worden, groeperingen van functionaliteit in lagen op basis van verantwoordelijkheid binnen de applicatie. In paragraaf 3 komt kwaliteit van software architecturen aan de orde. De daarin behandelde aspecten vormen belangrijke aandachtspunten bij het opstellen van een software architectuur. Tenslotte zullen in paragrafen 4 en 5 respectievelijk de Service Oriented Architecture en XML Web Services behandeld worden, om daarmee de tweede respectievelijk derde onderzoeksvraag te beantwoorden.

1

Software architecturen

ABSTRACTIES

Abstractie wordt veelal gebruikt om te kunnen redeneren over grote en complexe systemen. In het verleden leidde dit tot de abstracte data types, macrofuncties, objecten, componenten, et cetera. Uiteindelijk leidde dit tot de software architectuur: een ordening van functionele blokken (objecten en componenten) die een bepaald software systeem voorstellen [GAR94], [BAR99]. Software architecturen zijn belangrijk omdat ze het mogelijk maken over een systeem te redeneren zonder dat alle objecten in dat systeem bekend zijn. Complexe systemen als WindexVIJF kunnen zo worden teruggebracht tot hun essentie: het probleem dat opgelost moet worden en de manier waarop dat moet gebeuren.

1.1 Vooraf: andere vormen van architectuur Voor de begripsvorming is het interessant om te kijken of er parallellen te trekken zijn tussen software architectuur en andere vormen van architectuur, zoals gebouwen, hardware en netwerken [PER92]. GEBOUWEN

6

Bij architectuur van gebouwen zijn er 2 fenomenen die interessant zijn in het kader van software architecturen: aanzichten en stijl. Een aanzicht is een belichting van de architectuur vanuit een bepaalde hoek, waarbij al het “niet-zichtbare” weggelaten wordt. Binnen software architectuur kan dit gebruikt worden voor stakeholderspecifieke “aanzichten” op de architectuur. Een stijl is een combinatie van “bouwmaterialen” (programmeertalen en ontwikkelomgevingen), -methodes (middleware, ontwikkelparadigma’s) en esthetica. Stijl kan gebruikt worden als discriminerende factor voor software architecturen.

Hoofdstuk 3: Stand van de technologie

HARDWARE

Hardware architecturen kenmerken zich door een klein aantal ontwerpelementen. Het benadrukte aspect1 is hierbij de discriminerende factor op basis waarvan verschillende architecturen onderscheiden worden. Schaal (nodig om om te kunnen gaan met hogere belastingen) wordt bereikt door replicatie van de ontwerpelementen. Software architecturen hebben echter een groot (en groeiend) aantal ontwerpelementen en bereiken schaal door het toevoegen van specifieke elementen.

NETWERK

In netwerkarchitecturen kunnen de diverse elementen worden gegeneraliseerd als nodes (de eindpunten van communicatie), verbindingen (het medium tussen nodes dat gebruikt wordt om over te communiceren) en relaties (wat en waarom er gecommuniceerd wordt). Netwerkarchitecturen kunnen dus bestaan uit slechts 3 ontwerpelementen: nodes, verbindingen en relaties. Daarmee lijken netwerk-architecturen een geschikte metafoor voor één bepaald aanzicht van software architectuur: het procesaanzicht, waarin de diverse processen binnen de applicatie in kaart worden gebracht. Er zijn echter maar een beperkt aantal topologieën van de ontwerpelementen binnen netwerkarchitecturen, terwijl het aantal topologieën bij software architecturen onbeperkt is. In deze 3 metaforen wordt architectuur gebruikt als metamodel. De architect maakt gebruik van een (liefst beperkt) aantal ontwerpelementen (of meta-classes), waarmee hij een model maakt van hetgeen hij wil ontwerpen (zij het een gebouw, een stuk hardware of een netwerk). Dit model kan hij vervolgens gebruiken om met bijvoorbeeld te stakeholders te communiceren over het te ontwerpen object en om dat object te analyseren en te manipuleren voordat dit geconcretiseerd wordt (in een specifiek ontwerp).

1.2 Inleiding tot software architectuur AANZICHT

Een architectuur bepaalt een aanzicht van een systeem, waarin een zeker aspect wordt belicht, zoals bijvoorbeeld de structuur of de communicatie. Architectuur is van een ander niveau dan ontwerp, omdat architectuur de nadruk expliciet op abstractie legt: de concretisering van een architectuur ís het ontwerp. Daarnaast ligt de nadruk op standaarden, om specifieke applicaties te ontstijgen en te komen tot meer algemene architecturale modellen van applicaties.

DOEL

Het doel van software architectuur valt in 4 punten uiteen [PER92]: 1. Een raamwerk voor het voldoen aan de eisen van de stakeholders; 2. Een basis voor het technisch ontwerp, proces-management en schattingen van de kosten; 3. Een effectieve basis voor hergebruik; 4. Een basis voor afhankelijkheids- en en consistentie-analyse.

HYPE

De initiële successen van de toepassing van software architecturen in het ontwerpproces leidden al snel tot een hype. In deze hype werd architectuur gelijkgetrokken met Architecture Description Languages

1

Zoals de instructieset bij RISC (Reduced Instruction Set Computer) architecturen

7


(ADL’s), software-ontwerp en systeemanalys [MED98]. ADL’s worden echter gebruikt om software architecturen formeel dan wel informeel te beschrijven, terwijl software-ontwerp van een lager abstractieniveau is dan software architectuur. Bij software-ontwerp ligt de focus niet zozeer op structuur van de applicatie, als wel op algoritmen en datatypes. Systeemanalyse tenslotte is maar een onderdeel van software architectuur: het formele karakter van systeemanalyse belemmert try-outs en globale inspecties van alternatieven, terwijl deze ook onderdeel kunnen vormen van software architectuur. STERK/ZWAK

Software architectuur is sterk als communicatiemiddel naar diverse (niet-technische) stakeholders. Grafische representaties en de hoge abstractie maken software architecturen goed te begrijpen, ook voor niet-technische stakeholders. Daarnaast kan architectuur dienen als voertuig voor scheiding van verwerking en interactie. Hier ontstaat echter ook meteen een zwakte van architectuur: implementaties hóeven de architectuur niet te volgen en uitspraken vanuit de architectuur hoeven dus niet noodzakelijkerwijs te gelden in een implementatie van de architectuur. Daarnaast worden micro-evoluties onzichtbaar door de hoge abstractiegraad.

1.3 Context en motivatie Het opstellen van een software architectuur neemt een bepaalde plaats in in het softwareproces, dit is de context. Binnen de afstudeeropdracht wordt deze context gedefinieerd als volgt2 [PER92]: • eisen bepalen (de karakteristieken van) de informatie en de verwerking, op basis van de behoefte van de gebruiker3 • architectuur is het raamwerk van elementen, interacties en beperkingen waarmee voldaan wordt aan de eisen • ontwerp deelt het systeem op in functionele modules en interfaces die de intermodulaire communicatie vastleggen. Algoritmen, procedures en datatypes maken ook deel uit van het ontwerp • implementatie is de representatie van het ontwerp in een specifieke programmeeromgeving Eisen

Architectuur

Ontwerp

Implementatie FIGUUR 1: HET SOFTWAREPROCES

2

Deze context is niet algemeen toepasbaar voor software architectuur, met name niet voor Artificial Intelligence (AI) 3 Dit is een erg “pure” definitie; in de praktijk zullen de architectuur, het ontwerp en de implementatie additionele (beperkende) eisen stellen

8


Daarnaast is er nog een motivatie nodig voor een software architectuur, die aangeeft waarom de software architectuur ontworpen is. De motivatie van een software architectuur bestaat uit deze doelen [PER92]: • een software architectuur geeft aan hoe strict een ontwerp moet zijn, en hoe relatief/specifiek de architectuur is • daarnaast wordt aangegeven welke elementen behoren tot de minimaal benodigde set om te voldoen aan de eisen (bouw) en welke daar buiten vallen (esthetica/decoratie) • indien nodig worden diverse aanzichten geboden, die elk een ander aspect benadrukken • ten slotte dient de architectuur ter analyse van de interafhankelijkheden van de eisen, de architectuur en het ontwerp, alsmede de verschillende elementen en ook de consistentie tussen stijlen, tussen stijl en architectuur en tussen architecturale elementen.

1.4 Model Het eerste element uit de context is “eisen”. Eisen aan een applicatie worden gesteld door iedereen die belang heeft bij de applicatie: bijvoorbeeld de klant, de gebruiker, de ontwikkelaar. Dit zijn stakeholders van de applicatie. Door hun eisen op te nemen in de architectuur, wordt de architectuur de hoeksteen van het softwareproces: zolang niet voldaan is aan de stakeholdereisen, kan niet worden overgegaan op ontwerp en implementatie. De elementen van een architectuur vallen uiteen in informatiebevattende data-elementen, die getransformeerd worden door verwerkings-elementen. Deze elementen worden verbonden met elkaar door verbindingselementen. Of elementen essentieel of decoratief zijn, wordt bepaald door middel van een weging van eigenschappen en relaties. Deze weging kan ook gebruikt worden voor een stelling van alternatieven, om de keuzeruimte te beperken. Dit is de vorm van een architectuur. Met deze 3 onderdelen ligt een architectuur nog niet vast: er zijn nog vele ontwerpkeuzes te maken. Deze worden expliciet gemaakt in de rationale. Hier wordt ook de motivatie van keuzes (als een keuze is gemaakt in de architectuur) in opgenomen. Dit leidt tot het volgende model voor architectuur [GAC95]: architectuur = {Elementen, Vorm, Rationale, Stakeholders} AANZICHTEN

Aanzichten vormen een gereedschap om de architectuur beter communiceerbaar te maken. Drie aanzichten zijn belangrijk: • proces4 geeft een beeld van hoe de data door het systeem stroomt in termen van de processen • data geeft een beeld van de stroom van de processen in termen van de data

4

In de literatuur worden vaak “functie” en “object” gebruikt. Het lijkt echter alsof hiermee al uitspraken gedaan worden over de implementatie (functioneel, object-georiënteerd). Daarom worden de neutralere termen “proces” en “data” gebruikt

9


•

verbindingen geeft een beeld van de verbindingen tussen de processen en de data Deze aanzichten zijn sterk verwant: de toestand in een aanzicht is vaak het directe gevolg van de toestand in de twee andere.

1.5 Voordelen Het opstellen van een software architectuur heeft een aantal sterke voordelen, enkele waarvan hier besproken worden.

Gegarandeerde basis De architectuur vormt een basis voor het uiteindelijke systeem, welke gegarandeerd voldoet aan de stakeholdereisen. Hoe vroeger in het softwareproces fouten worden ontdekt, hoe goedkoper deze zijn op te lossen. Ambiguïteiten, die ontstaan als de belevingswereld van stakeholders en ontwikkelaar verschillen, maar zij toch een gezamenlijke terminologie gebruiken, kunnen leiden tot ernstige dwalingen tijdens de implementatie. Het uiteindelijke systeem zal dan niet voldoen aan de eisen van de stakeholders en dus niet geaccepteerd worden. Door in een vroeg stadium de stakeholdereisen al expliciet te maken, en deze vervolgens expliciet in de architectuur te verwerken, wordt deze situatie voorkomen. Omdat alle stakeholdereisen expliciet zijn gemaakt, kan er ook een weging aan toegekend worden. Deze weging kan gebruikt worden om prioriteiten te stellen in het softwareproces. Deze prioriteiten kunnen weer meegenomen worden in een stuk Quality Assurance (QA, kwaliteitsbewaking) en risicomanagement: er kan dan in geval van nood bezuinigd worden op onderdelen met een lagere prioriteit om de onderdelen met een hogere prioriteit voldoende aandacht te geven. Verder ontstaat dankzij het overzicht van de eisen een beter beeld van het totale project. Dit leidt ertoe dat projectmanagement beter uitgevoerd kan worden en een betere schatting kan worden gemaakt van de benodigde inspanning.

Analyse De documentatie die bij een software architectuur hoort, bevat alle informatie die nodig is voor de analyse van het systeem. Na de initiële inspanning van het opstellen van de architectuur heeft men dus de beschikking over voldoende informatie voor de overige stappen in het softwareproces. Als gebruikgemaakt wordt van formele specificatiemethoden in de documentatie, kan deze zelfs vaak automatisch geanalyseerd worden. Met bepaalde formele methoden wordt het systeem ook verifieerbaar; dat wil zeggen dat het mogelijk is te verifiëren dat bepaald gedrag altijd, of juist nooit, of alleen in specifieke gevallen voorkomt. De initiële inspanning bij het opstellen van de architectuur maakt de volgende stappen in het softwareproces dankzij de analysemogelijkheden dus lichter, verkleint de kans op fouten en reduceert daarmee de ontwikkelinspanning en dus de kosten.

10


Hergebruik Zorgvuldig ontworpen architecturen bevorderen de mogelijkheden voor hergebruik. De architectuur kan als basis dienen voor een meer uitgebreide applicatie, of een gerelateerde applicatie. Door het hoge abstractieniveau kunnen elementen ook worden overgenomen in andere architecturen. Op het raamwerk van elementen en vorm kunnen daarnaast meerdere applicatie gebaseerd worden, bijvoorbeeld met verschillende data stores of presentatieterminals. Bij een opvolger van het systeem kan de architectuur ook als basis dienen. De ontwerpkeuzes zijn allemaal gedocumenteerd, en kunnen dus getoetst worden op relevantie ten opzichte van de opvolger. Veel beslissingen en aannames zullen nog steeds gelden en die onderdelen kunnen dus hergebruikt worden in de nieuwe versie.

2

Tiers Een tier is een combinatie van functies met een gemeenschappelijk doel, die vrijwel onafhankelijk is van eventuele andere tiers. Tiers kunnen gebruikt worden om semantische scheidingen aan te brengen in software architecturen.

2.1 2-tier architecturen Eén van de meest voorkomende architecturen is de 2-tier architectuur. In deze architectuur is er een client en een server. In de client vindt alle presentatie en verwerking plaats, terwijl de server alle data aanlevert. Traditionele Internet-applicaties zoals FTP, WWW en Gopher zijn ontworpen volgens de 2-tier architectuur [DTE98]. De 2tiered aanpak heeft een aantal tekortkomingen, zoals de fat clients5, complexe Application Programming Interfaces (API’s) voor business logic, hoge netwerkbelasting, beperkte transactie-ondersteuning, onbeheersbaarheid van het beveiligingsregime op de client, gebrekkige mogelijkheden voor hergebruik, en de slechte herconfigureerbaarheid (updates moeten altijd naar alle clients worden gedistribueerd). Door de 3-tier architectuur toe te passen kunnen deze problemen voorkomen worden.

2.2 3-tier architecturen De functies van de meeste applicaties zijn op te delen in 3 functiedomeinen: presentatie (interface en dialoog), applicatie (business logic) en data. Deze 3 domeinen vormen de 3 tiers in een 3tiered architectuur (zie Figuur 2). DATA

5

De data tier zorgt voor de opslag van gegevens, transacties en ontkoppeling van logische en fysieke datastructuur. Als de applicatie tier voor alle datafuncties vertrouwt op de data tier, ontstaat er een

Een client heet fat als deze alle verwerking van gegevens zelf uitvoert.

11


betere portability, omdat de data tier vervangen kan worden door een vergelijkbare tier zonder dat de applicatie tier hiertoe veranderd hoeft te worden. APPLICATIE

De applicatie tier (“Application Kernel”) bevat alle functionaliteit om de business tasks uit te voeren. De applicatie tier communiceert met de data tier om gegevens op te halen en op te slaan en gebruikt application services, welke het systeem ondersteunen in het verlenen van service.

PRESENTATIE

De presentatie tier tenslotte bestaat uit dialoogfuncties die de interactie met de gebruiker afhandelen en presentatiefuncties die informatie tonen aan de gebruiker. Voor systemen waar geen menselijke gebruiker aanwezig is, kunnen deze gelezen worden als batch control en definities van input/output formaten en interfaces. Input/output

Dialoog

Batch control

Services

Application Kernel

Application

Presentatie

Data FIGUUR 2: 3-TIER ARCHITECTURE [REN97]

KRITIEKE SUCCES FACTOREN

Kritieke succes factoren voor een 3-tier architectuur zijn: • zorgvuldig ontworpen interfaces • authenticatie, autorisatie en encryptie op ieder niveau • gegarandeerde consistentie middels transacties • passende communicatie-infrastructuur6

VOORDELEN

De 3-tier architecture heeft als voordelen dat de aandachtspunten gescheiden worden: de tiers zijn redelijk onafhankelijk, en kunnen dus vervangen worden door andere tiers die dezelfde functionaliteit bieden. Dit zorgt voor een goede onderhoudbaarheid, en testen en distributie worden er makkelijker door. Ook zorgt het voor een betere portability en neemt de belasting van de client en het netwerk af, doordat de verwerking nu op de server (of een aparte server) plaats kan vinden. Omdat de verwerking niet langer op de client plaatsvindt, maar op een “eigen” server is er een grotere controle mogelijk en kan er dus een beter securitymanagement gevoerd worden.

NADELEN

De heldere structuren en goed ontworpen, herbruikbare componenten zijn duurder in ontwikkeling en vereisen meer kennis, naast een formelere ontwerpstrategie. De toename van de ontwikkeltijd resulteert ook in een hogere time-to-market. Tenslotte wordt door de abstractie overhead geïntroduceerd, wat resulteert in een lagere efficiëntie en performance.

6

Veel gebruikte infrastructuren zijn CORBA (Common Object Request Broker Architecture), DCOM (Distributed COM), J2EE (Java 2 Enterprise Edition) en .NET

12


2.3 Meer tiers In principe is het aantal tiers niet gelimiteerd. Iedere zinnige combinatie van functioneel gerelateerde componenten kan een tier zijn. Dankzij het groeiend applicatiegericht gebruik van het Internet is een steeds breder geaccepteerde architectuur de 4-tier architectuur, waarin de Web Server een eigen tier heeft [NOA00].

3

Kwaliteit van software architecturen Hieronder volgt een opsomming van 6 belangrijke kwaliteitsgebieden voor software architecturen, zoals gedefinieerd door Hilliard et al [HIL96].

BEGRIJPELIJKHEID

Begrijpelijkheid is verreweg de belangrijkste, omdat een architectuur alleen nuttig kan zijn in zover deze uitgedrukt kan worden in termen die door de betrokkenen begrepen worden.

HAALBAARHEID

Na begrijpelijkheid komt haalbaarheid. De architectuur moet voorzien in een voldoende basis om daarop een systeem te ontwerpen welke voldoet aan de stakeholdereisen. Haalbaarheid is een vereiste voor implementeerbaarheid7, onderhoudbaarheid en evolueerbaarheid.

OPENHEID

Steeds belangrijker wordt de openheid van een architectuur. Een open architectuur is ontworpen rond publieke standaarden, met publieke interfaces en services. Afhankelijkheden van eigen systemen of API’s zijn tot een minimum gereduceerd. Openheid draagt bij aan de begrijpelijkheid, omdat open standaarden over het algemeen zeer duidelijk gedefinieerd zijn.

EVOLUEERBAARHEID

Behalve begrijpelijk, haalbaar en open, moet een architectuur evolueerbaar zijn. Dat wil zeggen dat de architectuur een graad van veranderbaarheid heeft zodat tegemoet kan worden gekomen aan toekomstige stakeholdereisen en niet gescript gebruik8 terwijl de integriteit van de architectuur behouden blijft.

ONDERHOUDBAARHEID

Na de initiële roll-out van een architectuur, moet deze onderhouden kunnen worden. Onderhoudbaarheid hangt samen met evolueerbaarheid, in die zin dat ook voor een goede onderhoudbaarheid een applicatie een zekere veranderbaarheid moet hebben.

TEVREDENHEID

De laatste kwaliteitseis aan een architectuur is tevredenheid. Impliciete en niet (goed) gedocumenteerde stakeholdereisen kunnen ertoe leiden dat een systeem lijkt te voldoen aan alle eisen, maar dat de gebruiker er toch niet tevreden over is. Het is zaak deze situatie tijdens het ontwerp van de architectuur al te voorkomen, door intensief contact met alle stakeholders.

7

Dit is geen kwaliteitseis, maar vloeit voort uit de haalbaarheid van een architectuur Dat wil zeggen dat er op een andere manier gebruik van wordt gemaakt dan door de ontwikkelaars gedacht was (= het ‘script’) 8

13


4

Service Oriented Architecture Al lange tijd bestaat bij systeemontwerpers de visie dat grote complexe systemen moeten kunnen worden opgebouwd uit kleine, eenvoudige componenten. Achtereenvolgens hebben macro-functies, objecten en componenten deze visie niet kunnen verwezenlijken. De service is een nieuw begrip, dat wederom probeert deze visie te verwezenlijken. Een service wordt gedefinieerd als een eenheid van informatie en verwerking waarmee functionele eenheden kunnen communiceren via een publieke interface.

4.1 Services en architectuur Services worden in de vorm van een architectuur ondersteund door de Service Oriented Architecture (SOA). Openheid staat bij SOA’s hoog in het vaandel. De de facto infrastructuur voor SOA’s is dan ook het Internet als alomtegenwoordige, universele, goedkope, gestandaardiseerde en open communicatiebus. De bouwblokken (of ontwerpelementen) van services zijn: • Service: een logische entiteit in de vorm van een contract9 • Service provider: een logische entiteit die een service implementeert • Service requestor/consumer: een logische entiteit die een service gebruikt • Service locator/registry: een speciale service provider die een register van services en diensten voor het registreren en zoeken van services aanbiedt • Service broker: een speciale service provider die als intermediair tussen service requestor en service provider de onderlinge communicatie afhandelt. Service locator

Service requestor

Service broker

Service provider FIGUUR 3: SOA BOUWBLOKKEN [BRO02]

4.2 Interfaces In het servicegeoriënteerde paradigma staan de interfaces centraal. Een interface is een set semantische verwante publieke methodes, een contract tussen service provider en requestor. Er zijn 3 hoofdklassen interfaces: gepubliceerde interfaces zijn uniek identificeerbare interfaces, geregistreerd bij een service register. 9

Binnen de context van services is een contract een verzameling interfaces en andere bepalingen omtrend de wijze van communicatie

14


Publieke interfaces zijn beschikbaar gemaakt door een service provider, maar niet gepubliceerd: requestors moeten weten waar ze de service kunnen vinden. Duale interfaces tenslotte zijn interfaces die afhankelijk zijn van andere interfaces, bijvoorbeeld in de vorm van callback-functionaliteit. GEDRAG

Een interfacedefinitie in de vorm van de beschikbare methodes is veelal niet voldoende. Vaak is er een impliciete volgorde waarin de methodes moeten worden aangeroepen. Een gedragsspecificatie moet deze expliciet maken. WSFL, de Web Services Flow Language, is hier een interessante ontwikkeling.

4.3 Karakteristieken van services Services hebben de volgende karakteristieken: • Coarse-grained: services bevatten doorgaans grotere “brokken” functionaliteit dan klassieke objecten en componenten • Interfaces: meerdere providers kunnen meerdere interfaces implementeren en interfaces kunnen onafhankelijk van implementaties worden ontworpen en geanalyseerd • Ontdekken: services kunnen zowel tijdens het ontwerp, als tijdens het uitvoeren worden ontdekt en kunnen geïdentificeerd worden op eigen of provider identiteit, of op servicecategorie • Singleton: waar klassieke objecten en componenten veelal worden aangemaakt waar ze nodig zijn en aan één gebruiker worden gekoppeld, worden services één keer aangemaakt en bedienen ze meerdere gebruikers • Weinig koppeling (loosely coupled): service requestor, provider en services zijn alleen gekoppeld via de service interface • Asynchroon: service-implementaties werken over het algemeen met asynchrone communicatie.

4.4 Gedrag Er zijn twee verschillende manieren waarop de verschillende bouwblokken binnen een SOA kunnen samenwerken: via een lokaal register en via een globaal register. LOKAAL REGISTER

Bij een lokaal register registreert een service provider eerst een service bij het register (1). Op een gegeven moment zoekt een service requestor een service bij een register (2). Het service register maakt dan een service lease aan (3) en via de service interface hebben de service requestor en de service provider interactie (4).

15


Lokaal service register [2]

[3]

Service requestor

Service lease

[1]

Service provider

Service [4] interface FIGUUR 4: GEDRAG BIJ EEN LOKAAL REGISTER [ALF02]

GLOBAAL REGISTER

Bij een globaal register registreert de service provider de service bij zijn lokale service register #2 (1). Zijn lokale service register registreert de service bij de globale service register (2). Op een gegeven moment zoekt een service requestor een service bij zijn lokale service register #1 (3). Deze kan de service niet vinden, en probeert het bij de globale service register (4). De globale service register zorgt ervoor dat er een service lease wordt aangemaakt, en een service proxy, waarmee de service requestor zal communiceren (in plaats van de service provider) (5). De communicatie tussen proxy en provider hoeft niet dezelfde protocollen als de communicatie tussen de andere elementen te gebruiken (6). Tenslotte heeft de service requestor interactie met de service provider, via de service proxy (7). Service

[5]

[7]

Service requestor

Service lease

1111 0000 0000 1111 0000 1111 Service

proxy

interface [3]

Het wire protocol kan specifiek zijn voor proxy en provider [6]

Lokaal service register #1 [4] Globaal service register [2] Lokaal service register #2

[1]

Service provider

FIGUUR 5: GEDRAG BIJ EEN GLOBAAL REGISTER [ALF02]

4.5 Servicegeoriënteerd ontwerpen Nieuwe paradigma’s benaderen vanuit oude paradigma’s gaat vaak niet goed. Services vormen hierop geen uitzondering. Goede componenten zijn in de regel dan ook niet automatisch goede services, maar zijn wel de beste manier om services te implementeren. Dit leidt tot een gelaagd model voor applicatieontwerp:

16


Service laag

Component laag

Object/Class laag

FIGUUR 6: APPLICATIE-ONTWERPLAGEN [BRO02]

STATELESS

Services zijn vaak stateless en kunnen daarom beschouwd worden als managerobjecten die instanties van datatypen aanmaken en beheren. Het niet bijhouden van toestandsinformatie maakt kleine toestandsinspecties, waarbij slechts enkele gegevens uit een toestand worden opgevraagd, niet mogelijk: de gehele toestand moet in één keer opgevraagd worden. Services heten dan ook chunky, waar traditionele componenten vaak chatty heten.

CONSISTENTIE

Een bijkomend probleem is het gebrek aan een consistentiegarantie. Een requestor kan niet weten of de toestand die hij aangeleverd krijgt nog steeds de geldige toestand is op de provider en de provider kan niet garanderen dat een requestor een geldige toestand gebruikt. Duale interfaces met callback mechanismen bieden hier een oplossing.

4.6 Voor- en nadelen Het gebruik van de Service Oriented Architecture kent zijn voor- en zijn nadelen. Een aantal voordelen zijn [PAL01]: • losse koppeling, beperking afhankelijkheden tot interfaces • stabiel ontwerp dankzij de nadruk op publieke interfaces • flexibele configuratie dankzij de abstractie van lokatie en implementatie • behoud van investeringen door oude applicatie te voorzien van een “service-wrapper” • snellere time-to-market door kortere ontwikkelcyclus (integratie van services) Een aantal nadelen zijn: • abstracties introduceren overhead • netwerkverkeer is traag in vergelijking tot verkeer binnen de computer10 10

Netwerkverkeer verdubbelt in snelheid per 9 maanden, waar processoren dit per 18 maanden doen, dus dit nadeel kan verdwijnen [FOS02]

17


•

5

het Internet is een onbetrouwbaar medium

XML Web Services In de afgelopen 15 jaar zijn er 3 grote platformen geweest voor servicegeoriënteerde systemen: CORBA van de Object Management Group, Jini van Sun Microsystems en DCOM van Microsoft. Deze platformen kennen 4 belangrijke mankementen [OTO03]: • de interfacetalen zijn niet uitwisselbaar en niet universeel geaccepteerd • de informatiebussen zijn niet altijd uitwisselbaar en niet universeel • de interfaces van CORBA en Jini zijn in de praktijk statisch, terwijl DCOM een zeer ingewikkeld model gebruikt voor dynamische interfaces • het model voor de interface en het programmeermodel zijn bij deze drie platformen sterk gekoppeld.

5.1 Het ontstaan van XML Web Services Deze 4 mankementen worden opgelost door XML Web Services. Deze gebruiken XML als basis voor de interfaces (Web Services Description Language, WSDL), de communicatie (Simple Object Access Protocol, SOAP) en voor het beschrijven, ontdekken en integreren van services (Universal Description, Discovery & Integration, UDDI). Allen zijn open Internet standaarden, worden geaccepteerd en ondersteund door in ieder geval de belangrijkste spelers in de industrie en gebruiken het Internet als informatiebus. Tenslotte verzekert de documentmetafoor11 dynamische interfaces: eindpunten zijn simpel, terwijl de communicatie rijk is. Zoals reeds eerder opgemerkt is het Internet traditioneel een groot 2tiered gedistribueerd systeem. Business logic bevindt zich in de Web servers en de browser van de client presenteert deze. Interactie tussen systemen en mensen staat hier centraal. XML Web Services zorgen ervoor dat het Web gebruikt kan gaan worden als application space, een 3- of meer tiered systeem waar de focus niet ligt op interactie tussen systeem en mens, maar ook op systemen onderling. Middleware is op dit moment òf documentgeoriënteerd, òf proceduregeoriënteerd en de integratie is gericht op respectievelijk documenten of procedures en methodes. XML Web Services doorbreken dit patroon en ondersteunen beide vormen. Electronic Data Interchange (EDI), een standaard voor geïntegreerde B2B (business to business) transacties die veel gebruikt wordt door bedrijven, is kostbaar in implementatie en onderhoud. XML Web Services kunnen gebruikmaken van XML voor de definitie van elektronische documenten en kunnen dus ook een vervanger voor EDI vormen.

11

Bij documenten draait het niet om wie het document geschreven heeft, of wie het leest, maar wat er in het document staat.

18


5.2 Dynamische e-business Tijdens de Internet-hype raakten bedrijven in de ban van e-commerce en e-business: zakendoen en financiële transacties zouden voortaan plaatsvinden via het Internet. Het is nu tijd voor de volgende stap: dynamische e-business, waarbij integratie in de supply-chain (het netwerk van afnemers, transporteurs en leveranciers) centraal staat. Bij dynamische e-business zijn software bronnen loosely coupled. Service interfaces zijn universeel gepubliceerd en toegankelijk en de communicatie is gestandaardiseerd via Internetprotocollen. Applicaties kunnen opgebouwd worden door services te integreren en software kan verkocht worden in de vorm van een dienst. De SOA in het algemeen en XML Web Services in het bijzonder vormen enablers voor dynamische e-business. Dynamische e-business maakt het mogelijk automatiserings-software nauw aan te sluiten op de bedrijfsvoering en de mogelijkheden voor hergebruik maken het kosten- en productie-efficiënt. Daarnaast biedt dynamische e-business een nieuwe markt voor softwareontwikkelaars.

5.3 Architecturen voor XML Web Services Er zijn twee belangrijke architecturen voor XML Web Services: de Global XML Web Services Architecture (GXA) van Microsoft en de Web Services Conceptual Architecture (WSCA) van IBM. Beiden zijn een combinatie van specificaties en standaarden binnen het XML Web Services spectrum [KRE01], [MIC01]. Infrastructure protocols Transactions Reliable Messaging ... Discovery

SOAP Modules Referral

Security ...

Routing

License

Directory Inspection Description

Internet FIGUUR 7: DE GLOBAL XML WEB SERVICES ARCHITECTURE [MIC01]

19


Service Flow

Management

Service Description

Security

Service Publication

Quality of Service

Service Discovery

XML−based messaging Network FIGUUR 8: DE WEB SERVICES CONCEPTUAL ARCHITECTURE [KRE01]

De fundering van beide architecturen wordt gevormd door respectievelijk het Internet en het netwerk. Bij beiden is dit in de praktijk HTTP (HyperText Transfer Protocol), maar FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), MQ (Message Queue) en IIOP (WSCA) horen ook tot de mogelijkheden. Communicatie verloopt bij beide architecturen via het op XML gebaseerde Simple Object Access Protocol (SOAP) en beschrijvingen van services worden opgegeven in de Web Service Description Language (WSDL). Publicatie en ontdekken van services geschiedt via het op XML gebaseerde Universal Description, Discovery & Integration. Bij de WSCA vormen HTTP, SOAP en WSDL de minimale architectuur: deze is minimaal nodig om gebruik te kunnen maken van XML Web Services. Aangezien dit open Internet standaarden zijn en HTTP zo goed als alomtegenwoordig is, vormt dit een relatief goedkope instapbasis. SOAP kan uitgebreid worden met tal van modules, zoals de GXA laat zien. WS-Referral, WS-Routing, WS-Security en WS-License zijn enkele voorbeelden van (toekomstige) gestandaardiseerde SOAP modules die een uitbreiding vormen op SOAP. Bovenop de standaarden is ruimte voor eigen protocollen: zo definieert de GXA ondersteunende protocollen voor transactiemanagement en betrouwbare communicatie, en de WSCA de Web Services Flow Language (WSFL), waarmee gedrag van een service gespecificeerd kan worden.

20

Hoofdstuk 4: Opdrachtkader

H O O F D S T U K

4

Opdrachtkader De in Hoofdstuk 3 behandelde theorie zal toegepast worden om te komen tot adviezen inzake de methoden en technieken die door Windex Software BV gebruikt kunnen worden voor WindexVIJF. Er gelden echter een aantal randvoorwaarden, welke in dit hoofdstuk behandeld worden. Ten eerste wordt WindexVIJF ontwikkeld met het .NET framework. In sectie 4.1 wordt .NET afgezet tegen de klassieke Windows Distributed interNet Architecture (DNA). Ten tweede heeft Microsoft voor het succesvol gebruik van .NET een aantal richtlijnen opgesteld, welke behandeld worden in sectie 4.2. Ten derde zijn er een aantal kwaliteitsaspecten ten aanzien van de architectuur belangrijk voor WindexVIJF: flexibiliteit, schaalbaarheid, beveiliging en betrouwbaarheid. In de sectie 4.3 tot en met 4.6 worden deze aspecten beschreven. Elk van deze aspecten vormt een onderdeel van de omkadering van WindexVIJF. Ten slotte zijn er een aantal ontwerpkeuzes opgesteld ten aanzien van de scheiding tussen de lagen, de communicatie tussen de lagen, abstracties en berichtenuitwisseling. Sectie 4.7 behandelt deze ontwerpkeuzes.

1

Het .NET framework WindexVIJF wordt gebaseerd op het .NET framework van Microsoft. .NET is de opvolger van de Windows Distributed interNet Architecture, ontwikkeld vanuit de SOA filosofie. De business logic van DNA applicaties werd geïmplementeerd met Active Server Pages (ASP), COM(+) componenten en stored procedures [CHA02]. Deze aanpak kent een aantal nadelen: • ASP maakt gebruik van simpele scripttalen en code moet geïnterpreteerd worden bij iedere executie • ASP vermengt verwerkingscode met presentatiecode, wat een slechte onderhoudbaarheid tot gevolg heeft • Het is niet goed mogelijk ASP code te hergebruiken • COM(+) is uitgebreid, maar ook complex • Stored procedures zijn nauwelijks te debuggen • Stored procedures hebben een beperkt programmeer-model • Stored procedures zijn database-specifiek, wat een slechte portability12 tot gevolg heeft In .NET wordt business logic geïmplementeerd met assembly’s bestaande uit componenten en/of ASP.NET pagina’s, of stored procedures. ASP.NET maakt via code-behind files gebruik van de kracht van .NET talen als C# (ten opzichte van de scripttalen van

12

Portability: de mate waarin het haalbaar is om systemen om te zetten naar een andere omgeving

21


ASP) en scheidt daarmee tevens de verwerkingscode van de presentatiecode, door de verwerkingscode op te nemen in de codebehind files. Code-behind files kunnen bovendien eenvoudig worden hergebruikt in andere ASP.NET pagina’s13.maar niet in Windows Forms pagina’s. .NET biedt verder ook een uitgebreid beveiligingsmodel, waardoor het niet langer noodzakelijk is code òf volledig, òf geheel niet te vertrouwen.

2

Richtlijnen vanuit .NET Microsoft heeft een aantal richtlijnen opgesteld voor succesvol ontwerp van applicaties met het .NET framework. Microsoft stelt daartoe eerst de volgende 5 doelen van het ontwerpen van een applicatie [MIC02]: 1. Oplossen van het probleem 2. Beveiliging van meet af aan verwerken in de applicatie 3. Optimale prestaties voor inzettingspatronen 4. Goede schaalbaarheid, beheersbaarheid, onderhoudbaarheid en betrouwbaarheid bewerkstelligen 5. Flexibel in te zetten in meerdere applicatie- en inzettingspatronen Microsoft geeft een aantal richtlijnen voor applicatie- en serviceontwerp met welke deze doelen verwezenlijkt kunnen worden.

2.1 Algemene richtlijnen Een aantal algemene adviezen bij het ontwerpen van gedistrueerde applicaties zijn: • identificeer benodigde componenten. Niet iedere applicatie heeft ieder component nodig. • consistent ontwerp. Componenten van hetzelfde type hebben liefst hetzelfde ontwerpmodel. Bij grote coherentie is een enkel basiscomponent interessant. • analyseer communicatie. Het communicatiemechanisme tussen componenten moet goed aansluiten bij de aard en het doel van de communicatie. • consistente representatie. Gegevens moeten overal in het systeem op dezelfde manier gerepresenteerd worden. Dit houdt de applicatie overzichtelijk en voorspelbaar. • gebruik policy’s. Beveiliging, beheer en communicatie zijn aspecten die geabstraheerd kunnen worden tot policy’s, en geïmplementeerd met platformfuncties. • bepaal striktheid scheiding. Hoe strikt de tiers van elkaar gescheiden zijn beïnvloed de schaalbaarheid, flexibiliteit en onderhoudbaarheid van de applicatie. Hoe strikter, hoe beter, maar ook hoe complexer en hoe minder efficiënt.

13

Helaas kunnen Windows Forms geen gebruikmaken van deze code-behind pagina’s, dus het hergebruik blijft wel beperkt tot andere ASP.NET pagina’s.

22


2.2 Services, componenten en tiers Om te komen tot maximale inzetbaarheid en herbruikbaarheid, moeten services, componenten en tiers los gekoppeld zijn. Iedere uitspraak die gedaan wordt over de omgeving, is een beperking. Een harde scheiding tussen de applicatietiers en het verzamelen van semantisch gerelateerde functies in componenten of services helpt hierbij. Figuur 9 geeft een basisarchitectuur voor applicaties die als blauwdruk voor .NET applicaties kan worden gebruikt: Gebruikers Presentatie tier User interface

Beveiliging

Communicatie

Operationeel management

User interface process Business logic tier Service interface Business workflow

Business components

Business entities

Data tier Data access logic

Data bronnen

Service agents

Services

FIGUUR 9: BLAUWDRUK VOOR .NET APPLICATIES [MIC02]

Data tier: • Data access logic abstraheert van de specifieke gegevenstoegang • Service agents abstraheren van de communicatieverantwoordelijkheden bij externe services Business logic tier • Business workflow biedt functies voor het beheren van bedrijfsprocessen • Business components bevatten business rules en business tasks • Business entities zijn logische representaties van fysieke objecten • Service interface is een interface naar de business logic, die deze in de vorm van een service beschikbaar stelt. Wordt ook wel Business Façade genoemd Presentatie tier • User interface process handelt de interactie met de gebruiker op een procesgeoriënteerde manier af • User interface biedt functies voor het opbouwen en renderen van de gebruikersinterface (user interface, UI)

23


Application services: • Beveiliging zorgt voor de authenticatie en autorisatie van gebruikers • Operational Management biedt functies voor het beheer en onderhoud van het systeem • Communicatie biedt functies voor de communicatie met andere applicaties en services.

2.3 Business tiers De kern van een applicatie wordt gevormd door de business logic: de functies nodig om de bedrijfsprocessen waarvoor de applicatie wordt ingezet te ondersteunen. De kern van deze business logic wordt weer gevormd door de domain logic, specifiek voor het applicatiedomein. De organisatie van de bedrijfsprocessen en langlopende transacties wordt ondersteund door business workflow. Transacties kunnen worden beheerd door de Distributed Transaction Coordinator (DTC) – een .NET Enterprise Service –, COM Transaction Integrator (COMTI) en Host Integration Server. De volgende aanbevelingen gelden voor business logic tiers: • laat communicatie via berichten verlopen • maak services idempotent: tweemaal hetzelfde bericht ontvangen mag niet tot inconsistent gedrag leiden • mislukte transacties moeten opnieuw geprobeerd kunnen worden, evenzo voor berichten bij services • business componenten zijn onafhankelijk van de gebruikerscontext en maken dus ook geen gebruik van de identiteit van de gebruiker voor autorisatie en authenticatie • gebruik een consistent dataformaat voor parameters

2.4 Service interfaces Service interfaces vormen een trust boundary: er kunnen geen uitspraken gedaan worden over de requestor. Dit vraagt om een ander beveiligingsregime: in principe moet iedere requestor gewantrouwd worden. Service interfaces kunnen automatisch gegenereerd worden (vanuit een implementatie via reflectie, of vanuit de code), maar dit leidt vaak tot instabiele interfaces die sterk gekoppeld zijn aan de specifieke implementatie. Beter is het de service interface apart te ontwerpen, om onafhankelijkheid van platform en programmeeromgeving te garanderen. (Open) standaarden helpen hierbij, omdat standaarden stabiel moeten zijn. Daarnaast zijn standaarden ook vaak onafhankelijk van platform en programmeeromgeving. Caching, mapping en transformatie zijn services die niet gecombineerd horen te worden met business logic. Dit zijn als het ware services voor services.

24


3

Flexibiliteit Eén van de eisen aan WindexVIJF is flexibiliteit. In deze sectie wordt uitgelegd wat flexibiliteit in een applicatie betekent en veronderstelt. Middleware zoals CORBA en DCOM zijn gemeengoed in moderne software systemen en realiseren portability en interoperability. In toenemende mate worden echter ook configurability en reconfigurability wenselijk [BLA00]. Configurability maakt het mogelijk systemen in te zetten in meerdere omgevingen, vaak met conflicterende eigenschappen. Reconfigurability maakt het mogelijk het systeem aan te passen aan veranderingen binnen de eigen omgeving, zoals in mobiele omgevingen. Reflectie is een belangrijke enabler van configurability en reconfigurability. In 1981 formuleerde Brian Cantwell Smith14 reflectie als volgt: “Voor zover een computationeel proces … kan redeneren over de externe wereld [om te komen tot] een … interpreter waarmee de representatie van die wereld formeel kan worden gemanipuleerd, zo kan een computationeel proces ook … over zichzelf redeneren [om te komen tot] een … interpreter waarmee de representatie van zijn eigen operaties en structuren formeel kan worden gemanipuleerd ” Het belang van deze uitspraak is dat een proces zó kan worden ingericht dat het toegang heeft tot de eigen representatie, hierover kan redeneren en deze kan veranderen. Deze toegang wordt gerealiseerd via een Meta Object Protocol (MOP) met services op meta-niveau. Reification, het expliciet maken van aspecten van de interne representatie, biedt toegang tot dat meta-niveau. Iedere interface in een gedistribueerd systeem heeft zijn eigen metaspace: het meta-niveau inclusief toegangsmechanisme. Deze metaspace wordt opgedeeld in 4 orthogonale modellen15: 1. Het encapsulation meta-model geeft toegang tot het metaniveau in termen van de methodes en de attributen. Dit is equivalent aan de introspectie-mogelijkheden van Java, met de extra mogelijkheid de aanpassing van de gegevens. 2. Het compositional meta-model geeft toegang tot de compositie van het meta-niveau in de vorm van een graaf. Deze graaf kan via de interface van het meta-model geïnspecteerd en aangepast worden. 3. Het environmental meta-model geeft toegang tot de activiteiten die een component ondersteunen. Via dit metamodel kunnen pre- en postmethodes worden toegevoegd om bijvoorbeeld concurrency control, security management en compressiemogelijkheden toe te voegen.

14

Brian Cantwell Smith is de grondlegger van reflectie in programmeertalen. In 1981 studeerde hij af aan MIT op de introductie van reflectie in 3-Lisp. Tegenwoordig is hij Principal Scientist bij het Xerox Palo Alto Research Center. 15 Naar de aanpak van de ontwerpers van AL-1/D, een reflectieve programmeertaal voor gedistribueerde systemen

25


4.

4

Het resources meta-model is geen onderdeel van de meeste reflectieve talen en systemen, maar biedt toegang tot de systeembronnen die in gebruik zijn. In mobiele systemen zou dit bijvoorbeeld gebruikt kunnen worden om realtime de kwaliteit van een videostream aan te passen.

Schaalbaarheid Een andere eis aan WindexVIJF is schaalbaarheid. In deze sectie wordt uitgelegd wat schaalbaarheid is en hoe zich dat vertaalt naar applicaties. Neumann definieert schaalbaarheid als: “Zonder noemenswaardig verlies van prestatie of verhoging van complexiteit aankunnen van de toevoeging van meer gebruikers en bronnen” [NEU94]. Schaal bestaat uit 3 dimensies: het aantal gebruikers en objecten, de afstand tussen de nodes en het aantal organisaties met administratieve taken. Schaalbaarheid heeft invloed op tal van andere aspecten van systemen. Betrouwbaarheid is er daar één van. Bij gedistribueerde systemen is betrouwbaarheid erbij gebaat als er sprake is van een zekere redundantie van service providers. Schaalbaarheid kan deze redundantie gebruiken om stijgende belasting op te vangen. Redundantie wordt bereikt door de introductie van replica’s. Dynamische replicatie is een vorm van reconfigurability. Caching is een andere techniek om de systeembelasting te verminderen, maar deze is minder geschikt in het kader van betrouwbaarheid vanwege de consistentie-problematiek. Op een gegeven moment is een systeem zo groot geworden, dat het niet langer wenselijk of nuttig is alle administratie op één centrale plaats te voeren. Vaak zijn er dan ook meerdere partijen die een eigen administratie willen voeren. Tegelijkertijd met de groei van het systeem zal echter ook de informatie in het systeem sneller veranderen. Dan is het juist wenselijk een centrale administratie te voeren. Dit probleem kan opgelost worden met distributie en autonomie. Autonomie houdt in dat delen van het systeem tot op zekere hoogte onafhankelijk van de andere systemen kunnen functioneren en dus een eigen administratie zouden kunnen hebben. Een laatste belangrijk punt ten aanzien van schaalbaarheid is coherentie: naarmate het systeem groeit, wordt het ook heterogener. Coherentie waarborgt dat het systeem ondanks deze heterogeniteit toch voorspelbaar en onderhoudbaar blijft [EMM00]. Coherentie wordt bereikt door middel van stabiele interfaces, gestandaardiseerde protocollen en instructiesets, of virtuele executiemachines zoals de Java Virtual Machine (JVM) of de .NET Common Language Runtime (CLR).

4.1 Richtlijnen Hieronder volgen enkele richtlijnen gedistribueerde systemen [MIC02]:

26

voor

schaalbaarheid

van


• • • • • • • • •

• •

5

repliceer belangrijke bronnen om de beschikbaarheid van deze bronnen te verhogen distribueer replica’s zo dat een optimum bereikt wordt tussen netwerkbelasting en servicetijd gebruik een sneeuwbalstrategie om updates door te voeren. Update eerst de meest gebruikte replica’s en laat deze de update verder distribueren [ACO02] cache hiërarchische gegevens in lagere nodes, zodat geen continue verbinding met hogere nodes hoeft te worden onderhouden partitioneer de gegevensset, bronnen en operaties als sprake is van een duidelijke partitie in gebruik laat clients berekeningen uitvoeren als er geen speciale serverside kennis nodig is en de te versturen informatie niet significant toeneemt broadcasts schalen niet, zendt deze dus niet over het hele netwerk uit multicast alleen naar nodes die gebruik zullen maken van de multicast gebruik asynchrone communicatie en/of queuing als een direct antwoord niet noodzakelijk is. De service provider kan dan zelf bepalen wanneer het request behandeld wordt en zo de belasting beter spreiden houdt alleen statusinformatie bij als dit nuttig is minimaliseer resource contention – het verschijnsel dat meerdere objecten tegelijkertijd dezelfde bron willen gebruiken – en de tijd dat een bron geblokkeerd wordt

Beveiliging Zodra een applicatie wordt ingezet in een gedistribueerde omgeving, wordt beveiliging een belangrijk kwaliteitsaspect. Deze sectie legt uit wat beveiliging inhoudt en geeft een aantal richtlijnen om te komen tot een goede beveiliging. Beveiliging bestaat uit 3 stappen: identificatie, authenticatie en autorisatie. Bij identificatie wordt door de gebruiker een bepaalde identiteit opgegeven. Het systeem controleert dan of de gebruiker inderdaad deze identiteit heeft (authenticatie). Tenslotte worden aan de gebruiker rechten toegekend op basis van een policy (autorisatie). Policy’s (beleid) zijn vaak organisatiespecifiek en bepalen wie of wat welke activiteiten mag uitvoeren. Vaak zijn er ook meerdere policy’s in gebruik binnen een organisatie en dan kan het nuttig zijn om de policy’s te gebruiken als basis voor security zones. Binnen een security zone geldt één policy (of een beperkte set gerelateerde policy’s). De grens van een security zone is een trust boundary: alles dat over de grens komt moet geïdentificeerd, geauthenticeerd en geautoriseerd worden. Identificatie kan op verschillende manieren, waarvan de gebruikersnaam en de unieke code de meest gebruikte zijn. Unieke codes kunnen gegenereerd worden uit de hard- en/of softwareconfiguratie van de gebruiker en indien deze configuratie

27


vertrouwd kan worden, is authenticatie niet nodig. Omdat de identiteit van een gebruiker minder betekenis heeft naarmate de functionaliteit verder van de gebruiker verwijderd is (denk aan low-level data retrieval functies), wordt binnen het systeem de identiteit van de gebruiker omgezet in een unieke code, gebonden aan de succesvolle authenticatie, zoals een session ID. Authenticatie is een belangrijke activiteit bij beveiliging, omdat dit vaststelt of de door de gebruiker opgegeven identiteit strookt met een beveiligingsidentiteit in het systeem. Een challenge-response mechanisme zoals de combinatie gebruikersnaam/ wachtwoord zorgt voor voldoende vertrouwen in het identificatie/ authenticatie-proces. Autorisatie tenslotte kent de gebruiker een serie rechten en mogelijkheden toe en beveiligt de toegang tot code in .NET (code access security). Gebruikersmogelijkheden worden gedefinieerd op gebruikersniveau, of via een rol die een gebruiker wordt toebedeeld. Rollen verdienen hierbij de voorkeur, omdat die minder gekoppeld zijn aan de gebruiker en dus beter te hergebruiken en te onderhouden. Gebruikersrechten worden op objectniveau vastgelegd en bepalen de mogelijkheden die gebruikers hebben met deze objecten (lezen, schrijven, aanmaken, verwijderen, zien, et cetera). Veelgebruikt hiervoor is de Access Control List (ACL). Code access security is een nieuwe beveiligingsmethode geïntroduceerd door .NET en een uitbreiding op sandboxmechanismes als in Java. Deze extra beveiligingsdimensie maakt het mogelijk om op assemblyniveau te bepalen wat de mogelijkheden zijn. De resulterende sandbox is als het ware een afgeschermde machine waarbinnen de assembly wordt uitgevoerd. Gebruikers kunnen een actie alleen uitvoeren als deze zowel door de code access, als door het object waarop de actie wordt uitgevoerd, als door hun rol worden goedgekeurd. De hierboven besproken vormen van beveiliging zijn voldoende in een gesloten systeem. Gedistribueerde systemen echter, maken vaak gebruik van publieke communicatiekanalen. Deze communicatiekanalen moeten dan ook beveiligd worden. Dit kan op twee manieren. Ten eerste kan het kanaal zelf beveiligd worden, bijvoorbeeld met Secure Sockets Layer (SSL, een implementatie van Netscape Communications Corporation van Transport Layer Security, RFC 2246), welke een beveiligde communicatiecontext creëert boven een gangbare TCP (Transmission Control Protocol) verbinding. Ten tweede kunnen de berichten beveiligd worden middels een viertal technieken: 1. encryptie maakt het bericht onleesbaar 2. checksumming maakt het bericht onveranderbaar 3. signing maakt het bericht onontkenbaar 4. stamping maakt het onmogelijk de volgorde van berichten te beïnvloeden, of berichten te herhalen De volgende richtlijnen kunnen voor beveiliging worden opgesteld [MIC02]: • Gebruik geteste en bewezen beveiligingssystemen en laat eigen oplossingen in ieder geval grondig (liefst extern) testen

28


• • • • • •

• •

6

Gebruik geen security through obscurity, waarbij “beveiligd” wordt door kwetsbare delen te verbergen Vertrouw nooit externe systemen en input Valideer input altijd Geef nooit meer privileges en rechten dan strikt noodzakelijk Stel alleen noodzakelijke gegevens en componenten beschikbaar Houdt rekening met STRIDE: o Spoofing, een valse identiteit voorwenden o Tampering, ongeautoriseerde wijzigingen aanbrengen o Repudiability, ontkennen van verantwoordelijkheid o Information disclosure, ongeautoriseerd vrijgeven van informatie o Denial of service, onmogelijk maken van de dienstverlening o Elevation of privileges, ongeautoriseerd verkrijgen van meer privileges Voer de identificatie, authenticatie en autorisatie op het vroegste moment uit Intern bestaan minstens zoveel risico’s als extern

Betrouwbaarheid WindexVIJF is een centrale applicatie in de werkzaamheden van de gebruikers. Betrouwbare dienstverlening is dan erg belangrijk. Er zijn een aantal maatregelen die genomen kunnen worden om de betrouwbaarheid te verhogen, welke hier behandeld zullen worden.

SINGLE POINT OF FAILURE

Iedere applicatie kent zijn zwakke plekken en dit is over het algemeen ook niet te voorkomen. Als een enkele zwakke plek echter in staat is om de hele applicatie te laten ophouden (correct) te functioneren, dan heet deze zwakke plek een single point of failure. Deze situatie moet voorkomen worden, middels redundantie en fail-over technologieën. Belangrijke bronnen moeten gerepliceerd worden en de replica’s moet zo gedistribueerd worden dat de autonomie verhoogd wordt.

SAME TIME AND PLACE

Als op hetzelfde moment, of op dezelfde plaats opeens veel acties moeten plaatsvinden (congestion), dan is dit vaak niet mogelijk. Queuing zorgt ervoor dat alle requests in een wachtrij terechtkomen zodat acties op een later tijdstip uitgevoerd kunnen worden en er geen requests verloren gaan. Bij het gebruik van queuing is het vaak noodzakelijk gebruik te maken van asynchrone communicatie, omdat de requestor anders niet verder kan zolang het request in de wachtrij zit. Caching zorgt ervoor dat gelijke requests sneller antwoord kunnen krijgen, omdat het antwoord tijdelijk wordt opgeslagen en de communicatie hoeft in dat geval niet asynchroon te zijn.

TESTEN EN DEBUGGEN

De belangrijkste methode om de betrouwbaarheid van systemen te verhogen blijft testen en debuggen. Hierbij zijn formele analyse en verificatie de krachtigste methoden, maar ook de meest complexe. Formele analyse en verificatie kan als enige garanderen dat het systeem geen fouten bevat en dat altijd het gewenste gedrag wordt vertoond. Vaak zijn formele methoden echter te complex. Rigoreus testen en debuggen middels een goede testen debugstrategie is dan een goede tweede.

29


7

Ontwerpkeuzes Er zijn een aantal ontwerpkeuzes die een grote invloed hebben op hoe de architectuur eruit gaat zien. Deze zullen hier behandeld worden.

7.1 Scheiding van de lagen De scheiding van de verschillende lagen in een architectuur kan heel strikt zijn, dat wil zeggen dat componenten altijd tot precies één laag behoren, of alleen conceptueel, dat wil zeggen dat alleen als er over de architectuur gesproken wordt sprake is van een scheiding. Alle tussenvormen zijn natuurlijk ook mogelijk. Het hebben van een strikte scheiding betekent dat de lagen communiceren via interfaces en geen andere kennis hebben van andere lagen dan de interface van die lagen. Dit heeft een aantal voordelen: • Implementaties zijn alleen afhankelijk van de interface en kunnen makkelijk onderling uitgewisseld worden • De interfaces kunnen afzonderlijk ontworpen en geanalyseerd worden waarbij implementatiegebonden factoren genegeerd kunnen worden • Het communicatieregime kan per laag verschillen. In ieder geval hoeven andere lagen daar geen weet van te hebben • Veranderingen binnen een laag kunnen doorgevoerd worden zolang de interface hierdoor niet gebroken wordt • De lagen kunnen eenvoudig gedistribueerd worden, omdat ze een afgesloten geheel vormen • Schaalbaarheid en betrouwbaarheid zijn makkelijker te verbeteren, omdat replicatie en distributie vergemakkelijkt worden • De ontwikkeling kan parallel plaatsvinden, nadat de interfaces zijn vastgesteld Er zijn ook enkele nadelen: • De ontwerpinspanning ligt hoger, omdat de interfaces zorgvuldig ontworpen moeten worden • De ontwerpfase wordt langer, omdat de interfaces vantevoren ontworpen moeten worden • Interfaces zijn abstracties en introduceren dus overhead • Interface-ontwerp is complex, omdat de interface niet ambigue mag zijn • Implementaties die interfaces niet strikt implementeren, kunnen zeer moeilijk detecteerbare fouten introduceren Tegenover een strikte scheiding staat een louter conceptuele scheiding. De scheiding is dan alleen van belang voor het creëren van een referentiemodel voor de redenatie. De implementatie zou dan zelfs een monolitisch geheel kunnen zijn. Voordelen van een dergelijke aanpak zijn: • Het ontwerp is eenvoudiger en dus goedkoper • De implementatie is eenvoudiger en dus goedkoper

30


•

Overhead wordt geminimaliseerd, wat de systeemprestaties kan verbeteren. Er zijn echter ook een behoorlijk aantal nadelen: • Het systeem is minder overzichtelijk omdat de relatie tussen model en implementatie marginaal is • Uitbreidingen kunnen op willekeurige plaatsen in het systeem fouten introduceren, deze zijn niet traceerbaar aan de hand van het model • Modules kunnen onderling afhankelijk zijn, waardoor fouten in module A via module B fouten in module C kunnen opleveren • De implementatie is onvoorspelbaar en dus niet goed onderhoudbaar • Bij gebrek aan functioneel autonome eilanden kan het systeem slecht geschaald en/of gedistribueerd worden • Het systeem evolueert slecht, omdat evoluties in de implementatie geen impact hebben op het model, en vice versa

7.2 Communicatie tussen lagen Voor de communicatie tussen de lagen zijn er twee belangrijke ontwerpkeuzes: het bereik en de richting van de communicatie. Voor het bereik van de communicatie kan gekozen worden voor een strikte aanpak, waarbij alleen gecommuniceerd kan worden met direct aangrenzende lagen, of een losse aanpak, waarbij gecommuniceerd kan worden met alle lagen. Een strikte aanpak heeft als voordeel dat veranderingen in de communicatie tussen twee lagen geen gevolgen kan hebben in andere lagen. Daarnaast worden in tussenliggende lagen stubs geïntroduceerd, een soort “doorgeefluik” voor de communicatie tussen hogere en lagere lagen. Deze stubs kunnen dienen als plaats waar op een later tijdstip extra verwerking kan worden toegevoegd. Deze stubs introduceren echter ook overhead en dat is meteen het grootste nadeel. Bij onbegrensde communicatie is het voordeel meteen ook het nadeel: omdat alles met alles kan communiceren zijn er geen restricties op de communicatie en is deze dus ook niet voorspelbaar. Voor de richting van de communicatie zijn er ook twee mogelijkheden: alleen van boven naar beneden (pull) of ook van beneden naar boven (push)16. Alleen van boven naar beneden communiceren heeft de volgende voordelen ten opzichte van beide richtingen op communiceren: • Er is een duidelijke stroming in de communicatie. Dit draagt bij aan de overzichtelijkheid van het systeem • Implementaties hoeven alleen de interface te implementeren die hogere lagen verwachten. • Lagere lagen hoeven geen aannames te doen over hogere lagen en deze kunnen dus genegeerd worden tijdens het ontwerp van de laag Beide richtingen op geeft de volgende voordelen: 16

Een puur push-regime is niet werkbaar: de gebruiker zou dan nooit acties kunnen starten. Dit regime wordt dan ook alleen gebruikt in autonome rapportagesystemen.

31


• •

7.3

Rapportage en andere typische push-communicatie is makkelijk te implementeren Functionaliteit in hogere lagen is ook voor lagere lagen bereikbaar.

Abstracties Het laatste gebied waar ontwerpkeuzes liggen is die van de abstracties. Er zijn veel abstracties denkbaar in een systeem. Een aantal zal hier behandeld worden. Het datamodel is een mogelijke abstractie. Als gekozen wordt voor een strikte scheiding van de lagen met een strikt bereik van de communicatie, is het datamodel alleen belangrijk in de laag van de datastore en de laag daarboven. Het kan dan handig zijn een abstractie van het datamodel te gebruiken, bijvoorbeeld in de vorm van een objectmodel in de applicatie, maar een relationeel schema in de database. Verder kan het datamodel datastorespecifiek worden opgesteld, terwijl het logisch model datastore-onafhankelijk is. De identiteit van de gebruiker is een andere mogelijk abstractie. De identiteit van de gebruiker speelt alleen een rol in lagen die direct iets te maken hebben met de gebruikerscontext. Andere lagen zouden genoegen kunnen nemen met een interne identiteit om de hoeveelheid gegevens van gebruikers te reduceren (het is bijvoorbeeld niet nodig om in de database voor iedere gebruiker een apart account aan te maken, dat kan ook gedaan worden op basis van een rol, of zelfs een algemeen account). Het beveiligingsmechanisme kan ook een abstractie zijn, om bijvoorbeeld gebruik te kunnen maken van een omgevings-specifiek beveiligingsmechanisme als Active Directory of Novell Directory. Er wordt dan een interface gedefinieerd welke vastlegt welke acties mogelijk moeten zijn. Per specifiek beveiligingsmechanisme wordt een implementatie gemaakt die de acties vertaalt. Organisaties hebben eigen indelingen. Het systeem toespitsen op een specifieke organisatiestructuur is dan onwenselijk en dus is abstractie een optie. Nadeel is dat tenzij een zeer flexibele metastructuur wordt gekozen, er altijd organisaties zullen zijn die een structuur hebben die zich niet (goed) laten vertalen in termen van de metastructuur. Presentatieterminals zijn er in vele verschillende soorten en formaten, van mobiele telefoons tot high-definition beeldschermen. Daarnaast zijn er nog veel verschillende vormen van presentatie: tekst, Webinterfaces, Windows-interfaces, X-interfaces, et cetera. Het kan nuttig zijn van de specifieke presentatieterminal en –vorm te abstraheren om meerdere terminals en vormen te ondersteunen.

7.4 Berichtenuitwisseling De laatste categorie ontwerpkeuzes die hier behandeld wordt is de berichtenuitwisseling. Dit is vaak niet zozeer een keuze op architecturaal niveau, als wel voor specifieke delen van de communicatie.

32


Een van de belangrijkste keuzes is die tussen synchrone en asynchrone communicatie. Asynchrone communicatie kan garanderen dat er uiteindelijk een antwoord komt, terwijl de client verder kan werken na een bericht verzonden te hebben. Daarnaast schaalt asynchrone communicatie goed, omdat de server zelf kan bepalen wanneer een bericht verwerkt wordt. Synchrone communicatie kan deze garantie niet geven, en de client moet wachten totdat antwoord is gegeven. Als de client geen nuttig werk kan doen zolang het antwoord niet in ontvangen, kan beter gekozen worden voor synchrone communicatie. In alle andere gevallen is asynchrone communicatie beter. Een andere keuze is tussen calls en documenten. Een call is een simpel bericht dat naar een complex eindpunt wordt gestuurd. Het eindpunt bepaald wat de te nemen acties zijn. Een document is een complex en rijk bericht dat naar een simpel eindpunt wordt gestuurd. Op basis van de inhoud van het bericht wordt actie ondernomen. Een typisch voorbeeld van calls zijn Remote Procedure Calls (RPC), terwijl events en exceptions typische voorbeelden van documenten zijn. Queuing is een strategie bij berichtenuitwisseling waarmee voorkomen wordt dat een bericht verloren gaat doordat een eindpunt het tijdelijk niet kan ontvangen. In combinatie met asynchrone communicatie wordt queuing bijna altijd toegepast. Brokering zorgt ervoor dat eindpunten niet langer kennis over de communicatie met andere eindpunten hoeven te hebben: de kennis wordt gedelegeerd naar een specifiek component, de broker. Eindpunten hoeven dan alleen kennis te hebben van de communicatie met de broker. De broker handelt verder alle communicatieverantwoordelijkheden af. Brokers kunnen een voertuig zijn voor schaalbaarheid, flexibiliteit, configurability, reconfigurability, betrouwbaarheid en andere QoS aspecten.

8

Conclusie Het .NET framework, de kwaliteitsaspecten en de ontwerpkeuzes vormen een kader, waarbinnen de afstudeeropdracht zal plaatsvinden. Dit kader is echter breder dan de afstudeeropdracht en niet ieder aspect zal dan ook terugkomen. In het softwareproces vormt dit hoofdstuk de eerste stap van de architectuur: de eisen zijn bekend (het .NET framework, de kwaliteitsaspecten) en dus kan begonnen worden met het opstellen van een architectuur. Het hier geschetste kader vormt een afbakening voor de architectuur. In het volgende hoofdstuk zal de volgende stap gezet worden: het opstellen van een architectuur.

33


H O O F D S T U K

5

Architectuur In dit hoofdstuk wordt op basis van de theorie uit Hoofdstuk 3 en het kader uit Hoofdstuk 4 een architectuur voor WindexVIJF gepresenteerd. WindexVIJF biedt een managementomgeving voor alle informatie binnen de organisatie zoals documenten, bijeenkomsten, relaties, et cetera. De architectuur van WindexVIJF is gebaseerd op het n-tier model. In sectie 5.1 wordt een aantal uitdagingen voor WindexVIJF genoemd. In sectie 5.2 wordt daarnaast een aantal uitgangspunten voor WindexVIJF genoemd. Samen vormen deze secties de input voor sectie 5.3, de referentie-architectuur. Dit is een eerste schets van de architectuur met de belangrijkste subsystemen en actoren. In sectie 5.4 wordt de referentie-architectuur verder verfijnd door de subsystemen verder onder te verdelen.

1

Uitdagingen De ontwikkeling van WindexVIJF omvat een aantal belangrijke uitdagingen. Deze uitdagingen worden ingegeven door de stakeholders en vormen de kritieke succes factoren.

EVOLUEERBAARHEID

Het moet mogelijk zijn de functionaliteit van WindexVIJF uit te breiden. De architectuur moet daarom een zekere mate van flexibiliteit hebben. Nieuwe functionaliteit mag verder geen onvoorspelbare fouten introduceren.

EXTERNE CONNECTORS

In het ideale geval is WindexVIJF onafhankelijk van de infrastructuur, bestaande uit netwerkprotocollen, besturings-systemen, datastores, et cetera. Dit betekent dat het noodzakelijk is de bouwblokken van WindexVIJF zorgvuldig te specificeren. Een zorgvuldige specificatie bevat geen ambiguïteiten en bevat een (liefst formele) specificatie van iedere externe connector in termen van structuur, gegevenstypen en gedrag.

INTEGREERBAARHEID

WindexVIJF zal gekoppeld worden aan externe applicaties. Door gebruik te maken van (open) standaarden en interfaces wordt de complexiteit van deze integratie verminderd.

(HER)CONFIGUREERBAARHEID

WindexVIJF moet aangepast kunnen worden aan verschillende omgevingen (configureerbaarheid) en moet zich kunnen aanpassen aan veranderende omgevingen (herconfigureerbaarheid). Om dit mogelijk te maken moet WindexVIJF flexibel zijn.

SCHAALBAARHEID

Het toevoegen van meer gegevens en gebruikers, distributie over grotere afstanden en toenemen van het aantal administratieve domeinen mogen niet leiden tot significante vermindering van de prestaties: WindexVIJF moet schaalbaar zijn.

34

Hoofdstuk 5: Architectuur

BESCHIKBAARHEID

De rol die WindexVIJF heeft in een organisatie maakt het onacceptabel dat het systeem gedurende langere tijd onbeschikbaar is. Single points of failure mogen niet voorkomen.

BETROUWBAARHEID

De rol van WindexVIJF houdt ook in dat het gedrag in belangrijke mate voorspelbaar moet zijn. Dat wil zeggen dat consistentie en integriteit van het systeem, en met name de gegevens in het systeem, belangrijke uitdagingen zijn. De uitvoer van het systeem mag alleen afhankelijk zijn van de invoer.

BEVEILIGING

De publieke toegang die WindexVIJF introduceert ten opzichte van Windex 4, maakt beveiliging een belangrijke uitdaging. Identificatie, authenticatie en autorisatie, alsmede STRIDE vormen belangrijke aandachtspunten.

ONDERHOUDBAARHEID

Tenslotte is het beheer en onderhoud van WindexVIJF een uitdaging: de applicatiebeheerder moet voorzien worden van voldoende mogelijkheden om WindexVIJF te beheren. WindexVIJF moet de applicatiebeheerder hiertoe voorzien van sensoren en monitors om de systeemtoestand van WindexVIJF uit te lezen. In het ideale geval is WindexVIJF voor een deel zelf in staat onderhoud te plegen.

2

Uitgangspunten Een aantal uitgangspunten voor WindexVIJF is opgesteld, welke de keuzeruimte beperken.

ONTWIKKELING

WindexVIJF zal ontwikkeld worden met het .NET framework van Microsoft. .NET is gestoeld op de visie dat complexe systemen opgebouwd kunnen worden door services te integreren (zoals ook de Service Oriented Architecture en XML Web Services, zie Hoofdstuk 3). De nadruk op interfaces beperkt de afhankelijkheden en zorgen voor een goede evolueerbaarheid. Tenslotte bevordert .NET het gebruik van (open) Internet standaarden voor communicatie.

OMGEVING

De omgeving van WindexVIJF zal bestaan uit Windows servers en workstations, voorzien van versie 1.1 van de .NET CLR. Deze eis maakt dat de servers minimaal Windows 2000 (maar geen 64-bits versies) en de workstations minimaal Windows 98 moeten gebruiken.

DATASTORE

Omdat alle informatie binnen een organisatie binnen het bereik van WindexVIJF valt is de keus voor een database als datastore logisch. WindexVIJF zal gebruikmaken van SQL Server 2000, al is de architectuur datastore-onafhankelijk.

PRESENTATIE

WindexVIJF wordt gepresenteerd middels ASP.NET Internetpagina’s, getoond door Internet Explorer vanaf versie 6.0. Het grote marktaandeel van Internet Explorer heeft Windex Software BV doen besluiten geen andere browsers te ondersteunen. De architectuur doet echter geen uitspraken over de presentatievorm.

EXTERNE SYSTEMEN

WindexVIJF rekent verder nog op de aanwezigheid van Exchange Server 2000 en Outlook XP voor elektronische berichtgeving en Word XP voor het schrijven van documenten.

35


3

Referentie-architectuur De referentie-architectuur is bedoeld als verzameling van vroege ideeën omtrent de architectuur. De referentie-architectuur bestaat uit de hoofdfuncties van het systeem, de tiers waarin die hoofdfuncties vallen en de actoren (rollen).

3.1 Tiers De de facto keus voor een architectuur voor een servicegeoriënteerde applicatie zoals WindexVIJF moet worden is een n-tier architectuur. 3 tiers (data, applicatie en presentatie) is de minimale ntier architectuur. Voor WindexVIJF wordt echter de applicatietier nog opgesplitst in twee tiers: één voor de business logic (de business logic tier) en één voor de functies die de applicatie en deze business logic ondersteunen (de platform tier). De informatie in WindexVIJF en de kernfunctionaliteit (welke beschikbaar worden gesteld via de platform tier), kunnen zo ook ingezet worden op andere, nog niet voorziene manieren. Ook biedt het een extra punt waar centralisatie/decentralisatie, replicatie en distributie en andere maatregelen genomen kunnen worden. De inzet van WindexVIJF wordt hiermee flexibeler.

3.2 Hoofdfuncties In deze sectie zullen de hoofdfuncties per tier worden besproken. De hoofdfuncties dienen ten eerste om een goed beeld te krijgen van de applicatie en de verschillende tiers, maar vormen ook een overzicht van het systeem en kunnen later gebruikt worden als leidraad bij het concretiseren van de architectuur.

Data tier Het meest basaal zijn de primitieve functies die nodig zijn om data op te slaan en op te halen (de zogenaamde CRUD functies17). Deze functies worden verzameld in een subsysteem: Data Storage. Om datastore specifieke eigenschappen af te schermen van de rest van de applicatie, is verder nog een subsysteem Data Access gedefinieerd, dat als een façade voor Data Storage functioneert. Deze subsystemen worden door alle andere subsystemen gebruikt wanneer deze gegevens willen opslaan of ophalen.

17

36

De CRUD functies worden in Hoofdstuk 6 nader besproken.


Data Access Data

Data Storage FIGUUR 10: DATA TIER

Platform tier Daarnaast zijn er specifieke functies voor de verschillende taken van de applicatie, die gegroepeerd kunnen worden in subsystemen. Zo zullen er functies nodig zijn om de gebruiker bij te staan bij het beheer van documenten in de vorm van flowing-, tracking-, versioning- en collaborationfuncties. Deze functies worden gegroepeerd in het subsysteem Document Beheer. Gerelateerd aan documentbeheer zal de gebruiker ook bijgestaan moeten worden bij activiteiten die te maken hebben met content management, zoals waar welke content moet worden neergezet, en hoe deze getoond moet worden. Dit doet het subsysteem Content Management. Tenslotte zullen ook de informatie-elementen in het systeem, zoals adressen, contacten, personen, et cetera moeten worden beheerd. De gebruiker wordt hierin bijgestaan door het subsysteem Enterprise Information Management. Deze drie subsystemen vormen samen een platform, waarbovenop andere subsystemen kunnen draaien. Content Management

Platform

Document Beheer

Enterprise Information Management FIGUUR 11: PLATFORM TIER

Business logic tier Functies die gebruik zullen maken van de platform tier zijn bijvoorbeeld functies die de gebruiker bijstaan bij het definiëren van business rules: automatiseringsregels voor bedrijfsprocessen. Deze functies zijn opgenomen in een subsysteem Business Rules. Verwant aan de business rules zijn functies om workflow mee te ondersteunen, die opgenomen worden in het subsysteem Workflow. Ondersteuning van organisatiespecifieke inrichting wordt tenslotte geboden door het subsysteem Structure Definition. Samen vormen deze subsystemen de business logic tier:

37


Workflow

Business logic

Business Rules

Structure Definition FIGUUR 12: BUSINESS LOGIC TIER

Presentation tier Tenslotte zijn er algemene functies denkbaar voor de presentatie aan de gebruiker. Deze presentatie moet immers opgebouwd worden (door een Renderer) en gedefinieerd kunnen worden (door een Interpreter). Deze subsystemen worden opgenomen in de presentatie tier: Renderer

Presentation

Interpreter FIGUUR 13: PRESENTATIE TIER

3.3 Rollen en actoren Actoren zijn entiteiten die op een bepaalde, kenmerkende manier gebruikmaken van het systeem (een actor kan meerdere rollen hebben). Hieronder worden de voor WindexVIJF onderscheiden rollen besproken. Er worden rollen onderscheiden, omdat WindexVIJF binnen veel verschillende organisaties zal worden ingezet en het dus moeilijk is te spreken van actoren. Wel kunnen binnen de actoren groepen worden onderscheiden, welke op een kenmerkende manier gebruikmaken van WindexVIJF. Deze groepen vormen de basis van de rollen. GEBRUIKER

De gebruiker is de hoofdrol in WindexVIJF. Alle entiteiten zijn in ieder geval gebruikers.

INFORMATION MANAGER

De information manager beheert de informatie in WindexVIJF. Hij is verantwoordelijk voor het aanmaken, publiceren, muteren, wijzigen en verwijderen van hoofdobjecten. Een hoofdobject is bijvoorbeeld de registratie van een lid.

38


INFORMATION WORKER

De information worker gebruikt de hoofdobjecten, en is verantwoordelijk voor het aanmaken, publiceren, muteren, wijzigen en verwijderen van subobjecten bij de hoofdobjecten. Bij een hoofdobject als de registratie van een lid is een mogelijk subobject een factuur die aan het lid gestuurd is.

PARTNER

De partner is een externe partij die informatie levert aan het systeem, of aan hem beschikbaargestelde informatie raadpleegt.

BEZOEKER

De bezoeker kan alleen publiekelijk toegankelijk gemaakte informatie raadplegen.

LID

Het lid is een bijzondere bezoeker, en kan de informatie die over hem wordt bijgehouden wijzigen en acties ondernemen die resulteren in nieuwe informatie-objecten van het lid, zoals zich inschrijven voor bijeenkomsten.

VERENIGINGSFUNCTIONARIS

De verenigingsfunctionaris is een speciaal lid, dat objecten voor de vereniging kan aanmaken, publiceren, muteren, wijzigen en verwijderen.

BEHEERDER

De beheerder maakt geen gebruik van de functionaliteit van het systeem, maar configureert en onderhoudt het systeem. Het systeem houdt de beheerder op de hoogte van de systeemtoestand. Sommige rollen zijn specialisaties van andere rollen. De volgende figuur geeft een overzicht van de rollen en de onderlinge specialisatierelaties. De actoren en de hier onderkende rollen vormen een essentieel onderdeel van de referentie-architectuur en zullen later dienen als bron voor het opstellen van use cases en dergelijke. Daarnaast kan een architect er gebruik van maken als indicatie van belangrijke gebruikersgroepen binnen de stakeholders. Binnen deze opdracht zullen deze rollen echter niet verder gebruikt worden. Wel zullen de tiers en de hoofdfuncties daarbinnen verder verfijnd worden.

39


Gebruiker

Information manager

Information worker

Bezoeker

Beheerder

Partner

Lid

Verenigingsfunctionaris FIGUUR 14: OVERZICHT VAN DE ROLLEN EN SPECIALISATIES

4

Verfijning De referentie-architectuur is verfijnd tot het uiteindelijke raamwerk, door de subsystemen verder in te vullen.

4.1 Data tier DATA STORAGE

40

De kern van het Data Storage subsysteem van de data tier wordt gevormd door de functies die verantwoordelijk zijn voor het werkelijk opslaan van de gegevens. Deze kern is ingevat in het subsysteem Persistency Engine. Naast functies voor het opslaan van objecten, zijn er ook functies voor het ophalen van gegevens, die ondergebracht zijn in Data Retrieval. Tenslotte kan via query’s worden aangegeven wélke gegevens moeten worden opgehaald. Een Query Factory bevat deze functies.


Query Factory

Data Storage

Data Retrieval

Persistency Engine FIGUUR 15: VERFIJNING VAN DATA STORAGE

DATA ACCESS

Een technologie die op datastore-onafhankelijke wijze toegang verleent tot gegevens, is ADO.NET, de .NET opvolger van ActiveX Data Objects (ADO). ADO.NET doet dit door een Data Interface te definiëren en voor iedere datastore een specifieke implementatie van die interface in de vorm van een Data Adapter te gebruiken. Omdat in het raamwerk dezelfde flexibiliteit gewenst is, wordt dat ook hier toegepast.

Data Interface

Data Access

Data Adapter FIGUUR 16: VERFIJNING VAN DATA ACCESS

4.2 Platform tier ENTERPRISE INFORMATION MANAGEMENT

Enterprise Information Management handelt om de informatieobjecten in het systeem. Deze informatie-objecten zijn vaak organisatiespecifiek, en het is dan ook wenselijk organisatiespecifieke types te ondersteunen. De type-informatie van deze types (meta-informatie) wordt beheerd door de Meta Information Base. Een dynamisch systeem wordt verkregen als op executietijd nieuwe types aangemaakt kunnen worden. Deze functionaliteit is ondergebracht bij de Information Object Factory. Informatie-objecten worden ook opgeslagen en vaak is het wenselijk ook informatie over het opslaan bij te houden (in de vorm van een mutatielog bijvoorbeeld). In het subsysteem Information Object Repository kan deze functionaliteit worden ondergebracht. Tenslotte draait het binnen CRM ook om de analyse van de opgeslagen informatie. Dit wordt gedaan door de Analysis Engine.

41


Analysis Engine

Meta Information Base Enterprise Information Management Information Object Factory

Information Object Repository FIGUUR 17: VERFIJNING VAN ENTERPRISE INFORMATION MANAGEMENT

DOCUMENT BEHEER

Binnen documentbeheer draait het om 4 distinctieve taken: • tracking volgt documenten door de organisatie en is nodig om document flowing mogelijk te maken. • flowing maakt het mogelijk om paden te definiëren waarlangs documenten door het systeem reizen, op een procesgerichte manier. • versioning maakt het mogelijk om meerdere versies van één document in het systeem te kunnen hebben, terwijl het document tóch consistent blijft (dat wil zeggen dat altijd duidelijk is met welke versie gewerkt wordt). • collaboration maakt het mogelijk dat meerdere personen tegelijkertijd aan één document werken. Elk van deze taken wordt ingevat in een eigen subsysteem.

Document Collaboration

Document Versioning Document Beheer Document Tracking

Document Flow FIGUUR 18: VERFIJNING VAN DOCUMENT BEHEER

CONTENT MANAGEMENT

42

Bij het publiceren en beheren van content zijn er 3 belangrijke aandachtsgebieden. Ten eerste moet de content op een of andere manier gedefinieerd worden: welke delen van welke content worden getoond? Het subsysteem Content Delivery handelt dit af. Ten tweede moet de content op een bepaalde manier getoond worden,


bijvoorbeeld in de huisstijl van de organisatie. Hier zorgt de Styling Engine voor. Tenslotte moet er nog structuur worden aangebracht in de content. Structure Definition, het subsysteem uit de business logic tier, kan dit afhandelen. Content Delivery

Content Management

Styling Engine FIGUUR 19: VERFIJNING VAN CONTENT MANAGEMENT

4.3 Business Logic tier BUSINESS RULES

Ook Business Rules kan verfijnd worden. In weze zijn er hier drie taken. Ten eerste, het aanmaken van de rules. Dit wordt gedaan door de Business Rules Factory. Ten tweede, het analyseren van de rules. Dit wordt gedaan door de Business Analysis Engine. Tenslotte kunnen de rules nog opgeslagen worden met de Business Rules Repository. Business Analysis Engine

Business Rules

Business Rules Factory

Business Rules Repository FIGUUR 20: VERFIJNING VAN BUSINESS RULES

WORKFLOW

Workflow bestaat uit het definiëren van workflows, en het uitvoeren en volgen van workflows. De definitie van workflow wordt uitgevoerd door Workflow Definition, terwijl het uitvoeren en volgen gedaan wordt door Workflow Tracking. Document flow biedt ondersteuning voor aspecten van workflow die te maken hebben met bijvoorbeeld collaboratie op documenten. Workflow Tracking Workflow

Workflow Definition FIGUUR 21: VERFIJNING VAN WORKFLOW

43


4.4 Presentatie tier INTERPRETER

De Interpreter communiceert met subsystemen in de business logic tier om de informatie die aan de gebruiker gepresenteerd moet worden te verzamelen. Een subsysteem UI Definition wordt gebruikt om voorkeuren op te geven voor de opbouw van de presentatie, terwijl een subsysteem UI Builder wordt gebruikt om de specifieke presentatie te bouwen (die dan door de Renderer wordt omgezet in instructies voor de specifieke presentatieterminal). UI Builder

Interpreter

UI Definition FIGUUR 22: VERFIJNING VAN INTERPRETER

5

Conclusie Het hier gepresenteerde raamwerk identificeert de bouwblokken die van belang zijn voor WindexVIJF. Verdere invulling van deze bouwblokken zou moeten resulteren in een implementatie van WindexVIJF welke voldoet aan de functionele eisen en die de gebruikers ondersteunt bij hun bezigheden in de diverse rollen ten aanzien van WindexVIJF. Onbekend is echter nog, welke implicaties dit raamwerk heeft voor de te behalen schaalbaarheid en flexibiliteit. Om hierover tot uitspraken te komen, is een tweetal prototypes ontwikkeld, welke een dwarsdoorsnede van het raamwerk vormen. In Hoofdstuk 6 zullen deze beschreven worden.

44

Hoofdstuk 6: Prototype

H O O F D S T U K

6

Prototype Er zijn twee prototypes gemaakt: één om aan te tonen dat de architectuur te realiseren is en één om de flexibiliteit en schaalbaarheid te kunnen testen.

1

1e Prototype In het eerste prototype is een implementatie gemaakt van de Information Object Factory. De implementatie is gebaseerd op Reflection.Emit, een .NET technologie die het mogelijk maakt om op run-time nieuwe types te creëren.

1.1 Reflection.Emit .NET Reflection is een reflectietechnologie waarmee zowel op designals op run-time objecten geïnspecteerd kunnen worden. Binnen .NET zijn er twee technologieën die sterk gerelateerd zijn aan .NET Reflection: Reflection.Emit en CodeDOM. CodeDOM is de technologie waarmee .NET compilers worden gemaakt: met CodeDOM wordt sourcecode omgezet in Common Intermediate Language (CIL), de instructiecodetaal van .NET. Reflection.Emit genereert ook CIL, maar aan de hand van zogenaamde Builders voor assembly’s, types, fields, property’s en methoden. De zo gegenereerde assembly’s heten dynamisch en kunnen zowel direct gebruikt worden, als opgeslagen voor toekomstig gebruik.

1.2 Information Object Factory CREATEASSEMBLYBUILDER

Bij het aanmaken van een dynamisch type moet eerst een AssemblyBuilder worden gemaakt. Aan de constructor van de AssemblyBuilder worden de volgende parameters meegegeven: • AssemblyName, dit is de naam die de assembly moet krijgen • AssemblyBuilderAccess, dit geeft aan of de dynamische assembly kan worden opgeslagen, of uitgevoerd, of allebei. De hiermee gecreëerde AssemblyBuilder wordt vervolgens gebruikt voor het aanmaken van een module.

CREATEMODULEBUILDER

Het aanmaken van een module geschiedt met de methode CreateModuleBuilder. ModuleBuilders worden aangemaakt vanuit een AssemblyBuilder, middels de methode DefineDynamicModule. Aan deze methode worden de volgende parameters meegegeven: • ModuleName, dit is de de naam die de module moet krijgen • FileName, die is de naam van het bestand waarin de module wordt opgeslagen. Dit kan afwijken van de assembly, maar in het prototype wordt hetzelfde bestand gebruikt. Daarnaast kan nog worden aangegeven of symboolinformatie moet worden gegenereerd. De symboolinformatie is nodig bij het debuggen van de dynamische assembly. Het prototype maakt hier geen gebruik

45


van. In modules worden types aangemaakt, waarvoor de door DefineDynamicModule opgeleverd ModuleBuilder voor wordt gebruikt. CREATETYPEBUILDER

De methode DefineType van ModuleBuilder wordt gebruikt om TypeBuilders aan te maken. TypeBuilders leveren de werkelijke objecten op. Aan de methode worden de volgende parameters meegegeven: • TypeName, dit is de naam van het type • TypeAttrributes, hierin worden attributen van het type, zoals de toegangsopties (public/private/…) opgenomen. Andere parameters, zoals die om overerving of het implementeren van interfaces aan te geven, worden niet gebruikt in dit prototype. Met de TypeBuilder kunnen builders worden aangemaakt voor fields en methods.

PROPERTY’S

In het eerste prototype kunnen alleen properties worden aangemaakt. Intern worden deze echter aangemaakt in de vorm van een private field en een getter methode. Is de property niet read-only, dan wordt ook een setter methode aangemaakt. De property’s worden vervolgens gedefinieerd met de methode DefineProperty van TypeBuilder, welke de volgende parameters meekrijgt: • PropertyName, dit is de naam van de property • PropertyAttributes, hiermee kunnen speciale propertyeigenschappen worden gecodeerd. Er wordt hier geen gebruikgemaakt van speciale eigenschappen, dus wordt hier None meegegeven • PropertyType, dit is het type van de property • ReadOnly, dit geeft aan of de property alleen uitgelezen kan worden • ParameterTypes, dit is een lijst van types welke meegegeven moeten worden met de setter (indien aanwezig)

FIELDS

Fields worden aangemaakt met de methode DefineField, welke de volgende parameters meekrijgt: • FieldName, dit is de naam van het field • FieldType, dit is het type van het field • FieldAttributes, dit zijn de eigenschappen van het field. In dit prototype is alleen gebruikgemaakt van Private om aan te geven dat van buiten de assembly geen toegang mag worden gegeven tot het field.

METHODS

Methods tenslotte worden aangemaakt met de methode DefineMethod. Hieraan worden de volgende parameter meegegeven: • MethodName, dit is de naam van de methode. Voor setters wordt “set_” + PropertyName gebruikt, voor getters “get_” + PropertyName • MethodAttributes, om attributen aan te geven. De volgende attributen worden in dit prototype gebruikt: o Public, omdat de methode van buiten de assembly aangeroepen moet kunnen worden door talen die geen property’s ondersteunen o HideBySig, omdat de methode verborgen moet worden als de property getoond kan worden o SpecialName, omdat de methode een setter of getter is.

46


•

MethodType, dit geeft het returntype van de methode aan. Voor de getter is dit PropertyType, voor de setter void • ParameterTypes. een lijst van types. Voor de setter is dit PropertyType, voor de getter een lege lijst. De body van een methode bestaat uit CIL, welke gegenereerd wordt aan de hand van zogenaamde OpCodes (een “vertaling” van de eigenlijke CIL codes) door de ILGenerator. De ILGenerator wordt verkregen met de methode GetILGenerator van MethodBuilder. GETTER/SETTER

De getter en de setter zijn te realiseren met 1, respectievelijk 2 OpCodes. De getter hoeft alleen de waarde van de property op de stack (de plaats in het geheugen waar de code terechtkomt) te zetten middels de OpCode ldfld. De setter moet de nieuwe waarde op de stack laden met ldarg_1 en deze opslaan als de nieuwe waarde van de property met stfld. De laatste stap is het registreren van de getter en de setter bij de property. Dit wordt gedaan door de methodes SetSetMethod en SetGetMethod van PropertyBuilder.

CREATEDYNAMICTYPE

CreateDynamicType is het verzamelpunt van al deze methodes en wordt aangeroepen om types te maken. Hiertoe wordt aan de methode de volgende parameters meegegeven: • AssemblyName, de naam van de assembly • ModuleName, de naam van de module • TypeName, de naam van het type • TypeData, een DataSet met daarin een DataTable Property waarin de property’s staan gedefinieerd in termen van de naam, het type en een indicatie van of de property read-only is Naast de property’s, maakt CreateDynamicType ook een Main methode aan, zodat de dynamische assembly’s uitgevoerd kunnen worden. Dit heeft alleen betekenis voor het prototype, omdat de dynamische types binnen het systeem als bibliotheken moeten worden gebruikt, niet als executables.

1.3 TestSuite Tijdens het eerste prototype is ook een testapplicatie voor de DynamicObjectFactory geschreven. Deze TestSuite is gebaseerd op .NET Reflection en bouwt dynamische interfaces voor .NET assembly’s. Reflectie wordt gebruikt om type-informatie en field-, property- en methode-informatie uit te lezen. Deze informatie wordt omgezet in interface-elementen. In deze interfaces zijn fields en property’s uit te lezen en te voorzien van een nieuwe waarde (met uitzondering van de read-only property’s uiteraard) en zijn methodes aan te roepen. Voor de invoer van waarden wordt gebruikgemaakt van standaard interface-elemeten, zoals een TextBox, een DatePicker en een CheckBox. Bij een beperkte set types wordt zo een passend interface-element gegenereerd. Hoewel de TestSuite meer als experiment met .NET Reflection is gebruikt, leverde het ook meteen een grafische front-end voor de DynamicObjectFactory en een inspectie-omgeving voor de met de DynamicObjectFactory gegenereerde dynamische types op.

47


1.4 Vervolg Het eerste prototype had een sterk experimenteel karakter. Wil het prototype beter toepasbaar worden, dan zijn er een aantal volgende stappen: • Allereerst moet de DynamicObjectFactory uitgebreid worden met ondersteuning van fields en methodes. Bij methodes komt hier een extra uitdaging bij kijken, namelijk de specificatie van de method body’s. Dit kan opgelost worden met templates, via CodeDOM, of met een speciale CIL parser. • Daarnaast is het noodzakelijk de code robuuster te maken. Er moeten meer controles worden uitgevoerd, vooral op de invoer. • De TestSuite zou verder uitgebreid moeten worden met ondersteuning voor meer types. Als in ieder geval alle basistypes een eigen interface-element krijgen, kan via cascadering bijna ieder type aangemaakt worden vanuit de interface. • Door een slechte koppeling tussen methodes, hun parametervelden en hun returnveld, is het nu zo dat de returnwaarde ook in alle parametervelden terechtkomt. In een volgende stap zou dit ook opgelost moeten worden. • Ook zou de TestSuite sneller gemaakt kunnen worden. Interfaces voor uitgebreide types genereren duurt erg lang, en ondertussen bevriest de interface. Door de interface op te delen zouden de aparte delen ook apart gegenereerd kunnen worden, waardoor de interface sneller zou “ontdooien”. • TestSuite genereert in de eerste slag interfaces die netjes uitgelijnd worden. Als de interface nu echter opnieuw opgebouwd moet worden (bijvoorbeeld omdat het hoofdvenster geresized wordt), verandert de lay-out in een flow lay-out en worden alle elementen achterelkaar gezet. Dit zou in een volgende stap netter gedaan kunnen worden. • De TestSuite zou verder uitgebreid kunnen worden met een koppeling met het bestandssysteem (zodat een directory waarin gezocht moet worden naar assembly’s geselecteerd kan worden). • In algemene zin kan dit prototype verder uitgebreid worden door deze te ontsluiten via XML Web Services of .NET Remoting. • Ook kan, in het kader van “opschoning”, het prototype gerefactored worden naar design patterns.

2

2e Prototype In het tweede prototype is een verticale kolom uit de architectuur geïmplementeerd. Dit prototype is daarna gebruikt tijdens de tests en de metingen om de schaalbaarheid te meten en te kijken waar het prototype flexibel is ten opzichte van Windex 4.

48


2.1 Specificatie Omdat niet de gehele architectuur, maar een verticale kolom daaruit geïmplementeerd is in dit tweede prototype, wordt eerst de specificatie van het prototype gegeven.

Data tier In de architectuur is de data tier als volgt gedefinieerd: Data Interface

Data Access

Data Adapter Data Query Factory

Data Storage

Data Retrieval

Persistency Engine FIGUUR 23: DATA TIER SPECIFICATIE

In dit prototype wordt de data tier geconcretiseerd. DATA INTERFACE

De Data Interface definieert de functies die een implementatie van het Data Storage systeem minstens moet ondersteunen wil deze geschikt zijn voor WindexVIJF. Deze functies vallen uiteen in vijf types: create, retrieve, update en delete (CRUD) en search. Create functies maken nieuwe gegevensobjecten aan in het Data Storage systeem (de data store). Omdat dergelijke objecten geïdentificeerd moeten kunnen worden, is het denkbaar dat de data store een ID oplevert, of dat een ID meegegeven kan worden. Retrieve functies halen gegevensobjecten op uit de data store. Dit kan selectief, waarbij een ID van een gegevensobject wordt meegegeven of een ander kenmerk wordt aangegeven zoals een type, of collectief, waarbij alle gegevensobjecten worden opgeleverd. In dit prototype wordt bij een collectieve retrieval een lijst met ID’s opgeleverd. Update functies vervangen gegevensobjecten in de data store door nieuwere gegevensobjecten. Dit kan door het gehele gegevensobject te vervangen, maar een efficiëntere aanpak kan zijn om alleen de waarde van een veld van een gegevensobject te vervangen. Omdat deze functie niets anders oplevert, kan een boolean waarde worden opgeleverd die aangeeft of de operatie succesvol is geweest.

49


Delete functies verwijderen gegevensobjecten uit de data store. Voor dit prototype volstaat het als het mogelijk is om selectief een gegevensobject te verwijderen. Net als bij update is het ook hier mogelijk een boolean waarde op te leveren om het succes aan te geven. Search functies worden gebruikt om op een gegeven set kenmerken corresponderende gegevensobjecten te zoeken. Dit prototype biedt hiervoor geen ondersteuning. DATA ADAPTER

De Data Adapter is een implementatie van de Data Interface. In dit prototype worden twee implementaties gemaakt: één die het file system als data store gebruikt, en één die het geheugen als data store gebruikt. Deze zijn beide vrij eenvoudig te implementeren, omdat serialisatie van objecten voor het file system en een in-memory hashtable voor het geheugen volstaan als data store. Uiteindelijk echter zal er ook een Data Adapter voor SQL Server moeten worden gemaakt.

DATA ADAPTER FACTORY

De Data Adapter beheert de toegang tot de data store. Om synchroniciteitsproblemen te voorkomen, mag er dus hooguit één instantie van de Data Adapter actief zijn in het systeem (tenzij de synchroniciteit en consistentie van de data store expliciet worden gewaarborgd, maar dat valt buiten het bereik van dit prototype). De Data Adapter Factory zorgt hiervoor. De Data Adapter Factory is een statisch type dat Data Adapters aanmaakt. Via een configuratiebestand (data.config) kan worden aangegeven welke Data Adapter standaard moet worden aangemaakt. Daarnaast is het wenselijk expliciet aan te kunnen geven welke adapter moet worden aangemaakt, zonder dat dit via het configuratiebestand gaat. Het complete UML schema voor de data tier in dit prototype wordt daarmee:

50


51


Platform tier In de architectuur is de platform tier als volgt gedefinieerd: Document Collaboration

Document Versioning Document Beheer Document Tracking

Content Delivery Platform

Document Flow

Content Management Analysis Engine

Styling Engine Meta Information Base Enterprise Information Management Information Object Factory

Information Object Repository FIGUUR 24: DE PLATFORM TIER IN DE ARCHITECTUUR

In dit prototype zal het Enterprise subsysteem worden geïmplementeerd.

Information

Management

META TYPE BASE

De Meta Type Base is de implementatie van de Meta Information Base. Hier worden de objecten op metaniveau beschreven. De Object Management Group (OMG) heeft hiervoor een standaard, de Meta Object Facility (MOF). Probleem van de MOF is dat de MOF geen directe ondersteuning biedt voor property’s. Daarnaast is de MOF een erg uitgebreide specificatie die veel verder gaat dan het bereik van dit prototype (zo kunnen zaken als overerving, implementatie van interfaces, inter-object relaties, et cetera ook worden gespecificeerd). Mede daarom is gekozen voor een eenvoudige, eigen oplossing voor dit prototype.

TYPEBESCHRIJVINGEN

Typebeschrijvingen bestaan uit een naam voor de assembly, en collecties field-, property- en methodbeschrijvingen. Een beschrijving van een field bestaat uit een naam, een type, een initiële waarde en een multipliciteit (voor arrays). Een beschrijving van een property bestaat uit een naam, een type, een initiële waarde en twee boolean waarden die aangeven of de property kan worden gelezen en of de property kan worden geschreven. Beschrijvingen van methodes bestaan uit een naam, een returntype, een body en een collectie

52


paramaterbeschrijvingen. Een beschrijving van een parameter bestaat uit een type en een naam. Al deze gegevens worden opgenomen in een gespecialiseerde DataSet en kunnen daardoor in XML gecodeerd weggeschreven worden. ACTIES

De Meta Type Base ondersteunt een vijftal acties. Naast de gangbare CRUD acties kan ook nog een lijst met alle assemblynamen van types in de Meta Type Base worden opgevraagd.

UML SCHEMA

De Meta Type Base is gedefinieerd volgens het volgende UML schema:

FIGUUR 25: UML SCHEMA VAN DE META TYPE BASE

OBJECT FACTORY

De Object Factory is de implementatie van de Information Object Factory en een refactoring van de factory uit het eerste prototype. De gegenereerde objecten zijn uitgebreid met een methode ToString(), welke het object vertaalt naar een stringrepresentatie. Het UML schema ziet er als volgt uit:

FIGUUR 26: UML SCHEMA VAN DE OBJECT FACTORY

OBJECT REPOSITORY

De Object Repository is de implementatie van de Information Object Repository en is een decorator van de Data Interface. Naast de Object Repository is er ook een Meta Object Base, waarin informatie over de opgeslagen objecten uit de repository wordt opgeslagen. De Information Object Repository is uitgebreid met een functie die de informatie uit deze Meta Object Base oplevert. De Object Repository kent een expliciete destructor, waarmee de Meta Object Base weggeschreven wordt. Omdat verder ook de uniciteit van de Object Repository gewaarborgd moet worden, wordt ook deze aangemaakt met een statische factory, de Object Repository Factory.

META OBJECT BASE

De Meta Object Base wordt gebruikt voor informatie over de opgeslagen objecten. De informatie die wordt bijgehouden bestaat uit het ID dat het object heeft gekregen, de eigenaar van het object (de huidige gebruiker), de assemblynaam van het object en de data waarop het object aangemaakt, aangepast en verwijderd is. Verwijderde objecten blijven dus geregistreerd.

UML SCHEMA

Dit resulteert in het volgende UML schema:

53


FIGUUR 27: UML SCHEMA VAN DE OBJECT REPOSITORY

Business Logic In de architectuur is de business logic tier als volgt gedefinieerd:

Business Analysis Engine

Business Rules

Business Rules Factory

Business Rules Repository Business logic

Structure Definition

Workflow Tracking Workflow

Workflow Definition FIGUUR 28: DE BUSINESS LOGIC TIER IN DE ARCHITECTUUR

In dit prototype is het Business Rules subsysteem geïmplementeerd. RULE REPOSITORY

54

In de Rule Repository worden Rules, Actions, Conditions en Expressions opgeslagen, opgehaald of verwijderd. De Rule Repository maakt hiertoe gebruik van de Object Repository. Het volgende UML schema geeft de specificatie van de Rule Repository:


FIGUUR 29: UML SCHEMA VAN DE RULE REPOSITORY

RULES FACTORY

In de Rules Factory worden Rules, Actions, Conditions en Expressions aangemaakt. Het volgende UML schema geeft de specificatie van de Rules Factory:

FIGUUR 30: UML SCHEMA VAN DE RULES FACTORY

EXPRESSION

Het basisobject van een business rule is een expressie. De interface IExpression is de algemene definitie van een expressie. Iedere expressie heeft een type, een waarde en een stringrepresentatie. Er zijn drie soorten expressies: constante expressies, variabele expressies (constante expressies met een naam en een waarde die aangepast kan worden) en functie-expressies. Een functie-expressie bevat een MethodInfo object, een .NET Reflection object waarin methode-informatie wordt opgeslagen. Niet alleen methodes, maar ook fields en property’s kunnen in een functie-expressie gevat worden. Hiervoor wordt gebruikgemaakt van dubbele reflectie: fieldinformatie en property-informatie worden opgeslagen in respectievelijk FieldInfo en PropertyInfo objecten. Beiden kennen de methode GetValue, welke de waarde van respectievelijk het field of de property oplevert. Deze methode wordt gereflecteerd in een MethodInfo object, dat gebruikt wordt voor de functie-expressie. Onderstaand UML schema geeft de specificatie van expressies in het prototype:

55


FIGUUR 31: UML SCHEMA VAN IEXPRESSION

CONDITION

Door twee expressie met elkaar te vergelijken, ontstaat een conditie. In dit prototype is een lijst mogelijke vergelijkers gedefinieerd. Onderstaand UML schema geeft de specificatie van condities in het prototype:

FIGUUR 32: UML SCHEMA VAN CONDITION

ACTION

56

Op basis van de evalutatie van een of meerdere condities, kunnen acties worden ondernomen. Een actie kan gecreëerd worden door een methode te selecteren in een informatie-object, maar er kunnen ook “helper-types” gemaakt worden waarin acties worden opgenomen, zoals het sturen van een e-mail. Een actie bestaat uit de informatie over deze methode (een MethodInfo object) en een lijst parameters. Daartoe zijn de objecten ParameterCollection, CollectionEnumerator en Parameter gecreëerd. Parameter is een decorator van het .NET Reflection type ParameterInfo, die het makkelijker maakt om met ParameterInfo-objecten te werken. Het volgende UML schema geeft de specificatie van acties weer:


FIGUUR 33: UML SCHEMA VAN ACTION

RULE

Een rule bestaat uit een set condities en een set acties. Deze worden in het prototype gesymboliseerd door een ActionCollection en een ConditionCollection. Hoe de condities in een set condities worden geëvalueerd ten opzichte van elkaar, kan nog worden aangegeven met een boolean operator. Onderstaand UML schema geeft de specificatie van Rule:

FIGUUR 34: UML SCHEMA VAN RULE

RULES ENGINE

De Rules Engine evalueert rules op basis van een Knowledge Base. Rules kunnen op verschillende manieren geëvalueerd worden. Het is dan ook denkbaar dat meerdere engines zullen worden ontwikkeld; een interface voor Rules Engines is dan ook nuttig.

57


KNOWLEDGE BASE

Een Knowledge Base is een repository voor informatie-objecten (kennis). Een Knowledge Base kan gebruikt worden om een business rule slechts op een selectie van de informatie-objecten in het systeem uit te voeren.

UML SCHEMA

De Rules Engine en de Knowledge Base worden als volgt gemodelleerd in UML:

FIGUUR 35: UML SCHEMA VAN RULES ENGINE

Presentatie In WindexVIJF zal de presentatie tier geïmplementeerd worden in de vorm van Web Forms die met een browser worden bekeken. Het valt buiten het bereik van de doctoraalopdracht en dit prototype om hier een implementatie van te geven. Zeker aangezien de voorgestelde scheiding van de tiers het onmogelijk zou maken om de presentatie dicht tegen het prototype aan te programmeren, is gekozen voor een implementatie van de presentatie tier die niet voldoet aan de architectuur. De presentatie tier bestaat uit Windows Forms en is zeer dicht tegen de verschillende objecten aan geprogrammeerd. Windows Forms werken met GDI+ (en de Win32 API’s) en bieden zo een veel uitgebreidere set widgets (interface-elementen), dan de Web Forms, die vertaald moeten worden naar HTML.

2.2 Beperkingen Het prototype is precies dat, een prototype. Dat betekent dat er beperkingen zijn, zoals stukken functionaliteit die missen, ongelukkige implementaties, of een lagere algehele kwaliteit. Door deze beperkingen expliciet te maken, wordt ook meteen duidelijk waar nog aan gewerkt moet worden voordat het prototype een meer definitief karakter kan krijgen.

Data tier beperkingen Het prototype bevat voor twee data stores een Data Adapter: voor het geheugen, en voor het file system. De adapter voor het geheugen kan alle objecten opslaan, maar is wel volatile. Dat wil zeggen dat als de applicatie wordt afgesloten, alle gegevens verloren gaan. Daarnaast is

58


het bij grote sets gegevens niet langer werkbaar, omdat het systeemgeheugen dan volloopt. Ook de adapter voor het filesystem kent zijn beperkingen. De drie vormen van serialisatie die door .NET worden geboden (XML, SOAP en binair) zijn geen van allen in staat om zondermeer alle objecten te serialiseren. Voor sommige types moet de serializer expliciet verteld worden hoe een object geserialiseerd moet worden. Het prototype doet dit niet. WindexVIJF zal gebruikmaken van SQL Server als data store. Hoewel bij wijze van test (zie volgend hoofdstuk) een SQL Data Adapter is geschreven, is dit eigenlijk een kopie van de file system adapter, die alleen de geserialiseerde objecten niet naar het file system, maar naar de database wegschrijft. Voor WIndexVIJF is het noodzakelijk om objecten te vertalen naar relationele schema’s. Ook dit is geen onderdeel van het prototype.

Platform tier beperkingen De Object Factory ondersteunt geen fields en methods. Voor fields is geen implementatie gegeven omdat het definiëren van arrays via Reflection.Emit niet bestudeerd is en fields verder geen andere functionaliteit bieden dan read/write property’s. Voor methods is geen implementatie gegeven, omdat geen intuïtieve manier voor het specificeren van method body’s (met daarbij de vertaling naar CIL OpCodes) bedacht is. Beiden zijn noodzakelijk om uiteindelijk echte objecten aan te maken. Het in het prototype gebruikte schema voor de definitie van types is beperkt, maar dit is bewust gekozen. Voor WindexVIJF zou het beter zijn de Meta Object Facility nader te bestuderen.

Business Logic tier beperkingen Business Rules met missende informatie worden nu nog gebrekking geëvalueerd. Acties en condities met objecten die pas op run-time bekend zijn, kunnen zo niet goed gebruikt worden. Dit is een ernstige tekortkoming, juist omdat rules op een meer flexibele en onafhankelijke manier gebruikt zouden moeten kunnen worden.

3

Conclusie Hiermee zijn de prototypes afgerond; er is een beperkte set functionaliteit geïmplementeerd, waarmee enerzijds de haalbaarheid van het raamwerk is aangetoond en anderzijds een mogelijkheid voor het testen en meten van de schaalbaarheid en flexibiliteit is gecreëerd. Met de in deze prototypes geïmplementeerde functionaliteit is tevens de basis gelegd voor WindexVIJF ten aanzien van de datataken en de business rules. In dit hoofdstuk is een aantal beperkingen genoemd van deze basis. Als deze beperkingen zijn opgelost, kan deze basis ingezet worden voor de realisatie van WindexVIJF.

59


60

Hoofdstuk 7: Tests en metingen aan het prototype

H O O F D S T U K

7

Tests en metingen aan het prototype Het tweede prototype uit het vorige hoofdstuk is gebruikt om een aantal tests en metingen mee te doen. In dit hoofdstuk zullen deze tests en metingen beschreven worden. In sectie 1 worden een aantal aandachtspunten ten aanzien van schaalbaarheid en flexibiliteit beschreven, welke in sectie 2 worden uitgeschreven tot doelstellingen. In sectie 3 worden daar wenselijke eigenschappen aan toegevoegd. In sectie 4 worden de gedane metingen en tests beschreven. Sectie 5 beschrijft een aantal technieken voor het verbeteren van de schaalbaarheid en de flexibiliteit. Dit hoofdstuk wordt afgesloten met een aantal conclusies en aanbevelingen.

1

Aandachtspunten Schaalbaarheid en flexibiliteit zijn moeilijk kwantificeerbare eigenschappen en manifesteren zich vooral in een aantal gedragseigenschappen. In deze sectie zullen een aantal aandachtspunten met betrekking tot schaalbaarheid en flexibiliteit besproken worden. Als deze aandachtspunten worden meegenomen in het ontwerp en de tests, kan men vaststellen of een systeem daadwerkelijk schaalbaar en flexibel mag heten.

1.1 Schaalbaarheid De performance van een systeem hangt nauw samen met schaalbaarheid van het systeem. Van schaalbaarheid is sprake, de performance niet significant daalt als het aantal gebruikers, aantal gegevenselementen, de afstand tussen nodes toeneemt of aantal administratieve organisaties toeneemt.

de als het het

Een eerste aandachtspunt is daarmee het aantal gebruikers. Hier zijn een aantal factoren van belang: het aantal actieve gebruikers dat gelijktijdig ondersteund wordt, het aantal actieve gebruikers dat opgenomen kan worden in een wachtrij en de gemiddelde wachttijd in de wachtrij. Daarnaast is het nog raadzaam te kijken naar de stijging in de behoefte aan systeembronnen (zoals processorkracht, geheugen en harde-schijf-ruimte) naarmate het aantal gebruikers stijgt. Een tweede aandachtspunt zijn de gegevenselementen. Ook deze hebben een directe impact op de performance, omdat het aantal gegevenselementen in het systeem gevolgen kan hebben voor de tijd die het kost om objecten aan te maken, op te halen, te wijzigen, te verwijderen of te zoeken. Er zijn ook gevolgen voor de behoefte aan systeembronnen.

61


Het aantal administratieve taken en organisaties binnen een systeem groeit met het systeem. Het is daarom belangrijk te kijken naar welke administratieve taken er binnen het systeem zijn, welke organisaties een eigen administratie willen of moeten voeren en hoe een balans gevonden kan worden tussen enerzijds centralisering en anderzijds decentralisering van de administratieve verantwoordelijkheden. Replicatie en distributie zijn veelgebruikte strategieën om de schaalbaarheid van een systeem te vergroten, die ook de aandacht verdienen in dit kader. De mogelijkheden hiervoor worden vergroot als hiermee al vroeg in de ontwikkeling van het systeem rekening wordt gehouden. Het is daarom belangrijk te kijken naar eventuele kandidaatsubsystemen voor replicatie en distributie. Ook kan gekeken worden of subsystemen verder onderverdeeld kunnen worden om de mogelijkheden voor replicatie en distributie te vergroten. Verder is het belangrijk te weten welke invloed de verschillende distributiestrategieën hebben op de servicetijd van gedistribueerde subsystemen. Tenslotte, hoe beïnvloedt de overhead die door replicatie en distributie wordt veroorzaakt de performance van het systeem?

1.2 Flexibiliteit Flexibiliteit draait om (on)afhankelijkheid. Afhankelijkheden beperken de configureerbaarheid van een systeem, omdat het systeem ten aanzien van een afhankelijkheid niet aangepast kan worden. Indien een systeem bijvoorbeeld afhankelijk is van een besturingssysteem, is het niet mogelijk dat systeem zo aan te passen dat het op een ander besturingssysteem draait. Om vast te stellen of een systeem flexibel is, of om flexibiliteit in een systeem te waarborgen, moet dus gekeken worden naar de afhankelijkheden van het systeem. Een eerste aandachtspunt zijn dan de grenzen van het systeem. Het systeem doet alleen uitspraken over wat er binnen deze grenzen ligt. Dit betekent dat het systeem in principe flexibel is ten aanzien van alles wat buiten de grenzen van het systeem valt. Binnen de grenzen van het systeem kan nog gekeken worden of de uitspraken noodzakelijk zijn. Onnodige uitspraken kunnen ontstaan als beperkende voorwaarden worden opgelegd, welke niet worden opgelegd door het systeem zelf. In het geval van .NET applicaties kan de aanwezigheid van Windows een eis zijn, maar als de applicatie voldoet aan de ECMA specificaties, zou het ook mogelijk moeten zijn om de applicatie te gebruiken op bijvoorbeeld het Mono18 platform onder Linux. Op de grenzen van het systeem vindt communicatie plaats met de buitenwereld. Dit is een tweede aandachtspunt. Eigen communicatieprotocollen doen zwaardere uitspraken over de omgeving dan (open) standaarden. Om de flexibiliteit te verbeteren kan dus gekeken worden of er communicatieprotocollen vervangen kunnen worden door gestandaardiseerde (open) alternatieven. Ook kan communicatie vastgelegd worden in een interface. Omdat de 18

Mono is een open source implementatie van de ECMA specificaties voor .NET. Zie voor meer informatie http://www.go-mono.org.

62


afhankelijkheden dan beperkt worden tot de interface, kan gecommuniceerd worden met alle systemen die die interface implementeren. Daarnaast kan nog interne flexibiliteit geïntroduceerd worden. Door subsystemen te definiëren in termen van interfaces, kunnen subsystemen vervangen worden door willekeurige andere implementaties van dezelfde interfaces. Zo kunnen eigen oplossingen geïntroduceerd worden als externe oplossingen wegvallen, of juist externe oplossingen worden geïntroduceerd als de eigen oplossing het laat afweten. Een flexibel systeem is flexibel in de configuratie, zodat deze kan worden aangepast aan zijn omgeving. Herconfigureerbaarheid wordt bereikt als het systeem kan worden aangepast aan veranderingen in de omgeving. Hiervoor moet het systeem geïnspecteerd kunnen worden, of zichzelf moeten kunnen inspecteren (via reflectie). Ook hier geldt dat door in een vroeg stadium al rekening te houden met de eisen die configureerbaarheid en herconfigureerbaarheid met zich meebrengen, de effectiviteit van deze strategieën voor flexibiliteit wordt verhoogd.

1.3 Overzicht aandachtspunten Hieronder volgt een overzicht van de onderkende aandachtspunten: • Het aantal gebruikers o Hoeveel actieve gebruikers worden gelijktijdig ondersteund? o Hoeveel actieve gebruikers kunnen opgenomen worden in een wachtrij? o Wat is de gemiddelde wachttijd in een wachtrij? o Hoe verandert de behoefte aan systeembronnen naarmate het aantal gebruikers stijgt? • Het aantal gegevenselementen o Hoe verandert de tijd die het kost om elementen te bewerken in verhouding tot de stijging in het aantal elementen? o Hoe verandert de behoefte aan systeembronnen ten aanzien van het aantal gegevenselementen? • Administratieve taken en organisaties o Welke zijn de administratieve taken? o Welke organisaties willen of moeten een eigen administratie voeren? o Hoe kan een balans gevonden worden tussen centralisering en decentralisering van de administratieve verantwoordelijkheid? • Replicatie en distributie o Welke subsystemen zijn kandidaat voor replicatie en distributie? o Waar kunnen extra scheidingen aangebracht worden om de mogelijkheden voor replicatie en distributie te vergroten?

63


Welke invloed hebben diverse distributiestrategieën op de servicetijd van gedistribueerde subsystemen? o Wat is de impact van de door replicatie en distributie geïntroduceerde overhead op de performance van het systeem? De grenzen van het systeem o Waarover doet het systeem uitspraken, waarvan is het systeem afhankelijk? o Zijn er uitspraken die onnodig zijn? Communicatie met de buitenwereld o Kunnen eigen communicatieprotocollen vervangen worden door (open) standaarden? o Zijn er mogelijkheden om communicatie in een interface te vatten? Interne communicatie o Is het mogelijk subsystemen vast te leggen in termen van interfaces? Configureerbaarheid en herconfigureerbaarheid o Kan het systeem aangepast worden aan zijn omgeving? o Kan het systeem geïnspecteerd worden, of is het systeem in staat zichzelf te inspecteren? o Kunnen op basis van de systeemtoestand en veranderingen in de omgeving veranderingen in de configuratie van het systeem worden aangebracht? o

•

•

• •

2

Doelstellingen Schaalbaarheid en flexibiliteit zijn geen Heilige Gralen, en komen met een prijs. Dat betekent dat er enerzijds grenzen zijn aan de te behalen winsten met schaalbaarheid en flexibiliteit, en anderzijds offers gebracht moeten worden voordat deze winsten genoten kunnen worden. De grens van wat haalbaar is met schaalbaarheid en flexibiliteit is sterk afhankelijk van het systeem zelf en is vaak niet via een eenvoudige formule af te leiden uit de systeemdefinitie. Extrapolatie van resultaten van tests van delen van het systeem kunnen echter dienen ter indicatie van de grens. Ligt de grens beneden wat wenselijk is, dan zal het systeem herontworpen moeten worden. Aan de andere kant komen schaalbaarheid en flexibiliteit met een prijs. Ze maken het systeem complexer, wat zijn tol vergt van de architecten, de ontwerpers, de programmeurs en het onderhoudspersoneel. Zij zullen minder makkelijk een goed inzicht kunnen ontwikkelen in het systeem, terwijl dit harder nodig is; anders presteert het systeem ondermaats. Ook introduceren schaalbaarheid en flexibiliteit overhead: replica’s vergen consistentiemechanismes, load-balancers, replicatiemechanismen, et cetera. Systeemmonitors vergen systeembronnen die ook door het systeem gebruikt hadden kunnen worden. Als willekeurig maatregelen voor verhoging van schaalbaarheid en flexibiliteit worden doorgevoerd, kan deze

64


overhead er zelfs voor zorgen dat de performance achteruitgaat in plaats van vooruit. Het is dus zaak om een balans te zoeken tussen de kosten van het doorvoeren van maatregelen voor de verhoging van schaalbaarheid en flexibiliteit en de te behalen winsten. Daarnaast moet duidelijk gesteld worden wat haalbaar is. Hierdoor ontstaan grenzen. Binnen deze grenzen voldoet het systeem aan de stakeholdereisen, daarbuiten wordt niets gegarandeerd. De grenzen worden bepaald door doelen te stellen.

2.1 Schaalbaarheid Doelen kunnen gesteld worden aan de hand van kwantificeerbare aspecten. Deze kwantificeerbare aspecten volgen uit de 3 dimensies van schaalbaarheid. Het aantal gebruikers van een systeem is het eerste kwantificeerbare aspect. Er zijn twee getallen te onderscheiden: het aantal gebruikers dat geregistreerd moet kunnen staan, en het aantal gebruikers dat gelijktijdig gebruik moete kunnen maken van het systeem. Deze getallen kennen een minimum, een maximum, een gemiddelde, een afwijking en een betrouwbaarheid. Het aantal elementen in een systeem kan net als het aantal gebruikers opgesplitst worden in twee getallen: het totale aantal elementen, en het aantal elementen dat een gebruiker gelijktijdig in gebruik heeft. Ook hier worden een minimum, maximum, gemiddelde, afwijking en betrouwbaarheid geregistreerd. De tweede dimensie van schaalbaarheid is de afstand tussen de nodes. Hoewel dit bij betrouwbaarheid inderdaad vaak fysieke afstand is, is het bij schaalbaarheid beter te spreken van afstand in tijd: deze is meer afhankelijk van de benodigde communicatie tussen twee nodes, dan de afstand daartussen. Hier worden ook een minimum, maximum, gemiddelde, afwijking en betrouw-baarheid genoteerd. De derde dimensie is die van de administratieve taken. Ook deze kunnen uitgedrukt worden in minimum, maximum, gemiddelde, afwijking en betrouwbaarheid. Bij deze getallen is het minimum een indicator van welke overhead acceptabel is: als bij een aantal minder dan het minimum de overhead de performance tezeer naar beneden haalt, dan is dit niet erg. Het maximum doet hetzelfde, maar dan voor de bovengrens van de schaalbaarheid. Het gemiddelde is een verwachting: bij dit aantal zijn de prestaties liefst optimaal. De afwijking en de betrouwbaarheid zijn indicatoren voor hoe zwaar de getallen wegen. Onbetrouwbare getallen met een grote afwijking zijn slechte indicatoren, terwijl zeer betrouwbare getallen met een kleine afwijking juist goede indicatoren zijn. Alle getallen bijelkaar leiden tot een set van kwantificeerbare aspecten en kwantificaties. Analyse van deze set (bijvoorbeeld via statistische toetsen) kan gebruikt worden als toetsing van het systeem.

65


2.2 Flexibiliteit Flexibiliteit is een meer kwalitatieve dan kwantitatieve eigenschap. Het is dus ook niet makkelijk flexibiliteit te meten. Wel kan gekeken worden naar raakvlakken van het systeem. Over deze raakvlakken kunnen dan uitspraken gedaan worden ten aanzien van de flexibiliteit. Software draait bijna altijd op een besturingssysteem. Dat besturingssysteem is zo’n raakvlak dat de flexibiliteit beïnvloedt. Toch blijkt dan meteen dat duidelijke definities nodig zijn waar het flexibiliteit aangaat. Is een systeem flexibel ten opzichte van het besturingssysteem als het op meerdere besturingssystemen werkt, als het voor meerdere geschikt gemaakt kan worden, of pas als het alle besturingssystemen ondersteunt? Een ander raakvlak wordt gevormd door externe services. Externe services zijn services zoals Internettoegang of e-mail. Flexibiliteit betekent hier dat makkelijk van leverancier van externe services gewisseld kan worden. Systeembronnen vormen een ander raakvlak. Flexibiliteit ten aanzien van systeembronnen betekent dat het systeem ge(her)configureerd kan worden om optimaal gebruik te maken van de beschikbare systeembronnen. Tenslotte zijn er nog veel interne raakvlakken zoals persistentieopties, presentatie-opties, uitwisselbare componenten, gebruikersvoorkeuren, applicatie-inrichting, et cetera. Flexibiliteit ten aanzien van deze interne raakvlakken betekent dat het systeem niet gebonden is aan één instelling. Ten opzichte van persistentie-opties kan bijvoorbeeld gedacht worden aan het prototype, waarin de keuze van datastore in principe onbeperkt is, mits een goede adapter geschreven wordt. Omdat flexibiliteit meer kwalitatief dan kwantitatief is, is het belangrijk dat duidelijke doelen gesteld worden. Er moeten duidelijke specificaties komen van waar flexibiliteit verwacht wordt, in welke mate en op welke manier. Aan de hand van deze doelstellingen wordt een implementatie van de architectuur getest op flexibiliteit.

3

Wenselijke eigenschappen In deze sectie worden wenselijke eigenschappen voor WindexVIJF ten aanzien van schaalbaarheid en flexibiliteit besproken.

3.1 Schaalbaarheid Als de prestaties van een systeem onacceptabel worden, moeten de systeembronnen uitgebreid worden. Dit kan op ruwweg twee manieren: scale-up en scale-out.

66


Scale-up en scale-out uitgelegd Scale-up wil zeggen dat de nodes waar het systeem op draait worden voorzien van snellere processoren, meer geheugen, snellere netwerkcontrollers en –verbindingen, et cetera. Redundantie van systeem bronnen wordt zo verminderd en het is relatief goedkoop. Er is echter wel een grens: op een gegeven moment is het niet meer mogelijk de systeembronnen uit te breiden. Daarnaast leidt het uitbreiden van een systeembron niet altijd tot een in verhouding staande stijging in prestaties. Als een node wordt voorzien van een snellere processor, maar er vooral dure en tijdrovende harde-schijf operaties worden uitgevoerd, zal de stijging in prestatie marginaal zijn. Scale-out wil zeggen dat de nodes waar het systeem op draait worden gerepliceerd. Load-balancing zorgt ervoor dat iedere node optimaal belast wordt. In theorie kent scale-out geen limiet19 en scale-out is goed te combineren met distributie, redundantie en andere betrouwbaarheidsmaatregelen. Het is echter wel relatief kostbaar en het systeem moet vaak specifiek ingericht worden. Verder resulteert replicatie in consistentieproblemen en neemt de complexiteit toe. Daarnaast kan door de geïntroduceerde overhead de prestatie afnemen, omdat de overhead van load-balancer en scheduler groter is dan de behaalde winst20.

Wensen ten aanzien van WindexVIJF Ten aanzien van WindexVIJF is het in ieder geval wenselijk scale-up te ondersteunen. De meeste uitbreidingen van systeembronnen worden automatisch al ondersteunt, zoals sneller processoren, meer geheugen, snellere netwerkverbindingen, et cetera. Om ook gebruik te kunnen maken van processoruitbreidingen in de vorm van meerdere logische processoren per node, moet wel specifieke ondersteuning worden toegevoegd. Dit kan door middel van multithreading: de thread-scheduler van de CLR zorgt er dan automatisch voor dat gebruikgemaakt wordt van de extra processoren. Scale-out is een optie, omdat er voor scale-out wel speciale logica moet worden geschreven. In het ideale geval is WindexVIJF zo toegerust dat het gebruik kan maken van scale-out, maar dat pas doet als de prestatiewinst de overhead overstijgt. Dit kan worden gerealiseerd middels herconfiguratie. Door middel van zelfinspectie zou dit automatisch kunnen, maar zelfinspectie introduceert wel extra overhead.

3.2 Flexibiliteit Ten aanzien van de flexibiliteit van WindexVIJF is het ten eerste wenselijk om alle afhankelijkheden zoveel mogelijk te beperken. Het 19

Er is wel een limiet: als de load-balancer en scheduler maximaal belast zijn. Deze zouden echter op hun beurt ook weer via scale-out kunnen worden geschaald. 20 Dit zijn echter wel specifieke gevallen; doorgaans zal de overhead niet hoger zijn dan de prestatiewinst.

67


systeem opdelen in verschillende logische, losstaande lagen waarbij de communicatie is vastgelegd in interfaces is dan een logische eerste stap. De architectuur schrijft vier lagen voor. Het is wenselijk deze vier lagen ook te vertalen naar het ontwerp en de implementatie. Daar waar geen uitspraken noodzakelijk zijn, wordt gekozen voor standaarden, of voor interfaces die vastleggen wat verwacht wordt. In de datalaag bijvoorbeeld wordt geen uitspraak gedaan over de te gebruiken datastore; een data adapter moet voorzien in de implementatie van de data interface en zo de systeemoperaties omzetten naar datastore specifieke operaties. Bijkomend voordeel van de 4 lagen uit de architectuur is dat deze relatief eenvoudig als verschillende nodes in het systeem geïmplementeerd kunnen worden, om de schaalbaarheid te verbeteren. Binnen de lagen moet een grote modulariteit nagestreefd worden. Subsystemen worden vastgelegd met interfaces. Het is belangrijk dat deze subsystemen worden gebaseerd op gedrag; gedrag is minder applicatiespecifiek dan een class-structuur. Een grote modulariteit zorgt er ook voor dat WindexVIJF kan worden aangepast aan de omgeving. Zo kan een afgeslankte vorm dienst doen op een Personal Digital Assistant (PDA), bijvoorbeeld. Tenslotte is het belangrijk een flexibele inrichting na te streven. Windex 4 bestaat uit een aantal hoofdonderdelen die gerelateerde functies combineren. Als één functie uit een bepaald onderdeel nodig is, moet het gehele onderdeel gebruikt worden. Om de flexibiliteit voor WindexVIJF te verbeteren, zouden functies gecombineerd moeten worden tot minimale sets van semantisch gerelateerde functies, om zo een breder scala aan onderdelen te verkrijgen. De subsystemen in de architectuur kunnen gebruikt worden als uitgangspunt voor deze sets.

4

Metingen en tests In deze sectie worden de metingen en tests die gedaan zijn om een indicatie van de schaalbaarheid en flexibiliteit van het prototype te krijgen beschreven.

4.1 Schaalbaarheid Omdat het buiten het bereik van de opdracht ligt om een volledige beoordeling van de schaalbaarheid te doen, en omdat de functionaliteit van het prototype nog erg beperkt is, wordt van de drie dimensies van schaalbaarheid er maar één bekeken: het aantal gebruikers en gegevenselementen. Deze dimensie wordt verder gereduceerd door alleen te kijken naar gegevenselementen. Gegevenselementen kunnen in het prototype worden aangemaakt, opgevraagd, gewijzigd en verwijderd. Er wordt alleen gekeken naar het aanmaken van objecten, zodat binnen beperkte tijd toch een redelijk aantal metingen gedaan kunnen worden. Tenslotte wordt alleen gekeken naar de functie StoreObject, omdat

68


StoreObjectWithIdniet bijster veel verschilt van StoreObject en de resultaten elkaar dus waarschijnlijk niet veel zullen ontlopen. Beide adapters (Memory Adapter en File System Adapter) zijn getest. In eerste instantie was het de bedoeling 7 metingen te doen van respectievelijk 1, 10, 100, 1000, 10.000, 100.000 en 1.000.000 objecten, maar dit bleek niet haalbaar voor de File System Adapter. Wel zijn alle metingen 100 keer na elkaar uitgevoerd, om toevalligheden zoveel mogelijk te elimineren. De tests worden tenslotte achterelkaar uitgevoerd, om insteleffecten zoals de initiële vertraging veroorzaakt door de JIT compiler op te vangen. Bij de metingen worden de processortijd en het geheugenbereik gemeten. Dit zijn twee van de drie Quality of Service (QoS) aspecten. De derde, netwerkbelasting, kan niet gemeten worden omdat geen gebruik gemaakt wordt van het netwerk. De gemeten aspecten worden verder uitgedrukt in de volgende eenheden: • Working Set, dit is het aantal pagina’s in het geheugen • Geheugengebruik, dit is een combinatie van: o Niet gepagineerd systeemgeheugen o Gepagineerd systeemgeheugen o Gepagineerd geheugen o Privaat geheugen o Virtueel geheugen • Delta Working Set, dit is de groei (of krimp) van de Working Set • Delta Geheugen, dit is de groei (of krimp) van het geheugengebruik • Processortijd, dit is een combinatie van: o Gepriviligeerde processortijd, dit is de tijd die gespendeerd wordt aan kernelfuncties o Processortijd van de gebruiker • Delta Processortijd, dit is de groei (of krimp) van de processortijd De processortijd wordt uitgedrukt in ticks. Eén tick komt overeen met 100 nanoseconden.

Memory Adapter In Appendix 2 zijn de meetresultaten van de Memory Adapter opgenomen. Het is nu interessant te kijken naar het verloop van de getallen. Dit verloop wordt bepaald door de stijging van twee opeenvolgende verschillen. Dat wil zeggen dat gekeken wordt naar de verschillen 1-10, 10-100, … , 100.000-1.000.000 en de stijging wordt bepaald door steeds een volgend verschil te delen door een vorig, dus 10-100/1-10, … , 100.000-1.000.000/10.000-100.000. Dat leidt tot de volgende tabel: 1 2 3 4 5

WS 1.8 20.9 9.5 2.8 4.4

Geh 2.2 9.5 10.7 2.1 13.9

∆WS -0.1 -105 9.6 2.6 5.3

∆Geh 2 9.6 11 1.5 19.5

t 9.8 2.9 12 11.2 14

∆t 9.8 2.9 12 11.2 14

TABEL 1: VERLOOP

69


In het ideale geval zou het verloop gelijk zijn aan de stijging van het aantal elementen, dus 10. Daar is geen sprake van, zo blijkt uit de tabel. Bij de working set en het geheugen zou dit kunnen liggen aan de scheduler, onderdeel van het besturingssysteem en de CLR. Er is meer onderzoek nodig om de oorzaak te achterhalen. De tijd kent een redelijk verloop, alleen de 2e waarde springt eruit als extreem laag. Het redelijk lineaire verloop doet verder vermoeden dat er nauwelijks sprake is van overhead bij een stijgend aantal elementen. De laatste, hoge meetwaarde zou goed veroorzaakt kunnen zijn door het opraken van systeemgeheugen: het besturingssysteem grijpt dan in met dure swapoperaties. Ook hier is echter meer onderzoek nodig om de precieze oorzaak te achterhalen.

File System Adapter De File System Adapter maakt veel gebruik van relatief dure file i/o operaties, waardoor deze vele malen trager is dan de Memory Adapter. De tests met 100.000 en 1.000.000 elementen zijn dan ook achterwege gelaten. In Appendix 3 zijn de resultaten van de File System Adapter opgenomen. De verlooptabel is als volgt: 1 2 3

WS 12.1 3 -0.3

Geh 5.6 -3.7 0.3

∆WS 11.3 2.3 -0.1

∆Geh 5.6 -7 -0.2

t 11.4 9.9 10.5

∆t 11.4 9.9 10.4

TABEL 2: VERLOOP FILE SYSTEM ADAPTER

Hier lijkt het geheugengebruik te convergeren naar een vaste hoeveelheid. De ervaringen met de Memory Adapter maken deze waarden echter onbetrouwbaar. Totdat uit onderzoek is gebleken welke invloed de schedulers van de CLR en het besturingssysteem op de resultaten hebben (of deze invloed weggenomen is), zijn geen betrouwbare uitspraken te doen. De benodigde processortijd blijkt wel bij benadering lineair, net als bij de Memory Adapter.

4.2 Flexibiliteit De flexibiliteit van het prototype is ook het meest duidelijk aanwezig in de datalaag. De Data Interface is een punt van flexibiliteit dat het mogelijk maakt willekeurige datastores te gebruiken. Dat blijkt al uit de twee adapters die voor het prototype zijn geschreven. In andere lagen is echter ook flexibiliteit aanwezig, zoals flexibiliteit van presentatielaag en flexibiliteit van business rules engine. Bij de test wordt echter alleen gekeken naar de datalaag. Windex 4 is geschreven voor SQL Server. Dat betekent dat er veel gebruikgemaakt wordt van SQL Server specifieke stored procedures en functies. Een breaking change in SQL Server kan er toe leiden dat Windex 4 niet meer functioneert. Daarnaast is het niet mogelijk om Windex 4 te gebruiken met IBM DB2, object-georiënteerde databases

70


(OODB), XML databases, low-cost oplossingen als MySQL of eenvoudig het bestandssysteem. Het prototype bevat de Data Interface (zie Appendix 4). Voor iedere willekeurige datastore kan een Data Adapter geschreven worden, die deze interface implementeert door de interfacefuncties te vertalen naar specifieke operaties voor de datastore. Daarnaast moet de PersistencyOption enumeratie nog uitgebreid worden met een identifier voor de datastore. De Data Adapter Factory tenslotte moet verteld worden hoe de Data Adapter aangemaakt moet worden. De drie wijzigingen hebben alleen betrekking op de datalaag. Er is geen communicatiestroom die over de datalaag heengaat die gewijzigd wordt door deze aanpassingen. Dat betekent dat voor de hogere lagen er functioneel gezien niets veranderd is. (Behalve dat er een nieuwe datastore beschikbaar is.) Bestaande configuraties blijven werken, terwijl nieuwe configuraties zo gemaakt kunnen worden dat ze de nieuwe datastore gebruiken. Bestaande configuraties kunnen ook de nieuwe datastore gebruiken, maar dan moet de gegevensset vertaald worden van de originele datastore naar de nieuwe. Hiervoor biedt het prototype geen ondersteuning. Ten aanzien van het zoeken van objecten dient nog opgemerkt te worden, dat datastores meestal een eigen, unieke, niet uitwisselbare query language gebruiken (zoals SQL21). Dit betekent dat de lagen boven de datalaag een onafhankelijk query language moeten gebruiken, die ook door de Data Adapter vertaald wordt naar specifieke query’s voor de datastore. Bij wijze van test is een SQL Data Adapter geïmplementeerd. Omdat het buiten het bereik van de opdracht ligt om een vertaalmachine van objectgeoriënteerde datamodellen naar relationele schema’s te ontwikkelen, is deze geïmplementeerd als de File System Adapter, met het verschil dat de geserialiseerde objecten niet naar het bestandssysteem, maar naar SQL Server worden weggeschreven. Onderstaand screenshot toont het resultaat: de applicatie gebruikt de SQL Data Adapter:

21

Hoewel SQL in principe een standaard is, gebruikt iedere datastore eigen uitbreidingen en interpretaties

71


FIGUUR 36: DE SQL DATA ADAPTER IN ACTIE

5

Technieken In de prototypes zijn niet veel technieken voor het verbeteren van schaalbaarheid en flexibiliteit doorgevoerd. In deze sectie worden alsnog een aantal veelgebruikte technieken behandeld. Al deze technieken kunnen worden toegepast binnen WindexVIJF.

5.1 Schaalbaarheid REPLICATIE

Eén van de meest gebruikte technieken om de schaalbaarheid te verbeteren is replicatie. Bij replicatie wordt een zwaar belast onderdeel van het systeem gerepliceerd (“gekloond”) en wordt een extra stukje applicatielogica toegevoegd om de belasting te verdelen over alle replica’s (“klonen”). Replicatie vergt een goede consistentieen updatestrategie, omdat alle replica’s over dezelfde (relevante) informatie moeten beschikken.

DISTRIBUTIE

Een andere techniek is distributie: hierbij worden verschillende systeemonderdelen verspreid over meerdere nodes en het netwerk, om de belasting op onderliggende systemen (zoals de nodes en het netwerk) te verminderen.

CACHING

Vaak is er een zekere herhaling waarneembaar in de taken die een systeem moet uitvoeren en de resultaten die opgeleverd moeten worden. Door deze taken en resultaten te cachen (“bewaren”), wordt voorkomen dat het systeem onnodige verwerkingen uitvoert. Het systeem gaat dan alleen over tot verwerking als de cache niet de juiste gegevens bevat.

72


(A)SYNCHRONICITEIT

Bij synchrone operaties wordt een systeem geblokkeerd zolang deze moet wachten op een antwoord op de operatie. Omdat er daarnaast ook vaak sprake is van “piekuren” bij een server, kan dit leiden tot lange wachttijden. Asynchrone operaties daarentegen laten het systeem doorwerken en maken het voor de server mogelijk om de requests beter te spreiden. Uiteindelijk wordt ieder request beantwoord. Voorwaarde voor asynchrone operaties is wel dat de client het antwoord niet nodig heeft om door te kunnen gaan (dus ander werk kan doen zolang het antwoord er nog niet is).

LOCKING

Als het mogelijk is dat een bron door meerdere processen wordt aangesproken, is het vaak noodzakelijk de bron vast te zetten (locking) om consistentie van de bron te waarborgen. Door de tijd die een bron bezet is te minimaliseren, wordt de beschikbaarheid van die bron gemaximaliseerd. Een hoge beschikbaarheid verhoogt de schaalbaarheid, omdat processen minder lang hoeven te wachten op een bron en de prestaties daardoor verbeterd worden.

PARTITIONERING

Naarmate een systeem groeit, ontstaan er meer en meer (semi-) autonome eilanden in de gegevensset. Door de gegevensset te partitioneren op deze eilanden, kunnen replicatie en distributie beter toegepast worden, omdat het niet altijd noodzakelijk is de gehele gegevensset te repliceren.

5.2 Flexibiliteit Technieken voor het verbeteren van de flexibiliteit van een systeem richten zich enerzijds op dynamiek en anderzijds op vastlegging van het systeem. Het systeem moet dynamisch zijn, om een grote (her)configureerbaarheid te bewerkstelligen, maar moet vastgelegd worden om te allen tijde een juiste en gedetailleerde beschrijving van het systeem te hebben. Alleen dan is het mogelijk de gevolgen van veranderingen in de configuratie te overzien, en daarmee de dynamiek te garanderen. AFHANKELIJKHEDEN

Systemen kennen veel afhankelijkheden tussen de componenten waaruit ze zijn opgebouwd. Een gevaar hierbij is het cascading dependency phenomenon: A is afhankelijk van B, en B is afhankelijk van C. Daardoor is A ook afhankelijk van C. Een verandering in C kan er dan toe leiden dat A niet meer correct functioneert. Deze onwenselijke situatie is een ernstige beperking van de flexibiliteit.

REGISTRATIE

Een eerste stap in het verbeteren van deze situatie is het registreren van afhankelijkheden. Het overzicht dat dan ontstaat kan gebruikt worden om de gevolgen van veranderingen te analyseren. Wordt het functioneren van het systeem in gevaar gebracht door de verandering, dan is dit op voorhand duidelijk en kunnen passende maatregelen genomen worden.

WAARDEREN

Een tweede stap is het waarderen van de afhankelijkheden. Deze waardering wordt gedaan aan de hand van een risico-analyse van een afhankelijkheid. Hoe stabiel is het component uit de afhankelijkheid? Componenten die vaak veranderen zijn niet stabiel. Hoeveel invloed is er op deze veranderingen en waar komt het

73


component vandaan? Externe componenten zijn vaak black boxes: het is niet bekend wat er gebeurd in het component. En tenslotte, hoe is het component gedocumenteerd? Een ongedocumenteerd component dat bijvoorbeeld van het Internet gedownload is vormt een zeer groot risico. REDUCEREN

Aan de hand van de waardering kunnen de afhankelijkheden gereduceerd worden. In deze derde stap moeten de onstabiele, ongedocumenteerde, of externe componenten vervangen worden door stabiele en gedocumenteerde componenten, zodat afhankelijkheden geminimaliseerd worden. Deze hoeven niet per sé intern te zijn: externe implementaties van standaarden (de facto of de jure) zijn bijvoorbeeld vaak te prefereren boven interne implementaties van eigen “standaarden”.

INTERFACES

Een meer constructieve oplossing is gebruik te maken van interfaces voor de specificatie van gedrag en communicatie. A is dan niet langer afhankelijk van B, maar van interface β, en daardoor ook niet langer afhankelijk van C.

REFLECTIE

Soms is het gebruik van ongedocumenteerde, externe componenten onontkoombaar. Reflectie kan dan gebruikt worden om het gewraakte component te inspecteren en op die manier alsnog een zekere documentatie van het component op te stellen. Reflectie kan daarnaast gebruikt worden voor herconfiguratie van het systeem.

SELF CONFIGURING

Door reflectie een stap verder te nemen en het systeem te voorzien van een deterministisch systeem dat middels via reflectie verkregen invoerwaardes zichzelf kan configureren, zijn systemen nog flexibeler te maken. Systemen kunnen dan vrijwel autonoom draaien, reageren op inen externe veranderingen en nemen beslissingen op basis van sensorgegevens. Dergelijke systemen heten self configuring.

SELF AWARENESS

Nóg een stap verder zijn zelfbewuste systemen (self awareness). Zelfbewuste systemen hebben kennis van zichzelf en kunnen over zichzelf redeneren. Het deterministisch systeem is dan niet meer nodig; het systeem neemt de beslissingen zelf. Door het systeem te voorzien van een set doelen, kan het systeem controleren of het nog correct functioneert. Is dit niet het geval, dan worden maatregelen genomen. Microsoft is actief op dit gebied met het Dynamic Systems Initiative (DSI), waarvan een van de eerste resultaten, de Automated Deployment Services (ADS), inmiddels in beta draait op Windows Server 2003 [MIC03a], [MIC03b].

5.3 Schaalbaarheid en flexibiliteit combineren Schaalbaarheid en flexibiliteit kennen raakvlakken, waarbij beiden voordeel hebben van eenzelfde strategie. Hier worden een aantal dergelijke strategieën besproken. Modulariteit

74

Bij schaalbaarheid is modulariteit belangrijk als enabler van replicatie en distributie. Flexibiliteit zegt dan dat deze modules gespecificeerd moeten worden in de vorm van interfaces, en dat deze interfaces de enige afhankelijkheden behoren te zijn tussen de modules.


Partitionering

Als een systeem migreert van een vaste naar een mobiele omgeving, schrijft flexibiliteit voor dat het systeem geherconfigureerd moet worden. Waarschijnlijk zal hierbij de gegevensset gepartitioneerd worden, omdat er geen ruimte is voor de hele data store in de mobiele omgeving, en deze ook niet nodig is. Het systeem wordt dan dus teruggeschaald voor de mobiele omgeving.

self configuring/awareness Zelfconfigurerende en –bewuste systemen zijn flexibel, maar kunnen ook schaalbaar zijn, als ze de juiste middelen hebben en voorzien worden van een Service Level Agreement (SLA) met kwaliteitsdoelen. In servicegeoriënteerde omgevingen behoort deze verantwoordelijkheid niet bij de afzonderlijke consumers en providers te liggen. Het is beter de broker te voorzien van deze verantwoordelijkheid. De broker die dan ontstaat, is een Quality-ofService aware broker. Een opzet voor een dergelijke broker kan gevonden worden in Appendix 4.

6

Conclusies en aanbevelingen De tests en metingen geven aan dat qua processortijd het prototype schaalt op een zo goed als lineaire manier. Qua geheugengebruik zijn er echter geen uitspraken te doen, omdat nog geen duidelijke oorzaak is gevonden voor het verloop22. In deze sectie worden een aantal conclusies en aanbevelingen gepresenteerd, deels gebaseerd op de tests en metingen, deels op best practices en algemene richtlijnen.

BOTTLENECKS

Als een systeem groeit en slechter gaat presteren, is er sprake van een bottleneck. Als deze bottleneck zich in de systeembronnen bevindt, dan kunnen via scale-up en scale-out technieken de prestaties teruggebracht worden op een acceptabel niveau. Bottlenecks in de software zelf zijn vaak minder makkelijk op te lossen en vaak is het noodzakelijk het systeem te herontwerpen.

BENCHMARK

De Memory Adapter is een goede kandidaat voor een benchmark. Deze adapter is niet afhankelijk van een opslagmedium of overhead van een datastore en is dus waarschijnlijk de meest efficiënte oplossing. Aan de hand van de Memory Adapter kunnen dan andere adapters getest worden. Deze benchmark kan ook dienen als enabler van een flexibel selectiemechanisme van Data Adapters, zodat op basis van een SLA een adapter gekozen kan worden. Bij een PDA kan dan bijvoorbeeld automatisch gemigreerd worden naar een RamDisk datastore.

REENGINEERING

Het prototype is te onvoorspelbaar, te onbetrouwbaar en te weinig getest om in productie genomen te worden, en reengineering is dus noodzakelijk. De volgende strategieën maken dat het uiteindelijke systeem wél voldoet aan de eisen qua schaalbaarheid en flexibiliteit: • Leg vast wat de eisen zijn voor schaalbaarheid en flexibiliteit. SLA’s moeten gebaseerd worden op deze eisen. Alleen dan voldoet het systeem gegarandeerd aan de SLA.

22

Mogelijke oorzaken liggen in de schedulers voor de allocatie van geheugen in het besturingssysteem en in de CLR. De Garbage Collector van de CLR speelt hierin waarschijnlijk ook een grote rol.

75


•

• •

• •

•

•

76

Voeg liefst formele gedragsspecificaties toe aan de specificaties van de subsystemen. Deze kunnen dan (formeel) geanalyseerd worden om zo vroeg mogelijk fouten als deadlocks en bottlenecks op te sporen. Specificeer interfaces voor de communicatie tussen lagen en subsystemen. Ga pas over tot ontwerp als alle interfaces vastliggen. Ontwerp de lagen sequentieel en bottom-up. Dit is een extra garantie van de communicatiestroom tussen de lagen (alleen initiërend van boven naar beneden) en zorgt er ook voor dat een duidelijk overzicht blijft bestaan en lagen niet buiten hun grenzen treden. Lagen zelf moeten top-down, vanuit de interface, ontworpen worden. Het is makkelijker om functionaliteit op een hoog niveau te beschrijven en dan op te delen, dan deze te distilleren uit vele kleine stukjes functionaliteit. Gebruik interfaces intensief. Hierdoor worden afhankelijkheden gereduceerd, flexibiliteit gegarandeerd en schaalbaarheid versterkt. Test iedere laag en ieder subsysteem uitvoerig. Begin pas met de ontwikkeling van afhankelijke lagen en subsystemen als de ontwikkeling van de huidige laag of subsysteem afgesloten is. Zo wordt het lokaliseren van fouten makkelijker. Verwerk flexibiliteit en schaalbaarheid vanaf de eerste specificaties. Achteraf toevoegen van maatregelen voor flexibiliteit en schaalbaarheid zoals multithreading is onnodig complex en leidt vaak tot eveneens onnodige fouten. Maak zoveel mogelijk gebruik van liefst open standaarden en bestaande middleware: deze zijn reeds uitvoerig gespecificeerd, getest en gedocumenteerd.

Hoofdstuk 8: Conclusies en aanbevelingen

H O O F D S T U K

8

Conclusies en aanbevelingen 1

Archituur, abstractie en architect De eerste onderzoeksvraag luidde: “Wat zijn software architecturen?”. Ten aanzien van deze onderzoeksvraag, wordt geconcludeerd dat software architectuur een nuttige abstractie is, waarmee een overzicht van complexe software systemen wordt verkregen. Software architectuur vormt een voertuig voor vroege systeemanalyse, voordat de individuele componenten en objecten bekend zijn. Omdat de stakeholdereisen expliciet worden opgenomen in de architectuur, zorgt software architectuur voor een basis voor het ontwerp van het systeem dat gegarandeerd voldoet aan de eisen van de stakeholders. De software architect is verantwoordelijk voor het opstellen van de software architectuur. Hij luistert naar de stakeholders, onderkent ook hun impliciete eisen en vormt een communicatiebrug tussen de externe, vaak niet-technische stakeholders en de interne stakeholders zoals het management en de software ontwerpers. Ook bij Windex Software BV is er een rol voor de software architect weggelegd. Hij zal de stakeholders in kaart moeten brengen en hun eisen op tafel moeten krijgen. Daarna kan de definitieve architectuur voor WindexVIJF worden opgesteld, waarna overgegaan kan worden tot het ontwerp en de implementatie van WindexVIJF. De architect ziet er in deze fase op toe dat het ontwerp en de implementatie voldoen aan de door de architectuur gestelde eisen. Daarnaast onderhoudt de architect de architectuur; dat wil zeggen dat als de eisen van stakeholders veranderen, of als er mogelijkheden zijn tot verbetering van de architectuur, de architect deze waarneemt en de architectuur indien nodig reviseert. De architectuur die in deze opdracht is gepresenteerd, vormt een eerste aanzet tot die doelarchitectuur. Er is een aantal lagen en subsystemen onderkend, maar dit is nog lang niet toereikend. Niet alleen zijn de stakeholders onvoldoende in kaart gebracht (en daarmee hun eisen), ook zijn de subsystemen onvoldoende uitgediept, waardoor essentiële functionaliteit nog niet gemodelleerd is. Een vervolg op dit werk is dan ook het aanstellen van een software architect met de opdracht de stakeholders in kaart te brengen, hun eisen op tafel te krijgen en de definitieve architectuur op te stellen.

77


2

Services De tweede en derde onderzoeksvragen luidden respectievelijk: “Wat is de Service Oriented Architecture, en hoe is deze ontstaan?” en “Wat zijn XML Web Services, en hoe zijn deze ontstaan?”. Centraal bij beide vragen staan services. Services zijn functionele eenheden van verwerking en informatie, die afhankelijkheden beperken tot interfaces, waardoor ze een krachtig gereedschap vormen om betrouwbare en voorspelbare software te maken. Ook zorgen de abstractie van lokatie en implementatie voor een grote flexibiliteit en schaalbaarheid. De behoefte aan een ondersteunende architectuur voor deze services heeft het ontstaan van de Service Oriented Architecture gestuurd. CORBA, Jini en DCOM zijn een aantal populaire platformen voor servicegeoriënteerde systemen. Helaas kennen deze platformen een aantal nadelen, waardoor services uit verschillende platformen niet onderling kunnen communiceren en de dynamiek en het bereik beperkt worden. XML Web Services zijn ontwikkeld om hier verandering in te brengen door gebruik te maken van universele, open, gestandaardiseerde technologieën voor de interfaces (WSDL), communicatie (SOAP) en beschrijvingen (UDDI) van services. XML Web Services vormen een belangrijke enabler van dynamische e-business (integratie in de supply-chain). Windex 4 kent veel problemen met verschillende parallelle versies, een gebrek aan een overzicht van het systeem, onvoldoende gespecificeerde subsystemen en een gebrek aan documentatie van afhankelijkheden. Voor WindexVIJF dient dan ook gekozen te worden voor een meer structurele aanpak in de ontwikkeling. Services zorgen voor deze aanpak door de ontwikkelaar te dwingen te denken in termen van gedrag, informatie en verwerking. Deze moeten gebundeld worden in een interface voor een service. Interfaces beperken verder de afhankelijkheden.

3

Strategieën De vierde onderzoeksvraag luidde: “Hoe kunnen flexibiliteit en schaalbaarheid worden meegenomen in de ontwikkeling van een architectuur?”. De diverse strategieën en technieken die in dit verslag worden beschreven vormen tezamen het antwoord op deze onderzoeksvraag. Elk van deze strategieën en technieken maakt het noodzakelijk dat in de architectuur voorbereidingen worden getroffen voor de realisatie van de strategieën en technieken. Als belangrijkste strategieën voor schaalbaarheid zijn genoemd replicatie en distributie. In de architectuur worden deze strategieën ondersteund door een grote modulariteit, welke immers veel replicatie- en distributiepunten introduceert. Ook vormen services, interfaces en gestandaardiseerde communicatie belangrijke enablers voor replicatie en distributie. Ook het delegeren van

78


verantwoordelijkheden als communicatie en lokatiebepaling naar gespecialiseerde componenten als een broker verbeterd de mogelijkheden voor replicatie en distributie. Als belangrijkste strategieën voor flexibiliteit zijn genoemd beperking van afhankelijkheden en reflectie. Beperking van de afhankelijkheden gaat in dit geval hand in hand met enablers voor replicatie en distributie zoals interfaces, services en brokers. Reflectie wordt ondersteund door .NET en maakt het mogelijk om wijzigingen in de configuratie (automatisch) door te voeren.

4

Voorstel architectuur De vijfde onderzoeksvraag luidde: “Hoe zou het framework voor Windex Software BV eruit moeten zien, met inachtneming van de verzamelde adviezen?”. In het voorstel voor de architectuur van WindexVIJF is voorgesteld WindexVIJF op te delen in vier lagen functies: een datalaag, een platformlaag, een business logic laag en een presentatielaag. Deze vier lagen zorgen voor een verdere structurering van WindexVIJF. Iedere laag heeft een eigen verantwoordelijkheid binnen WindexVIJF en wordt begrensd door interfaces. Communicatie tussen de lagen vindt alleen plaats tussen aangrenzende lagen, en hogere lagen nemen het initiatief bij de communicatie. Dit garandeert een losse koppeling en beperkt de afhankelijkheden van de lagen. De lagen worden onderverdeeld in subsystemen. Ieder subsysteem kent zijn eigen verantwoordelijkheid en neemt een specifieke plaats in in WindexVIJF. Ieder subsysteem wordt gedefinieerd door een interface, en kan zelf weer bestaan uit meerdere subsystemen. Dit zorgt ervoor dat de granulariteit van WindexVIJF flexibel is, en WindexVIJF in verschillende “zwaartes” aangeboden kan worden, waarbij niet noodzakelijke subsystemen worden weggelaten, of worden vervangen door domeinspecifieke alternatieven. De grote lijnen van WindexVIJF worden beschreven, maar het voorstel is geen uitputtende specificatie van WindexVIJF. De architect die voor Windex Software BV de architectuur van WindexVIJF zal opstellen, kan het voorstel gebruiken als uitgangspunt; de ideeën in de vorm van het lagenmodel en de communicatiestroom kunnen zondermeer overgenomen worden.

5

Prototypes Het eerste prototype toont aan dat het voorstel voor de architectuur van WindexVIJF te realiseren is. Daarnaast vormt de Object Factory een voertuig voor de gewenste klantspecifieke inrichting van WindexVIJF. Windex Software BV kan echter niet zondermeer de Object Factory inzetten voor WindexVIJF. Daarvoor is de functionaliteit nog te beperkt. Ook is het raadzaam te kijken naar standaarden voor

79


objectspecificatie zoals de Meta Object Facility, in plaats van de Type Description Base uit het prototype te gebruiken. Het tweede prototype is een implementatie van een vertikale kolom uit het voorstel voor de architectuur. Deze is gebruikt om de schaalbaarheid te meten en de flexibiliteit ten opzichte van Windex 4 te bekijken. Ook aan dit prototype moet flink gewerkt worden voordat het in productie kan worden genomen.

6

Metingen en tests Uit de metingen van de processortijd blijkt dat het prototype goed schaalt. Omdat de Memory Adapter veruit de snelste is, is het een optie om van deze adapter een benchmark voor andere adapters te maken. De tests op flexibiliteit geven verder aan dat met het voorstel voor de architectuur dat hier gepresenteerd is een sterk flexibele applicatie mogelijk is. Windex Software BV kan de hier gepresenteerde methodieken dus zeker toepassen voor WindexVIJF.

7

Afsluiting Tenslotte wordt Windex Software BV het volgende aanbevolen voor de ontwikkeling van WindexVIJF: • Leg vast wat de eisen zijn voor schaalbaarheid en flexibiliteit. SLA’s moeten gebaseerd worden op deze eisen. Alleen dan voldoet het systeem gegarandeerd aan de SLA. • Voeg formele gedragsspecificaties toe aan de specificaties van de subsystemen. Deze kunnen dan formeel geanalyseerd worden om zo vroeg mogelijk fouten als deadlocks en bottlenecks op te sporen. • Test iedere laag en ieder subsysteem uitvoerig. Begin pas met de ontwikkeling van afhankelijke lagen en subsystemen als de ontwikkeling van de huidige laag of subsysteem afgesloten is. Zo wordt het lokaliseren van fouten makkelijker. • Verwerk flexibiliteit en schaalbaarheid vanaf de eerste specificaties. Achteraf toevoegen van maatregelen voor flexibiliteit en schaalbaarheid zoals multithreading is onnodig complex en leidt vaak tot eveneens onnodige fouten. • Maak zoveel mogelijk gebruik van liefst open standaarden en bestaande middleware: deze zijn reeds uitvoerig gespecificeerd, getest en gedocumenteerd.

80


81


H O O F D S T U K

9

Reflectie Ik wil deze ruimte gebruiken om terug te blikken op de afgelopen maanden en deze doctoraalopdracht. De afgelopen maanden waren enerverende maanden waarin ik veel interessante dingen heb kunnen doen. Het uitdiepen van de mogelijkheden van Reflection.Emit en het bestuderen van de Common Intermediate Language vormden een fascinerend zijpad, waarvan ik het bewandelen niet betreur. Het kunnen aanmaken van types op runtime, maar meer nog het kunnen uitbreiden van types op runtime met pre- en postfuncties opent de weg naar nieuwe manieren van het gebruiken van (externe, niet gedocumenteerde) software. Zaken als logging, validatie van inen uitvoer, extra beveiligingschecks, et cetera kunnen allemaal toegevoegd worden, zonder dat de originele code beschikbaar hoeft te zijn! Het bestuderen van de Common Intermediate Language heeft mij verder inzichten in het .NET framework opgeleverd die mij via C# nooit eigen geworden waren: de fundamenten worden tenslotte door C# (en iedere andere 4G taal trouwens) verborgen. Daarnaast was het essentieel om de Object Factory te kunnen realiseren. Die Object Factory is ook interessant. In principe zou het mogelijk moeten zijn om Business Objecten op runtime te definiëren, evenals de Business Rules. Als hier een scripttaal voor zou worden ontwikkeld, zouden business solutions gemaakt kunnen worden als scripts, met een krachtige backend in de vorm van een Business Rules Engine en een datastore (mijn voorkeur gaat uit naar een objectgeoriënteerde database). Dit zou de ontwikkeling van business solutions sterk moeten vereenvoudigen. Binnen WindexVIJF wordt de Object Factory waarschijnlijk ingezet voor de klantspecifieke inrichting. Objecten worden eenmaal gedefinieerd en gecreëerd en zijn vanaf dat moment beschikbaar. Niet helemaal de hierboven beschreven script-toekomst, en dus hoop ik nog een tijd met de Object Factory en de ideëen erachter te mogen spelen. De Object Factory was natuurlijk niet het enige interessante resultaat van mijn doctoraalopdracht. Tijdens het uitvoeren van de opdracht is bij mij ook het idee voor de Quality-of-Service aware Broker ontstaan, en dát vind ik de meest interessante ontwikkeling. De QoS aware Broker is een concept dat volgens mij binnen 5-10 jaar gerealiseerd is. Het Dynamic Systems Initiative van Microsoft, nauw verwant, kent ook een dergelijke termijn overigens. Naarmate computers meer en meer alomtegenwoordig worden, zullen ook de grenzen tussen afzonderlijke computers verder vervagen. Duizenden

82

Hoofdstuk 9: Reflectie

computers zullen samenwerken om ons in ons dagelijks leven bij te staan. Het is dan niet langer mogelijk voor mensen om nog overzicht te hebben van dit schier-levend organisme. Zelfregulering en zelfconfiguratie zijn dan een noodzaak geworden, en die worden versterkt door zelfbewustzijn. De QoS aware broker is het meest sprekende voorbeeld van wat er steevast gebeurde tijdens het uitvoeren van de doctoraalopdracht: ik dwaalde af, wilde verder waar daar eigenlijk geen ruimte meer was, kwam talloze interessante dingen tegen die erom schreeuwden verder uitgediept te worden. Veel van die dwalingen zijn opgenomen in mijn lijstje van “dingen die ik ooit nog moet doen”. Daar komt alles wat ik ooit tegenkom, dat ik interessant vind en waar ik mij verder in wil verdiepen, maar waar ik de tijd niet voor heb op het moment. Tja, een dag kent tenslotte maar 24 uur… Hoewel ik tijdens mijn studie al niet ongecharmeerd was van de formele methoden, ben ik tijdens deze doctoraalopdracht (nog) meer gecharmeerd geraakt van de formele methoden. Veel formele methoden zijn sterk wiskundig en daardoor ook zeer complex voor mensen zonder voldoende wiskundige onderbouwing. Een methode die daar een uitzondering op vormt, en die ik hier wil noemen, zijn design patterns. Design patterns, letterlijk vertaald “ontwerppatronen”, zijn combinaties van objecten waarmee bepaalde typen problemen aangepakt kunnen worden. Door patterns te combineren ontstaan complexere oplossingen, voor complexere problemen. De charme van design patterns is nu, dat er maar een beperkt aantal patterns zijn en dat deze stuk voor stuk eenvoudig te doorgronden zijn. Het is daarmee een uiterst krachtige toolkit voor de software engineer. Graag had ik meer aandacht besteed aan design patterns. Maar, zoals zo vaak met eenvoudige doch rijke concepten, de moeilijkheid zit hem in de toepassing, en daar was de tijd er niet voor. Ik vermoed echter dat ik de design patterns nog wel zal tegenkomen in mijn professionele carrière. En dan de onvermijdelijke vraag: wat had ik anders, beter kunnen doen? In het algemeen had ik de theorie beter in de praktijk kunnen brengen. Hoewel de architectuur slechts een voorstel is, had ik al wel contact kunnen zoeken met enkele stakeholders, ook al gaf Windex Software BV te kennen zichzelf als enige stakeholder te beschouwen. Gegeven meer tijd, had ik ook een beter testregime op kunnen stellen. Ik had ook de oorzaak van de vreemde geheugenmetingen kunnen zoeken. Ook had ik een meer wiskundige analyse op de metingen kunnen loslaten, om te komen tot uitspraken in plaats van indicaties over de schaalbaarheid. In ieder geval is het voor mij een leerzame ervaring geweest. Eens te meer bleek er een groot verschil te zijn tussen de academische theorie (waarin een formele aanpak benadrukt wordt) en de praktijk (waarin diezelfde formele aanpak vaak niet gerealiseerd kan worden). Ook moeten er in de praktijk vaak concessies gedaan worden onder druk van kosten, tijd, en inspanning. Dat is jammer, want dat is vaak

83


een ernstige belemmering in het behalen van de door de academische theorie beloofde resultaten.

84

Afsluiting: Literatuur

A F S L U I T I N G

Literatuur [ALF02]

Alfred, C. & Jordan, T., Service Oriented Architecture: a Foundation for Web Services, Jini and Other Distributed Platforms, Foliage: 2002. http://www.foliage.com/whitepapers/request_SOA.shtml (7 april 2003)

[ACO02]

Acosta-Elias, J. & Navarro-Moldes, L., A Demand-based Algorithm for Rapid Updating of Replicas, Polytechnic University of Catalonia: 2002. http://people.ac.upc.es/leandro/pubs/resh2002.pdf (10 april 2003)

[BAR99]

Barroca, L. et al, An Introduction and History of Software Architectures, Components and Reuse, The Open University: 1999. http://mcs.open.ac.uk/lmb3/introduction.pdf, (2 april 2003)

[BLA00]

Blair, G.S. et al, The Role of Software Architecture in Constraining Adaptation in Component-Based Middleware Platforms, Open-ORB Project: 2000. http://www-rocq.inria.fr/solidor/doc/ps00/mdw.pdf (10 april 2003)

[BRO02]

Brown, A. et al, Using Service Oriented Architecture and Component Based Development to Build Web Service Applications, Rational Inc: oktober 2002 http://www.rational.com/media/whitepapers/TP032.pdf (7 april 2003)

[CHA02]

Chappell, D. & Kirk, S., Application Design Guidelines: from n-tier to .NET, Microsoft Corporation: april 2002. http://msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch001. asp (8 april 2003)

[DTE98]

d-Tec Distributed Technologie GmbH, 3- and n-tier Architectures, dTec Distributed Technologies GmbH: 1998. http://www.corba.ch/e/3tier.html (3 april 2003)

[EMM00]

Emmerich, W., Software Engineering and Middleware: a Roadmap, University College London: 2000. http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/finalemmerich.pdf (10 april 2003)

[FOS02]

Foster, I., An Open Grid Services Architecture, Argonne National Laboratory: april 2002. http://umbriel.dcs.gla.ac.uk/general/news/ukroadmap180402/OpenGri dServicesArchitectureApril20021.ppt (7 april 2003)

[GAC95]

Gacek, C. et al, On the Defintion of Software System Architecture, University of Southern California: april 1995. http://citeseer.nj.nec.com/cache/papers/cs/825/http:zSzzSzsunset.usc .eduzSzTechRptszSzPaperszSzSwArchDef.pdf/gacek95definition.pdf (2 april 2003)

85


[GAR94]

Garlan, D. & Shaw, M., An Introduction to Software Architecture, Carnegie Mellon University: 1994. http://www-2.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_sof tarch.pdf (2 april 2003)

[HIL96]

Hilliard, R. et al, Architecture Quality Assessment, version 2.0, MiTRE Corporation: 7 augustus 1996. http://members.bellatlantic.net/~rfh2/writings/aqa-swee.pdf (4 april 2003)

[KRE01]

Kreger, H., Web Services Conceptual Architecture, IBM Software Group: mei 2001. http://www-3.ibm.com/software/solutions/webservices/pdf/WSCA.pdf (8 april 2003)

[MED98]

Medvidovic, N. & Taylor, R.N., Separating Fact from Fiction in Software Architecture, University of California: 1998. http://delivery.acm.org/10.1145/290000/288435/p105-medvidovic.pdf (3 april 2003)

[MIC01]

Microsoft Corporation, Global XML Web Services Architecture, oktober 2001. http://www.gotdotnet.com/team/XMLwebservices/gxa_overview.aspx (8 april 2003)

[MIC02]

Microsoft Corporation, Application Architecture for .NET: Designing Applications and Services, Microsoft Press: 2002. http://msdn.microsoft.com/library/en-us/dnbda/html/distapp.asp (9 april 2003)

[MIC03a]

Microsoft Corporation, Automated Deployment Services, Technical Overview, Microsoft Corporation: 18 maart 2003. http://www.microsoft.com/windowsserver2003/techinfo/overview/ads. mspx (21 augustus 2003)

[MIC03b]

Microsoft Corporation, Microsoft Announces Dynamic Systems Initiative, Microsoft PressPas: 18 maart 2003. http://www.microsoft.com/presspass/press/2003/mar03/0318DynamicSystemsPR.asp (21 augustus 2003)

[NEU94]

Neumann, C.B., Scale in Distributed Systems, University of Southern California: 1994. http://citeseer.nj.nec.com/cache/papers/cs/16/ftp:zSzzSzftp.isi.eduzSz isi-pubszSzrs-94-411.pdf/neuman94scale.pdf (10 april 2003)

[NEW01]

Newport, B., Requirements for Building Industrial Strength Web Services: the Service Broker, TheServerSide.com: juli 2001. http://www.theserverside.com/resources/article.jsp?l=Service-Broker (8 april 2003)

86

Afsluiting: Literatuur

[NOA00]

Noack, J. et al, Architectural Patterns for Web Applications, Informatikzentrum der Sparkassenorganisation: 2000. http://citeseer.nj.nec.com/cache/papers/cs/12917/http:zSzzSzwww.ias ted.comzSzconferenceszSz2000zSzaustriazSz307abstractszSz3072-041.pdf/architectural-patterns-for-web.pdf (3 april 2003)

[OTO03]

O’Toole, A., Web Service Oriented Architecture: the Best Solution for Business Integration, Cape Clear Software, 2003. http://www.capeclear.com/clear_thinking.shtml (7 april 2003)

[PAL01]

Pallos, M.S., Service-Oriented Architecture: a Primer, eAi Journal: December 2001. http://www.eaijournal.com/PDF/SOAPallos.pdf (7 april 2003)

[PER92]

Perry, D.E. & Wolf, A.L., Foundation for the Study of Software Architecture, AT&T Bell Laboratories: 1992. http://citeseer.nj.nec.com/cache/papers/cs/4418/http:zSzzSzwww.belllabs.comzSz~depzSzworkzSzpaperszSzswa-sen.pdf/perry92foundati on.pdf (2 april 2003)

[REN97]

Renzel, K. & Keller, W., Three Layer Architecture, Bundesministerium für Bildung, Wissenschaft, Forschung und Technologie: 1997. http://www4.informatik.tu-muenchen.de/proj/arcus/TUM-I9746/2.1.ps.g z (3 april 2003)

[STA95]

Stal, M., The Broker Architectural Framework, Siemens AG: 1995. http://www.cs.wustl.edu/~schmidt/OOPSLA-95/html/papers/broker.ps. gz (3 april 2003)

87


A F S L U I T I N G

Gerelateerde literatuur Bloomberg, J., Testing Web Services Today and Tomorrow, The Rational Edge: oktober 2002. http://www.therationaledge.com/content/oct_02/m_Webtesting_jb.jsp (8 april 2003) Gisolfi, D., Web Services Architect, part 1-6, IBM: april-november 2001 http://www-106.ibm.com/developerworks/webservices/library/ws-arc1 (8 april 2003) http://www-106.ibm.com/developerworks/webservices/library/wsarc2.html (8 april 2003) http://www-106.ibm.com/developerworks/webservices/library/wsarc3/?open&l=809,t=grws,p=WSvsCORBA (8 april 2003) http://www-106.ibm.com/developerworks/library/ws-arc4 (8 april 2003) http://www-106.ibm.com/developerworks/webservices/library/ws-best5 (8 april 2003) http://www-106.ibm.com/developerworks/webservices/library/ws-best6 (8 april 2003) Mullender, M. & Burner. M., Application Architecture: Conceptual View, Microsoft Corporation: juli 2002. http://msdn.microsoft.com/library/en-us/dnea/html/distapp.asp (10 april 2003) Sonic Software Corporation, Understanding Service Oriented Architectures, 2002. http://www.sonicsoftware.com/sonic/sonicxq/whitepapers/understandi ng_service_oriented_architectures.pdf (7 april 2003) Vinoski, S., The Chief Architect’s View: Web Services, IONA Technologies: mei 2001. http://www.iona.com/sphere/is0501.html/#stevev (8 april 2003) Wang, W. et al, An Architecture Based Software Reliability Model, State University of New York: 2002. http://hera.csse.monash.edu.au/dsse/seminars/2002/00816223.pdf (10 april 2003)

88

Afsluiting: Afkortingen

A F S L U I T I N G

Afkortingen ACL ADL ADO ADS AI API ASN.1 ASP ASP B2B CIL CLR COM COMTI CORBA CRM CRUD DCE DCOM DNA DNS DSI DTC eAi EDI FTP GXA HTTP ICT IIOP ISV J2EE JNI JVM MOF MOP MQ OLE OMG OODB PDA QA RISC RPC SLA SMTP SOA UDDI UI

Access Control List Architecture Description Language ActiveX Data Objects Automated Deployment Services Artificial Intelligence Application Programming Interface Abstract Syntax Notation 1 Active Server Pages Application Service Provider Business to Business Common Intermediate Language Common Language Runtime Component Object Model COM Transaction Integrator Common Object Request Broker Architecture Customer Relationship Management Create, Retrieve, Update & Delete Distributed Computing Environment Distributed COM (Windows) Distributed interNet Architecture Domain Name System Dynamic Systems Initiative Distributed Transaction Coordinator enterprise Application integration Electronic Data Interchange File Transfer Protocol Global XML Web Services Architecture HyperText Transfer Protocol Informatie- en CommunicatieTechnologie Internet Inter-Orb Protocol Independent Software Vendor Java2 Enterprise Edition Java Native Interface Java Virtual Machine Meta Object Facility Meta Object Protocol Message Queues Object Linking and Embedding Object Management Group Object Oriented DataBase Personal Digital Assistant Quality Assurance Reduced Instruction Set Computer Remote Procedure Call Service Level Agreement Simple Mail Transfer Protocol Service Oriented Architecture Universal Description, Discovery & Integration User Interface

89


WSCA WSDL WSFL XDR XML

90

Web Services Conceptual Architecture Web Services Description Language Web Services Flow Language eXternal Data Representation eXtensible Markup Language

Afsluiting: Begrippenlijst

A F S L U I T I N G

Begrippenlijst access control list

een lijst met toegestane acties, die per object gedefinieerd wordt

application kernel

de applicatie-objecten die tot de kern van de applicatie behoren en geen relatie hebben met presentatiefuncties

application services

basale applicatiediensten zoals error handling, gateways, datatypes, datum- en tijdroutines, cetera

broker

een broker is verantwoordelijk voor communicatie tussen componenten

business logic

de logica die de functionaliteit of de business rules van een applicatie implementeert

code access security

beveiliging op assemblyniveau

content management

beheer van informatieverstrekking, meestal via een Internet portal of website

denial of service

het onmogelijk maken van de dienstverlening

distributed computing

vorm van computing waarbij applicaties en gegevens verspreid zijn over meer dan één computer, meestal over een netwerk

de

coördinatie

van

de

dynamische e-business volgende generatie e-business die zich richt op de integratie in de supply chain en infrastructurele complexiteiten van B2B activiteiten, gebaseerd op open Internetstandaarden e-business

zakendoen met behulp van elektronische hulpmiddelen, in het bijzonder het Internet

e-commerce

uitvoeren van financiële transacties met behulp van elektronische hulpmiddelen, in het bijzonder het Internet

elevation of privileges

illegaal verkrijgen van meer rechten

fat client

gebruikersapplicatie die naast voor de presentatie, ook voor de verwerking van gegevens verantwoordelijk is

information disclosure

illegaal publiceren van informatie

.NET framework

set technologieën ter ondersteuning van het applicatiegericht gebruik van het Internet, met name via XML Web Services, volgende generatie ontwikkelplatform

portability

de mate waarin het mogelijk is iets om te zetten van een platform naar een ander, bijvoorbeeld een Windows applicatie porten naar Linux

91


reification

expliciet maken van aspecten van de interne representatie van bijvoorbeeld een proces, zodat deze extern beschikbaar worden

repudiability

vermogen acties te ontkennen

sandbox

sterk gecontroleerde, beveiligde omgeving waarbinnen de mogelijkheden van applicaties beperkt worden ten opzichte van de buitenwereld

service

eenheid van informatie en verwerking waarmee functionele eenheden of andere services kunnen communiceren via een publieke interface

spoofing

een andere identiteit voorwenden

stijl

classificatie van architecturen op basis van bepaalde eigenschappen

supply chain

het netwerk van verkopers, distributeurs, transporteurs, opslagbedrijven en leveranciers betrokken bij de verkoop, bezorging en productie van een product

tampering

zonder toestemming wijzigingen aanbrengen

tier

set semantisch gerelateerd presentatiefuncties

tiered architecture

architectuur die is onderverdeeld in tiers

trust boundary

grens tussen twee domeinen met een verschillend niveau van vertrouwen, bijvoorbeeld tussen het Internet en het intranet

92

functies,

bijvoorbeeld

data-

of

Appendices

Appendix I: Opdracht

A P P E N D I X

I

Opdracht

I


A P P E N D I X

I I

Meetresultaten Memory Adapter 1

Working Set

Gemiddelde Maximum Minimum

2

100 18936722.64 19017728 15007744

1000 19351293.51 19447808 15024128

10.000 23279039.38 23822336 15040512

100.000 34312549.9 37224448 15028224

1.000.000 83197116.89 114008064 15044608

1 225685784.1 225791224 216636608

10 225722330 225832184 216513728

100 225803812.5 225914104 216513728

1000 226576167 226700536 216636608

10.000 234819864.9 235875576 216628416

100.000 251792847 271314168 216644800

1.000.000 487972549.8 590431524 216497632

10 184677.9029 15007744 0

100 184638.1359 15007744 0

1000 188813.6699 15024128 0

10.000 228938.5631 15040512 -372736

100.000 331696.466 15028224 -4374528

1.000.000 875708.8932 61956096 -20930560

Delta Working Set


II

10 18916839 19021824 15007744

Geheugen


3

1 18905545.32 18984960 15044608

1 184320 15044608 0

Appendix II: Meetresultaten Memory Adapter

4

Delta Geheugen


5

10 2192545.476 216513728 0

100 2193340.816 216513728 0

1000 2200976.078 216636608 0

10.000 2285123.029 216628416 -745472

100.000 2413955.689 216644800 -11493140

1.000.000 2192147.806 216636608 0

10 15922896

100 21831392

1000 38956016

10.000 244151072

100.000 2550166960

1.000.000 34757979520

10 154591.2233 4706768 0

100 211955.2621 4606624 0

1000 378213.7476 4406336 0

10.000 2370398.757 4506480 400576

100.000 24758902.52 28040320 1602304

1.000.000 337456111.8 363923296 2103024

Processortijd 1 15322032

Totaal

6

1 2192147.806 216636608 0

Delta Processortijd


1 148757.5922 4606624 0

III


A P P E N D I X

I I I

Meetresultaten File System Adapter 1

Working Set


2

100 20592341.75 20709376 15036416

1.000 23256451.73 24940544 15028224

10.000 22559574.99 25128960 15052800

1 226327165 226446808 216497296

10 226615797 226741720 216653328

100 228220990 228380080 216579224

1.000 222334715.8 236797360 215787316

10.000 220673484.6 237419864 216432056

10 192551.767 15028224 0

100 201061.9029 15036416 0

1.000 220826.0971 15028224 -1409024

10.000 219672.8544 15052800 -1466368

Delta Working Set


IV

10 19704782.29 19832832 15028224

Geheugen


3

1 19631491.73 19755008 15044608

1 191796.1942 15044608 0

: Meetresultaten File System Adapter

4

Delta Geheugen


5

10 2201375.922 216653328 -8192

100 2217282.33 216579224 0

1.000 2105565.398 216514064 -11452180

10.000 2127196.233 216432056 -10829660

1 18726928

10 32246368

100 186267840

1.000 1709958800

10.000 17662397280

10 313071.534 4506480 0

100 1808425.631 4406336 701008

1.000 16601541.75 19327792 2103024

10.000 171479585.2 181360784 1502160

Processortijd

Totaal

6

1 2198512.699 216497296 -8192

Delta Processortijd


1 181814.835 4907056 0

V


A P P E N D I X

I V

Data Interface using System; namespace Windex { namespace Data { /// <summary> /// Interface for data adapters /// public interface IDataAdapter { /// <summary> /// Gets the PersistencyOption that this Data Adapter /// implements /// PersistencyOption Persistency{get;} /// <summary> /// Stores an object and returns a globally unique /// identifier that is assigned to the object. /// /// <param name="obj">The object to be stored /// A GUID for the object Guid StoreObject(object obj); /// <summary> /// Stores an object with a supplied GUID. If storing is /// successful, true is returned, false otherwise. /// /// <param name="obj">The object to be stored /// <param name="id">The GUID to be assigned to the /// /// object /// True if storing is successful, false /// otherwise bool StoreObjectWithId(object obj, Guid id); /// <summary> /// Gets an object, identified by the supplied GUID /// /// <param name="id">GUID identifying the object /// The object corresponding to the GUID, or null /// if no corresponding object could be found object GetObject(Guid id); /// <summary> /// Gets all objects of a given type /// /// <param name="type">The type of the objects to be /// returned /// An array of all corresponding objects, or /// null if no corresponding objects exist object[] GetObjects(Type type); /// <summary> /// Updates an object identified by the supplied GUID with /// the values in obj /// /// <param name="id">GUID of the object to be /// updated /// <param name="obj">Object containing the new

VI

Appendix IV: Data Interface

/// values /// True if updating was successful, false /// otherwise bool UpdateObject(Guid id, object obj); /// <summary> /// Updates the supplied field of an object identified by /// the supplied GUID with the supplied value /// /// <param name="id">The GUID identifying the object to be /// updated /// <param name="field">The field to be updated /// <param name="val">The new value of the field /// True if updating was successful, false /// otherwise bool UpdateObjectField(Guid id, string field, object val); /// <summary> /// Deletes the object identified by the supplied GUID /// /// <param name="id">The GUID of the object to be /// deleted /// True if deletion was successful, false /// otherwise bool DeleteObject(Guid id); /// <summary> /// Gets all objects (via their id's) registered with this /// adapter /// /// An array of Guids denoting the /// objects Guid[] GetAllObjects(); } /// <summary> /// Holds the options for persistency /// public enum PersistencyOption { /// <summary> /// Uses the filesystem for storage /// FILESYSTEM = 1, /// <summary> /// Uses a SQL database for storage /// SQL = 2, /// <summary> /// Uses an in-memory solution for storage /// MEMORY = 4 }

VII


A P P E N D I X

I V

Quality-of-Service aware Broker De Quality-of-Service (QoS) aware Broker is een zelfbewuste, zelfconfigurerende broker die transparantie biedt van configuratie en herconfiguratie boven de normale transparantie van communicatie en lokatie. De QoS aware Broker wordt gepresenteerd als mogelijke oplossing voor het schaalbaarheids- en flexibiliteitsvraagstuk. Er wordt verder geen implementatie of uitputtende specificatie van gegeven. Dit zou wel onderdeel kunnen zijn van een vervolg op deze opdracht.

1

De Broker Architectural Framework Volgens Andrew S. Tannenbaum hebben gedistribueerde systemen één belangrijk nadeel: “[Gedistribueerde systemen] hebben radicaal andere software nodig dan gecentraliseerde systemen” Mede hierdoor zijn er de afgelopen jaren zoveel middleware platformen ontstaan: CORBA, Object Linking & Embedding (OLE), Distributed Computing Environment (DCE), DCOM, J2EE en recent .NET. Uit CORBA, OLE en DCE is de Broker Architectural Framework (BAF) afgeleid [STA95]. BAF kan toegepast worden op op structuur gedistribueerde systemen met ontkoppelde componenten die interactie hebben met elkaar via remote service invocations. Een broker is verantwoordelijk voor de coördinatie van de communicatie en het versturen van resultaten en exceptions.

1.1 Beschrijving Componenten die samenwerken, communiceren. Als de componenten de communicatie zelf implementeren, kan dat leiden tot ongewenste afhankelijkheden, redundantie van code, een slechte onderhoudbaarheid en een slechte herbruikbaarheid van de componenten. Een broker is een extra component, die de verantwoordelijkheden van de communicatie transparant maakt. Componenten registreren zich bij de broker en maken hun diensten kenbaar bij de broker middels interfaces. Dit zijn de (service) providers. Andere componenten communiceren met de broker, zoeken daar de interfaces en maken zo gebruik van de diensten. Dit zijn de (service) consumers. De componenten hoeven alleen te weten hoe ze met de broker moeten communiceren.

1.2 Structuur De BAF bestaat uit een zestal componenten: de server, de client, de broker, de client-side en de server-side proxy en de bridge.

VIII

Appendix IV: Quality-of-Service aware Broker

FIGUUR 37: BROKER ARCHITECTURAL FRAMEWORK

Een server implementeert een service interface, een bundeling van semantisch gerelateerde attributen en operaties. De geïmplementeerde service interfaces worden geregistreerd bij de broker. Een client gebruikt ten minste één service bij ten minste één server. De client zendt hiertoe requests naar de broker, van wie hij de resultaten en eventuele exceptions ontvangt. De broker publiceert service interfaces, regelt de communicatie tussen clients en servers en kan Quality of Service taken uitvoeren, zoals load-balancing en application services zoals marshalling23 en naamgeving24. De client-side proxy en de server-side proxy abstraheren van het brokermodel naar respectievelijk de client en de server toe. Ook kan de proxy abstraheren van de lokatie van de client/server om bijvoorbeeld mobiele omgevingen te ondersteunen. De bridge is een optioneel component dat abstraheert van de brokers, zodat deze ondanks implementatieverschillen met elkaar kunnen communiceren.

1.3 Voor- en nadelen Dit model kent vele voordelen [NEW01]. Omdat de broker abstraheert van de communicatie voor de componenten, hoeven de componenten daar geen kennis meer van te hebben. De broker abstraheert echter ook de rol die een component speelt in een applicatie. Componenten zijn daardoor niet gekoppeld aan een applicatie-context. 23

Bij marshalling worden interne daterepresentaties omgezet in algemene representatives, meestal volgens een standaard als Abstract Syntax Notation 1 (ASN.1), eXternal Data Representation (XDR) of XML. 24 Naamgeving zorgt ervoor dat er een koppeling wordt aangemaakt tussen interne ID’s en voor mensen makkelijk te onthouden en gebruiken namen. Vgl. Domain Name System (DNS).

IX


Extensibility is ook een voordeel. Zolang de interfaces gelijk blijven, kan alles veranderen: de fysieke providers kunnen wisselen, de implementatie van de providers kan veranderen en de broker kan intern veranderen zonder dat de dienstverlening hiervan schade ondervindt. Een ander voordeel is portability. De details van besturingssystemen en netwerken worden verborgen door de broker, waardoor de consumers en providers eenvoudig kunnen worden ingezet in heterogene omgevingen. Daarnaast is er nog een speciale broker: de bridge. Deze broker doet dienst tussen verschillende brokers en abstraheert van de communicatie tussen brokers. Dit zorgt voor interoperability. Het servicemodel zorgt voor een nieuwe manier van software ontwikkelen. Applicaties kunnen namelijk voor een belangrijk deel worden ingevuld door services te integreren. Services kunnen zo keer op keer herbruikt worden (reusability). Tenslotte verbergen brokers ook de fysieke lokaties van componenten. Componenten kunnen zich daardoor vrijelijk door het netwerk bewegen en load-balancing en fail-over technieken zijn makkelijker toe te passen (transparency). Er zijn ook enkele nadelen aan het gebruik van brokers. Ten eerste is het minder efficiënt, omdat de extra abstracties overhead introduceren en er generieker moet worden gewerkt. Omdat een fout in het netwerk ervoor kan zorgen dat een service (of de hele applicatie) niet meer werkt, is het ook minder fout-tolerant. Het testen en debuggen van applicaties is ook moeilijker, omdat fouten minder goed te lokaliseren zijn.

1.4 Varianten Er zijn een aantal varianten van BAF, die elk vanuit een andere doelstelling ontwikkeld zijn. Hieronder worden een aantal populaire varianten genoemd. Direct Communication Broker Systems gebruiken de broker alleen voor lokatiebepaling van servers, als een soort Gouden Gids. Clients communiceren verder rechtstreeks met de server. Message Passing Broker Systems richten zich op het doorsturen van gegevens, in plaats van varianten op Remote Procedure Calls (RPC). Clients sturen geen requests, maar documenten. Servers bepalen wat te doen aan de hand van de inhoud van een document (documentmetafoor). Trader Systems abstraheren van de servers. Er ontstaat dan een marktplaats voor services, waar de trader (de broker) voor de client bepaalt welke server de client moet gebruiken aan de hand van een set eisen die de client meegeeft.

X


Adapter Broker Systems abstraheren van de brokers, om zo meerdere middleware platformen te kunnen ondersteunen, zoals DCOM en CORBA. Callback Broker Systems gebruiken geen actief, door clients gestuurd communicatiemodel, maar een reactief, door events gestuurd model. De broker reageert op events door een callback te doen naar het corresponderende component. Er bestaat vanuit de broker gezien geen onderscheid tussen clients en servers.

2

Brokering for quality In essentie is een QoS aware Broker een broker die zich bewust is van de kwaliteit van de dienstverlening. Door actief te monitoren of de dienstverlening voldoet aan een prestatiecontract (SLA) en actie te ondernemen als dit niet zo is (de broker is bijvoorbeeld zelf in staat extra providers te activeren als dit nodig is), garandeert de QoS aware Broker het serviceniveau, zonder dat er mensen nodig zijn die het systeem continu onderhouden. Quality of Service aspecten zijn kwaliteitsaspecten van een service, zoals servicetijd, betrouwbaarheid, consistentie, beschikbaarheid, et cetera. Deze kunnen onderdeel gemaakt worden van een SLA. Application Service Providers (ASP) kunnen dit gebruiken als onderdeel van hun dienstverlening.

3

Uitdagingen voor de QoS aware Broker De pool van replica’s die een QoS aware Broker moet beheren, brengt zijn eigen uitdagingen met zich mee. Niet alleen moet de broker bepalen wanneer een nieuwe replica moet worden aangemaakt, ook moet de broker bepalen waar dit moet gebeuren, hoeveel replica’s er nodig zijn en in welke toestand deze replica’s gebracht moeten worden.

Wanneer

Het moment van replicatie is belangrijk: te laat en de dienstverlening voldoet niet langer aan de SLA. Te vroeg, en er is sprake van onnodige overhead (waardoor mogelijk ook niet aan de SLA voldaan kan worden). Het moment kan bepaald worden met een kansberekening van de kans dat aan de SLA voldaan kan worden. Met behulp van omslagtrajecten, voorzichtige en just-in-time replicatie, et cetera kan dan het juiste moment bepaald worden.

Waar

Repliceren op plaatsen in het netwerk waar de belasting al hoog is, is weinig efficiënt. De broker moet daarom ook een juiste plaats voor een replica kunnen bepalen. Netwerkmonitoren moeten de broker ondersteunen bij het inspecteren van het netwerk. Ook moet de broker bepalen welke server zijn service moet activeren. Dit kan gedaan worden op basis van belasting van de server of vermogen, of een andere eigenschap. De broker moet dus ook servers kunnen inspecteren.

XI


Het aantal

Het aantal replica’s dat de broker moet aanmaken kan een eenvoudige incrementele stap zijn, maar er kan ook gekozen worden voor een dynamische stap, waarbij het aantal wordt bepaald aan de hand van een analytisch model. Het analytisch model bepaalt dan welke graad van replicatie noodzakelijk is om, binnen een bepaalde betrouwbaarheid, te voldoen aan de QoS-eisen.

Toestand

Als replica’s een bepaalde toestand kunnen hebben, dient de broker hier ook rekening mee te houden. De broker zou iedere replica onmiddellijk in de juiste toestand kunnen brengen, maar dit kan leiden tot extra netwerkbelasting in de vorm van de extra berichten. De replica zou ook in een initiële toestand gebracht kunnen worden, en pas in de juiste toestand als dit nodig is. Er zijn ook andere strategieën mogelijk: verder onderzoek zal dus moeten uitwijzen welke strategie de beste is.

Selectie

Als een broker eenmaal een pool van replica’s tot zijn beschikking heeft, wordt het belangrijk een goede selectiestrategie te gebruiken. Er kan gekozen worden voor een random selectie, maar ook hier is het mogelijk om via deterministisch-analytische modellen de selectie uit te voeren.

Consistentie

Het hebben van replica’s brengt een belangrijke uitdaging met zich mee: het consistent houden van alle replica’s. Alle replica’s moeten immers in principe dezelfde informatie hebben en op dezelfde manier functioneren. De twee uitersten hier zijn absolute/pessimistische consistentie en relatieve/optimistische consistentie. Deze verschillen erin, dat bij absolute consistentie alle replica’s altijd up-to-date zijn, terwijl bij relatieve consistentie alleen gegarandeerd wordt dat de replica’s uiteindelijk over dezelfde informatie beschikken.

Serviceverlening

De gekozen consistentiestrategie heeft ook gevolgen voor de serviceverlening: bij absolute consistentie wordt altijd het juiste antwoord gegeven, maar ligt de serviceverlening stil tijdens het updaten van de replica’s. Bij relatieve consistentie wordt altijd een consistent, maar niet noodzakelijk juist, antwoord gegeven en kan de serviceverlening doorgaan tijdens de update. Zeker als er onbetrouwbare replica’s zijn, zoals in mobiele netwerken, is relatieve consistentie te prefereren boven absolute. Relatieve consistentie verhoogt de autonomie van replicahosts, omdat minder coördinatie nodig is. Er zou bijvoorbeeld gebruikgemaakt kunnen worden van een sneeuwbalachtig peer-to-peer updatemechanisme, waarbij replica’s de update doorzenden naar replica’s in de buurt (peers) en niet rapporteren aan de broker, maar aan de replica die hun de update doorzond.

4

De QoS aware Broker en schaalbaarheid en flexibiliteit De schaalbaarheid van een gedistribueerd, servicegeoriënteerd systeem kan gegarandeerd worden door de QoS aware Broker, omdat deze er zorg voor kan dragen dat de prestaties nooit beneden een bepaalde grens komen. De broker zelf is echter een

XII


verzamelpunt van verkeer, wat betekent dat bij een te zware belasting van de broker zelf, de prestaties alsnog afnemen. Door de broker zelf ook te repliceren en te distribueren kan dit opgelost worden. De brokers moeten dan in staat zijn om met elkaar te communiceren, maar kunnen wel autonomiegrenzen vormen. Er is dan steeds één broker verantwoordelijk voor een bepaald subnet van clients en servers. De flexibiliteit wordt ook door de broker verhoogd, door de abstractie van lokatie en communicatie. Clients en servers hoeven elkaars lokatie niet te kennen, en hoeven ook niet te weten hoe gecommuniceerd moet worden. De afhankelijkheden van clients en servers zijn beperkt tot de broker, en zolang de door de broker gedefinieerde interfaces netjes worden geïmplementeerd, kan iedere willekeurige client met iedere willekeurige server communiceren. Tenslotte voorziet de broker in zelfconfigurerende en zelfbewuste eigenschappen voor het systeem. Dit is ook een verbetering van de flexibiliteit.

XIII

Een servicegeoriënteerde architectuur voor Customer Relationship Management Strategieën voor verbeterde schaalbaarheid en flexibiliteit

Recommend Documents