Konseptet Enterprise Service Bus (ESB) har de siste årene blitt et populært begrep i IT-industrien, og de fleste store produktleverandørene markedsfører et av produktene sine som en ESB. Men hva er ESB egentlig? Og hvilke egenskaper et produkt skal ha for at det skal kunne kalles en ESB?

Innledning

Begrepet ble for første gang brukt av Sonic Software i 2002. Siden den gang har ulike produkter fra ulike leverandører med mer eller mindre sammenfallende funksjonalitet blitt markedsført som ESB, og i dag er det stor forvirring rundt hva man egentlig får hvis man anskaffer en ESB.

Det finnes enda ingen standarder eller spesifikasjoner for en slik type mellomvare. Det nærmeste man kommer en standard er Java Business Integration (JBI), men JBI spesifiserer kun hvordan ulike integrasjonskomponenter skal kunne kobles sammen og kommunisere med hverandre. Spesifikasjonen sier ingenting om hva en ESB skal tilby av funksjonalitet. En illustrasjon på hvilke uenigheter og ulike oppfatninger som finnes rundt ESB-begrepet blant produktleverandører har vi her listet noen uttalelser og/eller standpunkter hentet fra noen av markedets største aktører:

• En ESB må baseres på meldingsbasert mellomvare (MOM) – Sonic
• En ESB bør ikke baseres på MOM, men støtte det – Cape Clear
• ESB samsvarer med "message broker" og "router pattern" – IBM
• BizTalk bruker "Hub and Spoke"-topologi - Microsoft
• "A message broker is often called Hub and Spoke" - Enterprise Integration Pattern - Gregor Hophe

Vi vil i denne artikkelen prøve å klargjøre noen av forskjellene mellom de ulike produktene som markedsføres som ESBer, og samtidig prøve å bidra til å forklare nærmere hva en ESB egentlig er. Vi vil først beskrive hva som er formålet med å innføre en ESB i en virksomhet. Vi vil deretter skissere hvilke ulike typer ESBer som finnes på markedet, ulike egenskaper disse har og hva som er fordelene og ulempene med de ulike designprinsippene som de ulike produktene er bygget på. Vi vil til slutt oppsummere de viktigste kravene som bør stilles til mellomvare som skal brukes i en tjenesteorientert arkitektur (SOA).

Virksomhetens behov

I store organisasjoner i dag har man et stort antall applikasjoner kjørende på ulike plattformer, teknologier, programmeringsspråk og versjoner. Disse små eller store siloene av enkeltapplikasjoner må kunne snakke sammen og utveksle data for å kunne støtte stadig større krav til forretningsprosessene. Disse utfordringene har ofte blitt løst ved tradisjonell Enterprise Application Integration (EAI), noe som lett skaper spaghetti-lignende strukturer i systemlandskapet og tette koblinger mellom ulike delsystemer. Applikasjoner som skal integreres låses til bestemte kommunikasjonsprotokoller og formater, og kommunikasjonen går direkte mellom de ulike delsystemene. Dette gjør det svært tidkrevende og kostbart å gjøre endringer.

Service-Oriented Architecture (SOA) er en lovende løsning på mange av disse problemene, og vi forutsetter her at leseren er mer eller mindre kjent med SOA-konseptet. SOA er en arkitekturtilnærming som støtter opp om tjenesteorientering. Tjenesteorientering går ut på at man eksponerer funksjonalitet fra applikasjoner som løst koblede tjenester i systemlandskapet. Disse tjenestene har granularitet på forretningsnivå og er definert med teknologiuavhengige kontrakter (XML).

For å kunne lage en skalerbar SOA i en stor virksomhet bør man benytte en mellomvare og et eget integrasjonslag for å knytte de ulike applikasjonene og tjenestene sammen. En ESB er en realisering av et slikt lag. En ESB tar seg av meldingsflyt, routing, orkestrering, pålitelighet og sikkerhet mellom tjenester og forbrukere av tjenestene. En ESB gjør tjenester i en SOA transparente og løst sammenkoblede ved å skjule fysisk lokasjon, kommunikasjonsprotokoll og implementasjonsdetaljer mellom tjenesteforbrukere og tjenestetilbydere. Ved å benytte en ESB unngår man blant annet at prosesslogikk på tvers av delsystemer blir hardkodet inn i enkeltapplikasjonene. Ved bruk av en ESB kan man heller konfigurere opp avhengigheter mellom systemer fremfor å programmere de inn i de ulike applikasjonene.

