1

Specificatii arhitectura informatica SOA, configurarea platformei ca serviciu

- Versiunea 1 -

2

Cuprins

1. Elaborare arhitectura informatica orientata pe servicii pentru optimizare middleware ................................................................................................................ 4

2. Concluzii .............................................................................................. 13

3

Suportul software pentru virtualizarea resurselor in medii distribuite pe scară largă,

sisteme de tip Cloud ne conduce la elaborarea unei arhitectura informatice orientata pe servicii (SOA) având ca obiectiv optimizarea middleware-ului existent în sistemele care vor suporta paradigma SaaS. Principalul avantaj la SOA este acela de a nu fi legată de o anumita tehnologie, ci defineşte un set de principii ce poate fi oricând, cu respectarea standardelor, implementat în diverse contexte. De exemplu, contextul de e-Learning presupune interacţiunea la distanţă între participanţilor la instruire prin intermediul propriilor dispozitive (calculatoare de tip desktop, sisteme de tip leptop, iPad sau chiar SmartPhone-uri) şi componenta care oferă accesul la informaţie (de cele mai multe ori un server expus printr-un serviciu web). Am prezentat în secţiunea a doua a acestui document principiile SOA şi modul în care se realizează optimizarea componentelor de middleware prin încărcare balansată şi prin suportul toleranţei la defecte.

Elaborarea sistemului de management al serviciilor presupune descrierea detaliată cereri utilizatorilor precum şi ciclu de viaţa al serviciilor expuse către utilizatori. Aşa cum se arată în secţiunea 3 a acestui document, Un sistem de management al serviciilor este bazat pe o schemă, un model de design unde un rol important îl joaca încapsularea ideii de aplicaţie în servicii care interacţionează printr-un protocol de comunicaţie comun. Am prezentat în această secţiune modalitatea de interacţiune între aplicaţiile de tip client ale utilizatorilor şi serviciile web prin descrierea componentelor care joacă un rol important în această interacţiune şi care se referă la descoperirea serviciilor, expunerea şi descrierea detaliată a serviciilor, orchestrarea şi coregrafia serviciilor. Ciclul de viaţă al serviciilor este prezentat ca suport pentru aceste tipuri de interacţiuni. De asemenea, este prezentat un mic ghid de instalare şi set-up al unui serviciu web folosind o soluţie open-source.

4

1. Elaborare arhitectura informatica orientata pe servicii pentru optimizare middleware

Tendinţele actuale în ceea ce priveşte modelul de organizare a resurselor computaţionale sunt de a folosi servicii pentru a pune la dispoziţie sau a procesa date; potenţiali consumatori pentru astfel de servicii pot fi end-user-ii sau alte servicii. Vorbim deci de o arhitectura orientata pe servicii (SOA) în cadrul căreia dorim să avem o infrastructura cât mai adecvata scopului sistemului.

Studiat şi analizat în literatura de specialitate sub diverse forme/pattern-uri (ex: Direct Connection, Service Gateway, Business Service Choreography), conceptul de ESB1 are implementări peste servere de aplicaţie cunoscute: WebSphereESB (WebSphere), OpenESB (Glassfish, Sun Application Server), JBossESB (JBoss). Implementările ESB oferă suport atât pentru încărcare balansata cât şi pentru toleranta la defecte, dar mai mult, deţine un set de capabilităţi care îl fac să fie un candidat solid pentru a satisface cu succes cerinţele unui sistem a cărui problematica a fost descrisa.

In literatura de specialitate termenul încărcare balansată (load balancing) este folosit cu interes de tehnica de împărţire a task-urilor intre doua sau mai multe entităţi (computere, aplicaţii, CPUs, HDDs sau alte resurse) în scopul de a obţine utilizarea optima a resurselor, maximizarea throughput-ului (productivitatea unei maşini sau a unui sistem calculata într-o unitate cu semnificaţie pentru contextul în care se utilizează: rezultate pe ora, număr de cereri procesate pe unitatea de timp etc.) şi minimizarea timpului de răspuns.

