Architetture per le applicazioni...

14
1 Architetture per le applicazioni web-based Mario Cannataro 2 Sommario u Internet e le applicazioni web-based u Caratteristiche delle applicazioni web-based u Soluzioni per l’architettura three-tier F Livello utente F Livello applicativo F Livello dati u Valutazione delle possibili soluzioni u Conclusioni

Transcript of Architetture per le applicazioni...

1

1

Architetture per le applicazioni web-based

Mario Cannataro

2

Sommario

u Internet e le applicazioni web-baseduCaratteristiche delle applicazioni web-baseduSoluzioni per l’architettura three-tierF Livello utenteF Livello applicativoF Livello dati

uValutazione delle possibili soluzioniuConclusioni

2

3

Internet e le applicazioni web-based

u Internet, da “semplice” veicolo per lo scambio di informazioni, sta evolvendo verso una piattaforma per:F lo sviluppo, la diffusione e l'esecuzione di applicazioni distribuite

(web-based)

uL’evoluzione delle tecnologie:F sta radicalmente cambiando il modo di realizzare e diffondere il

software i Network Centric Computing, CORBA

F il concetto stesso di software è destinato a mutare per adattarsi alla nuova realtài Software “free”

4

Applicazioni web-based

uApplicazioni che permettono di accedere, tramite web, alle applicazioni / sistemi informativi aziendali F Inizialmente, via interfaccia web a preesistenti sistemi aziendali

(scarsa integrazione)F Successivamente, completa integrazione fra sistemi informativi

aziendali tradizionali e i server Web.

uTutto il patrimonio informativo (di processo) aziendale può essere utilizzato via Web, ottenendo così una serie di vantaggi tecnologici ed economici

3

5

Applicazioni web-based: vantaggi

uPossibilità di aumentare o uniformare i canali d’accesso alle applicazioni aziendali: F TCP/IP = infrastrutturaFweb-browser = client

uFacilità di aggiornamento e distribuzione: F gestione centralizzata sul server, F “pubblicazione” e/o update ⇒ distribuzione “universale”,

uAccesso multi-piattaforma: F l’accesso è indipendente, entro certi limiti, dall’hardware e dal

sistema operativo utilizzato dagli utenti.

6

Applicazioni web-based: vantaggi

uRiduzione dei costi di gestione (cost-of-ownership): F attraverso l’impiego di client leggeri, siano essi Network

Computer o Personal Computer, purchè l’interfaccia utente sia esclusivamente il browser

F uniformando e centralizzando i servizi trasversali (sicurezza, accounting, assistenza).

uScalabilità: F un’applicazione web-based ben progettata può crescere insieme

alle esigenze dell’aziendaF diverse dimensioni (rete, server applicativo, database)

4

7

Applicazioni web-based:caratteristiche

uContesto di esecuzioneF Internet, Intranet, Extranet* impatto su: client, requisiti del server, sicurezza

uGestione della SicurezzaF Tecnologia basata su crittografia asimmetrica e certificati digitalii SET, Https, SSL

* Impatto non solo su client, server e processi organizzativi (gestione dei certificati), ma anche:

* integrazione con la politica di sicurezza aziendalei autenticazione su server web, i autorizzazione tramite database aziendale preesistente

8

Applicazioni web-based:caratteristiche

uMantenimento dello stato dell’applicazione: ovvero, informazioni consistenti sullo stato della connessione tra l’utente (browser) e il server (http, …)F Il modello d’interazione HTTP non ha il concetto di sessione, F il server deve esplicitamente memorizzare informazioni sul

(browser) client e associargli un identificativo di sessione, per correlare le successive richieste

F gli stati intermedi di un’elaborazione (ad es. contenuto del “carrello della spesa”), sono visibili a seconda del contesto

uAmpiezza di Banda e stima caricoF Dimesione messaggi VS tempi di risposta

5

9

Applicazioni web-based:caratteristiche

uGestione delle transazioni: F garantire un affidabile flusso di dati tra le diverse componentiF gestire possibili stati di inconsistenza, dovuti tipicamente alla

caduta della connessione (condizioni ACID).

uAccesso a DBMS: F utilizzare un'interfaccia standard per l'accesso ai datiF confinare, in pochi moduli dell'applicazione, i dettagli dei

particolari DBMS utilizzati (stringhe di connessione).

10

