hoe definieer je een service? jeroen j van beele 14 december 2006

inhoud inleiding historisch perspectief wie zijn soa en soe? uitdaging en preciesering vraag ideeen en discussie

inleiding service oriented architecture (soa) wie zijn soa en soe? dienst georienteerde architectuur wie zijn soa en soe? een kernvraag: hoe definieer je een service?

historisch perspectief problemen in het vakgebied ict evolueerbaarheid beheersbaarheid, door afbakening oplossingen: oo, cbd en soa

in den beginne was er werk

toen werd er geautomatiseerd

er werd meer geautomatiseerd

groeit uit tot eilandautomatisering

wijzigingswet zonder maatregelen geldt: de hoeveelheid werk die nodig is om een wijziging door te voeren is evenredig met de omvang van het te wijzigen systeem als een systeem klein is is dat niet zo erg

eai complexiteitscatastrophe (chis verhoef)

stovepipes

eai

opnieuw maar anders scheiden

is dit een applicatielandschap?

mom: tight coupling a b systeem a heeft kennis over systeem b

soa: loose coupling de soa heeft kennis over systeem b a b

dit is een funxie- en codelandschap met een scheiding tussen de ongelijksoortige integratie- en implementatielaag integratie dienst implementatie scheiding

wie zijn soa en soe? soa = service oriented architecture soe = service oriented environment

meavita soe architectuurprincipes soa cots

elementen van soa common data model (cdm) componenten met interfaces bestaande uit diensten gedefinieerd mbv contracten workflowengines (op technisch niveau is er de esb)

interface dienst component ... .. ... ... gegevens subcomponent

servicedefinitie 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) Een dienst wordt volledig beschreven door zijn implementatiedocumentatie, authorisatieadministratie en contract. Dienstaanroepen worden geadministreerd zodat van elke dienst bekend is door welke andere (altijd composite) diensten hij / zij aangeroepen wordt. Het contract bevat de op deze en de volgende slide genoemde elementen, daarover het volgende: de eigenaar is de Meavitarol die verantwoordelijk is voor de inhoud van de dienst de versie is het versienummer van dit contract in de beschrijving staat wat de dienst doet, voor een compsite dienst is dat de workflow die de dienst implementeert diensten communiceren altijd door het uitwisselen van berichten die conform het CDM opgesteld zijn, dwz: in de in- en output van een dienst komen uitsluitend velden voor die in het CDM van een gespecificeerde versie geidentificeerd zijn

servicedefinitie (vervolg) responstijd quality of service (qos) foutafhandeling technisch business precondities (liefst geen) postcondities (liefst geen) de responstijd geeft aan binnen hoeveel tijd de dienst uiterlijk gerealiseerd moet zijn, het niet halen van deze timeout resulteert in een businessexception waar in de foutafhandeling (zie volgende slide) in voorzien dient te zijn de quality of service kan een van twee mogelijkheden zijn (hier is nog meer over te zegen): fire & forget (doorgaans voor publish & subscribe) store & forward (doorgaans voor request & reply) De meeste (zoniet alle) communicatie zal request / reply zijn. er worden twee soorten exceptions onderkend: technisch (bijvoorbeeld database down) mogelijk wordt voor een technische fout in een reactie voorzien elke technische fout wordt centraal gelogd en als de dienst zelf niet in een reactie voorziet dan wordt dat centraal geregeld business (bijvoorbeeld klant niet verzekerd) voor elke businessfout dient in een reactie / oplossing voorzien te zijn mogelijk wordt het optreden van een dergelijke fout centraal gelogd pre- en postcondities worden (aanvankelijk nog) toegestaan maar doel is om ze te vermijden, diensten worden zoveel mogelijk zo opgezet dat zij onafhankelijk van status of context kunnen worden aangeroepen

uitdaging en vraag uitdaging vraag organisatorisch technisch pre- en postcondities lagen? specificatie en implementatie front office/mid office/back office presentatie/flow/verwerking/gegevens business services/atomaire services mate van adhesie

vraag how to (formally!) describe pre- and postconditions? what (from an agility point of view useful?) levels of allowed pre-/postconditions can we define? how can we check that the implementation of a service indeed does not presuppose anything outside the interface definition?

uitleg services need to know what to expect of each other the main design principle of soa is that in order to know the expectations of a service it suffices to know the interface of that service so how to describe the interface of a service? in other words: how to describe the expectations of a service? at least in- and ouput should be described but this is not enough. examples: suppose a service updates status. the status is neither in the in- nor in the output definition, but obviously status is part of the expectations. what can we do here? a first idea is that status should be part of the common data model (cdm) which serves as a context in which the service acquires meaning. suppose we want to define a service "enroll new customer". this service has to check whether the candidate customer is not already enrolled. we could design the "enroll new customer" service as a composite service calling the 2 atomic services "check existence customer" and "register new customer". when designing in this way the service "register new customer" presupposes (expects) that the candidate customer doesn't exist yet. how can we describe this expectation in the definition of the service? my idea is to use pre- and postconditons.

