Curs 1

 Platforma Java Enterprise Editition (Java EE)

◦ Standard în domeniul platformelor enterprise
◦ Platformă pentru programarea la nivel de server
◦ Robusteţe
◦ Servicii
◦ Promovează modularitatea
◦ Uşurinţă în dezvoltare
◦ Set clar de specificaţii pentru implementatori
 API-uri
◦ JDBC, RMI, JavaMail, JMS, XML
◦ Web services etc

 API-uri unice Java EE

◦ Enterprise Java Beans (EJB)
◦ Java Transaction API (JTA)
◦ Java Message Service (JMS)
◦ Java EE Connector Architecture (JCA)
◦ Java Persistence API
◦ Interceptors
◦ Servlets
◦ Portlets (rulează în portaluri web)
◦ Java Server Pages (JSP)
◦ Java Server Faces (JSF)
◦ Web services
◦ etc
 Portabilitate
 Scalabilitate
 Integrare cu sisteme legacy
 Management automat:
◦ Resurse
◦ Tranzacţii
◦ Securitate
◦ Concurenţă
◦ Componente
◦ Servicii
 Sun GlassFish
 OW2 JOnAS Application Server
 JBoss Application Server
 Apache Geronimo
 IBM WebSphere
 Oracle WebLogic Application Server
 SAP NetWeaver Application Server
 etc
 Platforma JEE (Java Enteprise Edition) defineşte standardul pentru
dezvoltarea aplicaţiilor multi-tier, simplificând dezvoltarea
acestora prin introducerea componentelor standardizate. Se
oferă un set variat de servicii middleware cum ar fi: management
automat al tranzacţiilor, persistenţă automată, clustering,
securitate etc.
 Cel mai important aspect oferit de platforma JEE este acela al
unui nou model de aplicaţie.
 Specificaţiile JEE definesc o arhitectură multi-tier, componentele
corespunzătoare fiecărui nivel fiind:
◦ layer prezentare (Client tire): browser web, aplicaţie java, dispozitiv
electronic ce dispune de o maşină virtuală/hardware Java
◦ layer business logic (Web tire + Business tire): server J2EE, de obicei
alcătuit din 2 containere: un container pentru aplicaţii EJB şi un container
pentru aplicaţii web (pagini JSP, servlet-uri)
◦ layer date (EIS tire): sistem local de fişiere, SGBD, aplicaţii legacy etc.
 Managementul tranzacţiilor: tranzacţiile sunt controlate automat de
către serverul de aplicaţii, programatorul fiind responsabil doar cu
configurarea caracteristicilor principale ale acestora.
 Resource pooling: acest mecanism este conţinut în cadrul platformei,
fiind automat disponibil oricărei aplicaţii. Programatorul nu mai este
nevoit să scrie cod special de optimizare a aplicaţiilor cu implementări
de pool-uri de obiecte (conexiuni la baze de date, conexiuni cu alte
resurse etc).
 Scalabilitate: abilitatea unei aplicaţii de a-şi menţine performanţele
oferite odată cu creşterea proporţională a numărului de cereri faţă de
numărul de resurse puse la dispoziţie. Se asigură dezvoltarea şi
integrarea de noi module fără a perturba funcţionarea aplicaţiei iniţiale.
 Securitate: mecanisme de autentificare si API-uri standardizate.
 Load balancing: asigurarea echilibrării încărcării serverelor de aplicaţii ce
deservesc cereri prin redirecţionarea automată a acestora spre serverele
cel mai puţin încărcate.
 Fault tolerance: toleranţă la defecte – se realizează automat în cazul
serviciilor idempotente
 Programatorul se poate concentra aproape în totalitate asupra părţilor
esenţiale ale unei aplicaţii: logică, algoritmi, interfeţe, flux şi model de
date etc.
 O arhitectură enterprise pune la dispoziţia dezvoltatorilor de aplicaţii
distribuite o infrastructură pentru găzduirea aplicaţiilor (containere) cât
şi un set de API-uri bine definite pentru dezvoltarea acestora.

 Specificaţiile JEE nu impun o modalitate de implementare a containerelor

şi nici a setului de API-uri, ci doar specifică rolurile şi interfeţele
acestora, detaliile de implementare rămânând la latitudinea vendorilor.

 Prin urmare, specificaţiile definesc părţile componente ale platformei JEE

pe baza cărora vendorii dezvoltă produse conforme acestora sub forma
unor servere de aplicaţii compatibile JEE. Firma Sun Microsystems,
autoarea acestor specificaţii, oferă o implementare de referinţă sub
numele JEE RI (Reference Implementation), aceasta fiind disponibilă
pentru download pe site-ul Sun.
 Nivelul de business logic este în general alcătuit din două
containere:
◦ container pentru aplicaţii web – oferă suport pentru managementul şi
rularea servlet-urilor şi a JSP-urilor
◦ container pentru componente EJB – oferă suport pentru managementul şi
rularea componentelor EJB

 Tehnologiile JEE pot fi clasificate după cum urmează:

◦ tehnologia orientată pe componente: apare la nivelul business logic, fiind
axată pe trei tipuri de componente principale: pagini JSP, servlet-uri şi
componente EJB.
◦ tehnologia orientată pe servicii: asigură suportul necesar pentru prima
tehnologie, fiind compusă dintr-o serie de API-uri cum ar fi: JDBC, JTA,
JMS, JNDI etc.
◦ tehnologia de comunicaţii: oferă standarde de comunicaţie între modulele
aplicaţiilor enterprise, fiind axată pe o serie de protocoale clasice TCP/IP
(exemplu: HTTP, HTTPS, SSL etc.), protocoale pentru apelul obiectelor la
distanţă (exemplu: RMI over IIOP), şi alte protocoale cum ar fi protocoalele
pentru JMS sau JavaMail.
 Logica unei aplicaţii enterprise este implementată la
nivelul componentelor EJB, tot codul de business logic
fiind regăsit în cadrul acestora sau în cadrul altor
componente separate folosite de către componentele
EJB (exemplu: cod pentru interogarea bazelor de date,
cod pentru gestiunea coşurilor de cumpărături, cod
pentru actualizarea datelor etc).

 Componentele EJB sunt implementate sub forma unor

grupuri de clase şi interfeţe java care implementează
şi/sau extind clase şi interfeţe oferite de platforma
JEE, cu scopul de a oferi posibilitatea containerului să
automatizeze o serie de operaţii cum ar fi:
managementul tranzacţiilor, managementul pool-
urilor de resurse, controlul componentelor EJB etc.
 Componentele EJB sunt de două tipuri:
◦ Session beans: încapsulează comportamentul unei aplicaţii enterprise şi
implementează serviciile oferite de aceasta, modelând astfel business logic-ul.
◦ Message driven beans: asigură suportul necesar pentru tehnologia JMS (Java
Messaging Service), aceste bean-uri fiind automat apelate de către containerul EJB în
momentul recepţionării de mesaje JMS. Prin urmare, message driven bean-urile sunt
responsabile cu procesarea mesajelor primite, implementând astfel o parte din
business logic-ul aplicaţiei enterprise.

 Componentele care reprezintă datele din EIS se numesc entităţi

persistente (Java Persistence Entities). Acestea definesc obiectele
persistente ale unei aplicaţii enterprise, modelând datele prezente în
cadrul celui de-al treilea layer din cadrul arhitecturii JEE, layerul de date.

 Modelarea business logic-ului presupune efectuarea unor operaţii

asupra entităţilor persistente, în general de către componentele de tip
session bean. Managementul persistenţei stării componentelor de tip
entitate poate fi făcut explicit de către programator sau lăsat în seama
serverului de aplicaţii.
 Arhitectură de conectare a serverelor de aplicaţii enterprise cu sisteme
de informaţii enterprise (EIS – enterprise information systems)
 Set de specificaţii standard care descriu interacţiunea la nivel de sistem
dintre serverele de aplicaţii enterprise şi adaptoarele de resurse
◦ Managementul conexiunilor, pool de conexiuni
◦ Managementul tranzacţiilor (incusiv dacă există mai mulţi manageri de resurse
diferiţi)
◦ Managementul securităţii
◦ Managementul adaptorilor de resurse (controlul asupra life-cycle)
◦ Suport şi management pentru taskuri iniţiate de însăşi adaptoarele de resurse
(monitorizarea reţelei, prelucre a datelor etc). Furnizează posibilitatea de a folosi
logica de management şi pool-urile de resursele ale serverelor de aplicaţii
◦ Transmitere asincronă de mesaje către serverul de aplicaţii
 JDBC – folosit în mod special pentru conectarea aplicaţiilor JEE la baze de
date
 JCA – arhitectură mult mai generică pentru conectarea la sisteme de date
(inclusiv legacy)
 Application server vendor (suport pentru JCA) + EIS vendor (resource
adapter)
 For enterprise application integration, bidirectional connectivity between enterprise
applications and an Enterprise Information System (EIS) is essential. The Java EE Connector
Architecture defines a standard set of contracts that allow bidirectional connectivity between
enterprise applications and EIS providers. It also formalizes the relationships, interactions, and
the packaging of the integration layer, thus enabling unfettered enterprise application
integration. If an application server vendor extends its system once to support the connector
architecture, the application server vendor is assured of being able to seamlessly connect to
multiple off-the-shelf EIS offerings. Likewise, if an EIS vendor provides an industry standard
resource adapter, such as is described within JSR 322, the EIS vendor is assured of being able
to plug into any application server that supports the connector architecture.
 The Connector 1.6 specification (JSR 322) enhances the Connector Architecture through the
following means:
◦ Ease of development: Dramatically simplifies the development of resource adapters through extensive use of
Java language annotations, reducing the need to write redundant code and the need for a deployment
descriptor (ra.xml), provides better configuration defaults, and so on.
◦ Generic Work Context mechanism: Defines a generic mechanism for propagating contextual information
during Work execution. The specification standardizes passing in security, transactional and other quality-
of-service parameters from an EIS to a Java EE component during Work execution.
◦ Security Work Context: Defines a standard contract that a resource adapter could employ to establish
security information (established identity) while submitting a Work instance for execution to a WorkManager,
and while delivering messages to message endpoints (MDBs) residing in the application server.

