Applicazioni Web-based e non

1. Applicazioni Web-based e non Elementi di base di un’applicazione • I dati da trattare (dati sugli utenti, sul servizio offerto, etc.) • Logica applicativa (business logic), ovvero le funzionalità che l’applicazione deve offrire, il tipo di trattamento dei dati previsto (quali operazioni si possono fare), etc. • Interfaccia utente • interfaccia web (e.g., per browser, o testuale) • stand-alone (applicazione locale alla macchina su cui gira) Laboratorio di Servizi Web - Ardissono

2. Architetture delle applicazioni • Monoliti • Client/server (two-tier) • Three-tier • N-tier Laboratorio di Servizi Web - Ardissono

3. Monoliti (IT stovepipe) - I • Popolari ai tempi dei mainframe • Monoliti: • pezzi di codice indivisibili • controllavano l’intera logica dell’applicazione, dalla gestione (e memorizzazione) dei dati, fino all’interfaccia utente • gestivano applicazioni stand-alone • Popolarità dovuta a: • mainframe adatti ad eseguire pochi processi stand-alone, anzichè diversi processi comunicanti • non c’erano ancora i database Laboratorio di Servizi Web - Ardissono

4. Monoliti (IT stovepipe) - II User interface Logic Data Management Enterprise Laboratorio di Servizi Web - Ardissono

5. Architetture client/server - I • Dalla fine degli anni ‘70 alla metà degli anni ‘80 • Diffusione di server più piccoli ed economici dei mainframe, e di workstations e PC • Diffusione di RDBMS • Suddivisione delle applicazioni in due parti: • backend (server): gestione di database (+ o – complessi) e dei compiti di manipolazione dei dati • frontend (client): gestione interfaccia utente  maggiore scalabilità, rispetto a monoliti (carico computazionale distrbuito sui client)  sviluppo più veloce di applicazioni che accedono agli (stessi) dati Laboratorio di Servizi Web - Ardissono

6. Architetture client/server - III Client Client Client User interface Logic Data Management Server Enterprise Laboratorio di Servizi Web - Ardissono

7. Architetture client/server - II Svantaggi: • Traffico di messaggi intenso (frontend comunica continuamente con server dati) • Logica di business non gestita in componente separata dell’architettura: suddivisa tra frontend e backend •  client e server di applicazione dipendono l’uno dall’altro • difficile riutilizzare interfaccia in servizio che accede a dati diversi • difficile utilizzare DB da frontend diversi • tendenza a cablare la business logic nell’interfaccia utente  cambio di logica significa cambiare anche interfaccia Laboratorio di Servizi Web - Ardissono

8. Architetture client/server - IV • Problema: mancato riconoscimento dell’importanza della business logic • Es: servizio accessibile da più device (telefonino, desktop)  stessa logica, interfaccia diversa Nuovo Client Nuovo Client User interface Client Logic Adapter Adapter Data Management Server Enterprise Laboratorio di Servizi Web - Ardissono

9. Architetture three-tier - I • Introdotte all’inizio degli anni ‘90 • Business logic trattata in modo esplicito: • livello 1: gestione dei dati (DBMS, file XML, …..) • livello 2: business logic (processamento dati, …) • livello 3: interfaccia utente (presentazione dati, servizi) • Ogni livello ha obiettivi e vincoli di design propri • Nessun livello fa assunzioni sulla struttura o implementazione degli altri: • livello 2 non fa assunzioni su rappresentazione dei dati, né sull’implementazione dell’interfaccia utente • livello 3 non fa assunzioni su come opera la business logic .. Laboratorio di Servizi Web - Ardissono

10. Architetture three-tier - II • Non c’è comunicazione diretta tra livello 1 e livello 3 • Interfaccia utente non riceve, né inserisce direttamente dati nel livello di data management • Tutti i passaggi di informazione nei due sensi vengono filtrati dalla business logic • I livelli operano senza assumere di essere parte di una specifica applicazione •  applicazioni viste come collezioni di componenti cooperanti •  ogni componente può essere contemporaneamente parte di applicazioni diverse (e.g., database, o componente logica di configurazione di oggetti complessi) Laboratorio di Servizi Web - Ardissono

11. Architetture three-tier - III Motif Client Windows Client Telephony Client Mac Client User interface Presentation layer Logic Business layer Business Rules Business Rules Business Rules Data Management Data layer Data Service Data Service Data Service Enterprise Laboratorio di Servizi Web - Ardissono

