Proiectarea Sistemelor Software Complexe

Curs 6 Servere de Aplica ii

Serverele de aplicaii sunt servere bazate pe componente care se gsesc de obicei n mijlocul unei arhitecturi format din N niveluri (N-tier architecture) i ofer servicii precum comunicare, securitate, tranzacii i persisten. n Fig. 6.1 este prezentat arhitectura unei aplicaii Web dezvoltat pe N niveluri. Acest tip de arhitectur este unul destul de frecvent ntlnit la aplicaiile Web.

Browsere

Nivelul Client http

Server Web

Nivelul Web RMI .NET Remoting

Componente EJB, .Net

Nivelul Componentelor Business JDBC ADO.NET

Baz de Date

Nivelul Enterprise Information System

Fig. 6.1. Aplicaie Web pe N niveluri.

n continuare sunt explicate cele 4 niveluri care apar n Fig. 6.1: Nivelul Client ntr-o aplicaie Web nivelul client este reprezentat de un browser Internet care trimite cereri HTTP ctre serverul Web i descarc pagini HTML. Nivelul Web acest nivel ruleaz pe un server Web, scopul lui fiind acela de a atepta i a rspunde la cereri venite din partea clienilor. Atunci cnd apare o cerere serverul Web invoc anumite componente gzduite de server pentru a rspunde la cerere; aceste componente difer n funcie de tipul de server, de exemplu: pentru un server Web Java se poate vorbi de servlets i Java Server Pages (JSP), iar pentru un server .NET componentele sunt denumite Active Server Pages (ASP). Identificarea componentei care trebuie invocat se face pe baza informaiei coninut n cerere. Componenta identificat va procesa parametrii cererii i i va folosi pentru a apela nivelul business logic pentru a obine informaiile necesare pentru a rezolva cererea. n final componenta va formata rezultatele n format HTML pentru a trimite rspunsul la client prin intermediul serverului Web. Nivelul Componentelor Business acest nivel conine partea de business logic a aplicaiei. Componentele business sunt reprezentate fie de componente Enterprise JavaBeans (EJB) pentru J2EE, componente .NET sau obiecte CORBA. Componentele business primesc cereri de la nivelul

Web, rezolv cererile interognd una sau mai multe baze de date i trimit rspunsul ctre nivelul web. Aceste componente ruleaz ntr-un container care ofer o serie de servicii. Tipul de servicii oferite de container componentelor pe care le gzduiete depinde de tipul acestuia (EJB, .NET, CORBA), dar include: suport pentru tranzacii, managementul ciclului de via al componentelor, managementul strii, securitate, suport pentru multithreading i resource pooling. Componentele specific prin fiiere de configurare comportamentul pe care l doresc, iar containerul trebuie s garanteze ndeplinirea acestor cerine. Acest mod de a specifica comportamentul unei componente prin fiiere de configurare este foarte avantajos ntruct programatorul nu trebuie s adauge cod care s trateze aspecte care sunt specifice mediului n care componenta va fi rulat. Nivelul Enterprise Information System este reprezentat de una sau mai multe baze de date sau aplicaii back-end pe care nivelul business trebuie s le interogheze pentru a rezolva cererile primite de la clieni.

Nucleul unui server de aplicaii este reprezentat de containerul care gzduiete componentele business. n continuare va fi analizat ca i studiu de caz modelul EJB suportat de J2EE. 6.1 Enterprise JavaBeans Enterprise JavaBeans reprezint un model de programare standard pentru dezvoltarea de aplicaii server utiliznd limbajul de programare Java. Un server de aplicaii compatibil J2EE trebuie s conin un container EJB care s gestioneze execuia componentelor aplicaiei. Fig. 6.2 red relaiile dintre serverul de aplicaii container i serviciile oferite. Cnd un client EJB invoc o component de pe server, containerul aloc automat un fir de execuie i invoc o instan a componentei EJB. Containerul gestioneaz toate resursele folosite de component i mediaz interaciunile dintre component i mediul exterior.
Server de Aplicaii Container EJB Serviciu Tranzacii

EJB Pool

Serviciu Director

Serviciu Securitate

