Realizarea Unei Aplicatii Java Maven

Proiect de diplomă

Realizarea unei aplicații

Java Maven, utilizând

serverul de aplicații GlassFish

roducere

Alegerea unei platforme potrivite și a tehnologiilor aferente pentru o aplicație web de tip enterprise poate să fie un proces îndelungat și consumator de resurse. În ziua de astăzi, cei mai mulți arhitecți software aleg dintre cele mai comune stive de specificații web: LAMP (Linux – Apache – MySQL – PHP) sau WISA (Windows – IIS – SQL Server – ASP.NET). Cele două collecții de tehnologii sunt favorizate datorită înțelegerii ușoare a tehnologiilor și a tiparelor de programare. Cu toate acestea, în momentul expansiunii proiectului spre mediul enterprise, multe dintre aceste platforme cedează sub greutatea lipsei scalabilității și a imposibilității de mentenanță eficientă.

Această lucrare descrie procesul de dezvoltare și întreținere a unei aplicații de tip Java Web, utilizând instrumentul de build Maven, server-ul de aplicații GlassFish și tehnologiile specificate de Java Enterprise Edition. Motivul lucrării îl reprezintă dovedirea capabilităților de dezvoltare a platformelor enterprise folosind uneltele Java Web, în comparație cu restul platformelor de dezvoltare recunoscute.

Aplicațiile enterprise au nevoie să acceseze date, să aplice algoritmi complecși, să adauge straturi de prezentare și să comunice cu sisteme exterioare. Fiecare companie încearcă să implementeze aceste funcții, în concordanță cu minimizarea costurilor de întreținere și dezvoltare.

Valoarea adevărată a standardului Java Enterprise Edition nu stă în multitudinea trăsăturilor, ci mai degrabă în comunitatea de persoane ce le-au creat. Libertatea programatorilor software nu este impusă doar de noțiunea open-source, ci și de open-standards.

Lucrarea este structurată in patru capitole principale, dintre care primele două prezintă implementările alese, iar al treilea descrie aplicația practică care utilizează toate aceste tehnologii. Lucrarea se încheie cu un capitol dedicat concluziilor și observațiilor personale ale autorului.

Capitolul I – Java Enterprise Edition – acoperă structura platformei și modelul de programare. Se descrie procesul de gândire și listare a specificațiilor Java EE de către comunitatea JCP, cât și un scurt istoric a acestor tehnologii. Succesiv acestui capitol este Capitolul II – Tehnologii și Unelte – ce prezintă toate cuvintele cheie din titlul lucrării în detaliu, incluzând toate implementările și instrumentele aferente.

Capitolul III – Aplicația Practică – prezintă un caz real de implementare a tehnologiilor și tiparelor descrise în capitolele precendente. Secțiunea cuprinde și o analiză de tip sus-jos a proiectului, descriind structura modulară a acestuia.

“Există două moduri de construire a unui software: Un mod este de a construi o aplicație foarte simplă încât să nu se observe deficiențele. Celălalt mod este de a construi o aplicație suficientă de complexă încât să nu se observe deficiențele.”

– C.A.R. Hoare, cercetător britanic în informatică

Capitolul I. Java Enterprise Edition

Java Enterprise Edition a apărut la sfârșitul anilor 1990 aducând limbajului Java o platformă robustă pentru dezvoltarea aplicațiilor enterprise. Contestată la fiecare versiune nouă, platforma a fost neînțeleasă, folosită greșit, supra-programată și pusă în competiție cu alte framework-uri open-source. Astfel, această tehnologie a fost percepută ca grea și complexă. Comunitatea Java a profitat de aceste critici, simplificând tehnologia și aducând-o într-un stadiu stabil și compact. Din acest punct al lucrării, orice referință la Java Enterprise Edition va fi facută prin abrevierea JavaEE.

Colecția de standarde deschise formează principala sursă de putere a Java EE. De exemplu, o aplicație scrisă cu JPA, EJB, JSF, JMS, SOAP și/sau RESTful Web Services este portabilă peste mai multe server-e de aplicații. Atributul de open-source este de asemeanea un punct forte a platformei. Cele mai multe implementări ale specificațiilor Java EE sunt create sub licență open-source.

În terminologia Java, standardele sunt cunoscute sub numele de JSR-uri (Java Specification Request) – documente formale ce descriu specificațiile propuse și tehnologiile viitoare din platforma Java. Acestea sunt astfel concepute încât versiunile de platformă să aibă o anumită consistență între ele (backward compatibility).

În ziua de astăzi (2014), platforma JavaEE are un număr de 47 de JSR-uri, listate pe site-ul oficial al comunității.

I.1. Istoric

Cunoscut inițial sub numele de J2EE, versiunea 1.2 a fost dezvoltată de către Sun și dată spre utilizare în 1999 conținând 10 JSR-uri. La vremea respectivă s-a luat în considerare modelul sistemelor distribuite. Enterprise Java Beans (EJB) au fost introduse cu suport pentru servicii obiectuale de la distanță și suport optional pentru persistarea obiectelor.

Specificațiile au fost construite pe un model distribuit tranzacțional și modular care folosește RMI-IIOP (Remote Method Invocation – Internet Inter-ORB Protocol).

Stratul web era bazat pe servlets, JSP (JavaServer Pages – tehnologia ce generează pagini web dinamice utilizând Java) și JMS pentru trimiterea de mesaje.

I.2. Standarde

