Introduzione a J2EE Java 2 Enterprise Edition Pietro Martinelli

Sommario ● Due parole su Java: note storiche, caratteristiche principali ● J2EE: applicazioni complesse ed orientate al Web ● Piattaforme J2EE: mondo free e mondo proprietario ● Strumenti di sviluppo: ambienti integrati e tool “artigianali” ● Altri strumenti (più generici) di sviluppo

Java: note “storiche” ● Progettato e sviluppato da Sun Microsystems ● 1991: “Green” (lavatrici...) ● 1995 (SunWorld): Browser HotJava: Applet ● 1996: Netscape ed IE ● 1998: Java2 ● : J2SDK 1.5 (beta 1,2)

Idea di fondo ● Write Once, Run Anywhere TM ¿¿¿ Write Once, Debug Anywhere ???

Caratteristiche ● Un linguaggio interpretato (JRE, VM) ● Un linguaggio portabile (bytecode, VM) ● Un linguaggio Object Oriented (“C++-”) quasi puro

Elementi di successo – 1 ● Semplice da imparare, più “user friendly” del C++ ● Portabile ● Libreria di base (Java Fundamental Classes) ricca (multimedialità, crittografia, XML, I/O, matematica...), completa ed Open Source ● Ambienti di sviluppo free: J2SDK, J2EESDK, Sun One Studio, Netbeans,...

Elementi di successo – 2 ● Linguaggio “orientato al Web” (lato client): Applet, Applet sicure (SandBox 1 e 2) ● Linguaggio “orientato al Web” (lato server): Servlet, Java Server Pages (JSP) ● Linguaggio per applicazioni complesse e distribuite: Enterprise Java Beans (EJB)

Non tutto è oro... ● Efficienza: l'avvio della VM, l'interpretazione (ma: One – Time – Compilers, VM “non – SUN” come Kaffe: veloci ma non – standard) ● Tecnicismi anche per programmi semplici (OO in generale, J2EE in particolare)

J2EE ● Un'Architettura per applicazioni complesse e di grosse dimensioni (“Enterprise”), basate (principalmente, ma non solo) su Web ● Un'Architettura per applicazioni Server - Side ● Una specifica (uno Standard) per piattaforme (Application Server) che supportano Componenti e forniscono Servizi.

Architettura a componenti ● Un Componente è una tipologia di oggetti che svolgono un certo Ruolo, “vivono” in un certo Ambiente (Container) ed esportano certe Interfacce ● Un Container è l'ambiente che l'Application Server mette a disposizione del Componente, in termini di Servizi ed Interfacce verso l'esterno ● Un'interfaccia è un insieme di punti di accesso e comunicazione tra Componente, Container e (indirettamente) mondo esterno

Tipologie di Componenti J2EE ● Servlet Componenti che estendono le funzionalità di un Server Web, permettendo la generazioni di contenuti dinamici e più in generale di accedere alle funzionalità dell'applicazione J2EE ● Java Server Pages (JSP) Versione “scriptata” dei Servlet ● Enterprise Java Beans (EJB) Componenti che offrono ad altri Componenti o Applicazioni servizi, tipicamente di accesso a dati

Applicazione J2EE Un'applicazione J2EE è costituita, in generale, da ● Un certo numero di Componenti dei tre tipi. ● Informazioni di configurazione dell'Applicazione, sia di tipo standard (ovvero richiesti dalla piattaforma standard J2EE) sia specifici dell'Application Server prescelto. Queste informazioni sono fornite sotto forma di file XML (Deployment Descriptors).

Deployment Descriptor ● Un Deployment Descriptor è un file di configurazione (XML) necessario per fare “girare” l'applicazione J2EE in un Application Server. ● Un DD dà informazioni sui Componenti al relativo Container ● In generale, ogni applicazione J2EE contiene numerosi Dds

Architettura J2EE: Container Un Application Server fornisce due tipologie di “Contenitori” di Componenti: ● Web Container Costituisce l'ambiente all'interno del quale “vivono” le componenti Web dell'applicazione J2EE, Servlet e JSP ● EJB Container Costituisce l'ambiente all'interno del quale “vivono” gli EJB

