ESB Les 2 IBK3ESB01 Paul J. Cornelisse. ESB : alles draait om services… Service composition Service reusability Service transactions Two-phase commit.

Presentatie over: "ESB Les 2 IBK3ESB01 Paul J. Cornelisse. ESB : alles draait om services… Service composition Service reusability Service transactions Two-phase commit."— Transcript van de presentatie:

1 ESB Les 2 IBK3ESB01 Paul J. Cornelisse

2 ESB : alles draait om services… Service composition Service reusability Service transactions Two-phase commit Service repositories Service relocation SOA-Service proxy

3 Service composition Service Composition betekent: “het samenstellen van een grotere dienst door het combineren van vele kleinere diensten” Dit is analoog aan het samenstellen van een grotere software component uit meerdere kleinere componenten

4 Service composition

5 Service Composition kan er aanlokkelijk uitzien op papier, net als component composition, houd in gedachten dat de diensten doorgaans met elkaar communiceren via het netwerk

6 Service composition Dit betekent dat de inter-service communicatie veel trager is dan typische inter-component communicatie, die doorgaans plaatsvindt in dezelfde adresruimte (applicatie / proces).

7 Service composition Als een grotere service wordt ontbonden in te veel kleinere services, kan dit invloed hebben op de performance Vooral als de services intern communiceren via de ESB

8 Service composition Binnen SOA lossen we dit op door Service Statelessness te introduceren Ontwerp schaalbare services door ze waar mogelijk te scheiden van hun status data; die wordt “extern” bijgehouden” Resulteert in minder resources gebruikt door een service  betrouwbare verwerking van meer service aanroepen

9 Service reusability De herbruikbaarheid van een Service hangt sterk af van het ontwerp en het doel Met “reusability" wordt bedoeld hoe applicaties of grotere diensten, een bepaalde kleinere dienst kunnen hergebruiken

10 Service reusability Stel je hebt twee applicaties, A en B, die beide behoefte hebben aan klantinformatie Applicatie A heeft alleen de klant- voornaam en achternaam nodig, applicatie B heeft de klantvoornaam, achternaam, klantnummer, telefoonnummer, e-mailadres nodig

11 Service reusability First Name Last Name Application A First Name Last Name Customer Number Phone Number Email Address Application B

12 Service reusability Je hebt nu twee opties Maak een grote service waarin alle klanteninformatie terugkomt Maak twee Services. Een die alle klantinformatie, en een die alleen voornaam en achternaam weergeeft

13 Service reusability Vanuit een service reusabilityperspectief heeft het natuurlijk de voorkeur om slechts een service “klanten” te ontwikkelen en te hoeven onderhouden Deze dienst kan dan worden hergebruikt in zowel applicatie A en B.

14 Service reusability Vanuit het oogpunt van performance echter, zou de grote service “klanten” bij gebruik door applicatie A (die hoeft alleen de voornaam en achternaam), een te grote belasting op de transportlaag leggen Dit omdat er meer gegevens verstuurd zouden worden dan de toepassing nodig heeft

15 Service reusability Service mediation

16 Service mediation layer Bron: http://artofsoftwarereuse.com/2009/06/14/the-value-of-service- mediation/ an abstraction layer in between the service consumer and the service provider

17 Service transactions Eens in de zoveel tijd moeten services deelnemen aan transacties Dit wordt gedaan om ervoor te zorgen dat de business logica correct en volledig wordt uitgevoerd, óf volledig geannuleerd in het geval een van de diensten niet correct performt

18 Service transactions Voorbeeld: Een bank applicatie moet geld van de ene rekening naar de andere overmaken Momenteel heeft het banksysteem twee diensten: Storten Opnemen

19 Service transactions

20 Om geld van de ene rekening naar de andere te transporteren, moet de bank applicatie de services opnemen en betalen aanroepen Bijvoorbeeld, eerst € 100 opnemen van rekening A, en dan storten van € 100 op rekening B

21 Service transactions Als dit laatste niet lukt komt het systeem in een “inconsistent state” en wordt het risico gelopen dat er € 100 in cyberspace vervliegt. De oplossing is om iedere transactie “atomair” te behandelen

22 Atomaire transactie Een transactie groepeert een of meer acties bij elkaar, en zorgt ervoor dat ze worden uitgevoerd alsof het een enkele actie is. Als een van de acties faalt, dan leg je op dat alle acties falen (en dus ook de transactie faalt). Indien alle acties slagen wordt het resultaat van de acties “committed" (permanent opgeslagen) in het systeem