Man kan også oppnå isolasjon av tjenester; prinsippet at en tjeneste ikke skal vite om en annen tjeneste. Det er ofte ønskelig å utvikle en felles normalisert datamodell for virksomheten som ESBen bruker for å konvertere data fra enkeltapplikasjoner til en kanonisk form. Dette gjør tilgangen og utvekslingen av informasjon i virksomheten mer konsistent og helhetlig. Siden alle forbrukere av tjenester (både interne og eksterne) kommuniserer gjennom dette integrasjonslaget, vil det være enklere å monitorere og måle forretningsprosessene, avdekke avvik og håndtere feil.

[FIGUR HER]

Figur 1: Arkitektonisk oversikt over en ESB. Tjenesteforbrukere kaller tjenester og prosesser i ESBen som tilbys fra underliggende systemer gjennom ulike tilkoblingsmåter (adaptere).

Figur 1 skisserer hva slags plass og hvilken funksjon en ESB har i systemlandskapet til en virksomhet og i en tjenesteorientert arkitektur. Figuren viser en virksomhetsarkitektur som er typisk for en stor organisasjon. Et økende krav om brukerfokuserte og horisontale forretningsprosesser krever at flere av de eksisterende applikasjonene må kunne fungere sammen og utveksle informasjon, f.eks for å kunne presentere sammenstilt innhold i en portal (internett/intranett). ESBen bidrar til at alle underliggende applikasjoner kan eksponere tjenester som andre applikasjoner og klienter kan bruke og man kan oppnå en dypere grad av automatisering av prosesser i virksomheten. Man kapsler inn og abstraherer bort den teknologien som er brukt for å implementere de ulike tjenestene i de ulike applikasjonene. Slik kan man benytte tjenester uten å skape tette koblinger eller teknologiske avhengigheter mellom de ulike systemene.

For å oppsummere vil vi si at de viktigste formålene ved å innføre en ESB er følgende:

• Abstrahere bort applikasjonssiloene - tjenesteforbrukere trenger ikke å vite om systemtype og/eller lokasjon
• Unngå punkt-til-punkt integrasjon - ESBen reduserer antall koblinger i systemlandskapet ved å være et lag og aksesspunkt mellom tjenesteforbrukere og tjenestetilbydere
• Støtte for orkestrering av forretningsprosesser - orkestrering av tjenester ved hjelp av verktøy og modeller. Unngå hardkoding av prosesslogikk i de ulike applikasjonssiloene. Prosesslogikk spesifiseres eller implementeres i ESBen og abstraheres derfor vekk fra de ulike subsystemene.
• Unngå en 1-til-1 mapping mellom systemers API’er og tjenester - SOA er ikke det samme som å eksponere objektorienterte metoder som web services. Tjenester i en SOA er mer grovkornede forretningstjenester.
• Støtte for ulike kommunikasjonsmønstre og protokoller - ESBen kan f.eks. simulere synkronitet ovenfor en klient selv om underliggende tjenester er asynkrone. Tjenester kan tilbys og eksponeres via ulike typer kommunikasjonsprotokoller.
• Gi støtte for semantisk interoperabilitet - tilby verktøy for mapping og transformasjon av data
• Tilby ulike støttefunksjoner knyttet til sikkerhet, vedlikehold og overvåking.

Ulike produkter og designprinsipper

Mange ulike aktører kjemper om en fot innenfor ESB-markedet. De ulike selskapene har kommet frem til sin ESB-variant fra ulike utgangspunkt:

• Bygget på en eksisterende applikasjonsserver
• Bygget på en eksisterende meldingsbussinfrastruktur
• Bygget på et eksisterende Business Process Management (BPM) produkt
• Videreutvikling av en meldingsmegler (message broker)
• Bygget fra bunnen av

De ulike ESBene bygger på en del forskjellige designprinsipper. Vi vil her gå igjennom de viktigste designprinsippene og forklare forskjellene, fordelene og ulempene med disse teknikkene:

Sentralisert vs distribuert

En sentralisert ESB tar utgangspunkt i den velkjente "Hub-and-spoke"-arkitekturen som blant annet er kjent gjennom Microsoft sitt integrasjonsprodukt BizTalk. Denne arkitekturen kjennetegnes ved en sentral hub som applikasjoner henvender seg til for å utveksle data og kommunisere med andre applikasjoner igjennom.

Distribuerte eller såkalte forente (federated) ESBer bygger på en mer distribuert arkitektur der man kan produksjonssette ESB-instanser spredt utover på de nodene/applikasjonene i virksomheten som trenger slik funksjonalitet. Disse ESB-instansene kommuniserer så med hverandre på en Peer-to-Peer (P2P) lignende måte for å utføre ulike oppgaver, men fremstår som én logisk enhet for klientene av ESBen.

De fleste distribuerte ESBer tilbyr selektiv deployment av funksjonalitet. Dette betyr at man bare trenger å deploye nøyaktig den funksjonaliteten man trenger ved en node og ikke mer. F.eks. hvis et delsystem eller en applikasjon kun trenger en transformeringstjeneste for å bli integrert mot andre systemer, er det heller ikke nødvending å tilby mer funksjonalitet ved denne noden. Dette åpner opp for en mer inkrementell og lightweight tilnærming til integrasjon.

Distribuert prosessering skalerer i natur bedre og ved å unytte P2P-tankegangen utnytter man noder på kanten av nettet og unngår en sentral flaskehals og single-point-of-failure. En node vil f.eks. transformere dataene sine selv før de sendes videre til en annen node, istedenfor at all transformasjon skal skje sentralt. Derimot krever de distribuerte ESBene mer kompliserte administrasjons-, overvåknings- og delploymentmekanismer fordi det ikke er nok å oppdatere kode eller konfigurasjonsfiler på et sentralt sted.

Gitt at ikke alle distribuerte ESBer i markedet inkluderer en mekanisme for sentral lagring av konfigurasjon, kan det være tidkrevende å gjøre oppdateringer og vanskelig å sikre konsistens. Den distribuerte arkitekturen kan også føre til mer nettverkstrafikk grunnet kommunikasjon mellom de ulike ESB-instansene.

Meldingssentrert vs tjenestesentrert

En meldingssentrert ESB er bygget rundt en meldingsbuss og krever et slikt produkt for å fungere. All kommunikasjon må routes via en spesifikk meldingsbuss og man blir fort låst til en enkelt meldingsbussleverandør. Det er en fare for at funksjonaliteten i ESBen blir for tett knyttet til meldingsbussen og dens designprinsipper.

Noen brukere av slike ESBer har måttet utvikle sitt eget abstraksjonslag for å abstrahere seg fra den meldingsorienterte programmeringsmodellen. På den andre siden tilbyr meldingsbusser et pålitelig og asynkront kommunikasjonslag, og man kan få gjenbrukt tidligere investert programvare. Noen meldingssentrerte ESBer leveres med egenproduserte meldingsbusser, mens andre kommer med støtte for å koble på de mest kjente meldingsbussene på markedet.

Tjenestesentrerte ESBer er totalt transportagnostiske og har mer fokus på bruk av web services og WS-*-standardene. All funksjonalitet i ESBen er selv deployet som tjenester på lik linje med de forretningstjenestene som den tjenesteorienterte arkitekturen tilbyr. Dette betyr at all funksjonalitet kan benytte samme infrastruktur og ikke er delvis implementert gjennom meldingsprogramvare eller annen propretiær programvare.

