Enterprise service bus(ESB) March 21, 2007 09:08 over 4 years ago
Hvad er en entreprise service bus og hvad skal en ESB gøre?
Heldigvis findes ingen konkret industri definition på en ESB. Nogle definere en ESB som værende en arkitektur komponent, andre definere ESB med udgangspunkt i hardware platforme og andre igen definere ESB som arkitektoniske mønstre.
ESB definitionen betyder forskellige ting for forskellige mennesker desværre.
Hvis man søger informationer om ESB gennem brochure, på web eller hos udbyder af løsninger får man endnu flere forskellige rettede oplysninger. Reklamerne er fulde af buswords som workflow, BPEL server og applikation extensions osv osv.
Svært at forstå hvad det i virkeligheden er og mange bruge masser af tid på at prøve at forstår Man kan vende det lidt på hoved og prøve at definere en bus udefra hvilken egenskaber den udfylder og hvad som skal erstatte den ifald den fjernes.
ESB er en implementering af SOX som er en eksekverings kontekst. Med andre ord, i SOA har vi en klient som er en forbruger af services og vi har en server som er en udbyder af services. ESB har til hoved opgave at forbinde de to på den mest simple måde, hurtigt og let. Ud fra et definitions standpunkt passer ESB’en perfekt.
Hvor kan man med fordel bruge en ESB og hvornår skal man ikke? Et godt eksempel er når der findes flere delte services på flere klient applikationer. Dette er et typisk SOA scenario hvor en ESB performere virkeligt godt. Et dårligt eksempel er en single silo applikation med få dedikeret services.
Skal man have et ESB produkt for at implementere en SOA applikation? Det er et trick spørgsmål. Nej. Der er tre ting man kan bruge i stede, en hardware plan, en software produkt eller man kan bruge et mønster men det som er pointen her er at når vi implementere SOA der er bestemte egenskaber som skal være til stede som fx ruting, besked udveksling, besked transformation, besked protokol, osv. Disse egenskaber skal være et sted i en SOA applikation og forhåbentlig er det ikke klientens ansvar, heller ikke sevices, og heller ikke middelware. Så svaret er stadig nej, men så må man selv implementere de egenskaber som en ESB løser.
ESB implementere ikke direkte en service orienteret arkitektur (SOA) men tilbyder svar på mange forskellige løsninger. Det er en fælles overbevisning at en ESB kun er til web services men der kan benyttes mange protokoller. ESB bør være standart baseret, fleksible og supportere mange transport media. Baseret på EAI frem for SOA mønstre prøver det at fjerne den tætte kobling mellem service kalder og selve transport medium.
Er der nogen ting som man kan undvære i en ESB? Hvis man kigger på en ESB som en arkitektur komponent ud fra et objekt orienteret synsvinkel er der klart egenskaber som procenterne smider med I pakken som ikke nødvendigvis tilhører en effektiv messing bus.
Analogi til Java sproget. Vi taler ikke mere om Java som sprog men mere som en platform. Vi inddrage en masse komponenter under det samme ord. Og sådan er det også med en ESB. En ESB som komponent bør hurtig, let og funger som middelware messing bus men vi begynder at fylde mere og mere adfærd på den, nogle gange er det nødvendigt og andre gange er det bare flof.
Ting som efter min mening ikke hører hjemme i en ESB er fx process choreography, services orchestration og meget andet gejl.
Måske mangler der en rå super hurtig beskeds bus som kan binde klienter og server samme.
By Frank Vilhelmsen - 2 tags: server soa - Add comment