Specificatii arhitectura informatica SOA, configurarea

platformei ca serviciu
-

Versiunea 1

Cuprins

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

Concluzii .............................................................................................. 13

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) avnd 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 definete un set de principii ce poate fi oricnd, cu respectarea
standardelor, implementat n diverse contexte. De exemplu, contextul de e-Learning
presupune interaciunea la distan ntre participanilor la instruire prin intermediul propriilor
dispozitive (calculatoare de tip desktop, sisteme de tip leptop, iPad sau chiar SmartPhoneuri) i componenta care ofer accesul la informaie (de cele mai multe ori un server expus
printr-un serviciu web). Am prezentat n seciunea a doua a acestui document principiile SOA
i modul n care se realizeaz optimizarea componentelor de middleware prin ncrcare
balansat i prin suportul toleranei la defecte.
Elaborarea sistemului de management al serviciilor presupune descrierea detaliat
cereri utilizatorilor precum i ciclu de viaa al serviciilor expuse ctre utilizatori. Aa cum se
arat n seciunea 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
aplicaie n servicii care interacioneaz printr-un protocol de comunicaie comun. Am
prezentat n aceast seciune modalitatea de interaciune ntre aplicaiile de tip client ale
utilizatorilor i serviciile web prin descrierea componentelor care joac un rol important n
aceast interaciune 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 interaciuni. De asemenea, este prezentat un mic
ghid de instalare i set-up al unui serviciu web folosind o soluie open-source.

1. Elaborare arhitectura informatica orientata pe servicii pentru optimizare

middleware
Tendinele actuale n ceea ce privete modelul de organizare a resurselor
computaionale sunt de a folosi servicii pentru a pune la dispoziie sau a procesa date;
poteniali consumatori pentru astfel de servicii pot fi end-user-ii sau alte servicii. Vorbim deci
de o arhitectura orientata pe servicii (SOA) n cadrul creia dorim s avem o infrastructura
ct 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
implementri peste servere de aplicaie cunoscute: WebSphereESB (WebSphere), OpenESB
(Glassfish, Sun Application Server), JBossESB (JBoss). Implementrile ESB ofer suport
att pentru ncrcare balansata ct i pentru toleranta la defecte, dar mai mult, deine un set
de capabiliti care l fac s fie un candidat solid pentru a satisface cu succes cerinele unui
sistem a crui problematica a fost descrisa.
In literatura de specialitate termenul ncrcare balansat (load balancing) este folosit
cu interes de tehnica de mprire a task-urilor intre doua sau mai multe entiti (computere,
aplicaii, CPUs, HDDs sau alte resurse) n scopul de a obine utilizarea optima a resurselor,
maximizarea throughput-ului (productivitatea unei maini sau a unui sistem calculata ntr-o
unitate cu semnificaie pentru contextul n care se utilizeaz: rezultate pe ora, numr de
cereri procesate pe unitatea de timp etc.) i minimizarea timpului de rspuns.
Utilizarea mai multor componente folosind ncrcarea balansata n locul unei singure
componente delegate cu responsabilitate de execuie poate creste sigurana accesrii unei
resurse (reliability) prin intermediul redundantei.
ncrcarea balansat este de obicei folosita pentru a media comunicaia intre clustere
de calculatoare, n special clustere cu accesibilitate ridicata (high-availability clusters). De
cele mai multe ori serviciul de ncrcare balansata poate fi oferit fie la nivel software prin
intermediul unei aplicaii dedicate (software dedicat), fie la nivel hardware, prin intermediul
unui device (de ex: multilayer switch). Una dintre cele mai ntlnite modaliti de a nzestra
aplicaiile cu ncrcare balansata este punerea la dispoziie a un serviciu internet existent pe
mai multe servere - acest gen de aplicaie apare n literatura de specialitate sub denumirea
de server farm. Vom denumi i folosi n continuare entitatea ce este delegata n cadrul unei
aplicaii cu responsabilitatea de realizare a ncrcrii balansate: LB (Load Balancer).
Sistemele cu ncrcare balansata pot fi specializate pe diverse domenii. Dintre cele mai
populare amintim site-uri web, reele de mesagerie, site-uri cu funcii FTP, servere DNS.
Daca ar fi s descriem modalitatea n care ncrcarea 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/