Tjenestesentrerte ESBer kan bruke eksisterende meldingsprogramvare som underliggende kommunikasjonskanal hvis dette er ønskelig, men kommunikasjonen internt i ESBen foregår ikke via en meldingsbuss.

Routing, orkestrering og prosessmodellering

En ESB må ha en mekanisme for å definere og kjøre forretningsprosesser. Mye av merverdien i en SOA ligger i det å kunne abstrahere prosesslogikken opp i et eget lag i arkitekturen. De ulike ESBene på markedet har forskjellige tilnærminger til routing, orkestrering av tjenester og måten prosessmodellering gjøres. Et svært sentralt konsept ved de fleste distribuerte ESBene er en teknikk som blir kalt itinerary-basert routing (itinerary = reisebeskrivelse). Dette er en desentralisert og hendelsesorientert teknikk som gjør at man kan koble sammen tjenester fra ulike systemer og ESB-instanser til å utføre forretningsprosesser. Teknikken er meldingssentrert ved at en melding blir sett på som en reisende gjennom systemlandskapet. Meldingen følger en reisebeskrivelse som definerer hvilke tjenester som skal prosessere meldingen.

Disse tjenestene kan befinne seg på ulike ESB-instanser i nettverket. Reisebeskrivelsen til en melding konfigureres i XML og brukes av ESBen til å route meldingen til de riktige tjenestene. Itinerary-basert routing bygger altså på distribuert prosesshåndtering hvor man unngår å bruke en sentral prosesseringsenhet, noe som kan gi en god skalerbarhet og ytelse. Hovedproblemene med denne teknikken er mangelen på standarder (hver produsent har sin egen proprietære implementasjon og eget format), den krever et sentralt repository for å kunne brukes i praksis og at den kun støtter helt enkle sekvensielle prosesser. Itinerary-baserte prosessmodeller kan utvides med mer avansert kontrollflyt og routing ved hjelp av innholdsbaserte routing-mekanismer som f.eks. er basert på Xpath. Problemet er da at man må skrive mye kompliserende kode for å få spesifisert prosessene riktig. Det vil da ofte være mer fornuftig å ta i bruk et mer avansert, komplett og standardisert prosessmodelleringsspråk og orkestreringsverktøy.

Opp igjennom årene har det blitt introdusert en rekke ulike spesifikasjoner for prosessmodellering og arbeidsflyt (Rosetta, ebXML, BPML, BPMN, WSCI, osv...), men det ser nå ut som om standarden Business Process Execution Language (BPEL) blir stadig mer utbredt. I BPEL lager man forretningsprosesser i XML ved å definere flyt og hendelser mellom ulike web services. Det kan defineres svært avansert prosesslogikk ved å lage løkker, spesifisere transformasjoner, deklarere variabler og benytte feilhåndteringsmekanismer. BPEL har enda ikke modnet helt som standard og man må til tider spesifisere noe av logikken i prosessen ved hjelp av kode. I tillegg har leverandører av BPEL-programvare begynt å introdusere spesiallagde mekanismer som standarden ikke dekker. Dette fører til at ikke alle BPEL-modeller er 100% portable. De tjenestesentrerte ESBene har større vekt på BPEL som den beste teknikken for prosesshåndtering, enn hva de meldingssentrerte ESBene har.

Åpen kildekode, standardisering og proprietære løsninger

ESBer basert på åpen kildekode har åpenbare fordeler som følger med åpen kildekode som f.eks. det faktum at de er gratis å anskaffe, ofte har god og åpen support, man har innsikt i kildekoden og at man ofte kan finne mye god dokumentasjon på internett. Videre er store deler av disse ESBene basert på åpne standarder (som f.eks. JBI) og derfor ofte satt sammen av komponenter fra ulike leverandører. Dette kan gjør at man kan få produkter som er satt sammen slik at de er mer optimale og scenariotilpassede.