Fig. 6.2. Serverul de aplicaii J2EE, containerul EJB i serviciile asociate.

6.2 Modelul unei Componente EJB Modelul unei componente EJB definete arhitectura unei componente EJB. Specific interfaa componentei precum i modul n care ea interacioneaz cu containerul i cu alte componente. Specificaiile pentru EJB versiunea 1.1 definesc dou tipuri principale de componente EJB: session beans i entity beans. Componentele de tipul session beans pot fi folosite pentru a executa partea de business logic a unei aplicaii i de a oferi servicii care pot fi apelate de clieni. ntr-o arhitectur de tipul modelview-controller un session bean corespunde nivelului controller (ncapsuleaz partea de business logic a unei aplicaii pe trei niveluri). Un entity bean pe de alt parte este folosit pentru a reprezenta o structur de date. Membrii unui entity bean corespund cmpurilor stocate ntr-o baza de date. Un entity bean este folosit (accesat) de ctre un session bean pentru a implementa un anumit serviciu. De asemenea exist dou tipuri de session beans i anume: session bean fr stare i session bean cu stare. n Fig. 6.3 este ilustrat diferena dintre cele dou tipuri de session beans. Un bean fr stare se caracterizeaz prin faptul c nu stocheaz nici o informaie despre un client ntre dou apeluri succesive. Un client obine o referin ctre o astfel de component dup care poate s fac mai multe apeluri ctre diferite operaii ale componentei. Totui, de la un apel la altul se poate ca, containerul EJB s delege o alt component pentru a deservi apelul. Alocarea componentelor beans fr stare se realizeaz n funcie de necesiti, de aceea un client nu poate fi sigur cu ce component comunic. Acest lucru face inutil stocarea unei stri. Un session bean cu stare se caracterizeaz prin faptul c poate stoca informaii despre comunicarea cu un clientul. Odat ce un client a obinut o referin ctre o referin toate apelurile realizate de client vor fi direcionate ctre aceeai component. Containerul va crea cte o component bean pentru fiecare client. Clientul poate stoca orice fel de informaie n starea componentei pe care o va putea regsi la urmtorul apel. Ciclul de via al unei componente cu stare este gestionat de containerul EJB. Containerul va salva starea componentei pe disc dac acesta nu a fost folosit pentru o anumit perioad de timp i o va rencrca automat atunci cnd apare un nou apel din partea clientului. De asemenea un container mai poate fi configurat s tearg o component cu stare dac acesta nu a fost folosit pentru o anumit perioad de timp.
container EJB beans fr stare stare

stare

stare stare beans cu stare stare stare Clieni EJB

Fig. 6.3. Componente session beans cu stare i fr stare.