Utilizarea mai multor componente folosind încărcarea balansata în locul unei singure componente delegate cu responsabilitate de execuţie poate creste siguranţa accesării unei resurse (reliability) prin intermediul redundantei.

Încărcarea balansată este de obicei folosita pentru a media comunicaţia intre clustere de calculatoare, în special clustere cu accesibilitate ridicata (high-availability clusters). De cele mai multe ori serviciul de încărcare balansata poate fi oferit fie la nivel software prin intermediul unei aplicaţii dedicate (software dedicat), fie la nivel hardware, prin intermediul unui device (de ex: multilayer switch). Una dintre cele mai întâlnite modalităţi de a înzestra aplicaţiile cu încărcare balansata este punerea la dispoziţie a un serviciu internet existent pe mai multe servere - acest gen de aplicaţie apare în literatura de specialitate sub denumirea de server farm. Vom denumi şi folosi în continuare entitatea ce este delegata în cadrul unei aplicaţii cu responsabilitatea de realizare a încărcării balansate: LB (Load Balancer). Sistemele cu încărcare balansata pot fi specializate pe diverse domenii. Dintre cele mai populare amintim site-uri web, reţele de mesagerie, site-uri cu funcţii FTP, servere DNS. Daca ar fi să descriem modalitatea în care încărcarea balansata se materializează în cadrul serviciilor internet, iată cum ar putea fi imaginat acest lucru: LB este un program software

1 Enterprise Service Bus - http://www-01.ibm.com/software/integration/wsesb/about/

5

care asculta pe un port cereri de la clienţii externi care doresc să acceseze servicii puse la dispoziţie. LB trimite mai departe cererea către un server ce poate realiza sarcina ceruta, care la rândul lui, trimite răspunsul/rezultatul la LB. LB obţine rezultatul pe care îl prezintă clientului. Clientul primeşte rezultatul fără a cunoaşte mecanismul de separare interna a funcţiilor.

Acest mecanism împiedica clientul să cunoască serverele din spatele aplicaţiei, ce poate avea beneficii la nivel de securitate a aplicaţiei prin ascunderea structurii interne a reţelei, dar şi restricţionarea accesului la alte servicii ce rulează pe alte porturi ce nu au legătura cu aplicaţia pusa la dispoziţie; pentru aceste servicii accesarea de către anumiţi clienţi ar trebui restricţionata.

Uneori LB dispune de funcţionalitatea de a efectua o operaţie speciala când toate serverele din spatele aplicaţiei ce pun la dispoziţie un anumit serviciu sunt inaccesibile. LB poate delega cererea către un LB de backup sau să afişeze un mesaj cu detalii despre inaccesibilitate. O metoda alternative de a realiza încărcarea balansata care nu presupune existenta unui software dedicat sau a unui hardware cu funcţii speciale este round robin DNS. Prin folosirea acestei tehnici se asociază mai multe adrese IP aceluiaşi nume de domeniu (ex: www.exemplu.org – se asociază ip-urilor: 11.172.20.84, 11.172.20.83, 11.172.21.84). Clienţii au opţiunea de a alege serverul la care să se conecteze. Spre deosebire de folosirea unui LB dedicat, aceasta metoda nu este transparenta pentru clienţi deoarece expune serverele existente în spate aplicaţiei (aici numele de domeniu).