Java EE este bazată pe standarde. Este o “specificație umbrelă” ce encapsulează o mănunchi de JSR-uri. Motivul este unul simplu: s-a urmărit exemplul altor domenii (limbi, navigare, măsurători, electricitate, telefonie, protocoale etc.).

Apariția framework-urilor open-source nu a însemnat și existența standardelor libere. Acum, folosirea open-source înseamnă limitarea la framework-ul respectiv, vreme ce folosirea unui open-source ce implementează un standard reprezintă portabilitate și flexibilitate.

Orice aplicație JavaEE poate fi migrată de pe o implementare pe alta (comerciala: servere WebLogic, WebSphere etc. sau open-source: servere GlassFish, Jboss etc.), deobicei cu foarte puține schimbări.

I.3. Arhitectură

Java EE este un set de specificații implementate de containere diferite. Containerele sunt medii Java care asigură aplicația cu anumite servicii: ciclu de viață, injecție de dependințe etc. Aceste componente folosesc contracte bine definite pentru a comunica cu infrastructura Java EE și cu celelalte componente. Acestea sunt împachetate într-un mod standard (fișiere arhivate) înainte de a fi găzduite. Fiind un superset al platformei Java SE, orice API din aceasta poate fi folosit și în Java EE.

Figura I.1. prezintă structura logică dintre aceste containere. Săgețile reprezintă protocoalele utilizate de fiecare container pentru a accesa altul.

Fig.I.1. Container Java EE Standard

Mediul Java EE specifică patru tipuri de componente pe care o implementare este obligată sa le suporte:

Applets – Aplicații interfață utilizator care sunt executate în browser.

Applications – Sunt acele programe ce sunt executate pe un client. Deobicei sunt aplicații cu o interfață vizuală, sau linie de comandă.

Web Applications – Aplicații construite din mai multe componente web. Sunt executate într-un container web și au rolul de a răspunde la cereri HTTP de la clienți web.

EJBs – “Container-managed components for processing transactional business logic”. Ele pot fi accesate local și de la distanță utilizând RMI.

I.4. Arhivarea unui proiect

Pentru a fi găzduita într-un recipient, o aplicației Java EE necesită o arhivare folosind un format standard. Java SE definește fișierele JAR (Java Archive) care conțin un agregat de mai multe fișiere specifice Java: clase, descriptori, resurse, librării externe etc. Java EE definește alte tipuri de arhivări proprii.

Pentru proiectele web, cea mai comună formă de arhivare este WAR (Web Archive), dar în unele cazuri (cazurile proiectelor enterprise) se folosește EAR (Enterpise Archive) care prezintă un alt set de proprietăți. Figura I.2. prezintă structura generică a aplicațiilor Java Web, fiind una dintre tiparele recomandate pentru astfel de proiecte.

Fig.I.2. Organizarea fișierelor în stadiul de dezvoltare

a aplicațiilor Java Web

Assembly Root reprezintă nivelul cel mai superior al arhivei. Acesta conține directoarele cu paginile web, cât și directorul WEB-INF care encapsulează clasele compilate Java, librării externe și descriptori (fișiere de configurare).

I.5. JavaServer Faces

JavaServer Faces (pe scurt: JSF) dă posibilitatea dezvoltatorilor de aplicații web să construiască interfețe cu utilizator solide, folosind un set extensibil de componente reutilizabile. Cu ajutorul oferit de JSF, se pot crea interfețe complexe ce comunică în mod eficient cu o sursă de date.

JSF este compus din trei straturi: o arhitectură pentru componente, o colecție standard de UI widgets și o infrastructură pentru aplicații web. Arhitectura de componente definește un mod comun de construire a widget-urilor personalizate. Componentele standard includ butoane, hyperlink-uri, checkbox-uri, câmpuri de text etc., acestea punând bazele componentelor third-party.

Deoarece aplicațiile web, spre deosebire de aplicațiile desktop, sunt necesare a se prezenta în diferite medii utilizator (browser, telefoane mobile, tablete, PDA-uri etc.), JSF oferă o arhitectură puternică și flexibilă pentru afișarea componentelor în mai multe moduri. În același timp oferă facilități extensibile pentru validarea input-ului de la utilizator (validarea unei parole, de exemplu).

Pentru a ține toate aceste element de UI sincronizate cu obiectele Java, JSF are o arhitectură prin care transformă unele obiecte Java în entități de colectare a datelor numite “backing beans”. Aceste bean-uri sunt legate în mod bidirecțional de componentele JSF din paginile web.

Fiind compatibil cu aplicațiile enterprise, o altă caracteristică a JSF este capabilitatea de internaționalizare și traducere a componentelor cu text dinamic.

Toate aceste caracteristici descriu JavaServer Faces ca fiind tehnologia ideală pentru aplicațiile Java Enterprise. Următoarele subcapitole se concentrează pe detaliile acestor trăsături.

I.5.1. Principiile de funcționare

Aplicațiile Java pentru desktop folosesc și ele anumite librării (framework-uri) pentru construirea interfeței cu utilizatorul. Două dintre cele mai comune sunt Swing și SWT. Diferența majoră dintre JSF și acestea este faptul că JSF rulează pe server. Astfel, o aplicație Faces operează într-un recipient ca GlassFish.

În Swing, când un buton este apăsat, se aruncă o notificare care poate fi manipulată direct în codul scris pentru aplicația de desktop. În contrast, browser-ele web nu sunt conștiente de existența componentelor JSF sau a notificărilor. Ele știu doar să afișeze HTML. Prin urmare, la apăsarea unui buton în JSF se va trimite o cerere de la client (browser) către server (GlassFish). Faces este responsabil pentru traducerea acestei cereri într-o notificare ce poate fi procesată de către logica aplicației de pe server. Este de asemenea responsabil pentru translația fiecărui widget creat pe server în componente de UI din browser.