uitleg i learnt that pre- and postconditions are not what i want. but now i am inclined to differentiate this view. i can image there are several levels (like composite and atomic) at which services can be defined. each level allows more or less pre- and postconditions. at the highest level neither pre- nor postconditions are allowed, going down the hierarchy more and more conditions are allowed. in this way the coupling becomes tighter downwards in the hierarchy and looser upwards. all together this means that a soa consists of cdm levels of allowed pre-/postconditions services defined using level in-/output pre-/postconditions conforming to its level qos

ideeen en discussie demo archimate

dank voor uw bijdrage

scheiden in lagen de oplossing die we voorstellen is een scheiding in 2 lagen specificatielaag implementatielaag

specificatielaag we willen voor de specificatielaag een taal ontwikkelen waarin we kunnen servicecontracten specificeren interaxie tussen diensten vastleggen idealiter is deze soa-taal het kader waarbinnen implementaties gehangen worden zo kan er compile-time gecontroleerd worden of de implementatie overeenkomt met de specificatie en is dus de documentatie op orde

specificatielaag met de business is te praten in de businessview van deze taal welke taal is dit? wsdl? bpel?

implementatielaag in de specificatielaag staan de interfaces beschreven volgens welke de diensten in de ict-portfolio gehangen dienen te worden de implementatie van diensten dient onafhankelijk van de rest van de ict-portfolio te geschieden dwz dat de implementatie alleen gebruik maakt van elementen van de ict-portfolio via de gespecificeerde interfaces en niet direct

eis de dienstenlaag is self contained dwz je hebt de implementatielaag niet nodig om te snappen hoe de diensten gezamelijk hun funxionaliteit realiseren dat betekent dat de aanroepen van diensten in diezelfde dienstenlaag geregistreerd worden de implementerende code mag alleen via de dienstenlaag communiceren buiten zichzelf

integratie en implementatie mom begon met een dunne integratielaag daardoor leverde dat tight coupling op als je de integratielaag dikker maakt wordt de coupling looser, maar hoe dik? voorstel: laat de integratielaag bestaan uit businessbeschrijvingen – demo (dietz) entiteiten activiteiten (wsdl) flow (bpel)

bewustzijn ict vervangt runtime bewustzijn door designtime bewustzijn hierdoor is runtime bewustzijn zinloos geworden

filosofie de problematiek van de ict is een veelkoppig monster de twee belangrijkste constanten zijn wat mij betreft niveau van it-ers te laag voor hun werk tools die teveel vrijheid laten waar it-ers van onvoldoende niveau de verkeerde wegen in kiezen op technisch niveau resulteert dat in een wirwar

wirwar die wirwar bestaat uit conceptueel enkelvoudige eenheden zijn in meerdere onafhankelijk van elkaar te ontwikkelen delen gesplitst bijvoorbeeld funxionaliteit is meervoudig geimplementeerd conceptueel meervoudige composities zijn als enkelvoudige eenheden uitgevoerd bijvoorbeeld monolieten

funxionaliteit een traditionele scheiding is maar funxionaliteit kent data funxionaliteit maar funxionaliteit kent verwerking flow die wirwar ligt voor mijn gevoel voor een belangrijk deel in impliciete flow

flow dient geisoleerd te worden en komt daarmee expliciet in bijvoorbeeld een bpm-tool te liggen

bewustzijn it-systemen kennen van zichzelf geen bewustzijn alleen design-time zijn de ontwerpers bewust en niet de it-systemen (in wording) maw: een it-systeem kan niet controleren of zijn (ongecontroleerde) gedrag zich aan het fo conformeert

controle voor run-time controle is nodig in- en overzicht bewustzijn dezen bestaan alleen op humanoide niveau

controle ik geloof dat controle nodig is als je controle een vies woord vindt mag je ook spreken van (vertrouwen op) invloed of bewustzijn mijn idee is dat je design-time controle alleen kunt kunt verlaten tgv run-time controle dus niet voor maar tijdens executie

organism metaphor mutation level cell growth organism reproduction species evolution cycle short longer long dna unchanged changes restructure change restricted more complete

organism metaphor applied mutation level new version new funxionality new way of working cycle short longer long spex unchanged changes restructure develpment rebuild redesign change ide

3e-model: entity - execution - event 3f-model: fact - function - flow 3g-model: gegeven - gedrag - gebeurtenis entity execution event relation

example 1 1 customer order line N N 1 N 1 product yes check stock ok issue order 1 1 1 no order yes check credit no

implementation: molecules wf da ... ...

growth through splitting how to grow an information system from spex see spex as if they are dna and a developer as the cell that contains it grow means splitting cell splitting cells means copying dna, ie: the developer copies the spex to a fellow developer and they decide who does what

split along borders in order to distribute the work borders have to be drawn

growth through splitting molecules there is no presentation layer because humans are molecules alike dna = detailed spex of wf, da and verwerking andere manier: laat moleculen krimpen of groeien om zo de impact van een wijziging te vangen dat kan virtueel zijn: nadat de wijziging ontworpen is kan via de inverse groei of krimp het ontwerp per molecuul worden gespecificeerd

architectuurprincipes de bus is er voor het transport van berichtenverkeer en meer niet 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

architectuurprincipes alle flow ligt in (verschillende) workflows dus diensten roepen elkaar niet aan diensten worden steeds aangeroepen vanuit een workflow applicaties en diensten kunnen workflow triggeren workflow bevat state en context binnen een component mogen diensten elkaar onder water (ie buiten de esb om) aanroepen