Aceasta modalitate de a asigura încărcarea balansata are avantaje şi dezavantaje funcţie de gradul de control peste serverele de DNS şi de granularitatea încărcării balansate aspect ce ar trebui luat în considerare. în decizia de a trimite o cerere către un server, LB se foloseşte de un algoritm de planificare care se poate utiliza sub forme variate, funcţie de factorii de care se vrea ca sistemul să tine cont. Unele sisteme abstractizează mult încărcarea neglijând aceşti factori tocmai pentru a simplifica algoritmul de alegere a resursei spre care să se îndrepte cererea. Astfel algoritmi ca round robin, first available sau random choice sunt consideraţi simpli. Algoritmii mai sofisticaţi iau în consideraţie factori adiţionali cum ar fi gradul de încărcare raportat de către fiecare server, ultimul timp de răspuns, up/down status (determinat de către o entitate care monitorizează resursele sistemului), numărul de conexiuni active, localizarea geografica, capabilităţile fiecărui server sau traficul înregistrat de server în cel mai recent interval de timp de lungime stabilita. Deci, termenul de “încărcare” poate fi rezultatul unor calcule mult mai complexe funcţie de factorii de care se doreşte a se tine cont în implementarea algoritmului de planificare a încărcării balansate. Echilibrarea încărcării este utila mai ales atunci când volumul de activitate nu este cunoscut înaintea începerii execuţiei. De asemenea, ea ajuta la diminuarea efectelor datorate diferenţelor de viteza dintre unităţile de execuţie, chiar şi atunci când volumul de activitate este cunoscut în avans.

Echilibrarea statica a încărcării poarta în general numele de problema mapării sau problema planificării (scheduling problem). Aceasta problem se dovedeşte a fie foarte complexa şi nu are o rezolvare unica. Putem intalii moduri diferite de echilibrare al încărcării funcţie de algoritm. Iată mai jos câteva exemple:

6

Fair Load Balancer este cel mai simplist dar şi cel mai corect. Acest mod va selecta fiecare unitate de execuţie care are pe moment cele mai puţine calcule planificate. Minusul major al acestei metode consta în faptul ca nu se ia în calcul starea unitarii de execuţie. Acest lucru rezulta într-o continua încercare de a selecta acea unitate de execuţie chiar şi daca acesta va reîntoarce datele planificate înapoi direct după aceea. Rezultatul final al acestui minus este ca daca un server nu este accesibil, performanta sistemului întreg va scădea foarte mult datorita încercărilor continue de a selecta acel server.

Round Robin Load Balancer a fost implementat în general pentru a fi utilizat în scopul echilibrării încărcării intre procesoarele locale. Este un mod complet inadecvat în echilibrarea serverelor.

Predictive Load Balancer oferă acelaşi grad de acurateţe ca şi Fair Load Balancer dar nu va lăsa serverele inaccesibile să scadă performanta întregului sistem. Acest lucru este realizat utilizând un sistem de “punctare” al fiecărei unităţi de execuţie care a cerut date. Desigur, exista un număr nelimitat de algoritmi ce pot fi utilizaţi în scopul echilibrării

încărcării. Însa aceste implementări sunt lăsate în latitudinea programatorului care doreşte să extragă maxim de performanta. Atât LB software cât şi cele hardware pot avea mai multe funcţii de care sistemul în care se integrează poate beneficia:

Asymmetric load: prin posibilitatea configurării manuale a coeficientului de încărcare la nivel de server se poate realiza o configuraţie a încărcării admise astfel încât unele servere să poată suporta o încărcare mai mare decât altele. Metoda des aplicata atunci când unele servere procesează date mai rapid decât altele – acestea vor putea accepta o încărcare mai mare. Viteza reprezentând un factor care cântăreşte semnificativ în ecuaţia încărcării;

Priority activation: când numărul serverelor funcţionale scade sub un anumit prag sau încărcarea pe oricare dintre serverele funcţionale depăşeşte un anumit prag, serverele inactive se vor activa;

SSL Offload and Acceleration: aplicaţiile ce folosesc SSL pot fi o adevărata povara pentru resursele unui server Web în special în ceea ce priveşte utilizarea CPU. în acest context and-user-ul poate sesiza un răspuns întârziat (ori serverul realizează seturi de procesări, altele pentru care a fost destinat să execute). în rezolvarea acestor probleme LB are trebui să deţină capabilităţi de realizare SSL Offloading implementate în hardware specializat. Când LB obţine conexiunea SSL, anumite operaţii SSL sunt realizate în hardware, deci mult mai rapid, iar performata nu se reduce fata de end-useri;