Fig.I.3. O privire de la nivel înalt a unei aplicații JavaServer Faces.

Figura I.3. prezintă o vizualizare de la distanță a unui proiect JSF. În aceasta se poate observa faptul că aplicația rulează pe server și în același timp poate fi integrată cu alte sub-sisteme (exemplu: EJB-uri, baze de date etc.).

I.5.2. Sprijinul tehnologic

Toate aplicațiile JSF pot fi considerate aplicații standard Java Web. Acestea comunică utilzând protocolul HTTP prin Servlet API. Tehnologia de afișare a datelor este constituită din componente ce comunică direct cu obiectele Java.

HTTP excelează la servirea conținutului static, dar pentru generarea de conținut dinamic este necesară scrierea de cod. Java Servlet oferă o soluție orientată pe obiecte a interfețelor web. Cererile și răspunsurile HTTP sunt încapsulate în obiecte, iar accesul la acestea se face prin stream-uri. În mod obișnuit, o întreagă aplicație Java Web este bazată în totalitate pe servlet-uri ce rulează în recipiente Java EE.

JSF aduce îmbunătățiri snivel înalt a unei aplicații JavaServer Faces.

Figura I.3. prezintă o vizualizare de la distanță a unui proiect JSF. În aceasta se poate observa faptul că aplicația rulează pe server și în același timp poate fi integrată cu alte sub-sisteme (exemplu: EJB-uri, baze de date etc.).

I.5.2. Sprijinul tehnologic

Toate aplicațiile JSF pot fi considerate aplicații standard Java Web. Acestea comunică utilzând protocolul HTTP prin Servlet API. Tehnologia de afișare a datelor este constituită din componente ce comunică direct cu obiectele Java.

HTTP excelează la servirea conținutului static, dar pentru generarea de conținut dinamic este necesară scrierea de cod. Java Servlet oferă o soluție orientată pe obiecte a interfețelor web. Cererile și răspunsurile HTTP sunt încapsulate în obiecte, iar accesul la acestea se face prin stream-uri. În mod obișnuit, o întreagă aplicație Java Web este bazată în totalitate pe servlet-uri ce rulează în recipiente Java EE.

JSF aduce îmbunătățiri semnificative la servelt-uri care includ manipularea automată a unor tipuri de cereri și răspunsuri dintre client și server. Având componente de UI, JSF își împarte toate aceste căi de comunicare cu interfața web. În consecință, dezvoltatorului îi este oferit un nivel mare de abstractizare, scutindu-l de grijile cu cereri și răspunsuri HTTP, sau cu cele legate de servlet-uri.

O altă parte importantă din arhitectura Faces o reprezinta JavaBeans. Conceptual, JavaBeans sunt clase simple cu un număr oarecare de proprietăți, care sunt expuse prin setter-e și getter-e. De exemplu, o clasă Java cu metodele getName și setName expun proprietatea name a clasei. În cazul acestei lucrări, JavaBeans sunt utilizate sub numele de backing beans, folosind tot aceleași proprietăți.

I.5.3. JSF ca și framework

Ca și orice alt framework Java Web, Faces impune separarea de preocupări, adică diferențierea între stratul de prezentare și stratul de business logic. Cu toate acestea, JSF este înclinată către partea de interfață și prezentare, putând fi integrată cu alte tehnologii specializate pe business logic.

Toate sarcinile legate de UI sunt controlate de framework. Cel mai simplu exemplu de astfel de sarcină este procesarea formularelor. HTML-ul are formulare de pagină ce reprezintă colecții de input de la utilizator (exemplu: căsuțe de text, liste de căutare, butoane de confirmare etc.). Când utilizatorul confirmă formularul, toate aceste date sunt trimise către server. Un exemplu de câmp dintr-un astfel de formular este:

<input maxlength=256 size=55 name=”userName” value=”” />

Într-o aplicație web standard bazată pe servlet-uri, extragerea acestei valori se face direct din cererea de HTTP:

String userName = (String)request.getParameter(“userName”);

Acest tip de procesare de date este inconvenabil pentru formulare de dimensiuni mari. În acest caz, codul Java va trebui să asigure și validitatea datelor. Dezvoltarea și menținerea formularelor de acest tip este considerat un coșmar în programare.

Organizarea de bază și management-ul serviciilor este o necesitate pentru aplicațiile enterprise, dar în același timp este nevoie și de o structurare logică. În acest sens JSF urmează tiparul MVC (Model-View-Controller).

Figura I.4. prezintă o structură MVC specifică aplicațiilor Java Web:

Modelul constă în clase Java de tip POJO

View-ul este reprezentat de JSP sau altă tehnologie de display

Straturl de controller este constituit din servlet-uri

Fig.I.4. Structura de bază MVC a cărei variațiuni sunt urmate

de majoritatea framework-urilor web

Având acest tipar implementat, orice eroare de pe oricare strat al aplicației va fi detectată, testată și corectată pe același nivel. Dacă paginile JSP conțin erori, acestea nu vor afecta nici logica aplicației, nici modelul. Această separare permite testările de unitate pe fiecare strat în parte (exemplu: testare cu JUnit).

Capitolul II. Unelte Java EE

Pentru a ușura dezvoltarea și mentenața proiectelor Java EE, unele instrumente vin în ajutorul proiectanților. Cele trei unelte principale a căror capabilități sunt demonstrate în aplicația practică sunt: unealta de build Maven, server-ul de aplicații GlassFish și baza de date PostgreSQL.

În continuare se prezintă toate acestea în detaliu, făcând o paralelă cu alte tehnologii similare.

II.1. Apache Maven

Maven este atât un instrument de asamblare și de management, cât și un recipient abstract pentru rularea sarcinilor de asamblare a proiectelor. S-a demonstrat a fi indispensabil pentru proiectele complexe cu un număr mare de componente greu de întreținut.

Spre deosebire de o unealtă similară, Apache Ant, care se concentrează strict pe preprocesare, compilare, împachetare, testare și distribuție, Maven asigură un superset a acestor caracteristici, ocupându-se și de partea de management a proiectelor.

Parafrazând o definiție formală, “Maven este o unealtă de management a proiectelor ce encapsulează un model de proiect, un set de standarde, un ciclu de viată a proiectului, un sistem de management a dependințelor proiectului și o logică pentru executarea unor obiective în diferite faze a ciclului de viată a proiectului. Când Maven este folosit, proiectul va urmări un tipar bine definit asupra căruia se vor putea aplica o serie de logici de asamblare.”

II.1.1. Interfațare

Înainte ca Maven să asigure o interfață comună de construire a software-ului, fiecare proiect în parte trebuie să-și asigure propriul mecansim de management și asamblare. Dezvoltatorii erau nevoiți să consume din timpul de scriere a codului pentru a învăța idiosincrasiile fiecărui proiect noi la care doreau să contribuie. Era precedentă lui Maven a dat naștere așa-numiților “ingineri de asamblare”.

În ziua de astăzi, marea majoritate a dezvoltatorilor de open-source folosesc (sau cel puțin au folosit) Maven pentru a asigura un management adecvat a software-ului nou. Scopul ultimat al acestei unelte este standardizarea asamblării proiectelor, aducând o interfață comună.

II.1.2. Tiparul conceptual al unui proiect Maven

Maven definește un model de proiect. Un dezvoltator nu numai compilează cod, ci și creează un set de coordonate ce descriu aplicația. Aceste atribute a aplicației pot include: tipul de licență a proiectului, cine dezvoltă și menține aplicația, care alte proiecte depind de acesta etc.

Tipar este descris într-un fișier descriptor numit POM (Project Object Model). Modelul de proiect prezintă caracteristici ca:

Management-ul dependințelor. Fiecare proiect este descris de un set unic de coordonate ce sunt alcătuite din un identificator de grup, un identificator de artifact și un identificator de versiune. Utilizând aceste coordonate, se pot identifica automat alte dependințe externe, cu o minimizare a necesității interacțiunii umane.

Exemplu de coordonate:

Group ID: com.georgian.grec

Artifact ID: știicumzic

Version: 2.1.2-SNAPSHOT

Depozite la distanță. Utilizând coordonatele de proiect, se pot crea depozite de dependințe, care pot fi făcute publice în scopul împărtășirii acestora cu alte proiecte.

Reutilizare universală a logicii de asamblare. Regulile de ansamblare nu sunt specifice doar pentru un set de fișiere, ci pot fi reutilizate chiar și în alte proiecte.

Portabilitate și integrare. Medii de dezvoltare ca Eclipse sau NetBeans au ocazia de a avea descrierea unui proiect într-un singur loc. Înainte de Maven, fiecare mediu de dezvoltare trebuia să-și descrie singur structura de proiect, astfel eliminând caracteristica de portabilitate a acestuia.

Căutarea și filtrarea ușoară a artefactelor. Dezvoltatorul poate căuta alte artefacte dependente direct din mediul de dezvoltare. Se pot adăuga și șterge în mod dinamic depozitele de artefacte.

II.1.3 Apache Maven versus Apache Ant

Ant excelează la procesul de asamblare, fiind bazat pe sarcini și dependințe (similar cu “make” a sistemelor UNIX). Fiecare sarcină constituie un set de instrucțiuni aflate într-un fișier XML. Pentru a utiliza Ant, se specifică intrucțiuni de compilare și împachetare a rezultatului. Din acest motiv, Ant necesită detalii explicite ca: unde se află fișierele sursă, unde vor fi plasate fișierele compilate, care sunt dependințele necesare, și care este modalitatea de împachetare.

În contrast, Maven necesită doar creearea unui fișier descriptor pom.xml în directorul proiectului, urmată de rularea comenzii mvn install în linie de comandă. Astfel, procesul de asamblare este automatizat, asigurând rapiditatea dezvoltării.

Ant

Nu are convenții formale ca o structură comună de proiect sau un comportament predefinit.

Este procedural. Fiecare pas din asamblare trebuie descris explicit.

Nu are ciclu de viață. Sarcinile se definesc manual de către dezvoltator.

Maven

Are conveții. Este conștient de locația proiectului datorită respectării standardelor.

Este declarativ. Setul minim de operații necesare este creerea unui fișier pom.xml și plasarea lui în directorul proiectului

Are ciclu de viață propriu. În momentul execuției comenzii mvn install în linie de comandă, Maven va trece prima oară prin alte comenzi incluse automat (exemplu: rularea de teste, curățarea proiectului, rezolvarea dependințelor etc.).

Decizia de a alege Maven sau Ant nu este una binară. În mod evident, Ant își are propriul loc în proiectele de avengură mare. Există cazuri în care script-uri Ant pot fi folosite împreuna cu Maven, doar dacă respectă standardele impuse de Maven.

