1. Historisk utveckling 2. Tjänstekonceptet 3. SOA bakomliggande principer 4. SOA - Metamodell 5. XML 6. Roller. Pär Douhan,

Transkript

1 Enterprise Architecture (EA) FÖ2 1. Historisk utveckling 2. Tjänstekonceptet 3. SOA bakomliggande principer 4. SOA - Metamodell 5. XML 6. Roller 1 Pär Douhan, pdo@du.se

2 Arkitektur Historisk utveckling 2

3 Historisk utveckling (Paul Strassmann, 2011) 3

4 Systemarkitekturer (Paul Strassmann, 2011) Fokus på funktioner Fokus på processer Fokus på samverkan Funktionerna var Enterprise system Samverkan med kunder isolerade från varandra Från beställning till Samverkan med leverantörer Intra-organisatorisk leverans Extern-organisatorisk kontext kontext Inter-organisatorisk Grid computing kontext From systems to services 4

5 Responstid (Paul Strassmann, 2011) 10 milj. Sekunder = 3,8 månader Det som driver utvecklingen är kortare svarstider och allt större datamängder Detta ställer nya krav på arkitektur Google är redan där! 5

6 Vad krävs? SOA! Vad är Service Oriented Architecture (SOA)? En metod för design,, produktion och förvaltning av informationssystem (IS): Alla IS utformas som tjänster som är åtkomliga och exekverbara via nätverk Tjänsternas gränssnitt (interface) baseras på publika standarder d för informationsutbyte i 6

7 SOA = Evolution SOA = Evolution 7

8 1960 och 70 talet Mainframe Dum Terminal Data Affärslogik (Business rules) Presentation Fördelar Enkelhet! Miljön är känd Man vet hur accessen ser ut Nackdelar Skalbarhet! Om fler användare, Om fler applikationer, Mainframe måste sköta allt 8

9 1980 talet Mainframe Client/Server Arkitektur PC Data Presentation Affärslogik, T.ex. validering i Fördelar Nackdelar 9 Skalbarhet! Underhåll! Om högre belastning i form av fler användare, så En administratörs mardröm utförs mycket av jobbet av PC-datorerna Uppdatera program på 5000 PC Om fler applikationer, så installeras dessa på Olika OS PC-datorerna Win XP SP1, XP SP4, Win 2000, Win 98

10 Sent 1990, tidigt 2000 tal N-Tier Arkitektur Databas Applikationsserver Klient med webbläsare Data Applikationer Fördelar Nackdelar Skalbarhet! Komplexitet på app.servern! Klustrade servrar vid hög belastning Var finns modulen som utför kreditkontroll? I Enkelt att underhålla applikationer som bara finns databasen? På app.servern? på app.servern Omöjligt för ett PLSQL bibliotek i en Forms app. Att komma åt en modul skiven i Java på en Linuxserver 10

11 SOA Tjänstekonceptet 11

12 Vad är en tjänst? Inom ekonomisk teori är en tjänst en immateriell handelsvara en (säljbar) produkt som produceras för att tillfredsställa ett behov eller ett önskemål (Wikipedia) "A service is a logical representation of a repeatable activity that has a specified outcome. It is self-contained and is a black box to its consumers. (The Open Group) Den utför någon typ av arbete (funktion): Service A Kreditkortskontroll ts o t o Skicka faktura Betala ut lön Köpa biobiljett Räkna ut ränta 12

13 Använda en tjänst Inom SOA, kan tjänster användas av andra tjänster eller program. Detta kräver att tjänsterna är medvetna om varandras existens Denna medvetenhet uppnås genom användandet av s.k. service descriptions. Service A Service B Service description for service B Eftersom Service A har tillgång till Service B s service description, så har Service A all information som behövs för att kommunicera med Service B. 13

14 SOA Bakomliggande principer 14

15 Bakomliggande principer för SOA Service-Orientation Design Principles 1. Loose coupling Tjänster är löst kopplade till varandra Behöver bara veta vad tjänsten heter Vad den gör Hur den anropas Och vad den skickar tillbaka Spelar ingen roll om ett javaprogram på Linux eller en PLSQL procedur i en Oracle databas anropar Vi kan anropa den från ios eller Android Tjänsten är plattforms- och OS- och programoberoende Vi kan alltså skapa tjänster eller web services (webb tjänster) i Java på windows som kan kommunicera med tjänster skapade i C++ på Linux Tidigare var det i princip omöjligt för ett javaprogram som kördes i Linux att kommunicera med ett PLSQL bibliotek i en Oracle Forms applikation 15

