Samenvatting Service Oriented Architecture Wat is architectuur? Architecture is a term that lots of people try to define, with little agreement. There are two common elements: One is the highest-level breakdown of a system into its parts; the other, decisions that are hard to change. (Martin Fowler in Patterns of Enterprise Application Architecture) Wat is een software service A service is a means of delivering value to customers by facilitating outcomes the customers want to achieve without ownership of specific costs or risks (Service definitie in ITIL) Altijd minstens twee partijen Software service beide partijen zijn software Meestal over een netwerk Geautomatiseerde contracten contract = wat doet de service (tegen welke voorwaarden) Software services worden gebruikt in Enterprise applications Veel gebruikers grote applicaties Communicatie met andere applicaties in de onderneming en met externen KISS principe (Keep it simple stupid): eenvoudige algoritmen, eenvoudige datastructuren, maar ook eenvoudige hoofdstructuur Lange levensduur van data (ten opzichte van technologie) Flexibel Business driven Herbruikbare bouwstenen Veel stakeholders: politieke beslissingen Entropie stijgt in een gesloten systeem Applicatie ondergaat wijzigingen Oorspronkelijke design principes worden uit het oog verloren of workarounds Applicaties worden minder en minder beheerbaar Business architect moet hiervoor tegengas bieden Business architect Entropie van een systeem onder controle houden Applicaties kaderen in strategie Samenvatting service oriented architecture 1
Afwegen van niet-ideale oplossingen Refactoring: applicatie aanpassen zonder de functionaliteit te wijzigen (bijvoorbeeld interne structuur aanpassen) Typische cyclus: aanpassen => refactoring => aanpassen => refactoring... Incrementele optimalisatie (Service Oriented Architecture geschikt hiervoor) Officiële definitie van SOA A service-oriented architecture provides the flexibility to treat elements of business-processes and the underlying IT infrastructure as secure, standardized components (services) that can be reused and combined to address changing business priorities. (IBM) Services vormen componenten of bouwstenen Services kunnen herbruikt worden op business niveau Doordat services ook de technologie afschermen, kunnen we verschillende technologiën met elkaar combineren (.NET applicatie die via een service met een CICS backend werkt) Services zijn loosely-coupled Andere definitie SOA is about connecting customer requirements with enterprise capabilities, regardless of technology landscape or arbitrary organizational boundaries. SOA: drie termen Operations: (software) methodes die één welomschreven taak uitvoeren, bijvoorbeeld SchrijfGeldOver(rekening1, rekening2, bedrag) Service: logische groepering van operations, bijvoorbeeld een bankrekening service Business process: (meestal) langdurige opeenvolging van activiteiten die gebruikt maakt van services. Een business process is bursty en ful. Dat wil zeggen dat het proces een belangrijk deel van de tijd niets doet (staat te wachten) en ondertussen onthoudt wat er al gebeurd is. Een facturatieproces begint met de melding dat er mag gefactureerd worden. De factuur wordt verstuurd en men wacht op betaling. Wanneer de klant niet op tijd betaalt moet er een herinnering verstuurd worden. Wanneer er betaald wordt, moet de betaling afgeboekt worden in de boekhouding. Waar ligt de oorsprong van SOA Drie evoluties: Programmeertalen assembler: machinecode afschermen van programmeur via mnemonics COBOL: programmeerstructuren (iteratie, selectie) herbruiken door ze te definiëren in een hogere taal Werken met functies (functionaliteit herbruiken) Samenvatting service oriented architecture 2
Samenvatting service oriented architecture 3
Componenten: modules (verzameling van functies die samenhoren herbruiken) OO-talen: mogelijkheid om functionaliteit te herbruiken via overerving (inheritance) OO-talen: program to an interface, not to an implementation. Scheiding van interface (lijst van methodes + argumenten) en implementatie (de code die echt iets doet) => we kunnen de implementatie wijzigen zonder de intgerface te wijzigen. Daardoor zullen wijzigingen in de applicatie meer gelokaliseerd worden. Distributed computing Terminals (VT100 van Digital Equipment Corporation) => mainframe UNIX: besturingssysteem waarbij networking ingebouwd is in het besturingssysteem UNIX: via Network File System de bestanden op een andere machine in het netwerk aanspreken (maakt gebruik van Remote Procedure Calls) CORBA: Common Object Request Broker Architecture: objecten aanspreken via het netwerk (niet alleen procedures aanroepen, maar ook creatie en delete van objecten) World Wide Web: standaardisatie van de client applicatie (web browser met HTML en javascript). Je kunt vanop een Windows client surfen naar een UNIX server Enterprise Javabeans: Applicatie server waarin componenten worden geïnstalleerd. De application server is verantwoordelijk voor toegang tot databanken, logging, beheer van transacties en security SOAP: Simple Object Access Protocol om remote procedure calls uit te voeren via het web (HTTP protocol) en XML (webservice) WSDL: Webservice definition language. Gestandardiseerde beschrijving van de mogelijkheden van een interface zodat ontwikkelaars de code die nodig is om via het netwerk een webservice aan te spreken automatisch kunnen laten genereren(eigenlijk geautomatiseerd contract) Business computing Centrale mainframe waar alles opstaat (monolithische applicaties) Via batch programma's bepaalde taken uitvoeren (vertraging op resultaat aangezien batch programma's op bepaalde tijdstippen worden uitgevoerd en niet continu) Databanken: aparte applicaties om met data te werken. De databank kan ondervraagd worden via de taal SQL. Tegenwoordig wordt SQL gebruikt door ontwikkelaars. Oorspronkelijk is het ontwikkeld als een taal voor business mensen SAP R/2: gestandardiseerde software voor Enterprise Resource Planning. Real time processing van financiële data (<=> batch programma's) goedkope IBM PC zorgde ervoor dat er gemakkelijk client programma's naar de gebruiker konden worden gebracht. (client-server applicaties) Enterprise Application Integration: verschillende applicaties met elkaar integreren (ERP en Customer Relationship Management bijvoorbeeld) Business process Modeling: proces definiëren via een grafische interface (en uitvoerbaar maken) Model Driven Architecture: software genereren op basis van een model Samenvatting service oriented architecture 4
SOA: 9 onderdelen 4 hoofdbestanddelen: Application front end, service repository, service, service bus. Application front end stuurt het proces (eigenlijk de gebruiker van de application front end.) application frontends komen overeen met UI-layer van three tier. Maar opgelet: services komen niet overeen met de lagere lagen Services geven structuur aan de SOA (application front end kan regelmatig veranderen, services blijven grotendeels hetzelfde) Services omvatten een high level business concept. Contract: informele beschrijving van doel, functionaliteit, beperkingen (constraints) en gebruik van de service. Kan ook een formele definitie bevatten onder de vorm van IDL of WSDL, maar dit is altijd maar een deel van het contract Interface: deel van de service dat van buiten kan worden aangesproken. de beschrijving van de interface is deel van het contract. De implementatie van de interface gebeurt via proxies of stubs in de client van de service Implementatie: bevat business logica en data (programma's, configuratiebestanden + databanken) Business logic: deel van de implementatie dat business rules bevat Data: gegevens waarmee de service werkt, vooral bij data-centric service Service is een vertical slicing (geen horizontale zoals bij three tier layers) die een volledig business concept bevat. Service repository: om services terug te vinden. Hoeft niet via technologie geïmplementeerd te zijn. (een klasseur met documenten). Kan de volgende items bevatten: WSDL en XSD schema's Service owner: business level (vragen en change requests voor functional level), development level (technische vragen en change requests), operational level (beste manier om een service aan te spreken of operationele problemen) info over toegangsrechten Informatie over verwachte performantie en scalability. Kan via een SLA agreement Transactionele eigenschappen van de service. Service bus: verbindt alle deelnemers: services en application frontends. Lijkt op software bus van CORBA. Maar kan bijvoorbeeld uit verschillende technologieën bestaan. Connectivity: verbindt alle deelnemers heterogene technologieën: verschillende programmeertalen, operating systems moeten met elkaar verbonden kunnen worden. Heterogene communicatie: zowel synchrone als asynchrone communicatie technische services: logging, auditing, security, transacties... Service-oriented architecture: 8 principes Een gestandardiseerd service contract: alle services in de repository volgen dezelfde contract Samenvatting service oriented architecture 5
design standards Service loose coupling: service contracten leggen geen zware koppeling op met de consumers en services zijn zelf los gekoppeld aan hun omgeving Service abstraction: service contracten bevatten alleen essentiële informatie en informatie over services is beperkt tot wat er in het service contract staat Service reusability: services kunnen herbruikt worden Service autonomy: services kunnen hun taak uitvoeren zonder al te veel hulp van buitenaf Service lessness: services houden zo weinig mogelijk bij Service discoverability: services bevatten voldoende meta informatie (informatie over de service) om gemakkelijk gevonden te worden Service composability: services kunnen gemakkelijk deel uitmaken van een groter geheel Service-oriented architecture: 4 karakteristieken Business driven: in het verleden speelde software vooral in op tactische(=korte termijn) business vereisten. SOA moet zich meer richten naar lange termijn (strategische) plannen. => business en technologie groeien uit elkaar Vendor neutral: SOA moet de algemene principes volgen van de huidige SOA oplossingen, zonder afhankelijk te zijn van specifieke implementaties. => vendor (dus SOA) drijft business processen Enterprise centric: alle oplossingen moeten kaderen in het grotere geheel => geen software silos (=bijvoorbeeld eigen oplossing in Access of Excel) => alle software moet ontworpen zijn om gedeeld te worden. Composition centric: service moeten gemakkelijk deel kunnen uitmaken van een groter geheel(zelfs al zijn ze daar oorspronkelijk niet voor bedoeld) Communicatie tussen services Communicatie middleware: RPC, Corba(soms zonder object beheer, waardoor het eigenlijk RPC wordt), Message oriented middleware Transaction monitors en application servers synchrone vs asynchrone communicatie interface <=> payload semantics tight <=> loose coupling physical: direct verbonden of via een intermediary (MOM) communicatie stijl: synchroon vs asynchroon type systeem: interface vs payload interactie: OO (corba) vs self contained messages control of process logic: central vs distributed service discovery and binding: statically bound services vs dynamically bound services (twee soorten runtime binding) development time binding: gemakkelijkste en meest gebruikte. Bij het ontwikkelen van de client is geweten met welke service men een connectie wil maken en deze informatie zit vast in de code (interface) Samenvatting service oriented architecture 6
runtime binding: veel moeilijker runtime service lookup by name: meest gebruikt, service definitie is gekend tijdens development, service lokatie wordt opgezocht at runtime via de naam van de service runtime service lookup by properties: idem, maar niet gezocht op naam, maar op eigenschappen: zoek een print service op de tweede verdieping die postscript kan afdrukken (VERDIEPING=2, LANGUAGE=POSTSCRIPT) runtime service discovery via reflection: in tegenstelling tot bij de twee vorige is de interface niet gekend bij developing. Via reflection wordt de interface opgevraagd. Weinig gebruikt want veel te ingewikkeld. Remote procedure call Remote procedure kan worden aangesproken zoals een gewone procedure via een client stub. Dit is een methode die er hetzelfde uitziet als de echte methode (die op de server staat), maar met behulp van de RPC library de connectie verzorgt over het netwerk. Aan de server kant vertaalt de server stub de netwerk aanroep naar een gewone functie aanroep Distributed objects(corba) Hier kunnen niet alleen methodes of procedures worden opgeroepen, maar er kunnen ook objecten worden gemaakt, gezocht en verwijderd. Een client kan een verwijzing opvragen naar een object op de server (client proxy object). Via dat object kan men methodes via de client oproepen die op de server zullen worden uitgevoerd. Soms worden de Create, find en delete mogelijkheden niet gebruikt. In feite wordt CORBA dan RPC. In tegenstelling tot bij SOA zijn de methodes die worden opgeroepen fine-grained. Ze komen meestal niet overeen met business methodes. Message oriented middleware Geen rechtstreekse communicatie tussen beide partijen Verloopt via een tussenpersoon. Opdracht wordt als message verstuurd naar een queue (of een topic) Message bestaat uit een header en een payload. Header is algemeen voor elke applicatie die de MOM gebruikt. Bevat onder meer informatie naar welke queue de message moet worden gestuurd payload is applicatie specifiek en bevat business data (en opdrachten), dikwijls in XML formaat. Een queue is een plaats waar messages worden achtergelaten Samenvatting service oriented architecture 7
Voorbeeld van een Message Oriented Middleware is e-mail Twee soorten: Point-to-point (één-op-één communicatie) en publish-subscribe (één-op-veel of veel-op-veel communicatie) De eerste soort (Point-to-point) noemt men een queue. De tweede soort (publish-subscribe) noemt men een topic. Transaction monitors Duizenden gebruikers Computer resources verdelen onder gebruikers (multiplexing) Beheer van CPU, database transacties, sessions, opslag, Ook distributed applicaties Voorbeelden: CICS, IMS, Tuxedo CICS al meer dan 20 jaar oud. Wordt aangesproken via External Call Interface (ECI) ECI bevat library voor RPC aanroepen CICS transaction gateway bevat een object georiënteerde interface voor Java IMS werkt met MQSeries (MOM) Application servers Tussen webserver en backend systeem(bijv. Databank) Verzamelt informatie uit de backend en zet die om naar HTML code Componenten beheren, toegang tot datasources beheren, verschillende user interfaces ondersteunen Microsoft: Internet information server +.NET Java: JBoss, Websphere, Tomcat, : J2EE (of Java EE) Java EE bevat vele standaarden: Java Servlets, Java Server Pages, Java Server Faces, Enterprise JavaBeans, Java EE Connector Architecture, Java Naming and Directory Interface (JNDI), Java Management Extensions, Java Transaction API, CORBA, Java Messaging Service (JMS) Synchrone/asynchrone communicatie Bij synchrone communicatie moet de client wachten tot de server klaar is. De client blijft dus geblokkeerd. Wanneer een gebruiker gegevens opvraagt via een Windows applicatie en de opvraging gebeurt synchroon, zal de applicatie geblokkeerd blijven tot alle gegevens zijn overgehaald (tenzij de client met verschillende threads werkt) Meestal RPC-communicatie. Synchrone communicatie kan men vergelijken met een telefoongesprek. Bij asynchrone communicatie kan de client verderwerken vanaf het moment dat de opdracht verstuurd is. Er wordt niet gewacht op de server. (vergelijk met e-mail, de meeste mensen wachten niet op een antwoord) MOM kan ook gebruikt worden voor synchrone communicatie via een apart framework boven de message queue. Achter de schermen worden er twee queues gebruikt. Samenvatting service oriented architecture 8
De client verstuurt een bericht naar het framework. Dat plaatst het bericht in queue1. Het framework wacht op een antwoord in queue2 De server ontvangt het bericht en plaatst het antwoord in queue2 Vanaf het moment dat het antwoord in queue2 is ontvangen door het framework, stuurt dat het antwoord naar de client Voor de client is het net of er een synchrone communicatie is geweest RPC kan ook gebruikt worden op een asynchrone manier via callbacks: client stuurt en request naar de server die geeft de controle direct terug aan de client (heel korte methode), eventueel na een bevestiging De server verwerkt de request Wanneer de server klaar is wisselen de twee om van taak. De server wordt client en roept een callback methode op de oude client (nu dus de server) op Wanneer het niet mogelijk is om de oorspronkelijke client terug op te roepen( firewall) kan de client ook regelmatig pollen naar een antwoord Interface/payload semantics Interface semantics wil zeggen dat er voor elke aanroep een verschillende methode is, bijvoorbeeld getcustomer(int id) Bij payload semantics gebruiken alle aanroepen dezelfde methode (sendmessage). Wat de server juist moet doen staat in de message. Interface semantics zijn voor de ontwikkelaars gemakkelijker te gebruiken. Ze hebben een lijst met methodes en hun argumenten die ze kunnen oproepen. Wanneer de naam van methodes goed gekozen is, is het ook duidelijk wat de methode doet. Maar wanneer de parameters van de methode veranderen omdat er andere informatie moet worden meegestuurd (interface verandert), moeten alle applicaties die de interface gebruiken, worden verandert (zelfs al gebruiken ze de methode niet) Bij payload semantics kan men bijkomende messages definiëren, zonder dat de client over moet worden aangepast. In de tekeningen wordt gesuggereerd dat interface semantics bij RPC horen en payload semantics bij MOM. Dit hoeft niet. In RPC kan men ook een methode Execute (Message) hebben. SOAP is een voorbeeld van payload semantics. We noemen dit ook dpcument centric messages. Het volledige commando staat in een XML document. Samenvatting service oriented architecture 9
Tight vs Loose coupling Laag Tight coupling Loose coupling Physical coupling Directe fysieke link nodig Tussenpersoon Communicatie stijl Synchroon Asynchroon Types Interface semantics Payload semantics Interactie patroon Object trees Self contained messages Control of process logic Central control Distributed logic Service discovery & binding Platform afhankelijkheid Statically bound Sterk OS en programmeertaal afhankelijk Dynamically bound OS en programmeertaal onafhankelijk Samenvatting service oriented architecture 10
Services Bouwstenen van een Service-oriented architecture Coarse grained (Business driven): de functionaliteit wordt gedefinieerd op het business niveau, niet op het technische niveau We definiëren een aantal namen om gemakkelijker over services te kunnen praten Soorten: Application frontends: eigenlijk geen service, maar wel een onderdeel van een SOA. Basic services: business logic centric, data centric Intermediary services: hulp services Process centric services: beheren een proces Public enterprise services: toegankelijk voor externen Application frontends De client applicaties of batch processen. Ze starten de business processen en ontvangen ook de resultaten. Communiceren met de services over het netwerk Basic services: business logic services Business logic centric services: implementeren de business rules, bijvoorbeeld een service die de kennis bevat over de producten die door een verzekeringsmaatschappij worden verkocht. Deze service kan premies berekenen, betalingen verwerken en terugbetalingen, aanvragen beoordelen, offertes maken en allerlei simulaties uitvoeren Deze functionaliteit behoort standaard tot het backoffice systeem. Alleen iemand van de backoffice kan dan wettelijk bindende overeenkomsten afsluiten. Front office gebruikers hadden geen toegang tot die functionaliteit en moesten het vroeger doen met bijvoorbeeld niet bindende simulaties. Dit is niet klant-vriendelijk ( dit is onze aanbieding, maar alleen het hoofdkantoor kan een definitieve offerte maken ) Een alternatief is die functionaliteit kopiëren naar de PC's van de front office. Maar dat is niet zo eenvoudig (werkt een COBOL programma op die PC, hoe zorg ik ervoor dat alle front office clients de laatste wijzigingen hebben) Een derde mogelijkheid is de front office gebruikers rechtstreeks toegang te geven tot de backoffice. Dit is ogenschijnlijk de beste oplossing. Maar in de praktijk ligt het niet zo voor de hand dat een (externe) agent toegang heeft tot de interne applicaties. Een aparte service kan door alle betrokkenen worden aangesproken. We kunnen aparte interfaces voorzien voor externe gebruikers zodat ze slechts toegang krijgen tot een beperkte functionaliteit (gecombineerd met security) Opgelet: we zeggen hier niets over de implementatie van de service (aparte Java applicatie, toegang via CICS, tekst uitwisselen via een terminal simulatie,...) Basic services: data centric services Data centric services werken met persistente (bewaarde) data Die data kan bewaard worden in een relationele databank, het bestandssysteem of zelfs een Samenvatting service oriented architecture 11
tape library Data centric services lijken sterk op de data access layer in klassieke applicaties (DAL). Het grote verschil is dat in klassieke applicaties de volledige applicatie toegang had tot de volledige databank (via de DAL) Data centric services werken volgens het principe van de vertical layering: één service beheert één business entity. Wanneer een andere service data nodig heeft, moet de data centric service daarvoor worden gebruikt. Nadeel: in een klassieke applicatie is er maar één datastore. Dat is gemakkelijk voor bijvoorbeeld transacties. In een SOA applicatie zijn er meerdere datastores. Wie is er eigenaar van welke data? Hoe kunnen we transacties over meerdere data centric services gebruiken? Intermediary service: technology gateway Bijvoorbeeld: business rules van een legacy applicatie zijn nodig in een moderne (windows user interface) applicatie We zijn van plan om die legacy applicatie ooit eens te herschrijven (re-engineering) Een nieuw project kan daar niet op wachten ( ooit in de informatica = onverwijld in de politiek) we willen niet dat de legacy technology het nieuwe project besmet (we zouden een windows applicatie kunnen ontwikkelen die via terminal streams gegevens uitwisselt met de legacy applicatie) De technology gateway wordt tussen de legacy applicatie en de moderne windows client gezet. De windows client spreekt de technology gateway aan via webservices. De technology gateway vertaalt dit naar terminal streams en stuurt dit door naar de legacy applicatie Opgelet: in een service-oriented architecture zullen we niet één service voorzien voor de gehele legacy applicatie, maar een reeks services. Dat heeft als bijkomend voordeel dat we het re-engineering process ook in stapjes kunnen opdelen. => eerst de application front ends service-oriented maken. Intermediary services: adapter Technology gateway vertaalde de ene technologie naar de andere adapter vertaalt de ene interface naar de andere. Bijvoorbeeld: de merger van twee firma's beide hebben al een SOA architectuur maar de interfaces van de services verschillen Om de application frontends (of services) van firma B te laten werken met de customer data van firma A, gebruiken we een adapter die de aanvragen vertaalt van de ene interface naar de andere Intermediary services: facade Brengt verschillende services tezamen onder één interface Samenvatting service oriented architecture 12
Maar groot gevaar dat men de herbruikbaarheid in gevaar brengt. Door alle services te laten aanspreken via een Common Access server layer introduceren we een groot blok dat altijd in zijn geheel gebruikt moet worden Facades ontwikkelt men best voor één project zodat men de herbruikbaar van de services eronder voor ogen houdt. Facades zijn dikwijls tegelijkertijd ook technology gateways of adapters Intermediary services: functionality adding service Functionaliteit toevoegen aan een bestaande service Het is moeilijk om de bestaande service aan te passen( in de toekomst wordt de bestaande service toch vervangen, de bestaande service is een product van een andere producent) Functionality adding service kan een stap zijn in een evolutie van het ene systeem naar het andere Process centric service Process staat op een hoger niveau dan een service processen maken gebruik van services en sturen ze aan. De verschillende proces stappen maken gebruik van services. Proces moet ook toestand bijhouden (waar zit ik ergens in het proces) extra complexiteit (toestand van het proces) kan in een aparte service worden beheerd load balancing: we kunnen dezelfde service op meer machines zetten. De kan dan niet meer op die machines worden bijgehouden => bijhouden in process centric service multi channel applicaties: co-browsing twee browser sessies met elkaar samenwerken process logic afschermen van busines logic (in servies) en dialog control (in de application front end) Process centric services worden soms vergeten. De proces control zit mee in de basic services of (nog meer voorkomend) in de application front end. Process centric services zijn meestal project specifiek en kunnen moeilijk gedeeld worden tussen verschillende projecten. Vormen een brug tussen SOA en Business Process Modeling We maken hier een verschil tussen de proces control logic (in het Business Process Management System) en de business logic (in de basic layer) Samenvatting service oriented architecture 13
Business logic is stabieler dan Proces control. Business Process Management System => voert model uit Proces layer Intermediary layer Basic layer Public enterprise services Vorige services waren voor intern gebruik public enterprise services worden gebruikt door externen (klanten, leveranciers/partners, ) Business documenten uitwisselen. Bevat alle informatie die nodig is om de dienst te leveren (of om het resultaat terug te sturen). Dit is geen echt document, maar eerder een message (vgl MOM) grote decoupling => asynchrone communicatie en payload semantics niet iedereen mag die service (gratis) gebruiken: aanmelden (authenticatie) Informatie wordt over een publiek netwerk verstuurt: encryptie facturatie: voor het gebruik van de service kan een fee gevraagd worden => registratie van gebruik en integratie met facturatie systeem Service Level Agreements als verzekering voor externen SOA roadmap Men zal SOA niet ineens invoeren Fundamental => network => process-enabled SOA Process logica zit mee in de enterprise layer We hebben eventueel ook de mogelijkheid om data te delen (door een services te delen) => geen data uitwisseling meer tussen applicaties via bijvoorbeeld batch processen In een green field (nieuwe situatie) gemakkelijk te implementeren. Networked SOA voegt een intermediary laag toe via bijvoorbeeld facades (vereenvoudigen van het aanroepen van de operaties) of technology gateways (om legacy applicaties te gebruiken. Door een facade te maken, wordt het aanroepen van Boekingen en facturatie eenvoudiger Samenvatting service oriented architecture 14
(bijvoorbeeld één methode om zowel de boeking als de facturatie te doen) Process enabled SOA's zorgen ervoor dat de process control uit de application frontend verdwijnt. Process centric services zijn 'ful'. Ze onthouden waar de client ergens in het proces zit (welke processtap) Application frontend wordt nog eenvoudiger uitbreiden met intermediary services om bijvoorbeeld technologie af te schermen. Scheiding tussen business logica (in de basic services), process logica (in de process layer) en dialog control (in de application frontend waar de dialog boxen in de user interface bepalen welke processen gestart worden en hoe de informatie die de processen nodig hebben wordt verzameld) Andere view Level 1: Ad-hoc Level 2: Defined Level 3: Standardized Level 4: Managed Level 5: Agile Business Ad hoc Business Defined Business Standardized Business Managed Business Agile Business Organization Ad hoc Organization Defined Organization Standardized Organization Managed Organization Agile Organization Program Management Ad hoc program management Defined program management Standardized program management Managed program management Agile program management Governance Ad hoc governance Defined governance Standardized governance Managed governance Agile governance Technology Ad hoc technology Defined technology Standardized technology Managed technology Agile technology Operations and Management Ad hoc operations and management Defined operations and management Ad hoc operations and management Managed operations and management Agile operations and management Samenvatting service oriented architecture 15
Facturatieproces 1) Bestaat klant: nee => maak klant 2) Maak factuur Klant: nr, naam, adres, geboortedatum Factuur: Klantgegevens, factuurnr, Datum, 1 of meerdere factuurlijnen (product, eenheidsprijs, aantal, subtotal), total, BTW Services Klant o Lijst klanten <=FindKlant(zoekcriteria) o Klnr<=CreateKlant(naam, adres, gebdatum) Factuur o Facnr<=CreateFactuur(klnr, naam, adres, facdatum, factuurlijnen) Product o Product <=FindProduct (productnr) Bestelling(process centric) Samenvatting service oriented architecture 16
Process integriteit Data/process integriteit: we willen geen slechte data in het systeem. Bijvoorbeeld wanneer we een geboortedatum ingeven, mag die niet in de toekomst liggen. (voorbeeld van data integriteit) Data integriteit kan dikwijls worden afgedwongen door de databank process integriteit is moeilijker te implementeren dan data integriteit. Stel dat we twee systemen hebben: één systeem is verantwoordelijk voor de bestellingen, het tweede systeem is verantwoordelijk voor de facturatie. Elke nacht worden de bestellingen via een batch proces doorgestuurd naar het facturatie systeem. Bestelling en facturatie maken deel uit van hetzelfde proces. Neem nu de volgende situatie: klant bestelt maandag een product nacht maandag-> dinsdag wordt de bestelling doorgestuurd naar het facturatiesysteem dinsdag annuleert de klant de bestelling systeem bevat een inconsistentie: er zit een bestelling in het facturatie systeem die niet meer bestaat Hoe kunnen we processen integer/consistent houden? (gegeven dat een proces dikwijls uit een mix van systemen bestaat die historisch gegroeid is) Soorten fouten die gevolgen kunnen hebben voor de proces integriteit Technische fouten: databank crash, netwerkproblemen Technische problemen kunnen vaak opgelost worden door de technische omgeving (database recover, transacties gebruiken, opnieuw proberen in geval van netwerk problemen. Soms kan dit ingewikkelder zijn, bijvoorbeeld met netwerkproblemen kunnen we omgaan door tijdelijk de data die moet worden doorgestuurd te stockeren. Business exceptions: vlucht boeken in het verleden (kan zelfs worden afgehandeld in de user interface) moeilijkere gevallen: out of stock. Ga ik gewoon tegen de klant zeggen niet meer in voorraad? Betere oplossing op tijd bij bestellen (maar dit is een veel ingewikkelder oplossing: wanneer ga ik bijbestellen?) Speciale gevallen: afwijkingen van het happy path. Speciale gevallen vereisen veel meer programmeerwerk dan het happy path kunnen erg ingewikkeld worden: ga ik een vliegtuig/boot gewoon volboeken (veilig) of een beetje overboeken (commercieel interessanter) Oplossingen voor problemen Logging en tracing wijzigingen bijhouden (en wie ze uitgevoerd heeft) Wanneer we weten wat er gebeurd is, kunnen we bepaalde stappen ongedaan maken. Dikwijls manueel oplossen van problemen op basis van gelogde gegevens. (manueel oplossen is in eerste instantie soms goedkoper dan software te ontwikkelen die dit automatisch kan doen) Samenvatting service oriented architecture 17
Probleem: mix van systemen, verschillende logs => hoe vind ik de log entries terug die bij een bepaald proces horen (dikwijls alleen log entries met tijdsaanduiding) logging dikwijls in service bus ACID transacties Transactie: unit of work in de databank (geld overschrijven is geld afhalen van de ene rekening en storten op de andere rekening) ACID: Atomicity: ofwel gaan alle stappen in de transactie door, ofwel gaat er geen enkele stap door Consistency: transacties brengen het systeem van de ene consistente toestand naar de andere (geld overschrijven: de som van de rekeningen voor en na de overschrijving moet hetzelfde zijn. Er mag nooit een toestand voorkomen dat er teveel of te weinig geld op de rekeningen staat) Isolation: intern kan er altijd een toestand zijn die niet consistent is. Er is namelijk altijd een moment dat de aanpassing al gebeurd is op de ene rekening maar niet op de andere. Andere processen mogen deze toestand echter niet zien. Dat wordt opgelost via locking durability: Eenmaal dat de transactie is afgelopen moeten de data voorgoed weggeschreven zijn in de databank. Transaction monitors en 2 phase commit (2PC) ACID transacties werken alleen binnen één databank Wanneer een transactie moet gebeuren over twee verschillende databanken heen (geld van databank 1 moet overgeschreven worden naar databank 2) => distributed transaction coördinator 2 phase commit: elke databank moet zich in een toestand zetten zodat de aangepaste gegevens voorgoed kunnen worden weggeschreven (nodige locks zijn gezet bijvoorbeeld) maar ook dat ze niet weggeschreven kunnen worden Afhankelijk van de uitkomst van de vorige stap (elke databank geeft door of de update zal kunnen lukken) zal de transaction coördinator doorgeven dat de wijzigingen persistent moeten worden gemaakt (elke databank heeft doorgegeven dat het in orde is) Wanneer niet elke deelnemer heeft doorgegeven dat het in orde is, krijgt elke deelnemer de opdracht om de wijzigingen ongedaan te maken. Problemen met 2PC en ACID transacties performantie: transacties vertragen het systeem (onder meer wegens de locks) transacties zijn ontworpen om gebruikt te worden voor een korte duur. (locks niet te lang vasthouden) + proces transacties duren veel langer. Combinatie met legacy systemen en packaged applicaties (ERP, CMS): distributed transacties worden niet altijd ondersteund door legacy systemen of door packaged applicaties 2PC vereist een goede netwerk verbinding Samenvatting service oriented architecture 18
Compensaties Bijhouden welke stappen er moeten worden gezet om de acties ongedaan te maken. (Rek1 500) en (Rek2 + 500) => compensaties (Rek1 + 500) en (Rek2 500) Dit is een business oplossing (geen ACID transactie) omdat andere processen in principe de tussentoestand kunnen zien. Via een persistent queue kunnen we bijhouden wat er gebeurd is op een systeem. Elke stap die wordt uitgevoerd, wordt uit een lijst (queue) gehaald en na het uitvoeren in een tweede queue gestoken. De tweede queue bevat een lijst met alles wat er is uitgevoerd op de databank (in dit geval) (Hopelijk volstaat deze informatie om alle stappen ongedaan te maken) Concurrency contol Zorgen dat we rekening houden met multi user systemen: verschillende processen kunnen met dezelfde data proberen te werken twee oplossingen: optimistic en pessimistic concurrency control pessimistic locking van gegevens: zolang proces 1 met de data bezig is, kan niemand anders eraan niet aan te raden omdat dit grote gevolgen kan hebben voor de performantie optimistic proces 1 leest gegevens in proces 1 schrijft wijzigingen weg MAAR alleen wanneer ze ondertussen niet gewijzigd zijn ('versie' is niet veranderd) optimistic concurrency veel minder gevolgen voor performantie onwerkbaar wanneer er processen dikwijls met dezelfde data werken In een meer verfijnde vorm kunnen we proberen om de wijzigingen samen te voegen (merge) met de nieuwe gegevens die aanwezig zijn in de data. We lezen bijvoorbeeld de volgende gegevens in: Naam: Joske Vermeulen Straat: Trammezandlei 122 We veranderen de naam in Jos Vermeulen en proberen de gegevens weg te schrijven. Dat lukt niet want de gegevens zijn ondertussen gewijzigd. De nieuwe gegevens zijn: Naam: Joske Vermeulen Straat: Trammezandlei 124 Aangezien de aanpassing op twee verschillende plaatsen is gebeurd zouden we de gegevens kunnen Samenvatting service oriented architecture 19
samenvoegen: Naam: Jos Vermeulen Straat: Trammezandlei 124 Pessimistic locking We spreken hier niet over pessimistic locking op het niveau van de databank. Maar pessimistic locking wordt geïmplementeerd door de applicatie. Pessimistic locking zal gebruikt worden in plaats van optimistic locking wanneer er dikwijls gelijktijdige write operaties gebeuren op dezelfde data. Optimistic locking is dan minder interessant omdat de gebruiker die als tweede schrijft een foutmelding zal krijgen (begin maar terug opnieuw want iemand anders heeft de data al gewijzigd) Pesssimistic locking wordt op applicatie niveau geïmplementeerd door voor elke entity (klant, factuur, product, factuur, ) een aparte eigenschap 'LOCKED BY' te voorzien. Wanneer een gebruiker een wijziging wil aanbrengen, wordt er gekeken of het LOCKED BY attribuut is ingevuld. Wanneer dat het geval is, krijgt de gebruiker de melding dat het item op dit moment niet gewijzigd kan worden. Wanneer LOCKED BY niet is ingevuld, wordt het ingevuld met de ID van de gebruiker. (wanneer een ander proces probeert het veld te wijzigen, zal dat proces nu de foutmelding krijgen). De gebruiker voert de aanpassingen uit en wanneer de nodige aanpassingen zijn gebeurd, wordt het LOCKED BY veld terug leeg gemaakt. Op het eerste zicht lijkt dit eenvoudig, maar: we moeten zorgen dat er bij elke aanpassing wordt gechecked of het item gelockt is door de gebruiker zelf We moeten een beheertool voorzien waarmee locks kunnen worden veranderd (een item is toegewezen aan een gebruiker en een andere gebruiker moet het afhandelen) We moeten ook rekening houden met het feit dat een lock soms niet meer wordt vrijgegeven (bijvoorbeeld omdat de client is gecrasht). Via een management tool moeten dit soort van locks kunnen vrijgegeven. Idempotente operaties Stel dat ik een website heb om iets te bestellen De gebruiker vult gegevens in en drukt op de bestellen-knop Doordat het netwerk nogal traag is, heeft de gebruiker de indruk dat er niets gebeurt en drukt hij/zij op 'vernieuwen' (F5) Wat gebeurt er? (in de praktijk niets omdat websites dit meestal zelf oplossen) Een idempotente operatie zorgt ervoor dat een client een operatie nooit meerdere keren kan uitvoeren of dat het geen effect heeft wanneer de gebruiker een operatie meerdere keren zou uitvoeren. Dit probleem komen we tegen bij Add/increment operaties. (verhoog het aantal bestellingen met 1) Dit probleem treedt niet op bij set-operaties (verander de naam Joske in Jos ) We zorgen er dus best voor dat operaties vooral set-operaties zijn. Een andere oplossing is gebruik maken van sequence nummers. Wanneer een client een operatie wil uitvoeren, vraagt hij een nummer aan de service Samenvatting service oriented architecture 20