architectuurprincipes mapping altijd van / naar cdm altijd in service zelf implementeren separation of concerns dus niet in adapter of bus esb-toolonafhankelijk implementeren dus jms ipv rendez vous

architectuurprincipes een dienst wordt beschreven dmv contract implementatiedocumentatie er is een aparte authorisatieadministratie die controleert wie welke diensten mag gebruiken dit staat niet in het contract van een dienst afhandeling van errors staat wel in contract beschreven (applicatief en technisch)

onderbouwing wijzigingen hebben nu impact binnen verschillende componenten daardoor is het werk in beheersbare stukken opgedeeld de eis aan componenten is dus dat daarbinnen onderhoud mogelijk moet zijn zonder rekening te hoeven houden met wat er aan de andere kant van de interface gebeurt

onderbouwing de opdeling waarnaar we zochten is dus een scheiding in twee niveaux interface (diensten en workflow) implementatie van componenten hoe kunnen cots over de componenten verspreid worden – gescheiden ontsluiting?

cots en soa map de cots op een vsd conform de soa-lagenarchitectuur transformeer de vsd naar een fsd (fysical service description) wijzigingen kun je localiseren in de vsd en hebben daar beperkte impact de facto vinden de wijzigingen plaats in de fsd en daardoor gaat er mogelijk meer overhoop

randvoorwaarden services stateless contextless passen in precies 1 laag

onderdelen organisatie techniek ict biz logisch fysiek cdm services bus data/applicaties

cots worden ontsloten middels services die waar mogelijk zich aan de lagenstructuur conformeren.

lagen flow presentatie verwerking data

1.4.2. doel ict-architectuur er voor zorgen dat de evolutie van de ict-portfolio zo goed mogelijk aansluit bij de behoeften van de organisatie Vanuit de aspectsysteemgedachte evolueert de ICT-portfolio, met een dynamiek die wezenlijk verschilt van die van de business, niet zomaar in aansluiting op de behoeften van de business. Het doel van de ICT-architectuur is daarom de evolutie van de ICT-portfolio zo te sturen dat die zo goed mogelijk aansluit op de behoeften van de business.

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) Er zijn reeds vele definities van ICT-architectuur gegeven, hier volgen er twee die vanuit verschillende perspectieven naar het vakgebied kijken. Ook IEEE 1471-2000 geeft een mooie definitie.

1.4.4. elementen ict-architectuur it-governance ict-architectuurprincipes blauwdrukken (aspectarchitecturen) metamodellen ontwerpen Over wat een ICT-architectuur is lopen de meningen behoorlijk uiteen. Over de kern is men het wel ongeveer eens maar in concrete organisatiesituaties worden allerlei aspecten toegevoegd of weggelaten. Ook over hoe de verschillende ICT-architectuuraspecten ingevuld kunnen worden lopen de inzichten behoorlijk uiteen. Waar een ICT-architect in ieder geval mee te maken krijgt is dat hij zich behalve met het opstellen van het beleid ook bezig moet houden met het realiseren van dat beleid. Vandaar dat IT-governance een onontbeerlijk onderdeel is van ICT-architectuur. Er zijn twee hoofdgebieden die als het gaat om de invulling van ICT-architectuur van belang zijn: principes en blauwdrukken. Zoals de meesten nemen wij beide op en verwijzen met een zoete glimlach naar de levendige discussie hieromtrent. Principes zijn richtlijnen, uitspraken die richting geven aan de ontwerpen van ICT. Blauwdrukken zijn ontwerpen conform die principes. Blauwdrukken bestaan doorgaans uit collecties aspectarchitecturen. Voor zowel principes als blauwdrukken is een grote varieteit aan architectuurraamwerken en metamodellen in omloop.

1.4.5. aspectarchitecturen ontwikkel beheer beveiliging infrastructuur gegevens applicatie Ook het ICT-aspectsysteem kent (sub)aspectsystemen. Hier worden de meest gangbare genoemd. Tegen deze achtergrond wordt het mogelijk SOA te definieren. SOA bevindt zich voornamelijk, maar niet uitsluitend, op applicatiegebied. Naast ICT-architectuur onderkent met tegenwoordig ook enterprice architectuur waar ICT-architectuur een onderdeel van uitmaakt. Een ander onderdeel van enterprise architectuur is dan bijvoorbeeld businessarchitectuur. Wij gaan daar hier verder niet op in.

