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)– 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?

ba

mom: tight coupling

systeem aheeft kennisoversysteem b

ba

soa: loose coupling

de soaheeft kennisoversysteem b

dienstintegratie

implementatie scheiding

dit is een funxie- en codelandschap met een scheiding tussen de ongelijksoortigeintegratie- en implementatielaag

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)

..

...component

interfacedienst

gegevenssubcomponent

... ...

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)

servicedefinitie (vervolg)

• responstijd• quality of service (qos)• foutafhandeling

– technisch– business

• precondities (liefst geen)• postcondities (liefst geen)

uitdaging en vraag

• uitdaging– organisatorisch– technisch

• vraag– 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– 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

execution

3e-model: entity - execution - event3f-model: fact - function - flow

3g-model: gegeven - gedrag - gebeurtenis

relation

entity

event

customer order line

checkstock

checkcredit

no

no

okissueorder

order

yes

yes

1

N N1

N

1

product

1 1

example

1

1

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– ict– biz

• techniek– logisch

• cdm• services

– fysiek• 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

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

1.1. organisatieparadigma

• aspectsystemen– eigen dynamiek / evolutie

• afstemming

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)

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

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

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

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 2e 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

• 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

• 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• scc• business• diensteigenaar• business• business• 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

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

• 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. 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 serviceimplementeert

serviceimplementeert

presentatie

logica

data

virtual services fysical service

dienstintegratie

implementatie scheiding

dit is een funxie- en codelandschap met een scheiding tussen de ongelijksoortigeintegratie- en implementatielaag