J2EE, un'architettura a tre livelli - 1 ● Model: livello di Modellazione, che si occupa di astrarre l'applicazione rispetto ai dati (di cui, appunto, funge da modello) e di incapsulare la “logica di businness” L'architettura J2EE prevede che il livello Model sia implementato per mezzo di EJB J2EE è un'architettura che segue il paradigma “Model – View – Controller” (MVC) I tre livelli (ed i relativi Componenti J2EE)

J2EE, un'architettura a tre livelli – 2 ● View: livello di Presentazione, che si occupa di fornire al Client i risultati dell'elaborazione L'architettura J2EE prevede che il livello Presentation sia implementato per mezzo di JSP ● Controller: livello di Controllo, che si occupa dell'aspetto algoritmico dell'elaborazione e della coordinazione dei diversi moduli dell'applicazione L'architettura J2EE prevede che il livello Model sia implementato per mezzo di Servlet

Client 1 Client 3 Web Container EJB Container Application Server DB #1DB #2 XML LDAP Altro... Servlet 1Servlet 2Servlet 3JSP 1JSP 2JSP 3JSP 4 EJB 1 EJB 2EJB 3 EJB 4 EJB 5 EJB 6

Architettura 3 – tier: vantaggi ● Modularità ● Figure diverse sviluppano componenti diverse ● Modificabiltà (da Modularità) delle modalità e delle politiche di accesso ai dati ● Sicurezza: ogni livello può essere protetto indipendentemente dagli altri ● Standardizzazione (e, di nuovo, Modificabilità)

Architettura 3 – tier: svantaggi ● Necessità di comprendere l'architettura prima di sviluppare applicazioni ● Anche lapiù semplice applicazione richiede Scaffolding Code (Codice d'infrastruttura) [ma vedremo come ovviare...] ● Efficienza: l'architettura è pesante, gli Application Server sono scritti in Java (che non è un fulmine di guerra)

J2EE: Un gioco di ruolo... ● Suddivisione (esplicita) del lavoro tra figure identificate con Ruoli (lato sviluppo) Ogni “Role” si occupa di un aspetto delprocesso di sviluppo ● Autorizzazioni di accesso basate su Ruoli (lato utente) Ogni risorsa (Servlet, JSP, metodo di EJB) è accessibile agli utenti associati a determinati “Roles”

J2EE: Ruoli di sviluppo - 1 Ruoli di sviluppo previsti dalle specifiche SUN ● Enterprise Bean Provider ● Application Assembler ● Deployer (viva i neologismi: “deployare”) ● EJB Server Provider ● EJB Container Provider ● System Administrator [Ovviamente, una stessa persona può ricoprire più ruoli...]

J2EE: Ruoli di sviluppo – 2 ● Enterprise Bean Provider Si occupa dello sviluppo delle classi e delle interfacce che definiscono il comportamento di un EJB: tipicamente è un esperto di dominio che sviluppa Beans riusabili che implementano per lo più logica di businness o modellano entità del dominio ● Application Assembler Combina Beans diversi in un'unica unità (ejb-jar file) “deployabile”, aggungendo informazioni di deploy (Deployment Descriptors)

J2EE: Ruoli di sviluppo – 3 ● Deployer Prende uno o più ejb-jar e li “deploya” in uno specifico ambiente operativo, effettuando eventuali configurazioni dell'ambiente in questione (DataSources,...) ● EJB Server & Container Provider In genere, è uno specialista nell'area delle transazioni distribuite e di altri servizi di basso livello. Offre i tools necessari per il deploy di applicazioni ed il supporto di run-time per le istanze dei Beans

J2EE: Ruoli di sviluppo – 4 ● Amministratore di Sistema E' responsabile di configurazione ed amministrazione dell'infrastruttura entro cui “vive” l'ambiente operativo (Application Server) Ovviamente, analoga suddivisione di ruoli è prevista per lo sviluppo dei moduli Web di un'applicazione J2EE

Ruoli di sviluppo: perchè ? ● Ognuno fa (solo !!!) ciò di cui è esperto ● Modularità ed indipendenza tra un ambito e l'altro: posso modificare ogni “strato”, dal SO al Server ai DB, senza coinvolgere tutta l'applicazione (e tutto il gruppo di sviluppo !!!)