Det er også en fordel at man selv ganske enkelt kan utvide ESBen med egen kode eller andres produkter. Dessverre er mange av de disse ESBene noe umodne og passer derfor ennå best til bruk i forprosjekter og Proof-of-Concepts, noe de derimot er svært godt egnet til. Proprietære ESBer kan være mer komplekse og mer tidkrevende å lære seg. Mange av de kommersielle produktene er mer monolittiske og innvaderende applikasjoner som binder dine løsninger veldig tett opp i mot det aktuelle produktet. I den åpen kildekode baserte ESBen Mule kan man f.eks. skrive, deploye og eksponere en tjeneste som et Plain Old Java Object (POJO) noe som gjør tjenesten 100% portabel og gjenbrukbar på tvers av java-applikasjoner. Hvis ESBen i tillegg ikke er basert på noen standarder, er man nødt til å bruke alle komponenter fra en og samme leverandør. Noen av de kommersielle produktene har ikke tilgjengelig evalueringslisens og har mer eller mindre lukket tilgang til support og erfaringer.

I tillegg til ulikhetene nevnt ovenfor er det også stor forskjell på de ulike ESB-produktene i forhold til verktøystøtte. Man kan spare mye tid ved at produktene f.eks. har støtte for å modellere transformasjoner eller tilbyr gode prosessmodelleringsverktøy. De ulike produktene varierer også i forhold til støtte for grafisk brukergrensesnitt for overvåking, måling og produksjonssetting. Brukbarheten og effektiviteten til disse verktøyene varierer også betydelig.

SOA mellomvare - Egenskaper, krav og funksjonalitet

Som vi ser ovenfor har altså de ulike produktene svært ulike egenskaper og funksjonalitet. Hovedårsaken til forvirringen rundt ESB-konseptet er at mange produktleverandører tar et gammelt produkt og legger til litt ekstra funksjonalitet og kaller det hele for en ESB. ESB er mer et markedsføringsbegrep enn et produkt. Noen selskaper har bevisst latt vær å kalle produktet sitt for en ESB (f.eks Microsoft med BizTalk), men kan allikevel tilby store deler av den funksjonaliteten som andre leverandører tilbyr. Noen aktører i bransjen mener at ESB er mer et arkitektonisk mønster enn det er et produkt og at mellomvare ikke bør kjøpes inn, men må bygges selv for å oppnå langsiktig fleksibilitet.

Siden begrepet ESB er svært langt ifra å ha en entydig definisjon, mener vi det er mer hensiktsmessig å snakke om SOA Mellomvare (SOAM). Det er feil å ikke vurdere et produkt fordi det ikke markedsfører seg som en ESB. Hva slags mellomvare man trenger i et prosjekt eller i en virksomhet avhenger av svært mange faktorer og det er viktig at man tar i betraktning og vurderer alle typer av mellomvareløsninger som er tilgjengelig for en SOA. Det er også svært viktig å ta i betrakning hvor langt den aktuelle virksomheten har kommet i sin adopsjon og modenhet av SOA for å kunne vurdere hva slags funksjonalitet og krav som må stilles til SOAMen.

På grunnlag av vår erfaring med SOA, mellomvare og ulike ESB-produkter vil vi fremheve noen grunnleggende krav til en SOAM:

Routing - En SOAM må tilby mer avansert routingsfunksjonalitet enn vanlig meldingsprogramvare tilbyr. Innholdsbasert routing ved bruk av Xpath eller XQuery må være et minstekrav. Velger man en tjenestesentrert ESB er ikke kravet til routing lenger så viktig.

Transformasjons- og mappingsfunksjonalitet - Man må kunne transformere data fra et format til et annet. Man bør kunne benytte seg av en felles/kanonisk datamodell som alle applikasjoner som kobler seg til SOAMen oversetter til og fra. Bør som et minimum være støtte for Extensible Stylesheet Language Transformations (XSLT).

Konnektivitet - Ulike typer teknologier må kunne kobles til SOAMen ved bruk av ulike typer kommunikasjonsprotokoller. SOAMen må tilby konnektorer, adaptere og støtte for tredjepartsprodukter for å koble applikasjoner på SOAMen.

Grunnleggende støtte for web services - Tjenester må kunne eksponeres og forbrukes som web services på en enkel måte. Bør være støtte for WS-*-standarder.

