Service Orienteret Arkitektur Datalogisk Institut 22. november 2004 v/ Vidensleverandør Henrik Hvid Jensen, SOA Network henrikhvid@soanetwork.dk (c) SOA Network, 2004 1 Indførelse af et servicelag (c) SOA Network, 2004 3
Skifte i måden at betragte software-ressourcer på Traditionelt Funktionalitet til at understøtte er specifikt forretningsforhold Installeret det sted den skal bruges Virksomhedscentreret Forudsætter alle relevante teknologiske ressourcer placeret i samme virksomhed Store udfordringer når forbindelser skulle etableres Services Designet uden forudgående kendskab til deres brug Uafhængig af fysisk placering Fokuserer på interoperabilitet mellem heterogene it-miljøer Funktionalitet kan tilgås hvor og hvornår der er behov Specielt værdifuldt når teknologiske ressourcer skal forbindes på tværs af virksomheder (c) SOA Network, 2004 4 Definition af en service Indkapslede, løst koblede, genbrugelige softwarekomponenter, som semantisk veldefineret beskriver dets funktionalitet og opførsel, og som kan tilgås via programmer (c) SOA Network, 2004 5
Byens Taxi Store Taxi Hurtig Taxi SMS 0121: Get Taxi SMS Service Taxa Service Mobil A/S Virksomhed A/S Bank A/S (c) SOA Network, 2004 6 Dynamisk opdagelse Hurtig Taxi Sammensætning Byens Taxi Store Taxi SMS 0121: Get Taxi Mægling SMS Service Taxa Service Mobil A/S Betalingsservice Betalingsservice Virksomhed A/S Mellemled Bank A/S (c) SOA Network, 2004 7
Kernen i en serviceorienteret arkitektur (c) SOA Network, 2004 8 Roller og aktiviteter Roller: Serviceleverandør: Det system, der tilbyder servicen. Klient (Serviceforbruger): Systemet, der ønsker at finde og bruge servicen Servicemægler (Broker): Tilgængelig for alle parter, opbevaringssted for information omkring andre services. Aktiviteter: Offentliggør: Leverandøren sender information, der beskriver servicen til servicemægleren. Forespørg: Forespørger hos servicemægleren og modtager som svar en beskrivelse af servicen. Hvor man finder den, Hvordan man kommunikerer med den, og hvad kommunikationen skal indeholde. Forbind: Forbrugeren kontakter leverandøren og udfører den ønskede kommunikation. (c) SOA Network, 2004 9
SOAs fire primære søjler (c) SOA Network, 2004 10 SOA er distribueret Ingen krav om kendskab til placering Placeres hvor det er mest optimalt Lettere at mobilisere tilgængelige services Kræver ikke nyudvikling Forøge den innovative kapacitet Opnås gennem generelt tilgængeligt interface Web Services sikrer uafhængighed af Operativsystem, objektmodel, programmeringssprog, udvikling, platform, organisation osv. (c) SOA Network, 2004 11
SOAs fire primære søjler (c) SOA Network, 2004 12 SOA er løst koblet Den grad af afhængighed der er mellem komponenterne Undgå at kode faste forbindelser mellem to applikationer I dag er mange integrationsløsninger tæt koblede Kræver hensyntagen til det andet system Omkostninger i form af hastighed og udviklingsomkostninger Der eksisterer ikke et perfekt niveau af løs kobling Brug af Web Services standarderne giver ikke automatisk løs kobling (c) SOA Network, 2004 13
Løs kobling understøttes af Interfaces skal kunne udvides Sen binding Veldefinerede interfaces Asynkrone udvekslingsmønstre Grovkornede beskeder Leverandør- og platform-uafhængige beskeder (c) SOA Network, 2004 14 Interfaces skal kunne udvides Interfaces skal kunne udvides Sen binding Veldefinerede interfaces Asynkrone udvekslingsmønstre Grovkornede beskeder Leverandør- og platform uafhængige beskeder Nye versioner skal ikke kræve opdatering af alle klienter Undgå omfattende og kostbare opgraderinger Udvidelser (a) Fremad/bagud kompatible udvikling Inkompatible udvikling Web Services-standarderne er opbygget udvidelsesbart Web Services nedarver ikke automatisk disse aspekter Kræver versionsuafhængig udvikling (c) SOA Network, 2004 15
Udvikling af leverandør og forbruger Leverandør +1 Bagud kompatibilitet Forbruger +1 Leverandør Fremad kompatibilitet Forbruger Udvidelse: Muligheden for at andre end ophavsmanden kan tilføje elementer Versionering: Tilføjelse af komponenter under ophavsmandens kontrol. (c) SOA Network, 2004 16 Eksempel på organisation med versioneringsudfordringer Ligeledes skal det sikres, at ændringer i data dokumenteres, således at de historiske informationer er tilgængelig for eftertiden. For at leve op til denne forpligtigelse vil KMS opbygge et digitalt arkiv, hvor alle relevante arkivalier er tilgængelige. Kilde: Kort & Matrikelstyrelsens indsatsområder Data genbruges. It-arkitekturen skaber en ramme, således at teknologivalg, konkrete applikationer, dataformater, platforme, versioner mm. ikke udgør barrierer for genbrug af data mellem forskellige instanser og systemer. Ved ubesværet multianvendelse menes, at data let kan anvendes og genanvendes i alle sammenhænge, hvor det er relevant set fra brugerens synspunkt. KMS grænseflader understøtter dette (både de interne og eksterne i forbindelse med datamodtagelse og afsendelse). Kilde: Vision for it-arkitektur (c) SOA Network, 2004 17
Interfaces skal kunne udvides Sen binding Veldefinerede interfaces Tidlig binding kræver Asynkrone udvekslingsmønstre Grovkornede beskeder Leverandør- og platform uafhængige beskeder kendskab til alle APIer (c) SOA Network, 2004 18 Sen binding opnås gennem standardisering (c) SOA Network, 2004 19
Synkron kommunikation Interfaces skal kunne udvides Sen binding Veldefinerede interfaces Asynkrone udvekslingsmønstre Grovkornede beskeder Leverandør- og platform uafhængige beskeder (c) SOA Network, 2004 20 Asynkron kommunikation (c) SOA Network, 2004 21
Udfordringer ved asynkron kommunikation Udvikle eventdrevet Selvtilstrækkelige dokumenter Forståelsen skal også være løst koblet Udvikle dokumentorienteret (c) SOA Network, 2004 22 Messagingserver (c) SOA Network, 2004 23
Giver løsere kobling ved: Kommunikationen er asynkron Udføre andre aktiviteter Uafhængighed af øjeblikkelig tilgængelighed Applikationen er modulær Servicekvaliteten placeres i messagingserveren Uafhængig af modtagers platform Skal blot kunne sende beskeden til messagingserveren Applikationen skalerer godt Asynkron kommunikation kræver ikke øjeblikkelig svar Planlægning ud fra gennemsnitlig belastning Kompleksiteten placeres i messaginginfrastrukturen (c) SOA Network, 2004 24 Pålidelig beskedudveksling WS-Reliable Messaging Uafhængig af mellemliggende platform Sikrer at beskeder udveksles som forventet Sikrer fælles opfattelse af beskedernes status Eksempler på funktionalitet i en messagingserver Tillade, at beskeder bliver prioriteret. Levere beskeder, enten synkront eller asynkront. Garantere, at beskeder leveres én og kun én gang eller mindst én gang. Garantere, at beskeder leveres i den rigtige rækkefølge. Understøtte beskedbekræftelse. Angive antal gange, en besked skal forsøges sendt, før der opgives. (c) SOA Network, 2004 25
Interfaces skal kunne udvides Sen binding Veldefinerede interfaces Asynkrone udvekslingsmønstre Grovkornede beskeder Leverandør- og platform uafhængige beskeder Grovkornede beskeder (c) SOA Network, 2004 26 Betydningen af løs kobling Indkapsle applikation fra ændringer Ofrer optimeringen for at opnå fleksibilitet Målet er at forøge genbrugeligheden og tilpasningen til det uforudsete Væsentligste fordel Hurtigere tilpasning til nye ændringer Reducering af risici Billigere udvikling Understøttelse af forretningsinnovation Uafhængig systemudvikling En måde at designe på ikke en ny teknologi (c) SOA Network, 2004 27
SOAs fire primære søjler (c) SOA Network, 2004 28 Standarder Repræsenterer en aftale mellem forskellige virksomheder og organisationer om at implementere specifikke teknologier på en specifik måde Web Services- og SOA-forventningerne er under forudsætning af, at de rette standarder bliver udviklet og efterlevet. Selve eksistensen af integrationsproblemer skyldes en mangel på standardiseringer af applikationer og datainterface. Standarder eliminerer den semantiske kaos Det er kun gennem standarder, at virksomheder kan samarbejde mere effektivt, præcist og fleksibelt. De Facto standarder vil fremkomme Både horisontalt og vertikalt Drevet af markedslederne (c) SOA Network, 2004 29
Isoleret set er standarder uhensigtsmæssige Mange udviklere, der er vant til at optimere alt, vil kigge på XML og sige Jeg kan bygge noget, det er ikke helt XML, men det er en slags XML, og jeg er sikker på, at det vil være hurtigere og fylde mindre. Men det fungerer ikke i det lange løb. Til syvende og sidst er standarderne standarder, og de har en stor værdi på grund af det. Standarden Overlag Behov A Behov B Behov C Behov D Behov E Standard Standard Standard Standard Standard Behov (c) SOA Network, 2004 30 Implementer en bevidst standardstrategi Stor vækst i standarders betydning Fælles forståelse af interface Skal være bredt accepteret Standardstrategi Hovedreglen er at standarder skal efterleves 100% Undtagelser skal godkendes Sikre sig at alle standarder kan udvides Vælg åbne standarder Følg industristandarderne Undgå at lave egne standarder for noget der allerede eksisterer Også internt i organisationen Direkte eller indirekte deltagelse i industristandardgrupper (c) SOA Network, 2004 31
Standarder har en netværkseffekt Værdien af Web Services har en såkaldt netværkseffekt, hvilket betyder, at jo flere virksomheder, der bruger disse standarder til interaktion, jo mere værdi får hver virksomhed ud af dens Web Service-investering. (c) SOA Network, 2004 32 Resultatet af åbne standarder Leverandører må konkurrere inden for åbne standarder Et kundekrav Softwareudvikling ændres Funktioner kan leveres over nettet Leverandører af virksomhedssoftware vil udnytte kørselstidspunktintegrationen Ikke låst til en leverandør Standardisering af interfacet ikke kildekoden Web Service samarbejde med partnere bliver mere reglen end undtagelsen (c) SOA Network, 2004 33
SOAs fire primære søjler (c) SOA Network, 2004 34 Procescentreret perspektiv Byggeklodser der afspejler forretningsprocesser SOA betragtes som et forretningsprocesoperativsystem Udarbejder forretningsprocesser fra eksisterende byggeklodser Understøtter kortsigtede operative forretningsinitiativer Svarer til forretningens forståelse Letter kommunikation SOA er en samling af processer på et netværk der kommunikere med hinanden Skjuler tekniske implementering Fremkomst af en Bizmasterrolle (c) SOA Network, 2004 35
Roller (c) SOA Network, 2004 36 Der skal f.eks. opnås erfaring i: at identificere, hvilke funktionaliteter der skal udstilles, at opnå erfaring med at udtrække disse fra vidt forskellige systemer selve softwaren vil jo stadig ligge på heterogene systemer, som kræver forskellige udviklingsevner, at udvikle Web Servicens underliggende programkode, at opnå erfaring med at opbygge Web Services i den rette grovkornethed, at integrere Web Services, at gøre det hele på en sikker måde. (c) SOA Network, 2004 37
Fokus på standarder og forretningsprocesser Underliggende tekniske kompleksitet skjules Fysiske placering er uden betydning Adgang til alle tilgængelige ressourcer Interne såvel som eksterne Giver hele værdikæden adgang til distribueret information Understøtter netværksdata Beslutninger kan træffes på bedre grundlag (c) SOA Network, 2004 38 Opsummering (c) SOA Network, 2004 39
Serviceudviklere skal udvikle: Arkitekturen skal understøtte: Asynkront Baseret på hændelser Til messagingserver Til standarder Versionerbart Med hensyntagen til udvidelser Dokumentorienteret Selvtilstrækkelige dokumenter Grovkornet Ved processammensætning Beskedorienteret Løst koblet Fleksibelt Mod en mægler (c) SOA Network, 2004 40 Opsummering SOA betragter softwareressourcer som: Løst koblede Standardbaserede Services tilgængelig på et netværk Opbygge forretningsprocesser uafhængigt af implementationsplatform Trække mere værdi ud af it-ressourcer Implementeres gradvist for begrænsede initiale omkostninger I dag vil flertallet af services eksponere eksisterende ressourcer Genbrug og standardisering tillader én-til-mange fremfor én-til-én løsninger Kræver engagement, beslutninger og ekspertise (c) SOA Network, 2004 41
Spørgsmål? (c) SOA Network, 2004 42