Architetture di riferimento per le applicazioni web-based

uL’architettura per la progettazione, lo sviluppo, e l'erogazione delle applicazioni web-based ha un ruolo centrale:F interfaccia di progettazione e programmazione tra l'utente

(requisiti) e il dominio applicativo (applicazioni aziendali)F substrato di riferimento per la risoluzione di problemi comuni ai

diversi domini (approccio generale)F disponibilità sempre maggiore di software “free”, il cui codice è

a volte disponibile e modificabile

6

11

Architettura a tre livelli

Database

Logicafunzionale

Interfacciautente

LanInternet

12

Architettura a tre livelli

StoredProcedures

DBMS

Objects

Applicazioni

Livello dati

HTML Script

AppletJava

ControlliActiveX

Browser

Plug-in

Livello utente

Script

ServletJava

ASP

Server HTTP

API

CGI

JSP

Livello applicativo

7

13

Livello utente

u Interfaccia utente dell’applicazione:F acquisizione dati, elaborazione locale, visualizzazione risultatiF combinazione di elementi diversi (browser, dati, programmi)

uElaborazione sul client, VS Fruibilità (estetica/funzionale) per il maggior numero di utentiF dipende dal Contesto di esecuzione

uRequisiti generali: F Leggerezza, pagine scaricabili dall’utente in tempi brevi

F Universalità, pagine fruibili da qualunque utente

14

Livello applicativo

uFunzionalità:F gestire gli accessi e il colloquio con gli utenti F realizzare la logica funzionale dell’applicazione, indipenden-

temente dal server HTTPF accedere alle funzionalità di gestione dati, senza grosse

assunzioni sul tipo di DBMS e sul formato dei dati stessi

uProblematiche:F mantenimento e gestione delle sessionii Cookies, URL-Rewriting, Session-Tracking

F gestione della coerenza della navigazioneF trattamento dei dati personali

8

15

Livello applicativo - CGI

uCommon Gateway Interface (CGI)F interfaccia standard per la cooperazione tra il server HTTP e un

programma eseguibileF versatilità e semplicità VS inefficienza, scarsa manutenubilitàF ormai obsoleta

16

Livello applicativo - ASP

uActive Server Pages (ASP)F pagine HTML + codice script (es. VBscript - Visual Basic script)

sul serveri il codice Vbscript viene interpretato ed eseguito dal server HTTP

F Semplicità e rapidità di costruzione, (Visual Interdev)F L’esecuzione delle ASP sul server HTTP, può degradare le

prestazioni

F VBScript (scripting) inadeguato per progetti complessiF Tecnologia proprietaria

9

17

Livello applicativo - JSP

u Java Server Pages (JSP) F Simili alle ASP, pagine Html + codice Java F Basate su Java, del quale ereditano le caratteristiche di

espressività, sicurezza e portabilità i applicazione indipendente dalle componenti del livello applicativo, i integrazione con le Servlet e gli Enterprise Java Beans,i l’integrazione ASP con componenti OCX richiede una buona

conoscenza della tecnologia COM

F Per contro le JSP sono una soluzione nuova e poco collaudata, a fronte della maturità e stabilità raggiunta dalle ASP i scarsa disponibilità ambienti di sviluppo per JSP

18

Livello applicativo - Servlet

u Java Servlet: classi Java per applicazioni serverF portabilità - eseguite in una Java Virtual Machine (JVM), interna

o esterna al server HTTPF efficienza - al contrario dei programmi CGI, le Servlet vengono

interpretate una sola volta, alla prima invocazione, dopo di cherimangono in memoria per servire successive richieste.

F potenza espressivaF utilizzo personalizzabile ed ottimizzato dei cookiesF completo accesso a filesystem e socket

10

19

Enterprise JavaBeans

uSpecifica JavaSoftF definisce un modello a componenti (lato server), per lo sviluppo

ed erogazione di applicazioni Java, su un’architettura multi-tier, distribuita e ad oggetti

uFocus su: F sviluppo della business logic, piuttosto che sviluppo di

infrastrutture di basso livello, (accesso dati, concorrenza, transazioni, threading)

EJB Server

EJB Container

Enterprise Bean

Enterprise Bean

Clients

20

Livello applicativo: approccio Microsoft

Microsoft Visual Basic + ASP + ADO (Active Data Objects)

Browserutente

IIS

ASP