Orkestrering og prosessorientering - Tjenester må kunne settes sammen til prosesser, orkestreres og eksponeres som kompositte tjenester. Dette bør være basert på standarder som BPEL.

Sikkerhet og overvåkning - En SOAM må tilby pluggbar funksjonalitet for autentisering, kryptering, tilgangskontroll, logging og overvåking. Sikkerhetsmekanismer og standarder som f.eks SOAP Digital Signature, LDAP, JAAS, JSSE,  SAML, WS-Security osv kan støttes. Eksekvering av prosesser og funksjonalitet bør kunne spores/måles og feil må automatisk kunne rapporteres.

Deployment, vedlikehold og administrasjon - Distribuerte SOAMer må ha en sentral administrativ enhet for blant annet lagring og distribusjon av konfigurasjonsfiler. Vedlikeholdsfunksjonalitet bør være basert på standarder som Simple Network Management Protocol (SNMP) eller Java Management Extension (JMX)

Konklusjon

ESB har blitt et viktig begrep i forbindelse med SOA, men ingen entydig definisjon finnes. ESB-produkter på markedet er forskjellige mht. funksjonalitet og oppbygging, og av den grunn den bør man benytte begrepet SOA Mellomvare (SOAM). Valg av en slik mellomvare bør ikke baseres på en merkelapp (ESB), men på en grundig evaluering av teknologi, funksjonalitet, oppgaver som skal løses, virksomhetens størrelse, kompleksitet i eksisterende virksomhetsarkitektur og plattformer og eventuelt pris. Gjennom en slik evaluering kan det godt hende man kommer frem til at virksomheten er best tjent med å lage sin egen mellomvare og integrasjonslag basert på åpne standarder og kjente design- og integrasjonsmønstre. På denne måten slipper man å betale for funksjonalitet man ikke trenger og får en løsning som i mange tilfeller kan være bedre tilpasset virksomhetens behov, men kostnadene knyttet til utviklingen av en slik løsning kan være meget høye. Når man skal gå til anskaffelse av en SOAM, må man også ta i betraktning hva slags SOA-strategi og SOA-modenhetsgrad virksomheten har for å vurdere behov som den tjenesteorienterte arkitekturen vil kunne få i fremtiden.

Referanser

SOA antipatterns - The obstacles to the adoption and successful realization of Service-Oriented Architecture - http://www-128.ibm.com/developerworks/webservices/library/ws-antipatterns/

Enterprise SOA : Service-Oriented Architecture Best Practices by by Dirk Krafzig, Karl Banke, Dirk Slama - Prentice Hall PTR. ISBN: 0131465759

Microsoft on the Enterprise Service Bus (ESB) -  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/BTS_2004WP/html/47850cbd-63ed-4370-a467-6bd320636902.asp

Service-Centric vs. Message-Centric ESBs - http://www.capeclear.com/download/whitepapers/The_Service_Centric_ESB.pdf

Patterns: Implementing an SOA using an Enterprise Service Bus – IBM Redbook. - http://www.redbooks.ibm.com/redbooks/pdfs/sg246346.pdf

Enterprise Service Bus by David Chappell - O'Reilly Media, Inc. ISBN: 0596006756

Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe, Bobby Woolf - Addison-Wesley Professional. ISBN: 0321200683

How BPEL and SOA Are Changing Web Services Development -  http://developer.capeclear.com/?q=bpelandsoa

ESB and BPEL: Changing the Rules of Integration -  http://developer.capeclear.com/?q=ESB_BPEL_Rules_Integration

Enterprise service buses hit the road - http://www.infoworld.com/article/05/07/22/30FEesb_1.html

Understanding Microsoft Integration Technologies - A Guide to Choosing a Solution - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bts_2004wp/html/14bc36a8-69a9-48ed-8e4c-1c85202544c0.asp

Understanding BizTalk Server 2004 – http://msdn.microsoft.com/library/default.asp?url=/library/en-us/BTS_2004WP/html/c245a8af-9f01-410f-b1bc-c43e725bfc27.asp