Distributed Denial of Service (DDoS) attack protection: LB poate pune la dispoziţie funcţionalităţi ca SYN cookies şi deply-binding (serverele nu pot vedea clienţii pana la

7

realizarea handshake-ului TCP) pentru a tempera atacurile SYN flood şi pentru a eficientiza platforma;

HTTP compression: reducerea volumului de date în transferul obiectelor HTTP prin utilizarea compresiei gzip la nivelul browserelor web;

TCP offload: fiecare cerere HTTP înregistrata de la acelaşi client este văzuta ca o noua conexiune TCP. Acesta facilitate presupune cumularea mai multor cereri HTTP de la mai mulţi clienţi pe un acelaşi soket TCP la server.

TCP buffering: LB poate păstra răspunsul cererii intr-un buffer urmând apoi să trimită el datele către clienţii lenţi, lăsând serverul care a răspuns să efectueze alte task-uri;

HTTP caching: LB poate stoca conţinut static ceea ce face posibila tratarea unor cereri fără a contacta serverul.

Content Filtering: unele LB-uri pot modifica aleatoriu traficul în locurile unde acţionează.

HTTP security: LB poate ascunde unele erori, elimina informaţiile din headerele HTTP despre identificare serverelor sau cripta cooki-urile pentru ca utilizatorii finali să nu le poată manipula;

Priority queuing (rate shaping): alocarea de priorităţi diferite pentru trafic diferit.

Content aware switching: LB poate retrimite cererea înregistrata la mai multe servere pe baza URL-ului către care s-a făcut cererea;

Client authentication: supunerea utilizatorului autentificării pe mai multe surse înainte de a-i da accesul la o anumita resursa.

Programmatic traffic manipulation: cel exista un LB care pune la dispoziţie un limbaj de scripting pentru suprascrierea metodelor de încărcare balansata.

Firewall: realizarea satisfacerii constrângerilor de acces ca operaţie anterioara rezolvării cererii de către server Din punct de vedere software, funcţie de cerinţele sistemului putem adăuga în

implementare din funcţiile mai sus menţionate. Toleranta la defecte reprezintă abilitatea sistemelor de a redirecţiona calculul computaţional către un alt server funcţional la căderea unui server din “cluster” (un grup de servere independente interconectate într-o reţea pentru a lucra ca o resursa centralizata de procesare a datelor), în mod cât mai transparent posibil pentru utilizator.

Vom folosi în continuare pentru procesul de redirecţionare a calcului computaţional de la serverul inaccesibil către alt server funcţional notaţia FO (failover). Un scenariu ideal de FO presupune existenta unui serviciu care să preia cererile de la clienţi, să identifice care dintre serverele cu funcţionalitatea dorita sunt inaccesibile şi care sunt accesibile şi să trimită cererea către un server disponibil la momentul cererii. Serverul delegat cu aceasta

8

responsabilitate verifica periodic daca o resursa este disponibila, şi daca răspunsul este afirmativ marchează serverul ca adăugat intr-un pool de servere accesibile considerate active şi de interes la un moment dat. Pentru a ne decide unde se va produce activitatea ce presupune toleranta la defecte (sau încărcarea balansata, având în vedere ca aceste doua concepte se afla într-o strânsa legătura) avem următoarele variante:

1. La unul din nodurile server; 2. La un server intermediar cu capabilităţi de FO/LB; 3. La nivelul aplicaţiei client.

Figură 1. Variante de identificare a locului unde se pot realizară activităţile de FO/LB

Fiecare dintre soluţiile expuse are un set de avantaje şi dezavantaje. Prima soluţie presupune ca fiecare dintre entităţile server să cunoască topologia sistemului. Fiecare entitate server ştie să acceseze oricare alta entitate server din sistem. Nu este o soluţie foarte buna daca numărul de entităţi server existente în sistem este foarte mare.

