Service Orienteret Arkitektur en succes, der i stigende grad kræver IT Governance fokus 4. oktober 2006 C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y
DEVOTEAM i Danmark og i Europa 2 Devoteam Consulting grundlagt i 1978. Uafhængige af leverandørinteresser Devoteam Group: 2400 medarbejdere i 15 europæiske lande og i Mellemøsten 100 medarbejdere i Danmark Omsætning 1,5 Mia DKK i 2005 Bredt spekter af kunder: Bank, forsikring, pension Telekommunikation Handel og industri Energi Centraladministrationer Amter Kommuner
Emner 3 Kort definition af SOA principper (Gartner mv.) Ikke kun en teknisk integration Sikkerhedsmodel De vigtigste erfaringer Anbefalinger
Kort definition af SOA baseret på de seks principper (jfr. Gartner) Princip #1: - En service er en komplet forretningsfunktion, som stilles til rådighed for andre forretningsfunktioner og processer. Princip #2: - Løs kobling mellem serviceudbyder og servicekonsument. Services skal være karakteriserede ved lav kobling mellem servicekonsumenten og serviceudbyderen. Services skal udvikles som generiske services. Når services designes, må den ikke designes med baggrund i en bestemt servicekonsuments behov Princip #3: - En service skal være en black box : En service består af et service interface og en service implementering. Det essentielle i en service orienteret arkitektur er relationen mellem service interfaces. Princip #4: - Services skal være lokationstransparente. Det skal være muligt at tilgå services uafhængigt af, hvor servicekonsumenten befinder sig. Det betyder bl.a. også, at sikkerhedsmodellen ikke må bygge på, at servicekonsumenten befinder sig på et bestemt netværk. Princip #5: - Serviceimplementeringer bør være protokoluafhængige. Det skal tilstræbes, at implementeringen af serviceudbyderen og servicekonsumenten kan foregå uafhængige af hinanden og interaktion kun er formidlet via standard protokoller. Princip #6: - Services bør kunne udvikles uafhængigt af servicekonsumenten. Dette princip er en præcisering af princippet om lav kobling. En service bør kun videreudvikles, hvis det ikke kræver, at servicekonsumenten tilpasser sit system, når en ny version af servicen tilbydes. Servicekonsumenten bør have mulighed for at køre videre med den oprindelige service. 4
Forudsætter uafhængig infrastruktur og sikkerhedsløsning 5 Service konsumenter Praktiserende læge Hjemmepleje Sygehus Apotek Brugerstyring Katalog Portal/billetudsteder Infrastruktur Patientforløb sservice (WF-service) Service udbydere
Hidtil ofte kun teknisk integration (=SOAP protokol) Teknisk integration med SOAP alene er ikke SOA De hidtidige WS-løsninger har primært været rent teknisk integration - Manglende fælles logisk datamodel (MIM: Message Information Model) - Servicebeskrivelser ikke uafhængig af intern implementering - Punkt-til-punkt integration nødvendig - Ad-hoc sikkerhedsløsninger Service udbyder Snitflade Konsu ment type A Konsu ment type B Kun protokol er standardiseret (SOAP) Ofte autogenereret WS Ikke semantisk standardisering OIOXML ikke overholdt Sektorstandardisering ikke gennemført Punkt-til-punkt sikkerhedsløsning 6
Sammenhængende sikkerhedsløsning nødvendig 7 Single sign-on, det vil sige, at man som bruger af systemerne anvender samme identitet og samme kode for at få adgang til flere services Federated identity, hvor det er muligt at skabe sikkerhed for autenticitet, fortrolighed, integritet og uafviselighed i en åben infrastruktur mellem mange forskellige systemer både indenfor og udenfor en given virksomhed Med Federated identity vil en bruger, der logger på myndighedens systemer, uden fornyet logon f.eks. kunne tilgå systemer og informationer hos andre myndigheder/ virksomheder. Autenticitet, fortrolig, integritet og uafviselighed vil kunne sikres i det samlede informations forløb end-to-end De store leverandører (IBM, Microsoft o.a.) samt de betydelige interesseorganisationer (Organization for the Advancement of structured information standards (OASIS), World Wide Web Consortium (W3C), Liberty Alliance o.a.) udvikler p.t. standarder og produkter for IT-sikkerhed beregnet til at indgå i åbne service orienterede arkitekturer. Web Services-Security (WS-Security) og Security Assertions Markup Language (SAML) er de 2 væsentligste standarder som organisationer og leverandører samles om for definition af sikkerhedsservices. Begge standarder er XML baseret.
Fælles sikkerhedsmodel med billetter Billet udsteder 8 Kunde Kunde Kommune Rådgiver Rådgiver Jeg er Niels og er kunde i Nykredit Portal Billet kontrol SAML WS-security Billet kontrol System A System B System C System D System E Billet kontrol
Billetter 9 En særlig værdi, brug af billetter har, er muligheden for via autorisations- og attributbilletter at styre, hvilke autorisationer (eller rolle) en given bruger har i forskellige situationer. - F.eks. kan billetten indikere, at der i nogle situationer er adgang til et helt register og i andre kun til måske en enkelt record. - Et eksempel kunne være en ansats adgang til kundekonti som ansat eller som kunde Specielt vil en national standardisering af SAML specifikationer have stor betydning for den interoperabilitet, der kan opnås mellem systemer og services indenfor den offentlige sektor og i samspil med den private sektor!! SAML = Billetter WS-Security = Understøtter bl.a. transport af billetter + fortrolighed
De vigtigste erfaringer ved SOA implementering 10 Den forretningsmæssige Snitflade mellem udbyder og konsument skal fastlægges, helst før den tekniske integration - Sektorstandardisering nødvendig - OIOXML skal fastlægges på forhånd - Nødvendig med fælles logisk udvekslingsdatamodel (MIM) for servicen Sikkerhedsproblemstillingerne (bl.a. erfaringer fra SOSI) - Federated itentity management, med billetudsteder, er en forudsætning - Standarder er ved at være på plads, men erfaringer er meget få Autogenerering som leverandører ofte anvender er gift for SOA. - Gør det ikke muligt at definere en neutral snitflade som flere parter kan anvende. - Sektorstandardisering/OIOXML undermineres Asynkron kommunikation er en udfordring - Data er forældet det øjeblik de overføres - Specielle udfordringer mht. dataintegritet (opdatering af data kun via én service) Servicekatalog og publicering af service beskrivelser - Kun få realiseringer Få erfaringer med kravspecifikationsarbejde i SOA miljøer - Devoteams SOA Toolbox et godt udgangspunkt
Yderligere erfaringer 11 Governance/styring forankring på tværs af aktører er meget vigtig - SLA/OLA aftaler - Organisering roller/ansvar - Beslutningsstrukturer - SOA Principper - SOA arkitektur - Release styring - Test - Dokumentation - Forretningsforankring Succeser omkring Web Service anvendelse - Medicinprofilen - SKAT - Sundhed.dk - Virk.dk -. men efter Devoteams vurdering ikke ægte SOA løsninger (endnu)
Vigtigste beslutninger i SOA (1) 12 SOA principper - Principper for fælles applikationsservices og fælles informationsmodel herunder sikkerhed, overvågning og finansiering - Principper for XML Schema udvikling herunder namespace opbygning, domain struktur og versionering SOA arkitektur - Beslutning om konkret SOA arkitektur inkl. Service Register - Beslutning om konkret SOA systems management arkitektur inkl. sikkerhed, deployment og overvågning SOA infrastruktur - SOA middleware inkl. Service register - Systems Management Software til håndtering af SOA (overvågning, deployment, svartider, håndtering af SLA's) Hvem giver input til disse beslutninger? Hvem tager disse beslutninger?
Vigtigste beslutninger i SOA (2) 13 SOA anvendelse i forretningsapplikationer - Definition af nye namespace domains i informations model - Fastlægge ejerskab af XML Schemaer - Fastlægge sikkerheds krav til en applikations service - Fastlægge transaktions krav (Atomic transaction eller compensating transaction) til en applikations service - Definere en applikations service som en fælles service - Ny version af Applikations Service - Ny version af XML Schema - Definere Service Level Agreement for applikations services SOA investeringer - Betaling for udvikling af fælles applikationsservices - Økonomisk ramme for SOA infrastruktur investeringer Hvem giver input til disse beslutninger? Hvem tager disse beslutninger?
SOA Governance 14 Styringen af virksomhedens SOA skal sikre at man ved: Hvad der sker når en service ændres? Hvordan man kan være sikker på at den service man anvender har en høj kvalitet? Hvad der sker, hvis en delkomponent af en sammensat service tages ud? Hvordan man kan være sikker på at en ny service overholder it-, forretnings- og lov-krav? Hvordan man sikre en forudsigelig oppetid på en service? Dette kræver at virksomheden indarbejder en tilstrækkelig governance-infrastruktur, der ikke sætter behændigheden og fleksibiliteten over styr. Behændighed kan man opnå ved at anvende metadata i tilknytning til SOA. Disse skal gemmes i et metadata bibliotek, der kan anvendes i samspil med et service register(uddi). Man kan tale om et UDDI plus.
Anbefalinger 15 Involver forretningsorganisation og involverede aktører i design og specifikation Opbyg beslutningsstrukturer omkring SOA Klart ejerskab omkring SOA elementer vigtigt Frigør kravspecifikationsarbejdet for tekniske krav Bliv på forhånd enig om en logisk udvekslingsdatamodel Undgå autogenerering af skemaer Stram release styring på snitflade (WSDL, XML, SLA mv.) Kommuniker og involver (ikke en udviklingsøvelse alene) Audit og konsekvens ved afvigelser Få sikkerhedsmodellen på plads tidligt (inkl. afprøvning og implementering) Indfør unit test af services
Kontakt 16 BELGIEN DANMARK DEN TJEKKISKE REPUBLIK Kontakt Person: Per Foldager FORENEDE ARABISKE EMIRATER Telefon: +45 2271 2818 FRANKRIG HOLLAND MAROKKO NORGE POLEN SAUDIARABIEN SCHWEIZ E-mail: Adresse: Dokument per.foldager@devoteam.dk Devoteam Consulting A/S Tuborg Parkvej 10 2900 Hellerup + 45 3945 0700 www.devoteam.dk SPANIEN STORBRITANNIEN SVERIGE ØSTRIG ID: #37821 Forfatter: Herbert Jessen & Per Foldager Dato: 09-10-2006 Devoteam Consulting A/S Kopiering og distribution kun tilladt efter aftale med Devoteam Consulting.