Ruoli di accesso: perchè ? ● Autenticazione ed autorizzazione: differenze ● Modificabilità dei permessi di accesso senza (o quasi...) toccare il codice ● Il “codice” si occupa di FARE ● I descrittori (DDs) assegnano permessi di accesso a categorie (Roles) di utenti ● Repository di autenticazione / autorizzazione associano Ruoli ad Utenti

Autenticazione ed Autorizzazione ● Autenticazione Verificare se la coppia corrisponde ad un utente registrato ● Autorizzazione Se l'Autenticazione non fallisce, verifica quali Ruoli sono associati all'utente “loggato” ● La piattaforma J2EE permette esclusivamente l'esecuzione di moduli accessibili ai ruoli riconosciuti

Chi si occupa di che cosa ? ● L'Enterprise Bean Provider scrive codice indipendente da logiche di protezione / accesso ● L'Application Assembler assegna ogni risorsa ad uno o più Ruoli autorizzati all'esecuzione / accesso ● Il Deployer associa i diversi moduli a logiche (Policy) di Autenticazione / Autorizzazione specifiche della piattaforma (AS) specifica scelta ● L'EJB Server Provider si occupa di configurarle

Come si configura una Policy JAAS ● JAAS sta per Java Authentication and Autorization Service ● Si indicano all'Application Server: – Il tipo di Repository di sicurezza da utilizzare – I criteri di reperimento / confronto di password – I criteri di reperimento dei Ruoli degli utenti – Il nome che le applicazioni devono utilizzare per accedere a questa Policy JAAS

