Curs 8

Cursul 8 Integrarea sistemelor informatice
STUDIUL TEHNOLOGIILOR INFORMATICE DE

INTEGRARE A APLICAIILOR
4.3. Standarde utilizate la integrarea aplicaiilor
4.3.1. Business Process Execution Language - BPEL
BPEL este un standard bazat pe XML i servicii Web care permite modelarea
fluxurilor de afaceri i automatizarea acestora. Folosind acest limbaj, fluxurile i regulile
de afaceri pot fi definite ntr-un mod intuitiv, fiind asigurat un nivel ridicat de
transparen n realizarea acestor operaiuni. Tehnologia BPEL simplific modul de
integrare a diverselor aplicaii i procese de afaceri [NET07].
Figura 4.9. Integrarea cu partenerii de afaceri

Dup cum reiese din figura 4.9, integrarea aplicaiilor prin BPEL se realizeaz
prin intermediul soluiei Business Process Management (BPM), care se bazeaz pe
standarde i tehnologii fundamentale ce stau la baza Internetului i care pot fi folosite att
pentru automatizarea proceselor interne din cadrul firmei, ct i pentru derularea
fluxurilor cu partenerii de afaceri. n acest sens, soluiile de acest tip ofer o flexibilitate
deosebit n integrarea i automatizarea unor procese de afaceri care prezint un nivel
ridicat de complexitate i la care particip mai multe companii
Evoluia BPEL
Evoluia BPEL este sugestiv reprezentat n figura 4.10, evideniindu-se trecerea
prin urmtoarele faze de dezvoltare:
Figura 4.10. Evoluia BPEL

eXtensible Language (XLang): este un limbaj bazat pe XML pentru
definirea proceselor i permite modelarea complex a proceselor de afaceri
foarte dinamice, realiznd legtura dintre fiiere obiect din Fortran i C++;
Business Process Markup Language (BPML): este un metalimbaj pentru
2000/05 descrierea
2001/03 proceselor
2001/05 afacerii.
2001/06BPML
2002/03
2002/06 iniial pentru a suporta
a fost proiectat
procesele2005/2006
de afaceri care ar putea fi executate de un sistem BPM. Att
2002/08 2003/04
BPML, ct i Web Service Choreography Interface (WSCI), aprut mai
trziu, partajeaz acelai model de execuie a proceselor de afaceri i
prezint similariti de sintax. BPML suport planificarea activitilor la
momente de timp specifice;
Web Services Flow Language (WSFL): este proiectat pentru a descrie
modul n care vor conlucra o serie de funcii pentru a oferi servicii Web;
Electronic Business Extensible Markup Language (ebXML): a fost creat
pentru a permite utilizarea global a informaiei electronice ntr-un mod
sigur, interoperabil i consistent de ctre toate prile implicate;
Web Services Conversation Language (WSCL);
Web Service Choreography Interface (WSCI): este interfaa ce asigur
suportul pentru intercomunicarea serviciilor web. Problema schimbului de
mesaje ntre servicii aparine WSCI (Web Service Choreography Interface),
interfa ce funcioneaz pentru limbajele de definire a serviciilor Web.
Acesta se refer mai ales la comportamentul extern al unui serviciu Web
prin asigurarea unei interfee comune de schimb al mesajelor. WSCI asigur
deci intercomunicarea serviciilor Web i, mai ales, conlucrarea acestora
pentru crearea aplicaiilor mari;
Business Process Execution Language for Web Services (BPEL4WS): prin
intermediul XML i BPEL4WS se asigur un nou nivel de conectivitate i
interoperabilitate, conform cerinelor arhitecturii orientate pe servicii
(Service-Oriented Arhitecture - SOA), stabilite de standardele internaionale
ale organizaiei Web Services Interoperability. Sunt disponibile mai multe
instrumente vizuale care ncorporeaz interfee intuitive i funcionaliti de
drag-and-drop, fiind posibil astfel modelarea simpl a fluxurilor
informaionale i a proceselor de afaceri. Fiind foarte flexibil n construcia
regulilor care conduc procesele de afaceri, se realizeaz o simplificare
modului de integrare a diverselor aplicaii i procese de afaceri.
BPEL4WS este practic un limbaj standard pentru integrarea proceselor care, n
vederea identificrii datelor relevante din mesaje, utilizeaz proprietile acestora.
Folosind acest mecanism, proprietile pot fi vizualizate n dou modaliti: transparent i
opac. Datele transparente afecteaz protocoalele de afaceri publice, n timp ce datele
opace sunt n primul rnd asociate cu sistemele back-end (afecteaz protocoalele de
afaceri prin nedeterminare).

BPEL4WS definete un model i o sintax pentru descrierea comportamentului
unui proces folosind interaciunile dintre proces i parteneri. Aceste interaciuni cu
partenerii apar prin interfeele serviciilor Web, iar structura relaiilor la nivel de interfa
exist ntr-o entitate cunoscut ca serviciu link. Misiunea unui proces BPEL4WS este s
descrie cum interacioneaz cu aceti parteneri, definind un proces de afaceri i incluznd
o logic de coordonare. Cu ajutorul acestui standard, se pot procesa excepiile i, n cazul
n care acestea apar, se pot defini modurile n care sunt compensate activitile
individuale sau compozite dintr-un proces.
Exist dou concepte majore care trebuie evideniate n ceea ce privete
standardul BPEL4WS n contextul integrrii aplicaiilor. Mai nti, un proces BPEL4WS
poate defini un protocol de afaceri utiliznd conceptul de proces abstract i oferind un
mecanism pentru identificarea datelor relevante pentru protocol ca proprieti ale
mesajelor care prin folosirea valorilor non-deterministice ascund proprietile private. n
al doilea rnd, este posibil ca BPEL4WS s defineasc un proces de afaceri executabil
care include logica i starea procesului. Acest mecanism gestioneaz conceptele de
integrare a proceselor fundamentale.
BPEL4WS exist ca o extensie a mai multor specificaii XML, cum sunt:
WSDL 1.1;
XML Schema 1.0;
Xpath 1.0.
BPEL4WS ofer un set de faciliti pentru refacerea sistemului dup apariia unei
erori n timpul execuiei unui proces sau n timpul tratrii unei excepii. Acest standard se
folosete de capacitile de tratare a excepiilor ncorporate n WSDL. Mai mult dect
att, exist noiunea de compensare, n sensul c permite proiectantului procesului s
implementeze aciuni de compensare pentru anumite aciuni ireversibile. Acest aspect
este tratat n BPEL4WS folosind noiunea de scop. Scopul este o unitate de lucru pentru
compensare.
BPEL4WS are potenialul de a deveni un standard bazat pe limbaj pentru
integrarea proceselor i permite crearea modelelor pe o singur tehnologie de integrare a
aplicaiilor, fr a face transformri asupra codului.
Cadrul BPEL
Procesele de afaceri reprezint colecii de servicii Web care coopereaz pentru a
oferi o soluie comun unei anumite probleme. Cooperarea serviciilor impune
coordonarea acestora. Coordonarea serviciilor Web este realizat pe baza unui set partajat
de informaii care formeaz contextul de coordonare. Contextul de coordonare se
definete ca fiind totalitatea informaiilor partajate de ctre serviciile Web n vederea
conectrii activitilor individuale din cadrul proceselor generale de afaceri [MND05].
BPEL este un limbaj destinat definirii de fluxuri de activiti. Limbajul utilizeaz
sintaxa XML i permite descrierea de procese care pot fi att productori ct i
consumatori de servicii Web.

BPEL ofer suport att pentru procesele de afaceri executabile, ct i pentru cele
abstracte. Procesele executabile modeleaz comportamentul participanilor ntr-o
interaciune de afaceri specific, modelnd n esen un flux de activiti privat. Procesele
abstracte, modelate ca protocoale de afaceri n BPEL, specific schimburile de mesaje
publice ntre participani. Protocoalele de acest tip nu sunt executabile i nu transport
detalii interne ale fluxului proceselor.
n construirea proceselor de afaceri sunt parcuri urmtorii pai [MND05]:
Definirea interfeelor publice;
Crearea dicionarului partener;
Crearea mesajului i stabilirea tipul dicionarului;
Implementarea transformrilor logice;
Testarea mediului;
Repetarea, dac este cazul, a pailor 1-5;
Realizarea unui proiect pilot funcional;
Reglarea sarcinilor privind operaiunile.
IBM ofer specificaiile unui cadru pentru aplicaii dezvoltate prin integrarea de
servicii Web. Acest cadru permite utilizarea forei i avantajelor arhitecturii Web orientat
pe servicii n crearea i automatizarea tranzaciilor ntre partenerii unei afaceri, prin
automatizarea i integrarea solicitrilor serviciilor Web oferite de acetia.
Cadrul este format din specificaiile BPEL, WS-Transaction (Web Service
Transaction) i WS-Coordination (Web Services Coordination). El st la baza conectrii
aplicaiilor distribuite i a cooperrii activitilor acestora n mod dinamic.
WS-Transaction i WS-Coordination sunt specificaii complementare limbajului,
utilizate pentru a asigura coordonarea i corectitudinea rezultatelor produse de procesele
definite peste serviciile Web, n contextul problematicii sistemelor distribuite.
Procesele BPEL implementeaz scenarii n care, pentru soluionarea problemelor
unui client, sunt implicai mai muli parteneri, fiecare furniznd un serviciu Web. Fiecare
partener implementeaz o parte din ntregul proces necesar pentru a rspunde solicitrii.
Tehnologiile de realizare a tranzaciilor dintre parteneri sunt potenial incompatibile i au
cerine specifice, integrarea lor fiind soluionat de cadrul pentru aplicaii.
Cadrul ofer mijloace pentru definirea integrrii partenerilor eterogeni n
procesele globale, pentru stabilirea modului n care activiti ale acestor procese pot fi
externalizate public sub form de servicii Web, pentru coordonarea activitilor serviciilor
Web multiple ntr-o tranzacie global i, de asemenea, pentru legarea dinamic, la
execuie, a unui serviciu selectat, dintr-un set de servicii, pe baza datelor derivate din
fluxul proceselor.
Dezvoltarea unei aplicaii bazat pe servicii Web ncepe cu definirea proceselor,
urmat de stabilirea partenerilor, a conexiunilor dintre acetia, a mecanismelor de
coordonare i a operaiilor indivizibile utiliznd tranzacii.
n limbajul BPEL se creeaz o descriere abstract a proceselor de afaceri. BPEL
produce scripturi executabile care implementeaz descrierea abstract a proceselor i care
pot fi interpretate de motoare speciale.
Un script al unui proces este o succesiune de pai, fiecare pas corespunznd unei
singure activiti. Implementarea unei activiti nseamn definirea unei interaciuni cu un
serviciu Web.