1.1. organisatieparadigma aspectsystemen eigen dynamiek / evolutie afstemming Het organisatieparadigma van waaruit de ICT-architectuur en SOA worden gedefinieerd is een systeemtheoretische. Zonder hier op de gehanteerde definitie van systeem (op deze slide steeds in cybernetische zin) in te gaan is de belangrijkste observatie dat organisaties (als systemen) verschillende aspectsystemen kennen. Een aspectsysteem is een deel van het systeem dat een bepaald aspect van het totale systeem beschrijft. Het systeem Meavita kent bijvoorbeeld een businessaspectsysteem, een ICT-aspectsysteem, een HRM-aspectsysteem maar ook een cultuuraspectsysteem. Het kenmerkende van een aspectsysteem is dat zij een eigen dynamiek kent. Zo omvat de dynamiek van het Meavitabusinessaspectsysteem onder andere de wens tot groei en acties ivm concurrenten. En de dynamiek van het Meavita-ICT-aspectsysteem omvat bijvoorbeeld life cycles van ICT-systemen en vendor lock-in. Zo bezien is business-ICT-alignment het afstemmen van de aspectsystemen business en ICT door hun dynamiek te synchroniseren. SOA ondersteunt dit afstemmen door vanuit de SOA-gedachte zowel de business als de ICT dienstgeorienteerd te beschrijven respectivelijk op te zetten. Deze dienstorientatie van de beide aspectsystemen business en ICT leidt er toe dat de vertaling tussen de business en ICT op een concreter niveau plaatsvindt waardoor ICT-sturing vanuit de business inzichtelijker en daarmee realistischer en beheersbaarder wordt. Toelichting van dit laatste: de vertaling tussen business en ICT loopt van oudsher via het Functioneel Ontwerp (FO). Tussen dit FO en de daadwerkelijke implementatie van een ICT-systeem staat dan nog een Technisch ontwerp (TO). Doorgaans hebben de belanghebbenden uiteindelijk geen inzicht meer in de verbanden tussen hun businesswerkelijkheid en deze vaak lijvige documenten. Met behulp van loosely coupling worden nu voorheen monolitische ICT-systemen opgebroken in veel kleinere eenheden. De afstand tussen de functionele wensen en beoogde implementatie van deze eenheden is veel kleiner omdat die eenheden veel kleiner zijn. Hoe vervolgens die veel kleinere eenheden in elkaar passen is in de beide aspectsystemen business en ICT hetzelfde, de verbanden tussen deze beide aspectsystemen zijn op dit niveau dus onmiddellijk duidelijk. De vraag of de functionele wensen door de (voogestelde) implementatie worden gerealiseerd is nu dus in twee stappen opgedeeld: de eerste stap op hoofdlijnniveau waar het evident is dat de hoofdlijnen in beide aspectsystemen isomorf zijn en de tweede stap op detailniveau waarin veel kleine onderling onafhankelijke delen aan weerszijden veel eenvoudiger vergeleken kunnen worden.

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) De belanghebbenden kennen vele belangen die we kunnen onderbrengen in drie categorieen: het moet nu werken: functionaliteit het belang functionaliteit is het belang van de eigenaar / gebruiker en daarmee ook van de projectleider die in opdracht van de eigenaar / gebruiker die functionaliteit realiseert het moet straks werken: beheerbaarheid het belang onderhoudbaarheid is het belang van de ICT-beheerafdeling (of van de insourcer) die bijvoorbeeld obv documentatie eenvoudig parameters wil kunnen wijzigen en gebruikers ondersteuning bieden het moet (straks) anders werken: flexibiliteit het belang flexibiliteit is het belang van de hele organisatie maar niemand in het bijzonder en daarom uiteindelijk het het belang van de Raad van Bestuur Vooral dat laatste belang flexibiliteit is niet eenvoudig realiseerbaar. De moelijkheid zit hem in minstens twee facetten: techniek en IT-governance, hierover later meer.

3.1. business en ict business moet soa denken ict moet soa werken business en ict kunnen dan soa met elkaar praten SOA is niet een ICT-feestje maar werpt juist vruchen af als ook de business dienstgeorienteerd denkt, zie ook de note onder slide 4. Business werkt al dienstgeorienteerd alleen denkt zij niet op deze manier over zichzelf. Voor ICT is de dienstorientatie een majeure stap (hier dus een voorbeeld van hoe anders de verschillende dynamieken van de aspectsystemen business en ICT zijn). Er is nieuwe tooling nodig en een andere manier van werken die in het hiernavolgende beschreven wordt. Als ICT in staat is om dienstgeorienteerd te werken en de business zichzelf dienstgeorienteerd begrijpt en communiceert dan kunnen de hoofdlijnen van beide aspectsystemen gehomologiseerd worden. Ontwikkelingen in de business kunnen dan in kleine beheersbare delen opgedeeld worden zodat de ICT aligned wordt met de business, zie wederom de note onder slide 4.

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 De Meavita-SOA bevat drie kernelementen het common data model (CDM). Dit is het datamodel in welke alle berichten die binnen de dienstgeorienteerde omgeving (service oriented environment, SOE) uitgewisseld worden staan gesteld. componenten. Op het hoogste niveau bestaat de ICT-portfolio uit componenten. Voor het gemak kan aan pakketten gedacht worden. Een component heeft een interface die uit diensten bestaat. diensten. Een dienst wordt gedefinieerd mbv zijn contract. Pakketten worden ontsloten mbv diensten. Op de navolgende slides worden bovenstaande begrippen nader beschreven. Dit alles is nog op logisch niveau, om dit technisch mogelijk te maken wordt gebruik gemaakt van een enterprise service bus (ESB).

