Erfaringer med Service Orienteret Arkitektur

Transkript

1 Erfaringer med Service Orienteret Arkitektur ved Adm. direktør Niels Henrik Sodemann, Ementor Danmark A/S PA Consulting , Tuborg Boulevard 5, DK-2900 Hellerup SOA er som bekendt et sæt af principper i form af løse koblinger, åbne standarder, procesorientering med videre for at skabe interoperabilitet mellem forskellige it-systemer uanset platform og geografisk placering. Med udgangspunkt i et konkret og meget visionært system til den offentlige sektor fortælles om erfaringerne med at anvende SOA som arkitekturprincip for opbygning af en it-arkitektur. Der fortælles også om erfaringerne med opbygning af en enterprise arkitektur, og endelig fortælles om hvordan selve processen kan dokumenteres.

2 Agenda DFFE-CAP hvad er det? SOA hvad, hvorfra og hvorfor Enterprise arkitektur SOA Arkitektur / teknologi Opsamling

3 DFFE-CAP projekt hvad er det? Kunde: DFFE Direktoratet for FødevareErhverv Landbrugsstøtte administrationssystem Vision Bla. den nye CAP (Common Agricultural Policy) ordning 100+ andre ordninger Ca. udbetaling af 15 mia. DKK pr. år landmænd 500 sagsbehandlere Kunden i centrum Parameterstyret rammesystem Service Orienteret Arkitektur

4 DFFE-CAP projekt hvad er det? Stabil applikationsinfrastruktur Forventet timers projekt Ca i Danmark Resten i Ementors ODC i Chennai Udvikles på (b)leading-edge Microsoft.NET teknologier Biztalk 2006 R2 (TAP) C#,.NET 3.0, WinWF, WCF, MOSS 2007 mfl.

5 Agenda DFFE-CAP hvad er det? SOA hvad, hvorfra og hvorfor Enterprise arkitektur SOA Arkitektur / teknologi Opsamling

6 SOA og Enterprise Arkitektur er komplementære salt og peber Enterprise Arkitektur er et holistisk syn på forretning, it og deres indbyrdes sammenhænge En Enterprise Arkitektur metode kan bruges til at udvikle mange arkitekturer og views: Service Orienteret Arkitektur Services, applikationer og informationer i fokus Forretnings-arkitektur Strategier, begreber, processer og services i fokus Traditionel applikations- og informationsarkitekur Funktionsorienteret, og kan være mere monolitisk Teknologi-infrastruktur arkitektur Teknologivalg og infrastruktur servere, klienter, netværk i fokus SOA er et arkitekturprincip (mønster) Løse koblinger Genbrugelighed Brug af åbne standarder for data og teknologi Service-view på hvad it skal levere til forretningen Fokus på interoperabilitet (nem integration - integrationsbus) En Service Orienteret Arkitektur kan udvikles top-down (enterprisewide) via trin i en Enterprise Arkitektur metode (anbefales) kan udvikles bottom-up. I så fald fører det normalt blot til web-enabling, men ikke egentlig service- og datakonsolidering (anbefales ikke)

7 SOA Service Orienteret Arkitektur SOA er et arkitekturprincip for opbygning af it-arkitektur løse koblinger (atomare, autonome) åbne standarder procesorientering mm. Formål skabe interoperabilitet mellem forskellige it-systemer uanset platform eller geografisk placering En service er en selvstændig applikation, der understøtter en del af forretningen 7

8 Four Tenets of Service Orientation Tenet 1: Boundaries are Explicit Tenet 2: Services are Autonomous Tenet 3: Services share Schema and Contract, not Class Tenet 4: Service compatibility Is based upon policy

9 SOA begreber XML: tekst-fil med hierarkiske data Web-services / SOAP: (Simple Object Access Protocol) XML baseret funktionskald over HTTP (www protokol) ESB: Enterprise Service Bus, som er den infrastruktur der afvikler web-services / SOAP et fælles messaging -lag der forbinder (løst koblede) applikationer Workflow / proces Besked Sikkerhed Udstilling af services (UDDI katalog) Driftovervågning Brugere Økonomi Interessenter Uddata Besked Sag 9