care asculta pe un port cereri de la clienii externi care doresc s acceseze servicii puse la
dispoziie. LB trimite mai departe cererea ctre un server ce poate realiza sarcina ceruta,
care la rndul lui, trimite rspunsul/rezultatul la LB. LB obine rezultatul pe care l prezint
clientului. Clientul primete rezultatul fr a cunoate mecanismul de separare interna a
funciilor.
Acest mecanism mpiedica clientul s cunoasc serverele din spatele aplicaiei, ce
poate avea beneficii la nivel de securitate a aplicaiei prin ascunderea structurii interne a
reelei, dar i restricionarea accesului la alte servicii ce ruleaz pe alte porturi ce nu au
legtura cu aplicaia pusa la dispoziie; pentru aceste servicii accesarea de ctre anumii
clieni ar trebui restricionata.
Uneori LB dispune de funcionalitatea de a efectua o operaie speciala cnd toate
serverele din spatele aplicaiei ce pun la dispoziie un anumit serviciu sunt inaccesibile. LB
poate delega cererea ctre un LB de backup sau s afieze un mesaj cu detalii despre
inaccesibilitate. O metoda alternative de a realiza ncrcarea balansata care nu presupune
existenta unui software dedicat sau a unui hardware cu funcii speciale este round robin
DNS. Prin folosirea acestei tehnici se asociaz mai multe adrese IP aceluiai nume de
domeniu (ex: www.exemplu.org se asociaz ip-urilor: 11.172.20.84, 11.172.20.83,
11.172.21.84). Clienii au opiunea de a alege serverul la care s se conecteze. Spre
deosebire de folosirea unui LB dedicat, aceasta metoda nu este transparenta pentru clieni
deoarece expune serverele existente n spate aplicaiei (aici numele de domeniu).
Aceasta modalitate de a asigura ncrcarea balansata are avantaje i dezavantaje
funcie de gradul de control peste serverele de DNS i de granularitatea ncrcrii balansate
aspect ce ar trebui luat n considerare. n decizia de a trimite o cerere ctre un server, LB se
folosete de un algoritm de planificare care se poate utiliza sub forme variate, funcie de
factorii de care se vrea ca sistemul s tine cont. Unele sisteme abstractizeaz mult
ncrcarea neglijnd aceti 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 considerai simpli. Algoritmii mai sofisticai iau n consideraie factori adiionali
cum ar fi gradul de ncrcare raportat de ctre fiecare server, ultimul timp de rspuns,
up/down status (determinat de ctre o entitate care monitorizeaz resursele sistemului),
numrul de conexiuni active, localizarea geografica, capabilitile fiecrui server sau traficul
nregistrat de server n cel mai recent interval de timp de lungime stabilita. Deci, termenul de
ncrcare poate fi rezultatul unor calcule mult mai complexe funcie de factorii de care se
dorete a se tine cont n implementarea algoritmului de planificare a ncrcrii balansate.
Echilibrarea ncrcrii este utila mai ales atunci cnd volumul de activitate nu este cunoscut
naintea nceperii execuiei. De asemenea, ea ajuta la diminuarea efectelor datorate
diferenelor de viteza dintre unitile de execuie, chiar i atunci cnd volumul de activitate
este cunoscut n avans.
Echilibrarea statica a ncrcrii poarta n general numele de problema maprii sau problema planificrii
(scheduling problem). Aceasta problem se dovedete a fie foarte complexa i nu are o rezolvare unica. Putem
intalii moduri diferite de echilibrare al ncrcrii funcie de algoritm. Iat mai jos cteva exemple:

 Fair Load Balancer este cel mai simplist dar i cel mai corect. Acest mod va selecta