(sursa: https://www.sun.com/offers/docs/java_EE6_overview_paper.pdf)
 Persistence is the technique through which object models broker the
access and manipulation of information from a relational database.
 JPA handles the details of how relational data is mapped to Java objects,
and it standardizes Object/Relational mapping.
 JPA was introduced in Java EE 5, and provided a POJO-based persistence
model for Java EE and Java SE applications.
 JPA has been enhanced in Java EE 6. The Java Persistence API (JPA)
version 2.0 specification facilitates more effective and reliable (that is,
more strongly typed) methodology for building object-centric criteria-
based dynamic database queries.
◦ Object/Relational mapping enhancements. For example, JPA 2.0 adds the ability to
map collections of basic data types, such as Strings or Integers, as well as collections
of embeddable objects. There are new annotations that support collection mappings.
◦ Java Persistence Query Language (JPQL) enhancements. These include new operators
such as NULLIF, VALUE, and others, and case expressions can be used in queries.
◦ Criteria API. A type safe query mechanism, based on the metamodel concept, which
can verify persistent Java objects. It can be statically or dynamically accessed. A
string-based model is also available, but not as type safe.

(sursa: https://www.sun.com/offers/docs/java_EE6_overview_paper.pdf)
 Dependency Injection poate fi aplicat tuturor resurselor de care are
nevoie o componentă
 Aplicaţia nu mai include cod pentru căutarea şi crearea resurselor
 Serverul de aplicaţii injecteză automat resursele folosind adnotările din
cod
 Bean-urile pot fi ataşate unor scopuri (request, sesiune etc); serverul de
aplicaţii va face managementul automat atât al life-cycle-lui bean-urilor
cât şi al resurselor necesare acestora (creare, injectare, distrugere)
 Bean-urile au abilitatea de a genera şi observa evenimente, rezultând o
interacţiune loosely-coupled
 Arhitectura permite suportul tranzacţional pentru secţiunea web a unei
aplicaţii enterprise
 Desi popular, patternul Dependecy Injection nu a avut parte de o
abordare standard până recent. Dependency Injection for Java (JSR 330)
introduce un set standard de adnotări care pot fi folosite pentru
Dependecy Injection.
 Paşii necesari pentru dezvoltarea şi lansarea în
producţie a aplicaţiilor JEE sunt:
◦ dezvoltarea componentelor (EJB-uri, pagini JSP, servlet-
uri, pagini HTML etc.)
◦ asamblarea componentelor în module
◦ asamblarea modulelor în aplicaţii
◦ deployment-ul aplicaţiilor (instalarea acestora în cadrul
serverelor de aplicaţii compatibile cu specificaţiile JEE)
 Modulele JEE sunt părţi componente ale
aplicaţiilor enterprise special proiectate pentru a
rula în cadrul containerelor puse la dispoziţie de
serverele de aplicaţii JEE.
 modul web – conţine servlet-uri, pagini JSP, librării de tag-uri JSP, fişiere
jar, documente html, documente multimedia asamblate în pagini html,
applet-uri, clase Java şi alte resurse.
◦ componentele se asamblează respectând o structură descrisă de specificaţiile JEE la
care se adaugă un fişier XML de configurare (web deployment descriptor file) având
numele web.xml.
◦ modulul poate fi opţional comprimat într-un fişier cu extensia standard .war (web
archive).
◦ modulul va rula în cadrul containerul web pus la dispoziţie de serverele de aplicaţii
JEE.

 modul EJB – conţine un set de fişiere java compilate alături de alte

resurse necesare aplicaţiei enterprise.
◦ componentele se asamblează, ca şi în cadrul modulului web, respectând o structură
descrisă în cadrul specificaţiilor JEE la care se adaugă un fişier XML de configurare
(ejb deployment descriptor file) având numele ejb-jar.xml. Modulul EJB va rula în
containerul EJB pus la dispoziţie de serverele de aplicaţii JEE.

În toate cazurile descrise mai sus, rolul fişierului XML este acela de a specifica, în funcţie
de nivelul la care se află, comportamentul componentelor în cadrul modulelor, respectiv
al modulelor în cadrul aplicaţiei enterprise.
 Ultima fază cuprinsă de specificaţiile JEE este faza de
deployment, adică de instalare a aplicaţiei enterprise
în cadrul serverelor de aplicaţii JEE, fiecare server de
aplicaţii punând la dispoziţie instrumente specifice de
deployment.

 Specificaţiile JEE descriu un contract bine definit pe

care serverele de aplicaţii compatibile JEE trebuie să îl
respecte. Un aspect important este acela că
specificaţiile JEE nu interzic extinderea şi oferirea de
noi facilităţi, o aplicaţie enterprise putând astfel fi
compatibilă JEE şi în acelaşi timp să prezinte
particularităţi specifice numai în cadrul unui anumit
server de aplicaţii.
 Specificaţia EJB descrie un model de componente pe partea
de server, definind rolurile care apar în procesul de
dezvoltare (development) şi instalare (deployment),
precum şi componentele sistemului.

 Specificaţia defineşte un număr de roluri care apar în

dezvoltarea, instalarea şi rularea unui sistem enterprise
distribuit. Vendori, administratori şi programatori joacă
roluri variate care permit partiţionarea cunoştinţelor
tehnice pe domenii. Spre exemplu, vendorii oferă un cadru
de lucru, în timp ce programatorii dezvoltă componente
specifice (exemplu: componente pentru contabilitate etc).

 O aceeaşi entitate poate avea unul sau mai multe roluri.

 Furnizorul de Enterprise Bean-uri (Enterprise Bean Provider) –
dezvoltator de componente EJB reutilizabile, împachetate în fişiere ejb-
jar conforme cu structura definită de specificaţii.
 Asamblorul de aplicaţii (Application Assembler) – asamblează aplicaţii
enterprise pe baza unei colecţii de fişiere ejb-jar. Acest rol include
dezvoltarea de noi componente care utilizează colecţia pusă la
dispoziţie.
 Instalatorul (Deployer) – preia colecţia de fişiere ejb-jar de la Asamblorul
de aplicaţii şi/sau Furnizorul de Enterprise Bean-uri şi le instalează într-
un mediu de execuţie definit în termenii containerelor EJB (puse la
dispoziţie de serverele de aplicaţii JEE).
 Furnizorul de Containere/Servere de aplicaţii enterprise
(Container/Application Server Vendor) – oferă medii de execuţie şi
instrumente specifice care sunt utilizate pentru instalarea, administrarea
şi rularea componentelor enterprise.
 Administratorul de sistem (System Administrator) – gestionează
componentele şi serviciile oferite, fiind responsabil cu configurarea şi
asigurarea unei interacţiuni corecte între acestea. Acest rol include
managementul, activarea şi rularea întregului sistem enterprise.
 Componentele EJB sunt elemente de business logic reutilizabile, care
aderă la standarde şi modele de proiectare bine definite în cadrul
specificaţiei EJB, asigurându-se astfel portabilitatea acestora.
 Arhitectura descrisă de specificaţii permite ca alte servicii precum
securitate, evacuări pe niveluri secundare de memorie, tranzacţii
distribuite etc. să fie utilizate în folosul componentelor EJB.

 Containerul EJB este un mediu de execuţie care conţine şi rulează

componente EJB, oferind un set de servicii standard pentru acestea.
Pentru a permite independenţa de vendor, responsabilităţile
containerului EJB sunt strict definite în cadrul specificaţiilor.
 Containerul EJB oferă partea de infrastructură pentru EJB-uri, incluzând
tranzacţii distribuite, securitate, gestiunea ciclului de viaţă a
componentelor, mecanisme de caching, gestiunea firelor de execuţie,
gestiunea sesiunilor etc.
 Un server EJB este definit ca un server de aplicaţii JEE care conţine şi
rulează unul sau mai multe containere EJB. Se poate în general
presupune că atât containerul EJB cât şi serverul EJB reprezintă una şi
aceeaşi entitate.
 Serverul de aplicaţii Java EE: Componentă de runtime a unei
aplicaţii enterprise. Furnizează containere EJB şi containere web.
 Container Enterprise JavaBeans (EJB): Realizează managementul
bean-urilor enterprise din cadrul aplicaţiilor JEE. Bean-urile
enterprise cu containerul aferent rulează în cadrul serverului de
aplicaţii JEE.
 Containerul web: Realizează managementul execuţiei paginilor
web, a servleturilor şi a unor componente EJB. Componentele
web cu containerul aferent rulează în cadrul serverului de
aplicaţii JEE.
 Containerul de aplicaţie client: Realizează managementul
execuţiei componentelor de la nivelul clientului. Componentele
client cu containerul aferent rulează pe calculatorul clientului.
 Containerul pentru appleturi: Realizează managementul
execuţiei appleturilor. Este compus din browserul web şi Java
Plug-in, care împreună rulează pe calculatorul clientului.
 After 10 years of running business critical applications for
thousands of organizations, the Java Enterprise Edition
technology platform continues to make tremendous progress as
an enterprise application development and deployment platform.
 Java EE 6 delivers a comprehensive set of APIs that can simplify
the developer experience while improving productivity.
 Annotation-based programming and zero-configuration Web
frameworks that leverage open-source innovation further
simplify the developer environment while extending the
platform.
 Profiles create new, focused architectures of standards-based EJB
components, while pruning clears out unused technologies.
 There are several technical enhancements, including Servlet 3.0,
Facelets, RESTful Web services, Connectors, an enhanced
persistence architecture, dependency injection, and much more.
 Developing enterprise applications with Java technology has
never been easier.

(sursa: https://www.sun.com/offers/docs/java_EE6_overview_paper.pdf)
Curs 2
 concepte principale care se regăsesc la
fundaţia unui cluster enterprise
 modalităţi de definire şi construire a
clusterelor
 modalităţi de comunicare a nodurilor în
cadrul unui cluster
 cluster: set de noduri care au în general un
scop comun
 nod: calculator sau o instanţă de server, în
cazul din urmă mai multe instanţe de server
putând rula în cadrul aceluiaşi calculator
 obţinerea toleranţei la defecte (fault
tolerance)
 echilibrarea încărcării serverelor prin replicare
(load balancing through replication)
 proporţia de timp în care acest serviciu este
accesibil cu un timp de răspuns rezonabil /
predictibil.
 Termenul de ”Mare disponibilitate” (high
availability - HA) este în general folosit pentru a
indica o proporţie mare de timp.
 HA este dependent de context: HA-ul pentru un
sistem critic dintr-o navetă spaţială este probabil
mult mai mare decât HA-ul pentru un site web.
 HA specifică maximul de timp dintr-o anumită
perioadă, pentru care un serviciu poate să nu fie
disponibil.
Proporţia HA Timpul maxim cumulat admis de indisponibilitate în decursul unui an

98 % 7.3 zile

99 % 87.6 ore

99.5 % 43.8 ore

99.9 % 8.76 ore

99.95 % 4.38 ore

99.99 % 53 minute

99.999 % 5.25 minute

99.9999 % 31 secunde

99.99999 % 3.1 secunde

 deşi proporţia HA este strict legată de timpul
maxim admis cumulat de indisponibilitate în
decursul unei anumite perioade, costul, în
general, nu este: trecerea de la 99% la 99.99%
este mult mai costisitoare decât trecerea de la
98% la 99%, chiar dacă diferenţa procentuală
este mai mică.
 implică HA-ul
 datele cu o mare disponibilitate nu sunt în mod
necesar şi date corecte
 serviciile tolerante la defecte garantează
întotdeauna comportamente corecte şi
consistente, chiar şi în cazul apariţiei unor
defecte

Unele sisteme necesită doar HA (ex: directory

services ce conţin date statice), în timp ce altele
necesită toleranţă la defecte (ex: sisteme bancare
care necesită operaţiuni tranzacţionale).
 reprezintă mijlocul de obţinere a unor
performanţe mai bune prin dirijarea cererilor
venite către servere diferite
 nu este dependentă de toleranţa la defecte
sau de HA-ul sistemului
 un site web poate folosi o fermă de servere
pentru a oferi informaţii complexe bazate pe
datele stocate în baza de date.
 dacă baza de date nu reprezintă un bottleneck,
distribuirea cererilor între servere va îmbunătăţi
considerabil performanţele.

Baza de date reprezintă un punct singular de

defecte (single point of failure), o problemă de
funcţionare la nivelul acesteia rezultând în
căderea întregului sistem.
Acesta este unul dintre cazurile în care ferma de
servere nu poate îmbunătăţi HA-ul sistemului.
 Unele sisteme oferă atât mecanisme de
toleranţă la defecte, şi prin urmare
disponibilitate mare (HA), cât şi mecanisme
de echilibrare a încărcărilor pentru o mai
bună scalabilitate.
 Descoperirea automată a nodurilor. Nodurile unui cluster
ar trebui să se găsească singure fără o nici o configurare
prealabilă.
 Fail-over şi load balancing pentru: JNDI, RMI, Entity Beans,
Stateful Session Beans cu replicare în memorie a stării
interne, Stateless Session Beans.
 Replicarea sesiunilor HTTP
 Descoperirea automată a contextului JNDI. Clienţii JNDI ar
trebui să descopere în mod automat contextul iniţial (JNDI
IntialContext).
 Replicarea tree-ului JNDI în tot clusterul
 Deployment-uri inteligente
 Farming – deployment inteligent la nivel de cluster
 Politici flexibile şi configurabile de echilibrare a
încărcărilor (pluggable load-balance policies)
 Aşa cum a fost definit în secţiunile anterioare, un
cluster este alcătuit dintr-un set de noduri,
fiecare nod putând fi reprezentat de o instanţă
de server.
 Pentru construirea unui cluster mai multe
instanţe de server sunt grupate în cadrul unei
partiţii.
 Partiţia reprezintă un concept important în
domeniul clusterelor enterprise.
 În cadrul aceleiaşi reţele de calculatoare pot
exista mai multe partiţii diferite. Pentru a le
putea diferenţia, fiecare partiţie trebuie
identificată în mod unic.
(sursa: JBoss Clustering 4th Edition, JBoss Group LLC)
 o partiţie defineşte un set de noduri care
lucrează împreună pentru îndeplinirea unui scop
comun.
 caracteristicile de cluster necesită sub-
partiţionarea acestuia pentru o mai bună
scalabilitate.

Spre exemplu, pentru obţinerea toleranţei la

defecte, se poate folosi, în cazul stateful session
bean-urilor, replicarea în memorie a stării
acestora pe diferite noduri. Într-un cluster ce
conţine doar două noduri, acest lucru se face prin
replicarea stărilor tuturor bean-urilor de pe
nodul pereche.
 Problema replicării stărilor în memorie se complică atunci
când numărul nodurilor din cluster creşte. De exemplu,
pentru un cluster cu 10 noduri, conform raţionamentului
precedent, ar însemna ca fiecare nod să conţină stările de
backup ale tuturor bean-urilor din celelalte 9 noduri.
Această situaţie prezintă o problemă importantă deoarece
algoritmul nu este scalabil, fiecare nod ajungând să
conţină starea întregului cluster.
 Din acest exemplu reiese clar că este mult mai potrivită o
sub-partiţionare în cadrul unei partiţii (cluster), combinată
cu replicarea stărilor interne ale bean-urilor doar între
nodurile conţinute în cadrul aceleiaşi sub-partiţii.

Este posibil ca sub-partiţionarea clusterului să fie

configurată şi ajustată dinamic de către software-ul de
cluster.
(sursa: JBoss Clustering 4th Edition, JBoss Group LLC)
 Independent de soluţia de cluster aleasă,
mecanismele de fail-over şi load-balancing
trebuiesc implementate în cadrul unor
componente.
 Când un client comunică cu un nod care se
defectează brusc, unele soluţii necesită din
partea clientului reconectarea explicită la un
nou nod. Această soluţie oferă toleranţă la
defecte (fault tolerance), dar nu este
transparentă pentru client.
(sursa: JBoss Clustering 4th Edition, JBoss Group LLC)
 se poate imagina un fail-over transparent care să
aibă loc la nivelul unei entităţi intermediare
(dispatcher): când dispatcher-ul recepţionează o
cerere, această cerere va fi dirijată de către
acesta la o instanţă de server (nod), iar dacă
acesta se defectează (şi dacă semantica
îngăduie), mecanismul de fail-over pentru alt nod
de la nivelul dispatcher-ului intră în funcţiune.

Totuşi, apare o problemă la nivelul dispatcher-

ului: ce se întâmplă dacă acesta se defectează?
(sursa: JBoss Clustering 4th Edition, JBoss Group LLC)
 RMI oferă o serie de caracteristici importante:
◦ când un client cere un stub pentru un obiect remote, este posibilă
trimiterea unui obiect specializat.
◦ este posibil ca clientul să preia clasa stub-ului de la orice server în
mod transparent.

 În momentul în care clientul ia referinţa remote, acesta

obţine un obiect serializat însoţit de o adresă URL de la
care sub-sistemul RMI al clientului poate descărca definiţia
clasei. Astfel, acest obiect preluat:
◦ se comportă ca un stub pentru referinţa remote
◦ clasa acestuia poate fi generată programatic la runtime şi nu este
necesar ca interfeţele implementate şi clasele referite de acesta să
facă parte din librăriile clientului deoarece pot fi preluate din reţea
◦ poate conţine cod specific care va rula transparent pe calculatorul
clientului. Codul client este total izolat de existenţa acestui cod.
 Primul punct este important deoarece reprezintă
contractul dintre client şi obiectul remote: clientul trebuie
să poate face invocări remote prin stub-ul obţinut.
 Al doilea punct oferă aplicaţiilor enterprise posibilitatea de
a fi instalate în serverele enterprise fără o generare,
compilare şi distribuire prealabilă a stub-urilor către
clienţi.
 Al treilea punct reprezintă un punct cheie în
implementarea eficientă a unui cluster deoarece apare
posibilitatea în care clientul poate prelua codul unui stub
care conţine logica de fail-over şi de load-balancing.
Astfel, nu mai există riscul defectării dispatcher-ului din
cazul discutat anterior, în cazul de faţă acesta fiind direct
încorporat în codul clientului, ciclul de viaţă al clientului şi
al dispatcher-ului fiind strâns legate: dacă dispatcher-ul
moare este foarte probabil că şi codul clientului a murit.
(sursa: JBoss Clustering 4th Edition, JBoss Group LLC)
 Proxy-ul preluat de client va conţine o listă cu nodurile
accesibile din cadrul clusterului. Mai mult, acest proxy
poate conţine şi o politică de load-balancing care poate fi
specificată la instalarea aplicaţiei enterprise sau la
runtime, cum ar fi: round robin, primul disponibil etc.
 O problemă importantă în construirea clusterelor dinamice
o reprezintă schimbarea topologiei clusterului la runtime.
◦ Această problemă poate fi rezolvată în felul următor: dacă
topologia clusterului se schimbă, la următoarea invocare din
partea clientului, acesta din urmă va recepţiona pe lângă
rezultatele invocării şi o listă de noduri cu noua topologie. Proxy-
ul va extrage lista de noduri din răspuns, îşi va actualiza
informaţiile despre topologia clusterului şi va returna rezultatul
invocării codului client fără a include însă şi lista de noduri
primită.
 Introducerea logicii de clustering în cadrul proxy-urilor RMI are
mai multe consecinţe:
◦ Ca parte pozitivă, această soluţie oferă un număr foarte mare de
posibilităţi cu privire la politicile de clustering, acestea fiind transparente
pentru codul client.
◦ Ca parte negativă, această soluţie pare la prima vedere strâns legată de
RMI, având ca efect direct pierderea acestor funcţionalităţi în cazul
clienţilor non-RMI. Totuşi, analizând situaţia îndeaproape, modelul pentru
clienţii non-RMI poate fi redus la modelul dispatcher-ului discutat în
secţiunile anterioare: pe partea dinspre server a dispatcher-ului RMI-ul va
fi în continuare folosit, prin urmare păstrându-se toate funcţionalităţile de
clustering prezentate, în timp ce pe partea dinspre client a dispatcher-ului
se va putea folosi orice protocol, rolul dispatcher-ului în acest caz fiind
acela de traducere a invocărilor de la un protocol la altul.

Apare totuşi o problemă în cazul în care dispatcherul se

defectează, deoarece în cadrul abordării prezentate, unde
controlul asupra codului client este pierdut, nici o soluţie
software nu mai poate fi folosită. Prin urmare, un load-balancer
hardware ar trebui utilizat.
(sursa: JBoss Clustering 4th Edition, JBoss Group LLC)
 Definirea statică a topologiei clusterului nu mai este
necesară.
◦ singura informaţie care trebuie furnizată în acest caz este
identificatorul de cluster (partiţie).
◦ dacă identificatorul nu este specificat explicit atunci partiţia
implicită va fi folosită.
◦ odată ce o partiţie (cluster) a fost specificată, nodurile pot intra şi
ieşi în mod dinamic din cadrul acesteia.
 Folosind abordările discutate în secţiunile anterioare,
clienţii care invocă metode în cluster pot fi automat
informaţi despre schimbările dinamice ale topologiei
acestuia.
 Un cluster enterprise ar trebui să ofere posibilitatea unei
configurări cât mai flexibile a mecanismelor de
descoperire automată a nodurilor cât şi a comunicaţiilor
din cadrul reţelei.
 Comunicaţiile dintre nodurile unui cluster
sunt necesare pentru:
◦ descoperirea de noi noduri
◦ descoperirea nodurilor care s-au defectat
◦ schimbul de informaţii de stare
◦ realizarea acţiunilor (use-case-urilor) ce implică
noduri multiple

Un cluster enterprise poate oferi posibilitatea

schimbării infrastructurii de comunicaţie
folosite în cadrul acestuia.
 Round-Robin
◦ primul nod poate fi ales aleator din lista
◦ fiecare nouă invocare este trimisă către nodul următor din
listă în mod secvenţial
 Random-Robin
◦ fiecare nouă invocare este trimisă către un nod ales aleator
din listă
 First available
◦ un nod este ales în mod aleator din listă şi folosit pentru
toate invocările
◦ fiecare proxy îşi alege propriul nod
◦ suport pentru “sticky sessions”
 First available identical all proxies
◦ un nod este ales în mod aleator din listă şi folosit pentru
toate invocările şi pentru toate proxy-urile
 Transaction-Sticky Round-Robin
 Transaction-Sticky Random-Robin
 Transaction-Sticky First Available
 Transaction-Sticky First Available Identical All
Proxies

 Extind politicile standard

 Toate invocările din cadrul unei tranzacţii
sunt rutate către acelaşi nod
(sursa: JBoss AS 5.1 Clustering Guide, septembrie 2009)
 JGroups
◦ librărie de comunicaţii ce garantează transmiterea datelor în mod punct-la-punct sau
punct-la-multipunct
◦ librărie utilizată în toate comunicaţiile legate de clustering între noduri
 JBoss Cache
◦ librărie de caching tranzacţional la nivel de cluster
◦ asigură HA prin replicarea stărilor nodurilor în cluster
◦ asigură coerenţa datelor în cluster
◦ foloseşte JGroups pentru comunicaţii în cluster
 POJO Cache
◦ extensie a JBoss Cache
◦ suport pentru replicare “fine-grained” a stării sesiunilor în cadrul clusterului
 HAPartition
◦ adapter peste JGroups
◦ mai multe servicii de clustering pot folosi acelaşi canal de comuncaţii
◦ suport pentru un registru distribuit de servicii ce rulează în cluster
◦ suport pentru notificări cu privire la modificarea topologiei clusterului cât şi cu privire
la modificările din registrul distribuit de servicii
 canal de comunicaţii între nodurile unui
cluster
 asigură managementul apartenenţei nodurilor
în cadrul unui grup
 suport pentru detectarea nodurilor defecte
 asigură livrarea mesajelor după modelul
primul intrat primul ieşit (first-in-first-out)
 asigură controlul fluxului de mesaje şi
previne supraîncărcarea sistemului
 înglobează un set de protocoale în funcţie de
configuraţia specificată
 udp
◦ udp multicast
◦ shared între canale
◦ împachetarea mesajelor dezactivată datorită latenţei introduse în RPC-uri sincrone
◦ controlul fluxului de mesaje activat
 udp-async
◦ împachetarea mesajelor activată
◦ recomandat pentru servicii cu volum mare de RPC-uri asincrone (servicii de cache)
 udp-sync
◦ împachetarea mesajelor dezactivată
◦ controlul fluxului de mesaje dezactivat
◦ recomandat pentru RPC-uri sincrone cu volum de date şi rate de transmisie rezonabile
 tcp
◦ împachetarea mesajelor activată
◦ controlul fluxului de mesaje activat
◦ utilizat în general când IP multicast nu poate fi folosit într-o reţea (router-ele ignoră traficul multicast)
 tcp-sync
◦ împachetarea mesajelor dezactivată
◦ controlul fluxului de mesaje dezactivat
◦ recomandat pentru RPC-uri sincrone cu volum de date şi rate de transmisie rezonabile
 jbm-control
◦ optimizat pentru JBoss Messaging Control Channel
◦ implicit foloseşte aceiasi configuraţie ca şi udp ceea ce îngăduie folosirea aceloraşi socket-uri, buffere de reţea si pool-uri de
thread-uri
 jbm-data
◦ oprimizat pentru JBoss Messaging Data Channel
◦ axat pe tcp
(sursa: JBoss AS 5.1 Clustering Guide, septembrie 2009)
 framework distribuit de caching
 poate fi folosit în orice infrastructură
enterprise sau stand-alone
 oferă suport pentru cache distribuit pentru
mai multe servicii din clusterele JBoss:
◦ replicarea sesiunilor web
◦ replicarea stateful session beans
◦ cachingul entităţilor JPA şi Hibernate
◦ single sign-on la nivel de cluster
◦ replicarea arborelui HA-JNDI
◦ etc
Curs 3
 set de specificaţii care definesc toate aspectele unui mediu
distribuit de calcul necesare pentru a dezvolta aplicaţii
enterprise
 abordează o gamă largă de domenii, oferind specificaţii
pentru:
◦ pagini web dinamice (dynamic web pages)
◦ componente business (business components) – Enterprise
JavaBeans (EJB-uri)
◦ comunicaţii asincrone (Java Messaging Service - JMS)
◦ servicii de nume şi directoare (Java Naming and Directory
Interface - JNDI)
◦ accesul la baze de date (Java Database Connectivity API - JDBC)
◦ legăturile cu alte sub-sisteme (Java Connector Architecture -
JCA)
◦ securitate
◦ etc.
 Unele detalii, tipic implementate de mediile
enterprise, sunt lăsate nedefinite

 Exemplu: partea de clustering a serverelor JEE

◦ producătorii pot dezvolta mecanismele de
clustering în orice fel, atâta timp cât implementarea
oferită este conformă cu specificaţiile JEE.
 Implementează specificaţiile JEE
 Proiectarea arhitecturii de clustering implică
mecanisme specifice pentru:
◦ administrarea clusterului
◦ load-balancing
◦ fail-over
◦ replicarea stărilor între noduri
◦ tehnici de caching
◦ modalităţi şi protocoale de comunicaţie
◦ etc.
 Designul şi implementarea acestor
mecanisme trebuie făcută atât din perspectiva
serviciilor sincrone cât şi a serviciilor
asincrone.
 Suportul de clustering oferit în cadrul unei
implementări JEE poate cuprinde:
◦ toate tipurile de EJB-uri
◦ tree-ul JNDI
◦ sesiunile web (web sessions)
◦ cozile JMS
(sursa: Load Balancing and Failover in the JBoss Application Server, JBoss Group)
 Invocarea remote este iniţiată de un client remote
şi direcţionată către un server enterprise
 Pentru a putea realiza acest mod de comunicaţie,
clienţii trebuie mai întâi să obţină un proxy
pentru obiectul remote. Acest lucru de realizează
în mod tipic prin accesarea serviciilor JNDI.

 Modul de implementare a obiectului proxy este

lăsat în seama producătorului implementării JEE.
În general un proxy conţine secvenţe de cod
complexe.
 Văzut din exterior, un proxy (1) este similar
cu obiectul remote pe care îl reprezintă:
◦ implementează aceeaşi interfaţă (2)
◦ redirectează invocările recepţionate către obiectul
remote aflat pe server.

 Interfaţa remote se mai numeşte şi interfaţă

business (business interface).
 Când interfaţa proxy-ului este invocată,
această invocare este convertită (4) dintr-o
invocare dependentă de tip (typed call) (3)
într-o invocare independentă de tip (untyped
call) (6) asupra unei interfeţe interne (5)
independente de interfaţa business.

 Invocarea independentă de tip traversează în

cadrul clientului un lanţ de interceptori (7).
 Fiecare interceptor din lanţul de interceptori
recepţionează în mod secvenţial invocarea,
având posibilitatea să:
◦ analizeze conţinutul invocării şi să execute anumite
acţiuni
◦ adauge informaţii arbitrare invocării
◦ citească sau să modifice informaţiile ataşate
invocării
◦ înainteze invocarea următorului interceptor din
lanţul de interceptori
◦ întrerupă lanţul de interceptori şi să returneze
direct o valoare sau o excepţie
 Ultimul interceptor din lanţ va trimite invocarea
propriu-zisă pentru execuţie către server-ul
remote folosind un invoker specific unui anumit
protocol de transport (8) instalat în sistem.

 Dacă clientul se află în aceeaşi maşină virtuală

Java (JVM) ca şi obiectul ţintă, ultimul interceptor
va detecta această situaţie şi nu va mai apela
invoker-ul de transport realizând un apel local,
mult mai rapid, direct pe obiectul ţintă.
 Un aspect important al acestui tip de
arhitectură de invocare la distanţă este faptul
că acest tip de proxy este independent de
protocolul de transport al datelor în reţea.

 Singura componentă dependentă de

protocoalele de comunicaţii este componenta
invoker-ului de transport (8).
 Urmând calea inversă a returnării rezultatului
către client, similar cu abordarea trimiterii
invocării către server, fiecare interceptor din
lanţ are posibilitatea să modifice rezultatul
invocării:
◦ poate să schimbe valoarea returnată
◦ poate să arunce o excepţie
◦ poate modifica tipul unei excepţii deja aruncate
◦ etc.
 La proiectarea arhitecturii de clustering a unei
platforme enterprise un aspect important
care trebuie luat în calcul este acela al
stabilirii locaţiilor mecanismelor de load-
balancing şi fail-over

 Posibile variante ale locaţiilor:

◦ ...
 Posibile variante ale locaţiilor:
◦ la nivelul nodului
◦ pe o entitate intermediară între client şi server
◦ la nivelul aplicaţiei client (în cadrul proxy-ului)
(sursa: Load Balancing and Failover in the JBoss Application Server, JBoss Group)
 Fiecare soluţie oferă o serie de avantaje şi
dezavantaje.

 Avantajele ultimei soluţii surclasează

avantajele primelor două deoarece:
◦ ...
 se elimină existenţa oricărui punct singular
de defecte (single point of failure) pentru
simplul motiv că nu există nici o entitate
intermediară sau server care să participe pe
calea de comunicaţii
 ...
 mecanismele de load-balancing şi fail-over
îşi încetează execuţia când şi clientul îşi
încetează execuţia
 ...
 costurile de performanţă pentru activităţile de
load-balancing şi fail-over sunt minime şi
complet distribuite, aceste activităţi fiind
executate la nivelul clientului, în acest fel
eliminându-se potenţialele supraîncărcări de
la nivelul serverelor sau de la nivelul
entităţilor intermediare.
 Mecanismele de load-balancing şi fail-over
pot fi proiectate flexibil, permiţând
configurarea strategiei de selectare a
nodurilor pe care urmează a se face
invocarea.
◦ Ex: ...

 De asemenea, pot fi furnizate şi unele

mecanisme de notificare a clienţilor cu privire
la modificarea topologiei clusterului.
Exemplu de strategii:
 Round-Robin
◦ primul nod poate fi ales aleator din lista
◦ fiecare nouă invocare este trimisă către nodul următor din listă în
mod secvenţial
 Random-Robin
◦ fiecare nouă invocare este trimisă către un nod ales aleator din
listă
 First available
◦ un nod este ales în mod aleator din listă şi folosit pentru toate
invocările
◦ fiecare proxy îşi alege propriul nod
◦ suport pentru “sticky sessions”
 First available identical all proxies
◦ un nod este ales în mod aleator din listă şi folosit pentru toate
invocările şi pentru toate proxy-urile
 Ideea introducerii mecanismelor de load-
balancing şi fail-over în cadrul clientului nu
este nouă: de exemplu, protocolul GIOP din
cadrul CORBA (Common Object Request
Broker Architecture) introduce noţiunea de
mecanism multi-profil care populează
referinţele obiectelor remote (IOR) cu
destinaţii alternative de urmat în cazul
defectării destinaţiei selectate în mod curent.
 Logica şi mecanismele de load-balancing şi
fail-over pot fi localizate în cadrul ultimului
interceptor al proxy-ului.

 Proxy-ul poate conţine câte un invoker

pentru fiecare ţintă posibilă.
(sursa: Load Balancing and Failover in the JBoss Application Server, JBoss Group)
 În contextul
posibilităţii specificării
politicilor de load-
balancing şi fail-over,
interceptorul va putea
lua decizii de rutare în
funcţie de acestea.

(sursa: Load Balancing and Failover in the JBoss Application Server, JBoss Group)
 La apariţia unei invocări, ultimul interceptor
va interoga politica de load-balancing în
vederea selectării unui nod ţintă după care va
trimite invocarea pentru execuţie către
acesta.
 Dacă invocarea a fost făcută cu succes (nu au
apărut excepţii sistem), rezultatul invocării va
fi trimis clientului, altfel interceptorul va
verifica dacă poate să facă fail-over (excepţia
apărută poate fi recuperată – este
transparentă).
 Ex: ...
 Un exemplu de excepţie transparentă apare când
legătura cu nodul ţintă este întreruptă înainte de
trimiterea invocării. În acest caz, interceptorul va
notifica politica de load-balancing de această
situaţie, urmând să primească o nouă ţintă.

 Acesta este unul dintre cazurile în care mecanismul

de fail-over poate fi apelat în mod transparent pentru
codul client deoarece, datorită faptului că nodul ţintă
nu a putut fi atins, nici o modificare de stare nu a
avut cum să apară la nivelul serverului. Prin urmare,
nu există nici un risc de invocări duplicate sau
incomplete care trebuiesc recuperate explicit de către
aplicaţia client.
 Ex: ...
 Dacă interceptorul recepţionează un alt tip de
excepţie, cum ar fi o excepţie a bazei de date de
la nivelul server-ului, acesta se va afla în
imposibilitatea de a realiza un fail-over
transparent şi va înainta excepţia aplicaţiei client
care va avea posibilitatea de decizie asupra
modului în care această excepţie poate fi tratată.

 Situaţia discutată este un exemplu reprezentativ

al situaţiilor care nu pot fi rezolvate în mod
generic la nivelul interceptorului.
 Comportamentul descris este foarte flexibil, dar
configurarea şi implementarea acestuia poate fi
destul de complicată.

 Mecanismul de încărcare a claselor în Java oferă

posibilitatea de a nu avea unele clase disponibile
pe partea clientului (ex: clasele interceptorilor şi
ale politicilor de load-balancing şi fail-over), în
momentul preluării proxy-ului de către aplicaţia
client
◦ aceste clase pot fi preluate în paralel, sau chiar într-o
manieră lazy.
 În general, clusterele enterprise oferă
posibilitatea de a porni şi opri noduri în mod
dinamic.
 Pentru acest tip de clustere o configurare
statică este inadecvată.
 Comportamentul dinamic oferă o flexibilitate
mărită, dar ridică o problemă esenţială: ...
 Comportamentul dinamic oferă o flexibilitate
mărită, dar ridică o problemă esenţială:
proxy-ul clientului poate conţine la un
moment dat informaţii învechite cu privire la
topologia clusterului
(sursa: Load Balancing and Failover in the JBoss Application Server, JBoss Group)
 Pentru a răspunde acestei probleme, o soluţie
ar fi ca proxy-urile să îşi reactualizeze
informaţiile cu privire la topologia clusterului
de fiecare dată când o nouă invocare este
executată.
(sursa: Load Balancing and Failover in the JBoss Application Server, JBoss Group)
 În contextul prezentat mai sus, pentru fiecare
invocare asupra unui proxy, acesta din urmă
va trimite către server, pe lângă invocarea
propriu-zisă şi un număr de identificare al
topologiei clusterului deţinute în acel
moment la nivelul clientului (1), la nivelul
serverului urmând să se verifice dacă acest
număr de identificare reprezintă topologia
curentă a clusterului (2).
 Acest număr de identificare ar trebui:
◦ ...
 Acest număr de identificare ar trebui:
◦ să fie simplu de generat
◦ să nu depindă de ordinea membrilor clusterului
◦ să ofere posibilitatea de a ţine seama doar de un
subset de noduri din cluster (în cazul în care o
anumită aplicaţie enterprise este instalată doar pe
un subset de astfel de noduri)
 La nivelul serverului se verifică dacă numărul
de identificare trimis de client este acelaşi cu
numărul de identificare menţinut şi actualizat
de server (2), caz în care clientul deţine
informaţii actualizate cu privire la topologia
clusterului. Prin urmare, serverul va trimite
către client numai rezultatele invocării fără a
mai include şi informaţii adiţionale cu privire
la topologia clusterului.
 În situaţia în care numărul de identificare de la nivelul
serverului nu corespunde cu numărul de identificare
trimis de client, prin urmare clientul deţinând
informaţii neactualizate cu privire la topologia
clusterului, serverul va trimite către client atât
rezultatele invocării cât şi informaţii adiţionale cu
privire la topologia curentă a clusterului sub forma
unei liste actualizate a membrilor acestuia alături de
noul număr de identificare (3).
 Odată ce răspunsul va ajunge la client, invokerul
clientului va folosi aceste informaţii adiţionale pentru
a-şi reactualiza starea cu privire la topologia
clusterului şi va returna rezultatul invocării codului
client, nu înainte însă de a exclude datele adiţionale
referitoare la topologie.
 O altă componentă importantă a clustering-ului
enterprise o reprezintă activitatea de replicare care
poate avea loc între nodurile clusterului enterprise.
 Replicarea este importantă pentru componentele care
menţin o stare internă distinctă între două invocări
(stateful components), prezenţa acestora într-o
aplicaţie enterprise putând afecta performanţele
globale ale sistemului.
◦ Totuşi, acest lucru depinde atât de conţinutul
componentelor stateful cât şi de frecvenţa de schimbare a
acestuia.
 Multe aplicaţii enterprise folosesc doar componente
stateless care nu necesită mecanisme de replicare pe
cluster.
 Din punct de vedere al mecanismelor de
load-balancing şi fail-over, costurile
implementării descrise în secţiunile anterioare
sunt minime.
 Procesul de decizie nu este computaţional
intensiv şi se execută exclusiv pe calculatorul
clientului.
Curs 4
 Performanţă – obiectele sunt replicate şi
distribuite în cadrul clusterului pentru a putea
deservi mai mulţi clienţi simultan.
◦ ciclul de viaţă al acestor obiecte este controlat de
către sistem.
◦ sunt folosite tehnici specifice de optimizare cum ar
f evacuarea datelor
fi d l pe niveluri l secundare
d d
de
memorie, pool-uri de resurse, sub-partiţionări,
tehnici de load-balancing g şi
ş fault tolerance etc.
 Scalabilitate – în cazul creşterii numărului de
cereri din sistem, performanţele aplicaţiei
enterprise pot fi menţinute prin creşterea
numărului instanţelor obiectelor distribuite
proporţional cu cantitatea de noi resurse
computaţionale
p ţ şi
ş de comunicaţii ţ p
puse la
dispoziţie, fără a necesita modificări ale
codului sursă.
 Securitate – sunt puse la dispoziţie
mecanisme eficiente de autentificare şi
autorizare a entităţilor din sistem,
dezvoltatorii putând controla nivelurile de
securitate la granularitatea dorită.
 Tranzacţii distribuite – sunt oferite mecanisme de
controll all tranzacţiilor
iil distribuite
di ib i fără
fă ă a necesita
i
scriere de cod special în acest sens din partea
dezvoltatorilor.
◦ Tranzacţiile pot fi definite în afara codului de către
asamblorul de aplicaţii sau de către administratorul de
sistem folosind fişiere standard pentru configurarea şi
demarcarea acestora.
◦ În cazul apariţiei unei excepţii în timpul derulării unei
tranzacţii
tranzacţii, revenirea la starea de dinaintea începerii
acesteia a tuturor componentelor implicate în cadrul
tranzacţiei este garantată.
 Reutilizabilitate – componentele unei aplicaţii
enterprise conforme cu specificaţiile JEE, cât
şi întreaga aplicaţie, pot fi instalate şi rulate
cu un efort minim în cadrul altor servere de
aplicaţii compatibile JEE dezvoltate de alţi
vendori.
 Disponibilitate – în general sunt asigurate
mecanisme de fail-over care intră în acţiune
în cazul în care unul dintre serverele
disponibile se defectează,
defectează noile cereri apărute
în sistem fiind redirectate automat către
celelalte servere disponibile
p care conţin
ţ
replici sincronizate (datorită mecanismelor de
replicare pe cluster) ale datelor care se aflau
pe serverull d f t t
defectat.
 Platforma enterprise JEE descrie un model de
componente pe partea de server,
server care oferă toate
serviciile middleware prezentate în secţiunile
anterioare.
 Platforma oferă dezvoltatorilor posibilitatea de a
crea componente EJB (Enterprise JavaBeans)
focalizate numai pe partea de business a
problemei abordate.
 Deoarece componentele sunt definite într-un
mod standard, pot fi reutilizate şi instalate în
cadrul
cad u altor
a to aplicaţii
ap caţ enterprise
e te p se şi
ş al
a altor
a to servere
se e e
de aplicaţii compatibile JEE, fiind independente
de vendor.
 Din cauza asemănării de nume, există
confuzii în ceea ce priveşte relaţia dintre
modelul componentelor JavaBeans şi
specificaţia Entreprise JavaBeans.
JavaBeans
 În timp ce ambele specificaţii împărtăşesc
aceleaşi obiective de promovare a conceptelor
de reutilizare şi portabilitate a codului Java
între instrumentele de dezvoltare şi de
execuţie, motivele care stau la baza ffiecărei
specificaţii abordează probleme distincte.
 Standardele definite în cadrul modelului de
componente JavaBeans au fost dezvoltate
pentru crearea de componente reutilizabile
care sunt folosite în mod uzual în cadrul
instrumentelor de dezvoltare tip IDE
((Integrated
g Development
p Environment),
),
aceste componente fiind de obicei, deşi nu
întotdeauna, componente vizuale.
 Specificaţia Enterprise JavaBeans defineşte un
model de componente pentru dezvoltarea de
cod Java pe partea de server.
 Deoarece EJBEJB-urile
urile sunt concepute să ruleze
în cadrul diverselor servere de aplicaţii pe
diferite platforme (incluzând mainframe-urile
mainframe urile
care nu au mijloace de afişaj), acestea nu pot
utiliza librării grafice cum ar fi AWT (Abstract
Window Toolkit) sau Swing.
 Conceptul de clustering în cadrul
platformelor distribuite enterprise presupune:
◦ replicarea resurselor
◦ comunicaţii
◦ controlul concurenţei
◦ gestionarea defectelor
◦ controlul accesului la resursele externe
 În cazul în care în timpul unei invocări
executate de codul client în cadrul clusterului
apare o excepţie sistem, trei scenarii diferite
sunt posibile:
◦ ...
 nodul selectat s-a defectat sau comunicaţia
cu acesta a fost întreruptă înaintea
recepţionării cererii. În acest caz, mecanismul
de fail
fail-over
over poate acţiona transparent pentru
codul client selectând un nou nod din cluster
pe care va relua invocarea.
p
 ...
 nodul selectat a recepţionat invocarea dar s-a
defectat înainte de a termina procesarea
acesteia sau înainte de a-şi putea replica
starea în cluster
cluster. Ca şi în cazul precedent
mecanismul de fail-over poate acţiona
transparent
p p
pentru codul client.
 ...
 nodul selectat a recepţionat şi a procesat
invocarea, şi-a replicat starea în cadrul
clusterului, şi s-a defectat sau comunicaţia cu
clientul a fost întreruptă înainte ca răspunsul
să ajungă la acesta.
◦ Şi
Ş în acest caz mecanismul de fail-over ppoate
acţiona transparent pentru codul client cu
menţiunea că ...
 ... acest mecanism va trebui să marcheze
reinvocarea către noul nod selectat ca fiind
rezultată dintr-un fail-over.
◦ Nodurile din cluster trebuie să fie capabile să
recunoască această situaţie şi să evite o eventuală
reprocesare a cererii.
 O parte dintre serverele de aplicaţii J2EE
existente pe piaţă, JBoss AS fiind unul dintre
acestea, oferă posibilitatea specificării prin
intermediul fişierelor externe de configurare
a metodelor idempotente din cadrul
componentelor
p EJB.
J
 O metodă idempotentă este o metodă care
poate fi invocată de oricâte ori fără a modifica
starea sistemului. Prin urmare, folosind
mecanismele de marcare a metodelor
idempotente puse la dispoziţie de către
serverele de aplicaţii
p ţ JJEE,, p
performanţele
ţ
mecanismelor de fail-over pot fi mult
îmbunătăţite, deoarece ...
 ... acestea nu mai trebuie să identifice
contextele de fail-over, reducând atât timpul
de execuţie cât şi consumul de memorie atât
pe partea de client cât şi pe partea de server
server.
 Replicarea resurselor în cadrul unui cluster
enterprise presupune:
◦ replicarea Stateful Session Bean-urilor
◦ replicarea Entity Bean-urilor
◦ replicarea sesiunilor HTTP
◦ replicarea arborilor JNDI
 Există unele recomandări de instalare şi
configurare
fi a componentelor
l EJB cum ar fi:fi
◦ sesiuni legate de server (sticky sessions) – în timpul unei
sesiuni, toate cererile iniţiate de un client vor ajunge
întotdeauna pe acelaşi nod din cluster. (de ce?)
◦ instalare omogenă (homogeneous deployment) – codul
fiecărei componente
p din cadrul aplicaţiei
p ţ enterprise
p va fi
replicat pe toate nodurile din cluster.
 Luate împreună, aceste două abordări implică
faptul că fiecare cerere va fi procesată în
totalitate pe acelaşi server din cluster.
 Considerând mecanismele de replicare la
nivelul sistemului distribuit, fiecare
componentă care deţine o stare internă ce
trebuie păstrată între invocări trebuie
replicată în cadrul clusterului sau în cadrul
unei sub-partiţii
p ţ a acestuia.
 Mecanismele de replicare constau în general
în emiterea la nivelul clusterului, (când?), a
stării serializate a componentelor modificate
(optimizare?), replicarea având loc într
într-o
o
manieră sincronă (cum?).
 când - în urma fiecărei invocări
 optimizare – doar a câmpurilor modificate şi
nu a întregii componente
 cum - un mecanismi d
de llocking
ki di
distribuit
ib i
peste toate replicile din cluster este mai întâi
instalat.
instalat
 Problema replicării parţiale

 Problema partiţiilor
 potenţială problemă de coerenţă a datelor
care poate apărea în cadrul execuţiei use-
case-urilor care implică mai multe
componente stateful.
stateful
 pentru exemplificare se consideră două SFSB-
uri (Stateful Session Bean), S1 şi S2, replicate
în cadrul unui cluster pe două servere A şi B.
 Clientul invocă o
metodă a bean-ului
bean ului S1
pe nodul A.
 Bean-ul S1 invocă o
metodă a bean-ului
bean ului S2
în cadrul aceluiaşi nod.
 Invocarea bean-ului S2
se termină cu succes
iar starea acestuia este
replicată pe nodul B.
 Bean-ul S1 încearcă să
facă o altă invocare
asupra bean-ului S2,
dar nodul A se
defectează.
 Considerând acest
scenariu,
scenariu nodul B va
ajunge să conţină o
stare inconsistentă.
 Potenţiale soluţii:
◦ ...
 O posibilă soluţie în abordarea acestei
probleme este instalarea la nivelul clusterului
a unui manager de tranzacţii care să readucă
bean ul S2 la starea iniţială
bean-ul iniţială.
 ...
 O altă soluţie ar fi ca replicarea în cluster să
se facă simultan pentru toate componentele
modificate, numai în momentul în care
întreaga tranzacţie a fost executată cu
succes.
 O altă problemă de coerenţă a datelor care
poate apărea la nivelul clusterului este
determinată de un potenţial defect la nivelul
reţelei de comunicaţii
comunicaţii, defect ce poate împărţi
clusterul în două sau mai multe partiţii care
nu p
pot comunica.
 Clientul caută noduri
disponibile în cluster.
cluster
 În momentul găsirii
unui nod disponibil,
disponibil
clientul înaintează
cererea către acesta.
 Fiecare SFSB este
asociat în mod unic
unui singur client. Prin
urmare nu vor putea
exista alţi clienţi care
să acceseze aceeaşi
instanţă în altă partiţie.
 Lista serverelor
disponibile la client
este actualizată după
fiecare invocare
invocare.
 În momentul în care
defectul reţelei este
remediat, clienţii se vor
afla în situaţia de a
avea liste neactualizate
ale topologiei
clusterului.
 La următoarea cerere a
clientului,
clientului starea bean-
bean
ului implicat va fi
replicată în cadrul
clusterului, iar lista de
servere de la nivelul
clientului va fi
reactualizată.
 Bean-ul S3 nu este
replicat în cluster,
cluster
deoarece clientul nu a
invocat încă nici o
metodă asupra sa.
 Serverul C se
defectează.
defectează
 Clientul accesează din
nou bean-ul
bean ul S2 şi
găseşte (fails over)
noul server disponibil
A.
 Bean-ul S2 invocă
bean-ul
bean ul S3 care este
neactualizat.
 Potenţiale soluţii:
◦ ...
 O posibilă soluţie în abordarea acestei
probleme este instalarea unui mecanism de
marcare a conţinutului componentelor
stateful la nivelul nodurilor clusterului,
clusterului
combinat cu un mecanism de detecţie şi
reactualizare pprin replicare
p a tuturor
componentelor out-of-date, mecanism ce va
intra acţiune în momentul cuplării partiţiilor.
Curs 5
 O posibilă abordare a echilibrării încărcării în
cadrul unui cluster este aceea a folosirii
agenţilor mobili şi a algoritmilor genetici.
 Task-urile distribuite pot fi duse la
îndeplinire de mai mulţi agenţi pe mai multe
noduri din reţea (calculatoare gazdă).
 Maparea dintre agenţi şi nodurile din reţea
este de tipul many-to-one.
 Este posibil ca toţi agenţii sau o parte dintre
aceştia să ruleze pe acelaşi calculator gazdă.
 Problema care se ridică este cum se poate
realiza echilibrarea încărcării când toate
calculatoarele gazdă sau o parte dintre
acestea devin supraîncărcate şi cum se pot
remapa agenţii mobili din subgraful curent al
calculatoarelor gazdă pe un alt subgraf
subîncărcat din cadrul aceluiaşi cluster,
respectându-se anumite restricţii.
 În prezent, reţelele de calculatoare sunt în
plină ascensiune, devenind din ce în ce mai
complexe, oferind o gamă largă de noi
servicii şi formând reţelele eterogene ce pot
lucra împreună ca un întreg. Prin urmare,
managementul reţelelor de calculatoare a
devenit o sarcină a cărei complexitate este în
continuă creştere.
 Abordările descentralizate ale
managementului reţelelor de calculatoare
sunt în prezent discutate şi devine din ce în
ce mai evident faptul că soluţiile centralizate
nu pot furniza soluţii în ceea ce priveşte
scalabilitatea. În particular tehnologia
agenţilor mobili este examinată ca o nouă
soluţie în rezolvarea acestei probleme.
 O caracteristică esenţială în managementul
reţelelor de calculatoare o reprezintă
echilibrarea încărcării deoarece asigură
utilizarea eficientă a resurselor reţelei cât şi
evitarea situaţiilor de supraîncărcare.
 În secţiunile următoare, se iau în considerare
folosirea agenţilor mobili şi a algoritmilor
genetici pentru dezvoltarea unui mecanism
descentralizat de echilibrare a încărcării.
 Obiectivul echilibrării încărcării este acela de
a distribui în mod egal încărcarea
computaţională şi a comunicaţiilor în cadrul
reţelei de calculatoare.
 Dacă nu s-ar ţine cont de echilibrarea
încărcării, supraîncărcarea nodurilor şi
congestiile din reţea vor apărea în paralel cu
situaţia în care o parte dintre nodurile reţelei
nu vor fi folosite la capacitate maximă.
 O aplicaţie distribuită este alcătuită dintr-o
colecţie de entităţi cooperante (task-uri).
 Task-urile se pot executa secvenţial sau în
paralel pe două sau mai multe procesoare.
 Maparea task-urilor are rolul de a distribui
încărcarea sistemului între procesoarele
existente astfel încât performanţele de
procesare per ansamblu, în funcţie anumite
criterii, să fie maximizate.
 O strategie de alocare eficientă previne
situaţia în care unele procesoare sunt
subîncărcate în timp ce altele sunt
supraîncărcate.
 Algoritmii genetici reprezintă tehnici generale
de căutare a soluţiilor optime într-un spaţiu
vast de soluţii posibile putând fi aplicaţi în
cadrul unei game variate de probleme de
optimizare.
 În cele ce urmează, vom analiza următoarea
problemă de mapare: distribuirea optimă şi
dinamică a task-urilor comunicante în cadrul
procesoarelor unei reţele de calculatoare
distribuite folosind agenţi mobili şi algoritmi
genetici.
 Această problemă este cunoscută ca fiind o
problemă NP-completă. Metodele euristice
pot găsi doar aproximări ale soluţiei optime,
dar o vor face într-un timp rezonabil.
 P, NP, NP-complet
 P = NP?
 G1 izomorf cu G2?
◦ Se pare că nu este nici P, nici NP-completă, ci NP
 G1 izomorf cu un subgraf din G2?
◦ NP-completă
(sursa: http://en.wikipedia.org/wiki/Graph_isomorphism)
 Două tehnici de optimizare larg răspândite sunt:
◦ algoritmul hill-climbing
◦ algoritmul simulated annealing
 Algoritmul hill-climbing găseşte minimul global
doar în cadrul spaţiilor convexe, altfel soluţia
găsită fiind un minim local.
 Algoritmul simulated annealing furnizează o cale
de a depăşi acest inconvenient al algoritmului
hill-climbing, preţul plătit fiind acela al unui cost
computaţional ridicat. Mai rău, algoritmul
simmulated annealing este mai degrabă de
natură secvenţială, paralelizarea sa fiind un lucru
destul de dificil de obţinut.
 Alte tehnici distribuite de optimizare, inerent
paralele:
◦ reţelele neuronale
◦ algoritmi genetici (discutaţi în continuare)
 Sunt inspiraţi din adaptarea sistemelor
naturale evolutive, fiind recent aplicaţi în
probleme de optimizare într-o gamă largă de
domenii, cum ar fi:
◦ problema poştaşului (traveling salesman problem)
◦ problema optimizării conexiunilor reţelelor
neuronale
◦ sisteme de clasificare
◦ etc.
 O aplicaţie distribuită compusă din task-uri
distribuite poate fi modelată printr-un graf
Gt=(Vt, Et), unde nodurile (vertices) reprezintă
task-uri, iar valorile asociate acestor noduri
reprezintă costuri computaţionale cunoscute
sau estimate ale task-urilor.
 Muchiile (edges) reprezintă comunicaţiile
dintre task-uri, iar valorile asociate acestora
reprezintă costurile de comunicaţie
cunoscute sau estimate.
 Iniţial s-a luat în considerare un graf static de
task-uri, comportamentul de realocare
dinamică fiind dat de un layer de agenţi
mobili care monitorizează şi remapează task-
urile aplicaţiei dacă este cazul.
 Arhitectura reţelei este modelată printr-un
graf conex Gp=(Vp, Ep), unde nodurile
reprezintă procesoarele, iar valorile asociate
acestor noduri reprezintă puterea de
procesare cunoscută sau estimată a acestor
procesoare.
 Muchiile reprezintă liniile de comunicaţie
dintre procesoare, iar valorile asociate
acestora reprezintă viteza de transfer a
datelor cunoscută sau estimată a acestor linii
de comunicaţie.
 Calea de comunicaţie aleasă între două
procesoare este calea cea mai rapidă, dintre
toate căile posibile de comunicaţie fiind
aleasă calea care oferă cea mai mare viteză de
transfer a datelor.
 Arhitectura reţelei este considerată ca fiind o
arhitectură statică, configuraţia fizică a reţelei
rămânând neschimbată.
 Următoarea terminologie este folosită:
◦ M numărul de task-uri ce trebuiesc mapate, M=|Vt|
◦ N numărul de procesoare din cadrul reţelei, N=|Vp|
◦ ei costul computaţional al task-ului ti
◦ ppk puterea de procesare a procesorului pk
◦ cij costurile de comunicaţie între task-urile ti şi tj
◦ lskl cea mai bună linie de comunicaţie între
procesoarele pk şi pl
 Maparea este definită sub forma unor funcţii
de tipul M p : Vt → V p care mapează fiecare task
la un anumit procesor.
 Pentru a putea compara posibilele soluţii de
mapare a task-urilor la procesoare, o funcţie
de fitness F : M p → ℜ este definită pentru a
asocia o valoare reală fiecărei funcţii de
mapare generate.
 Două criterii de mapare contradictorii au fost
considerate:
◦ Minimizarea costului total de comunicaţii între
procesoare. Acest cost este calculat ca o medie a
tuturor costurilor de comunicaţie dintre toate
perechile de task-uri, luând în considerare
procesoarele şi liniile de comunicaţie dintre
procesoarele pe care aceste task-uri au fost
mapate.
2 cij
MIN (CC ) = MIN ( ∑
M ( M − 1) i , j∈Vt ls M p (i ) M p ( j )
)
◦ Minimizarea dezechilibrului încărcării computaţionale a
sistemului. Măsura cantitativă folosită pentru evaluarea
acestui criteriu este abaterea standard (standard
deviation) a încărcării computaţionale pe diferite
procesoare.

Abaterea standard măsoară gradul de împrăştiere

a unei distribuţii, fiind calculată ca rădăcina
pătrată a mediei aritmetice a abaterilor pătratice
medii a fiecărui număr faţă de median. Calculul
abaterii standard este o parte esenţială a multor
aplicaţii statistice şi de analiză.
 Minimizare abatere standard
1 N
MIN ( SD) = MIN ( ∑
N k =1
( Lk − L ) 2
)

M N
L = ∑ ei ∑ pp k
i =1 k =1

M
Lk = ∑e
i =1
i ppk
M p ( i )=k
 Funcţia de fitness F aleasă pentru a evalua o
funcţie de mapare m ∈ M p este dată de suma
ponderată a celor două funcţii, CC şi SD,
definite mai sus:
F (m) = SD(m) + wCC (m)

unde w reprezintă ponderea costului de

comunicaţie în tot sistemul relativă la
încărcarea computaţională din sistem.
 Problema care apare este alegerea unei valori
potrivite pentru w, valorile foarte mici
determinând ignorarea comunicaţiilor, în
timp ce valorile foarte mari ar determina
ignorarea încărcărilor computaţionale.
 Deoarece încărcarea computaţională într-o
reţea poate fi aproximată foarte bine cu o
distribuţie normală, putem folosi abaterea
pătratică medie sau abaterea standard pentru
a măsura gradul de echilibrare a încărcărilor
în reţea.
 Formula pentru calcul a abaterii standard este
foarte simplă: este rădăcina pătrată a abaterii
pătratice medii, fiind larg răspândită în
măsurarea gradului de împrăştiere a unei
distribuţii.
 O caracteristică importantă a abaterii
standard este aceea că dacă medianul şi
abaterea standard a unei distribuţii normale
sunt cunoscute, este posibil să se calculeze
încadrarea procentuală a oricărui punct din
cadrul distribuţiei.
 Într-o distribuţie normală, aproximativ 68% dintre puncte
sunt la o depărtare de maxim o abatere standard faţă de
median, iar aproximativ 95% dintre puncte sunt la maxim
două abateri standard faţă de median.
 Distribuţiile normale sunt simetrice, având punctele mult
mai concentrate în mijloc faţă de margini. Aceste
distribuţii sunt caracterizate de doi parametri: medianul
(μ) şi abaterea standard (σ). O serie largă de tipuri de date
comportamentale sunt foarte bine aproximate de o
distribuţie normală.

 Foarte multe teste statistice folosesc distribuţia normală,

majoritatea acestora fiind bine evaluate chiar dacă
distribuţia reală este doar aproximativ normală sau nu
deviază extrem de mult de la normalitate.
(sursa: http://en.wikipedia.org/wiki/Normal_distribution)
 Formula unei distribuţii normale este:

− ( x−µ )2
1
f ( x) = e 2σ 2

2πσ 2

f(x) este foarte apropiat de 0 dacă x este la

mai mult de trei abateri standard faţă de
median.
 Pentru a echilibra din punct de vedere
computaţional o reţea de calculatoare folosind
abaterea pătratică medie şi abaterea standard,
putem aproxima încărcările computaţionale din
cadrul reţelei cu o distribuţie normală.
 Scopul este de a obţine, folosind algoritmi
genetici, o distribuţie a încărcărilor
computaţionale în care abaterea pătratică medie,
şi deci abaterea standard sunt minime. Când
acest scop este îndeplinit, putem spune că
reţeaua este echilibrată din punct de vedere
computaţional.
 Conceptual, algoritmii genetici sunt inspiraţi
din teoria evoluţionistă a lui Darwin, ideea
principală fiind supravieţuirea celui mai
puternic.
 Teoria lui Darwin poate fi aplicată în
contextul în care potenţialele soluţii sunt
văzute ca o serie de indivizi, cupluri de
inidivizi putând da naştere la noi copii, adică
la noi indivizi.
 Crearea unui nou individ este însoţită de
aplicarea operatorului crossover peste genele
părinţilor, genele acestora fiind astfel combinate.
În plus, prin aplicarea operatorului genetic de
mutaţie, genele noilor indivizi pot suferi uşoare
modificări.
 Ca şi în natură, această teorie se bazează pe
supravieţuirea celui mai puternic, cele mai bune
soluţii mergând mai departe, ţinându-se cont de
presupunerea că părinţii puternici au o mai mare
probabilitate de a avea copii puternici.
 Algoritmii genetici, dezvoltaţi de Holland în
anul 1975, au folosit un tip de reprezentare
independent de domeniu, şirurile de biţi (bit-
strings).
 Totuşi, foarte multe aplicaţii recente ale
algoritmilor genetici s-au focalizat pe alte
reprezentări cum ar fi grafuri (folosite pentru
reţele neuronale), expresii Lisp, liste
ordonate, vectori cu valori reale etc.
procedure GA {
t = 0;
generate population P(t);
evaluate P(t);
while (t < nrGenerations AND evolution >
threshold) {
t = t + 1;
parentSelection P(t);
recombine P(t);
mutate P(t);
evaluate P(t);
survive P(t);
}
}
 Pseudo-codul prezentat descrie un algoritm
genetic tipic.
 După iniţializare, părinţii sunt selectaţi
folosind o funcţie probabilistică de selecţie
bazată pe fitness-ul relativ al acestora. Cu
alte cuvinte, indivizii cu o valoare de fitness
ridicată au mai mari şanse de a fi selectaţi ca
părinţi.
 K copii sunt creaţi prin recombinarea genelor
de la K părinţi. Cei K copii sunt apoi expuşi
procesului de mutaţie, iar în etapa de
supravieţuire, aceştia îşi vor înlocui părinţii
(toţi sau doar o parte dintre aceştia) în noua
populaţie.
 În cazul algoritmilor genetici, accentul pus pe
operatorul crossover relativ la operatorul
mutaţie este invers faţă de cazul programării
evolutive.
 În cazul algoritmilor genetici, operatorul
mutaţie este aplicat cu o probabilitate redusă,
fiind des considerat un operator de
background, iar crossover-ul pe de altă parte,
este considerat a fi un operator esenţial.
 Agenţii mobili au posibilitatea de a se
transfera, luând cu ei atât codul cât şi starea
în care se află la un moment dat, pe un alt
host pentru a-şi continua execuţia.
 Acest comportament defineşte proprietatea
de mobilitate pe care agenţii mobili o oferă.
 De asemenea, agenţii mobili adresează şi
proprietatea de localitate, aceştia putând
colabora local în cadrul hosturilor prezente în
sistem.
 Deoarece agenţii mobili acţionează în mod
autonom şi sunt concretizaţi prin procese
paralele, aceştia pot furniza baza pentru
transferul modelelor vieţii artificiale în cadrul
calculatoarelor şi al reţelelor de calculatoare.
 În cadrul sistemului descris, tehnologia
agenţilor mobili este folosită împreună cu
algoritmii genetici pentru a obţine o
echilibrare descentralizată a încărcării
computaţionale din cadrul unei reţele de
calculatoare.
 Performanţele globale ale sistemului rezultă
tocmai din interacţiunea agenţilor mobili.
 Faţă de abordările centralizate, nu există nici
o problemă în ceea ce priveşte scalabilitatea,
deoarece agenţii autonomi furnizează o
soluţie total descentralizată, care se poate
adapta indiferent de dimensiunea sistemului,
prin reproducere şi migraţie.
 În plus, acest tip de abordare constituie baza
pentru sistemele cu un grad înalt de
adaptabilitate, deoarece ciclul de viaţă al
agenţilor mobili şi abilitatea acestora de a
migra în cadrul reţelei oferă posibilitatea de
ajustare dinamică în funcţie de necesităţi.
 Prin urmare, tehnologia agenţilor mobili este în
particular potrivită sistemelor dinamice de
dimensiuni mari.
 Mai mult, deoarece agenţii mobili sunt autonomi
(se pot executa fără a depinde de alţi agenţi),
sistemul bazat pe aceştia este foarte robust şi
tolerant la defecte.
 În timp ce defectarea unei componente centrale
din cadrul unui sistem centralizat va cauza
căderea întregului sistem, defectarea unui grup
de agenţi poate cauza, în cel mai rău caz, o
funcţionare cu eficienţă redusă a acestuia.
Curs 6
 Ţinând cont de problema mapării, avem un
spaţiu de căutare S de mărime …
 … NM şi N simboluri.

 Funcţia de fitness F : S → ℜ asociază o

valoare reală fiecărui punct din spaţiul de
căutare S.
 Un punct din S este reprezentat de o funcţie
de mapare particulară, astfel că spaţiul S este
acelaşi cu spaţiul M al funcţiilor de mapare
definit anterior.
 Fiecare individ este reprezentat de un
cromozom. În schema de codare a
cromozomilor, fiecare task este văzut ca o
genă.
 Alelele fiecărei gene sunt reprezentate de ...
 Cei mai buni indivizi sunt selectaţi (selection) şi
împerecheaţi (crossover), astfel rezultând noi
indivizi.
 În cadrul împerecherii a doi indivizi, procesoarele
asociate task-urilor dinaintea unui punct de
crossover rămân nemodificate, iar cele aflate
după punctul de crossover sunt interschimbate,
acest procedeu fiind repetat până ce toate
punctele de crossover sunt parcurse. Prin
urmare, rezultatul împerecherii a doi indivizi este
format din alţi doi noi indivizi (reproduction).
 În plus, o potenţială nouă soluţie poate fi
uşor modificată (mutation), acest lucru
concretizându-se prin faptul că un task poate
fi remapat la un alt procesor.

 Daca valorile funcţiei de fitness pentru un

grup de copii sunt mai bune decât cele ale
părinţilor, aceştia din urmă vor fi înlocuiţi de
copiii lor în noua generaţie (new population).
 Exemplu de codificare a unui individ
(cromozom) pentru un set de 3 procesoare şi
8 task-uri:

P1 – task 1, task 3, task 7

P2 – task 4, task 6, task 8
P3 – task 2, task 5

Cromozom (individ) = {1, 3, 1, 2, 3, 2, 1, 2}

 Se generează un set de indivizi care formează
populaţia iniţială. Operatorii genetici sunt
utilizaţi în faza de reproducere pentru a
genera noi puncte în spaţiul S din punctele
deja existente.

 Principiul fundamental al algoritmilor genetici

este următorul: cu cât un cromozom este mai
aproape de optim, cu atât este mai probabilă
reproducerea sa.
 Deoarece dimensiunea populaţiei este
menţinută constantă, vom avea o competiţie
pentru supravieţuire a indivizilor pentru noua
generaţie. Astfel, se generează o situaţie
Darwiniană: supravieţuirea celui mai puternic.
 Ultima fază în generarea unei noi populaţii
este faza de înlocuire (replacement). În
aceasta fază, indivizii cei mai slabi din
generaţia anterioară sunt înlocuiţi de indivizii
mai puternici care au rezultat în urma fazei
de reproducere. Procesul genetic este
reaplicat noii populaţii un anumit număr ori
(numărul de generaţii dorit).
 Generarea aleatoare a unei populaţii de indivizi
 Evaluarea populaţiei – calculul valorii funcţiei de
fitness pentru fiecare individ
 while number_of_generations <= max
◦ Selecţie – selectarea perechilor de indivizi care au cea
mai mare probabilitate de împerechere, indivizii cei mai
puternici fiind selectaţi mai frecvent
◦ Reproducere – aplicarea operatorilor genetici (crossover
şi mutaţie) perechilor selectate în pasul anterior
◦ Evaluare – calculul valorii funcţiei de fitness pentru
fiecare nou individ rezultat
◦ Înlocuire – formarea noii populaţii prin înlocuirea
indivizilor mai slabi din populaţia anterioară cu indivizii
mai puternici rezultaţi în urma procesului de
reproducere
 Operatorii genetici folosiţi în faza de
reproducere sunt operatorul crossover şi
operatorul mutaţie.
 În plus, doi parametri adiţionali Pc şi Pm sunt
definiţi, aceştia reprezentând probabilitatea
de aplicare a operatorilor de crossover,
respectiv mutaţie.
 Două scheme de secţie comune algoritmilor
genetici au fost luate în considerare:
◦ selecţia tip ruletă (roulette wheel selection)
◦ selecţia pe ranguri (rank selection)

 Ambele scheme selectează indivizii care vor

lua parte la procesul de împerechere.
 În algoritmul genetic discutat a fost aleasă
selecţia pe ranguri.
  Dacă fi reprezintă
fitness-ul individului i
din populaţie,
probabilitatea de a fi
selectat este:

unde N este numărul

total de indivizi din
populaţie.

(sursa: http://en.wikipedia.org/wiki/Roulette-wheel_selection)
 Cei mai buni indivizi rezultaţi din faza de
selecţie sunt împerecheaţi.
 Genele fiecărei perechi de părinţi sunt
combinate pentru a da naştere altor indivizi,
pentru fiecare pereche de părinţi rezultând
doi copii.
 Operatorul crossover este responsabil cu
combinarea genelor părinţilor.
 Acest operator generează aleator un set de
puncte de crossover, atât ca număr, cât şi ca
poziţie, urmând să efectueze combinarea
propriu-zisă.

 Toate perechile de părinţi sunt astfel

combinate pentru a forma noua populaţie.
 Operatorul mutaţie este aplicat aleator unui
set de noi indivizi, după un anumit număr de
generaţii, oferind posibilitatea de a explora
noi soluţii şi de a furniza un comportament
aleator în căutarea soluţiei optime.

 Folosirea mutaţiei evită posibila limitare a

spaţiului de căutare datorită minimelor locale.
 Mutaţia are loc după un anumit număr de
generaţii, acest număr putând fi furnizat ca
parametru de intrare în sistem.
 Obiectivul principal al mutaţiei este acela de a
schimba aleator un număr de gene.
 În plus faţă de mutaţia standard, sistemul
foloseşte un tip de mutaţie adaptiv care
modifică genele doar dacă fitness-ul soluţiei
optime nu se îmbunătăţeşte după un anumit
număr de generaţii.
 Rolul agenţilor mobili este acela de a realiza
echilibrarea încărcării sistemului distribuit
prin mutarea task-urilor între hosturile din
cadrul acestuia în funcţie de rezultatele
furnizate de algoritmul genetic.
 Mai mult, în sistemul prezentat, agenţii
mobili oferă paralelizarea algoritmului
genetic cât şi o proprietate specială de mărire
a vitezei de convergenţă a soluţiei acestuia.
 Populaţia iniţială este mapată pe un graf
conex de procesoare, mai mulţi indivizi pe
procesor.

 Vecinătăţile diferitelor populaţii de indivizi se

suprapun, de aici şi conceptul de
suprapunere de insule.
 Sistemul a fost conceput să implementeze
două faze cu privire la schimburile de
populaţii între nodurile reţelei care rulează în
paralel:
◦ o fază locală (se execută la nivelul insulei)
◦ o fază globală (se execută la nivel global, între
insule).
 Procesul de selecţie este realizat local, într-o
vecinătate a fiecărui set de indivizi. În această
fază, selecţia depinde doar de starea locală a
sistemului.
 Dimensiunea vecinătăţii este un parametru de
sistem care poate fi specificat. Pentru a evita
overhead-ul şi complexitatea algoritmilor de
rutare, sistemul foloseşte ca dimensiune a
vecinătăţii valoarea 1, adică se limitează doar
la procesoarele direct conectate.
 O altă motivaţie a fazei de selecţie locale este
o motivaţie biologică: în natură nu există
selecţie globală, selecţia naturală fiind un
fenomen local care are loc în mediul
înconjurător al indivizilor.
 Sistemul implementat foloseşte o topologie
de reţea de tip tor în care fiecare procesor are
4 vecini.

 Orice altă topologie poate fi folosită, fiecare

procesor putând avea un număr variabil de
procesoare vecine.
 În cazul considerat, rutarea comunicaţiilor în
reţeaua de procesoare nu este necesară în
timpul fazei locale de interschimbare a
populaţiilor deoarece doar procesoarele
direct conectate schimbă informaţii.
 O caracteristică importantă a sistemului este
aceea că nu se consideră cea mai bună soluţie
găsită global, deoarece costurile de
comunicaţie ar creşte considerabil.

 Prin urmare, sistemul consideră ”cea mai

bună soluţie” ca fiind cea mai bună soluţie
dintr-un subset de insule ales aleator.
 Agenţii mobili joacă un rol important în
procesul găsirii soluţiei optime.
 Aceştia sunt utilizaţi pentru schimburile de
populaţii la nivelul insulelor (faza locală), dar
mai important, agenţii mobili replică cei mai
buni indivizi de la nivelul insulelor în
subseturi de insule (generate aleator) din
cadrul sistemului, în acest fel oferind baza
unui schimb global calitativ (faza globală).
set elitismPercent
set mergeGenerations
set crossoverStrength
set mutationStrength
set migrationPercent
set nrExchangePhases

procedure run
for i=0 to generations/exchange phase
generate pairs of individuals from population (rank selection)
newPopulation = empty
for each pair
offspring = crossover pair (with crossoverStrength)
mutate offspring (with mutationStrength)
evaluate offspring
newPopulation += offspring
end for
elitismPopulation = retrieve elitism from population (with elitismPercent)
if mergeGenerations
population = elitismPopulation + merge(newPopulation, population - elitismPopulation)
else
population = elitismPopulation + newPopulation
end if
end for
end procedure
all torus processors perform in parallel
initialization phase
population = generate initial population
evaluate population
procedure run
GLOBAL sync phase
end initialization phase

for k=1 to nrExchangePhases

retrieve migration population (with migration percent)
GLOBAL exchange of migration populations between
neighbors
procedure run
GLOBAL sync phase
end for
retrieve solution
end
 Important: calitatea soluţiei şi costul
computaţional necesar găsirii soluţiei optime
sunt direct dependente de valorile furnizate
parametrilor de control.
 Figura prezintă o posibilă soluţie de mapare a 22 de task-uri la 6
procesoare.

 Numărul care apare între paranteze în cadrul nodului aferent

unui task reprezintă costul computaţional al acestuia.
 Numărul care apare între paranteze în cadrul nodului aferent
unui procesor reprezintă puterea de procesare a acestuia.
 Legăturile dintre task-uri reprezintă legături de comunicaţie între
acestea, iar numerele care apar deasupra acestor legături
reprezintă costurile de comunicaţie.
 Legăturile dintre procesoare reprezintă legături de comunicaţie
între acestea, iar numerele care apar deasupra acestor legături
reprezintă viteza de transfer a datelor pe aceste legături.
 Legăturile dintre task-uri şi procesoare reprezintă maparea
efectivă a task-urilor la procesoare.
 tor cu 225 de
procesoare dispuse
într-o matrice 15x15

CEL MAI BUN CROMOZOM DE PE TOR: Cromozom <fitness=0.0555>

[3, 5, 3, 3, 5, 6, 1, 5, 1, 6, 6, 4, 5, 4, 2, 1, 5, 1, 3, 3, 6, 5]
NOTĂ: valorile mai mici sunt mai bune.
NOTĂ: valorile mai mici sunt mai bune.
 Deşi neacceptarea clonelor duce la obţinerea
unor rezutate mai bune, calitatea soluţiei în
cadrul torului variază într-un interval destul de
mare.
 În cazul acceptării clonelor, chiar dacă rezultatele
nu sunt aşa de bune ca în cazul neacceptării
acestora, calitatea soluţiei variază într-un interval
mult mai restrâns. Cu alte cuvinte, abaterea
standard a calităţii soluţiei în cadrul torului este
mult mai mică în cazul acceptării clonelor decât
în cazul neacceptării acestora.
 Aşa cum s-a menţionat în secţiunile anterioare,
sistemul nu consideră cea mai bună soluţie
globală deoarece costurile de comunicaţie
necesare găsirii acesteia ar fi mult prea mari.
 Astfel, se consideră ”cea mai bună soluţie” ca
fiind cea mai bună soluţie dintr-un subset de
insule ales aleator.
 În concluzie, dacă acest tip de căutare a soluţiei
optime este preferat şi se doreşte un rezultat
consistent în cadrul mai multor rulări care să nu
varieze în limite mari, atunci ipostaza acceptării
clonelor este mai potrivită.
NOTĂ: valorile mai mici sunt mai bune.
 Pentru a aborda problema echilibrării
încărcării computaţionale şi de comunicaţie în
cadrul unui cluster de calculatoare, trei
tehnici au fost folosite împreună:
◦ algoritmii genetici pentru generarea soluţiilor de
mapare optime
◦ agenţii mobili pentru migrarea task-urilor şi
interschimbarea populaţiilor atât la nivel de insulă
cât şi la nivel global
◦ suprapunerea insulelor de procesoare care
defineşte conceptul de localitate la diferite
granularităţi
 Se pot lua în considerare suprafeţe insulare
de diferite dimensiuni. Mai mult, intersecţiile
insulelor (suprafeţele de suprapunere) pot fi
implementate cu dimensiuni diferite în cadrul
clusterului.
 Poate fi luată în considerare posibilitatea
variaţiei suprafeţelor insulelor şi a
suprafeţelor de suprapunere în timpul rulării.
 Ţinând cont de testele efectuate, s-a observat
că prin creşterea ratei de migraţie, a
suprafeţei insulelor sau a dimensiunii setului
de insule din faza globală de interschimbare a
populaţiilor, performanţele şi calitatea
soluţiilor algoritmului paralel se
îmbunătăţesc.
 Totuşi, creşterea acestor parametri peste
anumite praguri poate determina un overhead
semnificativ care poate conduce la scăderea
performanţelor sistemului.
Curs 7
 utilizate în faza de design a aplicaţiilor
enterprise

 un nou set de design patterns a fost adăugat

în momentul în care platformele enterprise au
oferit suport şi pentru servicii web
 Clasificare:
◦ Layerul de prezentare (Presentation Tier)

◦ Layerul de business (Business Tier)

◦ Layerul de integrare (Integration Tier)

 Cuprinde design patterns cu privire la
organizarea componentelor cu scopul de a
îmbunătăţi reutilizarea codului folosit la
prezentarea datelor în cadrul secţiunii client
din cadrul unei aplicaţii enterprise.
 Oferă abilitatea de a manipula:
◦ o cerere înainte de procesare
◦ un răspuns înainte de a fi trimis
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ centralizează preprocesarea cererilor
◦ centralizează postprocesarea răspunsurilor

 De folosit când este nevoie de:

◦ preprocesarea cererilor
◦ postprocesarea răspunsurilor
 Design pattern utilizat pentru a încapsula
detaliile interne ale diverselor implementări
de protocoale cu scopul de a putea fi
refolosite.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje
◦ îmbunătăţeşte reutilizarea şi mentenanţa
◦ asigură portabilitatea codului între sistemele de
operare

 De folosit când:
◦ componentele au nevoie de acces la informaţii de
sistem
◦ este nevoie de decuplarea aplicaţiei de protocoalele
utilizate cât şi de interfeţele de sistem
 Oferă un punct central de control al cererilor
din layerul de prezentare.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ centralizează logica de control
◦ îmbunătăţeşte reutilizarea codului
◦ îmbunătăţeşte separarea tipurilor de servicii

 De folosit când este nevoie de:

◦ aplicarea unei logici comune mai multor cereri
◦ separarea view-urilor de logica de procesare
 Diferenţa faţă de Intercepting filter:
◦ ...
 Diferenţa faţă de Intercepting filter:
◦ Front controller determină execuţia procesării în
funcţie de cerere
◦ Intercepting filter modifică cererea

 Poziţionare Intercepting filter relativ la Front

controller:
◦ ...
 Centralizează achiziţia şi invocarea
componentelor ce realizează procesarea
cererilor.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ îmbunătăţeşte extensibilitatea
◦ îmbunătăţeşte separarea tipurilor de servicii

 De folosit când:
◦ aplicarea unei logici comune de control
◦ este nevoie de un management centralizat al view-
urilor
 Separă view-ul de logica de procesare
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ separă view-ul de logica de procesare

 De folosit când se doreşte:

◦ încapsularea logicii de procesare aferentă view-
urilor
 Combină view-uri simple în view-uri
complexe fără a modifica conţinutul sau
dispunerea acestora.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ duplicarea codului este redusă datorită părţilor
comune: headers, footers şi alte componente
◦ modificarea view-urilor în funcţie de autorizare

 De folosit când:
◦ se doreşte dezvoltarea unui set comun de
componente de tip view
◦ view-urile se modifică în funcţie de drepturile de
acces
 Execută cererea şi generează un răspuns
utilizând o procesare tip business limitată.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ separă view-ul de logica de procesare
◦ îmbunătăţeşte reutilizabilitatea

 De folosit când:
◦ aplicaţia conţine view-uri statice
◦ procesarea tip business este limitată
 Analizează cererea şi execută serviciile de tip
business logic înainte de a transmite
controlul către view.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ îmbunătăţeşte separarea tipurilor de servicii

 De folosit când se doreşte:

◦ centralizarea business logic pentru cereri
Curs 8
 Cuprinde design patterns care ajută la
decuplarea business logic de layerul de
prezentare şi de resurse.
 Ascunde complexitatea interacţiunii cu
componentele remote de tip business de
layerul de prezentare în care rulează clientul.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ decuplează aplicaţiile client de serviciile business
◦ ascunde comunicaţiile remote
◦ îmbunătăţeşte performanţele

 De folosit când se doreşte:

◦ încapsularea accesului la serviciile business de la
mai multe tipuri de clienţi
◦ maparea excepţiilor în excepţii de tip aplicaţie
◦ ascunderea detaliilor de creare şi comunicare cu
serviciile remote business
 Oferă o abordare consistentă asupra
localizării componentelor business indiferent
de tipul acestora.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ standardizează modalitatea de regăsire a
componentelor business

 De folosit când:
◦ sunt accesate diverse servicii business care
presupun modalităţi diferite de localizare
 Oferă o faţadă cu granularitate mărită a
componentelor business pentru clienţii
remote.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ reduce numărul de invocări remote pe componentele
business din partea clienţilor
◦ decuplează layerele de prezentare şi business
◦ îmbunătăţeşte performanţele datorită reducerii
numărului de invocări de granularitate scăzută din
partea clienţilor
◦ furnizează un API mult mai curat aplicaţiei client

 De folosit când:
◦ mai multe invocări din partea clientului pot fi grupate
într-o singură invocare de granularitate mărită
 Design pattern care centralizează şi
înglobează componente business.
 Poate fi văzut ca un helper pentru Session
facade care se ocupă cu executarea logicii de
business şi a workflow-ului.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ centralizează şi îmbunătăţeşte reutilizarea business
logic
◦ simplifică Session facade prin eliminarea business
logic de la nivelul acesteia

 De folosit când:
◦ încep să apară secvenţe de cod duplicate la nivelul
Session facade
 Separă datele şi mecanismele de persistenţă a
datelor de business logic.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ separă mecanismele de persistenţă a datelor de
business logic

 De folosit când:
◦ se doreşte a creşte gradul de reutilizabilitate a
business logic
 Înglobează mai multe entităţi business într-o
singură entitate de granularitate mărită.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ îmbunătăţeşte mentenanţa
◦ îmbunătăţeşte performanţele de transfer a datelor
în reţea

 De folosit când se doreşte:

◦ evitarea accesării entităţilor de date remote
◦ folosirea BMP (Bean Managed Persistence) cu
mecanisme de persistenţă custom
◦ încapsularea obiectelor business de tip POJO
 Defineşte un obiect de transfer de date între
layere.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ reduce traficul în reţea
◦ reduce duplicarea codului

 De folosit când:
◦ este nevoie de a trimite obiecte ce reprezintă
(parţial sau total) entităţi persistente între layere
 Construieşte obiecte de transfer de date
compuse şi le returnează clientului.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ îmbunătăţeşte performanţele de transfer a datelor
în reţea

 De folosit când:
◦ există mai multe obiecte de transfer de date care
sunt trimise între layere
 Menţine rezultatele în cache şi pune la
dispoziţia clientului modalităţi de traversare
şi accesare a acestora.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ rezultatele sunt menţinute în cache
◦ îmbunătăţeşte performanţele reţelei
◦ îmbunătăţeşte separarea tipurilor de servicii

 De folosit când se doreşte:

◦ accesarea rezultatelor prin iteratori
◦ implementarea de liste read-only fără suport pentru
tranzacţii
 Cuprinde design patterns care au ca scop
izolarea layerului de business logic de
sistemele externe şi de bazele de date.
 Încapsulează accesul la bazele de date
persistente şi realizează managementul
conexiunilor cu acestea.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ reduce complexitatea de cod de la nivelul clientului
◦ îmbunătăţeşte reutilizarea codului
◦ oferă o migrare mult mai uşoară la alt sistem de
baze de date

 De folosit când se doreşte:

◦ decuplarea accesului la date de business logic
◦ ca accesul datelor să se facă într-un layer separat
 Face managemenul cererilor asincrone asupra
componentelor business.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ clientul îşi poate continua procesarea
◦ integrează JMS (Java Message Service) în aplicaţie

 De folosit când:
◦ este nevoie de invocarea unui serviciu business în
mod asincron
 Separă persistenţa unui obiect de modelul
obiect.
 Utilizat în special în cadrul framework-urilor
ORM (Object Relational Model).
 Folosit în paralel cu Data access object.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ decuplează logica de business de logica de
persistenţă

 De folosit când:
◦ nu se doreşte folosirea bean-urilor de tip entitate
◦ utilizarea modelului obiect este complexă
 Expune şi intermediază serviciile business
utilizând XML şi protocoale web.
(sursa: Sun Certified Enterprise Architect for Java EE Study Guide, Second Edition, 2010)
 Avantaje:
◦ expune serviciile business pentru a fi accesate ca
servicii web

 De folosit când:
◦ este nevoie de a accesa serviciile business ca
servicii web
Curs 9
 Problemă:
◦ un client enterprise trebuie să execute logică tip
business pentru a completa un use-case
◦ use-case-ul trebuie să se execute într-o singură
tranzacţie şi într-o singură invocare în reţea
 Context:
◦ execuţia unui use-case presupune accesarea mai
multor obiecte (servicii/entităţi persistente) la
nivelul serverului
◦ accesarea directă de tipul fine-grained calls:
 adaugă un overhead datorită multiplelor invocări în
reţea
 codul care implementează business logic la nivelul
clientului este mult mai greu de reutilizat şi de
întreţinut
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
 Anti-pattern: crearea unei singure faţade care
implementează o gamă variată de use-case-
uri
 Soluţie: use-case-urile vor fi grupate şi
implementate în faţade diferite în funcţie de
specificul acestora
 Anti-pattern: logică de domeniu în faţadă
 Soluţie:
◦ un model de domeniu bine proiectat trebuie să
conţină toată logica necesară implementării
diferitelor use-case-uri
◦ faţadele pot conţine logică de domeniu doar dacă
aceasta implică lucrul cu entităţi de domeniu
diferite care nu au o legătură directă
 Anti-pattern: prezenţa unor secvenţe de
business logic duplicate
 Soluţie:
◦ refactorizarea layerului de faţade
◦ extragerea secvenţelor de business logic duplicate
(independente de use-case) într-un layer separat de
servicii
 Avantaje:
◦ overhead mic în reţea
◦ separarea clară a layerului de prezentare de
business logic
◦ integritate tranzacţională
◦ reutilizabilitate
◦ mentenanţă crescută
◦ separare tip verb-substantiv
 use-case-uri – verbe
 entităţi persistente - substantive
 Problemă:
◦ un client enterprise trebuie să execute logică tip
business pentru a completa un use-case fără a
necesita un răspuns imediat
◦ use-case-ul trebuie să se execute într-o singură
tranzacţie şi într-o singură invocare în reţea fără a
necesita un răspuns imediat
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
 Avantaje faţă de Session facade:
◦ se execută asincron
◦ execuţia este garantată (fault-tolerant)
◦ timp de răspuns imediat
◦ se elimină punctele singulare de defecte
 Dezavantaje:
◦ parametri de intrare weakly typed
◦ nu există valori de return
◦ nu există mecanism de propagare a excepţiilor
datorită naturii asincrone
 Problemă:
◦ un client enterprise trebuie să execute logică tip
business pentru a completa un use-case
◦ use-case-ul trebuie să se execute într-o manieră
lightweight, prin decuplarea clientului de server,
într-o singură tranzacţie şi într-o singură invocare
în reţea
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
 Părţi componente:
◦ command beans – clase POJO cu metode de tip set
şi get + o metodă execute() ce conţine business
logicul necesar pentru execuţia unui use-case
◦ logică de rutare la nivelul clientului – presupune
trimiterea comenzilor către server şi recepţionarea
răspunsului
◦ serviciu de tip stateless session bean ce acceptă şi
execută comenzi la nivelul serverului
 Avantaje:
◦ dezvoltarea rapidă de prototipuri de aplicaţii
◦ separarea logicii de prezentare de logica de
business
◦ presupune o singură invocare în reţea
◦ decuplează clientul de server
◦ se pot executa local şi pot produce date fictive în
cazul în care implementarea la nivelul serverului nu
este încă funcţională
 Dezavantaje:
◦ sunt stateless
◦ mecanism de tratare a erorilor limitat la o singură
excepţie generală datorită naturii generice a
serviciului ce preia comenzile la nivelul serverului
 excepţiile originale pot fi încapsulate în cadrul
excepţiei generice
◦ explozie de obiecte de comandă în proiecte mari
◦ duplicarea codului
◦ serviciul generic de preluare a comenzilor cuplat cu
serviciile de tratare a comenzilor
Curs 10
 Problemă:
◦ un client trebuie să transfere mai multe date către
şi de la server
◦ use-case-ul trebuie să se execute evitând mai
multe invocări în reţea
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
 Avantaje:
◦ o singură invocare în reţea pentru a transmite date
multiple
◦ obiectele de transfer de date pot fi folosite atât
pentru citire cât şi pentru scriere
◦ datele sunt încapsulate la nivelul obiectelor de
transfer de date
◦ obiectele de transfer de date pot fi concepute la
orice granularitate
◦ obiectele de transfer de date pot conţine şi alte
date decât cele din domeniului de date
 Problemă:
◦ layerul de DTO-uri necesită schimbări dese
◦ trebuie găsită o modalitate de a crea şi manipula
DTO-uri pentru a minimiza impactul schimbărilor
dese asupra sistemului
 Context:
◦ fiecare use-case necesită propriile DTO-uri la
granularităţi diferite
◦ layerul de DTO-uri poate exploda în sute sau mii de
obiecte în funcţie de complexitatea aplicaţiei
◦ logica de creare şi manipulare a DTO-urilor trebuie
decuplată de domeniul de date
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
(sursa: EJB Design Patterns. Advanced Patterns, Processes, and Idioms)
 Avantaje:
◦ separă logica de creare şi consumare a DTO-urilor de
business logic
◦ separă domeniul de date de datele necesare fiecărui use-
case în parte
◦ îmbunătăţeşte mentenanţa
◦ nu poluează domeniul de date
◦ îmbunătăţeşte performanţele prin încapsularea datelor într-
un singur call în reţea
◦ factory-ul poate fi conceput să contruiască orice tip de
DTO-uri şi la orice granularitate
◦ suportă construirea unor grafuri complexe de DTO-uri în
funcţie de necesităţi
◦ se recomandă gruparea logicii aferente construirii şi
manipulării DTO-urilor în mai multe factory-uri diferite în
funcţie de use-case-uri
 Problemă:
◦ un client iniţiază un update în server pe baza unor
date recepţionate într-o tranzacţie anterioară
◦ la momentul update-ului, datele care au stat la
baza modificărilor pot să nu mai fie de actualitate
◦ cum se poate determina şi rezolva această situaţie?
 Exemplu:
1. Userul A citeşte Entitatea X într-o tranzacţie
2. Userul B citeşte Entitatea X într-o tranzacţie
3. Userul A modifică local Entitatea X
4. Userul B modifică local Entitatea X
5. Userul A actualizează Entitatea X într-o tranzacţie
6. Userul B actualizează Entitatea X într-o tranzacţie
 Soluţie:
◦ folosire versioning pentru a detecta situaţiile în care
datele de la client nu mai sunt de actualitate
◦ versioning – implementat în general folosind o
variabilă de tip integer cu scopul de a identifica
starea unei entităţi la un moment dat
◦ variabila de versioning va fi incrementată de fiecare
dată când se modifică entitatea aferentă
 Paşi:
◦ transmiterea variabilei de versioning către client
împreună cu datele utile în cadrul DTO-urilor
◦ la actualizare, variabila de versioning este trimisă
înapoi către server împreună cu datele modificate
◦ dacă variabila de versioning de la server
corespunde cu cea primită de la client în cererea de
actualizare atunci se aplică modificările şi se
incrementează variabila de versioning
◦ în caz contrar, cererea de actualizare este bazată pe
date care nu mai sunt actuale, aceasta fiind
refuzată
Curs 11
 Într-o aplicaţie distribuită muti-tier,
transferurile de date au loc între toate
layerele, reprezentând un punct critic care
poate afecta în mod dramatic performantele
de ansamblu ale întregii aplicaţii.
 Arhitectura multi-tier a dus la apariţia unei
serii de design patterns cu privire la
transferurile de date, de la cache-uri simple
la structuri de date dedicate.
 Logica de business este împărţită între
diverse componente, care în funcţie de rolul
pe care îl au pot rula pe calculatoare diferite
şi în layere diferite.
 O aplicaţie distribuită tipică este formată din
următoarele secţiuni:
◦ secţiunea Client – conţine componente care rulează
pe calculatoarele client
◦ secţiunea Web – conţine componente care rulează
în cadrul serverelor front-end
◦ secţiunea Business – conţine componente care
rulează în cadrul serverelor de aplicaţii enterprise
◦ secţiunea Enterprise Information System (EIS) –
conţine componente care rulează în cadrul
serverelor EIS
 O aplicaţie enterprise distribuită poate fi alcătuită
din trei sau patru secţiuni.
 În general, secţiunile Web şi Business sunt
instalate pe aceleaşi servere.
 Prin urmare o aplicaţie multi-tier tipică este în
general considerată a fi alcătuită din trei secţiuni
(three-tier), deoarece este distribuită peste trei
locaţii diferite:
◦ calculatoarele client
◦ calculatoarele server
◦ calculatoarele de baze de date şi/sau calculatoarele
legacy în partea de back-end.
 Aplicaţiile three-tier extind vechea arhitectură
two-tier client-server prin inserarea unui
server de aplicaţii multi-thread între
aplicaţiile client şi datele stocate de back-
end.
 În orice aplicaţie distribuită există în general
două motive pentru care clientul
interacţionează cu serverul:
◦ pentru a prelua date de la server şi a le afişa
◦ pentru a modifica datele din partea de server prin
inserări, actualizări sau ştergeri
 În cazul în care cantităţi masive de date trebuiesc
transferate, acestea pot fi furnizate sub forma
unor parametri către metodele ce urmează a fi
executate (în cazul în care clientul trimite date
către server), sau prin execuţii de metode de
granularitate mică (în cazul în care clientul preia
date de la server).
 Prima opţiune poate scăpa rapid de sub control
în momentul în care se lucrează cu un număr
foarte mare de parametri, iar a doua opţiune
poate avea un impact negativ semnificativ asupra
performanţelor.
 În acest context, o serie de design patternuri
care tratează problema transferului de date
între layerele unei aplicaţii distribuite au fost
dezvoltate.
 Aceste design patternuri sugerează ideea de
a crea clase Java care vor oferi suportul
necesar pentru a construi aşa numitele
obiecte de transfer de date care vor încapsula
toate datele necesare în cadrul unei singure
comunicări în reţea.
 Un obiect de transfer de date (DTO)
reprezintă o instanţă a unei clase Java
serializabile care încapsulează un snapshot al
unui set de date din partea de server la un
moment dat.
 Obiectele de transfer de date pot fi folosite
atât pentru operaţiuni de citire cât şi de
actualizare a datelor într-un sistem distribuit.
 Antipattern:
◦ Informaţiile de actualizare ar putea fi trimise serverului
prin intermediul parametrilor metodelor, dar această
abordare este descurajată deoarece de fiecare dată când
informaţiile necesită modificări (datorită evoluţiei
proiectului), numărul şi tipul parametrilor se vor schimba
în conformitate, declanşând schimbări în semnăturile
metodelor.
◦ Acest efect de cascadă nu se opreşte aici, porţiuni
semnificative din cod trebuind a fi modificate şi
recompilate atât pe partea de client cât şi pe partea de
server. Acest lucru la rândul lui declanşează
incompatibilităţi cu versiunile mai vechi ale aplicaţiei.
 Prin încapsularea informaţiilor într-un DTO,
toate schimbările necesare sunt izolate la
nivelul DTO-ului şi a clasei Java
corespunzătoare.
 Obiectele de transfer de date sunt cel mai des
întrebuinţate pentru operaţiuni de citire.
Când un client necesită citirea unui set de
date de pe server (de obicei cu scopul de a
popula interfaţa grafică), utilizând abordarea
încapsulării datelor în interiorul DTO-urilor,
clientul poate recepţiona toate informaţiile de
care are nevoie folosind doar o singură
comunicaţie în reţea.
 Obiectele de transfer de date sunt practic
containere de date dependente de tip,
folosite pentru a transporta orice fel
informaţii între layerele unei aplicaţii
distribuite enterprise.
 Noţiunea de a transfera copii ale datelor din
partea de server între secţiunile unei aplicaţii
distribuite poate fi foarte confuză pentru
programatorii ne-experimentaţi în domeniul
aplicaţiilor distribuite, deoarece nu există o
paradigmă similară în lumea aplicaţiilor non-
distribuite.
 O problemă comună de care se lovesc
dezvoltatorii aplicaţiilor distribuite când
folosesc obiecte de transfer de date este
alegerea unei granularităţi optime, altfel
spus, care este cantitatea de date pe care un
DTO ar trebui să o încapsuleze, şi în ce punct
decizia de a folosi DTO-uri trebuie luată.
 Ca şi modalitate primară de schimb de date
între client şi server, obiectele de transfer de
date constituie o parte a interfeţei care separă
dezvoltatorii din partea de client de
dezvoltatorii din partea de server.
 La începutul proiectului, dezvoltatorii din
partea de client şi din partea de server trebuie
să cadă de comun acord asupra design-ului
obiectelor de transfer de date cam la acelaşi
moment în care trebuie să decidă şi ce
interfeţe ale serviciilor urmează să folosească.
 Design-ul obiectelor de transfer de date la
începutul proiectului poate fi dificil deoarece
dezvoltatorii deseori nu înţeleg pe deplin ce
unităţi de date trebuiesc transferate între
client şi server.
 O cale uşoară de a începe design-ul
obiectelor de transfer de date este de a copia
design-ul entităţilor de domeniu din partea
de server.
 Design-ul obiectelor domeniu de transfer de
date este uşor, deoarece echipele din proiect
au în general o idee bună despre cum arată
modelul de domeniu care urmează a fi
utilizat, aceste cerinţe fiind stabilite încă din
fazele iniţiale de dezvoltare ale unui proiect.
 Deşi această metodă de design al obiectelor
de transfer de date funcţionează bine la
începuturile unui proiect, pe măsură ce acesta
evoluează, clienţii enterprise ajung deseori să
necesite un acces la date cu o granularitate
mult mai fină decât cea prevăzută iniţial.
 În cele din urmă, datele schimbate între client
şi server trebuie să se potrivească cu nevoile
clientului.
 Prin urmare, pe măsură ce proiectul
evoluează şi nevoile clienţilor se finalizează,
obiectele domeniu de transfer de date deseori
devin neadecvate ca şi unităţi de schimb,
fiind de o granularitate mult prea mare
pentru a fi potrivite cerinţelor de granularitate
fină ale clientului.
 Un client poate avea nevoie de date care pur
şi simplu nu sunt încapsulate de nici un
obiect domeniu de transfer de date.
 În acest punct, dezvoltatorii pot trece la
design-ul unor obiecte custom de transfer de
date care nu sunt altceva decât obiecte de
transfer de date care încapsulează seturi
arbitrare de date şi a căror structură depinde
integral de nevoile particulare ale clientului.
 Diferenţele dintre aceste două paradigme de
design:
◦ DTO-uri mapate pe domeniu
◦ DTO-uri custom
pot avea un impact semnificativ asupra
design-ului întregii aplicaţii.
 Deşi reprezintă abordări contradictorii,
acestea pot coexista şi de obicei coexistă în
orice aplicaţie enterprise.
 deseori acest model de DTO-uri nu se aliniază
bine nevoilor clientului.
 interfeţe grafice diferite pot necesita seturi de
date diferite care pur şi simplu nu se mapează
peste containerele de date pe care DTO-urile
mapate pe domeniu le oferă.
 un client poate cere doar câteva dintre
numeroasele atribute ale unei entităţi
persistente.
 utilizarea unui DTO de domeniu pentru a
transfera toate atributele către client când doar
câteva sunt necesare reprezintă o risipă de
resurse de reţea.
 Acest model nu suferă de neajunsurile
menţionate anterior, dar la rândul său
introduce alte neajunsuri.
 În mod tipic, un nou DTO este scris pentru
fiecare use-case nou apărut în sistem, oferind
clientului un container pentru a transfera
doar datele care sunt cerute în cadrul noului
use-case.
 În ciuda simplicităţii acestei abordări, folosirea
DTO-urilor în această manieră suferă de multiple
neajunsuri:
◦ Utilizând acest pattern, o aplicaţie tipică enterprise
distribuită va prezenta o proliferare de DTO-uri custom,
aşa de multe încât deseori dezvoltatorii vor fi dispuşi să
accepte DTO-uri cu o granularitate mai mare (care pot
conţine mai multe atribute decât este necesar) decât să
scrie noi DTO-uri custom. Atâta timp cât nu sunt
returnate prea multe date în exces, această abordare
este viabilă. Prin urmare, rămâne la latitudinea
dezvoltatorilor să echilibreze preocupările legate de
întreţinere versus performanţe.
 DTO-urile custom sunt în general folosite pentru
operaţiuni read-only specifice interfeţelor grafice
cu utilizatorul şi sunt imutabile.
 Deoarece aceste DTO-uri custom sunt simple
containere care nu reprezintă obiecte business
din partea de server, potenţialele modificări
asupra acestora nu îşi au sensul.
 În mod tipic, actualizările sunt făcute prin
intermediul DTO-urilor mapate pe domeniu
(deoarece acestea reprezintă obiecte business
reale şi pot încapsula logică de validare) sau prin
intermediul unor metode specifice de use-case.
 Cost ridicat de modificare în timp:
◦ pe parcursul dezvoltării unei aplicaţii enterprise, use-
case-urile existente pot suferi modificări în paralel cu
apariţia de noi use-case-uri. Clienţi diferiţi pot avea
nevoie să acceseze sub-seturi de date diferite din partea
de server, sub-seturi care nu au fost iniţial cuprinse în
cadrul aplicaţiei.
◦ folosind abordarea DTO-urilor custom, este necesară
scrierea de cod suplimentar pe partea de server (cum ar
fi cod pentru noile DTO-uri şi pentru logica de
construire aferentă acestora) pentru a satisface noile
nevoi de acces la date ale clienţilor.
◦ odată ce un proiect a fost lansat, accesul la programatori
pentru partea de server tinde să devină scump, la fel ca
şi procesul de redepoyment al aplicaţiei.
 Nevoia de a construi un layer de obiecte de
transfer de date:
◦ DTO-urile custom constituie un nou layer care poate
exploda în mii de obiecte în cazul unor aplicaţii mari. Să
ne imaginăm un sistem distribuit în care fiecare domeniu
are ataşat un DTO de domeniu pentru a transfera datele
către şi dinspre secţiunea client. Use-case-urile
aplicaţiei pot necesita ca datele din aceste domenii să fie
împărţite în mai multe DTO-uri custom.
◦ prin urmare, un sistem de dimensiune medie poate
necesita sute de DTO-uri, fiecare dintre acestea având o
metodă aferentă de construire în partea de server.
◦ în cadrul aplicaţiilor mari, layerul de DTO-uri custom se
poate dovedi a fi foarte dificil de întreţinut.
 Interfeţele grafice de la client sunt cuplate cu
partea de server:
◦ în cazul utilizării DTO-urilor custom, fiecare
interfaţă grafică client este strâns legată de DTO-ul
pe care îl foloseşte pentru a se popula.
◦ în momentul în care DTO-ul custom este modificat,
codul client trebuie reactualizat pentru a ţine seama
de modificările apărute.
 Acest pattern oferă o alternativă la obiectele
de transfer de date, alternativă care
decuplează datele care sunt transferate de
obiectul care le încapsulează, menţinând în
acelaşi timp accesul şi transferul datelor între
secţiuni în cadrul unei singure comunicaţii în
reţea.
 Acest pattern reuşeşte să depăşească
neajunsurile pattern-urilor discutate anterior,
dar introduce noi neajunsuri.
 Nevoia de a menţine un contract pentru
cheile atributelor:
◦ în timp ce numele şi tipul atributelor sunt hard-
coded în numele metodelor din cadrul DTO-urilor
clasice, în cazul HashMap partea de client şi partea
de server trebuie să menţină un contract separat
pentru cheile şi tipurile atributelor, creându-se
astfel o dependenţă în plus între client şi server.
 Pierderea ”tipurilor puternice”(strong typing) şi a
verificărilor din faza de compilare (compile-time
checking):
◦ în cazul utilizării DTO-urilor clasice, valorile manipulate
de către metodele de tip setter/getter sunt întotdeauna
verificate şi corecte din punct de vedere al tipului
acestora, orice fel de erori fiind detectate în faza de
compilare.
◦ prin contrast, în cazul utilizării HashMap-urilor, valorile
manipulate nu pot fi verificate din punct de vedere al
tipului la compilare, clientul fiind forţat să apeleze atât
la folosirea operatorilor de cast la runtime cât şi la
menţinerea unei asocieri corecte între cheile atributelor
şi tipul acestora.
 Primitivele trebuiesc încapsulate:
◦ atributele de tip primitivă nu pot fi stocate într-un
map deoarece primitivele nu reprezintă subclase ale
clasei Object în Java.
◦ prin urmare, primitivele trebuiesc încapsulate într-
un obiect corespunzător înainte de inserarea
propriu-zisă în cadrul HashMap-ului.
 Operatorul de cast cerut la fiecare citire:
◦ de fiecare dată când valorile atributelor sunt
preluate din HashMap, acestea trebuiesc convertite
de la tipul Object la tipul corespunzător atributelor
pe care le reprezintă.
 Cei mai mulţi dezvoltatori preferă să
folosească abordarea DTO-urilor clasice.
Aceştia au înţeles foarte bine modul de
utilizare a DTO-urilor şi este foarte dificil
pentru programatorii din partea de client să
facă greşeli în acest context.
 Abordarea transferului de date folosind
HashMap-uri reprezintă o sabie cu două
tăişuri care rezolvă multe probleme de
întreţinere dar pe de altă parte, nefolosită
corect, poate introduce probleme grave
asupra coerenţei datelor şi asupra aplicaţiei în
general.
Curs 12
 metodă eficientă pentru transferul de date
între layerele aplicaţiilor distribuite enterprise
 obiectele lightweight polimorfice folosesc:
◦ buffere interne
◦ logică de lazy-loading
◦ grupuri lazy-load definite la runtime
 oferă performanţe superioare faţă de design
pattern-urile clasice care tratează transferul
de date între layere
 într-o aplicaţie distribuită enterprise,
transferurile de date au loc între toate
layerele, reprezentând un punct critic care
poate afecta în mod dramatic performantele
de ansamblu ale întregii aplicaţii.
 deşi complexitatea de design a pattern-ului
propus este mult mai mare decât cea a design
pattern-urilor discutate în cursurile
anterioare, acesta reuşeşte să depăşească
toate neajunsurile acestora
 mai mult, această nouă abordare prezintă un
design care înglobează toate beneficiile
design pattern-urilor discutate pe lângă
faptul de a introduce noi beneficii
 Structurile de date ale modelului de domeniu
sunt replicate la client în cadrul unei singure
comunicaţii în reţea:
◦ copii ale domeniului pot fi asamblate pe server şi
trimise la client folosind doar o singură comunicaţie
în reţea
◦ clientul poate apoi accesa local obiectele de transfer
de date şi poate executa operaţiuni de citire şi
actualizare asupra acestora fără a mai utiliza
resursele reţelei
◦ pentru actualizarea propriu-zisă la nivelul
serverului, clientul poate transmite obiectul de
transfer de date actualizat înapoi la server
 Design pattern uşor de folosit şi de înţeles
atât de către dezvoltatorii din partea de client
cât şi de cei din partea de server.
 Oferă suport pentru validarea sintactică a
atributelor la nivelul clientului:
◦ validarea sintactică a atributelor de domeniu poate fi
făcută la nivelul clientului prin încapsularea logicii de
validare în interiorul metodelor de tip setter din cadrul
obiectelor domeniu de transfer de date
◦ acest lucru permite ca erori legate de editarea sau
crearea de domenii să fie detectate direct la client
comparativ cu abordarea trimiterii obiectelor la server
doar pentru a recepţiona excepţii de validare
◦ bineînţeles că verificările semantice/validările business
ale atributelor urmează a fi efectuate în cele din urmă,
iar acest lucru în general nu poate fi făcut decât pe
partea de server
 Întreţinere excelentă. Este eliminat complet
layerul de obiecte custom de transfer de date:
◦ codul din partea de partea de server care trebuia
scris pentru a genera DTO-uri custom peste
domenii este eliminat
◦ prin urmare, explozia de DTO-uri custom peste
domenii nu mai prezintă o problemă, oferindu-se
astfel o potenţială reducere a codului cu mii de linii,
complexitatea acestuia scăzând foarte mult
 Ideal pentru interfeţe grafice dinamice:
◦ permite schimbarea comportamentului de cache al
bufferelor interne on-fly prin modificarea grupurilor
lazy-load la runtime
◦ prin urmare, interfeţele grafice dinamice nu suferă
nici o diminuare a performanţelor aşa cum se
întâmplă în cazul abordărilor clasice, de la nivelul
serverului fiind preluate doar datele strict necesare
aplicaţiei client
 Cost scăzut de întreţinere în timp:
◦ noi sub-seturi de date de date pot fi definite la
runtime fără a necesita în nici un fel modificarea
codului de la nivelul serverului, clienţii având
posibilitatea de a decide în mod dinamic
componenţa containerelor
 Prezintă o caracteristică importantă:
polimorfismul obiectelor de transfer de date:
◦ cu alte cuvinte un DTO poate să se transforme la
runtime, prin intermediul logicii de lazy-load (de
asemenea definită la runtime), într-un DTO de
domeniu sau într-un DTO custom, la orice
granularitate peste domeniul pe care îl reprezintă
 Comunicaţii reduse între secţiuni:
◦ asigură faptul că numai datele cu adevărat necesare
sunt transferate între secţiunile aplicaţiei distribuite
 Suportă DTO-uri care pot fi
modificate/actualizate chiar şi în cazul DTO-
urilor custom peste domenii:
◦ o componentă specială a fost concepută în partea
de server pentru a examina în mod transparent
bufferele interne ale DTO-urilor (custom sau nu) şi
a face actualizările necesare la nivelul serverului
 Prezintă un control total asupra granularităţii
DTO-urilor.

 Nu se pierd verificările din faza de compilare

(aşa cum se întâmpla în cazul design pattern-
ului Data Transfer HashMap).

 Mai mult, nu este necesară folosirea nici unui

operator de cast.
 Scopul principal al bufferelor interne este
acela de a reduce comunicaţiile între
secţiunile unei aplicaţii distribuite,
maximizând în acest fel performanţele
întregii aplicaţii enterprise.
 În spatele bufferelor interne se află un
mecanism de caching:
◦ odată ce un atribut a fost preluat este stocat în
buffer-ul de date intern, un nou acces asupra
aceluiaşi atribut fiind onorat direct din buffer fără a
mai fi necesare noi comunicaţii între secţiuni
procedure retrieveField(DTO, fieldName)
if useBuffers
if isBuffered(DTO, fieldName)
// access buffer
fieldValue = getBufferedFieldValue(DTO, fieldName)
else
// update buffer
fieldValue = call procedure remoteServerRequest(DTO, fieldName)
setBufferedFieldValue(DTO, fieldName, fieldValue)
end if
else
fieldValue = call procedure remoteServerRequest(DTO, fieldName)
end if
return fieldValue
end procedure

procedure remoteServerRequest(DTO, fieldName)

connect to SERVER
call remote procedure getFieldValue(DTO, fieldName) // involves serialization
receive fieldValue // involves result deserialization
return fieldValue
end procedure
remote procedure getFieldValue(DTO, fieldName)
if useServerCache
// check server internal cache
if isInServerCache(DTO, fieldName)
// access server cache
fieldValue = getCachedFieldValue(DTO, fieldName)
else
// update cache
fieldValue = call remote procedure interogateRDBMSServer(DTO, fieldName)
setCachedFieldValue(DTO, fieldName, fieldValue)
end if
else
fieldValue = call remote procedure interogateRDBMSServer(DTO, fieldName)
end if
return fieldValue
end remote procedure

remote procedure interogateRDBMSServer(DTO, fieldName)

connect to RDBMS SERVER
query = buildQuery(DTO, fieldName)
call remote procedure executeQuery(query) // involves serialization
receive fieldValue // involves result deserialization
return fieldValue
end remote procedure
 mecanismul bufferelor interne poate fi activat
sau dezactivat atât la nivelul secţiunilor client
şi web cât şi la nivelul secţiunii business în
mod independent.
 pentru controlul activării/dezactivării acestui
mecanism, la nivelul secţiunilor client şi web
este folosită variabila booleana useBuffers,
iar la nivelul secţiunii business este folosită
variabila booleană useServerCache.
 În cadrul unui sistem distribuit în care mai mulţi
clienţi pot simultan accesa şi actualiza acelaşi set de
date, apare problema menţinerii coerenţei acestora.
 Această problemă este adresată cu ajutorul unor
mecanisme de locking şi versioning a datelor la
nivelul serverului.
 În cazul modificării unui DTO clienţii vor trebui mai
întâi să obţină de la server un lock de update asupra
acestuia.
 Pentru a adresa problema defectării clientului şi a
elibera potenţialele lock-uri deţinute de acesta în
momentul defectării, lock-urile atribuite de server
sunt valide doar pentru o perioadă limitată de timp.
 În cazul operaţiunilor de citire, apare
problema actualităţii datelor din bufferele
interne de la nivelul clientului.
 Această problemă este adresată cu ajutorul
unui mecanism de invalidare a bufferelor
interne care acţionează la intervale regulate
de timp, forţând astfel preluarea unui nou set
de date actualizate de la nivelul serverului.
 Logica de lazy loading oferă posibilitatea de a
prelua şi utiliza datele doar în momentul în
care este nevoie de acestea.
 Dacă un atribut nu a fost încă preluat şi apare
o cerere de acces asupra acestuia, atunci
atributul urmează a fi preluat de la nivelul
serverului.
 În acelaşi moment logica de grupuri lazy-load
intră în acţiune după cum urmează: sistemul
caută şi face o reuniune a tuturor grupurilor
lazy-load definite până în acel moment şi
care conţin atributul în cauză.
 Un atribut poate face parte din mai multe
grupuri lazy-load simultan.
 Reuniunea rezultată este prelucrată în aşa fel
încât să nu conţină atribute duplicate.
 Următorul pas este de a elimina din reuniune
toate atributele care au fost deja preluate la
client şi de a trimite cererea pentru procesare
către server care, în funcţie de strategia de
caching de la nivelul acestuia:
◦ va returna direct din cache atributele cerute
sau
◦ va construi şi executa un query la nivelul bazelor de
date pentru preluarea acestora
 Mecanismul de lazy-loading oferă performanţe
superioare faţă de implementările clasice ale
design pattern-urilor de transfer de date între
layere.
 Acest mecanism oferă programatorilor
posibilitatea de a ajusta la orice granularitate
transferul de date între secţiunile unei aplicaţii
distribuite, caracteristică foarte importantă care,
atunci când este folosită corect, oferă o creştere
dramatică a performanţelor de ansamblu ale
întregii aplicaţii enterprise.
 Design pattern-uri clasice de transfer de date
între layere transferă cantităţi mari de
informaţii fără a ţine cont de faptul că o mare
parte dintre acestea riscă să nu fie utilizate
deloc, în acest caz resursele de reţea şi de
calcul fiind irosite.
 Acest neajuns major este depăşit cu succes în
cazul modelului discutat datorită
mecanismului de lazy loading şi a logicii de
grupuri lazy-load.
procedure retrieveField(DTO, fieldName)
if useBuffers
if isBuffered(DTO, fieldName)
// access buffer
fieldValue = getBufferedFieldValue(DTO, fieldName)
else
// update buffer
lazyLoadGroups = getLazyLoadGroups(DTO, fieldName)
fieldNames[] = performJoin(DTO, lazyLoadGroups)
fieldValues[] = call procedure remoteServerRequest(DTO, fieldNames[])
for each fieldName in fieldNames[]
setBufferedFieldValue(DTO, fieldName, fieldValues[fieldName])
end for
fieldValue = fieldValues[fieldName]
end if
else
fieldValue = call procedure remoteServerRequest(DTO, fieldName)
end if
return fieldValue
end procedure

procedure remoteServerRequest(DTO, fieldNames[])

connect to SERVER
call remote procedure getMultipleFieldValues(DTO, fieldNames[]) // involves parameters
serialization
receive fieldValues[] // involves result deserialization
return fieldValues[]
end procedure
remote procedure getMultipleFieldValues(DTO, fieldNames[])
for each fieldName in fieldNames[]
fieldValues[fieldName] = getFieldValue(DTO, fieldName)
end for
return fieldValues[]
end remote procedure
 Design pattern-ul introduce puncte de
control în managementul cache-urilor atât la
nivelul clientului cât şi la nivelul secţiunilor
business.
 Punctul de caching de la nivelul secţiunii EIS
nu este luat în discuţie deoarece acesta nu
este în general accesibil dezvoltatorilor.
 Comportamentul de caching la nivelul acestor
puncte poate fi controlat printr-o simplă
modificare a două variabile booleene, în
partea de client, respectiv în partea de server.
 Sunt posibile 7 situaţii din punct de vedere al
caching-ului, notate S1-S7 şi ilustrate în
tabelul următor, unde simbolul T reprezintă
"true" (adevărat) şi simbolul F reprezintă
"false" (fals).
 O problemă majoră pe care strategiile clasice
de transfer de date între layere o prezintă
este dată de faptul că acestea ori preiau inutil
cantităţi de date adiţionale ori sunt foarte
greu de controlat.
 Această situaţie este prezentă la toate
nivelurile unei aplicaţii multi-tier distribuite
în general, şi la nivelul interfeţelor grafice
dinamice sau al aplicaţiilor web, unde în mod
tipic doar un număr fix de rezultate şi
atribute sunt afişate în pagină, în particular.
 Design pattern-ul discutat oferă o caracteristică
denumită polimorfism al obiectelor de transfer
de date, un DTO putându-se transforma la
runtime într-un DTO de domeniu sau într-un
DTO custom la orice granularitate peste
domeniul pe care îl reprezintă.
 Poate înlocui oricare dintre clasicele design
pattern-uri de transfer de date între layere,
oferind o gamă largă de avantaje adiţionale ce
asigură performanţe mult mai bune comparativ
cu acestea.
 Logica de lazy-loading, logica grupurilor
lazy-load şi mecanismul bufferelor interne ce
acţionează ca şi cache-uri dinamice în acest
context, reprezintă caracteristici de runtime
ale sistemului, lucrând împreună pentru a
asigura un nivel ridicat de performanţe
întregii aplicaţii enterprise.
Curs 13
 Obiective: dezvoltare aplicaţii enterprise
eficiciente, scalabile şi uşor de întreţinut
 Arhitectura discutată este compusă din 9
layere esenţiale:
◦ Persistenţă
◦ Domeniu
◦ Servicii
◦ Faţade
◦ Factories
◦ DTO
◦ Delegaţi
◦ Aplicaţie
◦ Prezentare
 Modelul încapsulează o separare clară a
rolurilor fiecărui layer, principalul scop fiind
acela de a oferi dezvoltatorilor de aplicaţii
enterprise toate informaţiile necesare pentru
a putea construi un backbone solid care va
putea suporta dezvoltarea unor aplicaţii
enterprise eficiente, scalabile şi uşor de
întreţinut.
 Un alt scop al acestui model este acela de a
izola programatorii de complexitatea design
pattern-urilor enterprise.
 Aplicaţiile enterprise bine concepute folosesc
design pattern-uri
 Marele avantaj în aplicarea design pattern-
urilor este dat de faptul că acestea
îmbunătăţesc calitatea şi robusteţea întregii
aplicaţii, oferă posibilitatea reutilizării codului
cât şi un design clar şi relativ uşor de înţeles.
 Din păcate, aplicaţiile enterprise bine
concepute nu sunt aşa de uşor de dezvoltat
în principal deoarece încă există un deficit de
informaţie despre cum să se facă design-ul
unui sistem performant.
 Dezvoltatorii de aplicaţii enterprise fac
deseori greşeli de design costisitoare.

 Mai mult, procesul de învăţare a unui design
corect este în mod particular dificil pentru
noii programatori de aplicaţii enterprise,
mulţi dintre aceştia neavând experienţă
prealabilă în dezvoltarea de sisteme
distribuite şi prin urmare nu înţeleg pe deplin
nevoile fundamentale care influenţează
design-ul sistemelor distribuite.
 Cheia dezvoltării unui design enterprise bine
conceput este aceea de a abstractiza părţi ale
aplicaţiei şi de a reduce la maximum
dependenţele dintre modulele acesteia.
 Acest scop poate fi realizat dacă aplicaţia
enterprise este divizată în mai multe layere.
 Fiecare layer este compus din mai multe
clase, sau componente grupate împreună.
 Prin dezvoltarea sistemului folosind această
abordare, localizarea atât a datelor cât şi a
comportamentului conduce la scăderea
dependenţelor dintre clase şi obiecte, oferind
astfel un design mult mai robust şi mai uşor
de întreţinut.
 Una dintre cele mai eficiente abordări în
design-ul unei aplicaţii enterprise este
abordarea use-case-driven.
 Primul pas îl reprezintă identificarea setului
de use-case-uri pe care sistemul va trebui să
le suporte.
◦ Aceste use-case-uri sunt foarte importante
deoarece pot influenţa deciziile de design ale
aplicaţiei enterprise.
 Al doilea pas este acela de a identifica care
este semantica şi interacţiunile cu utilizatorul
ale fiecărui use-case în parte.
 Odată ce aceste specificaţii sunt stabilite,
următorul pas este de a analiza modelul use-
case-urilor.
 În funcţie de rezultatul analizei, designerii
aplicaţiei enterprise vor avea suficiente
informaţii pentru a începe să schiţeze
design-ul concret al aplicaţiei enterprise
finale.
 Modelul pe layere discutat suportă abordarea
use-case-driven.
 Modelul de domeniu cuprinde toate obiectele
persistente asupra cărora sunt efectuate
acţiuni.
 Folosind abordarea use-case-driven, modelul
de domeniu poate fi uşor derivat din use-
case-urile identificate.
 Deoarece granularitatea iniţială a modelului
de domeniu poate fi prea mare, sau din
contră prea mică, pentru a oferi performanţe
superioare ale aplicaţiei enterprise, modelul
de domeniu poate fi prelucrat şi rafinat în mai
mulţi paşi până când granularitatea de
domeniu dorită este obţinută. Această
operaţiune este în mod tipic executată de
experţi de domeniu.
 Unul dintre cele 9 layere ale modelului
prezentat este layerul de domeniu.
 Layerul de domeniu al unei aplicaţii
enterprise este compus din componente
persistente şi cuprinde modelul de domeniu.
 Există situaţii în care modelul de domeniu, şi prin
urmare layerul de domeniu, nu există. În astfel
de situaţii, bean-urile de sesiune ocolesc layerul
de domeniu şi fac apeluri directe în layerul de
persistenţă, un layer low-level care accesează
direct bazele de date din back-end.
 În afara unor cazuri excepţionale care urmează a
fi detaliate în secţiunile următoare, această
abordare nu ar trebui să apară niciodată în
design-ul unei aplicaţii enterprise.
 Unii dezvoltatori de aplicaţii enterprise aleg
totuşi această cale datorită unuia dintre
următoarele motive:
◦ Dezvoltarea rapidă a prototipurilor – aplicaţia enterprise
nu se intenţionează a avea o folosinţă îndelungată, sau
în timp vor apărea modificări dese asupra modelului de
domeniu.
◦ Modele de domeniu simple – modelul de domeniu al
aplicaţiei enterprise este foarte simplu şi timpul
disponibil pentru dezvoltarea unei soluţii este foarte
scurt.
◦ Motive de performanţă – în momentul în care se
implementează use-case-uri care sunt implicit read-
only.
 Ultimul motiv este unul dintre cazurile
excepţionale menţionate în care ar trebui
făcut bypass peste modelul de domeniu.
 Totuşi, chiar şi în acest caz modelul de
domeniu, şi prin urmare layerul de domeniu,
ar trebui să existe pentru a se putea oferi o
bază OO (orientată obiect) pentru celelalte
use-case-uri.
 Design-ul unei aplicaţii enterprise urmează a
fi dezvoltat layer cu layer.
 Cel mai important rol în design-ul fiecărui
layer în parte îl joacă design pattern-urile
acestea putând influenţa în mod dramatic
arhitectura internă a layerelor.
 Design-ul structurii aplicaţiei poate fi văzut
ca un graf orientat aciclic ce cuprinde layerele
aplicaţiei enterprise.
 Toate datele prelucrate de aplicaţia enterprise
sunt transferate între aceste layere în ambele
direcţii, layer cu layer, de la layerele din
partea de client către layerele din partea de
server şi invers.
 Layerele adiacente sunt conectate prin muchii
care includ conectori de asamblare. În cazul
de faţă, un conector de asamblare este un
conector între două layere care pune în
evidenţă faptul că un layer oferă servicii care
sunt cerute şi accesate de către layerul
adiacent.
 După ce dezvoltarea interfeţelor aplicaţiei
enterprise este finalizată implementarea
fiecărui layer în parte poate varia în mod
independent, fără a declanşa modificări în
cadrul layerelor adiacente, atât timp cât
contractul de interfaţare nu este încălcat.
 Layerele aplicaţiei enterprise pot fi clasificate
după cum urmează:
◦ layere pe partea de server: Persistenţă, Domeniu,
Servicii, Faţade, Factories
◦ layere pe partea de client: Delegaţi, Aplicaţie,
Prezentare
◦ layere comune: DTO
 Conţine toată logica necesară pentru a face
modelul de domeniu persistent la nivelul
bazelor de date din back-end, oferind o
abstractizare asupra RDBMS.
 Prin urmare orice bază de date poate fi
introdusă ca parte integrantă a aplicaţiei
enterprise fără a fi nevoie de modificări
asupra celorlalte layere dependente sau nu de
acesta.
 Conţine toate obiectele care au rezultat în
urma analizei orientate obiect a problemei de
business, fiind layerul care cuprinde modelul
de domeniu.
 Layerele Faţade, Servicii şi Factories
accesează acest layer în contextul mai multor
operaţiuni.
 Un layer Domeniu bine conceput este
adeseori independent de aplicaţie, putând fi
reutilizat în cadrul altor aplicaţii enterprise.
 Cuprinde toate bean-urile de sesiune care au
rezultat în urma fazei de analiză.
 Aceste bean-uri pot fi de două tipuri:
◦ Stateless Session Beans
◦ Stateful Session Beans
 Este accesat de layerul Faţade pentru a invoca
logica de business specifică use-case-urilor,
fiind responsabil atât pentru controlul
tranzacţiilor în cadrul cărora rulează un use-
case cât şi pentru aplicarea logicii şi a
delegărilor necesare finalizării acestuia.
 În mod tipic logica de business este aplicată
mai multor obiecte de domeniu, putând
include şi interacţiuni cu alte servicii.
 Decuplează layerele din partea de server de
layerele din partea de client, toate accesările
părţii de server din partea clientului fiind
canalizate prin acesta.
 Extinde conceptul clasicului design pattern
Session Facade pentru a acoperi atât layerul
Domeniu cât şi layerul Servicii.
 Serviciile de actualizare şi de preluare a
datelor de tip bulk (în cantităţi mari) care
lucrează cu DTO-uri sunt implementate la
nivelul acestui layer.
 Este un layer foarte important, deoarece
acesta controlează accesul către layerele din
partea de server, verificările de securitate cât
şi mecanismele de logging şi monitorizare
fiind de asemenea implementate la nivelul
acestuia.
 Pentru a ascunde detaliile implementării
layerului Domeniu de layerele din partea de
client, layerul Faţade utilizează serviciile
oferite de layerul Factories.
 Decuplează layerul Domeniu de layerele din
partea de client cu ajutorul fabricilor de DTO-
uri (Data Transfer Object factories), fiind
responsabil cu construirea DTO-urilor de
domeniu şi a DTO-urilor custom, fiecare
dintre acestea făcând parte din layerul DTO.
 Ascunde detaliile de implementare ale
layerului Domeniu de layerele din partea de
client.
 Încapsulează obiectele de transfer de date
folosite ca şi containere pentru transferul de date
în ambele direcţii, de la client la server şi de la
server la client.
 Se află între layerele părţii de client şi layerele
părţii de server, rolul principal al acestuia fiind de
a decupla layerul Domeniu de layerele părţii de
client.
 Într-un mediu securizat, DTO-urile pot încapsula
drepturi de securitate sub forma unei încărcături
de date adiţionale, aceste informaţii putând fi
folosite pentru a controla accesul asupra datelor
utile înglobate.
 Abstractizează layerele din partea de server
de layerele din partea de client, ascunzând
complexitatea API-ului enterprise prin
încapsularea întregului cod necesar pentru:
◦ descoperirea serviciilor
◦ delegarea operaţiunilor
◦ recuperarea transparentă în caz de eşec a
invocărilor efectuate asupra layerelor din partea de
server
 Datorită acestui layer, programatorii din
partea de client sunt complet decuplaţi de
tehnologia folosită la nivelul părţii de server.
 Prin urmare, design-ul şi implementarea
părţii de server poate varia independent de
partea de client.
 De asemenea, în cadrul acestui layer este
potrivit de a se implementa un mecanism de
logging la nivelul clientului.
 Este foarte util în cadrul proiectelor mari unde
layerele părţii de client şi layerele părţii de server
sunt dezvoltate de echipe diferite de programatori.
 În fazele iniţiale ale dezvoltării aplicaţiei enterprise,
când partea de server nu este disponibilă, acest layer
poate simula existenţa serverului prin furnizarea de
date fictive programatorilor părţii de client.
 Prin urmare, aceştia nu mai trebuie să aştepte ca
programatorii părţii de server să îşi termine lucrul,
dezvoltarea layerelor părţilor de client şi server
putând fi făcută în paralel, în acest fel procesul de
dezvoltare al aplicaţiei fiind accelerat.
 Reprezintă inima aplicaţiei client controlând
fluxul de informaţii dintre componentele
layerului Prezentare şi componentele layerului
Delegaţi.
 Este responsabil de managementul stării
interne a părţii clientului, de validările
sintactice asupra datelor furnizate de
utilizator, de implementarea cache-urilor de
aplicaţie şi de delegarea operaţiunilor către
layerul Delegaţi.
 Conţine toate componentele interfeţei grafice
împreună cu action listenerii corespunzători.
 În cazul unei aplicaţii client stand-alone,
aceste componente sunt în mod tipic
componente Swing şi AWT; în cazul unei
aplicaţii web, aceste componente sunt
componente web cum ar fi HTML, JSP, servlets
sau Flash.
 Action listenerii conţin metode tip callback
care sunt apelate automat de către
componentele interfeţei grafice în momentul
în care starea acestora se schimbă (în general
datorită unor acţiuni externe din partea
utilizatorului).
 Rolul action listenerilor este acela de a invoca
componentele din layerul Aplicaţie în funcţie
de starea curentă a interfeţei grafice, şi de a
actualiza această interfaţă în concordanţă cu
rezultatele obţinute în urma acestor invocări.
 Se poate deduce o ordine naturală în care
layerele pot fi dezvoltate.
 Această ordine poate fi uşor intuită din
arhitectura prezentată.
 Dacă considerăm graful orientat aciclic care
conţine layerele aplicaţiei enterprise, ordinea
naturală de dezvoltare a acestora este dată de
aplicarea unui algoritm de sortare topologică
pe acest graf.
 Prin urmare, ţinând cont de rezultatele
obţinute în urma acestei sortări, layerele DTO
şi Persistenţă ar trebui să fie primele layere
dezvoltate.
 Există totuşi unele situaţii în care layerul
Persistenţă nu va fi deloc dezvoltat de către
programatorii aplicaţiei enterprise.
 Astfel de situaţii, care nu sunt deloc rare, apar în
momentul în care dezvoltatorii părţii de server
aleg să folosească o tehnologie automată de
generare a logicii de persistenţă cum ar fi
utilizarea JDO(Java Data Objects), Hibernate sau a
altor utilitare de tipul Object/Relational mapping.
 Chiar şi în acest context, layerul Persistenţă va
exista în continuare, cu menţiunea că va fi
generat automat.
 Următorul layer care urmează a fi dezvoltat este
layerul Domeniu.
 După ce şi acest pas este finalizat, layerele
Servicii şi Factories sunt următoarele layere ce
urmează a fi dezvoltate. Aceste două layere pot fi
dezvoltate în paralel, toate dependenţele
acestora fiind deja rezolvate până în acest punct.
 Layerul Faţade este următorul layer ce urmează a
fi dezvoltat, urmat de layerul Delagaţi, layerul
Aplicaţie şi, în sfârşit, layerul Prezentare.
 De notat că, layerul DTO şi layerul Domeniu sunt
complet decuplate.
 Deşi DTO-urile în general reflectă obiecte care se
află în cadrul layerului Domeniu, maparea de la
DTO-uri către aceste obiecte nu este una directă.
 DTO-urile şi obiectele de domeniu pot fi
concepute la granularităţi diferite.
 Mai mult, DTO-urile pot include date adiţionale
care nu sunt reflectate de obiectele de domeniu,
cum ar fi câmpurile calculate.
 În mod similar, obiectele de domeniu pot conţine
câmpuri care nu sunt reflectate de DTO-uri, cum
ar fi câmpuri folosite intern de aplicaţie.
 Prin urmare, pentru a putea obţine o astfel de
abstractizare, o componentă specială de
decuplare care ţine evidenţa tuturor acestor
mapări trebuie implementată.
 Această componentă de decuplare este parte
integrantă a layerelor Factories şi Faţade,
fiind ilustrată în figura următoare.
 Ordinea de dezvoltare descrisă este posibilă
datorită modului în care întreaga structură a
aplicaţiei enterprise a fost concepută.
 Punctul cheie este reprezentat de faptul că
relaţiile de dependenţă sunt unidirecţionale,
această abordare fiind una dintre cele mai
bune practici recunoscute în lumea
aplicaţiilor enterprise.
 Layerele aplicaţiei enterprise formează o
structură de graf orientat aciclic asupra căreia
se pot aplica algoritmi de sortare topologică.
 Dezvoltarea unei aplicaţii enterprise utilizând
modelul prezentat oferă o serie de multe alte
avantaje.
 De exemplu, dacă aplicaţia enterprise trebuie să
ofere un mediu securizat, strict controlat, toate
modificările necesare sunt localizate doar la
nivelul layerului Faţade.
 În câteva cuvinte, o singură componentă ce
reprezintă un serviciu de securitate trebuie să fie
dezvoltată şi introdusă în cadrul acestui layer,
toate celelalte layere ale aplicaţiei enterprise
rămânând nemodificate.
 Procesul implementării unui model de securitate
ar declanşa modificări majore în cadrul unei
aplicaţii enterprise prost concepute unde
majoritatea componentelor din partea de server
ar trebui modificate pentru a suporta un mediu
securizat.
 În contextul modelului pe layere, doar câteva
mici modificări localizate numai la nivelul
layerului Faţade sunt necesare.
 Acelaşi lucru este valabil pentru o gamă largă de
alte servicii care tind să fie globale prin propria
natură.
 Un alt exemplu de serviciu care poate fi foarte
uşor introdus în sistem este un serviciu de
logging şi monitorizare. Ca şi în cazul serviciului
de securitate discutat mai sus, toate modificările
sunt localizate numai la nivelul layerului Faţade.
 Arhitectura prezentată oferă programatorilor de
aplicaţii enterprise posibilitatea de a introduce
noi servicii adiţionale într-un timp foarte scurt şi
cu un efort minim, toate acestea fiind posibile
datorită separării clare a rolurilor care este
inerentă acestui model pe layere.
 Modelul pe layere prezentat conţine toate
informaţiile necesare de care au nevoie
dezvoltatorii de aplicaţii enterprise pentru a
putea construi un backbone solid care va putea
suporta dezvoltarea unor aplicaţii enterprise
eficiente, scalabile şi uşor de întreţinut.
 Acest model oferă o serie de puncte cheie în
structura aplicaţiei unde dezvoltatorii de aplicaţii
enterprise pot uşor introduce o gamă largă de
servicii adiţionale, cum ar fi servicii de securitate,
servicii de logging şi monitorizare, servicii de
fail-over, servicii de caching etc.
 Folosind puterea proxy-urilor generate la
runtime şi a mecanismelor de serializare
custom pe care limbajul Java le oferă, unele
dintre aceste layere, în mod specific layerul
DTO, layerul Delegaţi şi layerul Faţade, pot fi
dezvoltate într-un mod generic.
 Arhitectura prezentată are scopul de a oferi
îmbunătăţiri majore calităţii şi performanţelor
aplicaţiilor enterprise şi de a accelera
procesul de dezvoltare al acestora.