Å rent faktisk implementere SOA er en ny øvelse, særlig hvis man snakker om en virkelig gjennomgripende tjenestearkitektur, og ikke bare det å være i gang med å etablere enkeltstående tjenester. Hvilke verktøy som vil være nyttige og nødvendige er derfor til dels ennå et diskusjonstema. Kanskje er dette også et område som tiltrekker verktøyleverandører med mer eller mindre akutt behov for å redefinere seg selv til noe annet enn det de holder på med i dag?

En del verktøy begynner imidlertid å få mange tilhengere og ganske entydige definisjoner, et av disse er den såkalte servicebussen, dvs en Enterprise Service Buss. En ESB altså. Som sagt er det ikke nødvendigvis enighet om nøyaktig hva en ESB skal omfatte, men her er ihvertfall en definisjon av hva en ESB skal bidra med:

• Ruting og formidling av tjenestekall
• Transformering og berikelse av meldinger
• Overvåkning og monitorering

En av de viktigste effektene av å ta i bruk slike mekanismer er å etablere en tjenesteproxy mellom tilbyder og konsument av tjenestene, dvs at tilbyder og konsument ikke snakker direkte med hverandre. Grunnen til at dette er bra er at det kan bidra til løsere sammenkobling i tjenestearkitekturen, noe som er sentralt for å oppnå den fleksibiliteten og endringsdyktigheten som SOA er ment å skulle gi.

Flere av disse egenskapene til en ESB er forøvrig godt kjent fra “hub-and-spoke” typen integrasjonsverktøy - mange av løftene om hva de skulle gi av fordeler var nok også de samme. For ikke alt for mange år siden ble det investert mye penger i denne typen verktøy (som f.eks SeeBeyond, WebMethods, Tibco), sannsynligvis uten at man oppnådde alt man ønsket. Systemene ble definitivt integrert med hverandre og dataene kom fra A til B, men over tid viste løsningene seg å være vanskelige og tidkrevende å endre på, samtidig som det var vanskelig å gjenbruke de integrasjonene som ble etablert.

Det kan selvfølgelig være mange grunner til dette, og den rent tekniske forskjellen på en ESB og et integrasjonsverktøy av denne typen kan også være rimelig subtile. En hovedårsak var imidlertid at man ikke fikk til løs kobling, dvs at integrasjonspunktene ble knyttet for tett til hverandre og det ble dermed vanskelig og kostbart å gjøre endringer.

Dette bringer oss fram til spørsmålet om SOA er en ESB. Svaret er egentlig nei - å etablere en SOA er (dessverre) langt mer komplisert enn å bare sette opp en ESB. Faren er at hovedfokus blir på å etablere alt som tjenester, noe en ESB forsåvidt kan hjelpe til med, men uten at man dermed oppnår det man egentlig ville med en tjenesteorientering. Jeg tror det er viktig at man holder fokus på at målet med SOA er økt fleksibilitet og endringsdyktighet. Løst koblede tjenester er middelet for å oppnå dette.

Når men jobber med SOA er det derfor viktig at man har et kontinuerlig fokus på hvordan oppnå fleksilitet og løs kobling, dette er nemlig ikke noe som kommer automatisk hverken av at man lager alt som tjenester eller om man bruker en ESB. Zapthink snakker til og med om sju nivåer av løs kobling “loose coupling”: http://www.zapthink.com/report.html?id=ZAPFLASH-20071128.

Tjenester og bruk av en ESB som et tjenesteproxy-lag i arkitekturen vil definitvt hjelpe deg på vei, men til slutt vil det være hvor godt tjenestene er utformet og hvordan de brukes som vil avgjøre graden av suksess. Regler for hvordan tjenestene skal utformes blir derfor viktig, dvs at man også må etablere en såkalt SOA Policy for å beskrive hvordan dette skal gjennomføres.
Og selv om det er vanskelig, så husk at suksess bør måles i hvor endringsdyktige man klarer å få IT-systemene til å bli og hvor stor grad av gjenbruk man klarer å oppnå, ikke i hvor mange tjenester man har etablert.

Det er også vel verdt å merke seg at bruken av en tjenesteproxy er et designpattern (dvs en god designide), og ikke noe som er uløselig knyttet til en ESB. Hvorvidt man velger å implementere dette pattern’et fra grunnen av selv eller kjøper inne en ESB, er en rent praktisk vurdering som bør gjøres ut fra hvilke krav man har, hvor mange tjenester det er snakk om og i hvilken grad man vil kunne nyttegjøre seg annen funksjonalitet (f.eks overvåkning og feilhåndtering) som kan finnes i en ESB.