În creerea aplicației practice a acestei lucrări se alege Maven datorită numărului mare de dependințe a proiectului și capabilității de dezvoltare rapidă oferită de Maven.

II.2. GlassFish Server

GlassFish este un server de aplicații open-source înființat de Sun Microsystems pentru platforma Java EE, în momentul de față fiind finanțat și întreținut de Oracle Corporation. Mai este cunoscut sub denumirea de Oracle GlassFish Server. Proiectul se află sub o licență duală: “Common Development and Distribution License” (CDDL) și “GNU General Public License” (GPL).

Este o implementare de specificație Java EE, oferind tehnologii ca EJB, JPA, JSF etc. menționate anterior, în al doilea capitol.

Construit peste un kernel modular (sprinjit de OSGi), GlassFish rulează peste implementarea Apache Felix.

II.2.1. Asocierea cu Java EE

GlassFish este considerat ca fiind prima implementare a Java EE 6 și de asemenea este primul server de aplicații ce suportă întreaga platformă Java EE 6 și noua platformă Java EE 6 Web Profile, care este special construită pentru aplicații web.

Suportul extensiv pentru clustering asigură încredere, scalabilitate, toleranță la defecțiuni și performanță pentru aplicații găzduite.

II.2.2. Viteză

Este considerat cel mai rapid server open-source de aplicații. A obținut cel mai mare scor la testul de performanță SPECjAppServer 2010, rezultatele fiind disponibile online.

Server-ul a dovedit perfomanță ridicată, start-up rapid și administrare simplificată.

II.2.3. GlassFish Server Control

GlassFish Server Control este o suită de unelte ce îmbunătățește management-ul găzduirilor de producție. Această suită include:

Monitorizarea clientului utilizând script-uri. Suport pentru script-uri personalizate ce monitorizează server-ul pe întreaga perioadă a rulării.

Backup și recuperare a domeniilor. Fiind bazat pe domenii de server, GlassFish realizează back-up-uri automate a domeniilor active, în mod automat.

Tuner de performanță. Îmbunătățiri de până la 300% față de configurația standard.

Cache activ. Replicări de resurse automate în memoria proprie.

Oracle Access Manager. Suport pentru autentificarea unor servicii și aplicații Oracle.

Load balancing. “Metodă în rețelele de calculatoare prin care volumul de muncă a server-ului se distribuie uniform peste mai multe resurse fizice: calculatoare în plus, cluster de calculatoare, rețele, unități centrale de procesare etc. Scopul este pentru îmbunătățirea performanței server-ului.”

II.2.1. Administrarea server-ului

Incluzând administrarea din linie de comandă, cât și din interfața grafică web, GlassFish oferă utilizatorilor un set extensibil de unelte pentru mentenanță și dezvoltare. Una dintre acestea este Call-Flow, un monitor integrat de observare a timpilor de răspuns dintre server și client.

II.3. PostgreSQL

PostgreSQL este un Object-Relational Database Management System (ORDBMS) care a luat diverse forme începând cu 1977. Din 1986, sistemul ope-source a fost dezvoltat sub numele de Postgres, urmând ca în anul 1996 să ia denumirea de PostgreSQL.

PostgreSQL este considerată de mulți dezvoltatori a fi cea mai avansată bază de date open-source din lume. Alte sisteme de baze de date similare include Microsoft SQL Server, MySQL sau chiar și MongoDB.

De-a lungul anilor PostgreSQL a dezvoltat o serie de caracteristici unice, care nu se regăsesc în alte sisteme de baze de date. Acestea sunt descrise în detaliu de către următoarele capitole.

II.3.1. Limitări

Fig.II.2 Limitările PostgreSQL

Sursa: “Postgres Succintly” de Peter Shaw, 2013 Syncfusion Inc.

Motivul acestor statistici este modul în care Postgres își persistă datele. Acestea sunt salvate sub forma unor fișiere standard pe sistemul gazdă. Astfel, singurele limitări ale baze de date sunt impuse de către limita superioară a spațiul de stocare fizic.

Sistemul are de asemenea o varietate de tipuri de indecși pentru a asigura accesul eficient al datelor. Indecșii standard a PostgreSQL sunt: B-Tree, Hash, GiST. Desigur, aceștia pot fi extinși, sau adăugați alții noi.

De asemenea, Postgres este o bază de date orientate pe obiecte. Este concepută astfel încât să modeleze datele în mod similar cu limbaje de programare ca Java sau C#.

II.3.2. Moștenirea între tabele

Moștenirea între tabele este procesul de utilizare a tabelelor unei baze de date utilizând principiile programării orientate pe obiecte. Astfel, componentele unui tabel pot fi moștenite de la altul, în timp ce acesta aduce propriile contribuții la structură.

Această funcționalitate este utilă în momentele de expansiune ale aplicației. Structura de bază se păstrează, iar noile tabele extind funcționalitate deja existentă.

Postgres este integrat cu un număr mare de limbaje de programare. Astfel, se pot crea proceduri în mod automat. Câteva dintre ele sunt: Java, C/C++, Ruby, Python, Perl, PHP etc. Toate aceste limbaje folosite în mod procedural pot avea impact direct asupra datelor din table (exemplu: bucle FOR, bucle WHILE, structuri condiționale etc.).

Capitolul III. Aplicația Practică – știicumzic.ro

Exemplul de implementare este o platformă online și un website de tip social media unde utilizatorii au posibilitatea de a împărtăși imagini de tip GIF însoțite de titluri. Conținutul este votat pozitiv și negativ de către ceilalți utilizatori, iar cele mai votate posturi vor face parte dintr-un top săptămânal.