VbScriptHTTP ADO

NT

Dati

11

21

Livello applicativo: approccio Java/Sun

Ciclo di vita Servlet

ClientBrowser Servlet

JDBC

DBMS

HTML

Http Server

22

Esempio di architettura basata su Servlet

Servlet

Java Runtime Environment (JVM)

APACHE JServ

Contenuti Statici(HTML)

JDBC

APACHE

UNIX / WINDOWS NT

Java ServletDevelopmen

t Kit

DatiUtente

12

23

Livello dati

uFunzionalità:F garantire l'accesso strutturato e affidabile ai dati, attraverso

un'interfaccia standardF controllo transazioni centralizzato (sul DBMS) VS controllo

decentralizzato (Livello applicativo e DBMS).

uApprocci:F CGI,⇒ interfaccia DBI simile al JDBC JavaF ASP, ⇒ interfaccia ADO (Active Data Objects) o ODBC

i ADO permette un accesso diretto al DBMS, i la presenza di un Manager ODBC, comporta un passo aggiuntivo.

F Servlet Java, ⇒ API JDBC i utilizzo di codice SQL nei servlet, inviato al DBMS, oppure i invocazione di Stored Procedures, contenute nella base di dati.

24

Valutazioni: Livello Utente

LIVELLOUTENTE

ACCESSIBILITÀ ELABORAZIONELOCALE

PRO CONTRO

HTML Massima Bassa Portabilità su tutti i browser. Penalizzazione elaborativasul server

Uso di Script Media Bassa Possibilità di semplicielaborazioni locali

Riduce poco la complessitàdel server

Applet Java Media, (eventualiincompatibilità traJVM)

Elevata Maggiore elaborazione,anche di tipo grafico

Necessarie molte risorse sulClient. Tempi elevati didownload/elaborazione.Possibili incompatibilitàJVM.

ControlliActive X

Ottima in ambienteWindows, No sualtri ambienti

Buona Prestazioni elevate, se si usaWindows in combinazionecon HTML, DHTML eScripting.

Scarsa portabilità, inaggiunta ai CONTRO delleApplet Java.

13

25

Valutazioni: Livello Applicativo

LIVELLOAPPLICATIVO

CGI ASP SERVLET + JSP

Velocità direalizzazione

Discreta (Perl) . Ottima (ambienti di sviluppodedicati)

Media(difficile generazione Html)

Efficienza Bassa (attivazione diprocesso per invocazione).

Ottima (VbScript su IIS) Buona (servlet attive per tuttala sessione)

Portabilità Buona (Perl) Inesistente (solo Windows eIIS)

Ottima (richiede una JVM)

Manutenzione Difficoltosa. Difficoltosa (generalmente pergli script).

Buona (paradigma OO e Java)

Accesso ai dati Buono (DBI). Ottima per MS SQL server,meno per altri DBMS (Ado èancora immatura)

Ottima (JDBC supportaefficientemente molti DBMS)

Mantenimento dellesessioni

Difficoltoso Medio Ottimo (in prospettiva EJB)

26

Valutazioni: Livello Dati

LIVELLO DATIArchitetturaAccesso ai dati

PIATTA – Ogni procedura accede al DBMSin maniera indipendente effettuando unapropria connessione

CENTRALIZZATA – Una sola proceduraeffettua la connessione al DBMS e gestiscetutte le richieste di accesso

Posizionamentocodice applicazione

Codice SQL puro viene inserito all’internodelle varie procedure e viene inviato al DBMS

All’interno delle procedure è effettuata unachiamata a Stored Procedure nel DBMS

Accesso a DBMSObject Oriented

CGI in C++, ma soprattutto Java (Servlet),permettono un accesso efficace a DBMS OO

Le ASP, pensate per RDBMS, possonosupportare ma con difficoltà i DBMS OO

14

27

Conclusioni

uLivello utenteF Elaborazione sul client dettata dalle necessità dell'applicazione

uLivello applicativoF ASP è ormai una soluzione ben collaudata e molto diffusa F I Servlet non sono ancora molto usatii prestazioni inferiori alle ASP e carenza di ambienti di sviluppo

Fma beneficieranno delle evoluzioni della piattaforma Javai portabilità, manutenibilità progetti complessi

uLivello dati F Stored Procedures (app. esterni) per una gestione efficiente F Confinare i punti di accesso ai dati