Clienii i serviciile Web sunt considerai parteneri i sunt conectai prin legturi
care se caracterizeaz prin tip i prin rolurile partenerilor.
Un proces este compus din mai multe activiti diferite, unele dintre acestea fiind
executate simultan. Toate activitile implicate n proces sunt supuse mecanismului de
coordonare, care asigur generarea de rezultate corecte i consistente.
Activitile implicate ntr-un proces trebuie finalizate cu succes fiecare n parte i
n ansamblul lor. Pentru aceasta trebuie soluionat att problematica clasic a
tranzaciilor, ct i cea specific sistemelor distribuite. n cazul sistemelor distribuite,
aceasta deriv din durata mare a unei tranzacii, ca i din latena semnificativ a
procesului de comunicare n reea. Controlul tranzaciilor la nivelul procesului se face de
ctre o infrastructur care monitorizeaz rezultatele fiecrei activiti individuale n raport
cu modul n care aceasta este relaional cu ansamblul procesului. Pentru gestionarea
tranzaciilor la nivelul fiecrei activiti se utilizeaz aplicaii tradiionale pentru
tranzacii i coordonare.
WS-Transaction este un cadru de aplicaii pentru monitorizarea succesului sau
eecului fiecrei activiti indivizibile n raport cu realizarea ansamblului activitilor care
formeaz procesul. Acest cadru se bazeaz pe servicii Web, n sensul c suportul pentru
tranzacii ofer interoperabilitate ntre aplicaiile proprietar de gestionare a tranzaciilor n
vederea realizrii modelului tranzacional la nivelul proceselor de afaceri.
Modelul proceselor de afaceri cu funcii de coordonare i tranzacii distribuite
ofer o serie de avantaje. Deoarece este construit peste o arhitectur orientat pe servicii
Web, el permite integrarea flexibil i dinamic a aplicaiilor ce se execut pe platforme
diferite i potenial incompatibile. Modelul este extensibil, oferind un cadru general
pentru crearea de procese de afaceri, care poate fi extins pentru a include noi cerine.
Acest lucru permite, de asemenea, evoluia instrumentelor de dezvoltare i testare a
aplicaiilor pe msura evoluiei cerinelor. Modelul este flexibil, oferind suport pentru o
procesare durabil, sigur i corect a unui spectru larg de procese de afaceri
tranzacionale i non-tranzacionale.
WS-Transaction este folosit n monitorizarea corectitudinii fiecrei activiti
individuale ce trebuie realizat ntr-un proces global. Iar BPEL este folosit pentru
definirea modului de compensare a activitilor euate.
BPEL limbaj pentru programarea orientat pe servicii Web
BPEL este un limbaj cu ajutorul cruia se definesc operaii de comunicare a
serviciilor Web. O astfel de compoziie descrie o serie de procese, numite procese de
afaceri (business processes), deoarece sunt specifice aplicaiilor unui anumit domeniu.
Acestea se execut prin integrarea mai multor servicii disponibile n Web. Limbajul poate
fi utilizat att pentru implementarea proceselor de afaceri, ct i pentru descrierea de
procese abstracte non-executabile [MND05].
Procesele de afaceri se pot reprezenta ntr-o diagram de flux a operaiilor care
exprim un algoritm cu care se definete un nou serviciu Web rezultat prin compunerea
mai multor servicii existente.
Partenerii sunt reprezentai printr-o referin tipizat la un serviciu. Aceast
referin trebuie rezolvat n sensul stabilirii corespondenei cu serviciul Web real. Exist
dou tipuri de parteneri: partenerii invocai - sunt cei pentru care procesele sunt clieni i

sunt parte integrat a algoritmului dup care acestea se desfoar; partenerii clieni sunt cei care invoc procesele.
O activitate scrie i acceseaz date aflate n containere de date. Un container
conine o instan a unui tip de mesaj definit de WSDL.
Limbajul ofer un set de activiti primitive pentru invocarea de servicii Web,
pentru manipularea datelor, pentru lansarea de execuii, acestea reprezentnd cea mai
simpl form de interaciune a procesului cu lumea exterioar lui. Activitatea primitiv se
definete ca fiind un pas individual n cadrul proceselor. Acestea interacioneaz cu un
serviciu, manipuleaz transferul datelor i trateaz excepiile.
<invoke> - invoc un serviciu sincron;
<receive> - ateapt mesaje despre pornirea sau repornirea proceselor;
<assign> - manipuleaz transferul de informaii, copiaz date de la un
container la altul, insereaz noi date ca rezultat al evalurii unor expresii;
<replay> - ntoarce rspuns pentru procesele sincrone;
<throw> - indic apariia unei erori;
<terminate> - determin abandonarea imediat a execuiei instanei curente
a proceselor de afaceri;
<wait> - pune procesele n ateptare un interval de timp, pn la atingerea
unui termen.
Activitile pentru structurare definesc ordinea de execuie a unei colecii de
activiti. Ele descriu structurile dup care sunt compuse mai multe activiti primitive
pentru a forma procese. Aceste structuri exprim abloanele de control, fluxul de date,
manipularea erorilor i a evenimentelor externe. Activitile de structurare descriu, de
asemenea, coordonarea schimbului de mesaje ntre instanele proceselor implicate.
<sequence> - permite definirea unei structuri ce conine o secven
ordonat de activiti;
<switch> - permite definirea unei structuri de ramificare;
<pick> - ofer posibilitatea alegerii unei ci din mai multe alternative;
<flow> - definete un set de legturi care are ca surs i ca destinaie
activiti de structur;
<link> - reprezint o legtur dintre dou obiecte;
<while> - permite definirea structurilor repetitive;
<scope> - este utilizat pentru divizarea proceselor de afaceri n pri
organizate; este un context executant pentru activitile coninute, un proces
fiind el nsui un <scope>.
O problem important este legat de manipularea erorilor i recuperarea
proceselor dup producerea acestora. Pentru manipularea erorilor limbajul ofer
construciile throw i catch. Pentru a da posibilitatea terminrii procesului erorile se
trateaz folosind <faultHandlers>.
Execuia proceselor BPEL
Un proces are mai multe puncte de intrare. Unul dintre acestea este punctul de
pornire al procesului care este accesat la prima solicitare a serviciului implementat de el
din partea fiecrui client. n acest punct se lanseaz operaiile de creare a instanei de
proces i de asociere a acestei instane cu valoarea cmpului cheie din mesaj. n
6

momentul invocrii unui proces, se execut o operaie numit corelare-mesaj. Aceast
operaie verific dac exist o instan corespunztoare cmpului cheie din mesajul de
invocare. Dac nu exist aceast instan, operaia de corelare-mesaj lanseaz procesul
prin punctul de pornire, iar dac instana corespunztoare exist, atunci lanseaz operaii
ale procesului prin celelalte puncte de intrare.
n definirea unui proces se descrie modul de interaciune cu partenerii, se
specific entitile de tip container pentru mesajele pe care procesul le schimb cu
partenerii si i se definesc activitile pentru interaciunea procesului cu lumea
exterioar lui.
Procesele de afaceri definite n limbajul BPEL pot fi repartizate i executate
utiliznd o platform ce implementeaz specificaiile acestui limbaj. O astfel de platform
este motorul BPWS4J oferit de AlphaWorks [MND05].
4.4. Arhitecturi utilizate n integrarea aplicaiilor

4.4.1. Arhitectura orientat pe servicii
Arhitectura orientat pe servicii (Service-Oriented Arhitecture - SOA) exprim
un concept de arhitectur software ce presupune folosirea serviciilor Web disponibile n
scopul satisfacerii cerinelor utilizatorilor de software. Un sistem SOA poate fi
implementat n multe moduri, folosind o varietate de instrumente i tehnologii.
Tehnologia serviciilor Web, care constituie baza SOA, a fost adoptat de marea majoritate
a juctorilor din industria de software: IBM, Microsoft, Sun Microsystems, SAP, Oracle
amd.
O platforma complet de tip SOA permite integrarea aplicaiilor de ntreprindere,
realizndu-se astfel implementarea simpl a proceselor de afaceri n cadrul companiilor.
ntr-un mediu SOA, nodurile dintr-o reea asigur disponibilitatea resurselor ca servicii
independente, pe care utilizatorii le acceseaz ntr-un mod standardizat.
SOA implic mai mult dect conexiunile dintre serviciile Web sau setul de
componente de afaceri ce ar urma s fie livrat i care ar putea funciona mpreun. SOA
determin, de fapt, obinerea de beneficii gestionnd proceselor de afaceri cu ajutorul
aplicaiilor existente. SOA reprezint viitorul serviciilor IT, o arhitectur orientat pe
servicii permind integrarea tuturor resurselor IT, inclusiv a aplicaiilor create prin
tehnologii .NET sau Java.
Orientarea pe servicii reprezint o nou metod pentru proiectarea sistemelor
distribuite. Conceptele principale folosite n cadrul acestei abordri sunt:
serviciu: unitate independent a unei aplicaii care expune funcionalitatea
ctre clienii din reea prin intermediul unei interfee bazate pe mesaje;
client: un modul al unei aplicaii care faciliteaz accesul utilizatorilor la
funcionalitatea oferit de servicii;
sistem distribuit: un sistem interconectat de servicii i clieni.
Sistemele orientate pe servicii sunt sisteme slab cuplate, proiectate pentru a
permite schimbarea pentru adaptarea la noi cerine sau metode de implementare. Prin
utilizarea modelului orientat pe servicii este posibil obinerea unei interoperabiliti ntre
aplicaii, indiferent de platformele i limbajele de programare utilizate n dezvoltarea
7

acesteia. Dezvoltatorii de aplicaii nu au nevoie s cunoasc tipul de sistem, modelul de
obiecte sau protocoalele folosite de ctre sistemele care trebuie integrate. Expunerea
funcionalitii folosind protocoale standardizate i interfee care pot fi obinute dinamic
conduce la o cuplare slab ntre subsisteme, permind astfel o conectare simpl i
asigurnd o flexibilitate sporit aplicaiei.
Implementarea SOA necesit o serie de componente, precizate detaliat n
[NET09]. Pe scurt, aceste componente sunt:
serviciile de afaceri (Business Services): n mod normal, primul pas spre
SOA este adoptarea serviciilor web. Acest lucru presupune expunerea
aplicaiilor i a sistemelor deja existente prin intermediul interfeelor bazate
pe standarde;
resgistrul (Registry): sistemul de nregistrri al unei SOA ce furnizeaz o
modalitate de administrare a serviciilor de afaceri. Un registru reine
descrierea detaliat a unui serviciu SOA i utilizeaz informaia respectiv
ntr-un serviciu de afacere de tip Registry;
managerul de politici (Policy Manager): produs bazat pe standarde ce
simplific procesul de creare, administrare i standardizare a politicilor
necesare oricrei afaceri;
consola de adminostrare (Management Console): soluie de management ce
permite utilizatorilor s monitorizeze, s administreze i s securizeze
serviciile Web sau procesele SOA n totalitate, dar i s asigure
managementul eficient al sistemelor fragile din punct de vedere
tehnologic;
translatoare de mesaje: module software aezate naintea oricrui serviciu
astfel nct serviciile interne s poat fi accesate n limbajul nativ al
sistemului n cauz i n acelai timp n acelai limbaj pe ansamblu, de
obicei XML, ca orice alt serviciu din reea.
La nceput, aceast tehnologie nu era dominat, n aparen, de o tendin anume.
Instrumentele de integrare nu erau difereniate: exista unul singur pentru toate
conexiunile. Pe msur ce conceptul SOA a evoluat, arhitectura s-a divizat n categorii cu
nsuiri diferite. La cel mai nalt nivel acestea sunt:
aplicaii fizice: programele care duc la bun sfrit sarcinile;
servicii directoare: separ procesele de afaceri;
sincronizarea datelor: component folosit la construirea i ntreinerea
conexiunilor de date;
nivelul de procese de afaceri, care utilizeaz serviciile pentru a acoperi
procesele specifice afacerii.
Aceste componente au funcii i structuri diferite, de aceea se recomand folosirea
de tehnologii separate.
Un principiu fundamental al SOA se refer la faptul c serviciul furnizat prin
intermediul unei interfee trebuie s rmn acelai, pn la identitate, independent de
implementare. Un serviciu de detalii client, de exemplu, trebuie s furnizeze aceeai
funcie economic independent de faptul c implementarea obiectului economic este
realizat ntr-o singur component partajat, peste mai multe platforme i sisteme
anterior n funcie, sau furnizat de la un partener comercial prin Internet.