3.2.1. common datamodel (cdm) het cdm heeft een versie In het contract dat een dienst definieert staan de in- en output geformuleerd. Deze in- en output staan altijd gesteld in het datamodel CDM. Natuurlijk zal ook het CDM evolueren. Daarom heeft het CDM een versie. Het CDM is niet fysiek geimplementeerd, het is de standaard waaraan de fysiek geimplementeerde diensten zich conformeren. Er kunnen daarom meerdere versies van het CDM naast elkaar 'leven' op de ESB: om een dienst te gebruiken hoeft de ontwikkelaar alleen maar te weten aan welke versie van het CDM deze dienst zich conformeert. Het lijkt niet zinnig deze mapping (van CDM-vs a naar CDM-vs b) door de ESB te laten doen.

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 In de SOE wordt de ICT-portfolio op het hoogste niveau beschreven in termen van componenten. Het concept component is van administratieve aard. Een component kun je niet fysiek onderkennen behalve als deze toevallig door bijvoorbeeld een pakket is geimplementeerd. Een component bevat alle aspecten van software in hun samenhang: flow, functie en feit (gegeven). De component bevat een datamodel en de diensten bevatten de flow en realiseren de functie. Componenten zijn hierarchisch genest. De component op het hoogste niveau is de Meavitacomponent. Uiteindelijk moet de interface van een component, bestaande uit diensten, geimplementeerd worden. Conform het tweede uitgangspunt wordt dit zoveel mogelijk gedaan mbv een pakket. Componenten hoeven niet geheel geautomatiseerd zijn. Ook mensen / rollen / afdelingen kunnen als component opgevat worden. Met een rol bedoelen we bijvoorbeeld taken / bevoegdheden / verantwoordelijkheden (tbv).

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 Een belangijke ontwerptaak is de indeling van de ICT-portfolio in componenten. Momenteel zijn daar nog geen duidelijke richtlijnen voor. Pakketten lijken zinnige kandidaten voor componenten maar het kan ook zijn dat een pakket (delen van) de interfaces van verschillende componenten implementeert (zie verderop). Als eerste scheidingsrichtlijn willen we co- en adhesie voorstellen. De hesie binnen SOA bestaat uit communicatie dus is de richtlijn dat de communicatie binnen componenten groter moet zijn dan de communicatie tussen componenten. Een andere richtlijn is dat er binnen een component buiten de ESB om gecommuniceerd mag worden. Het idee hier is dat de in hoeveelheden mindere communicatie over de ESB gaat. Vanuit evolutieoogpunt is het idee dat juist de adcommunicatie complexiteit veroorzaakt en dat deze dus gedocumenteerd dient te worden (zie verderop).

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 Een composite dienst kan alleen diensten van binnen zijn component aanroepen of diensten in kindcomponenten, maar niet in kleinkindcomponenten (de verwachting is niet dat er zoveel lagen zullen bestaan). De status en context van een process liggen altijd binnen een dienst die de betreffende workflow implementeert.

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 Componenten interageren alleen met de buitenwereld via hun (uit diensten bestaande) interface. Maar binnen een component is er meer vrijheid. Een dienst mag alleen gegevens van zijn component direct benaderen, dat kan alleen een atomaire dienst zijn. Als een dienst gegevens van een andere component wil benaderen (CRUD) dan dient die andere component daartoe CRUD-diensten ter beschikking te stellen die dus alleen benaderd kunnen worden door composite diensten. Voor managementinformatie (MI) wordt een data warehouse (DWH) met historische data overwogen. Het datamodel van het DWH dient conform het CDM te zijn.

resultaat het resultaat van een dienst is impact op de werkelijkheid, waaronder de gegevens opgeleverde gegevens in de 2e orde kan een dienst (zoals ontwikkelen van services) als impact een wijziging van de soa hebben Het resultaat van een dienst vind ik moeilijk te omschrijven. Er zijn vele mogelijkheden die in het contract, item beschrijving, beschreven dienen te worden. Omdat een dienst niet geheel geautomatiseerd hoeft te zijn kan het resultaat in principe van alles zijn.

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 Vooralsnog gaan wij uit van twee mogelijke QoS. Ik wil nog snappen hoe de volgende 3 begrippenparen zich tot elkaar verhouden: f&f – s&f p&s – r/r sync – async

3.3. berichten hebben een afzender oa ivm hebben een ontvanger? 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? Een bericht bevat minimaal afzender ontvanger input, gesteld in het CDM Binnen een component kan een datamodel gehanteerd worden dat niet overeenkomt met het CDM, in dat geval dient er mapping plaats te vinden. Deze mapping mag niet op de ESB plaatsvinden maar dient te geschieden in de component zelve.

3.4. versiebeheer er is versiebeheer voor cdm diensten componentdatamodellen Alle kernelementen van de Meavita-SOA evolueren en zijn daarom aan versiebeheer onderhevig. Die versies kunnen naast elkaar bestaan. Zo kan het zijn dat er al en CDM v2 is maar dat een bericht nog in CDM v1 gesteld is. Zolang de ontvangende partij nog CDM v1 ontvangen wil is dat geen enkel probleem. Om te upgraden naar CDM v2 zal terwijl CDM v1 en v2 naast elkaar bestaan en gebruikt worden die ontvangende partij geupgrade moeten worden naar CDM v2. Zodra deze nieuwe versie van de dienst in productie is kan de aanroepende partij omgezet worden naar CDM v2.

