De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

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

Verwante presentaties


Presentatie over: "Hoe definieer je een service? jeroen j van beele 14 december 2006."— Transcript van de presentatie:

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

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

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

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

5 in den beginne was er werk

6 toen werd er geautomatiseerd

7 er werd meer geautomatiseerd

8 groeit uit tot eilandautomatisering

9 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

10 eai complexiteitscatastrophe (chis verhoef)

11 stovepipes

12 eai

13 opnieuw maar anders scheiden

14 is dit een applicatielandschap?

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

16 ba soa: loose coupling de soa heeft kennis over systeem b

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

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

19 meavita soe architectuurprincipes –soa –cots

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

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

22 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)

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

24 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

25 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?

26 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.

27 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

28 ideeen en discussie demo archimate

29 dank voor uw bijdrage

30

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

32 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

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

34 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

35 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

36 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)

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

38 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

39 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

40 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

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

42 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

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

44 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

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

46 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

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

48 customerorderline check stock check credit no ok issue order yes 1 NN 1 N 1 product 11 example 1 1

49 implementation: molecules wf da...

50 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

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

52 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

53 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

54 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

55 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

56 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)

57 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

58 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?

59 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

60 randvoorwaarden services stateless contextless passen in precies 1 laag

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

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

63 lagen flow presentatie verwerking data

64 doel ict-architectuur er voor zorgen dat de evolutie van de ict- portfolio zo goed mogelijk aansluit bij de behoeften van de organisatie

65 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)

66 elementen ict-architectuur it-governance ict-architectuurprincipes blauwdrukken (aspectarchitecturen) –metamodellen –ontwerpen

67 aspectarchitecturen ontwikkel beheer beveiliging infrastructuur gegevens applicatie

68 1.1. organisatieparadigma aspectsystemen –eigen dynamiek / evolutie afstemming

69 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)

70 3.1. business en ict business moet soa denken ict moet soa werken business en ict kunnen dan soa met elkaar praten

71 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

72 common datamodel (cdm) het cdm heeft een versie

73 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

74 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

75 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

76 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

77 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

78 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

79 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?

80 3.4. versiebeheer er is versiebeheer voor –cdm –diensten –componentdatamodellen

81 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

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

83 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?

84 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?

85 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

86 4. implementatie 4.1. flow 4.2. deadlock 4.3. eisen componenten en cots 4.4. esb

87 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

88 4.2. deadlock om deadlock te voorkomen dienen timers gebruikt te worden

89 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

90 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

91 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

92 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

93 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)

94 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.

95 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)

96 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

97 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

98 "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 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.

99 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.

100 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

101 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

102 applicatieservice implementeert

103 service implementeert presentatie logica data virtual services fysical service

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


Download ppt "Hoe definieer je een service? jeroen j van beele 14 december 2006."

Verwante presentaties


Ads door Google