IT-bransjen er kjent for 3-bokstavers forkortelser som kommer og går. En av de nyeste som det nå blir snakket mye om fra mange aktører er SOA. Forkortelsene er svært aktuell, blant annet takket være styringsutfordringene i Forsvarets Golf-prosjekt. Det samme gjelder ambisjonene for Borgerportalen til moderniseringsminister Morten A. Meyer hvor det forventes elektroniske offentlige tjenester for alle fra offentlige etater til en lav pris.
Samhandling/integrasjon mellom ulike IT-systemer er en utfordring i alle større organisasjoner og øker etter hvert som man åpner seg opp mot partnere og kunder. I dag gjøres mye av denne sammenkoblingen på en kostbar og tidkrevende én-til-én måte.
Mange leverandører og kunder har lenge drømt om standarder for integrasjon og teknikker for å løse dette; komponenter, Corba og web services er eksempler på dette.
SOA er en tankegang som sammenfatter hvordan slike teknikker kan brukes for å gi en helhetlig modell for samhandling av systemer og skape nye tjenester.
Et godt eksempel på hva som kan oppnås med SOA, er det Amazon.com har gjort. De har eksponert de fleste av tjenestene sine som web services (SOAP) eller REST (en svært populær teknikk for systemkommunikasjon over web med XML). Resultatet har blitt en kjempeutvikling av nye tjenester fra andre aktører som aktivt bruker Amazons tjenester. For eksempel www.musicplasma.com, som viser et visuelt nettverk av musikkartister; hvor en selvsagt kan kjøpe musikken fra Amazon. Et annet eksempel er www.baconizer.com, som avdekker en interessekjede fra en gitt bok til en gitt film.
Som en av de få norske aktører, deltar konsulentselskapet Bekk i standardiseringsarbeidet knyttet til SOA. Her gir Lars Arne Skår, teknologidirektør i Bekk en forklaring:
I en SOA står dynamisk bruk av tjenester i sentrum. Tjenestene skal ha forretningsfokus og kunne settes sammen med andre tjenester til nye tjenester. En viktig forutsetning for at det skal fungere i praksis er at tjenestene tilbyr løse koplinger med minimale avhengigheter til IT infrastruktur. Selv om dette kan synes tilforlatelig og noe enhver god arkitekt bør fokusere på, er det sjelden dagens systemløsninger fungerer på den måten. Her er noen eksempler på vanlige problemstillinger:
- Bruk av tjenester som krever implisitt kjennskap til detaljer om hvordan tjenesten fungerer, hvor den er og overføring av data – dermed tett binding
- Komplekse avhengigheter mellom tilbyder og forbruker med hensyn på programvare og IT infrastruktur; Corba krever for eksempel at klient og tjener må ha programvare biblioteker på samme nivå
- Forbruker og tilbyder kan ha forskjellig oppfatning av data som overføres – semantisk ulikhet, noe som vil kreve tolking og transformering av disse data
- Sammensetning av tjenester blir ofte hardkodet i en ny tjeneste eller rutine, noe som gjør det vanskelig å gjenbruke flyten mellom tjenestene
- En organisasjon har ofte ulike initiativ avhengig av system eller produkt på hvordan et systems tjenester eksponeres – noe som skaper problemer når de skal brukes av andre
Programvare og de teknikker og metodikker som har vært benyttet til nå har ikke hatt fokus på tjenesteorientering, men prioritert å løse en gitt problemstilling, f.eks. kundestøtte, økonomistyring eller salg av produkter og tjenester. Teknikkene har i praksis hatt fokus på isolerte problemstillinger; mindre på hvordan systemer skal samhandle for effektivt å utveksle tjenester.
Tjenesteorientering er en naturlig videreutvikling fra objektorientert utvikling og komponentbasert tankegang hvor fokus denne gang er på eksponering av forretningsorienterte tjenester gjennom løse koplinger, slik at de dermed kan settes sammen til forretningsprosesser som igjen gjøres tilgjengelig for sluttbrukere. Følgende illustrasjon viser en måte å se dette på i en lagdelt fremstilling:
En slik tilnærming vil skape grunnlag for mer dynamisk bruk av tjenester, og dermed produkt- og tjenesteutvikling.
Bare se på strømnettet – noe så enkelt som å standardisere støpsel og plugg på det som tidligere var ment å være en erstatning for parafinlamper, har skapt en enorm produktutvikling. Før denne standardiseringen, måtte en tilkalle håndverkere med spesialkompetanse bare for å kople til elektrisk utstyr, i dag kjøper en og plugger det rett inn selv.
Et annet og ferskere eksempel, er telefoni, hvor en kan plugge inn en standard telefon til et IP-telefoni nett via en standard modulær telefonplugg. Det diskuteres om kvaliteten er den samme, men egenskapene ved tjenesten fungerer likt, selv om den er levert av andre på en annen protokoll.
Det er en slik utvikling vi håper tjenesteorientering vil føre til. At brukerne selv kan velge tjenester og hvordan de skal brukes uten å tilkalle spesialister hver gang en ny tjeneste kommer.
Programvareselskapene har den siste tiden aktivt posisjonert sine produkter og teknologier for å understøtte SOA. Microsoft er særdeles aktiv rundt sin Web Services satsning og vil støtte SOA ved å integrere gjeldende og kommende Web Services standarder i sine utviklingsverktøy.
IBM jobber aktivt både med Web Services og andre integrasjonsteknologier samt oppkjøp av komplementære programvareprodukter. Websphere Business Integrator som nå inkluderer Holosofx for modellering av flyt mellom tjenester er et aktuelt eksempel på dette.
BEA hevder hele sin plattform er SOA, men mener i praksis at de vil støtte gjeldende standarder i sine produkter. Blant annet vil de gå over fra Java Process Definition Language (JPD) til Business Process Language (BPEL) som er en XML-basert standard med svært bred støtte for å støtte definisjon av flyt mellom tjenester. Novell leverer SOA-spesifikke konsulenttjenester og programvare.
BEKK engasjerer seg sterkt i SOA for å understøtte den utviklingen som nå skjer. Utbredelsen er fortsatt liten, definisjonene utarbeides og tolkes i disse dager, men mulighetene SOA åpner for, og hva det vil kreve av vår bransje er såpass omfattende, at vi mener det er nødvendig å støtte en slik utvikling.
I fjor var vi representert i en arbeidsgruppe på OOPSLA sammen med 8 selskaper og forskergrupper fra hele verden med fokus på beste praksiser og metodikk knyttet til SOA. Her utarbeidet vi blant annet en omforent definisjon av SOA, hvor ambisjonen har vært å trekke frem det essensielle i en SOA:
"A SOA is an enterprise-scale IT architecture for linking resources on demand where the primary structuring element for applications is a service. These resources are represented as business aligned services which can participate and be composed in a value net, enterprise or line of business to fulfil business needs"
Referanser på SOA:
