4.5. Tehnologii informatice de integrare a aplicaţiilor

Cursul 8 – Integrarea sistemelor informatice

STUDIUL TEHNOLOGIILOR INFORMATICE DE INTEGRARE A APLICAŢIILOR

4.3. Standarde utilizate la integrarea aplicaţiilor

4.3.1. Business Process Execution Language - BPEL

BPEL este un standard bazat pe XML şi servicii Web care permite modelarea fluxurilor de afaceri şi automatizarea acestora. Folosind acest limbaj, fluxurile şi regulile de afaceri pot fi definite într-un mod intuitiv, fiind asigurat un nivel ridicat de transparenţă în realizarea acestor operaţiuni. Tehnologia BPEL simplifică modul de integrare a diverselor aplicaţii şi procese de afaceri [NET07].

Figura 4.9. Integrarea cu partenerii de afaceri

După cum reiese din figura 4.9, integrarea aplicaţiilor prin BPEL se realizează prin intermediul soluţiei Business Process Management (BPM), care se bazează pe standarde şi tehnologii fundamentale ce stau la baza Internetului şi care pot fi folosite atât pentru automatizarea proceselor interne din cadrul firmei, cât şi pentru derularea fluxurilor cu partenerii de afaceri. În acest sens, soluţiile de acest tip oferă o flexibilitate deosebită în integrarea şi automatizarea unor procese de afaceri care prezintă un nivel ridicat de complexitate şi la care participă mai multe companii

Evoluţia BPELEvoluţia BPEL este sugestiv reprezentată în figura 4.10, evidenţiindu-se trecerea

prin următoarele faze de dezvoltare:

1


Figura 4.10. Evoluţia BPEL

eXtensible Language (XLang): este un limbaj bazat pe XML pentru definirea proceselor şi permite modelarea complexă a proceselor de afaceri foarte dinamice, realizând legătura dintre fişiere obiect din Fortran şi C++;

Business Process Markup Language (BPML): este un metalimbaj pentru descrierea proceselor afacerii. BPML a fost proiectat iniţial pentru a suporta procesele de afaceri care ar putea fi executate de un sistem BPM. Atât BPML, cât şi Web Service Choreography Interface (WSCI), apărut mai târziu, partajează acelaşi model de execuţie a proceselor de afaceri şi prezintă similarităţi de sintaxă. BPML suportă planificarea activităţilor la momente de timp specifice;

Web Services Flow Language (WSFL): este proiectat pentru a descrie modul în care vor conlucra o serie de funcţii pentru a oferi servicii Web;

Electronic Business Extensible Markup Language (ebXML): a fost creat pentru a permite utilizarea globală a informaţiei electronice într-un mod sigur, interoperabil şi consistent de către toate părţile implicate;

Web Services Conversation Language (WSCL); Web Service Choreography Interface (WSCI): este interfaţa ce asigură

suportul pentru intercomunicarea serviciilor web. Problema schimbului de mesaje între servicii aparţine WSCI (Web Service Choreography Interface), interfaţă ce funcţionează pentru limbajele de definire a serviciilor Web. Acesta se referă mai ales la comportamentul extern al unui serviciu Web prin asigurarea unei interfeţe comune de schimb al mesajelor. WSCI asigură deci intercomunicarea serviciilor Web şi, mai ales, conlucrarea acestora pentru crearea aplicaţiilor mari;

Business Process Execution Language for Web Services (BPEL4WS): prin intermediul XML şi BPEL4WS se asigură un nou nivel de conectivitate şi interoperabilitate, conform cerinţelor arhitecturii orientate pe servicii (Service-Oriented Arhitecture - SOA), stabilite de standardele internaţionale ale organizaţiei Web Services Interoperability. Sunt disponibile mai multe instrumente vizuale care încorporează interfeţe intuitive şi funcţionalităţi de drag-and-drop, fiind posibilă astfel modelarea simplă a fluxurilor informaţionale şi a proceselor de afaceri. Fiind foarte flexibil în construcţia regulilor care conduc procesele de afaceri, se realizează o simplificare modului de integrare a diverselor aplicaţii şi procese de afaceri.

BPEL4WS este practic un limbaj standard pentru integrarea proceselor care, în vederea identificării datelor relevante din mesaje, utilizează proprietăţile acestora. Folosind acest mecanism, proprietăţile pot fi vizualizate în două modalităţi: transparent şi opac. Datele transparente afectează protocoalele de afaceri publice, în timp ce datele opace sunt în primul rând asociate cu sistemele back-end (afectează protocoalele de afaceri prin nedeterminare).

2

2000/05 2001/03 2001/05 2001/06 2002/03 2002/06

2002/08 2003/04 2005/2006


BPEL4WS defineşte un model şi o sintaxă pentru descrierea comportamentului unui proces folosind interacţiunile dintre proces şi parteneri. Aceste interacţiuni cu partenerii apar prin interfeţele serviciilor Web, iar structura relaţiilor la nivel de interfaţă există într-o entitate cunoscută ca serviciu link. Misiunea unui proces BPEL4WS este să descrie cum interacţionează cu aceşti parteneri, definind un proces de afaceri şi incluzând o logică de coordonare. Cu ajutorul acestui standard, se pot procesa excepţiile şi, în cazul în care acestea apar, se pot defini modurile în care sunt compensate activităţile individuale sau compozite dintr-un proces.

Există două concepte majore care trebuie evidenţiate în ceea ce priveşte standardul BPEL4WS în contextul integrării aplicaţiilor. Mai întâi, un proces BPEL4WS poate defini un protocol de afaceri utilizând conceptul de proces abstract şi oferind un mecanism pentru identificarea datelor relevante pentru protocol ca proprietăţi ale mesajelor care prin folosirea valorilor non-deterministice ascund proprietăţile private. În al doilea rând, este posibil ca BPEL4WS să definească un proces de afaceri executabil care include logica şi starea procesului. Acest mecanism gestionează conceptele de integrare a proceselor fundamentale.

BPEL4WS există ca o extensie a mai multor specificaţii XML, cum sunt:

WSDL 1.1; XML Schema 1.0;

Xpath 1.0.

BPEL4WS oferă un set de facilităţi pentru refacerea sistemului după apariţia unei erori în timpul execuţiei unui proces sau în timpul tratării unei excepţii. Acest standard se foloseşte de capacităţile de tratare a excepţiilor încorporate în WSDL. Mai mult decât atât, există noţiunea de compensare, în sensul că permite proiectantului procesului să implementeze acţiuni de compensare pentru anumite acţiuni ireversibile. Acest aspect este tratat în BPEL4WS folosind noţiunea de scop. Scopul este o unitate de lucru pentru compensare.

BPEL4WS are potenţialul de a deveni un standard bazat pe limbaj pentru integrarea proceselor şi permite crearea modelelor pe o singură tehnologie de integrare a aplicaţiilor, fără a face transformări asupra codului.

Cadrul BPEL

Procesele de afaceri reprezintă colecţii de servicii Web care cooperează pentru a oferi o soluţie comună unei anumite probleme. Cooperarea serviciilor impune coordonarea acestora. Coordonarea serviciilor Web este realizată pe baza unui set partajat de informaţii care formează contextul de coordonare. Contextul de coordonare se defineşte ca fiind totalitatea informaţiilor partajate de către serviciile Web în vederea conectării activităţilor individuale din cadrul proceselor generale de afaceri [MÎND05].

BPEL este un limbaj destinat definirii de fluxuri de activităţi. Limbajul utilizează sintaxa XML şi permite descrierea de procese care pot fi atât producători cât şi consumatori de servicii Web.

3


BPEL oferă suport atât pentru procesele de afaceri executabile, cât şi pentru cele abstracte. Procesele executabile modelează comportamentul participanţilor într-o interacţiune de afaceri specifică, modelând în esenţă un flux de activităţi privat. Procesele abstracte, modelate ca protocoale de afaceri în BPEL, specifică schimburile de mesaje publice între participanţi. Protocoalele de acest tip nu sunt executabile şi nu transportă detalii interne ale fluxului proceselor.

În construirea proceselor de afaceri sunt parcurşi următorii paşi [MÎND05]: Definirea interfeţelor publice; Crearea dicţionarului partener; Crearea mesajului şi stabilirea tipul dicţionarului; Implementarea transformărilor logice; Testarea mediului; Repetarea, dacă este cazul, a paşilor 1-5; Realizarea unui proiect pilot funcţional; Reglarea sarcinilor privind operaţiunile.

IBM oferă specificaţiile unui cadru pentru aplicaţii dezvoltate prin integrarea de servicii Web. Acest cadru permite utilizarea forţei şi avantajelor arhitecturii Web orientată pe servicii în crearea şi automatizarea tranzacţiilor între partenerii unei afaceri, prin automatizarea şi integrarea solicitărilor serviciilor Web oferite de aceştia.

Cadrul este format din specificaţiile BPEL, WS-Transaction (Web Service Transaction) şi WS-Coordination (Web Services Coordination). El stă la baza conectării aplicaţiilor distribuite şi a cooperării activităţilor acestora în mod dinamic.

WS-Transaction şi WS-Coordination sunt specificaţii complementare limbajului, utilizate pentru a asigura coordonarea şi corectitudinea rezultatelor produse de procesele definite peste serviciile Web, în contextul problematicii sistemelor distribuite.

Procesele BPEL implementează scenarii în care, pentru soluţionarea problemelor unui client, sunt implicaţi mai mulţi parteneri, fiecare furnizând un serviciu Web. Fiecare partener implementează o parte din întregul proces necesar pentru a răspunde solicitării. Tehnologiile de realizare a tranzacţiilor dintre parteneri sunt potenţial incompatibile şi au cerinţe specifice, integrarea lor fiind soluţionată de cadrul pentru aplicaţii.

Cadrul oferă mijloace pentru definirea integrării partenerilor eterogeni în procesele globale, pentru stabilirea modului în care activităţi ale acestor procese pot fi externalizate public sub formă de servicii Web, pentru coordonarea activităţilor serviciilor Web multiple într-o tranzacţie globală şi, de asemenea, pentru legarea dinamică, la execuţie, a unui serviciu selectat, dintr-un set de servicii, pe baza datelor derivate din fluxul proceselor.

Dezvoltarea unei aplicaţii bazată pe servicii Web începe cu definirea proceselor, urmată de stabilirea partenerilor, a conexiunilor dintre aceştia, a mecanismelor de coordonare şi a operaţiilor indivizibile utilizând tranzacţii.

În limbajul BPEL se creează o descriere abstractă a proceselor de afaceri. BPEL produce scripturi executabile care implementează descrierea abstractă a proceselor şi care pot fi interpretate de motoare speciale.

Un script al unui proces este o succesiune de paşi, fiecare pas corespunzând unei singure activităţi. Implementarea unei activităţi înseamnă definirea unei interacţiuni cu un serviciu Web.

