Arhitectura J2EE: Sabloane & Componente EJB

J2EE - Java 2 Enterprise Edition – este un set de specificatii arhitecturale provenite de la SUN Microsystems, in conformitate cu care sunt construite:

Pe orice platforma hardware, de la servere RISC cu sistem de operare Unix, pana la servere Intel-based cu sistem de operare Windows.

In esenta toate aplicatiile moderne medii-mari pentru intranet sau internet sunt realizate in una din tehnologiile J2EE sau Microsoft .NET, cu platforma J2EE conducand detasat prin maturitate, scalabilitate si portabilitate, indeosebi in sisteme mari (bancar, operatori comunicatii, militar, e-commerce).

Din punct de vedere al organizarii aplicatiei pe componente, in interiorul celor trei module principale MVC (Model View Controler), diagrama este urmatoarea :

2 Pattern-uri

Componentele din diagrama de mai sus sunt implementate folosind pattern-uri care nu sunt parte din specificatia oficiala J2EE.

2.1 Prezentare pattern-uri utilizate

Prin pattern se intelege o solutie standard la o problema specifica, care si-a dovedit in timp eficienta.

Exista mai multe clasificari si definitii ale pattern-urilor, propuse de catre diverse grupuri de autori, pornind de la nevoi diferite si cu rezultate diferite.

Se remarca de interes J2EE Patterns, promovate de catre Sun, care raspund in principal unor probleme de performanta, scalabilitate in conditiile unor aplicatii tipice de nivel enterprise, in tehnologia J2EE.

Categorie	Sablon
Arhitecturale	Model-View-Control (MVC)
Structurale	Front Controller
	Composite View
	Composite Entity
	Session Façade
	Data Access Object
	Pagination (Value List Handler, Page-by-Page Iterator)
	Generic Filter
	Generic Primary Key
	Fatkey
	Servive Locator
Creationale	Singleton
Creationale	Factory
Comporamentale	Command
	Value Object
	Entity Selective Update
	Fastlane Reader

2.1.1 Arhitecturale

- Model: aceasta componenta este destinata a inmagazina logica aplicatiei si starea sistemului. Este implementata prin Stratul de Persistenta (Entity Beans) si prin FaçadeSession Bean-uri.

- Control: reprezinta clasele ce realizeaza comunicarea intre clasele din Model si cele din View – in aplicatie se implementeaza prin clasele Action.

- View: este o colectie de clase reprezentand interfata cu utilizatorul (toate obiectele pe care utilizatorul le poate vedea pe ecran si cu care poate interactiona, cum ar fi butoane, casete de text, etc.) – este implementata prin totalitatea paginilor JSP, HTML, a stilurilor si a elementelor de design.

2.1.2 Structurale

Este procesorul central al arhitecturii si este responsabil pentru rutarea cererilor HTTP la obiectele corespunzatoare din arhitectura. Controlerul este un servlet si este implementat prin extinderea clasei ActionServlet.

Acest concept arhitectural se bazeaza pe obtinerea unor vederi (pagini jsp) prin compunerea mai multor vederi (pagini jsp). O simpla modificare la o sub-vedere este reflectata la toate paginile compuse ce folosesc aceea sub-vedere. Este implementat prin template.jsp (unul sau mai multe) si prin noua modalitate de a creia o fereastra prin includerea dinamica a componentelor vizuale (jsp) ce alcatuiesc pagina.

Contribuie la agregarea intr-un singur Entity Bean a mai multor obiecte persistente, logica acestei agregari fiind dictata, de regula, de relationari existente intre entitati ale bazei de date.

Acest pattern asigura o interfata unificata pentru un set de interfete dintr-un subsistem.

Session Façade este un strat arhitectural compus exclusiv din Session Bean-uri si care, din punct de vedere functional, administreaza relationarile dintre Business Objects si ofera un grad de abstractizare mai mare la client. Conform cu acest pattern, apelurile la entity-uri se fac numai prin intermediul unor Session Bean-uri pe post de wrappere.

Finder-ele din Entity Bean-uri lucreaza cu un obiect generic care ajuta la crearea interogarii SELECT pentru o cautare. In aplicatie acest obiect generic este o instanta a clasei EntityFilters.java

Identificare unui EJB la nivelul containerului de EJB se face prin intermediul unui obiect, intuitiv denumit primary key si care este implicit de tip string si poate diferi de la un EJB la altul. Acest pattern statueaza ca tipul obiectului primary key este acelasi pentru toate EJB-le. Este implementat prin clasa numita EJBGenericPK.java

Centralizeaza lookup-urile JNDI distribuite de obiecte. Implementeaza un sistem de cache care elimina lookup-urile redundante.

Folosit la fiecare entity bean, datele ce se citesc din tabele sunt impachetate intr-un ValueObject care contine get-ere si set-ere pentru fiecare camp. Toate obiectele de tip ValueObject extind un GenericValueObject unde se pot adauga functionalitati generale suplimentare.

Pentru fiecare camp dintr-un ValueObject exista o masca de biti care semnaleaza daca valoarea campului s-a modificat. La construirea interogarii UPDATE nu se va face updatarea pe campurile a caror valoare nu s-a schimbat.

Pentru afisarea de liste de valori, se evita incarcarea directa a unei liste de Entity Bean-uri. In acest caz, din Session Bean-uri se apeleaza metoda corespunzatoare dintr-o clasa DAO, si se returneaza direct o lista de ValueObject.