Tehnologiile de livrare a aplicaiilor ntrebuinate ulterior fac ca aceast
transparen s devin o problem dificil. Serviciile de apelare care sunt implementate n
diferite tehnologii nu sunt directe, iar cuplarea strns a interfeelor are ca semnificaie
afectarea acestora (prin modificare lor) odat ce a aprut o schimbare n implementarea
componentei. Schimbarea (modificarea) componentelor are ca efect, de asemenea,
schimbri n ceea ce privete aplicaiile de apelare, anulnd astfel anumite beneficii
ateptate de la proiectarea bazat pe componente.
Spre deosebire de arhitecturile tradiionale orientate-obiect (object-oriented), SOA
cuprinde servicii cuplate, dar independente, puternic interoperabile. Deoarece aceste
servicii opereaz pe diferite platforme de dezvoltare (Java sau .NET), componentele
software devin reutilizabile (de exemplu, un serviciu C# ar putea fi folosit de o aplicaie
Java sau alt limbaj de programare), datorit faptului c interfaa a fost definit inndu-se
cont de standarde (Web Services Description Language - WSDL) din domeniu, care
ncapsuleaz (ascund) implementarea specific fa de client/serviciu.
O caracteristic fundamental a arhitecturii propuse este separarea definirii
proceselor de integrarea back-end, separare ce permite analitilor s se concentreze
asupra dezvoltrii soluiilor pentru probleme specifice. Prin aceast separare, este
asigurat o arhitectur de tip plug-and-play, un nivel de separare ce sigur schimbarea
sistemelor de tip back-end fr schimbarea proceselor [NET18].
Arhitectura orientat pe servicii a fost dezvoltat pentru a soluiona problemele
legate de integrare i automatizarea proceselor interne i externe cu alte companii sau
parteneri n reea. Scopul final este de a avea o arhitectur IT care acoper n mod optimal
cerinele prezente i viitoare, respectiv integrarea intern EAI i extern G2B, G2C, G2G,
WebServices.
Arhitectura conceptual ndeplinete o serie de criterii pentru validarea ulterioar
a conceptelor, tehnologiei i produselor, care asigur:
integrarea tuturor funciilor relevante i a proceselor;
integrarea sistemelor existente n noua platform, asigurnd protecia
investiiilor;
minimizarea riscului, reacie rapid la schimbarea cerinelor;
complexitate redus prin construirea unei interfee bazate pe servicii
specifice integrate n sistem;
utilizarea standardelor XML, XSL, SOAP, UDDI, WSDL i HTTP;
flexibilitate;
abilitatea de extindere n conformitate cu necesitile scalabilitate;
reducerea costurilor i creterea productivitii prin transferul rapid al
aplicaiilor de pe orice platform.
Prin procese de afaceri construite pe o arhitectur orientat pe servicii, o
companie poate exploata aplicaiile software existente, astfel nct s ating un grad
superior de interoperabilitate nu doar ntre toate departamentele firmei ci i cu alte
companii. Aceast abordare valorific resursele existente pentru a ajuta la mbuntirea
productivitii, permind astfel companiei s reacioneze rapid la schimbrile intervenite
pe pia, fructificnd astfel oportunitile de afaceri.
Beneficiile arhitecturii orientate pe servicii

O arhitectur orientat pe servicii conine servicii web pe care dezvoltatorii le
creeaz ntr-un nivel de servicii specific. Serviciile pe care acetia le dezvolt dispun de
interfee publicate, ce se adreseaz unei anumite zone de afaceri. Organizaiile care i
concentreaz eforturile pe integrarea de servicii, vor avea parte de numeroase beneficii.
Recuperarea rapid a investiiilor. Un nivel de servicii robust are avantajul unei
recuperri rapide i substaniale a investiiilor aduse n construirea componentelor
software. Serviciile individualizeaz domeniile distincte ale afacerii. De exemplu, o
companie creeaz un serviciu ce dispune de toate metodele necesare pentru a administra
stocurile. Aeznd logica afacerii (datele) ntr-un nivel separat, acesta poate exista
independent de orice alt sistem n care este integrat. Un alt exemplu se poate referi la
nevoia unei organizaii de a crea un serviciu pentru autorizarea crilor de credit.
Dezvoltatorii vor introduce funcionalitatea respectiv n aplicaia care are nevoie de ea
sau ntr-o component independent.
Mobilitatea codului. Deoarece transparena locaiei este o proprietate a arhitecturii
orientate spre servicii, mobilitatea codului devine realitate. Conectarea dinamic la un
serviciu nseamn c activitatea utilizatorului nu este influenat de locaie (a lui sau a
serviciului pe care l folosete). De aceea, o organizaie are flexibilitatea necesar pentru
a muta servicii pe o main diferit sau ctre un furnizor extern.
Funcionaliti specializate pentru dezvoltatori. Arhitectura orientat spre servicii
va fora aplicaia s fie organizat pe mai multe niveluri, fiecare cu un rol specific pentru
dezvoltatori. Un dezvoltator de aplicaii client trebuie s cunoasc tehnologii precum
SWING, JSP sau .NET. Fiecare nivel necesit un set complex de cunotine. Avnd aceste
delimitri de specializare, dezvoltatorii vor excela n domeniul particular n care
activeaz. Companiile vor avea la rndul lor de ctigat, nefiind nevoite s mai apeleze la
specialiti cu o bogat experien n dezvoltarea de aplicaii.
Securitate mrit. Crearea unui nivel de servicii nseamn de fapt construirea unei
interfee de reea adiional ce poate fi folosit de mai multe aplicaii. Cnd sistemele
erau construite prin metode monolitice sau client-server, problema securitii era abordat
n front-end. De multe ori companiile nu mai implementau componente de securitate din
cauza cheltuielilor de ntreinere. Pe de alt parte, serviciile sunt folosite de multe
aplicaii, aa c dispun de propriul mecanism de securitate. De aceea fiecare program va
avea mai multe niveluri de autentificare pentru aplicaia client de serviciu.
Teste superioare - mai puine erori. Dezvoltatorii au la dispoziie instrumente
precum JUnit pentru crearea de teste. Acestea pot fi rulate pentru a valida serviciul,
independent de orice aplicaie care l folosete. O practic foarte bun este aplicarea de
teste n timpul unui proces automat. Mai multe teste nseamn, de obicei, mai puine erori
i o cretere pe ansamblu a calitii.
Suport pentru mai multe tipuri de clieni. Un alt beneficiu al SOA este
posibilitatea companiilor de a folosi o varietate de clieni pentru accesarea unui serviciu.
Un PDA ce folosete J2ME poate accesa un anumit serviciu prin HTTP, iar un client
SWING poate accesa acelai serviciu via RMI. Avnd n vedere faptul ca nivelurile de
aplicaii client sunt separate de servicii, noi tipuri de clieni pot fi implementai cu
uurin.
Asamblarea serviciilor. Utilizatorii vor ajunge s neleag serviciile ca pe nite
bunuri refolosibile, ce pot fi combinate ntr-o multitudine de moduri. Utilitatea va consta
n dezvoltarea mai rapid de noi aplicaii.
10

Mentenan superioar. Prin orientarea spre servicii, ca locaie a logisticii,
operaiunile de mentenan se mbuntesc deoarece dezvoltatorii pot localiza defectele
de cod mai uor.
Scalabilitate. O cerin important pentru arhitecturile orientate spre servicii este
transparena locaiei. Pentru a obine aceste lucru, aplicaiile caut servicii ntr-un director
i se conecteaz la ele dinamic. Aceast situaie caracterizeaz scalabilitatea, ntruct
cererile de conectare pot fi naintate fr intervenia clientului de serviciu.
Fr ndoial instalarea unui nivel de servicii presupune un efort suplimentar la
nceputul proiectului, dar beneficiile pe termen lung sunt evidente.
4.4.2. Oracle Application Integration Architecture
Oracle Application Integration Architecture (OAIA), arhitectur lansat n aprilie
2007, ofer procese de afaceri care leag compartimentele operaionale, crescnd
eficiena costurilor i reducnd ciclul de via. Oracle ofer soluii prefabricate de
integrare a proceselor, suport i optimizri pe parcursul acestor integrri, implementnd i
utiliznd cele mai bune practici de afaceri pentru conectarea i optimizarea operaiilor
afacerii.
Avantaje oferite:
soluii prefabricate de integrare care reduce costul integrrii sistemelor i
minimizeaz riscurile;
cele mai bune practice de afaceri bine documentate sunt disponibile pentru
integrare n aplicaiile existente;
arhitectur deschis, bazat pe standarde.
OAIA se bazeaz pe facilitile oferite de Oracle Fusion Middleware, i include
metodologia i instrumentele din SOA, mpreun cu un depozit de servicii de afaceri
(Business Service Repository) care permite dezvoltarea sau extinderea aplicaiilor.
4.4.3. Enterprise Services Architecture
Enterprise Services Architecture (ESA) este interpretarea pe care SAP a dot-o unei
arhitecturi SOA care extinde conceptul de serviciu Web, nlocuindu-l cu conceptul
propriu de serviciu al ntreprinderii (enterprise service). Din punct de vedere tehnic,
serviciile de ntreprindere se bazeaz pe servicii Web, oferind acces la elementele i
funciile afacerii n termeni economici. Utilizarea serviciilor de ntreprindere n cadrul
aplicaiilor conduce la o cretere a flexibilitii, deschiderii si vitezei.
Bazate pe standarde deschise, serviciile de ntreprindere ncapsuleaz
funcionalitile ntreprinderii i le expune ca servicii reutilizabile, care pot fi apoi
combinate cu alte servicii pentru a rspunde unor cerine noi. Serviciile de ntreprindere
pot fi rapid combinate pentru a compune noi aplicaii i a sprijini noi procese de afaceri.
11