Accesso secondo JAAS: vantaggi ● Codice e politiche di accesso indipendenti (ma c'è codice più indipendente di altro...): Aspect Oriented Programming... ● Di conseguenza: sviluppo più veloce, modificabilità, estrema flessibilità ● Sicurezza: ci si appoggia a sistemi e librerie di autenticazione ed autorizzazione testate ● Moduli / Applicazioni diverse possono condividere facilmente e naturalmente criteri di protezione d'accesso

JAAS: Tipologie di repository per le Policy In generale dipendono dalla piattaforma (AS) scelto ● Database (via JDBC) ● Server LDAP ● File locale ● SO locale

Piattaforma J2EE: servizi - 1 ● RMI: Remote Module Invocation ● JDBC: Java Database Connectivity ● JSP: Java Server Pages ● Servlet API ● EJB Api ● JNDI: Java Naming Directory Interface ● RMI-IIOP: RMI over Internet Inter-Orb Protocol ● JMS: Java Message Service

Piattaforma J2EE: servizi – 2 ● Java Mail ● JAF: JavaBeans Activation Framework ● JTA: Java Transaction API ● XML: Extensible Markup Language ● JMX: Java Management Extensions

Enterprise Java Bean: tipologie - 1 Esistono tre tipologie di EJB (secondo le specifiche EJB 2.0), ognuna soddivisa in due sotto-tipologie ● Entity Bean – CMP (Container Managed Persistence) La persistenza è gestita dal server, le informazioni ed eventuali query SQL sono definite dei DD mediante EJB-QL. Veloce ed “error - safe” – BMP (Bean Managed Persistence) La persistenza va codificata in fase di sviluppo. Più flessibile (ad es: repository non relazionali)

Enterprise Java Bean: tipologie – 2 ● Session Bean – Stateless (l'idea è la stessa dei Servlet: una stessa istanza può rispondere a richieste diverse) – Stateful (corrispondenza 1 – 1 tra client invocante ed oggetto servente) ● MDB (Message Driven Bean) – Queue (un ascoltatore consuma il messaggio) – Topic (tutti gli ascoltatori)

Enterprise Java Bean e Scaffolding Code Per sviluppare un EJB è richiesta la realizzazione di un certo numero di classi ed interfacce: ● Una INTERFACCIA che specifica i metodi pubblicati dall'EJB: l'accesso effettivo al Bean avviene attraverso oggetti di questo tipo ● Una INTERFACCIA “Home” che permette di creare / ricercare / distruggere istanze dell'EJB ● Una CLASSE che fornisce l'implementazione effettiva dell'EJB

Packages ● Ogni interfaccia (Home e del Bean) può essere Locale (accesso limitato alla VM) o Remota (accesso “totale”) ● Il package “fondamentale” è javax.ejb ● Le interfacce [locali] del Bean estendono l'interfaccia EJB[Local]Object ● Le interfacce Home estendono l'interfaccia EJB[Local]Home ● La classe del Bean implementa l'interfaccia SessionBean, EntityBean o MessageDrivenBean

Sviluppo e Scaffolding Code ● Per Scaffolding Code s'intende l'insieme di tutti gli elementi d'infrastruttura necessari alla realizzazione di un'applicazione J2EE: interfacce dei Bean, descrittori di Bean e Servlet ● Ambienti di sviluppo grafici permettono la generazione di tale codice mediante semplici GUI ● Xdoclet con Ant: chi non commenta il codice muore !!!

Ant, la formichina operosa -1 ● Makefile e limiti (sintassi, scarsissima portabilità) ● XML (eXtensible Markup Language) come Esperanto informatico: consorzio W3C, XML e dati, XSLT e rappresentazione ● Ant come “make” multipiattaforma (e molto, molto più chiaro da configurare). ●

Ant, la formichina operosa -2 Ant si basa su un file di configurazione XML, nel quale è possibile utilizzare TAG predefiniti di Ant (estrema varietà: dalla compilazione all'impacchettamento, dall'interazione con DB relazionali o con server CVS al deploy via FTP...) Quindi: ● Editing codice mediante un editor qualsiasi ● Ant (esteso con XDoclet) crea lo SC, compila, copia (e sostituisce !!!), impacchetta, deploya ● Qualitas: classi di 30 righe, buildfile di 750

Altri strumenti di sviluppo (free) ● Sun One Studio (le ultime versioni non sono free) ● Netbeans (free, ottima per lo sviluppo di applicazioni grafiche basate su swing / awt): supporta Servlet e JSP ma non EJB ● Eclipse, l'ambiente universale ● JEdit, un editor “più uguale degli altri” ● Piattaforme commerciali dispongono di ambienti di sviluppo properietari associati

Piattaforme J2EE SUN standardizza SPECIFICHE e fornisce un'implementazione di riferimento: J2EE Sun Application Server (Free) L'AS più famoso (ambito Web: non supporta infatti gli EJB), riferimento per l'implementazione di Web Container, è Apache Tomcat (open source) JBoss è un AS completo, certificato J2EE 1.3, open source IBM WebSphere e Bea WebLogic sono i due AS commerciali più noti

Un esempio di ambiente operativo ● AS JBoss integrato con Tomcat (o con Jetty) ● Sviluppo e codifica mediante editor di testo general porpouse (JEdit, Kate,...) ● Generazione di Scaffolding Code mediante XDoclet (Che genera anche i DD specifici per i diversi AS, mediante TAG dedicati) ● Impacchettamento mediante Ant

J2EE: questione di pacchetti... ● Un'applicazione J2EE è costituita da un archivio EAR (Enterprise ARchive, si tratta di un file Jar con estensione EAR) ● Un EAR contiene archivi WAR e JAR ● WAR (web Archive) per i moduli Web ● JAR per gli EJB ● Ogni archivio contiene un DDJ2EE ed eventuali DDs specifici della piattaforma di deploy scelta

J2EE: Pacchetti e descrittori ● JAR --> ejb-jar.xml Associa interfacce e classi di un bean in una singola entità, definisce i permessi di accesso ai singoli metodi ● WAR --> web.xml Mappa le classi dei Servlet su specifici URL, definisce i permessi di accesso alle risorse Web e le modalità di autenticazione (Form) ● EAR --> application.xml Elenca i moduli JAR e WAR, ed associa ogni WAR ad un URL specifico

Conclusioni ● J2EE è un'architettura per Applicazioni basate (principalmente:...) su Web ● J2EE è una specifica per piattaforme ● Modularità, divisione dei compiti, fruizione dei servizi forniti dalla piattaforma (JAAS, DS,...) ● Robustezza e Sicurezza di Java ● Riusabilità di moduli e servizi ● Chi va piano, va sano e va lontano

Appendice ● Castor, un framework per la gestione del Marshaling Java --> XML e dell'Unmarshaling XML --> Java ● Mondo XML: DOM ed XSLT ● J2SDK ● Qualche esempio ● Riferimenti ● Per chiarimenti e curiosità: