Blogg

Här finns tekniska artiklar, presentationer och nyheter om arkitektur och systemutveckling. Håll dig uppdaterad, följ oss på LinkedIn

Callista medarbetare Johan Eltes

Visst behövs JBI!

// Johan Eltes

“Java Business Integration” är den flummiga uttolkningen av den kryptiska acronymen “JBI”. Jag lämnade Mark Hapners JBI-presentation på The Server Side Symposium 2004 med lätt yrsel. Jag själv och kollegan Håkan tog oss en djupare titt på JBI i samband med våra förberedelser inför Cadec 2005. Tyvärr fanns då inga representativa implementationer, men bilden av en ny, mer generell container-arkitektur började växa fram. En arkitektur som skulle låta oss plocka de pusselbitar som behövs för att lösa problemet. Skulle java-världen äntligen få se JavaEE-moniliten brytas upp - eller rent utav förpassas till avbytarbänken?

Riktigt tydligt tycker jag att JBI blev först när Sun släppte betan av Open ESB. Detta skedde inte förrän i Februari 2007 - knappt tre år efter de första presentationerna av JBI. Men varför tar det sådan tid? JBI syftar till att standardisera en Java-baserad runtime för olika former av integrationsteknologier, i syfte att möjliggöra en ESB sammansatt av komponenter från olika leverantören - baserad på en EJB-container som kan vara från ytterligare en leverantör. Det behöver väl alla? En IDOC-adapter från SAP, en mappningslösning från Informatica, BPEL-motor från Oracle, XSLT-kärna från BEA samt Connector-container och EJB3-container från IBM; allt körandes i en JBI-container från Red Hat. Dessutom helt baserad på en service-orienterad ansats för integration.

Tidens tand har nog varit en viktig ingrediens i att få Sun att våga se Java EE som en teknologi i mängden - i vart fall i det service-orienterade perspektivet. Standardiseringsarbetet kring Service Component Architecture har förmodligen också verkat hämmande på JBI. Dels för att IBM och BEA är två av de mest drivande bakom SCA, samtidigt som de ställs sig utanför JBI. Dels att SCA och JBI länge uppfattats som uteslutande - snarare än kompletterande - teknologier.

I mitt tycke är JBI en viktigare standard än SCA. SCA är visserligen produktivitetshöjande, men värdet av standardisering är mindre tydligt än för JBI. Principerna för SCA kan enkelt tillämpas inom Java-världen m.h.a. DI-ramverk som Spring åtföljt av guidelines och designprinciper. Blanda-och-ge med integrationsteknologier i en ESB kräver däremot en standard.

Det är därför glädjande att se den senaste tidens nyhetsflöde kring JBI:

  • Java ONE rapporterar om planer på JBI 2.0 med aggressiv tidplan och viktiga frågor i fokus (så som policys för QoS)
  • Sun släpper Beta 2 av Open ESB
  • Open ESB frikopplas från Glassfish (och Java EE) och blir därmed en egen, fullvärdig meta-container som står på egna ben
Tack för att du läser Callistas blogg.
Hjälp oss att nå ut med information genom att dela nyheter och artiklar i ditt nätverk.

Kommentarer