Aceste servicii pot comunica logica de afaceri ntre aplicaii care ruleaz pe
platforme disparate. Utiliznd aceste servicii, se poate rspunde mai rapid la schimbrile
care apar n cadrul firmelor, i se pot reduce costurile prin reutilizarea fucionalitilor
deja existente.
Organizaiile pot adopta aceast arhitectur prin implementarea platformei SAP
NetWeaver. SAP are chiar un program de adoptare SOA, prin care asist organizaiile
doritoare la elaborarea i implementarea planului de adoptare SOA. SAP ofer att
soluiile software orientate pe servicii, ct i platforma tehnologic SAP Netweaver i
asisten altor companii care doresc s i dezvolte propriile arhitecturi orientate pe
servicii, pentru soluii SAP i non-SAP.
4.5. Tehnologii informatice de integrare a aplicaiilor

4.5.1. Tehnologia middleware
Tehnologiile care permit realizarea integrrii aplicaiilor n cadrul unei
ntreprinderi constituie ceea ce se numete n limbajul de specialitate middleware
[NET17]. Cea mai bun abordare n ncercarea de definire a middleware-ului este pe baza
funciilor sale. Middleware este un mecanism care permite unei entiti (baz de date sau
aplicaie) s comunice cu o alt entitate (sau cu mai multe entiti). Cu alte cuvinte,
middleware este un tip de software care faciliteaz comunicaia ntre dou sau mai multe
sisteme software.
Dei este un termen utilizat pentru a desemna mai multe subcategorii de
tehnologii, n prezent, pentru realizarea unei aplicaii formate din mai multe componente
distribuite se utilizeaz cu precdere fie tehnologiile orientate-obiect reprezentate n
standardele CORBA sau DCOM, fie tehnologia Java i conceptul de component Java
Bean. Cu ajutorul acestor tehnologii se realizeaz cele mai multe servere de aplicaii din
categoria celor ce trebuie s satisfac cerine severe de performan i disponibilitate.
Folosirea tehnologiilor middleware n cadrul integrrii aplicaiilor este posibil
datorit existenei urmtoarelor dou elemente:
conceptul de interfa care caracterizeaz fiecare component conectat la
magistrala middleware i permite descrierea ansamblului de servicii oferite
de ctre infrastructur; n cadrul EAI, interfeele sunt construite la nivelul
adaptoarelor asociate aplicaiilor;
metodologia orientat-obiect permite construirea unui model de interfee,
care s rspund necesitilor utilizatorilor i s contribuie la reducerea
nivelului de complexitate necesar crerii i gestionrii sistemelor distribuite
[SARU00].
Tehnologia middleware poate fi utilizat pentru urmrirea i administrarea
ciclurilor de via i pentru asigurarea politicilor n cadrul mediilor de dezvoltare
integrate.
12

4.5.1.1.Modele middleware
Exist dou modele de middleware: logic i fizic. Modelul logic descrie cum are
loc transferul de date conceptual, iar modelul fizic descrie metodele precum i tehnologia
folosite pentru transferul de informaie. Configuraiile asociate modelului logic sunt:
unu la unu,
muli la muli i
sincron versus asincron.
Modelului fizic i sunt asociate modele bazate pe mesaje.
Middleware unu la unu folosete o conexiune software temporar ntre dou
programe sau comenzi (pipe) pentru a permite unei aplicaii s acceseze alt aplicaie.
Considerm, spre exemplu, dou aplicaii A i B. Cnd aplicaia A ncearc s comunice
cu aplicaia B nchide conexiunea folosind o procedur de apel sau un mesaj (figura
4.11).
Aa cum sugereaz numele, middleware-ul muli la muli, leag mai multe
aplicaii ntre ele. Aceast capacitate l face cel mai potrivit pentru integrarea aplicaiilor.
n plus, este cel mai puternic middleware logic, deoarece ofer att flexibilitate ct i
adaptabilitate problemei integrrii.
Figura 4.11. Configuraia unu la unu

Sunt mai multe exemple de middleware muli la muli: integrare la nivel de
servere, middleware tranzacional (servere aplicaii i monitori TP) i chiar obiecte
distribuite. Practic, orice tip de middleware care poate s lucreze cu mai multe de dou
aplicaii surs i destinaie n acelai timp poate susine acest model (figura 4.12).
13
Figura 4.12. Configuraia muli la muli

Avantajul modelului unu la unu este simplitatea, modelul muli la muli avnd
dezavantajul complexitii. Aceast problem este atenuat de noua generaie de
middleware.
Middleware-ul asincron face transferul de informaie ntre mai multe aplicaii n
mod asincron, ceea ce presupune c software-ul middleware se poate deconecta de la
aplicaia surs sau destinaie. Aplicaiile nu sunt dependente de alte aplicaii conectate
pentru procesare. Procesul care permite acest lucru are aplicaiile plasate ntr-o coad de
ateptare, fiecare cu un mesaj asociat i fiecare ruleaz independent, rspunsul de la
celelalte aplicaii primindu-se mai trziu. Avantajul principal este acela c middleware-ul
nu blocheaz celelalte aplicaii din procesare. Mai mult dect att, deoarece middlewareul se decupleaz de la aplicaie, aceasta poate s continue procesarea, indiferent de stadiul
celorlalte aplicaii.
Pe de alt parte, middleware-ul sincron, este strns cuplat la aplicaii. Aplicaiile
sunt dependente de middleware pentru a procesa unul sau mai multe apeluri funcie pe o
aplicaie la distan. Ca rezultat, aplicaia care apeleaz trebuie s opreasc procesarea
pentru a atepta rspunsul aplicaiei aflate la distan. Acest tip de middleware este referit
ca unul care blocheaz. Dezavantajul acestui model este cuplarea aplicaiilor la
middleware i la aplicaia la distan.
4.5.1.2. Tipuri de middleware

Modelele middleware au avut o evoluie continu nc de la apariie, ceea ce duce
la ivirea unor dificulti de a le ncadra n anumite categorii. Cu toate acestea, se observ
existena ctorva tipuri de middleware care se pliaz foarte bine pe rezolvarea anumitor
tipuri de probleme. Urmtoarele tipuri de middleware vor fi descrise n continuare: RPC,
14

MOM, obiecte distribuite, middleware orientat pe baza de date, middleware tranzacional
(include monitori TP i servere de aplicaii) i servere de integrare.
Remote Procedure Calls (RPC) reprezint cel mai vechi tip de middleware, uor
de neles i de folosit. Acesta ofer dezvoltatorilor capacitatea de a apela o funcie dintrun program i de a o executa ntr-un alt program, pe o main la distan (figura 4.13).
Pentru dezvoltator, funcia se execut local, faptul c aceasta este de fapt executat pe
maina aflat la distan fiind ascuns.
Figura 4.13. Funcionarea RPC

RPC sunt modele sincron de middleware. Pentru ca RPC s fie activat, execuia
programului trebuie oprit. n ciuda simplitii, majoritatea RPC-urilor nu au o
performan foarte bun. Cum majoritatea transferurilor de informaie necesit o reea, un
middleware de tip RPC folosete toate resursele reelei. Un RPC tipic necesit 24 de pai
distinci pentru a ndeplini cererile. Acest nivel de performan limiteaz beneficiile unui
apel RPC ntr-o reea nceat, cum este Internetul.
Middleware-ul orientat pe mesaje (MOM) este un software care folosete mesaje,
uniti de informaie (de tip BYTE), care sunt interschimbate de aplicaii, ca pe un
mecanism de a face transfer de informaie de la un punct la altul. Deoarece MOM
folosete mesajele pentru a realiza comunicarea ntre aplicaii, nu este necesar cuplarea
aplicaiilor la middleware (se bazeaz pe modelul asincron). Mesajul intr astfel ntr-o
coad manager (figura 4.14), care hotrte cnd este trimis mesajul la destinaia final.
Mesajele care se ntorc la aplicaia apelant vor fi prelucrate cnd aplicaia va fi
disponibil. Dezvoltatorii consider ca utilizarea mesajelor MOM este destul de uor de
urmrit i organizat.
Mesajele au o structur (schem) i un coninut (date). Se pot asemna cu o baz
de date cu o singur nregistrare care se deplaseaz ntre aplicaii printr-un mecanism de
schimb de mesaje. Exist dou tipuri de modele MOM: unu la unu i coad de mesaje
(Message Queue - MQ). MQ permite fiecrui program participant s lucreze fr a fi
ntrerupt de nivelul middleware. Deoarece software-ul MQ (seria MQ de la IBM, MSMQ
de la Microsoft) gestioneaz distribuia de mesaje de la un program la altul, coada
manager poate optimiza performana folosind metode de acordare a prioritii.
15
Figura 4.14. Middleware orientat pe mesaje

n vederea ndeprtrii pericolului ca mesajele s se piard atunci cnd are loc o
cdere de sistem, majoritatea modelelor MQ permite ca mesajele s fie declarate drept
persistente sau stocate pe disc la anumite intervale de timp, oferind astfel un nivel de
protecie.
Obiectele distribuite sunt clasificate ca fiind middleware deoarece faciliteaz
comunicarea ntre aplicaii. Obiectele distribuite sunt programe-aplicaii de mici
dimensiuni care folosesc interfee i protocoale standard pentru comunicare. De exemplu,
dac se creeaz un obiect distribuit CORBA care ruleaz pe un sever UNIX i un altul
care ruleaz pe un server NT, folosind un protocol standard de comunicaie, obiectele pot
face interschimb de informaie i funcii (acelai standard CORBA, acelai protocol
IIOP (Internet InterORB Protocol)).
Exist dou tipuri de obiecte distribuite: CORBA i COM (Component Object
Model). CORBA este creat de OMG n 1991 i este mai mult un standard dect o
tehnologie oferind specificaii pentru crearea unui obiect distribuit. COM este creat de
Microsoft i include interfee standard i protocoale de comunicaie.
Middleware-ul orientat pe baza de date se refer la orice middleware care
faciliteaz comunicaia fie cu o baz de date, fie cu o aplicaie, fie ntre mai multe baze
de date. Dezvoltatorii folosesc acest tip de middleware ca pe un mecanism de extragere a
informaiei dintr-o baz de date local sau la distan. De exemplu, pentru a extrage
informaia dintr-o baz de date Oracle, dezvoltatorul trebuie s apeleze un astfel de
middleware astfel nct s poat realiza autentificarea la baza de date, cererea de
informaie i procesarea informaiei care a fost extras din baza de date (4.15).
Middleware-ul orientat pe baza de date lucreaz cu dou tipuri de baze de date:
CLI (Call Level Interface) i middleware nativ pe baza de date.
CLI reprezint API-uri comune, care ofer acces la baze de date folosind o
interfa bine definit. De obicei, CLI lucreaz cu baze de date relaionale. Acesta este i
cazul Open DataBase Connectivity (ODBC) de la Microsoft. ODBC folosete o interfa
pentru a facilita accesul la o baz de date i drivere pentru a gestiona diferenele dintre
bazele de date. De asemenea, ofer acces simultan la baze de date multiple, arhitectura
ODBC presupunnd existena unui driver manager care s faciliteze comunicaia ntre
diferite baze de date.
16
Figura 4.15. Middleware orientat pe baze de date
Java DataBase Connectivity (JDBC) de la JavaSoft este un alt exemplu de CLI.