4


Clienţii şi serviciile Web sunt consideraţi parteneri şi sunt conectaţi prin legături care se caracterizează prin tip şi prin rolurile partenerilor.

Un proces este compus din mai multe activităţi diferite, unele dintre acestea fiind executate simultan. Toate activităţile implicate în proces sunt supuse mecanismului de coordonare, care asigură generarea de rezultate corecte şi consistente.

Activităţile implicate într-un proces trebuie finalizate cu succes fiecare în parte şi în ansamblul lor. Pentru aceasta trebuie soluţionată atât problematica clasică a tranzacţiilor, cât şi cea specifică sistemelor distribuite. În cazul sistemelor distribuite, aceasta derivă din durata mare a unei tranzacţii, ca şi din latenţa semnificativă a procesului de comunicare în reţea. Controlul tranzacţiilor la nivelul procesului se face de către o infrastructură care monitorizează rezultatele fiecărei activităţi individuale în raport cu modul în care aceasta este relaţională cu ansamblul procesului. Pentru gestionarea tranzacţiilor la nivelul fiecărei activităţi se utilizează aplicaţii tradiţionale pentru tranzacţii şi coordonare.

WS-Transaction este un cadru de aplicaţii pentru monitorizarea succesului sau eşecului fiecărei activităţi indivizibile în raport cu realizarea ansamblului activităţilor care formează procesul. Acest cadru se bazează pe servicii Web, în sensul că suportul pentru tranzacţii oferă interoperabilitate între aplicaţiile proprietar de gestionare a tranzacţiilor în vederea realizării modelului tranzacţional la nivelul proceselor de afaceri.

Modelul proceselor de afaceri cu funcţii de coordonare şi tranzacţii distribuite oferă o serie de avantaje. Deoarece este construit peste o arhitectură orientată pe servicii Web, el permite integrarea flexibilă şi dinamică a aplicaţiilor ce se execută pe platforme diferite şi potenţial incompatibile. Modelul este extensibil, oferind un cadru general pentru crearea de procese de afaceri, care poate fi extins pentru a include noi cerinţe. Acest lucru permite, de asemenea, evoluţia instrumentelor de dezvoltare şi testare a aplicaţiilor pe măsura evoluţiei cerinţelor. Modelul este flexibil, oferind suport pentru o procesare durabilă, sigură şi corectă a unui spectru larg de procese de afaceri tranzacţionale şi non-tranzacţionale.

WS-Transaction este folosit în monitorizarea corectitudinii fiecărei activităţi individuale ce trebuie realizată într-un proces global. Iar BPEL este folosit pentru definirea modului de compensare a activităţilor eşuate.

BPEL – limbaj pentru programarea orientată pe servicii Web

BPEL este un limbaj cu ajutorul căruia se definesc operaţii de comunicare a serviciilor Web. O astfel de compoziţie descrie o serie de procese, numite procese de afaceri (business processes), deoarece sunt specifice aplicaţiilor unui anumit domeniu. Acestea se execută prin integrarea mai multor servicii disponibile în Web. Limbajul poate fi utilizat atât pentru implementarea proceselor de afaceri, cât şi pentru descrierea de procese abstracte non-executabile [MÎND05].

Procesele de afaceri se pot reprezenta într-o diagramă de flux a operaţiilor care exprimă un algoritm cu care se defineşte un nou serviciu Web rezultat prin compunerea mai multor servicii existente.

Partenerii sunt reprezentaţi printr-o referinţă tipizată la un serviciu. Această referinţă trebuie rezolvată în sensul stabilirii corespondenţei cu serviciul Web real. Există două tipuri de parteneri: partenerii invocaţi - sunt cei pentru care procesele sunt clienţi şi

5


sunt parte integrată a algoritmului după care acestea se desfăşoară; partenerii clienţi - sunt cei care invocă procesele.

O activitate scrie şi accesează date aflate în containere de date. Un container conţine o instanţă a unui tip de mesaj definit de WSDL.

Limbajul oferă un set de activităţi primitive pentru invocarea de servicii Web, pentru manipularea datelor, pentru lansarea de execuţii, acestea reprezentând cea mai simplă formă de interacţiune a procesului cu lumea exterioară lui. Activitatea primitivă se defineşte ca fiind un pas individual în cadrul proceselor. Acestea interacţionează cu un serviciu, manipulează transferul datelor şi tratează excepţiile.

<invoke> - invocă un serviciu sincron; <receive> - aşteaptă mesaje despre pornirea sau repornirea proceselor; <assign> - manipulează transferul de informaţii, copiază date de la un

container la altul, inserează noi date ca rezultat al evaluării unor expresii; <replay> - întoarce răspuns pentru procesele sincrone; <throw> - indică apariţia unei erori; <terminate> - determină abandonarea imediată a execuţiei instanţei curente

a proceselor de afaceri; <wait> - pune procesele în aşteptare un interval de timp, până la atingerea

unui termen.Activităţile pentru structurare definesc ordinea de execuţie a unei colecţii de

activităţi. Ele descriu structurile după care sunt compuse mai multe activităţi primitive pentru a forma procese. Aceste structuri exprimă şabloanele de control, fluxul de date, manipularea erorilor şi a evenimentelor externe. Activităţile de structurare descriu, de asemenea, coordonarea schimbului de mesaje între instanţele proceselor implicate.

<sequence> - permite definirea unei structuri ce conţine o secvenţă ordonată de activităţi;

<switch> - permite definirea unei structuri de ramificare; <pick> - oferă posibilitatea alegerii unei căi din mai multe alternative; <flow> - defineşte un set de legături care are ca sursă şi ca destinaţie

activităţi de structură; <link> - reprezintă o legătură dintre două obiecte; <while> - permite definirea structurilor repetitive; <scope> - este utilizat pentru divizarea proceselor de afaceri în părţi

organizate; este un context executant pentru activităţile conţinute, un proces fiind el însuşi un <scope>.

O problemă importantă este legată de manipularea erorilor şi recuperarea proceselor după producerea acestora. Pentru manipularea erorilor limbajul oferă construcţiile throw şi catch. Pentru a da posibilitatea terminării procesului erorile se tratează folosind <faultHandlers>.

Execuţia proceselor BPELUn 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 fiecărui client. În acest punct se lansează operaţiile de creare a instanţei de proces şi de asociere a acestei instanţe cu valoarea câmpului cheie din mesaj. În momentul invocării unui proces, se execută o operaţie numită corelare-mesaj. Această

6


operaţie verifică dacă există o instanţă corespunzătoare câmpului cheie din mesajul de invocare. Dacă nu există această instanţă, operaţia de corelare-mesaj lansează procesul prin punctul de pornire, iar dacă instanţa corespunzătoare există, atunci lansează operaţii ale procesului prin celelalte puncte de intrare.

În definirea unui proces se descrie modul de interacţiune cu partenerii, se specifică entităţile de tip container pentru mesajele pe care procesul le schimbă cu partenerii săi şi se definesc activităţile pentru interacţiunea procesului cu lumea exterioară lui.

Procesele de afaceri definite în limbajul BPEL pot fi repartizate şi executate utilizând o platformă ce implementează specificaţiile acestui limbaj. O astfel de platformă este motorul BPWS4J oferit de AlphaWorks [MÎND05].

4.4. Arhitecturi utilizate în integrarea aplicaţiilor

4.4.1. Arhitectura orientată pe servicii

Arhitectura orientată pe servicii (Service-Oriented Arhitecture - SOA) exprimă un concept de arhitectură software ce presupune folosirea serviciilor Web disponibile în scopul satisfacerii cerinţelor utilizatorilor de software. Un sistem SOA poate fi implementat în multe moduri, folosind o varietate de instrumente şi tehnologii. Tehnologia serviciilor Web, care constituie baza SOA, a fost adoptată de marea majoritate a jucătorilor din industria de software: IBM, Microsoft, Sun Microsystems, SAP, Oracle şamd.

O platforma completă de tip SOA permite integrarea aplicaţiilor de întreprindere, realizându-se astfel implementarea simplă a proceselor de afaceri în cadrul companiilor. Într-un mediu SOA, nodurile dintr-o reţea asigură disponibilitatea resurselor ca servicii independente, pe care utilizatorii le accesează într-un mod standardizat.

SOA implică mai mult decât conexiunile dintre serviciile Web sau setul de componente de afaceri ce ar urma să fie livrat şi care ar putea funcţiona împreună. SOA determină, de fapt, obţinerea de beneficii gestionând proceselor de afaceri cu ajutorul aplicaţiilor existente. SOA reprezintă viitorul serviciilor IT, o arhitectură orientată pe servicii permiţând integrarea tuturor resurselor IT, inclusiv a aplicaţiilor create prin tehnologii .NET sau Java.

Orientarea pe servicii reprezintă o nouă metodă pentru proiectarea sistemelor distribuite. Conceptele principale folosite în cadrul acestei abordări sunt:

serviciu: unitate independentă a unei aplicaţii care expune funcţionalitatea către clienţii din reţea prin intermediul unei interfeţe bazate pe mesaje;

client: un modul al unei aplicaţii care facilitează accesul utilizatorilor la funcţionalitatea oferită de servicii;

sistem distribuit: un sistem interconectat de servicii şi clienţi.Sistemele orientate pe servicii sunt sisteme slab cuplate, proiectate pentru a

permite schimbarea pentru adaptarea la noi cerinţe sau metode de implementare. Prin utilizarea modelului orientat pe servicii este posibilă obţinerea unei interoperabilităţi între aplicaţii, indiferent de platformele şi limbajele de programare utilizate în dezvoltarea acesteia. Dezvoltatorii de aplicaţii nu au nevoie să cunoască tipul de sistem, modelul de

7


obiecte sau protocoalele folosite de către sistemele care trebuie integrate. Expunerea funcţionalităţii folosind protocoale standardizate şi interfeţe care pot fi obţinute dinamic conduce la o cuplare slabă între subsisteme, permiţând astfel o conectare simplă şi asigurând o flexibilitate sporită aplicaţiei.

Implementarea SOA necesită o serie de componente, precizate detaliat în [NET09]. Pe scurt, aceste componente sunt:

serviciile de afaceri (Business Services): în mod normal, primul pas spre SOA este adoptarea serviciilor web. Acest lucru presupune expunerea aplicaţiilor şi a sistemelor deja existente prin intermediul interfeţelor bazate pe standarde;

resgistrul (Registry): sistemul de înregistrări al unei SOA ce furnizează o modalitate de administrare a serviciilor de afaceri. Un registru reţine descrierea detaliată a unui serviciu SOA şi utilizează informaţia respectivă într-un serviciu de afacere de tip Registry;

managerul de politici (Policy Manager): produs bazat pe standarde ce simplifică procesul de creare, administrare şi standardizare a politicilor necesare oricărei afaceri;

consola de adminostrare (Management Console): soluţie de management ce permite utilizatorilor să monitorizeze, să administreze şi să securizeze serviciile Web sau procesele SOA în totalitate, dar şi să asigure managementul eficient al sistemelor “fragile” din punct de vedere tehnologic;

translatoare de mesaje: module software aşezate înaintea oricărui serviciu astfel încât serviciile interne să poată fi accesate în limbajul nativ al sistemului în cauză şi în acelaşi timp în acelaşi limbaj pe ansamblu, de obicei XML, ca orice alt serviciu din reţea.

La început, această tehnologie nu era dominată, în aparenţă, de o tendinţă anume. Instrumentele de integrare nu erau diferenţiate: exista unul singur pentru toate conexiunile. Pe măsură ce conceptul SOA a evoluat, arhitectura s-a divizat în categorii cu însuşiri diferite. La cel mai înalt nivel acestea sunt:

aplicaţii fizice: programele care duc la bun sfârşit sarcinile; servicii directoare: separă procesele de afaceri; sincronizarea datelor: componentă folosită la construirea şi întreţinerea

conexiunilor de date; nivelul de procese de afaceri, care utilizează serviciile pentru a acoperi

procesele specifice afacerii.Aceste componente au funcţii şi structuri diferite, de aceea se recomandă folosirea

de tehnologii separate.Un principiu fundamental al SOA se referă la faptul că serviciul furnizat prin

intermediul unei interfeţe trebuie să rămână acelaşi, până la identitate, independent de implementare. Un serviciu de “detalii client”, de exemplu, trebuie să furnizeze aceeaşi funcţie economică independent de faptul că implementarea obiectului economic este realizată într-o singură componentă partajată, peste mai multe platforme şi sisteme anterior în funcţie, sau furnizată de la un partener comercial prin Internet.

Tehnologiile de livrare a aplicaţiilor întrebuinţate ulterior fac ca această transparenţă să devină o problemă dificilă. Serviciile de apelare care sunt implementate în

8


diferite tehnologii nu sunt directe, iar cuplarea strânsă a interfeţelor are ca semnificaţie afectarea acestora (prin modificare lor) odată ce a apărut o schimbare în implementarea componentei. Schimbarea (modificarea) componentelor are ca efect, de asemenea, schimbări în ceea ce priveşte aplicaţiile de apelare, anulând astfel anumite beneficii aşteptate de la proiectarea bazată pe componente.