A doua varianta pune la dispoziţie o entitate care să medieze intre celelalte entităţi server din sistem care găzduiesc servicii. Orice cerere către un serviciul localizat pe o entitate server din sistem este procesata mai întâi de entitatea mediatoare care decide cărui server să trimită cererea. Entitatea mediatoare este singura care cunoaşte topologia sistemului. Entitatea mediatoare este punctul critic în accesarea resurselor din sistem. Entitatea mediatoare este în acest caz “single point of failure”. Accesibilitatea sistemului depinde de accesibilitatea entităţii mediatoare. Aceasta a doua varianta, rezolva problema ridicata pentru prima varianta, dar primeşte o nota proasta la capitolul accesibilitate sistem.

Ultima soluţie duce logica încărcării balansate la nivelul aplicaţiei client. Aplicaţia client poate fi un nivel de indirectare existent pentru nivelul serviciilor prezent – cu alte cuvinte poate fi o aplicaţie care să medieze alte aplicaţii. Unele dintre avantajele acestei soluţii este ca: elimina ‘single point of failure’ pentru ca nu exista nicio entitate mediatoare care să realizeze încărcarea balansata sau să se interpună în procesul de comunicare intre client şi

9

serverul care găzduieşte serviciul invocat de client; costul obţinerii încărcării balansate este minim: daca încărcarea balansata are loc la client nu mai exista overhead de sistem datorat altei entităţi mediatoare, iar clientul plăteşte toate costurile; Încărcarea balansata exista atâta timp cât aplicaţia client exista – dispariţia aplicaţiei client nu afectează cu nimic structura sistemului.

Totuşi acesta modalitate de realizare a încărcării balansata nu este o soluţie de integrare a unui sistem. Încărcarea balansata realizându-se la nivelul aplicaţie va fi foarte greu pentru a aplicaţie de mari dimensiuni să confrunte problema scalabilităţii. Iată un posibil scenariu de funcţionare LB (loadbalancer):

entitate proxy interceptează cereri de la clienţi.

Orice cerere este analizata de algoritmul de realizare a încărcării balansate şi se decide spre care nod spre care va fi trimisa cererea mai departe.

Daca invocarea nodului target se realizează cu succes (nu exista excepţii) răspunsul se va trimite clientul care a emis cererea către proxy.

Daca invocarea nodului eşuează entitatea proxy va analiza daca se poate trece transparent peste starea de excepţie. Un exemplu în care starea de excepţie poate fi recuperabila transparent este atunci

când nodul target devine inaccesibil. Entitatea proxy apelează din nou la algoritmul de încărcare balansata obţinând un alt nod spre care face invocarea. Entitatea proxy “ştie” ca poate să facă “silent failover” către un alt nod din sistem (“ştie” - în sensul ca are capabilitatea, este setata corespunzător). Nu exista riscul task-uri incomplete sau duplicate care ar trebui identificate, filtrate şi ignorate de aplicaţiile client.

Pe de alta parte, data interceptorul primeşte un alt tip de excepţie, cum ar fi excepţie la nivelul bazei de date existente pe maşina server, în acest caz nu poate face operaţia de “silent failover” către un alt nod din sistem. Va trimite excepţia mai departe către client. Clientul poate să îşi facă propriul business pentru tratarea unei astfel de excepţii. Interceptorul nu poate să rezolve generic altfel de excepţii.

Acest comportament este flexibil şi cât se poate de elocvent în majoritatea cazurilor. Evident daca nivelul de complexitate al sistemului creste, cazurile de utilizare devin şi ele mai pretenţioase. Încărcarea balansata se afla în strânsa corelaţie cu toleranta la defecte: orice cerere eşuata recepţionata de FO e urmata o invocare a LB, care decide care este următorul nod ce găzduieşte serviciul apelat de client. Totuşi, daca nu exista niciun nod disponibil care să servească o cerere atunci FO va răspunde clientului cu un mesaj relevat, anunţându-l de excepţia creata.