16 Bakomliggande principer för SOA Service-Orientation Design Principles 2. Service contract Tjänsterna följer ett gemensamt avtal Detta avtal finns beskrivet i ett eller flera s.k. tjänstebeskrivningsdokument Kallas Service Level Agreement (SLA) Innehåller WSDL XML schema WS Policy En rad olika dokument som beskriver tjänsten på olika sätt T. ex. 24 x 7 availability 2 sec. response time Intranet access only 100 ms response time Security Functional specifications Exceptions 16

17 Bakomliggande principer för SOA Servicekontraktet ska gå att läsa av människor Alla tjänster ska ha ett kontrakt som baseras på en fördefinierad mall (template) Innehåller funktionella aspekter T.ex. vad en tjänst gör för någonting Detta måste vara kopplad till ett fördefinierad terminologi. Alla ska veta vad termen kreditkontroll är. Innehåller icke-funktionella aspekter T.ex. QoS Tanken bakom detta är att underlätta återanvändning 17

18 Bakomliggande principer för SOA Service-Orientation Design Principles 3. Service abstraction Det enda omvärlden känner till om tjänsten är det som finns beskrivet i servicekontraktet Tjänstens logik är inte synlig för omvärlden Ett resultat av den här principen är att konsumenter av tjänster inte vet om tjänsten, som de använder, är stand alone eller komponerad av flera andra tjänster 18

19 Bakomliggande principer för SOA Service-Orientation Design Principles 4. Service reusability Programfunktioner delas upp i tjänster Avsikten är att understödja återanvändning Within service-orientation reusability represents a core target design characteristic that is tied to the goal of achieving repeated ROI for agnostic services. ( ) agnostic services are not aware of the context in which they are being called, nor are they aware of how the service is implemented, which platform, technology etc. 19

20 Bakomliggande principer för SOA Service-Orientation Design Principles 5. Service composability Möjligheten att sätta ihop flera tjänster till en sammansatt eller komposit tjänst. Ibland kallas denna komposita tjänst för komponent På detta sätt kan vi lösa stora och komplexa problem genom att låta flera tjänster samarbeta Man kan alltså ge sig på ett stort komplext problem och bryta ner det till mindre hanterbara delproblem Sedan kan man låta tjänster lösa delproblemen 20

21 Bakomliggande principer för SOA SOA är ett design paradigm med ett tydligt fokus på att bryta ner problem till mindre delproblem Big Problem A Små delproblem representerar kollektivt det stora problemet Small Problem Small Problem Small Problem Small Problem Enheter av solution logic som enskilt löser ett litet problem A B C D 21

22 Bakomliggande principer för SOA A B D För att lösa Big Problem A, sätter man ihop enheterna enligt en viss specifikation som tillåter enheterna att lösa problemet på ett koordinerat sätt C Orchestration versus Choreography Hands on introduction to BPEL Löser Big Problem A 22

23 Bakomliggande principer för SOA Service-Orientation Design Principles 6. Service autonomy Tjänsten har kontroll över den logik som den innehåller Detta är viktigt när tjänster ska sättas ihop till sammansatta tjänster 23

24 Bakomliggande principer för SOA Service-Orientation Design Principles 7. Service statelessness Ibland kan en tjänst behöva information om olika typer av tillstånd T. ex. interaktionsspecifik data, någon fyller i ett webbformulär och skickar iväg innehållet Ett tillstånd kan vara att komma ihåg hur formuläret var ifyllt. State data management consumes system resources 24

25 Bakomliggande principer för SOA State data is commonly o deferred ed at runtime ut eaow allowinga service to remain active and stateless while other processing occurs. 25

26 Bakomliggande principer för SOA Service-Orientation Design Principles 8. Service discoverability Explorativ metadata "Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted." 26

27 SOA Uppbyggnad av en tjänst 27

