ESB:n är död – leve ESB:n!

ESB-namnet myntades för några år sedan. Många gillade idén och ett antal leverantörer skapade ESB-plattformar. Inte sällan skapades de i mjukvarusviter där det kom att ingå en ganska bred funktionalitet. ESB-tanken tycktes passa bra ihop med SOA-principerna (Service Oriented Architecture) som redan fått ett uppsving.

Med SOAs populäritet kom en oro över hur man skulle kunna hålla ordning på alla systemsamband och tjänster som kommunicerade med varandra hit och dit. Man sa: SOA-spaghetti är också spaghetti och syftade på Gartners gamla problembegrepp inter-application spaghetti.

Ett sätt att hålla ordning vore förstås att kräva att all SOA-kommunikation skulle gå genom en ESB. I en ESB brukar det finnas meddelandestatistik och rättighetshantering till hjälp. Dessutom får man då tillgång till ESB:ns andra nyttigheter. Ett stort antal ESB:er infördes grundat på det här resonemanget.

De olika bussarna har varierande möjligheter, men de flesta mjukvarusviterna brukar klara asynkron köhantering, garanterad leverans, publicering/prenumrering, så snabb responstid att det duger för ”online”, formatkonvertering, tjänstekatalog, exekvering av affärslogik med mera. I praktiken har de lånat ganska många egenskaper från de äldre EAI-lösningarna (Enterprise Application Integration), men med större rapphet i meddelandeförmedlingen och med mer distribuerade driftsegenskaper.

Men så småningom uppenbarade sig en del nackdelar. Ofta hade man kanske inte nytta av ESB-svitens hela funktionsrepertoar utan det blev istället ett problem att behöva förstå en mängd inställningar och finesser som man ändå inte använder. Lösningarna kom också att bli ganska komplexa och kräver interna specialister (eller externa konsulter) som både har god utbildning och rejäl erfarenhet vad gäller vald ESB-produkt. Detta skapar både kostnader och personberoenden. En del införda ESB-lösningar har kommit att bli ledtidsflaskhalsar eftersom nya verksamhetskrav på vidareutveckling av SOA-kommunikationen ibland har fastnat på grund av tidsbrist hos dessa specialister.

ESB:er brukar vara distribuerade i sin grundkaraktär, det är då lätt att undvika att få någon driftsmässig single-point-of-failure. Däremot kan de riskera att bli en single-point-of-failure ur systemförvaltningssynpunkt. Om all SOA-kommunikation i hela företaget går genom ESB:n och någon råkar sätta en parameter fel i den så kan verksamheten närmast tvärstanna ifall organisationen är starkt IT-beroende.

Trots att det alltså finns en del nackdelar med ESB:er så är de ändå väl värda att satsa på, IFALL man verkligen har behov av deras breda funktionalitet, och inte bara behov av viss kontroll över meddelandeflödena.

För flera år sedan började man prata om SOA Governance. Till att börja med handlade det om formella riktlinjer, rutiner för att ta i saker i drift, förändringshantering, uppföljning av kontrakt för informationsutbytet och så vidare. Men snart började begreppet glida och idag har det ofta kommit att inkludera även driftsövervakning för SOA-meddelanden, automatisk kartläggning av vad som anropar vad, driftsstatistik samt i en del fall även rättighetshantering och tjänstekatalog. Med andra ord precis sådant som var det egentliga motivet bakom en mängd ESB-införanden för några år sedan.

Men numer finns det produkter för att i praktisk drift införa den här delen av SOA Governance! Ibland går produkterna under andra rubriker, som SOA Management eller till och med det lite konkretare, Web Services Management (WSM). De här produkterna är oftast mycket simplare än ESB:erna och har förstås heller inte lika många möjligheter. De är alltså lättare att konfigurera och lära sig. Men de tycks ha precis de finesser som behövs för att just få ordning och kontroll  – och för att undvika problem med SOA-spaghetti.

De verkar också enklare att installera. Vanligen handlar det om en liten, agentbaserad programvara som installeras i servermaskinerna. I en del fall behöver inte ens alla servrar som deltar i  SOA-utbytet få en installation, verktyget kan i alla fall leverera överblicksinformation.

En notering är att flera av verktygen har skapats av mindre och nystartade leverantörer. Många av bolagen har sedan köpt varandra eller blivit köpta av något stort företag. Med andra ord: bäst att utvärdera förväntad långsiktighet hos produkten.

Sammanfattningsvis: rubriken är förstås lite tillspetsad. Men ESB:n är nog död om behovet endast är övervakning och kontroll. Har man däremot en mer sammansatt behovsbild fortlever ESB:n vid full vigör. De nya produkterna för SOA Governance eller SOA Management är hur som helst definitivt värda att utvärdera som alternativ till ESB.

Sven-Håkan Olsson är en fristående konsult som särskilt arbetar med att kombinera verksamhetsnytta med teknikhöjd. Han har en lång karriär sedan 70-talet som it-konsult (it-arkitektur, systemdesign, programmering, reviewer, utredningar, kursledning). Sven-Håkan är också medgrundare av Know IT och var dess teknikchef 1990-2003. Han utsågs till en av "Sveriges topputvecklare" av Computer Sweden 2008.

Sven-Håkan håller regelbundet kurser åt Dataföreningen Kompetens, till exempel ”Cloud Computing integration och migration”. Läs gärna mer på hans blogg www.definitivus.se.

Sven-Håkan Olsson