JDBC este o interfa standard care folosete un singur set de metode Java pentru a
facilita accesul la baze de date multiple. JDBC se aseamn cu ODBC i funcioneaz de
pe orice aplicaie Java: applet, servlet, Java Server Pages (JSP), Enterprise JavaBean
(EJB).
Monitorii TP sunt prima generaie de servere de aplicaii, la fel ca i produsele
middleware de tip tranzacional. Acestea ofer un mecanism pentru a facilita comunicarea
ntre dou sau mai multe aplicaii (figura 4.16), precum i o locaie pentru logica
aplicaiei. Exemple de TP includ Tuxedo de la BEA Systems, MTS de la Microsoft, CICS
de la IBM.
Figura 4.16. Monitor TP
17

Monitorii TP se bazeaz pe tranzacii, vzute ca uniti de lucru cu un nceput i
un final. O tranzacie are doar dou stri: poate sa fie ori finalizat, ori anulat complet.
n acest ultim caz, dac tranzacia a actualizat resurse aflate la distan (baze de date,
cozi), aceste actualizri vor fi anulate de asemenea.
TP asigur dou servicii importante. Pe de o parte, TP ofer servicii care
garanteaz integritatea tranzaciilor (serviciul de tranzacie), iar pe de alt parte, un
monitor TP asigur managementul resurselor i servicii de management pe termen lung
(serviciul de aplicaie). Cele dou servicii sunt ortogonale.
De asemenea, monitorii TP ofer conectori la resurse ca baze de date, alte aplicaii
sau cozi. Aceti conectori necesit o dezvoltare de aplicaie sofisticat pentru a comunica
cu tipurile variate de resurse. Odat conectate, aceste tipuri de resurse sunt integrate n
tranzacii. Ca urmare, aceti conectori pot fi reconstituii dac apare o cdere de sistem.
Serverele de aplicaie definesc segmentul pieei de middleware cu cea mai rapid
evoluie. Cu toate acestea, tehnologia serverelor de aplicaii nu este nou (monitorii TP
pot fi considerai servere de aplicaii datorit caracteristicilor comune). Majoritatea
serverelor de aplicaii sunt middleware Web i proceseaz tranzacii aparinnd
aplicaiilor Web. Noutatea acestor servere de aplicaii este c folosesc limbaje moderne,
cum este Java, n locul celor tradiionale procedurale, cum sunt C sau Cobol (ceea ce se
ntmpl la monitorii TP).
Mai simplu, serverele de aplicaii asigur posibilitatea accesului la alte aplicaii i
fac posibil procesarea i stabilirea resurselor necesare conexiunilor. Aceste resurse
includ baze de date, aplicaii ERP i chiar aplicaii tradiionale de tip mainframe.
Serverele de aplicaii ofer interfeei utilizator mecanisme de dezvoltare. n plus, n cele
mai multe cazuri ofer i mecanisme de amplasare a aplicaiilor pe platforma Web (4.17).
18
Figura 4.17. Arhitectura unui server de aplicaie tipic

Productorii de servere de aplicaii consider c produsele lor au o tehnologie ce
permite rezolvarea problemelor de integrare a aplicaiilor. Ca urmare, serverele de
aplicaie, ca i monitorii TP, joac un rol important n domeniul integrrii aplicaiilor.
Muli dintre productori ncorporeaz tehnologii de gestiune a mesajelor, transformare i
rutere inteligente, servicii care sunt native serverelor de integrare.
Serverele de integrare reprezint partea de vrf a tehnologiei middleware pentru
integrarea aplicaiilor sau cel puin potenialul acesteia. Serverele de integrare pot facilita
schimbul de informaie ntre dou sau mai multe aplicaii surs sau destinaie i pot face
diferena ntre semanticele aplicaiei i platforme. Ca urmare, aceast tehnologie se
potrivete perfect cu integrarea aplicaiilor.
19
Figura 4.18. Servere de integrare

Serverele de integrare pot aprea n multe aplicaii folosind reguli comune i
motoare de rutere. Ele pot transforma schema i coninutul informaiei pe durata
transferului ntre aplicaii i baze de date.
Serverele de integrare sunt servere care gestioneaz mesaje ntre dou sau mai
multe aplicaii surs sau destinaie. n plus, aceste servere transform schemele de mesaje
i modific coninutul mesajelor. Serverele de integrare pot avea ntr-adevr funcii
adiionale, incluznd un motor i o interfa de integrare a proceselor, precum i un
mecanism de management.
Importana serverelor de aplicaii este stabilit n funcie de poziia ocupat de
acestea n cadrul companiei. n general, dup cum este evideniat i n figura 4.18,
serverele de integrare nu sunt o tehnologie de dezvoltare a aplicaiilor ci mai degrab una
care permite comunicarea ntre mai multe aplicaii, fr s presupun existena unui
schimb de informaii despre natura aplicaiilor ntre care se face schimbul de date. Pe
scurt, serverele de integrare gestioneaz informaia ntre baze de date i aplicaii.
4.5.2. Java
Java este un limbaj de programare de nivel nalt, orientat-obiect, care a fost
proiectat iniial pentru realizarea de aplicaii pentru Internet. Acesta este utilizat n
prezent cu succes i pentru programarea aplicaiilor destinate Intranet-urilor. n acest
sens, multe firme recurg la limbajul Java n procesul de informatizare ntruct ofer un
20

foarte bun suport pentru tehnologiile de vrf i, nu n ultimul rnd, pentru faptul c este
gratuit i n mod continuu mbogit i mbuntit.
Write once, run anywhere (WORA) sau, uneori, Write once, run everywhere
(WORE), este sloganul creat de Sun Microsystems pentru a ilustra beneficiile aduse de
limbajul Java prin rularea pe orice tip de platform. La modul ideal, aceasta nseamn c
un program Java poate fi dezvoltat pe orice platform, compilat n formatul standard
bytecode i apoi rulat de pe orice sistem care are n prealabil instalat maina virtual
Java (Java Virtual Machine - JVM).
Legtura care s-a creat ntre Internet i Java a condus la situaia n care majoritatea
companiilor care dezvolt aplicaii pentru Internet s considere Java ca limbaj de
implementare, n acest moment Java nefiind un limbaj de programare obinuit, ci
desemnnd un ansamblu de tehnologii care permit trecerea de la o abordare a aplicaiilor
desk-centric, la network-centric, realizndu-se platforme de calcul deschise i universal
accesibile din Internet.
Prin urmare, trecerea conceptului Java din sfera limbajului de programare n cea a
tehnologiilor i a platformelor de tehnologii nu devine improprie. Tehnologia Java st la
baza celor mai performante soluii de dezvoltare a aplicaiilor de ntreprindere i
controleaz cu adevrat funcionalitatea unei reele prin faptul c este n acelai timp un
limbaj de programare precum i o selecie de platforme specializate. Prin aceste
caracteristici, Java standardizeaz dezvoltarea i implementarea unor aplicaii securizate,
portabile, stabile i scalabile.
Caracteristicile limbajului Java
Caracteristicile limbajului Java sunt numeroase, drept pentru care vor fi prezentate
cele mai semnificative, pornind de la articolul [STAN01]:
uor de utilizat att pentru avansai ct si pentru nceptori;
simplu fiind ndeprtate aspectele derutante din C++, cum ar fi
suprancrcarea operatorilor i motenirea multipl; a fost introdus un
colector automat de deeuri care rezolv problema dealocrii memoriei n
mod uniform, fr intervenia programatorului;
independent de platform compilatorul Java furnizeaz o secven de
instruciuni ale unei maini virtuale Java, iar execuia aplicaiilor este
interpretat;
viteza sczut de execuie caracteristic a limbajelor interpretate fa de
cele compilate. Pentru creterea acestei viteze se poate cere mediului de
execuie Java s genereze automat, plecnd de la codul mainii virtuale, un
executabil nativ platformei respective. De obicei, n Java se compileaz doar
prile mari consumatoare de timp, celelalte fiind interpretate;
interpretorul Java este gndit pentru a lucra pe maini mici, iar mpreun
cu bibliotecile standard s nu depeasc 300KB;
orientat-obiect deoarece se pot crea clase de obiecte i instane ale
acestora, se pot ncapsula informaii, se pot moteni variabile i metode de
la o clas la alta. Suplinete motenirea multipl (care lipsete) cu interfaa,
21

care permite definirea unui anumit comportament pentru a crea o clas de
obiecte, altul dect cel standard. n Java orice element este obiect, cu
excepia datelor primare i lipsesc funciile i variabilele globale;
distribuit are implementate biblioteci pentru lucrul n reeaua TCP/IP,
suport URL i ncrcarea resurselor din reea; aplicaiile Java pot accesa
foarte uor reeaua, prin apelurile ctre un set standard de clase;
robust legarea funciilor se face n timpul execuiei, iar informaiile de
compilare sunt disponibile pn n momentul rulrii aplicaiei. Astfel
sistemul poate determina n orice moment neconcordana dintre tipul referit
la compilare i cel referit n timpul execuiei, evitndu-se intruziunile n
sistem prin intermediul referinelor falsificate. De asemenea, pointerii
lipsesc (mpreun cu aritmetica lor), eliminnd nc o surs principal de
erori, iar eliberarea memoriei ocupate de obiecte i tablouri se face automat,
evitndu-se ncercrile de eliberare multipl a zonei de memorie;
securitate ridicat prin verificarea codului la fiecare ncrcare, prin
mecanisme de Cyclic Redundancy Check (CRC) i prin verificarea
operaiilor disponibile pentru fiecare set de obiecte, robustee, ncorporarea
proteciei obiectelor la citire/scriere. Verificarea se face n timpul execuiei,
mediul de execuie Java putnd fi configurat pentru a proteja reeaua local,
fiierele i celelalte resurse ale calculatorului pe care ruleaz aplicaia Java;
multithreading suport nativ pentru aplicaii care lucreaz cu mai multe fire
de execuie, inclusiv primitive de sincronizare ntre firele de execuie,
independent de platform;
dinamic bibliotecile de clase n Java pot fi reutilizate cu mare uurin,
variabilele sunt legate doar n faza de execuie, rezolvnd problema
fragilitii superclasei din C++, regsirea variabilelor se face prin nume i
nu prin deplasament fix; se elimin necesitatea actualizrii aplicaiilor,
datorat apariiei unei noi versiuni de bibliotec.
Java furnizeaz un cadru de lucru curat, format din mai multe straturi diferite care
creeaz mediul de execuie Java. Aceste straturi sunt: limbajul de programare, biblioteca
standard API, compilatorul Java, codul specific (bytecode), mecanismul pentru ncrcarea
dinamic i verificarea bibliotecilor, automatul de colectare a deeurilor (garbage
collector), maina virtual universal pentru executarea bytecode-ului - Java Virtual
Machine (JVM).
4.5.2.1. Platforme Java