Similar cu alte site-uri de tip social media (exemplu: Reddit, Digg, 9GAG etc.), știicumzic.ro adună o colecție de posturi a căror GIF-uri, în combinație cu titlurile acestora, sugerează amuzament.

Motivul alegerii acestei teme este demonstrarea capabilităților de extindere a unei aplicații relativ mici către un mediu enterprise, cât și observarea utilizării tehnologiilor descrise în partea teoretică.

Aplicația este dezvoltată în mediul Eclipse Kepler, folosind anumite caracteristici puse la dispoziției de acesta: fațade de proiect. Fațadele de proiect definesc trăsături și cerințe ale proiectelor Java EE, fiind folosite ca și parte din configurația de runtime. Cele folosite de acest proiect sunt: Dynamic Web Module 3.0, Java 1.7, JavaServer Faces 2.1 și JPA 2.0. În momentul activării acestora din configurația de proiect, s-au adăugat automat anumite fișiere specifice proiectelor Java EE. Structura rezultată este prezentată în următorul capitol.

Fig.III.1. Primul prototip al interfeței

III.1. Structura proiectului

Aplicația respectă structra standard Maven, combinată cu cea de Java Web. Părțile principale sunt:

Clasele Java. Conțin întreaga logică a aplicației.

Resurse. În cazul acestei aplicații, resursele include doar fișiere de configurație.

Pachetul de test. Test de unitate, de bază de date, de integrare, de server, de model etc.

Aplicația web efectivă. Cuprinde toate elementele specifice web: pagini HTML, fișiere CSS, fișiere JavaScript, imagini statice etc. – pe lângă acestea, aici se include și fișierele de configurație JSF (exemplu: faces-config.xml).

Librării. “Ajutoare” externe, cât și tot pachetul oferit de Java SE.

Metadata și setări. Setările specifice mediului de lucru (specifice Eclipse)

Bytecode. Clasele Java compilate.

Target. Întreaga aplicației asamblată de către Maven

Configurația Maven. Aceasta constă deobicei din fișierul pom.xml.

Figura III.2 prezintă structura vizuală a proiectului, direct din Eclipse. Unele pachete și folder-e sunt ascunse pentru economia de spațiu. În continuare sunt descrise componentele vitale din această ierahie.

Fig.III.2. Structura proiectului în Eclipse

III.1.1. Pachetul src/main/java

Fișierele din vârful ierarhiei (IApplicationConstants, IPresentationConstants etc.) conțin interfețe Java cu constantele statice ale aplicației. Din aceste fișiere se configurează: calea către server, locația bazei de date fizice, ID-ul aplicației de Facebook cu care este contectată, etc. – de asemenea, pot conține și anumite constante de tip String, pentru a se evita re-instanțierea acestora la fiecare utilizare: spații goale, semne de punctuație, caracterul de rând nou etc.

Pachetul backing consită în toate clasele de tip backing bean. Acestea sunt legate direct de paginile compilate de JSF, și au acces în timp real la informații despre sesiunea utilizatorului.

Pachetul ejb conține toate bean-urile care au rolul de a executa operații CRUD (Create/Read/Update/Delete) în mod direct asupra bazei de date. Acest strat este unul dintre cele mai joase din aplicație.

Pachetele exception și helper conțin clase ce au rolul de a ușura dezvoltarea și mentenanța. Aceste tipare au fost concepute cu scopul de a evita cod duplicat prin sistem.

Pachetul servlet conține acele servlet-uri create de dezvoltator. Cu mențiunea faptului că JSF manipulează majoritatea servlet-urilor din sistem, acest lucru nu înseamnă că dezvoltatorul are restricție la a crea propriile servlet-uri.

III.1.2. Pachetul src/main/webapp

Pe nivelul superior a folder-ului se află paginile web de tip XHTML. Formatul acesta este tipic pentru JSF deoarece motoarele de parsare ale framework-ului caută pentru XHTML.

WEB-INF este un simplu folder ce găzduiește fișierele de configurație JSF. Resursele specifice web se află în pachetul resources, urmând apoi tiparul web de folder-e.

III.2. Logica organizațională

În programare, logica organizațională sau logica de domeniu este parte a programului care codifică regulile de afaceri din lumea reală, care determină modul în care pot fi create de date, prezentate, stocate, și schimbate. Acesta se află în contrast cu restul de software care se ocupă cu detalii de nivel inferior: de gestionare a unei baze de date sau afișarea interfaței cu utilizatorul, infrastructura de sistem, sau în general, conectarea diferitelor părți ale programului.

Prima pagină prezintă totalitatea post-urilor din baza de date. Acestea se încarcă în mod lazy pe măsură ce utilizatorul face scroll în jos pe pagină.

Fig.III.3. Cod sursă pentru componenta ce încarcă fiecare post

Figura III.3 prezintă componenta JSF dataScroller ce folosește modelul de date din backing bean-ul postLoader. La fiecare iterație, toate variabilele de UI se încarcă în post, de unde există acces la toate informațiile necesare pentru a afișa postul (exemplu: titlu, calea către GIF etc.).

III.3. Baza de date

Baza de date este altcătuită din trei tabele primare ce descriu utilizatorii, caracteristicile posturilor și mesajele de la fiecare post. Figura III.4 prezintă structura bazei de date din panoul de control PostgreSQL.