28 Uppbyggnad av en tjänst En tjänst består av tre delar: 1. The implementation Tjänsten är utvecklad, testad och driftsatt Konfigurerad infrastruktur 2. The interface Beskriver hur vi anropar tjänsten 3. The contract Beskriver vad tjänsten erbjuder och dess constraints 28

29 Metafor En användbar metafor för nedbrytandet av en tjänst till föregående tre delar kan vara att likna det vid ett kraftbolag som levererar el till kunder: The implementation är metoderna som används för att generera ström: solkraft, vattenkraft, kärnkraft etc. och elnätet som gör den producerade elen tillgänglig för olika kunder. Konsumenterna behöver inte veta hur elen tillverkas eller var den kommer ifrån. The interface är eluttaget. För att många olika typer av produkter ska kunna anslutas till eluttaget så har en standard upprättats vad gäller strömstyrka och spänning, samt hur eluttagen ser ut. The contract är överenskommelsen att betala ett visst pris för strömförbrukningen vid vissa intervall. Kunden kan förhandla med elbolaget för att få vissa villkor uppfyllda (QoS) allt detta finns då beskrivet i (SLA) 29

30 SOA - översikt 30

31 UML - diagram Instansnivå Typnivå 31

32 Process, tjänst och data Process Processen kopplas till tjänsten Tjänst Tjänsten kopplas till data Data 32

33 SOA Meta modell 33

34 SOA Meta Model 34

35 SOA Logical Model Representerar business objects Kund, order, faktura XML struktur 35

36 SOA XML 36

37 XML Egna självstudier efter föreläsningen: p 37

38 SQL - Data select persnr,fnamn from bilägare; PERSNR FNAMN Jan-Erik Mbtuu Arne arrne Anna-Lena Urban 38

39 SQL -> XML Data <?xml version="1.0"?> <ROWSET> <ROW> <PERSNR> </PERSNR> <FNAMN>Jan-Erik</FNAMN> </ROW> <ROW> <PERSNR> </PERSNR> <FNAMN>Mbtuu</FNAMN> </ROW> <ROW> <PERSNR> </PERSNR> <FNAMN>Arne</FNAMN> </ROW> <ROW> <PERSNR> </PERSNR> <FNAMN>arrne</FNAMN> </ROW> <ROW> <PERSNR> </PERSNR> <FNAMN>Anna-Lena</FNAMN> </ROW> <ROW> <PERSNR> </PERSNR> <FNAMN>Urban</FNAMN> </ROW> </ROWSET> select dbms_xmlgen.getxml( 'select persnr,fnamn from bilägare') from dual; 39

40 Tabellstruktur -> XML struktur BILÄGARE persnr fnamn <table= bilägare > <columns> <name= persnr /> <datatype= string /> <allownulls= false /> </name> <name= fnamn > <datatype= string /> <allownulls= false /> </name> </columns> </table> 40

41 XML schema <schema targetnamespace=" xmlns:po=" xmlns=" <complextype name="purchaseordertype"> <sequence> <element name="ponum" type="decimal"/> <element name="company"> <simpletype> <restriction i base="string"> " <maxlength value="100"/> </restriction> </simpletype> </element> <element name="item" " maxoccurs="1000"> <complextype> <sequence> <element name="part"> <simpletype> <restriction base="string"> string <maxlength value="1000"/> </restriction> </simpletype> </element> <element name="price" type="float"/> </sequence> </complextype> </element> </sequence> </complextype> <element name="purchaseorder" type="po:purchaseordertype"/> </schema> 41 Filen PO.xsd beskriver struktur och andra egenskaper för en ikö inköpsorder (PurchaseOrder)

42 PO.xml godkänd enligt PO.xsd XML-fil innehållande data för en inköpsorder <PurchaseOrder xmlns=" com/po xsd" xmlns:xsi=" xsi:schemalocation=" <PONum>1001</PONum> <Company>Oracle Corp</Company> <Item> <Part>9i Doc Set</Part> <Price>2550</Price> </Item> </PurchaseOrder> </schema> Filen valideras mot PO.xsd. Uppfyller den inte kravet på struktur och innehåll går den inte att skicka iväg. 42

43 XML - SOAP SOAP skickas över HTTP Vi kan skicka med bilagor i SOAP-protokollet Bilder, filmer och dokument 43

44 Arkitektur Roller 44

45 Roller 45

46 ROI 46