fiecare unitate de execuie care are pe moment cele mai puine calcule planificate.
Minusul major al acestei metode consta n faptul ca nu se ia n calcul starea unitarii de
execuie. Acest lucru rezulta ntr-o continua ncercare de a selecta acea unitate de
execuie chiar i daca acesta va rentoarce datele planificate napoi direct dup aceea.
Rezultatul final al acestui minus este ca daca un server nu este accesibil, performanta
sistemului ntreg va scdea foarte mult datorita ncercrilor continue de a selecta acel
server.
Round Robin Load Balancer a fost implementat n general pentru a fi utilizat n scopul
echilibrrii ncrcrii intre procesoarele locale. Este un mod complet inadecvat n
echilibrarea serverelor.
Predictive Load Balancer ofer acelai grad de acuratee ca i Fair Load Balancer dar
nu va lsa serverele inaccesibile s scad performanta ntregului sistem. Acest lucru
este realizat utiliznd un sistem de punctare al fiecrei uniti de execuie care a
cerut date.
Desigur, exista un numr nelimitat de algoritmi ce pot fi utilizai n scopul echilibrrii
ncrcrii. nsa aceste implementri sunt lsate n latitudinea programatorului care dorete s
extrag maxim de performanta. Att LB software ct i cele hardware pot avea mai multe
funcii de care sistemul n care se integreaz poate beneficia:
Asymmetric load: prin posibilitatea configurrii manuale a coeficientului de ncrcare la
nivel de server se poate realiza o configuraie a ncrcrii admise astfel nct unele
servere s poat suporta o ncrcare mai mare dect altele. Metoda des aplicata
atunci cnd unele servere proceseaz date mai rapid dect altele acestea vor putea
accepta o ncrcare mai mare. Viteza reprezentnd un factor care cntrete
semnificativ n ecuaia ncrcrii;
Priority activation: cnd numrul serverelor funcionale scade sub un anumit prag sau
ncrcarea pe oricare dintre serverele funcionale depete un anumit prag, serverele
inactive se vor activa;
SSL Offload and Acceleration: aplicaiile ce folosesc SSL pot fi o adevrata povara
pentru resursele unui server Web n special n ceea ce privete utilizarea CPU. n
acest context and-user-ul poate sesiza un rspuns ntrziat (ori serverul realizeaz
seturi de procesri, altele pentru care a fost destinat s execute). n rezolvarea
acestor probleme LB are trebui s dein capabiliti de realizare SSL Offloading
implementate n hardware specializat. Cnd LB obine conexiunea SSL, anumite
operaii 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 dispoziie
funcionaliti ca SYN cookies i deply-binding (serverele nu pot vedea clienii pana la

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 acelai client este vzuta ca o
noua conexiune TCP. Acesta facilitate presupune cumularea mai multor cereri HTTP
de la mai muli clieni pe un acelai soket TCP la server.
TCP buffering: LB poate pstra rspunsul cererii intr-un buffer urmnd apoi s trimit
el datele ctre clienii leni, lsnd serverul care a rspuns s efectueze alte task-uri;
HTTP caching: LB poate stoca coninut static ceea ce face posibila tratarea unor cereri
fr a contacta serverul.
Content Filtering: unele LB-uri pot modifica aleatoriu traficul n locurile unde
acioneaz.
HTTP security: LB poate ascunde unele erori, elimina informaiile 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 prioriti diferite pentru trafic diferit.

Content aware switching: LB poate retrimite cererea nregistrata la mai multe servere
pe baza URL-ului ctre care s-a fcut cererea;
Client authentication: supunerea utilizatorului autentificrii pe mai multe surse nainte
de a-i da accesul la o anumita resursa.
Programmatic traffic manipulation: cel exista un LB care pune la dispoziie un limbaj
de scripting pentru suprascrierea metodelor de ncrcare balansata.
Firewall: realizarea satisfacerii constrngerilor de acces ca operaie anterioara
rezolvrii cererii de ctre server
Din punct de vedere software, funcie de cerinele sistemului putem aduga n
implementare din funciile mai sus menionate. Toleranta la defecte reprezint abilitatea
sistemelor de a redireciona calculul computaional ctre un alt server funcional la cderea
unui server din cluster (un grup de servere independente interconectate ntr-o reea pentru
a lucra ca o resursa centralizata de procesare a datelor), n mod ct mai transparent posibil
pentru utilizator.
Vom folosi n continuare pentru procesul de redirecionare a calcului computaional de
la serverul inaccesibil ctre alt server funcional notaia FO (failover). Un scenariu ideal de
FO presupune existenta unui serviciu care s preia cererile de la clieni, s identifice care
dintre serverele cu funcionalitatea dorita sunt inaccesibile i care sunt accesibile i s trimit
cererea ctre un server disponibil la momentul cererii. Serverul delegat cu aceasta

responsabilitate verifica periodic daca o resursa este disponibila, i daca rspunsul este
afirmativ marcheaz serverul ca adugat 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 ncrcarea balansata, avnd n vedere ca aceste doua
concepte se afla ntr-o strnsa legtura) avem urmtoarele variante:
1. La unul din nodurile server;
2. La un server intermediar cu capabiliti de FO/LB;
3. La nivelul aplicaiei client.

Figur 1. Variante de identificare a locului unde se pot realizar activitile de FO/LB

Fiecare dintre soluiile expuse are un set de avantaje i dezavantaje. Prima soluie
presupune ca fiecare dintre entitile server s cunoasc topologia sistemului. Fiecare
entitate server tie s acceseze oricare alta entitate server din sistem. Nu este o soluie
foarte buna daca numrul de entiti server existente n sistem este foarte mare.
A doua varianta pune la dispoziie o entitate care s medieze intre celelalte entiti
server din sistem care gzduiesc servicii. Orice cerere ctre un serviciul localizat pe o
entitate server din sistem este procesata mai nti de entitatea mediatoare care decide crui
server s trimit cererea. Entitatea mediatoare este singura care cunoate 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 entitii mediatoare. Aceasta a doua varianta, rezolva problema
ridicata pentru prima varianta, dar primete o nota proasta la capitolul accesibilitate sistem.
Ultima soluie duce logica ncrcrii balansate la nivelul aplicaiei client. Aplicaia client
poate fi un nivel de indirectare existent pentru nivelul serviciilor prezent cu alte cuvinte
poate fi o aplicaie care s medieze alte aplicaii. Unele dintre avantajele acestei soluii este
ca: elimina single point of failure pentru ca nu exista nicio entitate mediatoare care s
realizeze ncrcarea balansata sau s se interpun n procesul de comunicare intre client i

serverul care gzduiete serviciul invocat de client; costul obinerii ncrcrii balansate este
minim: daca ncrcarea balansata are loc la client nu mai exista overhead de sistem datorat
altei entiti mediatoare, iar clientul pltete toate costurile; ncrcarea balansata exista atta
timp ct aplicaia client exista dispariia aplicaiei client nu afecteaz cu nimic structura
sistemului.
Totui acesta modalitate de realizare a ncrcrii balansata nu este o soluie de
integrare a unui sistem. ncrcarea balansata realizndu-se la nivelul aplicaie va fi foarte
greu pentru a aplicaie de mari dimensiuni s confrunte problema scalabilitii. Iat un posibil
scenariu de funcionare LB (loadbalancer):
entitate proxy intercepteaz cereri de la clieni.
Orice cerere este analizata de algoritmul de realizare a ncrcrii 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 excepii) rspunsul
se va trimite clientul care a emis cererea ctre proxy.
Daca invocarea nodului eueaz entitatea proxy va analiza daca se poate trece
transparent peste starea de excepie.
Un exemplu n care starea de excepie poate fi recuperabila transparent este atunci
cnd nodul target devine inaccesibil. Entitatea proxy apeleaz din nou la algoritmul de
ncrcare balansata obinnd un alt nod spre care face invocarea. Entitatea proxy tie ca
poate s fac silent failover ctre un alt nod din sistem (tie - n sensul ca are
capabilitatea, este setata corespunztor). Nu exista riscul task-uri incomplete sau duplicate
care ar trebui identificate, filtrate i ignorate de aplicaiile client.
Pe de alta parte, data interceptorul primete un alt tip de excepie, cum ar fi excepie la
nivelul bazei de date existente pe maina server, n acest caz nu poate face operaia de
silent failover ctre un alt nod din sistem. Va trimite excepia mai departe ctre client.
Clientul poate s i fac propriul business pentru tratarea unei astfel de excepii.
Interceptorul nu poate s rezolve generic altfel de excepii.
Acest comportament este flexibil i ct se poate de elocvent n majoritatea cazurilor.
Evident daca nivelul de complexitate al sistemului creste, cazurile de utilizare devin i ele mai
pretenioase. ncrcarea balansata se afla n strnsa corelaie cu toleranta la defecte: orice
cerere euata recepionata de FO e urmata o invocare a LB, care decide care este urmtorul
nod ce gzduiete serviciul apelat de client. Totui, daca nu exista niciun nod disponibil care
s serveasc o cerere atunci FO va rspunde clientului cu un mesaj relevat, anunndu-l de
excepia creata.
FO poate s funcioneze dup principiul ntotdeauna N instane disponibile. Aceasta
presupune regenerarea unei instane de serviciu pe unul din serverele disponibile, daca nu
mai poate fi accesibila. La fel, daca nodul czut i revine, o alta instana este aleasa s
moara. Aceasta strategie poate fi costisitoare din punct de vedere al procesrilor adiionale