FO poate să funcţioneze după principiul “întotdeauna N instanţe disponibile”. Aceasta presupune regenerarea unei instanţe de serviciu pe unul din serverele disponibile, daca nu mai poate fi accesibila. La fel, daca nodul căzut îşi revine, o alta instanţa este aleasa să “moara”. Aceasta strategie poate fi costisitoare din punct de vedere al procesărilor adiţionale

10

pentru regenerare. Dar pe de alta parte asigura o accesibilitate relativ constanta în timp. Daca sistemul este alcătuit din numeroase noduri cu funcţii diferite (servicii diferite) atunci pentru a controla automat accesibilitatea sistemului se poate apela la aceasta tehnica. Altfel, readucere unui nod în sistem se va face cu intervenţia factorului uman.

Toleranta la defecte şi încărcarea balansata se afla în strânsa corelaţie. în cadrul realizării tolerantei la defecte, o deosebita atenţie se acorda modulelor de încărcare balansata. Aceste module expun un set de metode ce sunt apelate atunci când se doreşte selecţia următorului client ce va primi un set de date, sau când acel client va întoarce setul de date rezultat. Este important deci ca modulul de echilibrare să ia în considerare şi numărul de ori când un client nu a putut evalua setul de date de intrare.

Daca acel factor nu intra în decizia selecţiei următorului obiect e posibila o scădere dramatica al vitezei de calcul pentru ca datele vor fi într-o continua mişcare spre entitatea care nu răspunde şi de la el.

In acest scop, un algoritm Predictive Load Balancer este cel mai bine adaptat. Acesta foloseşte un sistem bazat pe puncte de penalizare:

La selecţia următorului nod, acestuia i se atribuie un punct de penalizare şi un punct de încărcare. Celorlalte noduri li se va scădea cate un punct de penalizare daca numărul acestora este mai mare ca 0;

Daca nodul raportează succesul operaţiunii de evaluare, lui i se va scădea un punct de încărcare. în cazul în care acesta are puncte de penalizare, i se vor scădea 2 puncte;

Daca nodul raportează eşecul operaţiunii de evaluare, i se va scădea un punct de încărcare şi se vor adăuga 3 puncte de penalizare;

Metoda de selecţie al următorului nod este simpla, şi anume: se va selecta acela care are suma puncte de încărcare + puncte de penalizare cea mai mica. SOA nu este legata de o anumita tehnologie, ci defineşte o serie de principii (Figură

2):

Figură 2. Principiile SOA

Daca ne oprim asupra interoperabilităţii (capacitatea unor aplicaţii de pe platforme

diferite de a interacţiona intr-un mod standard) putem spune ca este un aspect important în asigurarea comunicaţiei la nivel de business. Sistemele distribuite pot exista pe platforme diferite care se poate traduce în sisteme de operare diferite (Windows, Linux, Mac OS etc.), dar şi în medii de programare diferite (Java, .NET etc.).

11

Interoperabilitatea se poate prezenta sub diferite aspecte:

Application-to-Application (A2A)

Enterprise Application Integration (EAI)

Business-to-Business (B2B) ESB este unul din cele mai importante modele ale SOA. ESB unifica conceptele într-o

infrastructura. Conceptul de ESB a fost la început descris ca fiind "o noua arhitectura care exploatează serviciile Web, trimiţând mesaje, realizând o rutare inteligenta precum şi transformare" (Roy Schulte, Predicts 2003: Enterprise Services Buses Emerge, 2002). Începând cu anul 2002 (an al apariţiei publicaţiei anterior menţionate), ESB a devenit un subiect al dezbaterilor specialiştilor în SOA şi în servicii Web.

Figură 3. Componentele metodei SOA

Figură prezintă metoda SOA, precum şi componentele sale. Aceasta arata ca SOA se bazează pe existenta mai multor metode şi tehnici ce combina tehnologiile şi disciplinele serviciilor Web cu ESB.

