meavitasoa jeroen j van beele jan blom 21

meavita-soa jeroen j van beele, jan blom 21 april 2006 versie 1. 0

inhoud 1. 2. 3. 4. 5. 6. kader uitgangspunten soa implementatie onderbouwing architectuurprincipes

1. kader 1. 1. organisatieparadigma 1. 2. belanghebbenden 1. 3. belangen 1. 4. ict-architectuur

1. 1. organisatieparadigma • aspectsystemen – eigen dynamiek / evolutie • afstemming

1. 2. belanghebbenden • rvb • eigenaren / gebruikers • ict – ontwikkeling – beheer

1. 3. belangen • funxionaliteit • beheerbaarheid • evolueerbaarheid / flexibiliteit – een systeem is flexibel als de benodigde inspanning voor een wijziging overeenkomt met de omvang van de wijziging (ipv met de omvang van het systeem)

1. 4. ict-architectuur 1. 4. 1. beelden 1. 4. 2. doel 1. 4. 3. definitie 1. 4. 4. elementen 1. 4. 5. aspectarchitecturen

1. 4. 1. beelden ict-architectuur • ict is als de fusie in een studentenhuis • ict-architectuur is als het netjes achterlaten van de wc terwijl je de trein nog wilt halen

1. 4. 2. doel ict-architectuur • er voor zorgen dat de evolutie van de ictportfolio zo goed mogelijk aansluit bij de behoeften van de organisatie

1. 4. 3. definitie ict-architectuur • ict-architectuur is het behartigen van de lange termijn belangen van een organisatie bij haar ict • ict-architectuur is dat wat moeilijk te veranderen is (naar chris verhoef)

1. 4. 4. elementen ict-architectuur • it-governance • ict-architectuurprincipes • blauwdrukken (aspectarchitecturen) – metamodellen – ontwerpen

1. 4. 5. aspectarchitecturen • • • ontwikkel beheer beveiliging infrastructuur gegevens applicatie

2. uitgangspunten • soa • cots

3. soa 3. 1. business en ict 3. 2. elementen soa voor ict 3. 2. 1. common data model 3. 2. 2. componenten 3. 2. 3. diensten 3. 3. berichten 3. 4. versiebeheer 3. 5. eigenaren

3. 1. business en ict • business moet soa denken • ict moet soa werken • business en ict kunnen dan soa met elkaar praten

3. 2. elementen soa voor ict • common data model (cdm) • componenten met interfaces • bestaande uit diensten gedefinieerd mbv contracten • dit wordt technisch ingevuld door de esb

interface dienst component . . . subcomponent gegevens

3. 2. 1. common datamodel (cdm) • het cdm heeft een versie

3. 2. 2. componenten • componenten zijn hierarchisch genest • een component bestaat (precies) uit – een binnen de soe unieke naam – een eigenaar – de naam van 1 parentcomponent – de namen van onderliggende componenten – 1 datamodel (kan afwijken van cdm) – interface bestaande uit aangeboden diensten

indeling in componenten • hier is nog geen duidelijkheid over • een pakket is een candidaat voor een component • het lijkt er op dat componenten idealiter diensten en gegevens samenbrengen die meer cocommuniceren dan adcommuniceren • binnen een component mogen diensten elkaar onder water (ie buiten de esb om) aanroepen

3. 2. 3. diensten • er zijn twee soorten diensten – atomaire diensten • kunnen workflow bevatten • roepen nooit andere diensten aan – composite diensten • bestaat uitsluitend uit workflow • die andere (atomaire en composite) diensten aanroept • diensten ontsluiten cots

composite diensten • een composite dienst kan diensten aanroepen van – de eigen component – de (direct) onderliggende componenten – een dienst aangeboden door een onderliggende component kan door zijn parentcomponent aangeboden worden door deze dienst expliciet door de parentcomponent aan te laten bieden • status bevindt zich altijd in een dienst – en niet daartussen, ie geen pre-/postcondities

contract • een dienst wordt (precies) gedefinieerd mbv – implementatiedocumentatie – authorisatieadministratie • wie mag welke diensten gebruiken – contract • • • aanroepnaam eigenaar versie beschrijving benodigde gegevens voor de aanroep (cdm) resultaat van de aanroep (cdm)

contract (vervolg) • responstijd • quality of service (qos) • foutafhandeling – technisch – business • precondities (liefst geen) • postcondities (liefst geen)

datatoegang • een (atomaire) dienst mag alleen gegevens van zijn eigen component direct benaderen • gegevens van andere componenten kunnen alleen benaderd worden (door composite diensten) als die gegevens door die component middels een (atomaire) dienst beschikbaar zijn gesteld • uitzondering: bulk read voor bijvoorbeeld managementinformatie (mi) kan wel

resultaat • het resultaat van een dienst is – impact op de werkelijkheid, waaronder de gegevens – opgeleverde gegevens • in de 2 e orde kan een dienst (zoals ontwikkelen van services) als impact een wijziging van de soa hebben

quality of service • de verwachting van de esb kan bestaan uit – fire & forget (best effort) – store & forward – synchroon voor workflow? • er zijn meer mogelijkheden die we hier voorlopig buiten beschouwing laten

3. 3. berichten • hebben een afzender oa ivm – authorisatie – return van output • hebben een ontvanger? • zijn gesteld in het cdm (van een versie) • als in een component (bijv in een cots) een ander datamodel gebruikt is, wordt het interne model altijd op het cdm gemapt – mapping in component, niet in esb of adapter?

3. 4. versiebeheer • er is versiebeheer voor – cdm – diensten – componentdatamodellen

3. 5. eigenaren • • esb (infra + beheer) authorisatiemodel component dienst proces (binnen dienst) orchestratie / choreography data / cdm per component authorisaties • • directeur ict scc business diensteigenaar business

4. implementatie 4. 1. flow 4. 2. deadlock 4. 3. eisen componenten en cots 4. 4. esb

4. 1. flow • alle flow ligt in diensten – diensten worden getriggerd door applicaties of composite diensten • we willen liefst 1 tool gebruiken om flow in vast te leggen – taskflow kan wel in workflowtools vastgelegd worden maar niet andersom • dus business works niet gebruiken • behalve om performanceredenen

4. 2. deadlock • om deadlock te voorkomen dienen timers gebruikt te worden

4. 3. eisen componenten en cots • binnen componenten moet onderhoud mogelijk zijn zonder rekening te hoeven houden met wat er aan de andere kant van de interface gebeurt • cots moeten zo over componenten gespreid (ontsloten) kunnen worden dat delen in verschillende componenten los van elkaar staan

4. 4. esb • de bus is er voor het transport van berichtenverkeer en meer niet, dus niet voor – vertalen – authenticatie / authorisatie – monitoring • esb-toolonafhankelijk implementeren – dus jms ipv rendez vous

5. onderbouwing • wijzigingen hebben nu impact binnen verschillende componenten • daardoor is het werk in beheersbare stukken opgedeeld • de opdeling waarnaar we zochten is dus een scheiding in twee niveaux – interface (diensten en hun interaxie) – implementatie van componenten

6. architectuurprincipes • tbd