pentru regenerare. Dar pe de alta parte asigura o accesibilitate relativ constanta n timp.
Daca sistemul este alctuit din numeroase noduri cu funcii 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 intervenia factorului uman.
Toleranta la defecte i ncrcarea balansata se afla n strnsa corelaie. n cadrul
realizrii tolerantei la defecte, o deosebita atenie se acorda modulelor de ncrcare
balansata. Aceste module expun un set de metode ce sunt apelate atunci cnd se dorete
selecia urmtorului client ce va primi un set de date, sau cnd acel client va ntoarce setul
de date rezultat. Este important deci ca modulul de echilibrare s ia n considerare i numrul
de ori cnd un client nu a putut evalua setul de date de intrare.
Daca acel factor nu intra n decizia seleciei urmtorului obiect e posibila o scdere
dramatica al vitezei de calcul pentru ca datele vor fi ntr-o continua micare spre entitatea
care nu rspunde i de la el.
In acest scop, un algoritm Predictive Load Balancer este cel mai bine adaptat. Acesta
folosete un sistem bazat pe puncte de penalizare:
La selecia urmtorului nod, acestuia i se atribuie un punct de penalizare i un punct
de ncrcare. Celorlalte noduri li se va scdea cate un punct de penalizare daca
numrul acestora este mai mare ca 0;
Daca nodul raporteaz succesul operaiunii de evaluare, lui i se va scdea un punct
de ncrcare. n cazul n care acesta are puncte de penalizare, i se vor scdea 2
puncte;
Daca nodul raporteaz eecul operaiunii de evaluare, i se va scdea un punct de
ncrcare i se vor aduga 3 puncte de penalizare;
Metoda de selecie al urmtorului nod este simpla, i anume: se va selecta acela care
are suma puncte de ncrcare + puncte de penalizare cea mai mica.
SOA nu este legata de o anumita tehnologie, ci definete o serie de principii (Figur
2):

Figur 2. Principiile SOA

Daca ne oprim asupra interoperabilitii (capacitatea unor aplicaii de pe platforme

diferite de a interaciona intr-un mod standard) putem spune ca este un aspect important n
asigurarea comunicaiei 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.).

10

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, trimind mesaje, realiznd o rutare inteligenta precum i
transformare" (Roy Schulte, Predicts 2003: Enterprise Services Buses Emerge, 2002).
ncepnd cu anul 2002 (an al apariiei publicaiei anterior menionate), ESB a devenit un
subiect al dezbaterilor specialitilor 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 implementrii SOA, att aplicaiile ct i infrastructura trebuie s suporte
principiile SOA. Existenta aplicaiilor presupune crearea interfeelor de business pentru noi
funcii n mod direct sau prin intermediul unor adaptoare. Existenta infrastructurii la nivelul de
baza presupune existenta clauzei capacitaii de rutare i transport a serviciilor cerute prin
intermediul provider-ului corect. Rolul ESB este acela de a permite infrastructurii aceasta
legtura. Adevrata valoare a ESB este de a permite accesarea infrastructurii pentru SOA, n
scopul satisfacerii nevoilor actuale ale aplicaiilor 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 fr a rezulta un efect negativ asupra clientului final.

11

Figur 4. Rezultatele implementrii 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 cror rol este relativ la ESB. Astfel ESB poate fi asociat cu urmtoarele componente
adiionale:
Business Service Directory pune la dispoziia 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 cnd ESB nu poate
realiza acest lucru. Organizaiile 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.

12

2. Concluzii
Pentru a obine 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 funcionalitate prin servicii s fie capabile de a fi configurate de ctre utilizatori fr
s ca acetia s devina experi n domeniul respectiv. Produsele software moderne, care
implementeaz arhitectura SOA, furnizeaz funcionalitatea necesara instituiei prin
implementarea unei magistrale de tip ESB. Abordarea ESB este aceea de a transforma
infrastructura robusta de mesagerie ntr-o platforma de dezvoltare a aplicaiilor care
interacioneaz prin interfee de tip serviciu. Metoda de lucru si gestiune pe baza uneltelor
coninute n produsele software SOA/ESB transforma infrastructura IT, astfel incat poate fi
utilizata att de administratorii IT, de programatori ct i de utilizatorii oameni de afaceri. Sunt
de asemenea luate n considerare modalitile de optimizare prin ncrcare balansat i
suport la defecte.
Specialitii considera ca un ESB poate realiza cu ncredere integrarea aplicaiilor (EIA)
n condiiile 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 declanate de evenimente (event
driven arhitecture). Astfel se ofer rspuns n timp real schimbrilor de business aprute.
ESB ofer o imagine de ansamblu a capabilitii infrastructurii, implementate in centrul
serviciilor n cadrul SOA. Odat cu cderea n dizgraie a soluiilor EAI, care nu satisfceau
cerinele complexe aprute i nu ofereau flexibilitate i scalabilitate, tafeta integrrii IT a fost
preluata, n ultimii 2-3 ani, de un alt concept care prea s revoluioneze radical acest
domeniu de grania: Enterprise Service Bus (ESB). Un studiu Forrester Research publicat n
august 2004 evidenia faptul ca 25% din companiile intervievate au renunat la platformele
EAI, optnd pentru o soluie ESB.

13