Pentru o performanță ridicată a aplicației, metoda de stocare a BLOB-urilor este pe filesystem și nu direct în baza de date. În momentul upload-ului pe website a unui fișier GIF, acesta este serializat și stocat în mod direct într-un folder care se comportă ca o bază de date fizică. Fișierul este denumit corespunzător, iar în baza de date propriu-zisă se stochează calea către acest fișier, timestamp-ul, autorul etc. Introducere acestor date în DB are rolul de a păstra consistența datelor.

Mărimea fișierului de stocare fizic este limitat doar de resursele hardware ale server-ului. Locația acestui fișier (denumit știicumzic-storage) se află în folder-ul de aplicații găzduite de către server, exact lângă aplicația efectivă știicumzic.

Numărul de GIF-uri este de asemeanea limitate doar de tipul de formatare a harddisk-ului gazdă și a sistemului de operare. ȘtiiCumZic este găzduit pe un server rulând Linux, cu formatare EXT4 rezultând într-o limită de 4 miliarde de fișiere într-un folder.

Pentru o căutare eficientă și rapidă a unor posturi în folder-ul de stocare, acesta este împărțit în subfolder-e, fiecare aparținând unui utilizator.

Fig.III.4. Captură a structurii bazei de date din panoul Postgres

Toate fișierele GIF sunt upload-ate prin backing bean-ul FileUploadBacking. Acesta este legat direct de o componentă de file-upload de la PrimeFaces. În momentul în care utilizatorul execută submit la fișier, obiectul este salvat pe harddisk (și de asemenea detaliile acestuia în baza de date) cu un anumit format de nume.

Format: YYMMddHHmmss_tilul-complet-al-fisierului.gif

Prima parte a formatului reprezintă formatarea timestamp-ului de la momentul upload-ului, urmată de un caracter dash și titlul complet al postului. Acesta poate să fie o propoziție întreagă, inclusiv conținând caractere speciale. Caractere ce nu fac parte din setul UTF-8 sunt scoase automat de către un parser.

Exemplu: 140620135521_post-de-test.gif

Putem citi faptul că acest post a fost urcat pe website în data de 2014.06.20 la ora 13:55:21 cu titlul „Post de test”. Depinzând în care subfolder se află, putem determina și utilizatorul care l-a upload-at.

III.4. Componentele de interfață cu utilizatorul

Toate componentele utilizate în aplicație fac parte din setul extensibil de widget-uri de la JSF și de la Primefaces.

Primefaces este un distribuitor de componente UI open-source construite pe baza a JSF. Librăria conține o multitudine de widget-uri minimaliste și performante. Câteva dintre acestea sunt incluse de asemenea în ȘtiiCumZic. Următoarele figuri descriu aceste componente.

Fig.III.5. Componenata GROWL – În momentul emiterii mesajelor globale din codul Java, această componentă afișează un mic panou de informare în colțul din dreapta sus. Este destinat mesajelor scurte informative.

Fig.III.6. Link-ul de la PrimeFaces asociază acțiunea de click cu o metodă dintr-un backing bean. Este mai convenabilă folosirea acestei componente față de un link HTML simplu, datorită asocierii cu codul Java.

Fig.III.7. Cerințele componentelor Primefaces față de fișierul XHTML de care aparțin.

III.5. Login-ul cu Facebook

Design-ul paginilor web este minimalist, aplicația concentrându-se pe funcționalitate și ușurință la utilizare.

Caracteristica principală constă în login-ul cu Facebook. ȘtiiCumZic are propria aplicație pe înregistrată pe Faceook Developers utilizând un ID și o cheie secretă pentru accesul la informațiile utilizatorilor de Facebook.

Sesiunile de logare sunt reținute cu ajutorul cookie-urilor în browser. Fiecare utilizator Facebook este identificat în baza de date știicumzic.ro prin cheia user_social_id ce poate fi extrasă prin API-urile de Facebook.

Librăria folosită pentru social login este de asemenea un proiect open-source numit Social Auth. Cu ajutorul acestor interfețe Java, se pot extrage informații despre un utilizator Facebook, cu acordul lui.

Pașii necesari pentru login sunt descriși în figura III.5. Librăria nu este specifică doar pentru Facebook. Există de asemenea posibilitatea de logare cu Google, LinkedIn ș.a.m.d.

ID-ul aplicației de Facebook și cheia secretă sunt stocate ca și câmpuri statice în codul Java aflat în src/main/java.

Fig.III.5. Procesul de logare cu Facebook

III.6. Testare

Testare este esențială în orice aplicație proporții ridicate. Testele asigură o consistență în stabilitate și o dezvoltare continuă.

ȘtiiCumZic.ro conține atât teste de unitate și de model, cât și teste simple de funcționalitate a interfeței cu utilizatorul. Testele de model și server au rolul de informa dezvoltatorul că în momentul schimbării codului nu s-a schimbat nimic în sensul stabilității sistemului. Aceste informații sunt critice în cadrul sistemelor enterprise. Erorile neobservate ce ajung în stadiul de producție pot cauza chiar și pierderi financiare.

ȘtiiCumZic.ro urmează un proces standard de dezvoltare bazată pe testare. Ciclul de dezvoltare este descris în figura III.6.

Fig.III.6. Procesul de dezvoltare al ȘtiiCumZic.ro

Capitolul IV. Concluzii

Pentru dezvoltarea unei aplicații web enterprise nu există o platformă perfectă, ci există unele mai performante decât altele în funcție de cerințele proiectului.

ȘtiiCumZic folosește stiva de tehnologii Java EE datorită disponibilității resurselor hardware ce includ un server GlassFish 3.1.2.2 puternic, precum și datorită cunoștințelor vaste în domeniul Java a dezvoltatorilor.