in het huidige model zie ik in de interface alleen ingaande triggers: welke diensten biedt een component aan; dwz: op welke vragen reageert deze component maar wie roept die diensten eigenlijk aan, wie stelt eigenlijk die vragen? in mijn eerste ideeen zijn dat andere diensten of kunnen applicaties / componenten dat ook? ik wil in de interface ook uitgaande triggers zien, welke diensten deze component aanroept

hoe zit dat met business works engines? diensten kunnen elkaar aanroepen, dat geeft een (proces)flow, die zie ik nu nergens geexpliciteerd flows workflow iprocess taskflow business works messageflow esb – tibco-product? hoe zit dat met business works engines? kun je hiermee services implementeren die taskflow bevatten? best effort = fire & forget?

wat is het verband tussen diensten en berichten? een dienst kun je aanroepen door een bericht te sturen conform het contract uitgaand stuurt een dienst een bericht berichten gaan over de bus hoe moet ik mij dit voorstellen op executableniveau? hoe zit dat met publish & subscribe? moet je je abonneren om een published message te kunnen ontvangen? of pakken diensten een published message op zodra zij die aankunnen?

hoe worden berichten die gepubliceerd worden beschreven? wat is het verband met contracten van diensten? voorbeelden azr-instroom: asynchroon gegevens bij bsn: synchroon wanneer is communicatie (a)synchroon? hoe zit dat met state en context?

3.5. eigenaren esb (infra + beheer) authorisatiemodel component dienst proces (binnen dienst) orchestratie / choreography data / cdm per component authorisaties directeur ict scc business diensteigenaar Ieder van de elementen van de Meavita-SOA heeft een eigenaar die verantwoordelijk is voor dat element. Alle componenten zijn in beheer bij het SCC. De diensten waaruit hun interfaces bestaan zijn steeds eigendom van de verantwoordelijke businessrol. De eigenaar van een dienst is (a fortiori) ook verantwoordelijk voor de workflow binnen die dienst. Workflow die over diensten heengaat, orchestratie genaamd, ligt ook bij de business maar (meestal) op een hoger niveau. Het CDM is eigendom van het SCC maar de verschillende dataelementen steeds bij betreffende businessrollen. Evenzo besluit de business wie waar toegang toe heeft.

4. implementatie 4.1. flow 4.2. deadlock 4.3. eisen componenten en cots 4.4. esb In deze paragraaf volgen enkele principes tbv de implementatie. De ratio achter de verschillende keuzes mbt flow wordt eerst gegeven. Vervolgens wordt kort ingegaan op deadlock. De filosofie achter deze opzet van de SOA resulteert in twee eisen aan componenten en COTS die met deze opzet gerealiseerd zouden moeten zijn maar waaraan daadwerkelijke implementaties (juist ook in geval van afwijking van de hier opgestelde principes) getoetst moeten worden. Tenslotte nog enkele principes mbt de 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 De kern van de filosofie achter deze SOA is het isoleren van de flow. Doordat alleen composite diensten, die workflow bevatten, andere diensten mogen aanroepen wordt alle flow die de ict-portfolio rijk is op dienstenniveau geexplicteerd. Samen met de authorisatieadministratie maakt dit het onderhoud aan de flow beheer(s)baar.

4.2. deadlock om deadlock te voorkomen dienen timers gebruikt te worden Deadlock kan nooit helemaal voorkomen worden. Veruit de meeste schade kan beperkt worden door het standaard gebruiken van timers.

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 Voorgaande principes zijn zo opgesteld dat het mogelijk moet zijn binnen componenten onderhoud te plegen zonder rekening te hoeven houden met wat er buiten de component / interface gebeurt. Alle ontwikkelingen moeten deze moeder van alle principes toch expliciet respecteren om onvoorziene afhankelijkheden te identificeren, in het bijzonder in het geval dat principes (gedocumenteerd!) geschonden worden. De verwachting is dat pakketten soms niet binnen een component te positioneren zijn. In dat geval stellen we als eis aan het pakket dat hij / zij zo ontsloten kan worden dat de diensten in de verschillende componenten onafhankelijk van elkaar zijn (wederom dwz: dat onderhoud binnen de component geen invloed heeft op andere componenten).

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 Functionaliteiten als mapping, authenticatie / authorisatie en monitoring vinden plaats in aparte omgevingen, niet in de ESB. Ook binnen de ESB worden open standaarden gebruikt zoals JMS ipv RendezVous. Het voorkomen van vendor lock in is in beide gevallen de belangrijkste argumentatie.

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 In deze paragraaf onderbouwen we waarom de voorgestelde keuzes de geidentificeerde belangen zo goed mogelijk behartigen. De kern van de argumentatie is dat er een opdeling van de voorheen monolitische ICT-portfolio is ontstaan. De koppeling en impliciete flow worden als eerste verantwoordlijk gehouden voor de rigiditeit van de ICT-portfolio. Door de flow separaat centraal te beleggen en de implementatie van functionaliteiten via die interfacing van elkaar te ontkoppelen ontstaat een ICT-portfolio waarin de impact van de evolutie goed beheersbaar te plaatsen is, zie wederom de note onder slide 4.