Limbajul Java poate fi considerat unul din cele mai populare i mai versatile
limbaje de programare, mai ales dac ne gndim la rolul lui n cadrul spaiului World
Wide Web. Rezultat al distilrii celor mai bune practici n proiectarea de limbaje de
programare orientate-obiect, Java a adus cu sine i o libertate de necontestat n ceea ce
privete alegerea elementelor de design, implementare i exploatare a aplicaiilor
concepute n acest limbaj.
22

Platformele Java se pot clasifica n: Java 2 Micro Edition (J2ME), Java 2 Standard
Edition (J2SE) i Java 2 Enterprise Edition (J2EE). Acestea se utilizeaz dup cum
urmeaz (figura 4.19):
J2ME - mediul pentru dezvoltarea aplicaiilor Java pentru micro-dipozitive;
J2SE - mediul standard pentru dezvoltarea aplicaiilor Java. Sunt disponibile
pachetele de baz ale limbajului Java, necesare realizrii aplicaiilor desktop;
J2EE - mediul Java pentru dezvoltarea aplicaiilor de ntreprindere. Se ofer un
foarte bun suport pentru utilizarea serverelor de aplicaii.
Figura 4.19. Platforme Java

Pentru toate tipurile de aplicaii se remarc avantajul tehnologiei Java: codul se
scrie o singur dat dar ruleaz pe orice sistem - Write once, run anywhere.
Java 2 Micro Edition (J2ME) este un mediu Java puternic optimizat ce intete
spre o larg varietate de produse de larg consum, incluznd pagere, telefoane celulare,
agende electronice de buzunar i sisteme de navigaie pentru automobile. O aplicaie
scris n tehnologia Java 2 Micro Edition poate fi folosit pe orice echipament HandHeld
(PDA) sau pe orice telefon mobil cu suport Java. Totodat, ediia J2ME definete i o
implementare complet nou a mainii virtuale Java optimizat pentru dispozitivele
mobile (Kilobyte Virtual Machine - KVM).
Java 2 Enterprise Edition (J2EE) este o platform Java creat de Sun
Microsystems, utilizat pentru a dezvolta, utiliza i administra aplicaiile multi-nivel
(multi-tier). Aplicaiile J2EE sunt aplicaii dezvoltate pe 3 straturi: aplicaie-client, server
de aplicaie i server de baz de date. Noutatea este apariia serverului de aplicaie pe care
sunt EJB-urile, acestea fiind programe scrise n Java care reprezint aproximativ 60% din
aplicaie.
Fiind dezvoltat n Java, J2EE este o platform independent de sistemul de
operare, avnd cerine hardware minime. Un avantaj important al J2EE se refer la faptul
c dezvoltarea aplicaiilor este mult simplificat, iar necesitatea programrii efective prin
23

scrierea de cod este redus, ntruct sunt disponibile module de componente
standardizate, reutilizabile.
Aplicaiile Internet J2EE se pot baza att pe servere open source (Apache Tomcat,
Jetty, JBoss) ct i pe servere performante cu renume (IBM WebSphere Application
Server, Bea WebLogic Server, Oracle Application Server). Aceast caracteristic aduce
avantajul unui buget flexibil alocat aplicaiei respective.
n cazul sistemelor desktop, Java 2 Standard Edition (J2SE), aceeai aplicaie
poate rula pe orice sistem de operare, att Windows/Machintosh, ct i variante
Unix/Linux.
4.5.2.2. Java 2 Enterprise Edition - J2EE

J2EE este un standard iniiat de ctre Sun Microsystems i susinut de parteneri
importani, dintre care cel care a investit cel mai mult este IBM. Unul dintre obiectivele
crerii limbajului de programare Java a fost independena de platform, deziderat realizat
prin crearea de JVM specifice sistemelor de operare. Odat cu dezvoltarea tehnologiei
Internet a aprut necesitatea redrii de coninut dinamic n paginile Web. Rspunsul
tehnologiei Sun, orientat Java, la aceast nou provocare a fost apariia tehnologiilor
Servlet i Java Server Pages (JSP). n paralel a aprut i tehnologia Entrepise JavaBeans
(EJB), iar mai trziu, ncepnd din anul 2004, Java Server Faces (JSF).
Standardul J2EE st la baza celor mai robuste platforme pentru dezvoltarea de
aplicaii de ntreprindere. J2EE reprezint un set de specificaii de construire a unor
aplicaii pe niveluri multiple, folosind limbajul de programare Java. n ultimii ani,
experiena acumulat de dezvoltatori i apariia de noi standarde au contribuit la continua
mbuntire a platformei J2EE.
Norma J2EE a aprut ca rspuns la nevoia de a extinde ideea de portabilitate de la
nivelul limbajului (Java) la nivelul serverelor de aplicaie. n afar de portabilitate, J2EE
prezint o serie de alte avantaje, cum ar fi dezvoltarea orientat pe componente, separarea
containerelor etc.
Securitatea este ncorporat n tehnologia J2EE, serverul de baze de date fiind
accesat numai prin intermediul serverului de aplicaie, ceea ce face ca utilizatorul s nu
aib acces direct la baza de date, ci numai prin aplicaie.
Securizarea unei aplicaii de ntreprindere conform normei J2EE se face pe baza
unor standarde, n cadrul crora se pune accent pe separarea autentificrii de autorizare.
Securizarea se poate face pe dou niveluri: declarativ i aplicativ [BRC 05].
n cadrul implementrii securitii declarative a unei aplicaii J2EE, prima etap
este autentificarea n care utilizatorul furnizeaz un nume de utilizator i o parol pentru a
i se valida identitatea. Securizarea declarativ mpiedic sau acord accesul utilizatorilor
asupra resurselor Web ale aplicaiei. Pentru a avea o aplicaie corect din punct de vedere
funcional, acest lucru nu este suficient. Astfel, dac un utilizator nu are acces la o pagin,
butonul care acceseaz pagina respectiv trebuie s nu fie vizibil pentru utilizatorul n
cauz. Acest lucru este realizat prin implementarea securitii aplicative, prin API-urile
24

suportate de ctre norma J2EE i care permit testarea rolului unui utilizator autentificat.
Important este de reinut faptul c odat ce utilizatorul s-a autentificat pe aplicaie nu se
mai testeaz asupra ID-ului su ci asupra apartenenei sale la un rol sau altul. Securitatea
aplicativ ntregete astfel ansamblul de faciliti puse la dispoziia dezvoltatorului de
ctre implementrile normei J2EE pentru o gestiune complet a securitii unei aplicaii.
Implementarea celor mai bune practici implic n mod uzual adugarea a
numeroase noi coduri, ceea ce poate constitui un obstacol pentru cei care i dezvolt
primele aplicaii J2EE. Modalitatea de a elimina aceste obstacole este folosirea unui
cadru de lucru ce abstractizeaz elementele de complexitate ale platformei J2EE i pune
n valoare beneficiile acestui mediu. Un astfel de mediu de dezvoltare este oferit de
Oracle Application Development Framework, inclus n produsul Oracle JDeveloper 10g.
Nucleul J2EE include: Java Server Pages (JSP), Servlets, Enterprise JavaBeans
(EJB) i servicii Web, arhitectura platformei fiind evideniat n figura 4.20:
Figura 4.20. Arhitectura J2EE

4.5.2.3. JAVA SERVER PAGES (JSP)
Tehnologia Java Server Pages (JSP) este cea mai popular metod de a crea
interfee Web pentru aplicaiile care ruleaz pe platforma Java. Ea se bazeaz pe
tehnologia numit Java Servlets fiind, de fapt, o completarea a acesteia n ideea crerii ct
mai facile a paginilor Web dinamice.
Tehnologia JSP a aprut pentru a acorda dinamicitate paginilor statice HTML i
pentru a evita scrierea de cod HTML n servlet-uri. Exist la ora actual o multitudine de
medii de programare care pot gestiona vizual compoziia unei pagini JSP, obinnd
ctiguri foarte importante n productivitate fa de generarea dinamic a codului HTML
n cadrul unui servlet.
Punctul central al tehnologiei o reprezint aa-numitele pagini JSP care sunt,
practic, fiiere text care combin descrieri HTML cu cod Java. Paginile JSP sunt
25

gestionate i accesibile prin intermediul unui server de aplicaii. Acesta primete cereri
venite prin HTTP de la un browser Web. Dac o cerere refer o pagin JSP, serverul
prelucreaz local pagina respectiv i, n funcie de coninutul acesteia, genereaz
dinamic o pagin HTML pe care o trimite, ca rspuns, browser-ului. Este important de
reinut faptul c toate prelucrrile legate de paginile JSP se fac pe partea de server,
acestea nefiind niciodat transmise n forma original ctre client. n plus, trebuie reinut
faptul c serverul de aplicaii include i o main virtual Java n care ruleaz att codul
Java ntlnit n paginile JSP ct i obiectele instaniate de acesta.
Paginile JSP prezint avantaje fa de servlet-uri deoarece permit separarea
coninutului static HTML al paginii de coninutul generat dinamic, iar scrierea
coninutului HTML direct (nu prin intermediul operaiilor de print, ca n servlet) este
mult mai simpl i mai intuitiv. Codul Java existent se convertete ntr-un servlet care
construiete partea dinamic de rspuns i aceast parte se combin cu partea static din
pagina JSP pentru a forma pagina HTML de rspuns ctre client.
Caracteristicile principale ale tehnologiei JSP, evideniate i n lucrarea [VELI03]
sunt:
poate funciona pe o multitudine de servere i este independent de
platforma pe care ruleaz, ntruct scripturile JSP au la baz limbajul Java;
separ logica aplicaiei (construit cu alte tipuri de tehnologii - servlet,
JavaBeans etc.) de interfaa cu utilizatorul (aspectul paginilor Web);
permite reutilizarea unor componente generate cu alte tehnologii att
independent ct i n cadrul unor interfee de dezvoltare a paginilor Web;
pagina JSP se interpune ntre browser-ul clientului i componentele pentru
logica aplicaiei (realizate n JavaBeans, CORBA, JDBC etc.) care
acceseaz o baz de date;
tehnologia JSP se poate utiliza n aplicaii tip multi-nivel (multi-tier);
pagin JSP poate indica modul de manipulare a unor evenimente;
execuia unei pagini JSP este realizat de ctre motorul JSP instalat pe un
server de Web, care proceseaz pagina i returneaz o alta n format
standard HTML/XML;
implementarea tehnologiei JSP se face n dou etape: traducerea, care se
efectueaz o singur dat i are ca efect generarea unui servlet i procesarea
fiecrei cereri n parte de ctre acesta;
pagin JSP poate conine urmtoarele elemente: marcatori HTML, marcatori
de date, marcatori JSP, HTML predefinit, cod Java etc.
4.5.2.4. SERVLET-URI
Un servlet este o clas Java care prelucreaz cererile clienilor i construiete
dinamic pagina HTML de rspuns. Servlet-urile sunt componente ale aplicaiilor server,
independente de platform, care extind dinamic serverele care au suport Java integrat. Ele
sunt independente i de protocol, asigurnd un cadru general pentru servicii pe baza
modelului cerere-rspuns. Acest binecunoscut model este des folosit la programarea
sistemelor distribuite, ncepnd cu apeluri de proceduri la distan i terminnd cu
protocolul HTTP pentru cereri ctre servere Web. Cu ajutorul servlet-urilor, aadar, se
26