10 Traditionel system opbygning Et system varetager mange funktioner Funktioner kan være opdelt i separate moduler Tilgangen sker gennem en fælles brugergrænseflade Alle processer udstilles som implementeret funktionalitet, typisk gennem brugergrænsefladen ESDH og Økonomisystemer er eksempler på ovenstående Processer GUI Brugere Økonomi Kunder Dokumenter 10

11 Traditionel system tilgang GUI GUI GUI GUI Processer Brugere Økonomi Kunder Processer Adresser Sager Rapporter Processer Brugere Økonomi Kunder Processer Adresser Sager Rapporter Dokumenter Skanning Dokumenter Skanning System 1 System 2 Tung klient 11 System 1 System 2 Portal

12 Traditionel system sammenknytning 12

13 Overgang fra silo til separate applikationer (services) Opdeling af systemdele i domæner og begreber Måske mindre end 40% af kommunal sagsbehandling understøttes alene af FESD / ESDH system Mange sagsgangs i centraladministrationen kræver mere end FESD / ESDH Processer GUI Brugere Økonomi Kunder Dokumenter Processer GUI Adresser Sager Rapporter Skanning Bruger administration Sager og dokumenter Kunder og andre adressater Økonomi Uddata Sag Hændelse Dokument Sagsbehandler Sagspulje Facet Rettighed Kunde Adresse Sagspart Advisering Kvitteringsbrev Masseudsendelse System 1 System 2 Domæner Begreber 13

14 Overgang fra silo til separate applikationer (services) Opdeling af systemdele i services Brugere Økonomi Processer GUI Brugere Økonomi Kunder Dokumenter Processer GUI Adresser Sager Rapporter Skanning Interessenter Sag Uddata System 1 System 2 14 Services

15 ESB en som centraliseret integrationsplatform Portal Integrationsplatform Fælles data og metadata 15

16 Enterprise Service Bus - Sammenbinding af services Besked Besked Brugere Interessenter Uddata Økonomi Sag 16

17 Agenda DFFE-CAP hvad er det? SOA hvad, hvorfra og hvorfor Enterprise arkitektur SOA Arkitektur / teknologi Opsamling

18 Enterprise arkitektur ( Top-down ) Erkendelser/principper Forretningsmæssige strategier driver kravene til ITløsninger og ikke teknologiske valg Enterprise arkitekturen er en iterativ (cyklisk) proces Kundens arkitekturprincipper udvikler og videreudvikler sig i takt med at forretningens behov ændrer sig

19 Enterprise arkitektur ( Top-down ) Aspekter Strategi: Forretningsmæssige strategi nu og fremover Processer: De arbejdsgange der skal understøttes af forretningen Information: Forretningens begreber og data Løsning: Strukturering og beskrivelse af løsninger Platform: Teknologiske IT-infrastruktur

20 Enterprise arkitektur ( Top-down ) Procesdiagrammer

21 Enterprise arkitektur ( Top-down ) Begrebsmodel

22 Enterprise arkitektur ( Top-down ) Use case diagram Håndter kunde Timer UC 5.43 Automatisk opdatering af kunde UC 5.42 Opret Kunde ( ) «uses» «uses» «uses» UC 5.7 Opret CVR kunde ( A) UC 5.8 Opret CPR kunde ( B) e-boks UC 5.4 Manuel opdatering af kunde ( A) UC 5.9 Opret anden kunde ( C) CVR Servicemedarbejder UC 5.3 Identificer «uses» kunde ( ) «uses» UC 5.2 Hent historik på Kunde CPR UC 5.5 Hent stamdata og engagement ( ) «uses» UC 5.10 Hent Engagement, brugerindstilinger ( B) «uses» Autorisationsudsteder Kunde UC 5.6 Registrer autorisation UC 5.11 Hent Engagement, Fuldmagter ( C) GLR Autorisationsmodtager UC 5.17 Anmod om autorisation UC 5.18 Accepter autorisation UC 5.13 Identificer via digital signatur «uses» UC 5.19 Slet autorisation UC 5.12 Fremsøg autorisation(2.2-3 A) UC 5.14 Anmod om oprettelse som kunde Sagsbehandler UC 5.15 Behandl anmodning om oprettelse som kunde «uses» UC 5.42 Opret Kunde ( ) UC 5.41 Opdater eboks markeringer Superbruger

23 Enterprise arkitektur ( Top-down ) Use Case beskrivelse

