| CATEGORII DOCUMENTE | ||
|
||
Interconectarea unor sisteme diferite necesita prezenta unei infrastructuri care sa mute datele intre sisteme, sau chiar a unui nivel functional suplimentar situat deasupra functiilor furnizate de aplicatiile existente, care sa poata automatiza procese complexe de afaceri sau sa ofere acces unificat la datele raspandite in cadrul diferitor sisteme. La inceput, conotatiile procesului de integrare au fost in principal tehnice si s-a acordat putina importanta aspectelor calitative. Notiunea de sistem integrat presupunea aspecte hardware si probleme de interconectare a componentelor calculatoarelor. In prezent, procesul de integrare s-a extins si vizeaza programe, date si comunicatii.
In continuare este descris pe larg procesul de integrare a aplicatiilor, punctandu-se principalele tipuri de integrare a acestora, etapele si o parte dintre tehnologiile informatice utilizate in acest scop.
4.1. Tipuri de integrare a aplicatiilor
Automatizarea procesului de integrare conduce la o crestere a eficientei si poate ajuta la eliminarea inconsistentelor intalnite in practica. Dar, o automatizare completa ar necesita un efort deosebit, care ar intarzia mult beneficiile tangibile. Solutiile mai simple pot ajunge mai repede la atingerea acestora, cu un risc mult mai redus, desi conduc la obtinerea doar unei parti din beneficii.
Pot fi identificate mai multe nivele de integrare [MICR04]:
integrarea prin entitati;
integrarea prin procese;
integrarea prin portal.
Integrarea prin portal permite vizualizarea unei multitudini de sisteme, atat interne unor intreprinderi, cat si externe acestora, printr-o interfata simpla de tip utilizator. Acest tip de integrare aduce un plus de beneficiu datorita evitarii problemelor de integrare si adaptarii interfetei utilizator a fiecarui sistem la o interfata utilizator comuna (interfata utilizator agregata), care este de cele mai multe ori un browser Web (Figura 4.1). Ca rezultat, toate sistemele participante sunt integrate intr-un browser, chiar daca aplicatiile nu sunt direct integrate in cadrul companiilor sau intre acestea.
Este o abordare mai putin flexibila decat integrarea prin procese, dar da utilizatorului flexibilitate si este mult mai rapid de implementat. Eventual, integrarea prin portal poate fi utilizata ca o solutie intermediara pana la mai buna intelegere a proceselor si formularea unui model de procese.
Gradul de integrare a aplicatiilor depinde de varianta de portal, iar in cele ce urmeaza vor fi prezentate succint cateva variante reprezentative.
Cea mai simpla varianta de portal este cea care doar afiseaza datele din diferite sisteme in diferite zone ale ecranului, fara a oferi nici o functionalitate.
Figura 4.1. Integrarea prin portal
O alta varianta de portal este cea care ofera si cateva reguli simple care il ajuta pe utilizator in luarea deciziilor, transformand datele brute in informatii utile pentru utilizator.
Cea mai frecvent intalnita varianta de portal este cea care, pe langa afisarea informatiilor din diferitele sisteme in diferite zone ale ecranului, permite si fructificarea acestora prin trimiterea de comenzi unei singure aplicatii la un moment dat.
O varianta mai complexa de portal este cea care permite o interactiune de baza intre diferitele zone afisate pe ecran, astfel incat ceea care se afiseaza intr-o anumita zona depinde de cea care a fost selectat in alta zona, usurand sarcinile utilizatorului, fara a solicita o integrare completa intre sisteme. Acest tip de portal necesita disponibilitatea unor chei comune in cadrul mai multor sisteme.
Desi este mai usor de implementat decat alte solutii de integrare (de unde si popularitatea), integrarea prin portal are dezavantajul ca o mare parte din procesele de afaceri si regulile care le guverneaza raman doar in mintea utilizatorului, nefiind incluse in sistem. Procesul de business care descrie secventa de sarcini nu trebuie sa fie reprezentat intr-un model de procese, ceea ce permite utilizatorului sa compenseze diferentele semantice dintre diferite subsisteme si sa ia decizii in functie de caz.
Beneficiile oferite de aceasta solutie de integrare sunt:
Nonintruziunea. Deoarece integrarea prin portal are ca principal scop extragerea si afisarea de informatii, ea poate fi adaugata sistemelor existente fara a afecta functionalitatea existenta.
Viteza de implementare. Adaugarea unui portal la aplicatiile existente se poate adesea realiza in cateva zile sau saptamani, in timp ce o integrare completa ar necesita cateva luni.
Flexibilitatea. Deoarece in cazul integrarii prin portal deciziile apartin utilizatorului, aceasta versiune de integrare este folosita in cazul in care regulile afacerii nu sunt bine intelese sau nu au fost general acceptate.
Punctele slabe ale acestei solutii de integrare sunt:
Ineficienta. Deoarece cele mai multe dintre solutiile bazate pe portal permit interactiunea cu o singura aplicatie la un moment dat, pentru completarea unei functii complexe de business este adesea nevoie de un sir de actiuni manuale din partea utilizatorului. Din acest motiv, integrarea prin portal este ineficienta in cazul unor aplicatii care lucreaza cu volume mari de date, recomandandu-se integrarea prin procese.
Vulnerabilitatea la erori. In cazul integrarii prin portal, utilizatorul ia decizii de business si determina secventa de actiuni de realizat, ceea ce desi confera flexibilitate, introduce riscul erorilor umane.
Daca alte tipuri de integrare sunt orientate pe schimbul de informatie in timp real, acest tip de integrare este axat pe externalizarea informatiei provenind din mai multe sisteme si companii intr-o singura aplicatie cu interfata unica. Totusi, integrarea aplicatiilor, referindu-se la schimbul automat de informatie sau la legarea a doua sau mai multe procese fara ajutorul unui utilizator final, poate aparea si la nivelul interfatei utilizator. Intr-adevar, majoritatea exemplelor de schimb de informatie intr-un mediu Business-to-Business (B2B) se pliaza pe tehnica integrarii orientate pe portal, folosindu-se de transfer digital. Ca urmare, se poate concluziona ca, desi este diferita, aceasta tehnica se pliaza pe problematica integrarii in general.
Solutia ORACLE PORTAL 10g
Oracle a lansat recent Oracle Application Server 10g cu Oracle Portal, bazat pe noua arhitectura integrata bazata pe servicii (SOA), incluzand si facilitati de business intelligence cum ar fi: OLAP, data mining, rapoarte, procese de afaceri si reguli de afaceri. Oracle Portal 10g este un instrument puternic ce pemite realizarea usoara a unor tablouri de bord care ofera un proces de business intelligence traditional si in timp real, intr-un mod organizat si intuitiv, Dupa cum se mentioneaza in [ORA10g], principalele facilitati oferite de Oracle Portal 10g sunt:
Business intelligence integrat - ofera acces la depozite de date si alte depozite pentru interogare, raportare si analize ad-hoc ale datelor intreprinderii si ofera abilitatea de a publica rapoarte de calitate ridicata in format HTML, PDF sau XML;
Vizualizare intuitiva - integrarea diferitor perspective de business intelligence si indicatori de performanta cheie intr-o singura viziune intuitiva, destinata unei anumite zone din cadrul organizatiei devine usor de realizat cu ajutorul instrumentelor de tip browser.
O frecventa utilizare a unui tablou de bord este cea de analiza a unor indicatori de performanta cheie: profitul, fluxul de numerar, rentabilitatea, rata interna de revenire, evolutia vanzarilor, etc, obiectiv care poate fi realizat cu unui instrument de business intelligence (Oracle Discoverer) si cu ajutorul portleturilor furnizate de Oracle Portal (Oracle Discoverer Portlets).
Dupa cum se mentioneaza in [ORA10g], Oracle Discoverer Portlets ofera trei tipuri de portleturi:
portletul Discoverer Worksheet- este utilizat pentru a publica in Oracle Portal un tabel sau un grafic realizat in Discoverer. Publisher-ul ofera si un link numit Analyze, care permite utilizatorilor deschiderea paginii in Discoverer Viewer pentru analize mai detaliate: roll-up, drill-down (agregare pe nivelele superioare sau detaliere pe nivelele inferioare), sectiuni, rotatii ale datelor.
portletul Discoverer Gauges - contine date dintr-o pagina Discoverer, afisate sub forma unuia sau mai multor potentiomentre semicirculare. Este un mod de a vizualiza date in intervale de valori definite prin limite inferioare, acceptabile si superioare, numite "valori prag". Intervalele de valori reflecta indicatorii de performanta cheie. Portlet-urile de acest tip pot fi create doar pentru pagini Discoverer de tip "crosstab".
portletul Discoverer List of Worksheets - contine legaturi spre pagini si grafice Discoverer, iar daca utilizatorul da click pe unul dintre acestea, pagina respectiva se deschide intr-o pagina din Discoverer Viewer.
In urmatoarea figura, sunt folosite toate cele trei tipuri de portlet pentru construirea unui tablou de bord:
Figura 4.2. Exemplu de tablou de bord BI
Portlet-urile Oracle Discoverer necesita definirea unei conexiuni la Oracle Discoverer din cadrul portalului, lucru care se poate realiza de catre utilizatori direct sau utilizand Oracle Application Server Control. In cazul de fata a fost utilizat pentru definirea unei conexiuni publice Oracle Application Server Control.
Figura 4.3. Oracle Enterprise Server Manager 10g
Prima etapa este inregistrarea sursei externe de date in cadrul portalului, sub forma unui furnizor extern (Remote Provider). Apoi se va defini conexiunea spre Discoverer, precizand URL-ul si celelalte setari pentru conectare. Este importanta selectarea proprietatii "The user has the same identity in the Web providers application as in the Single Sign-On identity", care permite existenta unui singur punct de identificare in cadrul portalului, fara a mai fi necesara autentificarea ori de cate ori are loc conectarea portalului la Oracle Discoverer. De asemenea, se poate realiza in momentul configurarii si stabilirea drepturilor de acces la conexiunea respectiva a diferitor utilizatori sau grupuri de utilizatori.
Figura 4.4. Definirea unei conexiuni Oracle Discoverer
In momentul in care furnizorul Discoverer a fost inregistrat cu succes, el va aparea ca o sursa de portleturi daca se doreste adaugarea unui nou portlet intr-una din paginile portalului. Eventual, daca se doresc imbunatatiri ale performantelor de lucru, se pot modifica setarile Discoverer.
In paginile portalului poate fi definit aproape orice tip de continut: fisiere, legaturi URL, texte, date dinamice (in PL/SQL) sau chiar scripturi server (prin protlet). Cele mai importante facilitati care sunt oferite la nivelul fiecarui element continut intr-o pagina sunt:
urmarirea versiunilor - prin activarea acestei optiuni, sistemul retine vechea versiune a elementului in loc sa o suprascrie in momentul editarii elementului, iar utilizatorul poate reveni la o versiune anterioara daca este necesar;
securitate la nivel de element - optiunea este utilizata pentru a preveni ca utilizatori neautorizati sa acceseze un element sau pentru a permite un nivel de acces mai inalt decat ar fi fost realizat altfel pe baza drepturilor la nivelul paginii caruia ii apartinea elementul;
date de expirare - utilizand acest atribut, se poate specifica pentru fiecare element pana cand va fi afisat in pagina.
O facilitate importanta a portalului este cea de cautare a continutului: mediul portalului integreaza direct capacitati avansate de cautare, deoarece intreg continutul depozitului portalului este indexat. Este returnat doar continutul la care utilizatorul este autorizat sa aiba acces.
Administrarea portalului este simpla si flexibila. Un administrator unic sau un grup de administratori pot administra portalul prin utilizarea unor portlet-uri predefinite ale paginilor, intr-o sectiune speciala de administrare.
Principala limitare a integrarii prin portal este faptul ca realizeaza integrarea informatiilor doar pentru utilizatori, nu si pentru aplicatii. Pentru rezolvarea acestei probleme, integrarea prin entitati ofera aplicatiilor o viziune unificata [MICR04].
Datele de la nivelul intreprinderii sunt, de obicei, distribuite in mai multe stocuri de date in mod inconsistent. Aplicatiile existente au insa nevoie de o reprezentare unica, consistenta a entitatilor cheie.
Agregarea entitatilor ofera o reprezentare logica a datelor unificata in cadrul diferitelor surse de date, cu conexiuni fizice care ofera accesarea si actualizarea instantelor corespunzatoare din cadrul stocurilor de date multiple. Aplicatiile pot sa interactioneze cu aceasta reprezentare ca si cum ar exista o singura sursa de date.
Problema este ca nivelul de integrare trebuie sa rezolve orice aparitie a disonantei semantice intre sistemele individuale, aspect care, alaturi de crearea unui nivel unificat de date poate reprezenta un efort deosebit. Disonanta semantica este una dintre problemele principale in construirea de aplicatii integrate, care apare in momentul in care date din diferite sisteme care par sa fie aceleasi, sunt de fapt diferite din punct de vedere semantic.
Agregarea entitatilor implica doi pasi:
1. definirea unei reprezentari la nivel de intreprindere care ofera o reprezentare consistenta unica a entitatii;
2. implementarea unei conexiuni fizice bidirectionale intre aceasta reprezentare si instantele corespunzatoare in stocurile diferitor sisteme.
Problemele care pot sa apara si care trebuie avute in vedere in cazul acestui tip de integrare sunt:
Pot exista mai multe sisteme de inregistrare a aceleiasi entitati. Pentru o anumita entitate, modul in care se determina sistemul de inregistrare pentru o anumita entitate depinde de regulile si procesele de afaceri. De exemplu, un angajat apare ca entitate in mai multe sisteme (resurse umane, salarizare), care au diferite viziuni asupra sa.
Adeseori exista disonanta semantica intre valorile aceleiasi entitati in cadrul surselor diferite de date.
Pot aparea date invalide in cadrul diferitor stocuri de date datorita unor reguli de validare inconsistente.
Poate sa apara incalcarea integritatii referentiale peste stocuri multiple de date datorita lipsei sau unei proaste functionari a sistemelor de sincronizare a datelor.
Intre anumite stocuri de date pot sa existe deja procese de sincronizare, care permit unuia dintre stocuri sa functioneze ca sursa pentru celalalt. In acest caz, se recomanda pastrarea mecanismelor de sincronizare. Este cazul tipic, in care se foloseste replicarea datelor intre doua instante diferite ale bazei de date care folosesc aceeasi tehnologie.
Abordari arhitecturale
Exista doua abordari arhitecturale ale integrarii prin entitati:
Procesarea directa presupune obtinerea informatiilor direct din stocurile sursa de date in timp real si corelarea informatiilor intr-un singur view unificat. Aceasta implica faptul ca nivelul de integrare are conectivitate in timp real cu stocurile si trebuie sa fie capabil sa asocieze instantele disparate ale unei entitati.
Replicarea presupune existenta unui stoc de date fizic separat, in cadrul nivelului de integrare, care sa stocheze datele conform reprezentarii unificate la nivelul intreprinderii. Datele din stocurile initiale sunt replicate in acest stoc, si sunt implementate procese care forteaza regulile de business care valideaza datele replicate. Replicarea este necesara daca:
nu exista conectivitate directa la stocurile de date;
realizarea unei reprezentari consistente necesita jonctiuni multiple asupra instantelor entitatii din mai multe stocuri de date;
performanta solutiei este vitala.
Aceasta abordare este foarte asemanatoare cu cea a depozitelor de date, create initial pentru pastrarea de date tranzactionale sumarizate in vederea utilizarii lor in business intelligence si analiza tendintelor. In multe intreprinderi acestea s-au tranformat de fapt in mari stocuri la nivel de intreprindere, care pot constitui un punct de plecare pentru reprenzentarea entitatilor la nivel de intrerindere.
In continuare, pot fi detaliate urmatoarele aspecte:
Reprezentarea datelor include reprezentarea entitatilor si reconcilierea schemelor. Reprezentarea entitatii este definirea reprezentarii unice la nivel de intreprinderii a unei entitati cu atributele sale si relatiile sale cu alte entitati. Trebuie stabilit, pe langa modul de reprezentare a datelor si modul de stocare al acestei reprezentari. Reconcilierea schemelor presupune reconcilierea diferitor definitii ale schemelor din cadrul stocurilor de date.
Identificarea datelor in cadrul nivelului de integrare necesita un mecanism care sa identifice in mod unic fiecare entitate in toate stocurile de date, de exemplu referinta entitatii.
Operarea cu datele se refera la modul in care se vor realiza operatiile tranzactionale (Create, Retrieve, Update, Delete). Trebuie tinut cont de faptul ca tehnologia disponibila in momentul de fata pentru interogarea datelor este mai robusta decat cea pentru actualizarea acestora.
Guvernarea datelor se refera la stabilirea unui apartenente pentru mentenanta in curs si stabilirea unui proces de management al schimbarilor pentru a conduce mentenanta. De exemplu, pentru atribute ale unei entititati care sunt prezente in mai multe sisteme, trebuie stabilita o sursa autoritara, astfel incat atributele respective vor fi intotdeauna consultate din acea sursa.
Avantajele oferite de aceasta solutie de integrare sunt:
Consensul asupra modului de reprezentare a entitatilor printr-un singur view asupra entitatilor cheie;
Acces mai bun la informatii prin intermediul view-lui unic de la nivelul intreprinderii;
Disonanta semantica redusa datorita procesului de agregare a entitatilor;
Localizare centrala a datelor;
Impact redus al schimbarilor din stocurile diverselor sisteme.
Puncte slabe ale acestei solutii de integrare sunt urmatoarele:
Un nivel arhitectural suplimentar;
Consensul necesar intre unitatile de afaceri referitor la reprezentarea entitatilor;
Reingineria aplicatiilor care sunt strans cuplate la un anumit set de stocuri de date astfel incat sa se adapteze noului nivel.
Integrarea prin procese de afaceri se realizeaza prin coordonarea interactiunilor intre mai multe sisteme, urmarind starea fiecarui proces de afaceri in cadrul fiecaruia dintre sisteme si permitand raportarea centralizata. Fiecare dintre sistemele de aplicatii disparate completeaza o parte dintr-o functie de business si se doreste integrarea acestora in asa fel incat functia de business sa poata fi completata in mod automat.
Aceast tip de integrare se realizeaza prin crearea unui nivel de logica a aplicatiei, care va contine procese ce vor fi gestionate unitar si vor fi definite pe baza setului curent de procese si date, existent in aplicatiile a caror integrare este vizata (figura 4.5).
Integrarea prin procese de afaceri reprezinta un mecanism de gestiune a datelor interschimbate si de apelare a proceselor intr-un mod unitar, astfel incat sa se permita administrarea si executia proceselor comune care exista in cadrul aplicatiilor si intre acestea. Scopul este de a grupa procese relevante pentru a obtine valoare maxima, sustinand fluxul de informatie si controlul logic intre aceste procese.
Integrarea proceselor de afaceri completeaza solutiile de integrare a aplicatiilor (solutii care includ serverele de aplicatii, obiecte distribuite si alte niveluri middleware) prin oferirea unui mecanism pentru legarea proceselor disparate si pentru crearea solutiilor proces-proces care automatizeaza o sarcina odata ce aceasta a fost realizata manual.
Exista multe diferente intre integrarea de aplicatii traditionala si integrarea bazata pe procesele de afaceri:
Figura 4.5. Integrarea prin procese de afaceri
O singura instanta a integrarii proceselor de afaceri este echivalenta cu mai multe instante ale integrarii aplicatiilor traditionale;
integrarea traditionala a aplicatiilor se refera la schimbul de informatii intre doua sau mai multe sisteme, fara ca procesele interne sa fie vizibile; integrarea proceselor de afaceri duce la un model de proces si muta informatia intre aplicatii conform modelului respectiv;
integrarea aplicatiilor este tipic o solutie tactica, motivata de cerintele a doua sau mai multe sisteme de a comunica; integrarea proceselor de afaceri este strategica, gestionand regulile de afaceri pentru a determina cum ar trebui sa interactioneze sistemele astfel incat sa sustina valoarea afacerii din fiecare sistem folosind un model de afaceri abstract.
Integrarea prin procese de afaceri este cel mai bine definita prin cateva reguli, intr-o secventa logica pentru a realiza :
interschimbul de informatii intre sistemele participante ;
vizualizarea proceselor pe niveluri de aplicatii;
crearea de procese abstracte comune atat pentru sistemele interne, cat si pentru cele externe.
Ca urmare, sunt trei servicii majore pe care le ofera acest tip de integrare:
vizualizarea proceselor continute de sistemele in cauza ;
abstractizarea interfetei;
o masurare in timp real a performantei proceselor de afaceri.
Solutia pentru realizarea integrarii prin procese presupune mai mule etape. Se defineste un model de proces de afaceri care descrie pasii individuali care formeaza functia de afaceri complexa. Se creeaza o componenta separata manager de procese care poate interpreta instante concurente multiple ale acestui model si care poate interactiona cu aplicatiile existente pentru a realiza pasii individuali ai procesului.
Pentru fiecare cerere pentru functia de afaceri, managerul de procese va crea o noua instanta de proces pe baza modelului de proces. Fiecare instanta va pastra starea curenta a procesului si alte informatii necesare pentru ca procesul de afaceri sa continue. Dupa ce o aplicatie isi completeaza functia proprie, managerul de procese determina care va fi functia executata in continuare, pe baza starii instantei procesului. Astfel, fiecare dintre aplicatiile participante pot opera individual, fara a cunoaste secventa de pasi definita in modelul de proces.
Managerul de proces interactioneaza cu aplicatiile individuale prin [MICR04]:
integrare la nivel de date,
integrare la nivel functional sau
integrare la nivel prezentare,
in functie de natura interactiunii si tipul de arhitectura al aplicatiei.
Integrarea bazata pe procese se aseamana cu o aplicatie compusa, construita pe baza functiilor de business din aplicatiile existente. Ea ofera o separare clara intre definirea procesului (in modelul procesului), executia procesului (in managerul de procese) si implementarea functiilor individuale in cadrul aplicatiilor. Aceasta separatie permite reutilizarea functiilor aplicatiilor in mai multe procese diferite.
Aceasta separare permite managerului de procese sa fie independent de domeniu, deoarece el doar interpreteaza constructiile de baza care formeaza procesul.Prin utilizarea acestor constructii, intreprinderea poate crea un model la nivelul afacerii fara a fi nevoie de intelegerea elementelor interne ale managerului de procese sau a aplicatiilor individuale.
Managerul de proces ofera, de obicei, o interfata externa care sa permita initierea proceselor de afaceri definite de modelul de proces (de un utilizator, de un partener sau de o alta aplicatie). Interfata poate fi sub forma unei interfete utilizator sau sub forma API (Application Programming Interface) care pot fi oferite altor aplicatii prin integrare functionala, nefiind practic diferita de o aplicatie simpla.
Faptul ca completarea functiei de business poate dura destul de mult conduce la niste cerinte speciale pentru managerul de proces. Acesta trebuie:
sa coreleze mesajele din sisteme externe cu instanta procesului de afaceri caruia i se adreseaza;
sa suporte tranzactii care ruleaza timp indelungat;
sa trateze exceptiile ridicate de pasii individuali din cadrul procesului de afaceri;
sa ofere logica de compensare pentru refacerea actiunilor realizate anterior in cadrul procesului de afaceri daca are loc un esec.
Integrarea proceselor este o cerinta atat de comuna, asfel incat au fost definite limbaje standard pentru descrierea modelelor de procese, printre care:
BPML - Business Process Modeling Language;
BPEL - Business Process Execution Language;
WSCI - Web Services Choreography Interface.
Avantajele principale oferite de aceasta solutie de integrare sunt considerate:
Mentenabilitatea;
Reutilizabilitatea;
Flexibilitatae;
Capacitatile de raportare.
Punctele slabe ale integrarii pin procese sunt:
Posibilele blocaje;
Tendinta de suprautilizare;
Complexitatea.
Cu toate ca mai sunt aspecte care ar putea fi imbunatatite, acest tip de integrare este considerat cel mai potrivit, tinand cont si de faptul ca trebuie perfectionata tehnologia middleware.
In momentul in care se incearca conectarea la o anumita aplicatie, trebuie sa se tina cont de arhitectura acesteia. Cele mai multe dintre aplicatii au o arhitectura structurata pe trei niveluri [MICR04]:
Nivelul prezentare - este cel care afiseaza informatiile utilizatorului final si permite introduceri de date de catre acesta;
Nivelul logica de afaceri - contine functiile de afaceri care actioneaza asupra datelor afacerii ;
Nivelul datelor - realizeaza depozitarea persistenta a datelor in stocuri de date. Acest nivel mai este denumit si nivelul resurselor.
In mod similar, exista trei moduri de conectare intre aplicatii si nivelul de integrare [MICR04]:
Integrare la nivelul prezentare - nivelul de integrare poate extrage informatii de la nivelul de prezentare al utilizatorului printr-o tehnica denumita "screen scraping";
Integrare la nivelul functional - interactiunea intre nivelul de integrare si nivelul logicii afacerii se realizeaza prin interfete de aplicatii sau servicii ;
Integrare la nivelul datelor - nivelul de integrare poate muta date in si din nivelul datelor.
Conectarea aplicatiilor prin stocurile de date este relativ simpla, apeland la: FTP, utilitati oferite de SGBD-uri, instrumente ETL (Extract, Transform and Load), servere de integrare. Multitudinea de instrumente suport pentru integrare la acest nivel usureaza mult efortul de integrare.
Acest tip de integrare este momentan cel mai raspandit si, ca urmare, a fost prezentat pe larg in capitolul anterior.
Conectarea la nivelul prezentare este cea mai putin invaziva, deoarece celelalte aplicatii apar la nivelul aplicatiei gazda, ca si utilizatorii care actioneaza prin intermediul interfetelor, motiv pentru care nu solicita nici o schimbare la nivelul aplicatiei gazda.
Aplicatiile se vor conecta la aplicatia gazda prin intermediul sirului de byte de prezentare, deci datele si aceul la functionalitati trebuie obtinute pe baza acestui sir de byte. Aceasta inseamna exact inversarea transformarii efectuate de nivelul prezentare. Un alt dezavantaj este faptul ca aplicatiile pot avea acces doar la ceea ce le este disponibil utilizatorilor. Granularitatea datelor si functionalitatilor oferite este foarte mare.
Figura 4.7. Integrare la nivel functional
Avantajul oferit de integrarea la acest nivel este costul scazut. Prin insasi natura sa, integrarea la acest nivel este strans cuplata cu prezentarea aplicatiei gazda. Daca prezentarea aplicatiei se modifica, solutia de integrare trebuie modificata si ea.
Prin conectarea direct la nivelul logicii de business, acest tip de integrare permite aplicatiilor si serviciilor sa beneficieze de pe urma logicii de afaceri incapsulate in alte sisteme.
Integrarea la nivel functional conecteaza aplicatiile prin interfete si specificatii. Din nefericire, nu toate aplicatiile dintr-o arhitectura integrata au interfete si specificatii. Adesea aplicatiile care au API nu isi expun datele si functiile la nivelul de granularitate necesar pentru integrare.
Exista trei alternative de integrare functionala :
1. Integrarea prin obiecte distribuite - se mai numeste si colaborare bazata pe instante, deoarece extinde modelul calculului orientat obiect si pentru solutiile distribuite, Obiectele dintr-o aplicatie pot interactiona cu obiectele dintr-o aplicatie aflata la distanta in acelasi mod in care interactioneaza cu un obiect local.
2. Integrare prin middleware orientat pe mesaje - conecteaza sistemele prin utilizarea unor cozi de mesaje asincrone.
3. Integrare prin servicii - conecteaza aplicatiile permitand ca acestea sa solicite sau sa apeleze servicii Web XML. Acest tip de integrare utilizeaza standarde pentru a oferi un tip de sistem portabil si un cadru extensibil pentru mesaje. In plus, acest tip de integrare recomanda WSI Basic Profile pentru a asigura interoperabilitatea intre punctele finale. WSI Basic Profile este un subset selectat din XML, SOAP, HTTP si alte standarde.
Integrarea prin servicii permite aplicatiilor sa imparta metode comune. Acest proces se realizeaza fie prin definirea unor metode care sa poata fi accesate de toate aplicatiile si ca urmare integrate, fie prin punerea la dispozitie a unei infrastructuri pentru asemenea metode, ca de exemplu serviciile Web (figura 4.8). Metodele pot fi accesate prin stocarea acestora pe un server central (obiecte distribuite) sau printr-un mecanism de servicii Web standard, cum ar fi .NET.
Figura 4.8. Integrarea prin servicii
Incercarile de a permite accesul la procese comune au o istorie lunga, incepand cu arhitectura client-server. Un set comun de metode intr-o aplicatie care foloseste reutilizarea reduce redundanta metodelor. Din pacate, reutilizarea totala a fost realizata deocamdata doar la nivel de intreprindere. In cele mai multe cazuri, limita reutilizarii este cauzata de lipsa unei arhitecturi nitare a sistemlui informatic la nivelul companiei si a unui control central. Utilizarea uneltelor si a tehnicilor de integrare ofera acum posibilitatea folosirii acelorasi metode. Mai mult decat atat, aceste unelte si tehnici creeaza infrastructura care face acest proces sa devina realitate. Dezavantajul consta in costurile destul de ridicate, daca se iau in considear serviciile Web, obiectele distribuite si cadrele tranzactionale.
Integrarea prin date nu necesita schimbari ale sistemelor sursa sau destinatie, pe cand integrarea prin servicii impune modificari la aproape toate aplicatiile pentru a beneficia de avantajele acestei paradigme. Cu toate ca problemele ridicate de costuri sunt importante, aplicabilitatea in mai multe domenii ofera acestui tip de integrare un avantaj. Ca urmare, folosirea integrarii orientate pe servicii se recomanda doar acolo unde este strict necesara.
Modificarea aplicatiilor este adesea o operatiune scumpa. Pentru a schimba logica aplicatiei, sunt necesare testarea si integrarea aplicatiei, procese care cauzeaza o crestere a costurilor in spirala. Aceste costuri apar fie ca se lucreaza cu o tehnologie mai veche, CORBA (Common Object Request Broker Architecture), fie cu tehnologii noi ca .NET, ultimul tip de arhitectura bazata pe servicii.
Inainte de a folosi acest tip de integrare, trebuie intelese foarte bine aspectele legate de oportunitatile oferite de aceasta si riscurile implicate. Numai atunci se poate face o evaluare obiectiva. Posibilitatea de a avea acces la serviciile unei aplicatii si, drept urmare, posibilitatea integrarii acestor aplicatii, reprezinta un beneficiu extraordinar. Totusi, acest beneficiu este urmat de un risc real ridicat din cauza costurilor de implementare a integrarii bazate pe servicii, deoarece aceste costuri ar putea, in anumite cazuri, sa depaseasca valoarea creata de integrare.
Procesul de integrare a aplicatiilor cuprinde 12 pasi, bazeazandu-se pe o abordare practica si refolosind o serie de activitati care tin de proiectarea si dezvoltarea aplicatiilor traditionale. De multe ori, sunt folosite aceleasi sabloane de proiectare pentru a conecta aplicatiile intre ele.
Aceasta abordare pragmatica se bazeaza pe concepte familiare, cum sunt: metadate, scheme, modelare orientata-obiect, analiza si proiectare orientata-obiect. Cu toate ca acestea nu sunt singurele activitati care trebuie luate in considerare, intr-un proiect de integrarea aplicatiilor, trebuie urmati urmatorii pasi:
Intelegerea companiei si a domeniului problemei;
Analiza semnificatiei datelor;
Analiza semnificatiei proceselor;
Identificarea tuturor interfetelor aplicatiei;
Identificarea tuturor proceselor de afaceri;
Identificarea scenariilor de transformare a datelor;
Maparea transferului de informatie;
Aplicarea tehnologiei;
Testarea;
Analiza performantei;
Definirea valorii;
Crearea procedurilor de mentenanta.
Este foarte important ca in procesul de integrare, de mare anvergura intr-un lant colaborativ, organizatia sa urmareasca:
abilitatea de a extrage si importa date;
capacitatea de a comunica informatii prin intermediul protocoalelor Internet, cu acoperirea cerintelor necesare de protectie si securitate a datelor;
posibilitatea de a dezvolta noi procese economice in maniera dinamica.
Integrarea aplicatiilor unei intreprinderi (EAI) inseamna aducerea la un numitor comun a sistemelor si entitatilor disparate, care vor fi regandite si modelate impreuna pentru atingerea obiectivelor organizatiei. Aceste piese care vor fi combinate includ diverse platforme si medii de operare, multiple aplicatii (proprii, achizitionate cate una sau integrate in suite ERP), diverse baze de date si sisteme de gestiune a acestora sau unitati organizatorice dispersate teritorial.
In literatura de specialitate [MYER02] sunt descrise patru stadii distincte ale procesului de integrare a sistemelor (fiecare dintre acestea se defineste individual, are proprietati, aspecte si complexitati distincte):
1. interconectivitatea sau integrarea hardware;
2. interoperabilitatea sau integrarea software;
3. integrarea semantica sau integrarea datelor si a depozitelor de date;
4. integrarea retelelor de comunicatie.
Este o etapa de baza, asigura infrastructura celorlalte etape si presupune analiza modalitatilor prin care echipamentele si tehnologiile diferite lucreaza impreuna.
Sunt incluse, de asemenea, aplicatiile de partajare a perifericelor, transferurile de fisiere, crearea cailor de comunicatie dintre diversele componente. Aplicatiile de baza, functionalitatile si modurile de functionare, legaturile pentru urmatoarele stadii se stabilesc la acest nivel.
Aceata etapa vizeaza modalitatea prin care o aplicatie si tehnologia aferenta acesteia comunica cu alta aplicatie, fiind exploatate functionalitatile ambelor platforme. Interoperabilitatea este deosebit de importanta mai ales in domeniul bazelor de date, unde aplicatiile sunt complexe si se cere compatibilitate intre platforme.
Portabilitatea permite realizarea solutiilor intr-un mediu si transferarea ulterioara in alte medii. Standardele de interoperabilitate ne dau posibilitatea sa construim legaturi intre aplicatii care functioneaza pe platforme complet diferite [ALTM04].
Este de dorit sa se poata prevedea care dintre standardele existente vor deveni universale (cum ar fi TCP/IP) si care vor disparea. Modelul de Maturitate al Standardelor (Standard Maturity Model - SMM) poate fi folosit pentru a determina standardele si a prezice cat timp este necesar unui standard pentru a atinge completitudinea.
SMM are 5 niveluri:
Nivelul 5 - "Adecvat din punct de vedere functional";
Nivelul 4 - Multe aplicatii folosesc versiuni "adecvate functional";
Nivelul 3 - Este aprobata versiunea standardului "adecvata functional";
Nivelul 2 - Este propusa versiunea 1.0 a standardului;
Nivelul 1 - Multi recunosc problema;
Nivelul 0 - Putini realizeaza ca este o problema.
La nivelul 1 al SMM, toata lumea stie ca exista o problema, dar solutiile sunt proprietare.
La nivelul 2, vanzatorii sau intreprinderile colaboreaza la noul standard. Standardul nu este complet deoarece exista intotdeauna lipsuri si ambiguitati in prima versiune. Acesta este motivul pentru care aceasta versiune incipienta este inaintata spre verificare unei institutii de standarde, cum ar fi Consortiumul W3 sau OASIS.
La nivelul 3, standardul a fost revizuit de cateva ori si acum este complet functional. Se refera la problemele tehnice pentru care a fost propus.
La nivelul 4, cele mai multe aplicatii noi si cele mai noi instrumente implementeaza standardul.
Maturitatea completa este atinsa la nivelul 5. Aici cele mai multe aplicatii suporta standardele de interoperabilitate si cele mai multe platforme folosite suporta standardele de portabilitate.
Singurele standarde legate de servicii Web care au ajuns la nivelul 5 sunt TCP/IP, HTTP si Secure Socket Layer (SSL). Chiar si XML, care este o piatra de incercare pentru serviciile Web, este de abia la nivelul 4 al SMM.
Standardele de baza pentru servicii Web includ:
Simple Object Access Protocol (SOAP);
Web Services Description Language (WSDL);
Universal Description, Discovery and Integration (UDDI).
Acestea sunt complete din punct de vedere functional, dar sunt inca in faza in care distribuitorii construiesc suport pentru aceste standarde in toate produsele lor noi. Din fericire pentru cei care doresc sa anticipeze "integrarea plug-and play" realizata prin serviciile Web care au ajuns la nivelul 4, aceasta este partea cea mai usoara. Pentru a ajunge la nivelul 5, mii de aplicatii trebuie inlocuite sau prelucrate. Este un proces lung si costisitor care nu se va incheia foarte curand. Ar putea dura 10, 15 ani pana cand interoperabilitatea dintre aplicatii care folosesc SOAP, WSDL si UDDI sa devina realitate.
Aceste standarde ale serviciilor Web de baza permit doar scenariile cele mai simple de interoperabilitate. Standardele care guverneaza recunoasterea evenimentelor, transmiterea mesajelor in conditii de siguranta, autentificarea, retransmiterea, gestiunea tranzactiilor si alte functii avansate trebuie, de asemenea, standardizate inainte de a putea construi cazuri mai complicate de interoperabilitate cu serviciile Web standard.
Dar nici atunci nu se considera realizata integrarea adevarata. Din momentul in care standardele serviciilor Web devin mature si complete, tot ceea ce s-a obtinut este interoperabilitatea "plug-and-play". Cu alte cuvinte, se pot transfera cifre si text in conditii de siguranta si securitate. Dar aplicatiile sursa si destinatie nu sunt neaparat de acord din punct de vedere al semanticii datelor. In aplicatia sursa, spre exemplu, caracteristica greutate poate desemna greutatea neta a produsului, masurata in grame, dar aplicatia destinatie poate folosi aceeasi caracteristica pentru a indica greutatea bruta a produsului, in kg. Nu se poate vorbi despre integrare pana cand problemele de semantica a datelor nu sunt rezolvate. De asemenea, aplicatiile sursa si destinatie trebuie sa fie de acord cu privire la semantica tranzactilor.
Integrarea "plug-and-play" completa se va produce in momentul in care standardele rezolva si problemele de semantica.
Cel mai important efort investitional intr-un proiect de integrare este indreptat spre implementarea sistemelor de gestiune a bazelor de date si a sistemelor sofisticate de analiza si raportare manageriala. Eforturile sunt indreptate spre rationalizarea datelor, termenelor, scadentelor si planurilor. Accente deosebite sunt acordate accesibilitatii datelor si minimizarii erorilor umane in crearea definitiilor standard si a formatelor pentru date.
Pentru integrarea semantica nu este suficienta simpla implementare a sistemelor de gestiune a bazelor de date, datele trebuind sa suporte un proces de rationalizare pentru utilizarea lor cu acuratete.
Volumul, diversitatea si viteza datelor in organizatii cresc [CARD02]. Volumul de date este in crestere odata cu cresterea afacerii. Diversitatea datelor creste datorita numarului de aplicatii implementate si din activitatea de achizitie a acestora. Viteza datelor creste datorita cererii de procesare in timp real.
Pentru a realiza integrarea informatiei corect, este bine sa se ia in considerare definirea informatiilor operationale si financiare care ajuta la luarea deciziilor in organizatie. Acest lucru se realizeaza cel mai bine cu ajutorul unor echipe cu diferite functii si responsabilitati organizationale variate.
In mod obisnuit, informatia provenind de la unitati multiple ale organizatiei este reprezentata pe zone de interes si unele unitati sunt implicate in toate domeniile. Acesta este considerat un element critic in determinarea potentialelor lipsuri, redundante si neconsistente. Echipa ar trebui sa identifice si sa elimine redundantele inutile si sa integreze sursele ramase.
Datoria EAI este sa realizeze accesibilitatea datelor unei aplicatii din punct de vedere semantic si sintactic pentru o alta aplicatie [MCGO03].
Desi nu este singurul factor, costul ridicat al proiectelor de integrare este legat direct de dificultatea integrarii datelor. Nivelul de dificultate are doua componente primare: transportul de date si incompatibilitatea datelor.
Este nivelul cel mai sofisticat, depinde de parcurgerea celor anterioare si presupune mai mult decat integrarea tehnologiilor, aplicatiilor si rationalizarea bazelor de date partajate.
Integrarea sistemelor reprezinta punctul de plecare al crearii de noi forme organizationale (intreprinderea virtuala) si nasterea unor procese de afaceri noi. Convergenta integrarii antreneaza integrarea tehnologiilor cu procesele de afaceri, cu performantele si cunostintele umane.
BPEL este un standard bazat pe XML si servicii Web care permite modelarea fluxurilor de afaceri si automatizarea acestora. Folosind acest limbaj, fluxurile si regulile de afaceri pot fi definite intr-un mod intuitiv, fiind asigurat un nivel ridicat de transparenta in realizarea acestor operatiuni. Tehnologia BPEL simplifica modul de integrare a diverselor aplicatii si procese de afaceri [NET07].
Figura 4.9. Integrarea cu partenerii de afaceri
Dupa cum reiese din figura 4.9, integrarea aplicatiilor prin BPEL se realizeaza prin intermediul solutiei Business Process Management (BPM), care se bazeaza pe standarde si tehnologii fundamentale ce stau la baza Internetului si care pot fi folosite atat pentru automatizarea proceselor interne din cadrul firmei, cat si pentru derularea fluxurilor cu partenerii de afaceri. In acest sens, solutiile de acest tip ofera o flexibilitate deosebita in integrarea si automatizarea unor procese de afaceri care prezinta un nivel ridicat de complexitate si la care participa mai multe companii
Evolutia BPEL
Evolutia BPEL este sugestiv reprezentata in figura 4.10, evidentiindu-se trecerea prin urmatoarele faze de dezvoltare:
Figura 4.10. Evolutia BPEL
eXtensible Language (XLang): este un limbaj bazat pe XML pentru definirea proceselor si permite modelarea complexa a proceselor de afaceri foarte dinamice, realizand legatura dintre fisiere obiect din Fortran si C++;
Business Process Markup Language (BPML): este un metalimbaj pentru descrierea proceselor afacerii. BPML a fost proiectat initial pentru a suporta procesele de afaceri care ar putea fi executate de un sistem BPM. Atat BPML, cat si Web Service Choreography Interface (WSCI), aparut mai tarziu, partajeaza acelasi model de executie a proceselor de afaceri si prezinta similaritati de sintaxa. BPML suporta planificarea activitatilor la momente de timp specifice;
Web Services Flow Language (WSFL): este proiectat pentru a descrie modul in care vor conlucra o serie de functii pentru a oferi servicii Web;
Electronic Business Extensible Markup Language (ebXML): a fost creat pentru a permite utilizarea globala a informatiei electronice intr-un mod sigur, interoperabil si consistent de catre toate partile implicate;
Web Services Conversation Language (WSCL);
Web Service Choreography Interface (WSCI): este interfata ce asigura suportul pentru intercomunicarea serviciilor web. Problema schimbului de mesaje intre servicii apartine WSCI (Web Service Choreography Interface), interfata ce functioneaza pentru limbajele de definire a serviciilor Web. Acesta se refera mai ales la comportamentul extern al unui serviciu Web prin asigurarea unei interfete comune de schimb al mesajelor. WSCI asigura deci intercomunicarea serviciilor Web si, mai ales, conlucrarea acestora pentru crearea aplicatiilor mari;
Business Process Execution Language for Web Services (BPEL4WS): prin intermediul XML si BPEL4WS se asigura un nou nivel de conectivitate si interoperabilitate, conform cerintelor arhitecturii orientate pe servicii (Service-Oriented Arhitecture - SOA), stabilite de standardele internationale ale organizatiei Web Services Interoperability. Sunt disponibile mai multe instrumente vizuale care incorporeaza interfete intuitive si functionalitati de drag-and-drop, fiind posibila astfel modelarea simpla a fluxurilor informationale si a proceselor de afaceri. Fiind foarte flexibil in constructia regulilor care conduc procesele de afaceri, se realizeaza o simplificare modului de integrare a diverselor aplicatii si procese de afaceri.
BPEL4WS este practic un limbaj standard pentru integrarea proceselor care, in vederea identificarii datelor relevante din mesaje, utilizeaza proprietatile acestora. Folosind acest mecanism, proprietatile pot fi vizualizate in doua modalitati: transparent si opac. Datele transparente afecteaza protocoalele de afaceri publice, in timp ce datele opace sunt in primul rand asociate cu sistemele back-end (afecteaza protocoalele de afaceri prin nedeterminare).
BPEL4WS defineste un model si o sintaxa pentru descrierea comportamentului unui proces folosind interactiunile dintre proces si parteneri. Aceste interactiuni cu partenerii apar prin interfetele serviciilor Web, iar structura relatiilor la nivel de interfata exista intr-o entitate cunoscuta ca serviciu link. Misiunea unui proces BPEL4WS este sa descrie cum interactioneaza cu acesti parteneri, definind un proces de afaceri si incluzand o logica de coordonare. Cu ajutorul acestui standard, se pot procesa exceptiile si, in cazul in care acestea apar, se pot defini modurile in care sunt compensate activitatile individuale sau compozite dintr-un proces.
Exista doua concepte majore care trebuie evidentiate in ceea ce priveste standardul BPEL4WS in contextul integrarii aplicatiilor. Mai intai, un proces BPEL4WS poate defini un protocol de afaceri utilizand conceptul de proces abstract si oferind un mecanism pentru identificarea datelor relevante pentru protocol ca proprietati ale mesajelor care prin folosirea valorilor non-deterministice ascund proprietatile private. In al doilea rand, este posibil ca BPEL4WS sa defineasca un proces de afaceri executabil care include logica si starea procesului. Acest mecanism gestioneaza conceptele de integrare a proceselor fundamentale.
BPEL4WS exista ca o extensie a mai multor specificatii XML, cum sunt:
WSDL 1.1;
XML Schema 1.0;
Xpath 1.0.
BPEL4WS ofera un set de facilitati pentru refacerea sistemului dupa aparitia unei erori in timpul executiei unui proces sau in timpul tratarii unei exceptii. Acest standard se foloseste de capacitatile de tratare a exceptiilor incorporate in WSDL. Mai mult decat atat, exista notiunea de compensare, in sensul ca permite proiectantului procesului sa implementeze actiuni de compensare pentru anumite actiuni ireversibile. Acest aspect este tratat in BPEL4WS folosind notiunea de scop. Scopul este o unitate de lucru pentru compensare.
BPEL4WS are potentialul de a deveni un standard bazat pe limbaj pentru integrarea proceselor si permite crearea modelelor pe o singura tehnologie de integrare a aplicatiilor, fara a face transformari asupra codului.
Cadrul BPEL
Procesele de afaceri reprezinta colectii de servicii Web care coopereaza pentru a oferi o solutie comuna unei anumite probleme. Cooperarea serviciilor impune coordonarea acestora. Coordonarea serviciilor Web este realizata pe baza unui set partajat de informatii care formeaza contextul de coordonare. Contextul de coordonare se defineste ca fiind totalitatea informatiilor partajate de catre serviciile Web in vederea conectarii activitatilor individuale din cadrul proceselor generale de afaceri [MIND05]
BPEL este un limbaj destinat definirii de fluxuri de activitati. Limbajul utilizeaza sintaxa XML si permite descrierea de procese care pot fi atat producatori cat si consumatori de servicii Web.
BPEL ofera suport atat pentru procesele de afaceri executabile, cat si pentru cele abstracte. Procesele executabile modeleaza comportamentul participantilor intr-o interactiune de afaceri specifica, modeland in esenta un flux de activitati privat. Procesele abstracte, modelate ca protocoale de afaceri in BPEL, specifica schimburile de mesaje publice intre participanti. Protocoalele de acest tip nu sunt executabile si nu transporta detalii interne ale fluxului proceselor.
In construirea proceselor de afaceri sunt parcursi urmatorii pasi [MIND05]:
Definirea interfetelor publice;
Crearea dictionarului partener;
Crearea mesajului si stabilirea tipul dictionarului;
Implementarea transformarilor logice;
Testarea mediului;
Repetarea, daca este cazul, a pasilor 1-5;
Realizarea unui proiect pilot functional;
Reglarea sarcinilor privind operatiunile.
IBM ofera specificatiile unui cadru pentru aplicatii dezvoltate prin integrarea de servicii Web. Acest cadru permite utilizarea fortei si avantajelor arhitecturii Web orientata pe servicii in crearea si automatizarea tranzactiilor intre partenerii unei afaceri, prin automatizarea si integrarea solicitarilor serviciilor Web oferite de acestia.
Cadrul este format din specificatiile BPEL, WS-Transaction (Web Service Transaction) si WS-Coordination (Web Services Coordination). El sta la baza conectarii aplicatiilor distribuite si a cooperarii activitatilor acestora in mod dinamic.
WS-Transaction si WS-Coordination sunt specificatii complementare limbajului, utilizate pentru a asigura coordonarea si corectitudinea rezultatelor produse de procesele definite peste serviciile Web, in contextul problematicii sistemelor distribuite.
Procesele BPEL implementeaza scenarii in care, pentru solutionarea problemelor unui client, sunt implicati mai multi parteneri, fiecare furnizand un serviciu Web. Fiecare partener implementeaza o parte din intregul proces necesar pentru a raspunde solicitarii. Tehnologiile de realizare a tranzactiilor dintre parteneri sunt potential incompatibile si au cerinte specifice, integrarea lor fiind solutionata de cadrul pentru aplicatii.
Cadrul ofera mijloace pentru definirea integrarii partenerilor eterogeni in procesele globale, pentru stabilirea modului in care activitati ale acestor procese pot fi externalizate public sub forma de servicii Web, pentru coordonarea activitatilor serviciilor Web multiple intr-o tranzactie globala si, de asemenea, pentru legarea dinamica, la executie, a unui serviciu selectat, dintr-un set de servicii, pe baza datelor derivate din fluxul proceselor.
Dezvoltarea unei aplicatii bazata pe servicii Web incepe cu definirea proceselor, urmata de stabilirea partenerilor, a conexiunilor dintre acestia, a mecanismelor de coordonare si a operatiilor indivizibile utilizand tranzactii.
In limbajul BPEL se creeaza o descriere abstracta a proceselor de afaceri. BPEL produce scripturi executabile care implementeaza descrierea abstracta a proceselor si care pot fi interpretate de motoare speciale.
Un script al unui proces este o succesiune de pasi, fiecare pas corespunzand unei singure activitati. Implementarea unei activitati inseamna definirea unei interactiuni cu un serviciu Web.
Clientii si serviciile Web sunt considerati parteneri si sunt conectati prin legaturi care se caracterizeaza prin tip si prin rolurile partenerilor.
Un proces este compus din mai multe activitati diferite, unele dintre acestea fiind executate simultan. Toate activitatile implicate in proces sunt supuse mecanismului de coordonare, care asigura generarea de rezultate corecte si consistente.
Activitatile implicate intr-un proces trebuie finalizate cu succes fiecare in parte si in ansamblul lor. Pentru aceasta trebuie solutionata atat problematica clasica a tranzactiilor, cat si cea specifica sistemelor distribuite. In cazul sistemelor distribuite, aceasta deriva din durata mare a unei tranzactii, ca si din latenta semnificativa a procesului de comunicare in retea. Controlul tranzactiilor la nivelul procesului se face de catre o infrastructura care monitorizeaza rezultatele fiecarei activitati individuale in raport cu modul in care aceasta este relationala cu ansamblul procesului. Pentru gestionarea tranzactiilor la nivelul fiecarei activitati se utilizeaza aplicatii traditionale pentru tranzactii si coordonare.
WS-Transaction este un cadru de aplicatii pentru monitorizarea succesului sau esecului fiecarei activitati indivizibile in raport cu realizarea ansamblului activitatilor care formeaza procesul. Acest cadru se bazeaza pe servicii Web, in sensul ca suportul pentru tranzactii ofera interoperabilitate intre aplicatiile proprietar de gestionare a tranzactiilor in vederea realizarii modelului tranzactional la nivelul proceselor de afaceri.
Modelul proceselor de afaceri cu functii de coordonare si tranzactii distribuite ofera o serie de avantaje. Deoarece este construit peste o arhitectura orientata pe servicii Web, el permite integrarea flexibila si dinamica a aplicatiilor ce se executa pe platforme diferite si potential incompatibile. Modelul este extensibil, oferind un cadru general pentru crearea de procese de afaceri, care poate fi extins pentru a include noi cerinte. Acest lucru permite, de asemenea, evolutia instrumentelor de dezvoltare si testare a aplicatiilor pe masura evolutiei cerintelor. Modelul este flexibil, oferind suport pentru o procesare durabila, sigura si corecta a unui spectru larg de procese de afaceri tranzactionale si non-tranzactionale.
WS-Transaction este folosit in monitorizarea corectitudinii fiecarei activitati individuale ce trebuie realizata intr-un proces global. Iar BPEL este folosit pentru definirea modului de compensare a activitatilor esuate.
BPEL - limbaj pentru programarea orientata pe servicii Web
BPEL este un limbaj cu ajutorul caruia se definesc operatii de comunicare a serviciilor Web. O astfel de compozitie descrie o serie de procese, numite procese de afaceri (business processes), deoarece sunt specifice aplicatiilor unui anumit domeniu. Acestea se executa prin integrarea mai multor servicii disponibile in Web. Limbajul poate fi utilizat atat pentru implementarea proceselor de afaceri, cat si pentru descrierea de procese abstracte non-executabile [MIND05].
Procesele de afaceri se pot reprezenta intr-o diagrama de flux a operatiilor care exprima un algoritm cu care se defineste un nou serviciu Web rezultat prin compunerea mai multor servicii existente.
Partenerii sunt reprezentati printr-o referinta tipizata la un serviciu. Aceasta referinta trebuie rezolvata in sensul stabilirii corespondentei cu serviciul Web real. Exista doua tipuri de parteneri: partenerii invocati - sunt cei pentru care procesele sunt clienti si sunt parte integrata a algoritmului dupa care acestea se desfasoara; partenerii clienti - sunt cei care invoca procesele.
O activitate scrie si acceseaza date aflate in containere de date. Un container contine o instanta a unui tip de mesaj definit de WSDL.
Limbajul ofera un set de activitati primitive pentru invocarea de servicii Web, pentru manipularea datelor, pentru lansarea de executii, acestea reprezentand cea mai simpla forma de interactiune a procesului cu lumea exterioara lui. Activitatea primitiva se defineste ca fiind un pas individual in cadrul proceselor. Acestea interactioneaza cu un serviciu, manipuleaza transferul datelor si trateaza exceptiile.
<invoke> - invoca un serviciu sincron;
<receive> - asteapta mesaje despre pornirea sau repornirea proceselor;
<assign> - manipuleaza transferul de informatii, copiaza date de la un container la altul, insereaza noi date ca rezultat al evaluarii unor expresii;
<replay> intoarce raspuns pentru procesele sincrone;
<throw> - indica aparitia unei erori;
<terminate> - determina abandonarea imediata a executiei instantei curente a proceselor de afaceri;
<wait> - pune procesele in asteptare un interval de timp, pana la atingerea unui termen.
Activitatile pentru structurare definesc ordinea de executie a unei colectii de activitati. Ele descriu structurile dupa care sunt compuse mai multe activitati primitive pentru a forma procese. Aceste structuri exprima sabloanele de control, fluxul de date, manipularea erorilor si a evenimentelor externe. Activitatile de structurare descriu, de asemenea, coordonarea schimbului de mesaje intre instantele proceselor implicate.
<sequence> - permite definirea unei structuri ce contine o secventa ordonata de activitati;
<switch> - permite definirea unei structuri de ramificare;
<pick> - ofera posibilitatea alegerii unei cai din mai multe alternative;
<flow> - defineste un set de legaturi care are ca sursa si ca destinatie activitati de structura;
<link> - reprezinta o legatura dintre doua obiecte;
<while> - permite definirea structurilor repetitive;
<scope> - este utilizat pentru divizarea proceselor de afaceri in parti organizate; este un context executant pentru activitatile continute, un proces fiind el insusi un <scope>.
O problema importanta este legata de manipularea erorilor si recuperarea proceselor dupa producerea acestora. Pentru manipularea erorilor limbajul ofera constructiile throw si catch. Pentru a da posibilitatea terminarii procesului erorile se trateaza folosind <faultHandlers>.
Executia 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 fiecarui client. In acest punct se lanseaza operatiile de creare a instantei de proces si de asociere a acestei instante cu valoarea campului cheie din mesaj. In momentul invocarii unui proces, se executa o operatie numita corelare-mesaj. Aceasta operatie verifica daca exista o instanta corespunzatoare campului cheie din mesajul de invocare. Daca nu exista aceasta instanta, operatia de corelare-mesaj lanseaza procesul prin punctul de pornire, iar daca instanta corespunzatoare exista, atunci lanseaza operatii ale procesului prin celelalte puncte de intrare.
In definirea unui proces se descrie modul de interactiune cu partenerii, se specifica entitatile de tip container pentru mesajele pe care procesul le schimba cu partenerii sai si se definesc activitatile pentru interactiunea procesului cu lumea exterioara lui.
Procesele de afaceri definite in limbajul BPEL pot fi repartizate si executate utilizand o platforma ce implementeaza specificatiile acestui limbaj. O astfel de platforma este motorul BPWS4J oferit de AlphaWorks [MIND05
Arhitectura orientata pe servicii (Service-Oriented Arhitecture - SOA) exprima un concept de arhitectura software ce presupune folosirea serviciilor Web disponibile in scopul satisfacerii cerintelor utilizatorilor de software. Un sistem SOA poate fi implementat in multe moduri, folosind o varietate de instrumente si tehnologii. Tehnologia serviciilor Web, care constituie baza SOA, a fost adoptata de marea majoritate a jucatorilor din industria de software: IBM, Microsoft, Sun Microsystems, SAP, Oracle samd.
O platforma completa de tip SOA permite integrarea aplicatiilor de intreprindere, realizandu-se astfel implementarea simpla a proceselor de afaceri in cadrul companiilor. Intr-un mediu SOA, nodurile dintr-o retea asigura disponibilitatea resurselor ca servicii independente, pe care utilizatorii le acceseaza intr-un mod standardizat.
SOA implica mai mult decat conexiunile dintre serviciile Web sau setul de componente de afaceri ce ar urma sa fie livrat si care ar putea functiona impreuna. SOA determina, de fapt, obtinerea de beneficii gestionand proceselor de afaceri cu ajutorul aplicatiilor existente. SOA reprezinta viitorul serviciilor IT, o arhitectura orientata pe servicii permitand integrarea tuturor resurselor IT, inclusiv a aplicatiilor create prin tehnologii .NET sau Java.
Orientarea pe servicii reprezinta o noua metoda pentru proiectarea sistemelor distribuite. Conceptele principale folosite in cadrul acestei abordari sunt:
serviciu: unitate independenta a unei aplicatii care expune functionalitatea catre clientii din retea prin intermediul unei interfete bazate pe mesaje;
client: un modul al unei aplicatii care faciliteaza accesul utilizatorilor la functionalitatea oferita de servicii;
sistem distribuit: un sistem interconectat de servicii si clienti.
Sistemele orientate pe servicii sunt sisteme slab cuplate, proiectate pentru a permite schimbarea pentru adaptarea la noi cerinte sau metode de implementare. Prin utilizarea modelului orientat pe servicii este posibila obtinerea unei interoperabilitati intre aplicatii, indiferent de platformele si limbajele de programare utilizate in dezvoltarea acesteia. Dezvoltatorii de aplicatii nu au nevoie sa cunoasca tipul de sistem, modelul de obiecte sau protocoalele folosite de catre sistemele care trebuie integrate. Expunerea functionalitatii folosind protocoale standardizate si interfete care pot fi obtinute dinamic conduce la o cuplare slaba intre subsisteme, permitand astfel o conectare simpla si asigurand o flexibilitate sporita aplicatiei.
Implementarea SOA necesita o serie de componente, precizate detaliat in [NET09]. Pe scurt, aceste componente sunt:
serviciile de afaceri (Business Services): in mod normal, primul pas spre SOA este adoptarea serviciilor web. Acest lucru presupune expunerea aplicatiilor si a sistemelor deja existente prin intermediul interfetelor bazate pe standarde;
resgistrul (Registry): sistemul de inregistrari al unei SOA ce furnizeaza o modalitate de administrare a serviciilor de afaceri. Un registru retine descrierea detaliata a unui serviciu SOA si utilizeaza informatia respectiva intr-un serviciu de afacere de tip Registry;
managerul de politici (Policy Manager): produs bazat pe standarde ce simplifica procesul de creare, administrare si standardizare a politicilor necesare oricarei afaceri;
consola de adminostrare (Management Console): solutie de management ce permite utilizatorilor sa monitorizeze, sa administreze si sa securizeze serviciile Web sau procesele SOA in totalitate, dar si sa asigure managementul eficient al sistemelor "fragile" din punct de vedere tehnologic;
translatoare de mesaje: module software asezate inaintea oricarui serviciu astfel incat serviciile interne sa poata fi accesate in limbajul nativ al sistemului in cauza si in acelasi timp in acelasi limbaj pe ansamblu, de obicei XML, ca orice alt serviciu din retea.
La inceput, aceasta tehnologie nu era dominata, in aparenta, de o tendinta anume. Instrumentele de integrare nu erau diferentiate: exista unul singur pentru toate conexiunile. Pe masura ce conceptul SOA a evoluat, arhitectura s-a divizat in categorii cu insusiri diferite. La cel mai inalt nivel acestea sunt:
aplicatii fizice: programele care duc la bun sfarsit sarcinile;
servicii directoare: separa procesele de afaceri;
sincronizarea datelor: componenta folosita la construirea si intretinerea conexiunilor de date;
nivelul de procese de afaceri, care utilizeaza serviciile pentru a acoperi procesele specifice afacerii.
Aceste componente au functii si structuri diferite, de aceea se recomanda folosirea de tehnologii separate.
Un principiu fundamental al SOA se refera la faptul ca serviciul furnizat prin intermediul unei interfete trebuie sa ramana acelasi, pana la identitate, independent de implementare. Un serviciu de "detalii client", de exemplu, trebuie sa furnizeze aceeasi functie economica independent de faptul ca implementarea obiectului economic este realizata intr-o singura componenta partajata, peste mai multe platforme si sisteme anterior in functie, sau furnizata de la un partener comercial prin Internet.
Tehnologiile de livrare a aplicatiilor intrebuintate ulterior fac ca aceasta transparenta sa devina o problema dificila. Serviciile de apelare care sunt implementate in diferite tehnologii nu sunt directe, iar cuplarea stransa a interfetelor are ca semnificatie afectarea acestora (prin modificare lor) odata ce a aparut o schimbare in implementarea componentei. Schimbarea (modificarea) componentelor are ca efect, de asemenea, schimbari in ceea ce priveste aplicatiile de apelare, anuland astfel anumite beneficii asteptate de la proiectarea bazata pe componente.
Spre deosebire de arhitecturile traditionale orientate-obiect (object-oriented), SOA cuprinde servicii cuplate, dar independente, puternic interoperabile. Deoarece aceste servicii opereaza pe diferite platforme de dezvoltare (Java sau .NET), componentele software devin reutilizabile (de exemplu, un serviciu C# ar putea fi folosit de o aplicatie Java sau alt limbaj de programare), datorita faptului ca interfata a fost definita tinandu-se cont de standarde (Web Services Description Language - WSDL) din domeniu, care incapsuleaza (ascund) implementarea specifica fata de client/serviciu.
O caracteristica fundamentala a arhitecturii propuse este separarea definirii proceselor de integrarea back-end, separare ce permite analistilor sa se concentreze asupra dezvoltarii solutiilor pentru probleme specifice. Prin aceasta separare, este asigurata o arhitectura de tip "plug-and-play", un nivel de separare ce sigura schimbarea sistemelor de tip back-end fara schimbarea proceselor [NET18].
Arhitectura orientata pe servicii a fost dezvoltata pentru a solutiona problemele legate de integrare si automatizarea proceselor interne si externe cu alte companii sau parteneri in retea. Scopul final este de a avea o arhitectura IT care acopera in mod optimal cerintele prezente si viitoare, respectiv integrarea interna EAI si externa G2B, G2C, G2G, WebServices.
Arhitectura conceptuala indeplineste o serie de criterii pentru validarea ulterioara a conceptelor, tehnologiei si produselor, care asigura:
integrarea tuturor functiilor relevante si a proceselor;
integrarea sistemelor existente in noua platforma, asigurand protectia investitiilor;
minimizarea riscului, reactie rapida la schimbarea cerintelor;
complexitate redusa prin construirea unei interfete bazate pe servicii specifice integrate in sistem;
utilizarea standardelor XML, XSL, SOAP, UDDI, WSDL si HTTP;
flexibilitate;
abilitatea de extindere in conformitate cu necesitatile - scalabilitate;
reducerea costurilor si cresterea productivitatii prin transferul rapid al aplicatiilor de pe orice platforma.
Prin procese de afaceri construite pe o arhitectura orientata pe servicii, o companie poate exploata aplicatiile software existente, astfel incat sa atinga un grad superior de interoperabilitate nu doar intre toate departamentele firmei ci si cu alte companii. Aceasta abordare valorifica resursele existente pentru a ajuta la imbunatatirea productivitatii, permitand astfel companiei sa reactioneze rapid la schimbarile intervenite pe piata, fructificand astfel oportunitatile de afaceri.
Beneficiile arhitecturii orientate pe servicii
O arhitectura orientata pe servicii contine servicii web pe care dezvoltatorii le creeaza intr-un nivel de servicii specific. Serviciile pe care acestia le dezvolta dispun de interfete publicate, ce se adreseaza unei anumite zone de afaceri. Organizatiile care isi concentreaza eforturile pe integrarea de servicii, vor avea parte de numeroase beneficii.
Recuperarea rapida a investitiilor. Un nivel de servicii robust are avantajul unei recuperari rapide si substantiale a investitiilor aduse in construirea componentelor software. Serviciile individualizeaza domeniile distincte ale afacerii. De exemplu, o companie creeaza un serviciu ce dispune de toate metodele necesare pentru a administra stocurile. Asezand logica afacerii (datele) intr-un nivel separat, acesta poate exista independent de orice alt sistem in care este integrat. Un alt exemplu se poate referi la nevoia unei organizatii de a crea un serviciu pentru autorizarea cartilor de credit. Dezvoltatorii vor introduce functionalitatea respectiva in aplicatia care are nevoie de ea sau intr-o componenta independenta.
Mobilitatea codului. Deoarece transparenta locatiei este o proprietate a arhitecturii orientate spre servicii, mobilitatea codului devine realitate. Conectarea dinamica la un serviciu inseamna ca activitatea utilizatorului nu este influentata de locatie (a lui sau a serviciului pe care il foloseste). De aceea, o organizatie are flexibilitatea necesara pentru a muta servicii pe o masina diferita sau catre un furnizor extern.
Functionalitati specializate pentru dezvoltatori. Arhitectura orientata spre servicii va forta aplicatia sa fie organizata pe mai multe niveluri, fiecare cu un rol specific pentru dezvoltatori. Un dezvoltator de aplicatii client trebuie sa cunoasca tehnologii precum SWING, JSP sau .NET. Fiecare nivel necesita un set complex de cunostinte. Avand aceste delimitari de specializare, dezvoltatorii vor excela in domeniul particular in care activeaza. Companiile vor avea la randul lor de castigat, nefiind nevoite sa mai apeleze la specialisti cu o bogata experienta in dezvoltarea de aplicatii.
Securitate marita. Crearea unui nivel de servicii inseamna de fapt construirea unei interfete de retea aditionala ce poate fi folosita de mai multe aplicatii. Cand sistemele erau construite prin metode monolitice sau client-server, problema securitatii era abordata in front-end. De multe ori companiile nu mai implementau componente de securitate din cauza cheltuielilor de intretinere. Pe de alta parte, serviciile sunt folosite de multe aplicatii, asa ca dispun de propriul mecanism de securitate. De aceea fiecare program va avea mai multe niveluri de autentificare pentru aplicatia client de serviciu.
Teste superioare - mai putine erori. Dezvoltatorii au la dispozitie instrumente precum JUnit pentru crearea de teste. Acestea pot fi rulate pentru a valida serviciul, independent de orice aplicatie care il foloseste. O practica foarte buna este aplicarea de teste in timpul unui proces automat. Mai multe teste inseamna, de obicei, mai putine erori si o crestere pe ansamblu a calitatii.
Suport pentru mai multe tipuri de clienti. Un alt beneficiu al SOA este posibilitatea companiilor de a folosi o varietate de clienti pentru accesarea unui serviciu. Un PDA ce foloseste J2ME poate accesa un anumit serviciu prin HTTP, iar un client SWING poate accesa acelasi serviciu via RMI. Avand in vedere faptul ca nivelurile de aplicatii client sunt separate de servicii, noi tipuri de clienti pot fi implementati cu usurinta.
Asamblarea serviciilor. Utilizatorii vor ajunge sa inteleaga serviciile ca pe niste bunuri refolosibile, ce pot fi combinate intr-o multitudine de moduri. Utilitatea va consta in dezvoltarea mai rapida de noi aplicatii.
Mentenanta superioara. Prin orientarea spre servicii, ca locatie a logisticii, operatiunile de mentenanta se imbunatatesc deoarece dezvoltatorii pot localiza defectele de cod mai usor.
Scalabilitate. O cerinta importanta pentru arhitecturile orientate spre servicii este transparenta locatiei. Pentru a obtine aceste lucru, aplicatiile cauta servicii intr-un director si se conecteaza la ele dinamic. Aceasta situatie caracterizeaza scalabilitatea, intrucat cererile de conectare pot fi inaintate fara interventia clientului de serviciu.
Fara indoiala instalarea unui nivel de servicii presupune un efort suplimentar la inceputul proiectului, dar beneficiile pe termen lung sunt evidente.
Oracle Application Integration Architecture (OAIA), arhitectura lansata in aprilie 2007, ofera procese de afaceri care leaga compartimentele operationale, crescand eficienta costurilor si reducand ciclul de viata. Oracle ofera solutii prefabricate de integrare a proceselor, suport si optimizari pe parcursul acestor integrari, implementand si utilizand cele mai bune practici de afaceri pentru conectarea si optimizarea operatiilor afacerii.
Avantaje oferite:
solutii prefabricate de integrare care reduce costul integrarii sistemelor si minimizeaza riscurile;
cele mai bune practice de afaceri bine documentate sunt disponibile pentru integrare in aplicatiile existente;
arhitectura deschisa, bazata pe standarde.
OAIA se bazeaza pe facilitatile oferite de Oracle Fusion Middleware, si include metodologia si instrumentele din SOA, impreuna cu un depozit de servicii de afaceri (Business Service Repository) care permite dezvoltarea sau extinderea aplicatiilor.
Enterprise Services Architecture (ESA) este interpretarea pe care SAP a dot-o unei arhitecturi SOA care extinde conceptul de serviciu Web, inlocuindu-l cu conceptul propriu de serviciu al intreprinderii (enterprise service). Din punct de vedere tehnic, serviciile de intreprindere se bazeaza pe servicii Web, oferind acces la elementele si functiile afacerii in termeni economici. Utilizarea serviciilor de intreprindere in cadrul aplicatiilor conduce la o crestere a flexibilitatii, deschiderii si vitezei.
Bazate pe standarde deschise, serviciile de intreprindere incapsuleaza functionalitatile intreprinderii si le expune ca servicii reutilizabile, care pot fi apoi combinate cu alte servicii pentru a raspunde unor cerinte noi. Serviciile de intreprindere pot fi rapid combinate pentru a compune noi aplicatii si a sprijini noi procese de afaceri.
Aceste servicii pot comunica logica de afaceri intre aplicatii care ruleaza pe platforme disparate. Utilizand aceste servicii, se poate raspunde mai rapid la schimbarile care apar in cadrul firmelor, si se pot reduce costurile prin reutilizarea fuctionalitatilor deja existente.
Organizatiile pot adopta aceasta arhitectura prin implementarea platformei SAP NetWeaver. SAP are chiar un program de adoptare SOA, prin care asista organizatiile doritoare la elaborarea si implementarea planului de adoptare SOA. SAP ofera atat solutiile software orientate pe servicii, cat si platforma tehnologica SAP Netweaver si asistenta altor companii care doresc sa isi dezvolte propriile arhitecturi orientate pe servicii, pentru solutii SAP si non-SAP.
Tehnologiile care permit realizarea integrarii aplicatiilor in cadrul unei intreprinderi constituie ceea ce se numeste in limbajul de specialitate middleware [NET17 Cea mai buna abordare in incercarea de definire a middleware-ului este pe baza functiilor sale. Middleware este un mecanism care permite unei entitati (baza de date sau aplicatie) sa comunice cu o alta entitate (sau cu mai multe entitati). Cu alte cuvinte, middleware este un tip de software care faciliteaza comunicatia intre doua sau mai multe sisteme software.
Desi este un termen utilizat pentru a desemna mai multe subcategorii de tehnologii, in prezent, pentru realizarea unei aplicatii formate din mai multe componente distribuite se utilizeaza cu precadere fie tehnologiile orientate-obiect reprezentate in standardele CORBA sau DCOM, fie tehnologia Java si conceptul de componenta Java Bean. Cu ajutorul acestor tehnologii se realizeaza cele mai multe servere de aplicatii din categoria celor ce trebuie sa satisfaca cerinte severe de performanta si disponibilitate.
Folosirea tehnologiilor middleware in cadrul integrarii aplicatiilor este posibila datorita existentei urmatoarelor doua elemente:
conceptul de interfata care caracterizeaza fiecare componenta conectata la magistrala middleware si permite descrierea ansamblului de servicii oferite de catre infrastructura; in cadrul EAI, interfetele sunt construite la nivelul adaptoarelor asociate aplicatiilor;
metodologia orientata-obiect permite construirea unui model de interfete, care sa raspunda necesitatilor utilizatorilor si sa contribuie la reducerea nivelului de complexitate necesar crearii si gestionarii sistemelor distribuite [SARU00].
Tehnologia middleware poate fi utilizata pentru urmarirea si administrarea ciclurilor de viata si pentru asigurarea politicilor in cadrul mediilor de dezvoltare integrate.
Exista doua modele de middleware: logic si fizic. Modelul logic descrie cum are loc transferul de date conceptual, iar modelul fizic descrie metodele precum si tehnologia folosite pentru transferul de informatie. Configuratiile asociate modelului logic sunt:
unu la unu,
multi la multi si
sincron versus asincron.
Modelului fizic ii sunt asociate modele bazate pe mesaje.
Middleware unu la unu foloseste o conexiune software temporara intre doua programe sau comenzi (pipe) pentru a permite unei aplicatii sa acceseze alta aplicatie. Consideram, spre exemplu, doua aplicatii A si B. Cand aplicatia A incearca sa comunice cu aplicatia B inchide conexiunea folosind o procedura de apel sau un mesaj (figura 4.11).
Asa cum sugereaza numele, middleware-ul multi la multi, leaga mai multe aplicatii intre ele. Aceasta capacitate il face cel mai potrivit pentru integrarea aplicatiilor. In plus, este cel mai puternic middleware logic, deoarece ofera atat flexibilitate cat si adaptabilitate problemei integrarii.
Figura 4.11. Configuratia unu la unu
Sunt mai multe exemple de middleware multi la multi: integrare la nivel de servere, middleware tranzactional (servere aplicatii si monitori TP) si chiar obiecte distribuite. Practic, orice tip de middleware care poate sa lucreze cu mai multe de doua aplicatii sursa si destinatie in acelasi timp poate sustine acest model (figura 4.12).
Figura 4.12. Configuratia multi la multi
Avantajul modelului unu la unu este simplitatea, modelul multi la multi avand dezavantajul complexitatii. Aceasta problema este atenuata de noua generatie de middleware.
Middleware-ul asincron face transferul de informatie intre mai multe aplicatii in mod asincron, ceea ce presupune ca software-ul middleware se poate deconecta de la aplicatia sursa sau destinatie. Aplicatiile nu sunt dependente de alte aplicatii conectate pentru procesare. Procesul care permite acest lucru are aplicatiile plasate intr-o coada de asteptare, fiecare cu un mesaj asociat si fiecare ruleaza independent, raspunsul de la celelalte aplicatii primindu-se mai tarziu. Avantajul principal este acela ca middleware-ul nu blocheaza celelalte aplicatii din procesare. Mai mult decat atat, deoarece middleware-ul se decupleaza de la aplicatie, aceasta poate sa continue procesarea, indiferent de stadiul celorlalte aplicatii.
Pe de alta parte, middleware-ul sincron, este strans cuplat la aplicatii. Aplicatiile sunt dependente de middleware pentru a procesa unul sau mai multe apeluri functie pe o aplicatie la distanta. Ca rezultat, aplicatia care apeleaza trebuie sa opreasca procesarea pentru a astepta raspunsul aplicatiei aflate la distanta. Acest tip de middleware este referit ca unul care "blocheaza". Dezavantajul acestui model este cuplarea aplicatiilor la middleware si la aplicatia la distanta.
Modelele middleware au avut o evolutie continua inca de la aparitie, ceea ce duce la ivirea unor dificultati de a le incadra in anumite categorii. Cu toate acestea, se observa existenta catorva tipuri de middleware care se pliaza foarte bine pe rezolvarea anumitor tipuri de probleme. Urmatoarele tipuri de middleware vor fi descrise in continuare: RPC, MOM, obiecte distribuite, middleware orientat pe baza de date, middleware tranzactional (include monitori TP si servere de aplicatii) si servere de integrare.
Remote Procedure Calls (RPC) reprezinta cel mai vechi tip de middleware, usor de inteles si de folosit. Acesta ofera dezvoltatorilor capacitatea de a apela o functie dintr-un program si de a o executa intr-un alt program, pe o masina la distanta (figura 4.13). Pentru dezvoltator, functia se executa local, faptul ca aceasta este de fapt executata pe masina aflata la distanta fiind ascuns.
Figura 4.13. Functionarea RPC
RPC sunt modele sincron de middleware. Pentru ca RPC sa fie activat, executia programului trebuie oprita. In ciuda simplitatii, majoritatea RPC-urilor nu au o performanta foarte buna. Cum majoritatea transferurilor de informatie necesita o retea, un middleware de tip RPC foloseste toate resursele retelei. Un RPC tipic necesita 24 de pasi distincti pentru a indeplini cererile. Acest nivel de performanta limiteaza beneficiile unui apel RPC intr-o retea inceata, cum este Internetul.
Middleware-ul orientat pe mesaje (MOM) este un software care foloseste mesaje, unitati de informatie (de tip BYTE), care sunt interschimbate de aplicatii, ca pe un mecanism de a face transfer de informatie de la un punct la altul. Deoarece MOM foloseste mesajele pentru a realiza comunicarea intre aplicatii, nu este necesara cuplarea aplicatiilor la middleware (se bazeaza pe modelul asincron). Mesajul intra astfel intr-o coada manager (figura 4.14), care hotaraste cand este trimis mesajul la destinatia finala. Mesajele care se intorc la aplicatia apelanta vor fi prelucrate cand aplicatia va fi disponibila. Dezvoltatorii considera ca utilizarea mesajelor MOM este destul de usor de urmarit si organizat.
Mesajele au o structura (schema) si un continut (date). Se pot asemana cu o baza de date cu o singura inregistrare care se deplaseaza intre aplicatii printr-un mecanism de schimb de mesaje. Exista doua tipuri de modele MOM: unu la unu si coada de mesaje (Message Queue - MQ). MQ permite fiecarui program participant sa lucreze fara a fi intrerupt de nivelul middleware. Deoarece software-ul MQ (seria MQ de la IBM, MSMQ de la Microsoft) gestioneaza distributia de mesaje de la un program la altul, coada manager poate optimiza performanta folosind metode de acordare a prioritatii.
Figura 4.14. Middleware orientat pe mesaje
In vederea indepartarii pericolului ca mesajele sa se piarda atunci cand are loc o cadere de sistem, majoritatea modelelor MQ permite ca mesajele sa fie declarate drept persistente sau stocate pe disc la anumite intervale de timp, oferind astfel un nivel de protectie.
Obiectele distribuite sunt clasificate ca fiind middleware deoarece faciliteaza comunicarea intre aplicatii. Obiectele distribuite sunt programe-aplicatii de mici dimensiuni care folosesc interfete si protocoale standard pentru comunicare. De exemplu, daca se creeaza un obiect distribuit CORBA care ruleaza pe un sever UNIX si un altul care ruleaza pe un server NT, folosind un protocol standard de comunicatie, obiectele pot face interschimb de informatie si functii (acelasi standard - CORBA, acelasi protocol - IIOP (Internet InterORB Protocol)).
Exista doua tipuri de obiecte distribuite: CORBA si COM (Component Object Model). CORBA este creat de OMG in 1991 si este mai mult un standard decat o tehnologie oferind specificatii pentru crearea unui obiect distribuit. COM este creat de Microsoft si include interfete standard si protocoale de comunicatie.
Middleware-ul orientat pe baza de date se refera la orice middleware care faciliteaza comunicatia fie cu o baza de date, fie cu o aplicatie, fie intre mai multe baze de date. Dezvoltatorii folosesc acest tip de middleware ca pe un mecanism de extragere a informatiei dintr-o baza de date locala sau la distanta. De exemplu, pentru a extrage informatia dintr-o baza de date Oracle, dezvoltatorul trebuie sa apeleze un astfel de middleware astfel incat sa poata realiza autentificarea la baza de date, cererea de informatie si procesarea informatiei care a fost extrasa din baza de date (4.15).
Middleware-ul orientat pe baza de date lucreaza cu doua tipuri de baze de date: CLI (Call Level Interface) si middleware nativ pe baza de date.
CLI reprezinta API-uri comune, care ofera acces la baze de date folosind o interfata bine definita. De obicei, CLI lucreaza cu baze de date relationale. Acesta este si cazul Open DataBase Connectivity (ODBC) de la Microsoft. ODBC foloseste o interfata pentru a facilita accesul la o baza de date si drivere pentru a gestiona diferentele dintre bazele de date. De asemenea, ofera acces simultan la baze de date multiple, arhitectura ODBC presupunand existenta unui driver manager care sa faciliteze comunicatia intre diferite baze de date.
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 interfata standard care foloseste un singur set de metode Java pentru a facilita accesul la baze de date multiple. JDBC se aseamana cu ODBC si functioneaza de pe orice aplicatie Java: applet, servlet, Java Server Pages (JSP), Enterprise JavaBean (EJB).
Monitorii TP sunt prima generatie de servere de aplicatii, la fel ca si produsele middleware de tip tranzactional. Acestea ofera un mecanism pentru a facilita comunicarea intre doua sau mai multe aplicatii (figura 4.16), precum si o locatie pentru logica aplicatiei. Exemple de TP includ Tuxedo de la BEA Systems, MTS de la Microsoft, CICS de la IBM.
Figura 4.16. Monitor TP
Monitorii TP se bazeaza pe tranzactii, vazute ca unitati de lucru cu un inceput si un final. O tranzactie are doar doua stari: poate sa fie ori finalizata, ori anulata complet. In acest ultim caz, daca tranzactia a actualizat resurse aflate la distanta (baze de date, cozi), aceste actualizari vor fi anulate de asemenea.
TP asigura doua servicii importante. Pe de o parte, TP ofera servicii care garanteaza integritatea tranzactiilor (serviciul de tranzactie), iar pe de alta parte, un monitor TP asigura managementul resurselor si servicii de management pe termen lung (serviciul de aplicatie). Cele doua servicii sunt ortogonale.
De asemenea, monitorii TP ofera conectori la resurse ca baze de date, alte aplicatii sau cozi. Acesti conectori necesita o dezvoltare de aplicatie sofisticata pentru a comunica cu tipurile variate de resurse. Odata conectate, aceste tipuri de resurse sunt integrate in tranzactii. Ca urmare, acesti conectori pot fi reconstituiti daca apare o cadere de sistem.
Serverele de aplicatie definesc segmentul pietei de middleware cu cea mai rapida evolutie. Cu toate acestea, tehnologia serverelor de aplicatii nu este noua (monitorii TP pot fi considerati servere de aplicatii datorita caracteristicilor comune). Majoritatea serverelor de aplicatii sunt middleware Web si proceseaza tranzactii apartinand aplicatiilor Web. Noutatea acestor servere de aplicatii este ca folosesc limbaje moderne, cum este Java, in locul celor traditionale procedurale, cum sunt C sau Cobol (ceea ce se intampla la monitorii TP).
Mai simplu, serverele de aplicatii asigura posibilitatea accesului la alte aplicatii si fac posibila procesarea si stabilirea resurselor necesare conexiunilor. Aceste resurse includ baze de date, aplicatii ERP si chiar aplicatii traditionale de tip mainframe. Serverele de aplicatii ofera interfetei utilizator mecanisme de dezvoltare. In plus, in cele mai multe cazuri ofera si mecanisme de amplasare a aplicatiilor pe platforma Web (4.17).
Figura 4.17. Arhitectura unui server de aplicatie tipic
Producatorii de servere de aplicatii considera ca produsele lor au o tehnologie ce permite rezolvarea problemelor de integrare a aplicatiilor. Ca urmare, serverele de aplicatie, ca si monitorii TP, joaca un rol important in domeniul integrarii aplicatiilor. Multi dintre producatori incorporeaza tehnologii de gestiune a mesajelor, transformare si rutere inteligente, servicii care sunt native serverelor de integrare.
Serverele de integrare reprezinta partea de varf a tehnologiei middleware pentru integrarea aplicatiilor sau cel putin potentialul acesteia. Serverele de integrare pot facilita schimbul de informatie intre doua sau mai multe aplicatii sursa sau destinatie si pot face diferenta intre semanticele aplicatiei si platforme. Ca urmare, aceasta tehnologie se potriveste perfect cu integrarea aplicatiilor.
Figura 4.18. Servere de integrare
Serverele de integrare pot aparea in multe aplicatii folosind reguli comune si motoare de rutere. Ele pot transforma schema si continutul informatiei pe durata transferului intre aplicatii si baze de date.
Serverele de integrare sunt servere care gestioneaza mesaje intre doua sau mai multe aplicatii sursa sau destinatie. In plus, aceste servere transforma schemele de mesaje si modifica continutul mesajelor. Serverele de integrare pot avea intr-adevar functii aditionale, incluzand un motor si o interfata de integrare a proceselor, precum si un mecanism de management.
Importanta serverelor de aplicatii este stabilita in functie de pozitia ocupata de acestea in cadrul companiei. In general, dupa cum este evidentiat si in figura 4.18, serverele de integrare nu sunt o tehnologie de dezvoltare a aplicatiilor ci mai degraba una care permite comunicarea intre mai multe aplicatii, fara sa presupuna existenta unui schimb de informatii despre natura aplicatiilor intre care se face schimbul de date. Pe scurt, serverele de integrare gestioneaza informatia intre baze de date si aplicatii.
Java este un limbaj de programare de nivel inalt, orientat-obiect, care a fost proiectat initial pentru realizarea de aplicatii pentru Internet. Acesta este utilizat in prezent cu succes si pentru programarea aplicatiilor destinate Intranet-urilor. In acest sens, multe firme recurg la limbajul Java in procesul de informatizare intrucat ofera un foarte bun suport pentru tehnologiile de varf si, nu in ultimul rand, pentru faptul ca este gratuit si in mod continuu imbogatit si imbunatatit.
"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 platforma. La modul ideal, aceasta inseamna ca un program Java poate fi dezvoltat pe orice platforma, compilat in formatul standard bytecode si apoi rulat de pe orice sistem care are in prealabil instalata masina virtuala Java (Java Virtual Machine - JVM).
Legatura care s-a creat intre Internet si Java a condus la situatia in care majoritatea companiilor care dezvolta aplicatii pentru Internet sa considere Java ca limbaj de implementare, in acest moment Java nefiind un limbaj de programare obisnuit, ci desemnand un ansamblu de tehnologii care permit trecerea de la o abordare a aplicatiilor desk-centric, la network-centric, realizandu-se platforme de calcul deschise si universal accesibile din Internet.
Prin urmare, trecerea conceptului Java din sfera limbajului de programare in cea a tehnologiilor si a platformelor de tehnologii nu devine improprie. Tehnologia Java sta la baza celor mai performante solutii de dezvoltare a aplicatiilor de intreprindere si controleaza cu adevarat functionalitatea unei retele prin faptul ca este in acelasi timp un limbaj de programare precum si o selectie de platforme specializate. Prin aceste caracteristici, Java standardizeaza dezvoltarea si implementarea unor aplicatii securizate, portabile, stabile si scalabile.
Caracteristicile limbajului Java
Caracteristicile limbajului Java sunt numeroase, drept pentru care vor fi prezentate cele mai semnificative, pornind de la articolul [STAN01]:
usor de utilizat - atat pentru avansati cat si pentru incepatori;
simplu - fiind indepartate aspectele derutante din C++, cum ar fi supraincarcarea operatorilor si mostenirea multipla; a fost introdus un colector automat de deseuri care rezolva problema dealocarii memoriei in mod uniform, fara interventia programatorului;
independent de platforma - compilatorul Java furnizeaza o secventa de instructiuni ale unei masini virtuale Java, iar executia aplicatiilor este interpretata;
viteza scazuta de executie - caracteristica a limbajelor interpretate fata de cele compilate. Pentru cresterea acestei viteze se poate cere mediului de executie Java sa genereze automat, plecand de la codul masinii virtuale, un executabil nativ platformei respective. De obicei, in Java se compileaza doar partile mari consumatoare de timp, celelalte fiind interpretate;
interpretorul Java - este gandit pentru a lucra pe masini mici, iar impreuna cu bibliotecile standard sa nu depaseasca 300KB;
orientat-obiect - deoarece se pot crea clase de obiecte si instante ale acestora, se pot incapsula informatii, se pot mosteni variabile si metode de la o clasa la alta. Suplineste mostenirea multipla (care lipseste) cu interfata, care permite definirea unui anumit comportament pentru a crea o clasa de obiecte, altul decat cel standard. In Java orice element este obiect, cu exceptia datelor primare si lipsesc functiile si variabilele globale;
distribuit - are implementate biblioteci pentru lucrul in reteaua TCP/IP, suporta URL si incarcarea resurselor din retea; aplicatiile Java pot accesa foarte usor reteaua, prin apelurile catre un set standard de clase;
robust - legarea functiilor se face in timpul executiei, iar informatiile de compilare sunt disponibile pana in momentul rularii aplicatiei. Astfel sistemul poate determina in orice moment neconcordanta dintre tipul referit la compilare si cel referit in timpul executiei, evitandu-se intruziunile in sistem prin intermediul referintelor falsificate. De asemenea, pointerii lipsesc (impreuna cu aritmetica lor), eliminand inca o sursa principala de erori, iar eliberarea memoriei ocupate de obiecte si tablouri se face automat, evitandu-se incercarile de eliberare multipla a zonei de memorie;
securitate ridicata - prin verificarea codului la fiecare incarcare, prin mecanisme de Cyclic Redundancy Check (CRC) si prin verificarea operatiilor disponibile pentru fiecare set de obiecte, robustete, incorporarea protectiei obiectelor la citire/scriere. Verificarea se face in timpul executiei, mediul de executie Java putand fi configurat pentru a proteja reteaua locala, fisierele si celelalte resurse ale calculatorului pe care ruleaza aplicatia Java;
multithreading - suport nativ pentru aplicatii care lucreaza cu mai multe fire de executie, inclusiv primitive de sincronizare intre firele de executie, independent de platforma;
dinamic - bibliotecile de clase in Java pot fi reutilizate cu mare usurinta, variabilele sunt legate doar in faza de executie, rezolvand problema fragilitatii superclasei din C++, regasirea variabilelor se face prin nume si nu prin deplasament fix; se elimina necesitatea actualizarii aplicatiilor, datorata aparitiei unei noi versiuni de biblioteca.
Java furnizeaza un cadru de lucru curat, format din mai multe straturi diferite care creeaza mediul de executie Java. Aceste straturi sunt: limbajul de programare, biblioteca standard API, compilatorul Java, codul specific (bytecode), mecanismul pentru incarcarea dinamica si verificarea bibliotecilor, automatul de colectare a deseurilor (garbage collector), masina virtuala universala pentru executarea bytecode-ului - Java Virtual Machine (JVM).
Limbajul Java poate fi considerat unul din cele mai populare si mai versatile limbaje de programare, mai ales daca ne gandim la rolul lui in cadrul spatiului World Wide Web. Rezultat al distilarii celor mai bune practici in proiectarea de limbaje de programare orientate-obiect, Java a adus cu sine si o libertate de necontestat in ceea ce priveste alegerea elementelor de design, implementare si exploatare a aplicatiilor concepute in acest limbaj.
Platformele Java se pot clasifica in: Java 2 Micro Edition (J2ME), Java 2 Standard Edition (J2SE) si Java 2 Enterprise Edition (J2EE). Acestea se utilizeaza dupa cum urmeaza (figura 4.19):
J2ME - mediul pentru dezvoltarea aplicatiilor Java pentru micro-dipozitive;
J2SE - mediul standard pentru dezvoltarea aplicatiilor Java. Sunt disponibile pachetele de baza ale limbajului Java, necesare realizarii aplicatiilor desktop;
J2EE - mediul Java pentru dezvoltarea aplicatiilor de intreprindere. Se ofera un foarte bun suport pentru utilizarea serverelor de aplicatii.
Figura 4.19. Platforme Java
Pentru toate tipurile de aplicatii se remarca avantajul tehnologiei Java: codul se scrie o singura data dar ruleaza pe orice sistem - "Write once, run anywhere".
Java 2 Micro Edition (J2ME) este un mediu Java puternic optimizat ce tinteste spre o larga varietate de produse de larg consum, incluzand pagere, telefoane celulare, agende electronice de buzunar si sisteme de navigatie pentru automobile. O aplicatie scrisa in tehnologia Java 2 Micro Edition poate fi folosita pe orice echipament HandHeld (PDA) sau pe orice telefon mobil cu suport Java. Totodata, editia J2ME defineste si o implementare complet noua a masinii virtuale Java optimizata pentru dispozitivele mobile (Kilobyte Virtual Machine - KVM).
Java 2 Enterprise Edition (J2EE) este o platforma Java creata de Sun Microsystems, utilizata pentru a dezvolta, utiliza si administra aplicatiile multi-nivel (multi-tier). Aplicatiile J2EE sunt aplicatii dezvoltate pe 3 straturi: aplicatie-client, server de aplicatie si server de baza de date. Noutatea este aparitia serverului de aplicatie pe care sunt EJB-urile, acestea fiind programe scrise in Java care reprezinta aproximativ 60% din aplicatie.
Fiind dezvoltata in Java, J2EE este o platforma independenta de sistemul de operare, avand cerinte hardware minime. Un avantaj important al J2EE se refera la faptul ca dezvoltarea aplicatiilor este mult simplificata, iar necesitatea programarii efective prin scrierea de cod este redusa, intrucat sunt disponibile module de componente standardizate, reutilizabile.
Aplicatiile Internet J2EE se pot baza atat pe servere open source (Apache Tomcat, Jetty, JBoss) cat si pe servere performante cu renume (IBM WebSphere Application Server, Bea WebLogic Server, Oracle Application Server). Aceasta caracteristica aduce avantajul unui buget flexibil alocat aplicatiei respective.
In cazul sistemelor desktop, Java 2 Standard Edition (J2SE), aceeasi aplicatie poate rula pe orice sistem de operare, atat Windows/Machintosh, cat si variante Unix/Linux.
J2EE este un standard initiat de catre Sun Microsystems si sustinut de parteneri importanti, dintre care cel care a investit cel mai mult este IBM. Unul dintre obiectivele crearii limbajului de programare Java a fost independenta de platforma, deziderat realizat prin crearea de JVM specifice sistemelor de operare. Odata cu dezvoltarea tehnologiei Internet a aparut necesitatea redarii de continut dinamic in paginile Web. Raspunsul tehnologiei Sun, orientata Java, la aceasta noua provocare a fost aparitia tehnologiilor Servlet si Java Server Pages (JSP). In paralel a aparut si tehnologia Entrepise JavaBeans (EJB), iar mai tarziu, incepand din anul 2004, Java Server Faces (JSF).
Standardul J2EE sta la baza celor mai robuste platforme pentru dezvoltarea de aplicatii de intreprindere. J2EE reprezinta un set de specificatii de construire a unor aplicatii pe niveluri multiple, folosind limbajul de programare Java. In ultimii ani, experienta acumulata de dezvoltatori si aparitia de noi standarde au contribuit la continua imbunatatire a platformei J2EE.
Norma J2EE a aparut ca raspuns la nevoia de a extinde ideea de portabilitate de la nivelul limbajului (Java) la nivelul serverelor de aplicatie. In afara de portabilitate, J2EE prezinta o serie de alte avantaje, cum ar fi dezvoltarea orientata pe componente, separarea containerelor etc.
Securitatea este incorporata in tehnologia J2EE, serverul de baze de date fiind accesat numai prin intermediul serverului de aplicatie, ceea ce face ca utilizatorul sa nu aiba acces direct la baza de date, ci numai prin aplicatie.
Securizarea unei aplicatii de intreprindere conform normei J2EE se face pe baza unor standarde, in cadrul carora se pune accent pe separarea autentificarii de autorizare. Securizarea se poate face pe doua niveluri: declarativ si aplicativ [BARC 05].
In cadrul implementarii securitatii declarative a unei aplicatii J2EE, prima etapa este autentificarea in care utilizatorul furnizeaza un nume de utilizator si o parola pentru a i se valida identitatea. Securizarea declarativa impiedica sau acorda accesul utilizatorilor asupra resurselor Web ale aplicatiei. Pentru a avea o aplicatie corecta din punct de vedere functional, acest lucru nu este suficient. Astfel, daca un utilizator nu are acces la o pagina, butonul care acceseaza pagina respectiva trebuie sa nu fie vizibil pentru utilizatorul in cauza. Acest lucru este realizat prin implementarea securitatii aplicative, prin API-urile suportate de catre norma J2EE si care permit testarea rolului unui utilizator autentificat. Important este de retinut faptul ca odata ce utilizatorul s-a autentificat pe aplicatie nu se mai testeaza asupra ID-ului sau ci asupra apartenentei sale la un rol sau altul. Securitatea aplicativa intregeste astfel ansamblul de facilitati puse la dispozitia dezvoltatorului de catre implementarile normei J2EE pentru o gestiune completa a securitatii unei aplicatii.
Implementarea celor mai bune practici implica in mod uzual adaugarea a numeroase noi coduri, ceea ce poate constitui un obstacol pentru cei care isi dezvolta primele aplicatii J2EE. Modalitatea de a elimina aceste obstacole este folosirea unui cadru de lucru ce abstractizeaza elementele de complexitate ale platformei J2EE si pune in valoare beneficiile acestui mediu. Un astfel de mediu de dezvoltare este oferit de Oracle Application Development Framework, inclus in produsul Oracle JDeveloper 10g.
Nucleul J2EE include: Java Server Pages (JSP), Servlets, Enterprise JavaBeans (EJB) si servicii Web, arhitectura platformei fiind evidentiata in figura 4.20:
Figura 4.20. Arhitectura J2EE
Tehnologia Java Server Pages (JSP) este cea mai populara metoda de a crea interfete Web pentru aplicatiile care ruleaza pe platforma Java. Ea se bazeaza pe tehnologia numita Java Servlets fiind, de fapt, o completarea a acesteia in ideea crearii cat mai facile a paginilor Web dinamice.
Tehnologia JSP a aparut pentru a acorda dinamicitate paginilor statice HTML si pentru a evita scrierea de cod HTML in servlet-uri. Exista la ora actuala o multitudine de medii de programare care pot gestiona vizual compozitia unei pagini JSP, obtinand castiguri foarte importante in productivitate fata de generarea dinamica a codului HTML in cadrul unui servlet.
Punctul central al tehnologiei o reprezinta asa-numitele pagini JSP care sunt, practic, fisiere text care combina descrieri HTML cu cod Java. Paginile JSP sunt gestionate si accesibile prin intermediul unui server de aplicatii. Acesta primeste cereri venite prin HTTP de la un browser Web. Daca o cerere refera o pagina JSP, serverul prelucreaza local pagina respectiva si, in functie de continutul acesteia, genereaza dinamic o pagina HTML pe care o trimite, ca raspuns, browser-ului. Este important de retinut faptul ca toate prelucrarile legate de paginile JSP se fac pe partea de server, acestea nefiind niciodata transmise in forma originala catre client. In plus, trebuie retinut faptul ca serverul de aplicatii include si o masina virtuala Java in care ruleaza atat codul Java intalnit in paginile JSP cat si obiectele instantiate de acesta.
Paginile JSP prezinta avantaje fata de servlet-uri deoarece permit separarea continutului static HTML al paginii de continutul generat dinamic, iar scrierea continutului HTML direct (nu prin intermediul operatiilor de print, ca in servlet) este mult mai simpla si mai intuitiva. Codul Java existent se converteste intr-un servlet care construieste partea dinamica de raspuns si aceasta parte se combina cu partea statica din pagina JSP pentru a forma pagina HTML de raspuns catre client.
Caracteristicile principale ale tehnologiei JSP, evidentiate si in lucrarea [VELI03] sunt:
poate functiona pe o multitudine de servere si este independenta de platforma pe care ruleaza, intrucat scripturile JSP au la baza limbajul Java;
separa logica aplicatiei (construita cu alte tipuri de tehnologii - servlet, JavaBeans etc.) de interfata cu utilizatorul (aspectul paginilor Web);
permite reutilizarea unor componente generate cu alte tehnologii atat independent cat si in cadrul unor interfete de dezvoltare a paginilor Web;
pagina JSP se interpune intre browser-ul clientului si componentele pentru logica aplicatiei (realizate in JavaBeans, CORBA, JDBC etc.) care acceseaza o baza de date;
tehnologia JSP se poate utiliza in aplicatii tip multi-nivel (multi-tier);
pagina JSP poate indica modul de manipulare a unor evenimente;
executia unei pagini JSP este realizata de catre motorul JSP instalat pe un server de Web, care proceseaza pagina si returneaza o alta in format standard HTML/XML;
implementarea tehnologiei JSP se face in doua etape: traducerea, care se efectueaza o singura data si are ca efect generarea unui servlet si procesarea fiecarei cereri in parte de catre acesta;
pagina JSP poate contine urmatoarele elemente: marcatori HTML, marcatori de date, marcatori JSP, HTML predefinit, cod Java etc.
Servlet-urile pot fi considerate echivalentul applet-urilor pe partea de server, ele fiind asemanatoare din multe puncte de vedere. Insa, principala caracteristica a applet-urilor, interfata grafica utilizator, lipseste din servlet-uri, ele neavand nevoie de asa ceva din moment ce ruleaza in interiorul serverelor. In rest, ele se aseamana mult, un servlet fiind si el o componenta de aplicatie, scrisa in Java, care poate fi transferata la un sistem care are nevoie de ea.
Servlet-urile reprezinta o alternativa oferita de Java pentru rezolvarea problemelor legate de timp aparute odata cu programarea Common Gateway Interface - CGI. Acestea faciliteaza dezvoltarea unor module care permit servere-lor Web sa se conecteze si sa prelucreze informatia in mod dinamic, adica sa ruleze aplicatii Web si nu doar sa transfere documente statice. Solutia Java, mentine executabilul persistent pe server, intre cererile clientilor, spre deosebire de CGI unde fiecare cerere client lanseaza un nou proces pe server (ceea ce duce rapid la epuizarea resurselor serverului Web, adica la cresterea timpului).
Ciclul de viata al servlet-urilor este o proprietate specifica a acestora. Servlet-urile se incarca in mod dinamic, serverele oferind facilitati de administrare a incarcarii si a initializarii acestora. Exista si posibilitatea, deloc de neglijat, de a specifica incarcarea anumitor servlet-uri la lansarea in executie a serverului. Odata incarcate, acestea devin parte integranta a serverului. Procesul de incarcare este transparent pentru utilizator, acesta trebuind sa specifice doar locatia servlet-ului (local sau la distanta), numele clasei ce contine servlet-ul si numele sub care acesta va fi cunoscut de catre server (alias).
Caracteristicile principale ale servlet-urilor sunt evidentiate in [VELI03] si se refera la urmatoarele:
clasele si metodele necesare pentru a defini si utiliza un servlet sunt incapsulate in pachete Java;
tehnologia se utilizeaza pentru a dezvolta solutii bazate pe Web: accesul securizat la pagini Web, asigurarea interactiunii cu bazele de date, generarea dinamica a paginilor HTML, manipularea informatiilor care identifica unic un client pe parcursul uneia sau a mai multor sesiuni;
se poate crea cate un servlet pentru fiecare functie din paginile Web (conectare, inregistrare, actualizare etc.) sau unul singur care sa gestioneze toate tranzactiile din paginile Web respective, in mod dinamic;
tehnologia este o solutie optima pentru aplicatiile care utilizeaza intensiv bazele de date (serverul se ocupa de accesul la date iar clientii formuleaza cererile de regasire). Partea de cod se scrie o singura data si se stocheaza rezident, o singura data, pe server. La actualizarea codului se va face o singura inlocuire, pe server, si nu la fiecare utilizator in parte;
la initiere se pot deschide conexiuni la baze de date care devin astfel rezidente intre apelurile clientilor;
comunicarea client-server se realizeaza in mai multi pasi, astfel: clientul formuleaza si trimite catre server o cerere Web; serverul o directioneaza catre servlet pentru a fi procesata (ceea ce implica de multe ori si accesul la o baza de date); raspunsul (sub forma de pagini HTML, imagini etc.) este returnat serverului si apoi clientului care a formulat cererea;
un servlet poate fi apelat dintr-o pagina HTML sau dintr-un applet;
principalele situatii de utilizare a tehnologiei se refera la generarea paginilor Web dinamice si la realizarea aplicatiilor multi-nivel (multi-tier) cu JDBC. In acest ultim caz, servlet-ul poate accesa o varietate de baze de date prin intermediul JDBC si poate realiza, partial sau total, interfata cu utilizatorul prin pagini Web dinamice.
Paginile JSP si componentele servlet sunt functional interschimbabile, dar unele aspecte de programare se rezolva mai simplu intr-una sau alta din tehnologii. In cazul in care cererea clientului necesita includerea unei mari parti de cod HTML in pagina de raspuns, atunci paginile JSP sunt mai simplu de folosit. In schimb, daca respectiva cerere necesita multiple operatii de prelucrare a datelor, este indicata folosirea componentelor servlet.
JavaBeans este un model de dezvoltare a componentelor software care permite componentelor scrise in Java, numite beans, sa comunice intre ele. Aceste componente pot fi utilizate intr-un editor vizual sau pot fi inglobate in interiorul unor aplicatii. Un bean este in principiu o clasa Java care respecta anumite conventii de constructie.
Spre deosebire de componentele JavaBeans obisnuite, EJB sunt componente industriale care cuprind logica reutilizabila de afaceri si acces la resursele externe, cum ar fi bazele de date relationale ale unei companii.
Enterprise JavaBeans (EJB) este un standard pentru arhitectura componentelor la nivelul serverului. De fapt, EJB-urile sunt programe realizate in Java care reprezinta aproximativ 60% dintr-o aplicatie J2EE. Modificarea sau introducerea unei noi functii se rezolva simplu prin modificarea unui EJB sau prin introducerea unui EJB nou la nivelul serverului de aplicatie, intr-un timp redus. Actualizarea aplicatiei se realizeaza intr-un singur loc pe serverul de aplicatie si nu pe statiile de lucru.
Primul dintre scopurile EJB este faptul ca permite programatorilor sa se concentreze asupra logicii afacerilor fara a mai fi preocupati de detalii de nivel inferior, cum ar fi ciclul de viata, necesitatile tranzactionale de securitate etc. Aceste cerinte sunt gestionate automat intr-un mod care permite crearea componentelor ce pot fi transferate de pe un server de aplicatie pe altul, acesta fiind un alt scop al arhitecturii pe niveluri.
In plus, EJB tine intotdeauna cont de faptul ca valoarea unei componente este deseori masurata in posibilitatea de a o reutiliza.
Java Server Faces (JSF) este o tehnologie noua care permite construirea interfetelor grafice si controlul acestora pe partea de server. Desi interfata poate fi generata si prin servlet-uri sau prin pagini JSP, JSF ofera posibilitatea de a defini elemente mai complexe si de a reutiliza componentele existente, acestea fiind deja testate si usor configurabile.
Tehnologia JSF include doua componente majore [NET02]:
un set de API-uri pentru reprezentarea componentelor pentru interfata cu utilizatorul, controlul starilor, lucrul cu evenimente, validarea datelor de intrare si definirea modului de navigare intre pagini;
o biblioteca de marcatori (tag-uri) JSP pentru includerea elementelor de interfata din JSF in cadrul paginilor JSP;
Principiul de functionare a JSF se bazeaza pe arhitectura Model View Controller (MVC2) care propune separarea logicii aplicatiei de partea de prezentare. Conform SunMicrosystems, o aplicatie interactiva poate fi organizata in trei module complet separate unele de altele: primul pentru modelul aplicatiei (reprezentarea datelor si logica aplicatiei), al doilea pentru prezentarea datelor intr-o forma cat mai atractiva utilizatorilor, prin intermediul interfetelor grafice, iar al treilea modul, numit controller, pentru gestionarea cererilor, repartizarea lor partilor corespunzatoare din modelul aplicatiei si identificarea resursei care urmeaza sa fie afisata. Prin urmare, in modelul MVC2 paginile JSP sunt izolate unele de altele si au unicul rol de a asigura prezentarea datelor, intrucat logica aplicatiei si gestionarea cererilor sunt tratate separat.
O aplicatie Web construita prin utilizarea tehnologiei JSF va contine conform [TANA05]:
componente JavaBeans care vor contine datele si functionalitatile aplicatiei;
pagini Java Server Pages responsabile de modul de prezentare a datelor;
biblioteci de marcatori (tag-uri) pentru generarea componentelor interfetei cu utilizatorul, precum si pentru evenimente si validari ale datelor de intrare;
componente de interfata reprezentate de obiecte cu stari pe partea de server;
validatori ai datelor la nivel de prezentare, inainte de actualizarea modelului memorat pe server, elemente de tratare a evenimentelor si reguli de navigare intre pagini;
fisiere de configurare a aplicatiei (fisiere XML in cadrul carora sunt definite relatiile si interactiunile dintre componentele JSF) si a resurselor acesteia.
Atat Java cat si .NET cumuleaza un numar semnificativ de tehnologii. Tocmai din acest motiv este destul de greu de facut o comparatie a performantelor. Insa, privit din alt unghi, trebuie remarcat ca sursele Java si .NET sunt ambele interpretate iar in constructia masinii virtuale .NET s-a facut uz de tehnologiile dezvoltate in cadrul masinii virtuale Java (cum e de exemplu tehnologia JIT). .NET a fost dezvoltat si optimizat pentru Windows, ceea ce poate inclina balanta in favoarea acestei platforme. Insa Java este o tehnologie mult mai veche iar masinile virtuale Java sunt destul de mult optimizate. De aceea in general performantele .NET si Java se considera comparabile.
Marele avantaj al Java este datorat independentei de platforma, aplicatiile Java putand fi rulate pe orice sistem de operare care are instalat o masina virtuala Java. Acest argument nu poate fi decat in favoarea Java, atata vreme cat Linux devine tot mai popular, iar sistemul de operare al celor de la Apple, OSX, suporta si el Java. In plus, nu trebuie exclus rolul pe care il are in dezvoltarea continua a platformei asa-numita comunitate Java, compusa din oameni pasionati care au studiat indelung limbajul si au reusit sa impuna diferite standarde Java: tehnologiile de programare pe server si unele aplicatii desktop.
Microsoft este inca sistemul de operare folosit cu precadere de microcalculatoare. Se afirma chiar ca, pana si cei care nu sunt fani impatimiti ai Microsoft, utilizeaza totusi tehnologiile lor. Iar cata vreme Microsoft domina ar fi ilogic sa nu se realizeze aplicatii care sa se poata integra perfect in mediul Windows. Principalul limbaj utilizat pentru dezvoltare de aplicatii Windows al .NET este indiscutabil C#, cel despre care se spune ca nu imprumuta numai puterea C-ului, ci si structura bibliotecilor Java.
Se stie ca C# vine de la Microsoft ca un echivalent la Java si cu un suport mai puternic (decat celelalte limbaje) pentru mult mediatizata platforma .NET. Insa, daca C# (sau mai bine zis .NET) nu va fi independent de platforma (ceea ce este mai mult ca sigur) si atat timp cat vor exista sisteme de operare concurente - pentru care exista Java, acesta din urma nu are cum sa devina invechit ca limbaj de programare sau ca platforma de dezvoltare. Ideea anterioara este intarita luand in considerare faptul ca Java este un produs gratuit, este sprijinit de mari nume din industria IT (ca IBM, Borland etc.) si deja exista un numar foarte mare de programatori care sunt fascinati de acest limbaj.
Un alt concurent destul de puternic pentru C# (si chiar si pentru Java) ar putea deveni Delphi care are componente de .NET, are destul de multi 'adepti' si, ca si C# si Java, poate fi incadrat in categoria Rapid Application Developement (dezvoltare rapida de aplicatii).
Codul generat de oricare dintre platformele .NET si Java este interpretat, insa performantele nu se ridica la nivelul codului nativ generat, spre exemplu, de compilatoarele de C/C++. Cu toate acestea, aplicatiile scrise pentru platformele interpretate castiga teren in fata celor native din alte puncte de vedere: productivitate in dezvoltare, transparenta a platformei, un nivel sporit de reutilizare a codului, mentenanta semnificativ imbunatatita, un mai bun management al complexitatii.
.NET Framework prezinta o serie de avantaje: suporta limbaje gen C/C++, Perl, VB, Python etc. Spre deosebire de acesta, platforma Java suporta doar limbajul Java (in speta mediile de dezvoltare comerciale si nu limbajele de interes academic).
Exista de asemenea avantaje de performanta ale platformei .NET fata de Java (legata de viteza de executie a codului .NET, foarte apropiata de performanta codului nativ x86), avantaje tinand de suportul nativ pentru servicii Web sau avantajul integrarii in sistemul de operare.
.NET isi propune rezolvarea problemei interoperabilitatii in urmatorul mod: cum se poate realiza comunicarea a doua aplicatii X si Y extrem de diferite, scrise in limbaje distincte? Raspunsul .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 fara a fi necesara rescrierea acestuia in Java.
Abordarea Java, in schimb, este extrem de diferita, incercand sa promoveze portabilitatea ca solutie universala, in locul interoperabilitatii. Cu alte cuvinte, in loc sa facem aplicatiile X si Y de mai sus sa vorbeasca intre ele, mai bine rescriem totul in Java.
Un avantaj Java, insa, ar fi suportul pentru multithreading, deoarece este important sa poti scrie o aplicatie multithreading care sa mearga perfect pe orice sistem de operare suportat.
Problema comunicarii dintre aplicatii in Java este rezolvata de catre JVM (Java Virtual Machine), considerata o solutie impresionanta. Singura problema ar fi cantitatea de memorie consumata, deoarece pentru fiecare aplicatie se initiaza o JVM noua. O solutie pe care SUN o tot promite inca de prin anii 1996 este Multi-tasking Virtual Machine - MVM.
Se remarca, de asemenea, faptul ca tehnologia Java este utilizata cu predilectie in cazul dezvoltarii aplicatiilor de intreprindere cu baze de date, care utilizeaza Oracle sau IBM DB2, in timp ce .NET este utilizat in special in dezvoltarea aplicatiilor care utilizeaza baze de date SQL Server (tot de la Microsoft).
Prin urmare, desi limbajele sunt foarte asemanatoare (C# / Java), iar framework-urile, desi diferite pe alocuri, se aseamana foarte mult, se pot desprinde anumite concluzii, formulate in detaliu in articolul [EFTI02].
In realizarea comparatiei platformelor s-a luat in calcul faptul ca diversele variante de implementare a specificatiei J2EE duc la diverse calitati ale produselor finale, care variaza intre "Java best" (cea mai buna solutie) si "Java worst" (cea mai slaba solutie).
Figura 4.21. Java vs. .NET
Tinand cont de aceste considerente, analiza celor doua platforme a evidentiat urmatoarele (figura 4.21):
din punctul de vedere al independentei fata de producator, Java domina, intrucat functioneaza pe mai multe platforme si ruleaza la fel de bine pe Linux/Solaris/AIX/macosx/Windows, in vreme ce .NET functioneaza numai pe sistem de operare Windows (se remarca, insa, buna integrare cu acesta);
in privinta abilitatii producatorului si a posibilitatii de dezvoltare ulterioara a platformelor pe piata IT, cele doua produse au aproximativ aceeasi evolutie. La Java, insa, poate fi remarcata "strategia de supravietuire": grupul de producatori de solutii Java si-a impartit capacitatea de productie, orice produs Java fiind dezvoltat in paralel de mai multi producatori. Astfel, existenta si dezvoltarea viitoare a platformei nu depinde in mod necesar de existenta companiei Sun, in cazul insolvabilitatii acesteia, rolul sau putand fi transferat altei companii;
costurile cu licentele si cu intretinerea sunt un factor ce nu trebuie neglijat in luarea deciziei utilizarii uneia dintre cele doua tehnologii. Costurile solutiilor J2EE ale unor furnizori ca IBM sau BEA sunt transferate deja in categoria mainframe-urilor. Nu trebuie insa uitate ofertele open-source distribuite gratuit. Struts, JUnit, Eclipse, iar mai nou si Oracle JDeveloper - sunt doar cateva nume de framework-uri, module sau instrumente de dezvoltare gratuite care nu mai au nevoie de nici o recomandare suplimentara in lumea programatorilor si a inginerilor de software. Comparativ cu cele doua variante de implementare Java - "Java best" si "Java worst", pe scara preturilor, Microsoft .NET este asezat undeva pe la mijloc;
eficienta in utilizare se poate masura atat din punctul de vedere al automatizarii procesului de dezvoltare, cat si din cel al existentei uneltelor de depanare sau al celor de control al versiunilor. Din acest punct de vedere, pentru unele dintre implementarile J2EE performantele celor doua platforme sunt aproximativ echivalente;
portabilitatea este unul dintre avantajele certe ale platformei Java, aplicatiile putand fi rulate pe orice sistem care are instalat o masina virtuala Java (Java Virtual Machine - JVM), care este insa mare consumatoare de memorie. Portabilitatea in Java este asigurata de Java Runtime Environment (JRE), iar serverul de aplicatii si alte produse middleware pot fi programate in functie de sistemul de operare. Spre deosebire de Java, .NET nu prezinta portabilitate, dar incearca sa remedieze problema prin intermediul serviciilor Web, raspunzatoare de realizarea interoperabilitatii dintre aplicatii;
dincolo de criteriile de performanta, trebuie sa se tina cont de eficienta platformei si de productivitatea furnizata in dezvoltarea aplicatiilor. Daca se masoara productivitatea numai pe baza numarului de linii de cod, .NET prezinta avantaje clare fata de Java. Crucial este insa cat dintre aceste linii de cod trebuie sa fie scrise manual de catre dezvoltatorul de aplicatii. Aici intervine, insa, atat procesul automatizat de dezvoltare, cat si inteligenta mediului de dezvoltare software;
studiind aspectele legate de maturitatea si stabilitatea platformei, se constata ca, de-a lungul timpului, produsele J2EE au capatat un grad mare de maturizare, datorat si popularitatii obtinute de-a lungul timpului de tehnologia Java.
CAPITOLUL 4. STUDIUL TEHNOLOGIILOR INFORMATICE DE INTEGRARE A APLICATIILOR 155
4.1. Tipuri de integrare a aplicatiilor 155
4.1.1. Integrarea prin portal 156
4.1.2. Integrarea prin entitati 164
4.1.3. Integrare prin procese de afaceri 169
4.2. Niveluri de integrare ale aplicatiilor 174
4.2.1. Integrare la nivelul datelor 175
4.2.2. Integrare la nivelul prezentare 175
4.2.3. Integrare la nivel functional. Integrarea prin servicii 176
4.2. Etapele procesului de integrare 180
4.2.1. Etapa 1. Inteconectivitatea sau integrarea hardware 181
4.2.2. Etapa 2. Interoperabilitatea sau integrarea software 182
4.2.3. Etapa 3. Integrarea datelor si a depozitelor de date 185
4.2.4. Etapa 4. Integrarea retelelor de comunicatie 186
4.3. Standarde utilizate la integrarea aplicatiilor 186
4.3.1. Business Process Execution Language - BPEL 186
4.4. Arhitecturi utilizate in integrarea aplicatiilor 198
4.4.1. Arhitectura orientata pe servicii 198
4.4.2. Oracle Application Integration Architecture 206
4.4.3.
4.5. Tehnologii informatice de integrare a aplicatiilor 208
4.5.1. Tehnologia middleware 208
4.5.1.1.Modele middleware 209
4.5.1.2. Tipuri de middleware 211
4.5.2. Java 220
4.5.2.1. Platforme Java 224
4.5.2.2. Java 2
JAVA SERVER PAGES (JSP) 229
SERVLET-URI 231
JAVA SERVER FACES (JSF) 235
JAVA versus .NET 237
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 3798
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