extinde funcionalitatea unei aplicaii de tip server informaional (nu neaprat server
HTTP), un prim domeniu de aplicare fiind, bineneles, extinderea serverelor Web.
Servlet-urile pot fi considerate echivalentul applet-urilor pe partea de server, ele
fiind asemntoare din multe puncte de vedere. ns, principala caracteristic a appleturilor, interfaa grafic utilizator, lipsete din servlet-uri, ele neavnd nevoie de aa ceva
din moment ce ruleaz n interiorul serverelor. n rest, ele se aseamn mult, un servlet
fiind i el o component de aplicaie, scris n Java, care poate fi transferat la un sistem
care are nevoie de ea.
Servlet-urile reprezint o alternativ oferit de Java pentru rezolvarea problemelor
legate de timp aprute odat cu programarea Common Gateway Interface - CGI. Acestea
faciliteaz dezvoltarea unor module care permit servere-lor Web s se conecteze i s
prelucreze informaia n mod dinamic, adic s ruleze aplicaii Web i nu doar s
transfere documente statice. Soluia Java, menine executabilul persistent pe server, ntre
cererile clienilor, spre deosebire de CGI unde fiecare cerere client lanseaz un nou
proces pe server (ceea ce duce rapid la epuizarea resurselor serverului Web, adic la
creterea timpului).
Ciclul de via al servlet-urilor este o proprietate specific a acestora. Servlet-urile
se ncarc n mod dinamic, serverele oferind faciliti de administrare a ncrcrii i a
iniializrii acestora. Exist i posibilitatea, deloc de neglijat, de a specifica ncrcarea
anumitor servlet-uri la lansarea n execuie a serverului. Odat ncrcate, acestea devin
parte integrant a serverului. Procesul de ncrcare este transparent pentru utilizator,
acesta trebuind s specifice doar locaia servlet-ului (local sau la distan), numele clasei
ce conine servlet-ul i numele sub care acesta va fi cunoscut de ctre server (alias).
Caracteristicile principale ale servlet-urilor sunt evideniate n [VELI03] i se
refer la urmtoarele:
clasele i metodele necesare pentru a defini i utiliza un servlet sunt ncapsulate n
pachete Java;
tehnologia se utilizeaz pentru a dezvolta soluii bazate pe Web: accesul securizat la
pagini Web, asigurarea interaciunii cu bazele de date, generarea dinamic a
paginilor HTML, manipularea informaiilor care identific unic un client pe
parcursul uneia sau a mai multor sesiuni;
se poate crea cte un servlet pentru fiecare funcie din paginile Web (conectare,
nregistrare, actualizare etc.) sau unul singur care s gestioneze toate tranzaciile din
paginile Web respective, n mod dinamic;
tehnologia este o soluie optim pentru aplicaiile care utilizeaz intensiv bazele de
date (serverul se ocup de accesul la date iar clienii formuleaz cererile de
regsire). Partea de cod se scrie o singur dat i se stocheaz rezident, o singur
dat, pe server. La actualizarea codului se va face o singur nlocuire, pe server, i
nu la fiecare utilizator n parte;
la iniiere se pot deschide conexiuni la baze de date care devin astfel rezidente ntre
apelurile clienilor;
comunicarea client-server se realizeaz n mai muli pai, astfel: clientul formuleaz
i trimite ctre server o cerere Web; serverul o direcioneaz ctre servlet pentru a fi
procesat (ceea ce implic de multe ori i accesul la o baz de date); rspunsul (sub
form de pagini HTML, imagini etc.) este returnat serverului i apoi clientului care
a formulat cererea;
27

un servlet poate fi apelat dintr-o pagin HTML sau dintr-un applet;
principalele situaii de utilizare a tehnologiei se refer la generarea paginilor Web
dinamice i la realizarea aplicaiilor multi-nivel (multi-tier) cu JDBC. n acest ultim
caz, servlet-ul poate accesa o varietate de baze de date prin intermediul JDBC i
poate realiza, parial sau total, interfaa cu utilizatorul prin pagini Web dinamice.
Paginile JSP i componentele servlet sunt funcional interschimbabile, dar unele
aspecte de programare se rezolv mai simplu ntr-una sau alta din tehnologii. n cazul n
care cererea clientului necesit includerea unei mari pri de cod HTML n pagina de
rspuns, atunci paginile JSP sunt mai simplu de folosit. n schimb, dac respectiva cerere
necesit multiple operaii de prelucrare a datelor, este indicat folosirea componentelor
servlet.
4.5.2.5. ENTERPRISE JAVA BEANS (EJB)
JavaBeans este un model de dezvoltare a componentelor software care permite
componentelor scrise n Java, numite beans, s comunice ntre ele. Aceste componente
pot fi utilizate ntr-un editor vizual sau pot fi nglobate n interiorul unor aplicaii. Un
bean este n principiu o clasa Java care respect anumite convenii de construcie.
Spre deosebire de componentele JavaBeans obinuite, EJB sunt componente
industriale care cuprind logica reutilizabil de afaceri i acces la resursele externe, cum ar
fi bazele de date relaionale ale unei companii.
Enterprise JavaBeans (EJB) este un standard pentru arhitectura componentelor la
nivelul serverului. De fapt, EJB-urile sunt programe realizate n Java care reprezint
aproximativ 60% dintr-o aplicaie J2EE. Modificarea sau introducerea unei noi funcii se
rezolv simplu prin modificarea unui EJB sau prin introducerea unui EJB nou la nivelul
serverului de aplicaie, ntr-un timp redus. Actualizarea aplicaiei se realizeaz ntr-un
singur loc pe serverul de aplicaie i nu pe staiile de lucru.
Primul dintre scopurile EJB este faptul c permite programatorilor s se
concentreze asupra logicii afacerilor fr a mai fi preocupai de detalii de nivel inferior,
cum ar fi ciclul de via, necesitile tranzacionale de securitate etc. Aceste cerine sunt
gestionate automat ntr-un mod care permite crearea componentelor ce pot fi transferate
de pe un server de aplicaie pe altul, acesta fiind un alt scop al arhitecturii pe niveluri.
n plus, EJB ine ntotdeauna cont de faptul c valoarea unei componente este
deseori msurat n posibilitatea de a o reutiliza.
4.5.2.6. JAVA SERVER FACES (JSF)
Java Server Faces (JSF) este o tehnologie nou care permite construirea
interfeelor grafice i controlul acestora pe partea de server. Dei interfaa poate fi
generat i prin servlet-uri sau prin pagini JSP, JSF ofer posibilitatea de a defini
elemente mai complexe i de a reutiliza componentele existente, acestea fiind deja testate
i uor configurabile.
Tehnologia JSF include dou componente majore [NET02]:
28

un set de API-uri pentru reprezentarea componentelor pentru interfaa cu
utilizatorul, controlul strilor, lucrul cu evenimente, validarea datelor de
intrare i definirea modului de navigare ntre pagini;
o bibliotec de marcatori (tag-uri) JSP pentru includerea elementelor de
interfa din JSF n cadrul paginilor JSP;
Principiul de funcionare a JSF se bazeaz pe arhitectura Model View Controller
(MVC2) care propune separarea logicii aplicaiei de partea de prezentare. Conform
SunMicrosystems, o aplicaie interactiv poate fi organizat n trei module complet
separate unele de altele: primul pentru modelul aplicaiei (reprezentarea datelor i logica
aplicaiei), al doilea pentru prezentarea datelor ntr-o form ct mai atractiv
utilizatorilor, prin intermediul interfeelor grafice, iar al treilea modul, numit controller,
pentru gestionarea cererilor, repartizarea lor prilor corespunztoare din modelul
aplicaiei i identificarea resursei care urmeaz s fie afiat. Prin urmare, n modelul
MVC2 paginile JSP sunt izolate unele de altele i au unicul rol de a asigura prezentarea
datelor, ntruct logica aplicaiei i gestionarea cererilor sunt tratate separat.
O aplicaie Web construit prin utilizarea tehnologiei JSF va conine conform
[TANA05]:
componente JavaBeans care vor conine datele i funcionalitile aplicaiei;
pagini Java Server Pages responsabile de modul de prezentare a datelor;
biblioteci de marcatori (tag-uri) pentru generarea componentelor interfeei cu
utilizatorul, precum i pentru evenimente i validri ale datelor de intrare;
componente de interfa reprezentate de obiecte cu stri pe partea de server;
validatori ai datelor la nivel de prezentare, nainte de actualizarea modelului
memorat pe server, elemente de tratare a evenimentelor i reguli de navigare
ntre pagini;
fiiere de configurare a aplicaiei (fiiere XML n cadrul crora sunt definite
relaiile i interaciunile dintre componentele JSF) i a resurselor acesteia.
4.5.2.7. JAVA versus .NET

Att Java ct i .NET cumuleaz un numr semnificativ de tehnologii. Tocmai din
acest motiv este destul de greu de fcut o comparaie a performanelor. ns, privit din alt
unghi, trebuie remarcat c sursele Java i .NET sunt ambele interpretate iar n construcia
mainii virtuale .NET s-a fcut uz de tehnologiile dezvoltate n cadrul mainii virtuale
Java (cum e de exemplu tehnologia JIT). .NET a fost dezvoltat i optimizat pentru
Windows, ceea ce poate nclina balana n favoarea acestei platforme. ns Java este o
tehnologie mult mai veche iar mainile virtuale Java sunt destul de mult optimizate. De
aceea n general performanele .NET i Java se consider comparabile.
Marele avantaj al Java este datorat independenei de platform, aplicaiile Java
putnd fi rulate pe orice sistem de operare care are instalat o main virtual Java. Acest
argument nu poate fi dect n favoarea Java, atta vreme ct Linux devine tot mai
popular, iar sistemul de operare al celor de la Apple, OSX, suport i el Java. n plus, nu
trebuie exclus rolul pe care l are n dezvoltarea continu a platformei aa-numita
29