atomaire en composite 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 Een dienst wordt functioneel volledig beschreven door zijn contract waarin onder andere staat wanneer de dienst wat doet, welke input hij daarvoor nodig heeft en wat het resultaat is van zo'n aanroep. Een dienst wordt volledig beschreven door zijn contract tezamen met de implementatiedocumentatie en authorisatieadministratie. Er zijn twee soorten diensten: atomaire en composite diensten. Composite diensten zijn diensten die mbv workflow worden samengesteld uit andere diensten. Workflow is het enige dat een composite dienst mag bevatten. Alle niet workflow-functionaliteit dient in atomaire diensten geimplementeerd te worden, deze atomaire diensten mogen geen andere diensten aanroepen, ze kunnen nog wel workflow (die dus geen diensten aanroept) bevatten. Hiermee wordt de flow van de ict-portfolio beheer(s)baar (zie slide 4.1). Een dienst hoeft net als een component niet noodzakelijkerwijs geautomatiseerd te zijn. COTS worden in eerste instantie door diensten ontsloten. Ik vermoed dat het verstandig is om de twee soorten diensten met verschillende iconen te visualiseren.

in den beginne was er werk toen gingen we stukjes daarvan automatiseren dit wil ik graag beschrijven daarvoor heb ik een taal nodig de taal om automatisering te beschrijven is redelijk uitgekristalliseerd (uml bijvoorbeeld) als we handmatig werk gaan beschrijven in automatiseringstaal (wetstexten hebben hier iets van weg) dan zien we geen verschil tussen dat werk in handmatige en geautomatiseerde vorm maar in werkelijkheid is er een groot verschil tussen de handmatige en de geautomatiseerde vorm voorbeeld: volgens de beschrijving moet je eerst kijken of er wel voorraad is en daarna of de klant wel geregistreerd is - want ook als de klant niet geregistreerd is wil je wel dat de voorraad aangevuld wordt met producten waar kennelijk vraag naar is. maar als klanten die niet geregistreerd zijn stelselmatig vragen om producten die verder nooit geleverd worden (bijvoorbeeld omdat de leverancier van deze producten deze schijnklanten hiervoor speciaal inhuurt) is het handiger eerst te kijken of een klant wel geregistreerd is alvorens de voorraad te checken. deze laatste modificatie is er een die door medewerkers op de werkvloer bedacht wordt nav klachten over te hoog oplopende voorraden. hoe (met welke taal) dus de handmatige werkwerkelijkheid te beschrijven? essentieel verschil tov de taal voor het beschrijven van geautomatiseerd werk zijn in ieder geval de argumentaties, doelen, belangen, inschattingen, afwegingen, context, verhoudingsgevoel, bewustzijn, creativiteit en daaruit voortvloeiende dynamiek, iteraties, disrupties (vgl einstein: problemen worden niet opgelost op hetzelfde bewustzijnsniveau als waarop ze gecreeerd zijn)

als we handwerk automatiseren moeten we een aantal van die handmatige kenmerken weglaten, nl die kenmerken die niet geautomatiseerd kunnen worden automatisering brengt stijfheid (aan een slappe schroevedraaier heb je nix: gelijke monniken, gelijke kappen) maar ook verstarring (er zijn genoeg regels te bedenken die te grofmazig zijn) het gevolg van die verstarring (dat het in voorkomende gevallen niet beter geregeld is - te grofmazig) gaan we te lijf met meer regels (fijnmaziger maken, dit heet regelitis, zie einstein hierboven) voorbeeld: het probleem dat geintroduceerd wordt door het bovenbeschreven proces grofmazig te automatiseren en daarmee te ontdoen van de mogelijkheid om de constituerende processtappen om te draaien kan fijnmaziger geautomatiseerd worden door extra regels toe te voegen. bijvoorbeeld door de gebruiker steeds de keuze te geven, maar dan moet de gebruiker steeds een keuze maken, ook als dat helemaal niet nodig is... voorbeeld: schaar, zeis en maaimachine: de maaimachine kan alleen nog maar op hoogte ingesteld worden (extra regel) maar dan knipt hij ook alle grassprietjes op dezelfde lengte (stijfheid) behalve de kantjes (gebrek aan contextgevoeligheid)... voor al die automatisering geldt dat als je daar geen bewuste aandacht aan besteedt dat de hoeveelheid werk die nodig is om een verandering aan te brengen evenredig is met de omvang van het systeem. alleen in toevallige situaties is die hoeveelheid werk evenredig met de omvang van de wijziging. voorbeeld: met een maaimachine kun je geen graan oogsten, je zult de hele maaimachine moeten verbouwen om dat toch te kunnen doen. je kunt nog wel de instelhoogte wijzigen door extra gaatjes te boren. overigens is dit niet erg want de systemen zijn toch klein.