12. Architetture three-tier - IV User Interface Service consumer Application Logic Service provider Data providers XMLDocuments DB Directory service Laboratorio di Servizi Web - Ardissono

13. Vantaggi di architetture three-tier - I • Flessibilità e modificabilità di sistemi formati da componenti separate • componenti utilizzabili in sistemi diversi • modifica di una componente non impatta sul resto del sistema (a meno di cambiamenti negli API) • ricerca di bug più focalizzata (separazione ed isolamento delle funzionalità del sistema) • aggiunta di funzionalità all’applicazione implica estensione delle sole componenti coinvolte (o aggiunta di nuove componenti) Laboratorio di Servizi Web - Ardissono

14. Vantaggi di architetture three-tier - II • Interconnettività • API delle componenti superano il problema degli adattatori del modello client server  N interfacce diverse possono essere connesse allo stesso servizio etc. • Facilitato l’accesso a dati comuni da parte di applicazioni diverse (uso dello stesso gestore dei dati da parte di business logics diverse) • Gestione di sistemi distribuiti • Business logic di applicazioni distribuite (e.g., sistemi informativi con alcuni server replicati e client remoti) aggiornabile senza richiedere aggiornamento dei client • Aggiornamento dei client comunque costoso Laboratorio di Servizi Web - Ardissono

15. Vantaggi di architetture three-tier - III • Applicazioni distribuite geograficamente • Data server centrale • Business logic gestita da server logici regionali • Client remoti (ev. con business logic per maggior scalabilità) • Per ridurre traffico di rete e latency del servizio, anche il data server centrale può essere replicato (ma, gestione consistenza dati) Laboratorio di Servizi Web - Ardissono

16. Svantaggi di architetture three-tier - I • Dimensioni delle applicazioni ed efficienza • Pesante uso della comunicazione in rete  latenza del servizio • Comunicazione tra componenti richiede uso di librerie SW per scambio di informazioni  codice voluminoso • Legacy software • Molte imprese usano software vecchio (basato su modello monolitico) per gestire i propri dati  • difficile applicare il modello three-tier per nuove applicazioni • introduzione di adapters per interfacciare il legacy SW Laboratorio di Servizi Web - Ardissono

17. Three-tier è concettuale, non fisico Si possono implementare architetture three-tier su due livelli di macchine, o anche su uno solo... Data and Logic Server Clients User Interface Data Components Logic Rules User Interface Laboratorio di Servizi Web - Ardissono

18. Architetture n-Tier - I Permettono configurazioni diverse. Elementi fondamentali: • Interfaccia utente (UI) • gestisce interazione con utente • può essere un web browser, WAP minibrowser, interfaccia grafica, … • Presentation logic • definisce cosa UI presenta e come gestire le richieste utente • Business logic • gestisce regole di business dell’applicazione Laboratorio di Servizi Web - Ardissono

19. Architetture n-Tier - II • Infrastructure services • forniscono funzionalità supplementari alle componenti dell’applicazione (messaging, supporto alle transazioni, …) • Data layer: • livello dei dati dell’applicazione Laboratorio di Servizi Web - Ardissono

20. Architetture n-Tier - III Browser Firewall Application client Presentation Logic Services Business Logic XMLDocuments DB Laboratorio di Servizi Web - Ardissono

21. Applicazione Web-based tipica - I • Interfaccia utente: gestita sul browser utente • Logica applicativa: gestita sul server, che si interfaccia al web attraverso Web Server • Livello dei dati: su database, eventualmente localizzato su macchina diversa da quella del Web Server, per questioni di sicurezza Web Server Browser utente HTTP Business logic Laboratorio di Servizi Web - Ardissono

22. Applicazione Web-based tipica - II • Richiesta di pagina HTML statica (pagina HTML memorizzata nel file system dell’applicazione – il codice della pagina non viene generato eseguendo programmi applicativi sul server) Request: http://patzer/hello.html Local File System Browser utente Web Server /htdocs/hello.html Response: HTML code Laboratorio di Servizi Web - Ardissono

23. Applicazione Web-based tipica - III • Richiesta di pagina dinamica (pagina HTML generata dinamicamente, sulla base della richiesta del client – codice della pagina generato eseguendo programmi applicativi sul server) Request: http://www.di.unito.it/service1.html Web Server Browser utente Business logic Response: pagina HTML di risposta, con eventuali link e bottoni per continuare interazione Laboratorio di Servizi Web - Ardissono

