Studiul tehnologiilor informatice de integrare a aplicaţiilor standarde utilizate la integrarea aplicaţiilor

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.

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;
  
• 
  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]:

• 
  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 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 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 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.
  

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