In ideea implementării SOA, atât aplicaţiile cât şi infrastructura trebuie să suporte principiile SOA. Existenta aplicaţiilor presupune crearea interfeţelor de business pentru noi funcţii în mod direct sau prin intermediul unor adaptoare. Existenta infrastructurii la nivelul de baza presupune existenta clauzei capacitaţii de rutare şi transport a serviciilor cerute prin intermediul provider-ului corect. Rolul ESB este acela de a permite infrastructurii aceasta legătura. Adevărata valoare a ESB este de a permite accesarea infrastructurii pentru SOA, în scopul satisfacerii nevoilor actuale ale aplicaţiilor Enterprise - de a oferi servicii la diferite nivele, de a putea opera în diferite medii eterogene. ESB trebuie să fie capabil să substituie un serviciu de implementare cu altul fără a rezulta un efect negativ asupra clientului final.

12

Figură 4. Rezultatele implementării unui ESB

ESB nu este singura component care poate asigura infrastructura SOA. ESB este

principala entitate care asigura infrastructura, dar în jurul ei se pot situa şi alte componente ale căror rol este relativ la ESB. Astfel ESB poate fi asociat cu următoarele componente adiţionale:

Business Service Directory – pune la dispoziţia taxonomia şi detaliile despre serviciile disponibile în cadrul SOA;

Business Service Choreography – folosit pentru orchestrarea serviciilor în procese de business;

ESB Gateway – punct de control al accesului serviciilor externe când ESB nu poate realiza acest lucru. Organizaţiile de dimensiuni mari prefera a folosească. ESB Gateway ca o componenta separata. ESB Gateway poate fi folosit şi pentru a federaliza mai multe ESB-uri în cadrul unui Enterprise.

13

2. Concluzii

Pentru a obţine idealul de agilitate în medii ce colaborare electronică, cum ar fi cele de afaceri sau de instruire asistată de servicii electronice, este necesar ca infrastructura IT cu acces la funcţionalitate prin servicii să fie capabile de a fi configurate de către utilizatori fără să ca aceştia să devina experţi în domeniul respectiv. Produsele software moderne, care implementează arhitectura SOA, furnizează funcţionalitatea necesara instituţiei prin implementarea unei magistrale de tip ESB. Abordarea ESB este aceea de a transforma infrastructura robusta de mesagerie într-o platforma de dezvoltare a aplicaţiilor care interacţionează prin interfeţe de tip serviciu. Metoda de lucru si gestiune pe baza uneltelor conţinute în produsele software SOA/ESB transforma infrastructura IT, astfel incat poate fi utilizata atât de administratorii IT, de programatori cât şi de utilizatorii oameni de afaceri. Sunt de asemenea luate în considerare modalităţile de optimizare prin încărcare balansată şi suport la defecte.

Specialiştii considera ca un ESB poate realiza cu încredere integrarea aplicaţiilor (EIA) în condiţiile unui business cu dinamica şi flexibilitate sporită (agile business). O magistrala ESB eficienta furnizează mecanisme prin care utilizatorii pot manipula componente la nivel de business pentru a defini şi rula procese de business declanşate de evenimente (event driven arhitecture). Astfel se oferă răspuns în timp real schimbărilor de business apărute. ESB oferă o imagine de ansamblu a capabilităţii infrastructurii, implementate in centrul serviciilor în cadrul SOA. Odată cu căderea în dizgraţie a soluţiilor EAI, care nu satisfăceau cerinţele complexe apărute şi nu ofereau flexibilitate şi scalabilitate, ştafeta integrării IT a fost preluata, în ultimii 2-3 ani, de un alt concept care părea să revoluţioneze radical acest domeniu de graniţa: Enterprise Service Bus (ESB). Un studiu Forrester Research publicat în august 2004 evidenţia faptul ca 25% din companiile intervievate au renunţat la platformele EAI, optând pentru o soluţie ESB.