Spre deosebire de arhitecturile tradiţionale orientate-obiect (object-oriented), SOA cuprinde servicii cuplate, dar independente, puternic interoperabile. Deoarece aceste servicii operează pe diferite platforme de dezvoltare (Java sau .NET), componentele software devin reutilizabile (de exemplu, un serviciu C# ar putea fi folosit de o aplicaţie Java sau alt limbaj de programare), datorită faptului că interfaţa a fost definită ţinându-se cont de standarde (Web Services Description Language - WSDL) din domeniu, care încapsulează (ascund) implementarea specifică faţă de client/serviciu.

O caracteristică fundamentală a arhitecturii propuse este separarea definirii proceselor de integrarea back-end, separare ce permite analiştilor să se concentreze asupra dezvoltării soluţiilor pentru probleme specifice. Prin această separare, este asigurată o arhitectură de tip “plug-and-play”, un nivel de separare ce sigură schimbarea sistemelor de tip back-end fără schimbarea proceselor [NET18].

Arhitectura orientată pe servicii a fost dezvoltată pentru a soluţiona problemele legate de integrare şi automatizarea proceselor interne şi externe cu alte companii sau parteneri în reţea. Scopul final este de a avea o arhitectură IT care acoperă în mod optimal cerinţele prezente şi viitoare, respectiv integrarea internă EAI şi externă G2B, G2C, G2G, WebServices.

Arhitectura conceptuală îndeplineşte o serie de criterii pentru validarea ulterioară a conceptelor, tehnologiei şi produselor, care asigură:

integrarea tuturor funcţiilor relevante şi a proceselor; integrarea sistemelor existente în noua platformă, asigurând protecţia

investiţiilor; minimizarea riscului, reacţie rapidă la schimbarea cerinţelor; complexitate redusă prin construirea unei interfeţe bazate pe servicii

specifice integrate în sistem; utilizarea standardelor XML, XSL, SOAP, UDDI, WSDL şi HTTP; flexibilitate; abilitatea de extindere în conformitate cu necesităţile – scalabilitate; reducerea costurilor şi creşterea productivităţii prin transferul rapid al

aplicaţiilor de pe orice platformă.Prin procese de afaceri construite pe o arhitectură orientată pe servicii, o

companie poate exploata aplicaţiile software existente, astfel încât să atingă un grad superior de interoperabilitate nu doar între toate departamentele firmei ci şi cu alte companii. Această abordare valorifică resursele existente pentru a ajuta la îmbunătăţirea productivităţii, permiţând astfel companiei să reacţioneze rapid la schimbările intervenite pe piaţă, fructificând astfel oportunităţile de afaceri.

Beneficiile arhitecturii orientate pe serviciiO arhitectură orientată pe servicii conţine servicii web pe care dezvoltatorii le

creează într-un nivel de servicii specific. Serviciile pe care aceştia le dezvoltă dispun de

9


interfeţe publicate, ce se adresează unei anumite zone de afaceri. Organizaţiile care îşi concentrează eforturile pe integrarea de servicii, vor avea parte de numeroase beneficii.

Recuperarea rapidă a investiţiilor. Un nivel de servicii robust are avantajul unei recuperări rapide şi substanţiale a investiţiilor aduse în construirea componentelor software. Serviciile individualizează domeniile distincte ale afacerii. De exemplu, o companie creează un serviciu ce dispune de toate metodele necesare pentru a administra stocurile. Aşezând logica afacerii (datele) într-un nivel separat, acesta poate exista independent de orice alt sistem în care este integrat. Un alt exemplu se poate referi la nevoia unei organizaţii de a crea un serviciu pentru autorizarea cărţilor de credit. Dezvoltatorii vor introduce funcţionalitatea respectivă în aplicaţia care are nevoie de ea sau într-o componentă independentă.

Mobilitatea codului. Deoarece transparenţa locaţiei este o proprietate a arhitecturii orientate spre servicii, mobilitatea codului devine realitate. Conectarea dinamică la un serviciu înseamnă că activitatea utilizatorului nu este influenţată de locaţie (a lui sau a serviciului pe care îl foloseşte). De aceea, o organizaţie are flexibilitatea necesară pentru a muta servicii pe o maşină diferită sau către un furnizor extern.

Funcţionalităţi specializate pentru dezvoltatori. Arhitectura orientată spre servicii va forţa aplicaţia să fie organizată pe mai multe niveluri, fiecare cu un rol specific pentru dezvoltatori. Un dezvoltator de aplicaţii client trebuie să cunoască tehnologii precum SWING, JSP sau .NET. Fiecare nivel necesită un set complex de cunoştinţe. Având aceste delimitări de specializare, dezvoltatorii vor excela în domeniul particular în care activează. Companiile vor avea la rândul lor de câştigat, nefiind nevoite să mai apeleze la specialişti cu o bogată experienţă în dezvoltarea de aplicaţii.

Securitate mărită. Crearea unui nivel de servicii înseamnă de fapt construirea unei interfeţe de reţea adiţională ce poate fi folosită de mai multe aplicaţii. Când sistemele erau construite prin metode monolitice sau client-server, problema securităţii era abordată în front-end. De multe ori companiile nu mai implementau componente de securitate din cauza cheltuielilor de întreţinere. Pe de altă parte, serviciile sunt folosite de multe aplicaţii, aşa că dispun de propriul mecanism de securitate. De aceea fiecare program va avea mai multe niveluri de autentificare pentru aplicaţia client de serviciu.

Teste superioare - mai puţine erori. Dezvoltatorii au la dispoziţie instrumente precum JUnit pentru crearea de teste. Acestea pot fi rulate pentru a valida serviciul, independent de orice aplicaţie care îl foloseşte. O practică foarte bună este aplicarea de teste în timpul unui proces automat. Mai multe teste înseamnă, de obicei, mai puţine erori şi o creştere pe ansamblu a calităţii.

Suport pentru mai multe tipuri de clienţi. Un alt beneficiu al SOA este posibilitatea companiilor de a folosi o varietate de clienţi pentru accesarea unui serviciu. Un PDA ce foloseşte J2ME poate accesa un anumit serviciu prin HTTP, iar un client SWING poate accesa acelaşi serviciu via RMI. Având în vedere faptul ca nivelurile de aplicaţii client sunt separate de servicii, noi tipuri de clienţi pot fi implementaţi cu uşurinţă.

Asamblarea serviciilor. Utilizatorii vor ajunge să înţeleagă serviciile ca pe nişte bunuri refolosibile, ce pot fi combinate într-o multitudine de moduri. Utilitatea va consta în dezvoltarea mai rapidă de noi aplicaţii.

10


Mentenanţă superioară. Prin orientarea spre servicii, ca locaţie a logisticii, operaţiunile de mentenanţă se îmbunătăţesc deoarece dezvoltatorii pot localiza defectele de cod mai uşor.

Scalabilitate. O cerinţă importantă pentru arhitecturile orientate spre servicii este transparenţa locaţiei. Pentru a obţine aceste lucru, aplicaţiile caută servicii într-un director şi se conectează la ele dinamic. Această situaţie caracterizează scalabilitatea, întrucât cererile de conectare pot fi înaintate fără intervenţia clientului de serviciu.

Fără îndoială instalarea unui nivel de servicii presupune un efort suplimentar la începutul proiectului, dar beneficiile pe termen lung sunt evidente.

4.4.2. Oracle Application Integration Architecture

Oracle Application Integration Architecture (OAIA), arhitectură lansată în aprilie 2007, oferă procese de afaceri care leagă compartimentele operaţionale, crescând eficienţa costurilor şi reducând ciclul de viaţă. Oracle oferă soluţii prefabricate de integrare a proceselor, suport şi optimizări pe parcursul acestor integrări, implementând şi utilizând cele mai bune practici de afaceri pentru conectarea şi optimizarea operaţiilor afacerii.

Avantaje oferite:

soluţii prefabricate de integrare care reduce costul integrării sistemelor şi minimizează riscurile;

cele mai bune practice de afaceri bine documentate sunt disponibile pentru integrare în aplicaţiile existente;

arhitectură deschisă, bazată pe standarde.

OAIA se bazează pe facilităţile oferite de Oracle Fusion Middleware, şi include metodologia şi instrumentele din SOA, împreună cu un depozit de servicii de afaceri (Business Service Repository) care permite dezvoltarea sau extinderea aplicaţiilor.

4.4.3. Enterprise Services Architecture

Enterprise Services Architecture (ESA) este interpretarea pe care SAP a dot-o unei arhitecturi SOA care extinde conceptul de serviciu Web, înlocuindu-l cu conceptul propriu de serviciu al întreprinderii (enterprise service). Din punct de vedere tehnic, serviciile de întreprindere se bazează pe servicii Web, oferind acces la elementele şi funcţiile afacerii în termeni economici. Utilizarea serviciilor de întreprindere în cadrul aplicaţiilor conduce la o creştere a flexibilităţii, deschiderii si vitezei.

Bazate pe standarde deschise, serviciile de întreprindere încapsulează funcţionalităţile întreprinderii şi le expune ca servicii reutilizabile, care pot fi apoi combinate cu alte servicii pentru a răspunde unor cerinţe noi. Serviciile de întreprindere pot fi rapid combinate pentru a compune noi aplicaţii şi a sprijini noi procese de afaceri.

11


Aceste servicii pot comunica logica de afaceri între aplicaţii care rulează pe platforme disparate. Utilizând aceste servicii, se poate răspunde mai rapid la schimbările care apar în cadrul firmelor, şi se pot reduce costurile prin reutilizarea fucţionalităţilor deja existente.

Organizaţiile pot adopta această arhitectură prin implementarea platformei SAP NetWeaver®. SAP are chiar un program de adoptare SOA, prin care asistă organizaţiile doritoare la elaborarea şi implementarea planului de adoptare SOA. SAP oferă atât soluţiile software orientate pe servicii, cât şi platforma tehnologică SAP Netweaver şi asistenţă altor companii care doresc să îşi dezvolte propriile arhitecturi orientate pe servicii, pentru soluţii SAP şi non-SAP.

4.5. Tehnologii informatice de integrare a aplicaţiilor

4.5.1. Tehnologia middleware

Tehnologiile care permit realizarea integrării aplicaţiilor în cadrul unei întreprinderi constituie ceea ce se numeşte în limbajul de specialitate middleware [NET17]. Cea mai bună abordare în încercarea de definire a middleware-ului este pe baza funcţiilor sale. Middleware este un mecanism care permite unei entităţi (bază de date sau aplicaţie) să comunice cu o altă entitate (sau cu mai multe entităţi). Cu alte cuvinte, middleware este un tip de software care facilitează comunicaţia între două sau mai multe sisteme software.

Deşi este un termen utilizat pentru a desemna mai multe subcategorii de tehnologii, în prezent, pentru realizarea unei aplicaţii formate din mai multe componente distribuite se utilizează cu precădere fie tehnologiile orientate-obiect reprezentate în standardele CORBA sau DCOM, fie tehnologia Java şi conceptul de componentă Java Bean. Cu ajutorul acestor tehnologii se realizează cele mai multe servere de aplicaţii din categoria celor ce trebuie să satisfacă cerinţe severe de performanţă şi disponibilitate.

Folosirea tehnologiilor middleware în cadrul integrării aplicaţiilor este posibilă datorită existenţei următoarelor două elemente:

conceptul de interfaţă care caracterizează fiecare componentă conectată la magistrala middleware şi permite descrierea ansamblului de servicii oferite de către infrastructură; în cadrul EAI, interfeţele sunt construite la nivelul adaptoarelor asociate aplicaţiilor;

metodologia orientată-obiect permite construirea unui model de interfeţe, care să răspundă necesităţilor utilizatorilor şi să contribuie la reducerea nivelului de complexitate necesar creării şi gestionării sistemelor distribuite [SARU00].

Tehnologia middleware poate fi utilizată pentru urmărirea şi administrarea ciclurilor de viaţă şi pentru asigurarea politicilor în cadrul mediilor de dezvoltare integrate.

12


4.5.1.1.Modele middleware

Există două modele de middleware: logic şi fizic. Modelul logic descrie cum are loc transferul de date conceptual, iar modelul fizic descrie metodele precum şi tehnologia folosite pentru transferul de informaţie. Configuraţiile asociate modelului logic sunt:

unu la unu, mulţi la mulţi şi sincron versus asincron.

Modelului fizic îi sunt asociate modele bazate pe mesaje.Middleware unu la unu foloseşte o conexiune software temporară între două

programe sau comenzi (pipe) pentru a permite unei aplicaţii să acceseze altă aplicaţie. Considerăm, spre exemplu, două aplicaţii A şi B. Când aplicaţia A încearcă să comunice cu aplicaţia B închide conexiunea folosind o procedură de apel sau un mesaj (figura 4.11).

Aşa cum sugerează numele, middleware-ul mulţi la mulţi, leagă mai multe aplicaţii între ele. Această capacitate îl face cel mai potrivit pentru integrarea aplicaţiilor. În plus, este cel mai puternic middleware logic, deoarece oferă atât flexibilitate cât şi adaptabilitate problemei integrării.

Figura 4.11. Configuraţia unu la unu

Sunt mai multe exemple de middleware mulţi la mulţi: integrare la nivel de servere, middleware tranzacţional (servere aplicaţii şi monitori TP) şi chiar obiecte distribuite. Practic, orice tip de middleware care poate să lucreze cu mai multe de două aplicaţii sursă şi destinaţie în acelaşi timp poate susţine acest model (figura 4.12).

13


Figura 4.12. Configuraţia mulţi la mulţi

Avantajul modelului unu la unu este simplitatea, modelul mulţi la mulţi având dezavantajul complexităţii. Această problemă este atenuată de noua generaţie de middleware.

Middleware-ul asincron face transferul de informaţie între mai multe aplicaţii în mod asincron, ceea ce presupune că software-ul middleware se poate deconecta de la aplicaţia sursă sau destinaţie. Aplicaţiile nu sunt dependente de alte aplicaţii conectate pentru procesare. Procesul care permite acest lucru are aplicaţiile plasate într-o coadă de aşteptare, fiecare cu un mesaj asociat şi fiecare rulează independent, răspunsul de la celelalte aplicaţii primindu-se mai târziu. Avantajul principal este acela că middleware-ul nu blochează celelalte aplicaţii din procesare. Mai mult decât atât, deoarece middleware-ul se decuplează de la aplicaţie, aceasta poate să continue procesarea, indiferent de stadiul celorlalte aplicaţii.

Pe de altă parte, middleware-ul sincron, este strâns cuplat la aplicaţii. Aplicaţiile sunt dependente de middleware pentru a procesa unul sau mai multe apeluri funcţie pe o aplicaţie la distanţă. Ca rezultat, aplicaţia care apelează trebuie să oprească procesarea pentru a aştepta răspunsul aplicaţiei aflate la distanţă. Acest tip de middleware este referit ca unul care “blochează”. Dezavantajul acestui model este cuplarea aplicaţiilor la middleware şi la aplicaţia la distanţă.

4.5.1.2. Tipuri de middlewareModelele middleware au avut o evoluţie continuă încă de la apariţie, ceea ce duce

la ivirea unor dificultăţi de a le încadra în anumite categorii. Cu toate acestea, se observă existenţa câtorva tipuri de middleware care se pliază foarte bine pe rezolvarea anumitor tipuri de probleme. Următoarele tipuri de middleware vor fi descrise în continuare: RPC,

14


MOM, obiecte distribuite, middleware orientat pe baza de date, middleware tranzacţional (include monitori TP şi servere de aplicaţii) şi servere de integrare.

Remote Procedure Calls (RPC) reprezintă cel mai vechi tip de middleware, uşor de înţeles şi de folosit. Acesta oferă dezvoltatorilor capacitatea de a apela o funcţie dintr-un program şi de a o executa într-un alt program, pe o maşină la distanţă (figura 4.13). Pentru dezvoltator, funcţia se execută local, faptul că aceasta este de fapt executată pe maşina aflată la distanţă fiind ascuns.

Figura 4.13. Funcţionarea RPC

RPC sunt modele sincron de middleware. Pentru ca RPC să fie activat, execuţia programului trebuie oprită. În ciuda simplităţii, majoritatea RPC-urilor nu au o performanţă foarte bună. Cum majoritatea transferurilor de informaţie necesită o reţea, un middleware de tip RPC foloseşte toate resursele reţelei. Un RPC tipic necesită 24 de paşi distincţi pentru a îndeplini cererile. Acest nivel de performanţă limitează beneficiile unui apel RPC într-o reţea înceată, cum este Internetul.

Middleware-ul orientat pe mesaje (MOM) este un software care foloseşte mesaje, unităţi de informaţie (de tip BYTE), care sunt interschimbate de aplicaţii, ca pe un mecanism de a face transfer de informaţie de la un punct la altul. Deoarece MOM foloseşte mesajele pentru a realiza comunicarea între aplicaţii, nu este necesară cuplarea aplicaţiilor la middleware (se bazează pe modelul asincron). Mesajul intră astfel într-o coadă manager (figura 4.14), care hotărăşte când este trimis mesajul la destinaţia finală. Mesajele care se întorc la aplicaţia apelantă vor fi prelucrate când aplicaţia va fi disponibilă. Dezvoltatorii consideră ca utilizarea mesajelor MOM este destul de uşor de urmărit şi organizat.

Mesajele au o structură (schemă) şi un conţinut (date). Se pot asemăna cu o bază de date cu o singură înregistrare care se deplasează între aplicaţii printr-un mecanism de schimb de mesaje. Există două tipuri de modele MOM: unu la unu şi coadă de mesaje (Message Queue - MQ). MQ permite fiecărui program participant să lucreze fără a fi întrerupt de nivelul middleware. Deoarece software-ul MQ (seria MQ de la IBM, MSMQ de la Microsoft) gestionează distribuţia de mesaje de la un program la altul, coada manager poate optimiza performanţa folosind metode de acordare a priorităţii.

15


Figura 4.14. Middleware orientat pe mesajeÎn vederea îndepărtării pericolului ca mesajele să se piardă atunci când are loc o

cădere de sistem, majoritatea modelelor MQ permite ca mesajele să fie declarate drept persistente sau stocate pe disc la anumite intervale de timp, oferind astfel un nivel de protecţie.

Obiectele distribuite sunt clasificate ca fiind middleware deoarece facilitează comunicarea între aplicaţii. Obiectele distribuite sunt programe-aplicaţii de mici dimensiuni care folosesc interfeţe şi protocoale standard pentru comunicare. De exemplu, dacă se creează un obiect distribuit CORBA care rulează pe un sever UNIX şi un altul care rulează pe un server NT, folosind un protocol standard de comunicaţie, obiectele pot face interschimb de informaţie şi funcţii (acelaşi standard – CORBA, acelaşi protocol – IIOP (Internet InterORB Protocol)).

Există două tipuri de obiecte distribuite: CORBA şi COM (Component Object Model). CORBA este creat de OMG în 1991 şi este mai mult un standard decât o tehnologie oferind specificaţii pentru crearea unui obiect distribuit. COM este creat de Microsoft şi include interfeţe standard şi protocoale de comunicaţie.

Middleware-ul orientat pe baza de date se referă la orice middleware care facilitează comunicaţia fie cu o bază de date, fie cu o aplicaţie, fie între mai multe baze de date. Dezvoltatorii folosesc acest tip de middleware ca pe un mecanism de extragere a informaţiei dintr-o bază de date locală sau la distanţă. De exemplu, pentru a extrage informaţia dintr-o bază de date Oracle, dezvoltatorul trebuie să apeleze un astfel de middleware astfel încât să poată realiza autentificarea la baza de date, cererea de informaţie şi procesarea informaţiei care a fost extrasă din baza de date (4.15).

Middleware-ul orientat pe baza de date lucrează cu două tipuri de baze de date: CLI (Call Level Interface) şi middleware nativ pe baza de date.

CLI reprezintă API-uri comune, care oferă acces la baze de date folosind o interfaţă bine definită. De obicei, CLI lucrează cu baze de date relaţionale. Acesta este şi cazul Open DataBase Connectivity (ODBC) de la Microsoft. ODBC foloseşte o interfaţă pentru a facilita accesul la o bază de date şi drivere pentru a gestiona diferenţele dintre bazele de date. De asemenea, oferă acces simultan la baze de date multiple, arhitectura ODBC presupunând existenţa unui driver manager care să faciliteze comunicaţia între diferite baze de date.

16


Figura 4.15. Middleware orientat pe baze de date

Java DataBase Connectivity (JDBC) de la JavaSoft este un alt exemplu de CLI. JDBC este o interfaţă standard care foloseşte un singur set de metode Java pentru a facilita accesul la baze de date multiple. JDBC se aseamănă cu ODBC şi funcţionează de pe orice aplicaţie Java: applet, servlet, Java Server Pages (JSP), Enterprise JavaBean (EJB).

Monitorii TP sunt prima generaţie de servere de aplicaţii, la fel ca şi produsele middleware de tip tranzacţional. Acestea oferă un mecanism pentru a facilita comunicarea între două sau mai multe aplicaţii (figura 4.16), precum şi o locaţie pentru logica aplicaţiei. Exemple de TP includ Tuxedo de la BEA Systems, MTS de la Microsoft, CICS de la IBM.

Figura 4.16. Monitor TP

17


Monitorii TP se bazează pe tranzacţii, văzute ca unităţi de lucru cu un început şi un final. O tranzacţie are doar două stări: poate sa fie ori finalizată, ori anulată complet. În acest ultim caz, dacă tranzacţia a actualizat resurse aflate la distanţă (baze de date, cozi), aceste actualizări vor fi anulate de asemenea.

TP asigură două servicii importante. Pe de o parte, TP oferă servicii care garantează integritatea tranzacţiilor (serviciul de tranzacţie), iar pe de altă parte, un monitor TP asigură managementul resurselor şi servicii de management pe termen lung (serviciul de aplicaţie). Cele două servicii sunt ortogonale.

De asemenea, monitorii TP oferă conectori la resurse ca baze de date, alte aplicaţii sau cozi. Aceşti conectori necesită o dezvoltare de aplicaţie sofisticată pentru a comunica cu tipurile variate de resurse. Odată conectate, aceste tipuri de resurse sunt integrate în tranzacţii. Ca urmare, aceşti conectori pot fi reconstituiţi dacă apare o cădere de sistem.

Serverele de aplicaţie definesc segmentul pieţei de middleware cu cea mai rapidă evoluţie. Cu toate acestea, tehnologia serverelor de aplicaţii nu este nouă (monitorii TP pot fi consideraţi servere de aplicaţii datorită caracteristicilor comune). Majoritatea serverelor de aplicaţii sunt middleware Web şi procesează tranzacţii aparţinând aplicaţiilor Web. Noutatea acestor servere de aplicaţii este că folosesc limbaje moderne, cum este Java, în locul celor tradiţionale procedurale, cum sunt C sau Cobol (ceea ce se întâmplă la monitorii TP).

Mai simplu, serverele de aplicaţii asigură posibilitatea accesului la alte aplicaţii şi fac posibilă procesarea şi stabilirea resurselor necesare conexiunilor. Aceste resurse includ baze de date, aplicaţii ERP şi chiar aplicaţii tradiţionale de tip mainframe. Serverele de aplicaţii oferă interfeţei utilizator mecanisme de dezvoltare. În plus, în cele mai multe cazuri oferă şi mecanisme de amplasare a aplicaţiilor pe platforma Web (4.17).

18


Figura 4.17. Arhitectura unui server de aplicaţie tipic

Producătorii de servere de aplicaţii consideră că produsele lor au o tehnologie ce permite rezolvarea problemelor de integrare a aplicaţiilor. Ca urmare, serverele de aplicaţie, ca şi monitorii TP, joacă un rol important în domeniul integrării aplicaţiilor. Mulţi dintre producători încorporează tehnologii de gestiune a mesajelor, transformare şi rutere inteligente, servicii care sunt native serverelor de integrare.

Serverele de integrare reprezintă partea de vârf a tehnologiei middleware pentru integrarea aplicaţiilor sau cel puţin potenţialul acesteia. Serverele de integrare pot facilita schimbul de informaţie între două sau mai multe aplicaţii sursă sau destinaţie şi pot face diferenţa între semanticele aplicaţiei şi platforme. Ca urmare, această tehnologie se potriveşte perfect cu integrarea aplicaţiilor.

19


Figura 4.18. Servere de integrare

Serverele de integrare pot apărea în multe aplicaţii folosind reguli comune şi motoare de rutere. Ele pot transforma schema şi conţinutul informaţiei pe durata transferului între aplicaţii şi baze de date.

Serverele de integrare sunt servere care gestionează mesaje între două sau mai multe aplicaţii sursă sau destinaţie. În plus, aceste servere transformă schemele de mesaje şi modifică conţinutul mesajelor. Serverele de integrare pot avea într-adevăr funcţii adiţionale, incluzând un motor şi o interfaţă de integrare a proceselor, precum şi un mecanism de management.

Importanţa serverelor de aplicaţii este stabilită în funcţie de poziţia ocupată de acestea în cadrul companiei. În general, după cum este evidenţiat şi în figura 4.18, serverele de integrare nu sunt o tehnologie de dezvoltare a aplicaţiilor ci mai degrabă una care permite comunicarea între mai multe aplicaţii, fără să presupună existenţa unui schimb de informaţii despre natura aplicaţiilor între care se face schimbul de date. Pe scurt, serverele de integrare gestionează informaţia între baze de date şi aplicaţii.

4.5.2. Java

Java este un limbaj de programare de nivel înalt, orientat-obiect, care a fost proiectat iniţial pentru realizarea de aplicaţii pentru Internet. Acesta este utilizat în prezent cu succes şi pentru programarea aplicaţiilor destinate Intranet-urilor. În acest sens, multe firme recurg la limbajul Java în procesul de informatizare întrucât oferă un

20


foarte bun suport pentru tehnologiile de vârf şi, nu în ultimul rând, pentru faptul că este gratuit şi în mod continuu îmbogăţit şi îmbunătăţit.

„Write once, run anywhere” (WORA) sau, uneori, „Write once, run everywhere” (WORE), este sloganul creat de Sun Microsystems pentru a ilustra beneficiile aduse de limbajul Java prin rularea pe orice tip de platformă. La modul ideal, aceasta înseamnă că un program Java poate fi dezvoltat pe orice platformă, compilat în formatul standard bytecode şi apoi rulat de pe orice sistem care are în prealabil instalată maşina virtuală Java (Java Virtual Machine - JVM).

Legătura care s-a creat între Internet şi Java a condus la situaţia în care majoritatea companiilor care dezvoltă aplicaţii pentru Internet să considere Java ca limbaj de implementare, în acest moment Java nefiind un limbaj de programare obişnuit, ci desemnând un ansamblu de tehnologii care permit trecerea de la o abordare a aplicaţiilor desk-centric, la network-centric, realizându-se platforme de calcul deschise şi universal accesibile din Internet.

Prin urmare, trecerea conceptului Java din sfera limbajului de programare în cea a tehnologiilor şi a platformelor de tehnologii nu devine improprie. Tehnologia Java stă la baza celor mai performante soluţii de dezvoltare a aplicaţiilor de întreprindere şi controlează cu adevărat funcţionalitatea unei reţele prin faptul că este în acelaşi timp un limbaj de programare precum şi o selecţie de platforme specializate. Prin aceste caracteristici, Java standardizează dezvoltarea şi implementarea unor aplicaţii securizate, portabile, stabile şi scalabile.

Caracteristicile limbajului JavaCaracteristicile limbajului Java sunt numeroase, drept pentru care vor fi prezentate

cele mai semnificative, pornind de la articolul [STAN01]:

uşor de utilizat – atât pentru avansaţi cât si pentru începători; simplu – fiind îndepărtate aspectele derutante din C++, cum ar fi

supraîncărcarea operatorilor şi moştenirea multiplă; a fost introdus un colector automat de deşeuri care rezolvă problema dealocării memoriei în mod uniform, fără intervenţia programatorului;

independent de platformă – compilatorul Java furnizează o secvenţă de instrucţiuni ale unei maşini virtuale Java, iar execuţia aplicaţiilor este interpretată;

viteza scăzută de execuţie – caracteristică a limbajelor interpretate faţă de cele compilate. Pentru creşterea acestei viteze se poate cere mediului de execuţie Java să genereze automat, plecând de la codul maşinii virtuale, un executabil nativ platformei respective. De obicei, în Java se compilează doar părţile mari consumatoare de timp, celelalte fiind interpretate;

interpretorul Java – este gândit pentru a lucra pe maşini mici, iar împreună cu bibliotecile standard să nu depăşească 300KB;

orientat-obiect – deoarece se pot crea clase de obiecte şi instanţe ale acestora, se pot încapsula informaţii, se pot moşteni variabile şi metode de la o clasă la alta. Suplineşte moştenirea multiplă (care lipseşte) cu interfaţa, care permite definirea unui anumit comportament pentru a crea o clasă de

21


obiecte, altul decât cel standard. În Java orice element este obiect, cu excepţia datelor primare şi lipsesc funcţiile şi variabilele globale;

distribuit – are implementate biblioteci pentru lucrul în reţeaua TCP/IP, suportă URL şi încărcarea resurselor din reţea; aplicaţiile Java pot accesa foarte uşor reţeaua, prin apelurile către un set standard de clase;

robust – legarea funcţiilor se face în timpul execuţiei, iar informaţiile de compilare sunt disponibile până în momentul rulării aplicaţiei. Astfel sistemul poate determina în orice moment neconcordanţa dintre tipul referit la compilare şi cel referit în timpul execuţiei, evitându-se intruziunile în sistem prin intermediul referinţelor falsificate. De asemenea, pointerii lipsesc (împreună cu aritmetica lor), eliminând încă o sursă principală de erori, iar eliberarea memoriei ocupate de obiecte şi tablouri se face automat, evitându-se încercările de eliberare multiplă a zonei de memorie;

securitate ridicată – prin verificarea codului la fiecare încărcare, prin mecanisme de Cyclic Redundancy Check (CRC) şi prin verificarea operaţiilor disponibile pentru fiecare set de obiecte, robusteţe, încorporarea protecţiei obiectelor la citire/scriere. Verificarea se face în timpul execuţiei, mediul de execuţie Java putând fi configurat pentru a proteja reţeaua locală, fişierele şi celelalte resurse ale calculatorului pe care rulează aplicaţia Java;

multithreading – suport nativ pentru aplicaţii care lucrează cu mai multe fire de execuţie, inclusiv primitive de sincronizare între firele de execuţie, independent de platformă;

dinamic – bibliotecile de clase în Java pot fi reutilizate cu mare uşurinţă, variabilele sunt legate doar în faza de execuţie, rezolvând problema fragilităţii superclasei din C++, regăsirea variabilelor se face prin nume şi nu prin deplasament fix; se elimină necesitatea actualizării aplicaţiilor, datorată apariţiei unei noi versiuni de bibliotecă.

Java furnizează un cadru de lucru curat, format din mai multe straturi diferite care creează mediul de execuţie Java. Aceste straturi sunt: limbajul de programare, biblioteca standard API, compilatorul Java, codul specific (bytecode), mecanismul pentru încărcarea dinamică şi verificarea bibliotecilor, automatul de colectare a deşeurilor (garbage collector), maşina virtuală universală pentru executarea bytecode-ului - Java Virtual Machine (JVM).

4.5.2.1. Platforme Java

Limbajul Java poate fi considerat unul din cele mai populare şi mai versatile limbaje de programare, mai ales dacă ne gândim la rolul lui în cadrul spaţiului World Wide Web. Rezultat al distilării celor mai bune practici în proiectarea de limbaje de programare orientate-obiect, Java a adus cu sine şi o libertate de necontestat în ceea ce priveşte alegerea elementelor de design, implementare şi exploatare a aplicaţiilor concepute în acest limbaj.

Platformele Java se pot clasifica în: Java 2 Micro Edition (J2ME), Java 2 Standard Edition (J2SE) şi Java 2 Enterprise Edition (J2EE). Acestea se utilizează după cum urmează (figura 4.19):

22


J2ME - mediul pentru dezvoltarea aplicaţiilor Java pentru micro-dipozitive;J2SE - mediul standard pentru dezvoltarea aplicaţiilor Java. Sunt disponibile

pachetele de bază ale limbajului Java, necesare realizării aplicaţiilor desktop;J2EE - mediul Java pentru dezvoltarea aplicaţiilor de întreprindere. Se oferă un

foarte bun suport pentru utilizarea serverelor de aplicaţii.

Figura 4.19. Platforme Java

Pentru toate tipurile de aplicaţii se remarcă avantajul tehnologiei Java: codul se scrie o singură dată dar rulează pe orice sistem - „Write once, run anywhere”.

Java 2 Micro Edition (J2ME) este un mediu Java puternic optimizat ce ţinteşte spre o largă varietate de produse de larg consum, incluzând pagere, telefoane celulare, agende electronice de buzunar şi sisteme de navigaţie pentru automobile. O aplicaţie scrisă în tehnologia Java 2 Micro Edition poate fi folosită pe orice echipament HandHeld (PDA) sau pe orice telefon mobil cu suport Java. Totodată, ediţia J2ME defineşte şi o implementare complet nouă a maşinii virtuale Java optimizată pentru dispozitivele mobile (Kilobyte Virtual Machine - KVM).

Java 2 Enterprise Edition (J2EE) este o platformă Java creată de Sun Microsystems, utilizată pentru a dezvolta, utiliza şi administra aplicaţiile multi-nivel (multi-tier). Aplicaţiile J2EE sunt aplicaţii dezvoltate pe 3 straturi: aplicaţie-client, server de aplicaţie şi server de bază de date. Noutatea este apariţia serverului de aplicaţie pe care sunt EJB-urile, acestea fiind programe scrise în Java care reprezintă aproximativ 60% din aplicaţie.

Fiind dezvoltată în Java, J2EE este o platformă independentă de sistemul de operare, având cerinţe hardware minime. Un avantaj important al J2EE se referă la faptul că dezvoltarea aplicaţiilor este mult simplificată, iar necesitatea programării efective prin scrierea de cod este redusă, întrucât sunt disponibile module de componente standardizate, reutilizabile.

23


Aplicaţiile Internet J2EE se pot baza atât pe servere open source (Apache Tomcat, Jetty, JBoss) cât şi pe servere performante cu renume (IBM WebSphere Application Server, Bea WebLogic Server, Oracle Application Server). Această caracteristică aduce avantajul unui buget flexibil alocat aplicaţiei respective.

În cazul sistemelor desktop, Java 2 Standard Edition (J2SE), aceeaşi aplicaţie poate rula pe orice sistem de operare, atât Windows/Machintosh, cât şi variante Unix/Linux.

4.5.2.2. Java 2 Enterprise Edition - J2EE

J2EE este un standard iniţiat de către Sun Microsystems şi susţinut de parteneri importanţi, dintre care cel care a investit cel mai mult este IBM. Unul dintre obiectivele creării limbajului de programare Java a fost independenţa de platformă, deziderat realizat prin crearea de JVM specifice sistemelor de operare. Odată cu dezvoltarea tehnologiei Internet a apărut necesitatea redării de conţinut dinamic în paginile Web. Răspunsul tehnologiei Sun, orientată Java, la această nouă provocare a fost apariţia tehnologiilor Servlet şi Java Server Pages (JSP). În paralel a apărut şi tehnologia Entrepise JavaBeans (EJB), iar mai târziu, începând din anul 2004, Java Server Faces (JSF).

Standardul J2EE stă la baza celor mai robuste platforme pentru dezvoltarea de aplicaţii de întreprindere. J2EE reprezintă un set de specificaţii de construire a unor aplicaţii pe niveluri multiple, folosind limbajul de programare Java. În ultimii ani, experienţa acumulată de dezvoltatori şi apariţia de noi standarde au contribuit la continua îmbunătăţire a platformei J2EE.

Norma J2EE a apărut ca răspuns la nevoia de a extinde ideea de portabilitate de la nivelul limbajului (Java) la nivelul serverelor de aplicaţie. În afară de portabilitate, J2EE prezintă o serie de alte avantaje, cum ar fi dezvoltarea orientată pe componente, separarea containerelor etc.

Securitatea este încorporată în tehnologia J2EE, serverul de baze de date fiind accesat numai prin intermediul serverului de aplicaţie, ceea ce face ca utilizatorul să nu aibă acces direct la baza de date, ci numai prin aplicaţie.

Securizarea unei aplicaţii de întreprindere conform normei J2EE se face pe baza unor standarde, în cadrul cărora se pune accent pe separarea autentificării de autorizare. Securizarea se poate face pe două niveluri: declarativ şi aplicativ [BĂRC 05].

În cadrul implementării securităţii declarative a unei aplicaţii J2EE, prima etapă este autentificarea în care utilizatorul furnizează un nume de utilizator şi o parolă pentru a i se valida identitatea. Securizarea declarativă împiedică sau acordă accesul utilizatorilor asupra resurselor Web ale aplicaţiei. Pentru a avea o aplicaţie corectă din punct de vedere funcţional, acest lucru nu este suficient. Astfel, dacă un utilizator nu are acces la o pagină, butonul care accesează pagina respectivă trebuie să nu fie vizibil pentru utilizatorul în cauză. Acest lucru este realizat prin implementarea securităţii aplicative, prin API-urile suportate de către norma J2EE şi care permit testarea rolului unui utilizator autentificat. Important este de reţinut faptul că odată ce utilizatorul s-a autentificat pe

24


aplicaţie nu se mai testează asupra ID-ului său ci asupra apartenenţei sale la un rol sau altul. Securitatea aplicativă întregeşte astfel ansamblul de facilităţi puse la dispoziţia dezvoltatorului de către implementările normei J2EE pentru o gestiune completă a securităţii unei aplicaţii.

Implementarea celor mai bune practici implică în mod uzual adăugarea a numeroase noi coduri, ceea ce poate constitui un obstacol pentru cei care îşi dezvoltă primele aplicaţii J2EE. Modalitatea de a elimina aceste obstacole este folosirea unui cadru de lucru ce abstractizează elementele de complexitate ale platformei J2EE şi pune în valoare beneficiile acestui mediu. Un astfel de mediu de dezvoltare este oferit de Oracle Application Development Framework, inclus în produsul Oracle JDeveloper 10g.

Nucleul J2EE include: Java Server Pages (JSP), Servlets, Enterprise JavaBeans (EJB) şi servicii Web, arhitectura platformei fiind evidenţiată în figura 4.20:

Figura 4.20. Arhitectura J2EE

4.5.2.3. JAVA SERVER PAGES (JSP)

Tehnologia Java Server Pages (JSP) este cea mai populară metodă de a crea interfeţe Web pentru aplicaţiile care rulează pe platforma Java. Ea se bazează pe tehnologia numită Java Servlets fiind, de fapt, o completarea a acesteia în ideea creării cât mai facile a paginilor Web dinamice.

Tehnologia JSP a apărut pentru a acorda dinamicitate paginilor statice HTML şi pentru a evita scrierea de cod HTML în servlet-uri. Există la ora actuală o multitudine de medii de programare care pot gestiona vizual compoziţia unei pagini JSP, obţinând câştiguri foarte importante în productivitate faţă de generarea dinamică a codului HTML în cadrul unui servlet.

Punctul central al tehnologiei o reprezintă aşa-numitele pagini JSP care sunt, practic, fişiere text care combină descrieri HTML cu cod Java. Paginile JSP sunt gestionate şi accesibile prin intermediul unui server de aplicaţii. Acesta primeşte cereri

25


venite prin HTTP de la un browser Web. Dacă o cerere referă o pagină JSP, serverul prelucrează local pagina respectivă şi, în funcţie de conţinutul acesteia, generează dinamic o pagină HTML pe care o trimite, ca răspuns, browser-ului. Este important de reţinut faptul că toate prelucrările legate de paginile JSP se fac pe partea de server, acestea nefiind niciodată transmise în forma originală către client. În plus, trebuie reţinut faptul că serverul de aplicaţii include şi o maşină virtuală Java în care rulează atât codul Java întâlnit în paginile JSP cât şi obiectele instanţiate de acesta.

Paginile JSP prezintă avantaje faţă de servlet-uri deoarece permit separarea conţinutului static HTML al paginii de conţinutul generat dinamic, iar scrierea conţinutului HTML direct (nu prin intermediul operaţiilor de print, ca în servlet) este mult mai simplă şi mai intuitivă. Codul Java existent se converteşte într-un servlet care construieşte partea dinamică de răspuns şi această parte se combină cu partea statică din pagina JSP pentru a forma pagina HTML de răspuns către client.

Caracteristicile principale ale tehnologiei JSP, evidenţiate şi în lucrarea [VELI03] sunt:

poate funcţiona pe o multitudine de servere şi este independentă de platforma pe care rulează, întrucât scripturile JSP au la bază limbajul Java;

separă logica aplicaţiei (construită cu alte tipuri de tehnologii - servlet, JavaBeans etc.) de interfaţa cu utilizatorul (aspectul paginilor Web);

permite reutilizarea unor componente generate cu alte tehnologii atât independent cât şi în cadrul unor interfeţe de dezvoltare a paginilor Web;

pagina JSP se interpune între browser-ul clientului şi componentele pentru logica aplicaţiei (realizate în JavaBeans, CORBA, JDBC etc.) care accesează o bază de date;

tehnologia JSP se poate utiliza în aplicaţii tip multi-nivel (multi-tier); pagină JSP poate indica modul de manipulare a unor evenimente; execuţia unei pagini JSP este realizată de către motorul JSP instalat pe un

server de Web, care procesează pagina şi returnează o alta în format standard HTML/XML;

implementarea tehnologiei JSP se face în două etape: traducerea, care se efectuează o singură dată şi are ca efect generarea unui servlet şi procesarea fiecărei cereri în parte de către acesta;

pagină JSP poate conţine următoarele elemente: marcatori HTML, marcatori de date, marcatori JSP, HTML predefinit, cod Java etc.

4.5.2.4. SERVLET-URI

Un servlet este o clasă Java care prelucrează cererile clienţilor şi construieşte dinamic pagina HTML de răspuns. Servlet-urile sunt componente ale aplicaţiilor server, independente de platformă, care extind dinamic serverele care au suport Java integrat. Ele sunt independente şi de protocol, asigurând un cadru general pentru servicii pe baza modelului cerere-răspuns. Acest binecunoscut model este des folosit la programarea sistemelor distribuite, începând cu apeluri de proceduri la distanţă şi terminând cu protocolul HTTP pentru cereri către servere Web. Cu ajutorul servlet-urilor, aşadar, se extinde funcţionalitatea unei aplicaţii de tip server informaţional (nu neapărat server HTTP), un prim domeniu de aplicare fiind, bineînţeles, extinderea serverelor Web.

26


Servlet-urile pot fi considerate echivalentul applet-urilor pe partea de server, ele fiind asemănătoare din multe puncte de vedere. Însă, principala caracteristică a applet-urilor, interfaţa grafică utilizator, lipseşte din servlet-uri, ele neavând nevoie de aşa ceva din moment ce rulează în interiorul serverelor. În rest, ele se aseamănă mult, un servlet fiind şi el o componentă de aplicaţie, scrisă în Java, care poate fi transferată la un sistem care are nevoie de ea.

Servlet-urile reprezintă o alternativă oferită de Java pentru rezolvarea problemelor legate de timp apărute odată cu programarea Common Gateway Interface - CGI. Acestea facilitează dezvoltarea unor module care permit servere-lor Web să se conecteze şi să prelucreze informaţia în mod dinamic, adică să ruleze aplicaţii Web şi nu doar să transfere documente statice. Soluţia Java, menţine executabilul persistent pe server, între cererile clienţilor, spre deosebire de CGI unde fiecare cerere client lansează un nou proces pe server (ceea ce duce rapid la epuizarea resurselor serverului Web, adică la creşterea timpului).

Ciclul de viaţă al servlet-urilor este o proprietate specifică a acestora. Servlet-urile se încarcă în mod dinamic, serverele oferind facilităţi de administrare a încărcării şi a iniţializării acestora. Există şi posibilitatea, deloc de neglijat, de a specifica încărcarea anumitor servlet-uri la lansarea în execuţie a serverului. Odată încărcate, acestea devin parte integrantă a serverului. Procesul de încărcare este transparent pentru utilizator, acesta trebuind să specifice doar locaţia servlet-ului (local sau la distanţă), numele clasei ce conţine servlet-ul şi numele sub care acesta va fi cunoscut de către server (alias).

Caracteristicile principale ale servlet-urilor sunt evidenţiate în [VELI03] şi se referă la următoarele:

clasele şi metodele necesare pentru a defini şi utiliza un servlet sunt încapsulate în pachete Java;

tehnologia se utilizează pentru a dezvolta soluţii bazate pe Web: accesul securizat la pagini Web, asigurarea interacţiunii cu bazele de date, generarea dinamică a paginilor HTML, manipularea informaţiilor care identifică unic un client pe parcursul uneia sau a mai multor sesiuni;

se poate crea câte un servlet pentru fiecare funcţie din paginile Web (conectare, înregistrare, actualizare etc.) sau unul singur care să gestioneze toate tranzacţiile din paginile Web respective, în mod dinamic;

tehnologia este o soluţie optimă pentru aplicaţiile care utilizează intensiv bazele de date (serverul se ocupă de accesul la date iar clienţii formulează cererile de regăsire). Partea de cod se scrie o singură dată şi se stochează rezident, o singură dată, pe server. La actualizarea codului se va face o singură înlocuire, pe server, şi nu la fiecare utilizator în parte;

la iniţiere se pot deschide conexiuni la baze de date care devin astfel rezidente între apelurile clienţilor;

comunicarea client-server se realizează în mai mulţi paşi, astfel: clientul formulează şi trimite către server o cerere Web; serverul o direcţionează către servlet pentru a fi procesată (ceea ce implică de multe ori şi accesul la o bază de date); răspunsul (sub formă de pagini HTML, imagini etc.) este returnat serverului şi apoi clientului care a formulat cererea;

un servlet poate fi apelat dintr-o pagină HTML sau dintr-un applet;

27


principalele situaţii de utilizare a tehnologiei se referă la generarea paginilor Web dinamice şi la realizarea aplicaţiilor multi-nivel (multi-tier) cu JDBC. În acest ultim caz, servlet-ul poate accesa o varietate de baze de date prin intermediul JDBC şi poate realiza, parţial sau total, interfaţa cu utilizatorul prin pagini Web dinamice.

Paginile JSP şi componentele servlet sunt funcţional interschimbabile, dar unele aspecte de programare se rezolvă mai simplu într-una sau alta din tehnologii. În cazul în care cererea clientului necesită includerea unei mari părţi de cod HTML în pagina de răspuns, atunci paginile JSP sunt mai simplu de folosit. În schimb, dacă respectiva cerere necesită multiple operaţii de prelucrare a datelor, este indicată folosirea componentelor servlet.

4.5.2.5. ENTERPRISE JAVA BEANS (EJB)

JavaBeans este un model de dezvoltare a componentelor software care permite componentelor scrise în Java, numite beans, să comunice între ele. Aceste componente pot fi utilizate într-un editor vizual sau pot fi înglobate în interiorul unor aplicaţii. Un bean este în principiu o clasa Java care respectă anumite convenţii de construcţie.

Spre deosebire de componentele JavaBeans obişnuite, EJB sunt componente industriale care cuprind logica reutilizabilă de afaceri şi acces la resursele externe, cum ar fi bazele de date relaţionale ale unei companii.

Enterprise JavaBeans (EJB) este un standard pentru arhitectura componentelor la nivelul serverului. De fapt, EJB-urile sunt programe realizate în Java care reprezintă aproximativ 60% dintr-o aplicaţie J2EE. Modificarea sau introducerea unei noi funcţii se rezolvă simplu prin modificarea unui EJB sau prin introducerea unui EJB nou la nivelul serverului de aplicaţie, într-un timp redus. Actualizarea aplicaţiei se realizează într-un singur loc pe serverul de aplicaţie şi nu pe staţiile de lucru.

Primul dintre scopurile EJB este faptul că permite programatorilor să se concentreze asupra logicii afacerilor fără a mai fi preocupaţi de detalii de nivel inferior, cum ar fi ciclul de viaţă, necesităţile tranzacţionale de securitate etc. Aceste cerinţe sunt gestionate automat într-un mod care permite crearea componentelor ce pot fi transferate de pe un server de aplicaţie pe altul, acesta fiind un alt scop al arhitecturii pe niveluri.

În plus, EJB ţine întotdeauna cont de faptul că valoarea unei componente este deseori măsurată în posibilitatea de a o reutiliza.

4.5.2.6. JAVA SERVER FACES (JSF)

Java Server Faces (JSF) este o tehnologie nouă care permite construirea interfeţelor grafice şi controlul acestora pe partea de server. Deşi interfaţa poate fi generată şi prin servlet-uri sau prin pagini JSP, JSF oferă posibilitatea de a defini elemente mai complexe şi de a reutiliza componentele existente, acestea fiind deja testate şi uşor configurabile.

Tehnologia JSF include două componente majore [NET02]:

28


un set de API-uri pentru reprezentarea componentelor pentru interfaţa cu utilizatorul, controlul stărilor, lucrul cu evenimente, validarea datelor de intrare şi definirea modului de navigare între pagini;

o bibliotecă de marcatori (tag-uri) JSP pentru includerea elementelor de interfaţă din JSF în cadrul paginilor JSP;

Principiul de funcţionare a JSF se bazează pe arhitectura Model View Controller (MVC2) care propune separarea logicii aplicaţiei de partea de prezentare. Conform SunMicrosystems, o aplicaţie interactivă poate fi organizată în trei module complet separate unele de altele: primul pentru modelul aplicaţiei (reprezentarea datelor şi logica aplicaţiei), al doilea pentru prezentarea datelor într-o formă cât mai atractivă utilizatorilor, prin intermediul interfeţelor grafice, iar al treilea modul, numit controller, pentru gestionarea cererilor, repartizarea lor părţilor corespunzătoare din modelul aplicaţiei şi identificarea resursei care urmează să fie afişată. Prin urmare, în modelul MVC2 paginile JSP sunt izolate unele de altele şi au unicul rol de a asigura prezentarea datelor, întrucât logica aplicaţiei şi gestionarea cererilor sunt tratate separat.

O aplicaţie Web construită prin utilizarea tehnologiei JSF va conţine conform [TANA05]:

componente JavaBeans care vor conţine datele şi funcţionalităţile aplicaţiei; pagini Java Server Pages responsabile de modul de prezentare a datelor; biblioteci de marcatori (tag-uri) pentru generarea componentelor interfeţei cu

utilizatorul, precum şi pentru evenimente şi validări ale datelor de intrare; componente de interfaţă reprezentate de obiecte cu stări pe partea de server; validatori ai datelor la nivel de prezentare, înainte de actualizarea modelului

memorat pe server, elemente de tratare a evenimentelor şi reguli de navigare între pagini;

fişiere de configurare a aplicaţiei (fişiere XML în cadrul cărora sunt definite relaţiile şi interacţiunile dintre componentele JSF) şi a resurselor acesteia.

4.5.2.7. JAVA versus .NET

Atât Java cât şi .NET cumulează un număr semnificativ de tehnologii. Tocmai din acest motiv este destul de greu de făcut o comparaţie a performanţelor. Însă, privit din alt unghi, trebuie remarcat că sursele Java şi .NET sunt ambele interpretate iar în construcţia maşinii virtuale .NET s-a făcut uz de tehnologiile dezvoltate în cadrul maşinii virtuale Java (cum e de exemplu tehnologia JIT). .NET a fost dezvoltat şi optimizat pentru Windows, ceea ce poate înclina balanţa în favoarea acestei platforme. Însă Java este o tehnologie mult mai veche iar maşinile virtuale Java sunt destul de mult optimizate. De aceea în general performanţele .NET şi Java se consideră comparabile.

Marele avantaj al Java este datorat independenţei de platformă, aplicaţiile Java putând fi rulate pe orice sistem de operare care are instalat o maşină virtuală Java. Acest argument nu poate fi decât în favoarea Java, atâta vreme cât Linux devine tot mai popular, iar sistemul de operare al celor de la Apple, OSX, suportă şi el Java. În plus, nu trebuie exclus rolul pe care îl are în dezvoltarea continuă a platformei aşa-numita comunitate Java, compusă din oameni pasionaţi care au studiat îndelung limbajul şi au

29


reuşit să impună diferite standarde Java: tehnologiile de programare pe server şi unele aplicaţii desktop.

Microsoft este încă sistemul de operare folosit cu precădere de microcalculatoare. Se afirmă chiar că, până şi cei care nu sunt fani împătimiţi ai Microsoft, utilizează totuşi tehnologiile lor. Iar câtă vreme Microsoft domină ar fi ilogic să nu se realizeze aplicaţii care să se poată integra perfect în mediul Windows. Principalul limbaj utilizat pentru dezvoltare de aplicaţii Windows al .NET este indiscutabil C#, cel despre care se spune că nu împrumută numai puterea C-ului, ci şi structura bibliotecilor Java.

Se ştie că C# vine de la Microsoft ca un echivalent la Java şi cu un suport mai puternic (decât celelalte limbaje) pentru mult mediatizata platformă .NET. Însă, dacă C# (sau mai bine zis .NET) nu va fi independent de platformă (ceea ce este mai mult ca sigur) şi atât timp cât vor exista sisteme de operare concurente - pentru care există Java, acesta din urmă nu are cum să devină învechit ca limbaj de programare sau ca platformă de dezvoltare. Ideea anterioară este întărită luând în considerare faptul că Java este un produs gratuit, este sprijinit de mari nume din industria IT (ca IBM, Borland etc.) şi deja există un număr foarte mare de programatori care sunt fascinaţi de acest limbaj.

Un alt concurent destul de puternic pentru C# (şi chiar şi pentru Java) ar putea deveni Delphi care are componente de .NET, are destul de mulţi "adepţi" şi, ca şi C# şi Java, poate fi încadrat în categoria Rapid Application Developement (dezvoltare rapidă de aplicaţii).

Codul generat de oricare dintre platformele .NET şi Java este interpretat, însă performanţele nu se ridică la nivelul codului nativ generat, spre exemplu, de compilatoarele de C/C++. Cu toate acestea, aplicaţiile scrise pentru platformele interpretate câştigă teren în faţa celor native din alte puncte de vedere: productivitate în dezvoltare, transparenţă a platformei, un nivel sporit de reutilizare a codului, mentenanţă semnificativ îmbunătăţită, un mai bun management al complexităţii.

.NET Framework prezintă o serie de avantaje: suportă limbaje gen C/C++, Perl, VB, Python etc. Spre deosebire de acesta, platforma Java suportă doar limbajul Java (în speţă mediile de dezvoltare comerciale şi nu limbajele de interes academic).

Există de asemenea avantaje de performanţă ale platformei .NET faţă de Java (legată de viteza de execuţie a codului .NET, foarte apropiată de performanţa codului nativ x86), avantaje ţinând de suportul nativ pentru servicii Web sau avantajul integrării în sistemul de operare.

.NET îşi propune rezolvarea problemei interoperabilităţii în următorul mod: cum se poate realiza comunicarea a două aplicaţii X şi Y extrem de diferite, scrise în limbaje distincte? Răspunsul .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 fără a fi necesară rescrierea acestuia în Java.

Abordarea Java, în schimb, este extrem de diferită, încercând să promoveze portabilitatea ca soluţie universală, în locul interoperabilităţii. Cu alte cuvinte, în loc să facem aplicaţiile X şi Y de mai sus să vorbească între ele, mai bine rescriem totul în Java.

Un avantaj Java, însă, ar fi suportul pentru multithreading, deoarece este important să poţi scrie o aplicaţie multithreading care să meargă perfect pe orice sistem de operare suportat.

Problema comunicării dintre aplicaţii în Java este rezolvată de către JVM (Java Virtual Machine), considerată o soluţie impresionantă. Singura problemă ar fi cantitatea

30


de memorie consumată, deoarece pentru fiecare aplicaţie se iniţiază o JVM nouă. O soluţie pe care SUN o tot promite încă de prin anii 1996 este Multi-tasking Virtual Machine - MVM.

Se remarcă, de asemenea, faptul că tehnologia Java este utilizată cu predilecţie în cazul dezvoltării aplicaţiilor de întreprindere cu baze de date, care utilizează Oracle sau IBM DB2, în timp ce .NET este utilizat în special în dezvoltarea aplicaţiilor care utilizează baze de date SQL Server (tot de la Microsoft).

Prin urmare, deşi limbajele sunt foarte asemănătoare (C# / Java), iar framework-urile, deşi diferite pe alocuri, se aseamănă foarte mult, se pot desprinde anumite concluzii, formulate în detaliu în articolul [EFTI02].

În realizarea comparaţiei platformelor s-a luat în calcul faptul că diversele variante de implementare a specificaţiei J2EE duc la diverse calităţi ale produselor finale, care variază între „Java best” (cea mai bună soluţie) şi „Java worst” (cea mai slabă soluţie).

Figura 4.21. Java vs. .NET

Ţinând cont de aceste considerente, analiza celor două platforme a evidenţiat următoarele (figura 4.21):

din punctul de vedere al independenţei faţă de producător, Java domină, întrucât funcţionează pe mai multe platforme şi rulează la fel de bine pe Linux/Solaris/AIX/macosx/Windows, în vreme ce .NET funcţionează numai pe sistem de operare Windows (se remarcă, însă, buna integrare cu acesta);

în privinţa abilităţii producătorului şi a posibilităţii de dezvoltare ulterioară a platformelor pe piaţa IT, cele două produse au aproximativ aceeaşi evoluţie. La Java, însă, poate fi remarcată „strategia de supravieţuire”: grupul de producători de soluţii Java şi-a împărţit capacitatea de producţie, orice produs Java fiind dezvoltat în paralel de mai mulţi producători. Astfel, existenţa şi dezvoltarea viitoare a platformei nu depinde în mod necesar de

31


existenţa companiei Sun, în cazul insolvabilităţii acesteia, rolul său putând fi transferat altei companii;

costurile cu licenţele şi cu întreţinerea sunt un factor ce nu trebuie neglijat în luarea deciziei utilizării uneia dintre cele două tehnologii. Costurile soluţiilor J2EE ale unor furnizori ca IBM sau BEA sunt transferate deja în categoria mainframe-urilor. Nu trebuie însă uitate ofertele open-source distribuite gratuit. Struts, JUnit, Eclipse, iar mai nou şi Oracle JDeveloper – sunt doar câteva nume de framework-uri, module sau instrumente de dezvoltare gratuite care nu mai au nevoie de nici o recomandare suplimentară în lumea programatorilor şi a inginerilor de software. Comparativ cu cele două variante de implementare Java - „Java best” şi „Java worst”, pe scara preţurilor, Microsoft .NET este aşezat undeva pe la mijloc;

eficienţa în utilizare se poate măsura atât din punctul de vedere al automatizării procesului de dezvoltare, cât şi din cel al existenţei uneltelor de depanare sau al celor de control al versiunilor. Din acest punct de vedere, pentru unele dintre implementările J2EE performanţele celor două platforme sunt aproximativ echivalente;

portabilitatea este unul dintre avantajele certe ale platformei Java, aplicaţiile putând fi rulate pe orice sistem care are instalat o maşină virtuală Java (Java Virtual Machine - JVM), care este însă mare consumatoare de memorie. Portabilitatea în Java este asigurată de Java Runtime Environment (JRE), iar serverul de aplicaţii şi alte produse middleware pot fi programate în funcţie de sistemul de operare. Spre deosebire de Java, .NET nu prezintă portabilitate, dar încearcă să remedieze problema prin intermediul serviciilor Web, răspunzătoare de realizarea interoperabilităţii dintre aplicaţii;

dincolo de criteriile de performanţă, trebuie să se ţină cont de eficienţa platformei şi de productivitatea furnizată în dezvoltarea aplicaţiilor. Dacă se măsoară productivitatea numai pe baza numărului de linii de cod, .NET prezintă avantaje clare faţă de Java. Crucial este însă cât dintre aceste linii de cod trebuie sa fie scrise manual de către dezvoltatorul de aplicaţii. Aici intervine, însă, atât procesul automatizat de dezvoltare, cât şi inteligenţa mediului de dezvoltare software;

studiind aspectele legate de maturitatea şi stabilitatea platformei, se constată că, de-a lungul timpului, produsele J2EE au căpătat un grad mare de maturizare, datorat şi popularităţii obţinute de-a lungul timpului de tehnologia Java.

32


STUDIUL TEHNOLOGIILOR INFORMATICE DE INTEGRARE A

APLICAŢIILOR..................................................................................................................1

4.3. Standarde utilizate la integrarea aplicaţiilor.................................................1

4.3.1. Business Process Execution Language - BPEL.....................................1

4.4. Arhitecturi utilizate în integrarea aplicaţiilor................................................7

4.4.1. Arhitectura orientată pe servicii.............................................................7

4.4.2. Oracle Application Integration Architecture.......................................11

4.4.3. Enterprise Services Architecture..........................................................11

4.5. Tehnologii informatice de integrare a aplicaţiilor......................................12

4.5.1. Tehnologia middleware.......................................................................12

4.5.2. Java......................................................................................................20

33

4.5. Tehnologii informatice de integrare a aplicaţiilor

Documents

Transcript of 4.5. Tehnologii informatice de integrare a aplicaţiilor