24 Enterprise Architecture top-down Proces diagram Service catalog Use Cases UseCase1 «uses» «uses» UseCase2 Copy link «uses» Actor1 Use Case description UseCase3 Update Actor2 Input High Level Business Type Model Input Input Input Xxx Xx Xxxx Xxx xxx Service description Input Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Input Input

25 Løsningsprodukter

26 Ementors læring Implementer en klar / solid EA governance model Vær meget klar på løsningsprodukterne Artefakterne (hvilke, hvor, hvordan) CM (Configuration Management) i centrum Værktøjer (QualiWare, TFS, Caliber osv.) Overvej omfang / brug af OIO

27 Agenda DFFE-CAP hvad er det? SOA hvad, hvorfra og hvorfor Enterprise arkitektur SOA Arkitektur / teknologi Opsamling

28 Serviceorienteret arkitektur skitse

29 ESB Bits bytes lego - dublo Ruleset Workflow for enduser Activity Process service Business service

30 TAS-CAP / 5.0 Business Services Generel Services Proces Services Activity Services Workflow Economy Customer User Template Scheme Subsidy Access Case Form CMS/Portal Control Risk Analysis Spot Test Subsidy Calculation Autovalidation Technology Services Output Output Message Support Services FSB Services Control Population CPR Currency Power of Attorny Parcel data CVR PID to CPR Other... GLR

31 SOA ESB implementering Præsentation IIS Kundeportal TAS 5.0 DFFE Intranet - Cockpit Work items Service Service agenter Smart Client Work items Service Service agenter MOSS Work items Service Service agenter WS (read) WS (update) WS (read) WS (update) WS (read) WS (update) Enterprise Service Bus Forretningsservice 1..n FSB Forretningslaget Datalaget.NET / WinWF ibatis.net OR/M Datamapper ADO.NET? Service facade (WCF / WS-*) Domain & Business logic (.NET) Service facade (WCF / WS-*) Service router (.NET) Service Agenter (.NET) Microsoft BizTalk 2006 R2 WS (synchronous) / binary serialization over tcp/ip WS (asynchronous) / binary serialization over tcp/ip SOAP WS / binary serialization over tcp/ip Enterprise Library Logging / Instrumentation WS / binary serialization over tcp/ip CVR CPR GLR e-boks KMD ESDH (Scan Jour) Eksterne datakilder Sikkerhed (AD, X.509, WS-Federation, STS Management SOAP / binary serialization over tcp/ip Database 1..n Oracle og/eller Microsoft SQL

32 Service operationer Servicedefinition består af: Adresse Binding Contract Tenet 1: Boundaries are Explicit Tenet 3: Services share Schema and Contract, not Class WSDL Web Service Definition Language Servicebeskrivelsen i maskinlæsbart format XSD XML Schema Definition Begrebsmodellen i maskinlæsbart format

33 WSDL - Web Service Definition Language Servicebeskrivelse

34 XSD - XML Schema Definition Begrebsmodel

35 Mange afhængigheder i udviklingsfasen Udfordring: Mange service = mange udviklere mange kontrakter (WSDL) Mange services kalder andre services Langt projektforløb ikke alle services er klar samtidigt Stor geografi / tidszoner DK og Indien

36 Mange afhængigheder i udviklingsfasen Løsning: Contract first development WSDL før kode Stubbing En service er ikke afhængig af andre services kun deres WSDL Service board Sikre versionering af kontrakter Godkender nye version af kontrakter Styre integrationstest

37 Ementors læring CM og Service board helt centrale processer ESB teknologier er emergerende Meget infrastruktur programmering STS, omkring BTS orkestrering og WinWF SOA management (livscyklus) tools er ikke klar

38 Connect strategi Gartner term Hvad gør man med standardramme/ gamle systemer? SAP, Axapta, Captia, mainframe osv. Service enabling vha. connect strategi data og velfungerende funktionalitet i eksisterende systemer, standardløsninger mv. så vidt muligt udnyttes adgang til disse systemer i form af services, så systemernes ressourcer kan genbruges til nye formål og i flere sammenhænge både internt og eksternt

39 Udfordringer med connect strategi Redundant data, f.eks.: Kunder Sager Brugere Transaktion styring i løst koblede systemer Regnskabslovgivning / revisionsspor Emergerende standarder WS-CAF (WS-Context, WS-Coordination Framework, WS- Transaction Management), samt WS-choreography og WS-orchestration

40 Spørgsmål?