comunitate Java, compus din oameni pasionai care au studiat ndelung limbajul i au
reuit s impun diferite standarde Java: tehnologiile de programare pe server i unele
aplicaii desktop.
Microsoft este nc sistemul de operare folosit cu precdere de microcalculatoare.
Se afirm chiar c, pn i cei care nu sunt fani mptimii ai Microsoft, utilizeaz totui
tehnologiile lor. Iar ct vreme Microsoft domin ar fi ilogic s nu se realizeze aplicaii
care s se poat integra perfect n mediul Windows. Principalul limbaj utilizat pentru
dezvoltare de aplicaii Windows al .NET este indiscutabil C#, cel despre care se spune c
nu mprumut numai puterea C-ului, ci i structura bibliotecilor Java.
Se tie c C# vine de la Microsoft ca un echivalent la Java i cu un suport mai
puternic (dect celelalte limbaje) pentru mult mediatizata platform .NET. ns, dac C#
(sau mai bine zis .NET) nu va fi independent de platform (ceea ce este mai mult ca
sigur) i att timp ct vor exista sisteme de operare concurente - pentru care exist Java,
acesta din urm nu are cum s devin nvechit ca limbaj de programare sau ca platform
de dezvoltare. Ideea anterioar este ntrit lund n considerare faptul c Java este un
produs gratuit, este sprijinit de mari nume din industria IT (ca IBM, Borland etc.) i deja
exist un numr foarte mare de programatori care sunt fascinai de acest limbaj.
Un alt concurent destul de puternic pentru C# (i chiar i pentru Java) ar putea
deveni Delphi care are componente de .NET, are destul de muli "adepi" i, ca i C# i
Java, poate fi ncadrat n categoria Rapid Application Developement (dezvoltare rapid
de aplicaii).
Codul generat de oricare dintre platformele .NET i Java este interpretat, ns
performanele nu se ridic la nivelul codului nativ generat, spre exemplu, de
compilatoarele de C/C++. Cu toate acestea, aplicaiile scrise pentru platformele
interpretate ctig teren n faa celor native din alte puncte de vedere: productivitate n
dezvoltare, transparen a platformei, un nivel sporit de reutilizare a codului, mentenan
semnificativ mbuntit, un mai bun management al complexitii.
.NET Framework prezint o serie de avantaje: suport limbaje gen C/C++, Perl,
VB, Python etc. Spre deosebire de acesta, platforma Java suport doar limbajul Java (n
spe mediile de dezvoltare comerciale i nu limbajele de interes academic).
Exist de asemenea avantaje de performan ale platformei .NET fa de Java
(legat de viteza de execuie a codului .NET, foarte apropiat de performana codului
nativ x86), avantaje innd de suportul nativ pentru servicii Web sau avantajul integrrii
n sistemul de operare.
.NET i propune rezolvarea problemei interoperabilitii n urmtorul mod: cum
se poate realiza comunicarea a dou aplicaii X i Y extrem de diferite, scrise n limbaje
distincte? Rspunsul .NET este: prin componentizare, la nivel de Intranet sau prin servicii
Web (XML/SOAP/WSDL) la nivel de Internet. .NET are suport foarte bun pentru
reutilizarea codului existent fr a fi necesar rescrierea acestuia n Java.
Abordarea Java, n schimb, este extrem de diferit, ncercnd s promoveze
portabilitatea ca soluie universal, n locul interoperabilitii. Cu alte cuvinte, n loc s
facem aplicaiile X i Y de mai sus s vorbeasc ntre ele, mai bine rescriem totul n Java.
Un avantaj Java, ns, ar fi suportul pentru multithreading, deoarece este
important s poi scrie o aplicaie multithreading care s mearg perfect pe orice sistem
de operare suportat.
30

Problema comunicrii dintre aplicaii n Java este rezolvat de ctre JVM (Java
Virtual Machine), considerat o soluie impresionant. Singura problem ar fi cantitatea
de memorie consumat, deoarece pentru fiecare aplicaie se iniiaz o JVM nou. O
soluie pe care SUN o tot promite nc de prin anii 1996 este Multi-tasking Virtual
Machine - MVM.
Se remarc, de asemenea, faptul c tehnologia Java este utilizat cu predilecie n
cazul dezvoltrii aplicaiilor de ntreprindere cu baze de date, care utilizeaz Oracle sau
IBM DB2, n timp ce .NET este utilizat n special n dezvoltarea aplicaiilor care
utilizeaz baze de date SQL Server (tot de la Microsoft).
Prin urmare, dei limbajele sunt foarte asemntoare (C# / Java), iar frameworkurile, dei diferite pe alocuri, se aseamn foarte mult, se pot desprinde anumite
concluzii, formulate n detaliu n articolul [EFTI02].
n realizarea comparaiei platformelor s-a luat n calcul faptul c diversele
variante de implementare a specificaiei J2EE duc la diverse caliti ale produselor finale,
care variaz ntre Java best (cea mai bun soluie) i Java worst (cea mai slab
soluie).
Figura 4.21. Java vs. .NET

innd cont de aceste considerente, analiza celor dou platforme a evideniat
urmtoarele (figura 4.21):
din punctul de vedere al independenei fa de productor, Java domin,
ntruct funcioneaz pe mai multe platforme i ruleaz la fel de bine pe
Linux/Solaris/AIX/macosx/Windows, n vreme ce .NET funcioneaz numai
pe sistem de operare Windows (se remarc, ns, buna integrare cu acesta);
n privina abilitii productorului i a posibilitii de dezvoltare ulterioar a
platformelor pe piaa IT, cele dou produse au aproximativ aceeai evoluie.
La Java, ns, poate fi remarcat strategia de supravieuire: grupul de
productori de soluii Java i-a mprit capacitatea de producie, orice
produs Java fiind dezvoltat n paralel de mai muli productori. Astfel,
31

existena i dezvoltarea viitoare a platformei nu depinde n mod necesar de
existena companiei Sun, n cazul insolvabilitii acesteia, rolul su putnd fi
transferat altei companii;
costurile cu licenele i cu ntreinerea sunt un factor ce nu trebuie neglijat n
luarea deciziei utilizrii uneia dintre cele dou tehnologii. Costurile
soluiilor J2EE ale unor furnizori ca IBM sau BEA sunt transferate deja n
categoria mainframe-urilor. Nu trebuie ns uitate ofertele open-source
distribuite gratuit. Struts, JUnit, Eclipse, iar mai nou i Oracle JDeveloper
sunt doar cteva nume de framework-uri, module sau instrumente de
dezvoltare gratuite care nu mai au nevoie de nici o recomandare
suplimentar n lumea programatorilor i a inginerilor de software.
Comparativ cu cele dou variante de implementare Java - Java best i
Java worst, pe scara preurilor, Microsoft .NET este aezat undeva pe la
mijloc;
eficiena n utilizare se poate msura att din punctul de vedere al
automatizrii procesului de dezvoltare, ct i din cel al existenei uneltelor
de depanare sau al celor de control al versiunilor. Din acest punct de vedere,
pentru unele dintre implementrile J2EE performanele celor dou platforme
sunt aproximativ echivalente;
portabilitatea este unul dintre avantajele certe ale platformei Java, aplicaiile
putnd fi rulate pe orice sistem care are instalat o main virtual Java (Java
Virtual Machine - JVM), care este ns mare consumatoare de memorie.
Portabilitatea n Java este asigurat de Java Runtime Environment (JRE), iar
serverul de aplicaii i alte produse middleware pot fi programate n funcie
de sistemul de operare. Spre deosebire de Java, .NET nu prezint
portabilitate, dar ncearc s remedieze problema prin intermediul serviciilor
Web, rspunztoare de realizarea interoperabilitii dintre aplicaii;
dincolo de criteriile de performan, trebuie s se in cont de eficiena
platformei i de productivitatea furnizat n dezvoltarea aplicaiilor. Dac se
msoar productivitatea numai pe baza numrului de linii de cod, .NET
prezint avantaje clare fa de Java. Crucial este ns ct dintre aceste linii
de cod trebuie sa fie scrise manual de ctre dezvoltatorul de aplicaii. Aici
intervine, ns, att procesul automatizat de dezvoltare, ct i inteligena
mediului de dezvoltare software;
studiind aspectele legate de maturitatea i stabilitatea platformei, se constat
c, de-a lungul timpului, produsele J2EE au cptat un grad mare de
maturizare, datorat i popularitii obinute de-a lungul timpului de
tehnologia Java.
32
STUDIUL TEHNOLOGIILOR INFORMATICE DE INTEGRARE A

APLICAIILOR..................................................................................................................1
4.3. Standarde utilizate la integrarea aplicaiilor.................................................1
4.3.1. Business Process Execution Language - BPEL.....................................1
4.4. Arhitecturi utilizate n integrarea aplicaiilor................................................7
4.4.1. Arhitectura orientat pe servicii.............................................................7
4.4.2. Oracle Application Integration Architecture........................................11
4.4.3. Enterprise Services Architecture..........................................................11
4.5. Tehnologii informatice de integrare a aplicaiilor.......................................12
4.5.1. Tehnologia middleware........................................................................12
4.5.2. Java......................................................................................................20
33

Curs 8

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Curs 8

Încărcat de

Drepturi de autor:

Formate disponibile

Cursul 8 Integrarea sistemelor informatice

STUDIUL TEHNOLOGIILOR INFORMATICE DE

Figura 4.9. Integrarea cu partenerii de afaceri

Cursul 8 Integrarea sistemelor informatice

Figura 4.10. Evoluia BPEL

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

4.4. Arhitecturi utilizate n integrarea aplicaiilor

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

4.5. Tehnologii informatice de integrare a aplicaiilor

Cursul 8 Integrarea sistemelor informatice

Figura 4.11. Configuraia unu la unu

Cursul 8 Integrarea sistemelor informatice

Figura 4.12. Configuraia muli la muli

4.5.1.2. Tipuri de middleware

Cursul 8 Integrarea sistemelor informatice

Figura 4.13. Funcionarea RPC

Cursul 8 Integrarea sistemelor informatice

Figura 4.14. Middleware orientat pe mesaje

Cursul 8 Integrarea sistemelor informatice

Figura 4.15. Middleware orientat pe baze de date

Java DataBase Connectivity (JDBC) de la JavaSoft este un alt exemplu de CLI.

Figura 4.16. Monitor TP

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

Figura 4.17. Arhitectura unui server de aplicaie tipic

Cursul 8 Integrarea sistemelor informatice

Figura 4.18. Servere de integrare

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

4.5.2.1. Platforme Java

Cursul 8 Integrarea sistemelor informatice

Figura 4.19. Platforme Java

Cursul 8 Integrarea sistemelor informatice

4.5.2.2. Java 2 Enterprise Edition - J2EE

Cursul 8 Integrarea sistemelor informatice

Figura 4.20. Arhitectura J2EE

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

4.5.2.7. JAVA versus .NET

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

Figura 4.21. Java vs. .NET

Cursul 8 Integrarea sistemelor informatice

Cursul 8 Integrarea sistemelor informatice

STUDIUL TEHNOLOGIILOR INFORMATICE DE INTEGRARE A

S-ar putea să vă placă și