Riassunto Libro - Beginning Java EE 7 PDF

Preview

Summary

Riassunto italiano del libro Beginning Java EE 7...

Description

PROGRAMMAZIONE DISTRIBUITA RIASSUNTO DEL CORSO DI PD AA 2018/2019

Sommario Introduzione a Java EE........................................................................................................................................................2 1. Perché Java EE (motivazioni)?....................................................................................................................................2 2. Architettura................................................................................................................................................................3 2.1 Multilayer e Multitier...........................................................................................................................................3 2.2 Container..............................................................................................................................................................6 2.3 Packaging..............................................................................................................................................................8 2.4 Annotazioni e Deployment Descriptor.................................................................................................................9 3. Ecosistema Java EE...................................................................................................................................................11 3.1 Standard.............................................................................................................................................................11 3.2 Storia..................................................................................................................................................................11 3.3 Tecnologia..........................................................................................................................................................11 JEE Context and Dependency Injection............................................................................................................................14

Introduzione a Java EE 1. Perché Java EE (motivazioni)? Oggi le imprese vivono in mondo competitivo. Esse hanno la necessità di estendere la loro capacità di soddisfare clienti, dipendenti e fornitori con costi più bassi e tempi di risposta minori nel fornire i servizi richiesti. Le aziende sono distribuite sui continenti, operano 24 ore su 24, 7 giorni su 7 su Internet e in diversi paesi, hanno diversi data center e sistemi che devono gestire le valute e fusi orari diversi, il tutto riducendo i costi, tempi di risposta dei loro servizi, memorizzando i dati su uno storage affidabile e sicuro. In genere, le applicazioni che forniscono questi servizi devono integrare sistemi informativi aziendali esistenti (EIS (Enterprise Information System) con nuove funzioni aziendali che offrono servizi ad una vasta gamma di utenti. I servizi devono essere:  Altamente disponibili, per soddisfare le esigenze di ambienti di business globali.  Sicuri, per proteggere la privacy degli utenti e l’integrità dell’impresa.  Affidabili e scalabili, per garantire che le transazioni commerciali siano accurate e che avvengano in tempi brevi.  Enterprise application (applicazioni aziendali) devono affrontare cambiamenti e complessità e devono essere robuste. Proprio per questo è stato creato Java Enterprise Edition (Java EE o JEE). Obiettivo: sviluppare applicazioni distribuite, transazionali, portabili che sfruttano la velocità, sicurezza e affidabilità del tecnologia lato server. Scopo Java EE: fornire agli sviluppatori un potente set di API che permettono di ridurre i tempi di sviluppo, riduzione della complessità dell’applicazione e miglioramento delle prestazioni dell’applicazione. Java EE fornisce un modo standard per gestire la transazioni con Java Transaction API (JTA), scambio di messaggi con Java Message Service (JMS), gestione dei DB con Java Persistence API (JPA). Java EE è un insieme di specifiche progettate per le applicazioni enterprise.

2. Architettura 2.1 Multilayer e Multitier Le applicazioni Java EE seguono un’architettura multitiered distribuita. Questo significa che la logica applicativa è divisa in componenti in base alla funzionalità, e le varie componenti che insieme formano l’applicazione Java EE sono installate su macchine diverse a seconda di quale tier la componente appartiene. La Figura 1 mostra due applicazioni Java EE multitier e le parti di cui esse sono composte:  Le componenti del Client Tier sono eseguite sulla macchina client.  Le componenti del Web Tier sono in esecuzione sul Server Java EE.  Le componenti del Business Tier sono in esecuzione sel server Java EE.  Il software dell’Enterprise Information System (EIS) Tier è eseguito sul server EIS. Anche se un’applicazione Java EE può consistere di tre o quattro tiers come mostrato in Figura 1, le applicazioni Java EE sono generalmente considerate three-tiered perché sono sidtribuite su tre differenti locazioni: macchine client, server Java EE e database o sistemi legacy. applicazioni three-tiered che vengono eseguite in questo modo estendono il modello standard client-server collocando un’applicazione server multithreaded tra l’applicazione client e lo storage back-end.

Le

FIGURA 1 2.1.1 Componenti Un’applicazione Java EE è composta da componenti. Una componente è un’unita software funzionale che è assemblata in un’applicazione Java EE con le relative classi e file e che comunica con altre componenti. La specifica di Java EE definisce questi tipi di componenti:  Application Client e le applets sono componenti del client tier (quindi eseguite sulle macchine client).  Java Servlet e JavaServer Pages (JSP) sono componenti del web tier (quindi eseguite dal server).  Enterprise JavaBeans (EJB) sono componenti del business tier (quindi eseguite dal server). Le componenti Java EE sono scritte nel linguaggio Java e compilate nello stesso modo di qualsiasi altro programma Java. La differenza quando si lavora con la piattaforma Java EE è che le componenti Java EE sono assemblate in un’applicazione Java EE, verificato che esse siano conformi con le specifiche Java E, e installate (deployed), eseguite e gestite dal server Java EE.

2.1.2 Componenti del Client Tier Un client Java EE solitamente o è una client application oppure è un client web. 2.1.2.1 APPLICATION CLIENT Un’applicazione client viene eseguita su una macchina client e fornisce un modo all’utente di poter gestire i compiti che richiedono un’interfaccia utente più ricca di quella che può essere fornita da un markup language (html). Tipicamente sono interfacce grafiche utente (GUI - creata generalmente con le APIs AWT) o interfacce a linea di comando. Un’applicazione cliente accede direttamente agli EJB in esecuzione nel Business Tier. Tuttavia, se i requisiti dell’applicazione client Java EE lo richiedono, un’applicazione client può aprire una connessione HTTP per stabilire una comunicazione con una servlet in esecuzione nel web tier.

Le applicazioni client scritte in linguaggi diversi da Java possono interagire con i server Java EE. Questo consente alla piattaforma Java EE di poter interagire con vecchi sistemi e client che non sono scritti in Java.

2.1.2.2 WEB CLIENT Consiste di due parti: 1. Pagine web statiche o dinamiche contenenti vari tipi di markup language (HTML, XML, e così via), le quali sono generate da componenti web che vengono eseguiti nel Web Tier. 2. Un web browser che si occupa del rendering delle pagine ricevute dal server Un web client è spesso chiamato thin client: generalmente non interrogano il DB, eseguono complesse business rules o si connettono ad applicazioni legacy. Quando si usa un thin client, le operazioni più pesanti vengono scaricate sui EJB che sono in esecuzione sul server Java EE, in modo da poter sfruttare la sicurezza, velocità, servizi e affidabilità del server

2.1.2.3 APPLETS Una pagina web scaricata dal web tier può includere una applet. Una applet è una piccola applicazione client scritta in Java e che viene eseguita nella Java VM installata nel web browser. Tuttavia, i sistemi client avranno probabilmente bisogno del Plug-in Java e probabilmente di un file di politica di sicurezza affinché l’applet possa essere eseguito correttamente nel browser web. Le componenti web sono le API preferite per la creazione di un programma web client perché non sono necessari plug-in o file sulla policy di sicurezza nei sistemi client. Inoltre, le componenti web consentono un design dell’applicazione più pulito e modulare perché forniscono un modo per separare i programmi applicativi dal design delle pagine web. Il personale coinvolto nel design delle pagine web quindi non hanno bisogno di capire la sintassi del linguaggio Java per fare il loro lavoro.

2.1.2.4 JAVABEANS COMPONENTS Il client tier potrebbe anche includere una componente basata sull’architettura JavaBeans per gestire il flusso di dati tra un’applicazione client o applet e le componenti in esecuzione sul server Java EE. Le componenti JavaBeans non sono considerate componenti dalla specifica di Java EE. Le componenti JavaBeans scritte per la piattaforma Java EE hanno variabili d’istanza e metodi get e set per accedere ai dati delle variabili. Le componenti JavaBeans usate in questo modo sono tipicamente semplici nel design e nell’implementazione, ma dovrebbero essere conformi alle convenzioni sui nomi e sul design definite nell’architettura delle componenti JavaBeans.

2.1.2.5 COMUNICAZIONE TRA CLIENT E JAVA EE SERVER La Figura 2 mostra i vari elementi che possono formare il client tier. Il

client comunica con il business tier in esecuzione sul server sia direttamente o, nel caso che il client sia in esecuzione in un browser, passando attraverso pagine web JSP o servlet in esecuzione nel web tier.

FIGURA 2

2.1.3 Componenti del Web Tier Sono le servlet o le pagine web create con JavaServer Pages (JSP) o JavaServer Faces (JSF). Le servlet sono classi Java che dinamicamente processano le richieste e costruiscono le risposte Le pagine JSP sono documenti di testo con contenuto statico e frammenti (snippets) di codice Java per generare contenuto dinamico. Quando una pagina JSP viene caricata, una servlet in background esegue il codice negli snippets e ritorna la risposta. La tecnologia JavaServer Faces, costruita sulle servlet e la tecnlogia JSP, offre un framework per l’interfaccia utente per applicazioni web. Le pagine statiche HTML e le applets sono entrambe impacchettate (bundled) con le componenti web durante l’assembramento dell’applicazione, ma non sono considerate componenti web dalla specifica Java EE. Altre classi di utility al lato server possono essere impacchettate con le componenti web e, come le pagine HTML, non sono considerate componenti web esse stesse. Come mostrato nella Figura 3, il web tier, come il client tier, potrebbe includere una componente JavaBeans per gestire l’input fornito dall’utente e inviare tale input all’EJB in esecuzione nel business tier per essere processato.

FIGURA 3

2.1.4 Componenti del Business Tier Il business code, che rappresenta la logica applicativa che risolve o soddisfa le esigenze di un particolare dominio aziendale come banche, vendite al dettaglio o finanza, è gestita da EJB in esecuzione o nel business tier oppure nel web tier. La Figura 4 mostra come un EJB riceve dati dal client, li processa (se necessario) e poi li invia all’enterprise information system (EIS) per la memorizzazione. Un EJB può recuperare i dati dal DB, processarli (se necessario) e inviarli al client.

FIGURA 4

2.1.5 Componenti dell’EIS Tier Il tier sistema informativo aziendale (enterprise information system EIS) gestisce il software EIS e include i sistemi aziendali quali ERP (Enterprise Resource Planning), sistemi per basi di dati e altri sistemi informativi legacy. Per esempio, una componente Java EE potrebbe accedere al EIS per stabilire una connessione con il DB.

2.2 Container Le applicazioni client con l’architettura multi-tier sono difficili da scrivere perché coinvolgono molte linee di codice per manipolare le transazioni e gestione dello stato, multithreading, etc. L’architettura Java EE basato su componenti rende le applicazioni facili da scrivere perché la business logic è organizzata in componenti riusabili e i Java EE server forniscono i servizi sottostanti nella forma di un container per ogni tipo di componente. I container sono ambienti d’esecuzione di Java EE che forniscono certi servizi alle componenti che ospitano, come la gestione del ciclo di vita, dependency injection, concorrenza etc. Queste componenti usano contratti ben definiti per comunicare con l’infrastruttura Java EE e con le altre componenti. Devono essere impacchettate (packaged) in modo standard (seguende una definita struttura della directory che può essere compressa in file archivi) prima di essere installati (deployed).

2.2.1 Tipi di Container Ogni container ha uno specifico ruolo, supporta un insieme di API, e offre servizi ai componenti (sicurezza, accesso al DB, gestione delle transazioni, etc.). I container nascondono la complessità tecnica e aumentano la portabilità. Java EE ha quattro tipi differenti di container:  Applet Container: fornito dalla maggior parte dei browser per eseguire le applet. Quando si sviluppa una applet, bisogna concentrarsi sull’aspetto grafico dell’applicazione mentre il container fornisce un ambiente sicuro. L’applet container usa un modello di sicurezza detto sandbox (buco nella sabbia) dove il codice eseguito nel sandbox non può essere eseguito “fuori dal sandbox”. Questo significa che il container impedisce al codice scaricato nel computer locale di accedere alle risorse del sistema, come processi e file.  Application client container (ACC) sono i client (main()) usati per invocare i servizi. ACC comunica con l’EJB container usando RMI-IIOP e il web container con HTTP (es. per web service)  Web container: fornisce i servizi sottostanti per la gestione e l’esecuzione dei web components (servlet, EJBs Lite, JSPs, JSF pages, web services). È responsabile dell’instanziazione, inizializzazione e invocazione di servlet e supporta i protocolli http e HTTPS. È il container utilizzato per fornire pagine web ai client browser.  EJB container: è responsabile per la gestione dell’esecuzione degli enterprise bean (session bean e message-driven beans) che contengono la logica applicativa dell’applicazione Java EE. Crea nuove instanze dei EJBs, gestisce i loro cicli di vita e fornisce i servizi come transazione, sicurezza, concorrenza, etc.

2.2.2 Servizi dei Container Le componenti sono installate nei loro container durante il deployment. Prima che possa essere eseguita, una componente del web client (enterprise bean) o del application client deve essere assemblata in un modulo Java EE e installato nel suo container. Il processo di assemblamento coinvolge la specifica delle impostazioni del container per ogni componente nell’applicazione Java EE e per l’applicazione Java EE stessa. Le impostazioni del container personalizzano il supporto sottostante fornito dal server Java EE, includendo servizi come sicurezza, gestione delle transazioni, le ricerche sulle API di Java Naming and Direcotry Interface (JNDI), e la connettività remota. I container quindi offrono i seguenti servizi:  La Java Transaction API di Java EE permette di specificare le relazioni tra i metodi che formano una singola transazione così che i tutti i metodi di una transazione vengano trattati come una singola unità.  La Java Persistance API sono API standard per ORM (Object Relationship Mapping). Con JPQL (Java Persistence Query Language), possiamo interrogare i database sottostanti.  

La Validazione dei Bean tramite la dichiarazione di vincoli a livello di metodi e classi. Lo Java Message Service consente alle componenti di comunicare in modo asincrono attraverso messaggi. Supporta la messaggistica affidabile point-to-point (P2P) e il modello publish-subscribe (pub-sub).



         

I servizi di ricerca della API Java Naming and Directory Interface (JNDI) forniscono un’interfaccia unificata ai molteplici servizi di naming e directory nell’azienda, in modo che le componenti dell’applicazione possano accedere a questi servizi. L’applicazione usa questo servizio per associare (bind) un nome ad un oggetto e poi trovare questo oggetto (lookup) in una directory. La API di JavaMail consente l’invio di email. La JAF API (JavaBeans Activation Framework) consente la gestione di dati di differenti MIME type. È usato da JavaMail. La JAXP (Java API for XML processing) supporta il parsing dei documenti con API SAX e DOM. La JSON-P (JSON Processing) API consente alle applicazione di generare e trasformare query JSON. La Java EE Connector Architecture consente l’accesso a EIS da componente Java EE. Il modello di sicurezza di Java EE permette di configurare una componente web o EJB affinchè l’accesso alle Java Authentication and Authorization Service (JAAS - Java Authentication and Authorization Service). I Web Services sono servizi interoperabili eseguiti su una qualsiasi macchina, scritti in un qualsiasi linguaggio di programmazione ed eseguiti su un qualsiasi sistema operativo. Dependency Injection, cioè l’iniezione (injection) di risorse (data source, JMS factories, persistence units, EJB, …) nelle componenti. Java EE definisce delle API per la gestione dei container e dei server usando speciali EJB. La Java EE Deployment Specification definisce un contratto tra i tool di deployment e i prodotti Java EE per standardizzare il deployment delle applicazioni.

Poiché l’architettura di Java EE fornisce servizi configurabili, le componenti nella stessa applicazione possono comportarsi in modo diverso in base a dove vengono installate (deployed). Per esempio, un EJB può avere delle impostazioni di sicurezza che consentono un certo livello di accesso ai dati del database in un ambiente di produzione e un altro livello di accesso al database in un altro ambiente di sviluppo. Il container gestisce anche servizi non configurabili, come i cicli di vista dei EJB e delle servlet, pool di risorse per la connessione al database, persistenza dei dati, e accesso alle API della piattaforma Java EE. La Figura 5 mostra i servizi forniti dai container.

FIGURA 5

2.3 Packaging Prima di essere installate (deployed) in un container, le componenti devono essere prima impaccettate (packaged) in un archivio standard. Java SE definisce i file Java Archive (jar), che sono usati per aggregare diversi file (classi Java, deployment descriptor, risorse, o librerie esterne) in un unico file compresso (basato sul formato ZIP). Come mostrato in Figura 6, Java EE definisce diversi tipi di moduli che hanno un proprio formato di packaging basato su questo comune formato jar.

FIGURA 6  Un Application client module contiene classi Java e altre risorse che vengono inseriti in un file jar. Questo file jar può essere eseguito in un ambiente Java SE o in un ACC. Come qualsiasi altro formato archivio, il file jar contiene un opzionale META-INF directory per metainformazioni che descrivono l’archivio. Il file META-INF/MANIFEST.MF è usato per definire l’estensione e il packaging dei dati. Se deployato in un ACC, il deployment descriptor può essere opzionalmente collocato in META-INF/application-client.xml.  Un EJB module contiene uno o più bean session e / o message-driven bean (MDB) che vengono inseriti in un file jar (spesso chiamato EJB jar file). Esso contiene un deployment desccriptor opzionale chiamato META-INF/ejb-jar.xml e può essere deployato solo nell’EJB container.  Un Web application module contiene servlet, JSP e web service e altri file relativi al web (HTML, CSS, JavaScript, immagini, video, etc.). Tutti questi artefatti vengono inseriti in un file jar con estenzione .war (che fa riferimento a un Web Archive). Il web deployment descriptor opzionale è definito nel file WEB-INF/web.xml. Le classi Java (.class) sono messe in WEB-INF/classes e i file jar da cui dipendono in WEB...