hoe definieer je een service?

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. mom: tight coupling a b systeem a heeft kennis over systeem b

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

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

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. ... ... interface dienst component ... .. 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

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. 3e-model: entity - execution - event3f-model: fact - function - flow3g-model: gegeven - gedrag - gebeurtenis entity execution event relation

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

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