Este folosit pentru a face un cache la nivelul finderelor. Cand se executa un finder dintr-un EJB Entity, se incarca pe langa primary key si datele (valorile datelor din linia respectiva), care se seteaza ca un cache in PrimaryKey-ul rezultat. La executia metodei de ejbLoad din entity–ul respectiv se verifica daca cache-ul din primary key este nenul si in caz contrar se executa metoda load din clasa DAO corespunzatoare fapt ce conduce la executia unei interogari la baza de date ce va extrage datele corespunzatoare liniei indicate de primary key–ul respectiv si popularea ValueObject-ului cu date.

Fiecare Entity Bean are asociat o clasa DAO corespunzatoare. In clasele DAO se efectueaza conectarea si executarea interorgarilor la baza de date. Fiecare clasa DAO are metode cum ar fi : load, create, store, remove, findByPrimaryKey si contine continutul interogarilor hardcodat in variabile locale.

2.1.3 Comportamentale

Modelul Struts implementeaza pattern-ul Comand. Pentru asta, fiecare comanda extinde GenericAction care extinde clasa Action din Struts.

2.1.4 Creationale

Este un concept arhitectural prin care se restrictioneaza numarul maxim de instante ale unei clase, pe serverul de aplicatie, la o singura instanta. Acest concept este folosit in lucrul cu clasele manager (ex: SecurityManager.java)

Acest pattern poate fi interpretat si implementat in multe moduri. In principiu, se bazeaza pe mai multe clase ce implementeaza aceeasi interfata si obtinerea de instante ale unor obiecte de tipul claselor mai sus mentionate, fara a cunoaste implementarea acestora.

Folosirea acestor patern-uri este schematic reprezentata in figurile de mai jos:

2.2 Utilizarea modelului Façade pentru ascunderea EJB

Un model de proiectare des utilizat in straturile de prezentare care trebuie sa comunice cu un strat middleware distribuit este modelul Façade (fatada).

Modelul Façade utilizeaza un singur obiect sau un numar mic de obiecte ca interfata cu un set mare de obiecte corelate. Sa presupunem, de exemplu, ca intr-o aplicatie EJB sunt mai multe componente de sesiune cu care trebuie sa comunice cu stratul de prezentare. In loc sa se expuna diferitele componente de sesiune catre stratul de prezentare, poate fi folosit modelul Façade, astfel incat sa se expuna o singura interfata catre stratul de prezentare si sa se faciliteze lucrul cu interfetele de componenta. Obiectul care implementeaza modelul Façade poate fi in stratul de prezentare sau in stratul aplicatie. De exemplu, poate exista o singura componenta de sesiune care sa joace rolul de fatada pentru clientul la distanta. Cand un client invoca o operatie pe o componenta de sesiune, aceasta la randul ei, poate apela alte metode de componenta de sesiune. In acest fel, clientul nu este constient de celelalte componente de sesiune.

Urmatorul exemplu prezinta utilizarea modelului Façade pentru a ascunde fata de stratul de prezentare mai multe obiecte componenta de sesiune.

Desi modelul Façade din acest exemplu se gaseste in stratul Web, fatada este realizata pentru stratul de prezentare. Obiectul care asigura modelul Façade ar putea fi totusi nevoit sa utilizeze mai multe componente de sesiune, dar restul stratului de prezentare nu va sti nimic despre acest lucru.

2.3 Framework-ul Struts

Arhitectura Struts are ca principal deziderat implementarea modelului MVC-2 pe platforma J2EE. Pentru aceasta, Struts foloseste, in mod implicit, un singur controller.

Controllerul din Struts este materializat de instanta unui servlet (ActionServlet), care capteaza toate cererile clientilor, citeste din fisierul de configurare struts-config.xml ce actiune este mapata la cererea respectiva si, pe baza acestei mapari, transfera cererea HTTP, de regula, la o clasa Action ce va executa logica aplicatiei (o exceptie ar fi atunci cand cererea HTTP este transferata unei componente JSP pentru afisarea in browser).

1. Un request din browser este trimis si este interceptat de clasa ActionServlet, care are o singura instanta la nivel de server.

2. Action Servlet apeleaza Request Processor pentru a prepara obiectele request si response, pentru a determina ce actiune este mapata pe acest request, etc.

3. Request Processor creiaza (sau refoloseste) bean-ul Action Form corespondent, il populeaza cu valorile controalelor html si invoca validarea formei (daca este necesar).

4. Folosind actiunea mapata, Request Processor paseaza controlul la clasa Action corespunzatoare. Framework-ul Struts realizeaza un pool pentru instantele claselor Action, oricum, daca actiunea a fost deja ceruta ea va fi extrasa din pool si nu va fi creata la fiecare solicitare. Aceasta poate conduce la cresterea semnificativa a coliziunilor cand mai multi utilizatori acceseaza aceiasi actiune.

5. Clasa Action invoca beans-uri din stratul de business logic si acestea paseaza un obiect de tip Action Form la Model.

6. Dupa ce actiunea se executa in intregime, se returneaza un obiect de tip Action Forward care determina tinta request-ului.

7. Controlul este in cele din urma returnat la Request Processor care redirecteaza request-ul spre target-ul corespunzator.

1 Introducere