Componentele entity bean sunt i ele de dou tipuri: Container Managed Persistence (CMP) entity bean i Bean Managed Persistence (BMP) entity bean. n acest context prin persisten se nelege modul n care datele (de cele mai multe ori reprezint un rnd ntr-o baz de date relaionat) asociate cu un entity bean sunt citite respectiv scrise. n cazul componentelor CMP responsabilitatea de a ncrca datele n bean, respective de a scrie modificrile la momentele potrivite (sfritul unei tranzacii) napoi n baza de date revin containerului. Componentele CMP se bazeaz pe servicii oferite de container i nu necesit cod suplimentar ntruct containerul se ocup de tot. Componentele CMP sunt uor de implementat i de ntreinut pentru baze de date relaionate. n cazul componentelor de tipul BMP, sarcina de a accesa i salva data reprezentat de component revine chiar codului componentei. Acest lucru se poate realiza utiliznd apeluri JDBC sau apeluri ctre o baza de date dedicat sau apeluri API. Componentele BMP ofer programatorilor flexibilitatea de a implementa metode de persisten care sunt prea complicat de generat de ctre container sau care folosesc baze de date care nu sunt suportate de container (ex.: o baz de date dezvoltat peste FTP). Dei componentele BMP necesit un efort de programare mai mare ele se pot dovedi utile mai ales atunci cnd este nevoie de performane ridicate. 6.3 Programarea EJB O component EJB depinde n totalitate de containerul EJB pentru tot ce face. Dac o component EJB trebuie s foloseasc o conexiune JDBC sau o alt component EJB, ea va apela la serviciile puse la dispoziie de containerul EJB pentru a face acest lucru. Pentru a crea o component EJB trebuie implementate dou interfee: una definete partea de business a componentei, iar cealalt reprezint metodele care gestioneaz ciclul de via al componentei. Cele dou interfee sunt interfeele remote i home. Interfaa home conine metodele care definesc ciclul de viaa al unei componente EJB. Acest metode ofer clienilor servicii precum crearea, tergerea i gsirea de instane de componente. Pe de alt parte interfaa remote conine metode care reprezint partea de business a componentei. Aceste metode sunt specifice sistemului software. Pentru a putea invoca metode din interfaa remote un client trebuie mai nti s obin o referin la o component EJB utiliznd metode din interfaa home. Un client EJB poate fi o aplicaie Java de sine stttoare, un servlet, un applet sau chiar o alt component EJB. Toi clieni vor folosi interfaa home a componentei pentru a obine referine la component. Referina obinut n acest mod va fi asociat cu o instan a unei clase ce implementeaz interfaa remote a componentei. Astfel, clientul va interaciona cu componenta EJB prin intermediul metodelor din interfaa remote. 6.4 Deployment Descriptors Unul din principalele avantaje ale componentelor EJB este reprezentat de modul n care o astfel de component separ responsabilitile, i anume, ea separ partea de business logic de partea de infrastructur. Astfel o component EJB conine doar cod specific prii de business a unui sistem software. Rezolvarea problemelor specifice platformei i infrastructurii (ex.: tranzacii, ciclul de via al componentei sau securitatea) este n totalitate sarcina containerului EJB. Aceast separare a responsabilitilor duce la crearea unor componente relative simple fr a mai fi nevoie s se gestioneze complexitatea suplimentar introdus de gestionarea infrastructurii.

O component EJB informeaz containerul ce servicii are nevoie prin intermediul aa numitului deployment descriptor. Un deployment descriptor este un document XML asociat cu o component EJB. Atunci cnd o component EJB este instalat ntr-un container, acesta din urm va citi documentul XML asociat pentru a determina modul n care vor fi gestionate operaii precum tranzacii, persisten etc. Aadar un descriptor reprezint un mecanism declarativ prin care se descrie modul n care vor fi gestionate problemele legate de infrastructur. Avantajul acestui mecanism const n faptul c aceeai component EJB poate fi instalat utiliznd diferii descriptori fiecare fiind specific unui anumit tip de aplicaie. De exemplu, dac este nevoie de securitate se poate specifica modul n care componenta poate fi accesat, dac nu este nevoie de securitate atunci se specific acest lucru n descriptor. Avantajul este acela c n ambele situaii din punctul de vedere al ingineriei software componenta va fi aceeai. 6.5 Responsabilitile Containerului EJB Containerul EJB este o unitate software foarte complex. Serviciile pe care el trebuie s le ofere sunt: Gestionarea ciclului de via i a instanelor componentelor EJB, i anume: crearea, activarea, dezactivarea i tergerea. Intercepteaz apelurile clienilor ctre metode ale componentelor EJB pentru a garanta tranzaciile i securitatea. De asemenea asigur apeluri napoi la nceputul i sfritul unei tranzacii. Gestioneaz persistena cmpurilor unei componente CMP.

Un container EJB ofer i o serie de alte faciliti vitale: - Threading o component EJB nu trebuie s creeze i s manipuleze explicit un fir de execuie Java, ci trebuie s se bazeze pe container pentru a aloca un fir de execuie unei componente bean active pentru a mri gradul de concuren i performanele. Acest lucru simplific sarcina programatorului care nu mai trebuie s se preocupe de tratarea cererilor concurente. - Caching containerul EJB poate s gestioneze un cache de instane entity bean; dimensiunea cache-ului se poate specifica n descriptor. - Connection Pooling containerul poate s gestioneze un set de conexiuni la baza de date ceea ce duce la o cretere a eficienei accesului la resurse externe.

Bibliografie
[1] Ian Gorton. Essential Software Architecture. Editura Springer. 2006. [2] http://java.sun.com/javaee/5/docs/tutorial/doc/