toen gingen we meer automatiseren: eilandautomatisering, stovepipes tenslotte groeiden de eilanden aan elkaar (eai) maar nu hebben we een probleem: door het aan elkaar groeien hebben we opeens een heel groot systeem en de inspanning nodig voor veranderingen is nu evenredig met het grote systeem en daarmee onaanvaardbaar groot de integratie van de stovepipes was zinnig dus dat willen we niet loslaten maar ontkoppeling om flexibiliteit te genereren blijft nodig, alleen: langs welke lijnen? de eerste poging was die langs f/m/b-office, maar dan ontkoppel je op hetzelfde niveau als waar je ze eerst koppelde: langs applicatielijnen, dit werkte dus niet nu willen we een abstraxiestap maken: soa dat betekent voor ict-verandermanagement: - proactief veranderingen in kaart brengen (sessies met klantmanager en business) - vinkentouw - veranderingen vinden altijd en alleen via ons plaats (processen, in ieder geval daar waar het de kernsystemen betreft)

interconnect (bus) services (data, funxie) in back office; i/o; contract components (groepering services, process) applicaties (in lagen, mid office) = samenstel services work-/task-/documentflow (mid office) ook: point2point cdm service contract - biz naam - version - description - input - output - errors -- applicatie (biz) -- technisch (it) - responstijd - pre/postconditions

context-/stateless subset ebxml gebruiken benodigdheden - name space - qos (best effort; store & forward; file transfer; priority) - securitymodel - datamodel (cdm) - monitoring - operations - initial services - service contract - context - unit of work / distributed transxions - compensatory

"in order to achieve loose coupling i feel that when defining services we need to describe its interface not just syntactic but semantic aswell." on some occasions i proposed to come up with some clarifying examples and in creating these i gained some more insight. with this email i would like to share my ideas with you and refrase the above hunch once more hoping to inspire you to answer me with critiques and ideas. services are designed to work together otherwise there is no point in having a soa. but in working together the services need to know what to expect of each other. the main design principle of soa is that in order to know the expectations of a service it suffices to know the interface of that service. so how to describe the interface of a service? in other words: how to describe the expectations of a service? at least in- and ouput should be described. but this is not enough. eg: suppose a service updates status. the status is neither in the in- nor in the output definition, but obviously status is part of the expectations. what can we do here? a first idea is that status should be part of the common data model (cdm) which serves as a context in which the service acquires meaning. another example: suppose we want to define a service "enroll new customer". this service has to check whether the candidate customer is not already enrolled. we could design the "enroll new customer" service as a composite service calling the 2 atomic services "check existence customer" and "register new customer". when designing in this way the service "register new customer" presupposes (expects) that the candidate customer doesn't exist yet. how can we describe this expectation in the definition of the service? my idea is to use pre- and postconditons.

i learnt that pre- and postconditions are not what i want i learnt that pre- and postconditions are not what i want. but now i am inclined to differentiate this view. i can image there are several levels (like composite and atomic) at which services can be defined. each level allows more or less pre- and postconditions. at the highest level neither pre- nor postconditions are allowed, going down the hierarchy more and more conditions are allowed. in this way the coupling becomes tighter downwards in the hierarchy and looser upwards. all together this means that a soa consists of a cdm b levels of allowed pre-/postconditions c services defined using - level - in-/output - pre-/postconditions conforming to its level - qos when all this makes sense the hunch i have now boils down to 3 questions: 1 how to (formally!) describe pre- and postconditions? 2 what (from an agility point of view useful?) levels of allowed pre-/postconditions can we define? 3 how can we check that the implementation of a service indeed does not presuppose anything outside the interface definition? my guess is that demo(.nl) is a good starting point for answering these questions.

soa wil loose coupling maar samenwerking tussen diensten genereert tight coupling na gestructureerd programmeren komt gestructureerd integreren in den beginne was er spaghetti en toen heeft men gestructureerd programmeren ingevoerd het tijdperk van de eilandautomatisering werd afgesloten met eai en toen bleek de spaghetti op een hoger niveau teruggekeerd met soa gaan we nu gestructureerd integreren kenmerkend is dat automatisering runtime bewustzijn vervangt door designtime bewustzijn in de eilandautomatiseringsperiode bestond de middleware uit intelligent maar vooral bewust personeel services krijgen betekenis in een context

voorbeeld 1 services kunnen status wijzigen die status staat niet in de i/o want die wordt niet meegegeven - is status inlezen input en uitlezen output? moet het toch in de i/o? die status hoort eigenlijk in het cdm, die daarmee context is - status wijzigen is dus cdm wijzigen 2 nieuwe klant opvoeren, dan moet je eerst checken of deze klant niet al bestaat dat checken kan in die dienst zitten, dan is die dienst een composite service die op zijn beurt weer de atomaire services check en opvoeren aanroept maar dan heeft de atomaire service opvoeren wel de preconditie dat gecheckt is dat de klant niet al bestaat (in het systeem) 3 de dienst nieuw_spel gaat ervan uit dat de applicatie zojuist gestart is, impliciet dat het datamodel leeg is waar bestaan die pre-/postcondities uit? antwoord - mogelijk antwoord: je wilt alleen services op hoog niveau toestaan waar geen condities voor nodig zijn - beter antwoord: sta op verschillende niveaux meer en minder (soorten) condities toe -- die soorten omschrijf je in termen (van delen) van demo-vocabulair (status/processen/info/datalogic) - demo

applicatie service implementeert

virtual services fysical service service presentatie implementeert logica data

dit is een funxie- en codelandschap met een scheiding tussen de ongelijksoortige integratie- en implementatielaag integratie dienst implementatie scheiding