Modelli di applicazioni web

Docente: Gabriele Lombardi

[email protected]

© 2008 - CEFRIEL
The present original document was produced by CEFRIEL and the Teacher for the benefit and internal use of this
course, and nobody else may claim any right or paternity on it. No right to use the document for any purpose other than
the Intended purpose and no right to distribute, disclose, release, furnish or disseminate it or a part of it in any way or
form to anyone without the prior express written consent of CEFRIEL and the Teacher.
© copyright Cefriel and the Teacher-Milan-Italy-23/06/2008. All rights reserved in accordance with rule of law and
international agreements.

© 2008 - CEFRIEL
 Sommario
SLIDE CONTENUTO

Applicazioni web Scripting, responsabilità, scalabilità, MVC

Applicazioni distribuite Modello, problemi, soluzioni, tecnologie

J2EE Modelli di utilizzo

EJB Scopo, architettura, tecnologie

© 2008 - CEFRIEL
 Applicazioni web: responsabilità?

„ Responsabilità:
– non è ovvio chi debba avere la Esecuzione
responsabilità di eseguire cosa;
– possibilità:
• server fa tutto, client visualizza;
Esecuzione
• server fornisce le risorse
(compresi i programi), client
esegue e visualizza;
• server elabora le risposte ed
inserisce dinamicamente anche il Esecuzione Esecuzione
codice da eseguire lato client per
le parti interattive;
• client e svariati server cooperano
affrontando ognuno il proprio Esecuzione
compito: Esecuzione
– elaborazione richiesta;
– accesso ai dati;
– elaborazione risposta;
– presentazione del risultato Esecuzione Esecuzione
(eventualmente interattivo).

© 2008 - CEFRIEL
 Applicazioni web: scalabilità?

„ Se tanti server eseguono (parti diverse del) la stessa

applicazione web…
– come deve essere “spezzettata” l’applicazione?
– cosa succede se su un server “cade un asteroide”
(crash&failure)?
– chi si preoccupa di bilanciare il carico… e come (se
l’assegnazione è statica)?
„ Non (facilmente) fattibile se le tecnologie utilizzate sono
quelle descritte.
– Quindi… serve una soluzione che sia più facilmente (ed
automaticamente) scalabile.

© 2008 - CEFRIEL
 Applicazioni web: diversi sottoproblemi separabili

„ Utilizzo del pattern Model View

Controller (MVC); A B VIEW
„ accesso ai dati;
„ efficienza; C
„ scalabilità; CONTROLLER
„ sicurezza;
„ semplicità per richieste A B
semplici (da parte del C
committente);
A B
„ Modello standard di sviluppo.
C

A B
Gabriele Lombardi C
Nato a Milano
Il 18/02/1979 MODEL
Ecc ecc ecc
A B
C
© 2008 - CEFRIEL
 Sistemi distribuiti: modello
„ I client e i server:
– comunicano tramite le interfacce e le “primitive di rete”;
– usufruiscono di protocolli standard di comunicazione di rete;
– il middleware utilizza la rete per fornire servizzi agli strati superiori:
• concorrenza, gestione delle transazioni, persistenza, distribuzione,
naming e sicurezza;
– le applicazioni distribuite:
• sfruttano il middleware (usufruiscono dei servizi);
• non dipendono dal deploy (trasparenza).

Distributed applications (per noi un insieme di “moduli” interoperanti)

Middleware services (per noi alcuni strumenti di J2EE)

Networked O.S. (kernel) Networked O.S. (kernel)

Hardware & devices Hardware & devices
(network interfaces) (network interfaces)

client …net… server

© 2008 - CEFRIEL
 Sistemi distribuiti: problemi

„ Distribuzione:
– gestione di oggetti locali e remoti nascondendone la reale
localizzazione e la sincronizzazione;
– chiamate remote di procedure (RPC) e metodi (RMI);
„ Concorrenza:
– accessi concorrenti ad oggetti locali e remoti;
„ Persistenza:
– persistenza di oggetti robusta ai fallimenti;
– object relational mapping (ORM);
„ Transazioni:
– transazioni su DB e su oggetti dell’ORM;
– transazioni distribuite;
„ Sicurezza:
– controllo d’accesso (autenticazione e controllo d’identità);
– gestione di permessi sulle risorse;
– utilizzo di canali crittografati (es.: utilizzando il protocollo SSL).

© 2008 - CEFRIEL
 Sistemi distribuiti: tecnologie
„ Distribuzione:
– utilizzo di proxy-objects, ad esempio stub e skeleton in RMI;
– utilizzo di protocolli di comunicazione orientati all’invocazione remota, ad
esempio IIOP o SOAP;
– marshalling dei parametri;
– object request brokers, ad esempio ORB CORBA e DCOM;
– trasparenza dei protocolli, ad esempio con JCA;
„ Concorrenza:
– istanze multiple e caching per moduli non concorrenti;
– istanze multiple con semafori o monitor per moduli concorrenti ma ad istanza
singola per richiesta;
– problematica della concorrenza remota localmente trasparente;
„ Persistenza:
– utilizzo di DBMS;
– strumenti di ORM come Java Persistence;
„ Transazioni:
– delegazione della gestione delle transazioni, distribuite e non, al middleware, ad
esempio Java Transaction API (JTA);
„ Sicurezza:
– delegazione di tutte le operazioni potenzialmente pericolosa al middleware, così
da poter localizzare le problematiche di sicurezza come autenticazione e
autorizzazione, ad esempio utilizzando JAAS.

© 2008 - CEFRIEL
 J2EE

„ Set di API e container:

– rappresentano il middleware dello standard proposto
dalla Sun per la costruzione di applicazioni distribuite;
– offrono I servizi nominati precedentemente (e altri);
– permettono di costruire applicazioni distribuite
generali, ma sono facilmente integrabili con
tecnologie per le applicazioni web;
„ Modelli:
– le API J2EE sono utilizzabili a piacere ma…
– …esistono modelli che definiscono come realizzare
applicazioni robuste, riutilizzabili e modulari;
– identificheremo e studieremo le tecnologie…
– …per poi comporre la nostra prima applicazione
distribuita completa.
© 2008 - CEFRIEL
 J2EE: Modello Sevlet-based

HttpRequest
„ Il client invia una request
al server per una servlet; Servlet

„ il server ha un servlet
container… request HttpResponse

„ …e mantiene in memoria
le istanze delle servlet;
Servlet
„ ogni servlet lavora in Servlet
maniera simile ad un Servlet
Servlet
FastCGI

Servlet container

© 2008 - CEFRIEL
 J2EE: Modello Servlet-JSP

„ Il client invia una request al server request

per una servlet;
„ il server ha un servlet container…
„ …e un JSP container; response
„ i JavaBeans rappresentano le
strutture dati; request
„ il servlet container attiva la JSP
Servlet JSP
servlet… Servlet JSP
„ …che utilizza i JavaBeans per CONTROL
elaborare la richiesta; VIEW
Servlet container JSP container
„ scelta una pagina JSP adeguata,
la utilizza per generare l’output;
„ la risposta viene inviata.
JavaBean
„ L’architettura è MVC. JavaBean
MODEL
Beans container

© 2008 - CEFRIEL
 J2EE: Modello con EJB

request
„ In questo quadro più
complesso:
– l’elaborazione delle
richieste è svolta anche da response
EJB di tipo session, legati request
alla sessione; CONTROL
– lo stato è JSP
mantenuto/elaborato da Servlet
EJB di tipo entity, JSP
descriventi entità JSP
EJBSession
condivise; VIEW
– i JavaBeans mantengono JSP container
lo stato attuale degli Servlet container
EJBEntity per consentire
un accesso più efficiente;
JavaBean
– le comunicazioni sono più
complesse. EJBEntity
MODEL
EJB container

© 2008 - CEFRIEL
 EJB: tipi e scopo
„ EntityBeans:
entity entity
– rappresentazione dei dati;
– descrizione delle entità del dominio;
– descrizione delle relazioni tra enttà; entity
– object relational mapping. entity
„ SessionBeans:
– definiscono la business logic del sistema;
– possono essere:
• stateless:
– senza stato; SessionBean
– ogni richiesta è a sé;
• stateful: client
– stato interno;
– sono “personali” di ogni client.
„ MessageDrivenBeans:
– si appoggiano ad un messaging system (come JMS); MDBean
– reagiscono a richieste inviate come messaggi;
– non forniscono rispposta.
client
© 2008 - CEFRIEL
 EJB: entità e persistenza
Applicazione
„ Dall’analisi si può
definire:
entity
– l’insieme di entità e entity
relazioni;
– il database su cui entity
entity
devono essere mappate;
„ utilizzando Java
Persistence: ORM
(Java Persistence API)
– si può ottenere l’ORM
delle entità…
– …e delle relazioni;
– gestendone:
• insert, update,
merge, delete. DB

© 2008 - CEFRIEL
 EJB: sessioni con e senza stato
„ Reppresentano:
– la business logic dell’applicazione enterprise; DB
– moduli coesi per dipendenze e responsabilità;
– pool di operazioni invocabili da remoto; container EJB
– “luogo” in cui effettuare le transazioni.
„ Permettono: JDBC JPA
– manipolazioni dall’esterno con interfacce remote;
– di incapsulare tutta la logica dell’applicazione:
bean
• lato client non deve esserci logica di bus.,
• solo richieste e gestione della view.
„ Si creano:
– all’interno di un EJB container;
– utilizzando le risorse messe a disposizione
dall’applicazione, dal server e dal container EJB;
– implementando la logica di business in metodi;
– esponendo le operazioni (ad esempio come WS).

client
– creando le richieste all’interno dei client;
„ Stato:
– informazioni sullo stato della richiesta del client;
– persistenti tra una richiesta e la successiva;
– transazioni estese.
© 2008 - CEFRIEL
 EJB: message driven
„ Scopo:
– fornire servizi invocabili in differita;
– senza valori di ritorno (solo azioni); container EJB
– nessun riscontro; JDBC JPA
– no blocking.
„ Gestione:
MDB
– tramite message passing;
onMessage
– code di messaggi;
– messaggi indipendenti uno
dall’altro;
– nessuno stato della conversazione;
„ Si crano:
– in un container EJB;
– utilizzando un messaging system MS
(ad es.: JMS);
– implementando un metodo di client
elaborazione dei messaggi;
– generando i messaggi nei client.
© 2008 - CEFRIEL
 WS e SOAP

„ Scopo WS:
– effettuare RPC ed RMI tramite Web:
• superando problemi relativi alla sicurezza;
• utilizzando un protocollo standard;
– testo in chiaro facilmente parsabile;
• marshalling tramite conversione in stringhe;
– (nel nostro caso) interagire con EJB;
• in particolare con session beans;
– (nel nostro caso) fornire endpoint interfaces:
• accessibili anche da applicazioni non J2EE (app.
stand alone e WebApp non J2EE).
„ Scopo SOAP:
– standard per l’interoperabilità (comunicazione, RPC, RMI);
– basato su XML (quindi testo in chiaro facilmente parsabile);
– con registrazione e ricerca servizzi se si utilizza UDDI.
© 2008 - CEFRIEL
 E nel futuro?

Chi lo sa…
…pensiamo prima a oggi
passando dalla teoria alla pratica!

© 2008 - CEFRIEL