Aplicația are un spectru larg de posibilități în sensul expansiunii către enterprise efectiv. Datorită puterii Java EE de scalabilitate, funcționalități noi pot fi adăugate cu ușurință în momentul în care framework-ul de bază este stabil. Un număr de aceste caracteristici noi posibile includ:

Voturi pozitive și negative pe posturi. Fiecare utilizator are posibilitatea de a vota un post în funcție de preferințe. Pe baza acestei caracteristici se pot construi top-urile de posturi.

Top-uri zilnice, săptămânale și lunare. Posturile cu cele mai multe voturi au propria secțiune pe website

Categorii de posturi. Posturile pot fi segregate în mai multe categorii

Login cu alte rețele de socializare. Librăria SocialAuth descrisă în capitolul III.5 suportă logarea cu o varietate de rețele de socializare în afară de renumitul Facebook

Login cu utilizatori noi. Nu fiecare utilizator folosește o anume rețea de socializare. Astfel aplicația de față are posibilitatea de scalare către login cu înregistrare direct pe website. În acest caz baza de date nu se modifică radical, ci doar se extinde funcționalitate. Aceasta este una dintre caracteristicile PostgreSQL, descrise în capitolul II.3

O aplicație de rang înalt este greu de ținut la curent cu cele mai tehnologii și cele mai noi versiuni ale tehnolgiilor deja folosite. ȘtiiCumZic nu folosește ultimele versiuni ale tehnologiilor (datorită setului de cunoștințe a dezvoltatorului) dar folosește versiuni stabile. GlassFish are versiunea 3.1.2.2. în timp ce PostgreSQL este la versiunea 8. Implementarea de Java EE este 6, în a cărei consecință JSF are versiunea 2.1.

În general nu este necesară folosirea ultimelor versiuni de tehnologii, ci potrivirea acestora pentru a întâlni cerințele aplicației. În oricare caz, toate versiunile recente încă au suport din partea comunității, devenind nefolosibile abia dupâ zeci de ani.

Posibilități de migrare a tehnologiilor includ:

Server Wildfly. Este proiectul copil al GlassFish. Deși GlassFish 4 a fost scos în perioada scrierii acestei lucrări, în anii următori va fi înlocuit de Wildfly.

Java 8. Introducând expresiile lambda cât și medii de programare moderne, Java 8 este o versiune mult așteptată, îmbunătățind productivitatea programatorilor.

Java EE 7. Versiunea 7 aduce o mulțime de tehnologii noi, care includ și websockets. Acestea ne permit centralizarea logicii operaționale care a comunica cu diverși clienți (browser, telefon mobil, desktop etc.). Acesta va include JSF 2.2 (care include Primefaces 5) cât și alte implementări aferente care se regăsesc și in EE 6.

Server Amazon S3 pentru stocarea fizică. Pentru a separa locația aplicației cu cea a bazei de date fizicie, se va folosi un server extern construit cu acest scop.

Bibliografie

Majoritatea surselor bibliografice și a resurselor electronice se regăsesc ca note de subsol pe parcursul documentului. În această secțiune sunt listate acele surse ce încapsulează părți mai mari din lucrare.

[1] “Beginning Java EE 6 Platform with GlassFish 3”, Antonio Goncalves, Apress 2009

[2] “Pro JPA 2 – Mastering the Java Persistence API”, Mike Keith și Merrick Schincariol, Apress 2009

[3] “Core Servlets and JavaServer Pages, Second Edition”, Marty Hall și Larry Brown

http://pdf.coreservlets.com/

[4] “JavaServer Faces in Action”, Kito D. Mann, Manning Publications Co. 2005

[5] “Exploring JSF 2.0 and Primefaces”, Cagatay Civici, Prime Technology 2008

[6] “GlassFish Server Open Source Edition”, Quick Start Guide, Mai 2013

https://glassfish.java.net/docs/4.0/quick-start-guide.pdf

[7] “Maven: The complete reference”, versiune online publicată de Sonatype Inc.

http://books.sonatype.com/mvnref-book/pdf/mvnref-pdf.pdf

[8] “PostgreSQL”, Korry Douglas, ediția a 2-a, SAMS Publishing 2005

Bibliografie

Majoritatea surselor bibliografice și a resurselor electronice se regăsesc ca note de subsol pe parcursul documentului. În această secțiune sunt listate acele surse ce încapsulează părți mai mari din lucrare.

[1] “Beginning Java EE 6 Platform with GlassFish 3”, Antonio Goncalves, Apress 2009

[2] “Pro JPA 2 – Mastering the Java Persistence API”, Mike Keith și Merrick Schincariol, Apress 2009

[3] “Core Servlets and JavaServer Pages, Second Edition”, Marty Hall și Larry Brown

http://pdf.coreservlets.com/

[4] “JavaServer Faces in Action”, Kito D. Mann, Manning Publications Co. 2005

[5] “Exploring JSF 2.0 and Primefaces”, Cagatay Civici, Prime Technology 2008

[6] “GlassFish Server Open Source Edition”, Quick Start Guide, Mai 2013

https://glassfish.java.net/docs/4.0/quick-start-guide.pdf

[7] “Maven: The complete reference”, versiune online publicată de Sonatype Inc.

http://books.sonatype.com/mvnref-book/pdf/mvnref-pdf.pdf

[8] “PostgreSQL”, Korry Douglas, ediția a 2-a, SAMS Publishing 2005