24. Browser Web • Può essere visto come interfaccia utente universale • Invoca Web Server per richiedere pagine statiche o dinamiche • Riceve contenuti web da Web Server invocato e li presenta sulla macchina dell’utente • Browser moderni (MS Explorer, Netscape Navigator, …) interpretano codice HTML • Alcuni browser interpretano codice XML • Può eseguire script (e.g., javascript) localmente, per effettuare semplici computazioni (e.g., controllo correttezza input utente) • Può scaricare plug-in da Web Server per eseguire programmi localmente (e.g., animazioni Flash o altro) Laboratorio di Servizi Web - Ardissono

25. Web Server • Programma che • gira su una macchina server accessibile da internet • resta in ascolto di richieste (da parte di client web) su porta HTTP. E.g., http://www.di.unito.it:8080 • gestisce le richieste che arrivano (recupera pagina html richiesta, esegue programmi, invoca programmi associati a servizi richiesti, etc.) • restituisce a client una risposta (risultato della richiesta, messaggio di errore) Laboratorio di Servizi Web - Ardissono

26. La Piattaforma J2EE • J2SE: Java 2 Platform, Standard Edition. • Ambiente runtime per esecuzione di applicazioni Java e insieme di API (Application Programming Interface) per sviluppare applicazioni di vario tipo (applets, applicazioni stand-alone, …) • J2EE: Java 2 Platform, Enterprise Edition: • framework per lo sviluppo di applicazioni server-side complesse • J2ME: Java 2 Platform, Micro Edition: • framework per lo sviluppo di applicazioni su micro device (PDA, telefonini Java-enabled, etc.) Laboratorio di Servizi Web - Ardissono

27. Proprietà • J2EE: adatta allo sviluppo di applicazioni Web-based a livello di impresa, e.g., per commercio elettronico • Il suo competitor è Microsoft .net • Impresa (enterprise): organizzazione di business • Enterprise software applications: applicazioni SW che facilitano la gestione delle attività di impresa • interagire con clienti e partners via Internet • facilitare l’interazione tra le varie parti di un’impresa, eventualmente distribuite geograficamente • gestione del business: resource planning, gestione inventari, ... Laboratorio di Servizi Web - Ardissono

28. Caratteristiche di applicazioni “enterprise” • Necessità informative: spesso le stesse informazioni sono utilizzate sotto forma diversa dai consumatori  attività di business diverse processano le stesse informazioni, ma utilizzando formati diversi • Complessità dei processi di business: necessità di raccogliere, gestire e condividere informazioni, basandosi su una logica complessa • Eterogeneità delle applicazioni: un’impresa utilizza molte applicazioni basate su architetture e tecnologie diverse (legacy software) Laboratorio di Servizi Web - Ardissono

29. Requisiti di gestione del software d’impresa • Velocizzazione del processo di sviluppo delle applicazioni: cambiano gli standard, le tecnologie, le applicazioni devono entrare in uso velocemente • Affidabilità e disponibilità: il SW deve essere sempre accessibile (Web) ed essere affidabile (e.g., transazioni) • Sicurezza: protezione delle informazioni dell’azienda • Scalabilità: accesso efficiente a risorse, tolleranza al carico di milioni di utenti (Web) • Integrazione: le applicazioni vanno integrate nei sistemi informativi già esistenti Laboratorio di Servizi Web - Ardissono

30. J2EE • Si sono sviluppate soluzioni diverse per affrontare i vari problemi • J2EE: permette di integrare tali soluzioni e facilita lo sviluppo del SW • Modello di programmazione con approccio alla costruzione di applicazioni basato su API • Infrastruttura che permette di eseguire le applicazioni in modo efficiente e scalabile • basato su Java  portabile • basato sul concetto di Contenitore  servizi di gestione di base (messaggi, transazioni, ciclo di vita delle componenti, …) forniti dall’infrastruttura • Modulare, componenti riusabili Laboratorio di Servizi Web - Ardissono

31. In questo corso di laboratorio • Utilizzeremo JWSDP (Java Web Services Development Pack) come infrastruttura per lo sviluppo di applicazioni Web-based • Sperimenteremo l’uso di tecnologie di • accesso a Database mediante JDBC • gestione di XML • gestione di applicazioni Server-side (Servlets, JSP) • … • Non sperimenteremo l’uso degli EJB (Enterprise Java Beans), trattati nel corso di Sperimentazioni di Ingegneria del Software (SpisII) Laboratorio di Servizi Web - Ardissono