23 Atomaire transactie

24 Two phase commit Transaction Diensten die deelnemen aan een transactie moeten worden gecoördineerd om ervoor te zorgen dat hetzij alle óf geen enkele van de diensten hun acties binnen die transactie worden “ge- commit” Een populaire manier om dergelijke gedistribueerde transacties te coördineren is het "Two Phase Commit” (2PC) protocol.

25 Two phase commit Transaction Het twee fase commit protocol bestaat, na aanwijzen van een coördinator, uit de fasen: 1. Prepare / vote fase 2. Commit fase

26 Two phase commit Transaction Eerst wordt alle deelnemers verteld dat zij moeten deelnemen aan een transactie Vanaf dit punt, moeten alle acties die worden uitgevoerd door elke deelnemer verwijzen naar deze transactie Elke deelnemer moet al zijn acties uitvoeren als één enkele actie (locaal alles óf niets). Indien alles succesvol: vote YES; anders vote NO.

27 Two phase commit Transaction De acties worden niet vastgelegd in het hoofdsysteem, maar moeten locaal in elke deelnemer (Service) worden voorbereid en bewaard (status logging), totdat de deelnemer de instructie ontvangt om de handeling echt door te voeren (commit-ten)

28 Two phase commit Transaction Als alle acties succesvol zijn uitgevoerd door alle deelnemers (allemaal YES- votes), wordt alle deelnemers bevolen om naar de ”commit fase“ te gaan Als een deelnemer succesvol door de “prepare fase” komt (= status ‘prepared’ bereikt), moet ze garanderen dat alle acties die binnen de transactie uitgevoerd worden klaar staan om te worden vastgelegd

29 Two phase commit Transaction Als de deelnemer, nadat de actie status “prepared” heeft bereikt, niet in staat is de actie te voltooien, moet ze in staat zijn deze af te maken zodra ze weer correct functioneert Vanuit deze fase moet de actie een crash / reboot kunnen overleven Dit wordt meestal gedaan door het schrijven van een transactie log naar een duurzaam opslagmedium, zoals een harde schijf.

30 Two phase commit Transaction Als een van de deelnemers niet naar de “commit fase kan” moet door alle deelnemers een rollback (Abort) worden uitgevoerd

31 Two phase commit Transaction Als alle deelnemers met succes de status “prepared” hebben bereikt, wordt het commando “commit” gegeven Hierna worden de acties doorgevoerd en zijn de wijzigingen definitief zichtbaar in het systeem/de systemen

32 Two Phase Commit zwakte Niet 100% betrouwbaar Wat als de laatste service in de keten geen commit kan geven? Wat als deze niet meer opkomt? Wat is dan de status van het systeem?

33 Two Phase Commit zwakte

34 Tranactiecoördinatie Er moet een instantie zijn die de coördinatie voert De applicatie De ESB Een separate transactiemanager/service

35 Tranactiecoördinatie Een manier om het transactie management te vereenvoudigen is: Breng alle onderdelen onder in aparte onderliggende services

36 Tranactiecoördinatie

37 Service repository Een Service Repository is een catalogus waarin staat welke services beschikbaar zijn Iedere service heeft zijn eigen service contract, hierin staat wat de ‘capabilities’ van de betreffende service zijn Clients kunnen de repository raadplegen als een bepaalde service benodigd is

38 Service repository

39 Service relocation Als de clients de services opzoeken via de service repository, wordt het migreren van services eenvoudiger Alleen de service repository hoeft ge- update te worden zodat de bovenliggende client de service weer tot zijn beschikking heeft

40 SOA-Service proxy Een service proxy is een service die service calls vertaalt tussen twee verschillende client-service protocollen Dit klinkt abstract, dus hier is een voorbeeld:

41 SOA-Service proxy Stel: je hebt een service die alleen toegankelijk is via de Java RMI (Remote Method Invocation). Je wil graag toegang krijgen tot deze service via een webservice (SOAP)- interface, omdat de rest van de (service oriented) architectuur is gestandaardiseerd op SOAP.

42 SOA-Service proxy Om dit probleem op te lossen installeren we een service proxy, die SOAP oproepen ontvangt en deze vertaalt in hun overeenkomstige RMI oproepen om de Java RMI-service te aan te kunnen roepen

43 SOA-Service proxy

44 ESB als service proxy Sommige ESB's hebben ingebouwde capaciteit/functionaliteit om te fungeren als service proxy Dit maakt het veel eenvoudiger om delen van het landschap aan elkaar te knopen

45