Scarica Java EE Ita - Traduzione e riassunto capitolo1 - Beginning Java EE 7 e più Traduzioni in PDF di Programmazione Java solo su Docsity!
Introduzione a Java EE
JEET 1-Overview
Oggi gli sviluppatori sentono sempre di più il bisogno di sviluppare applicazioni distribuite, transazionali e portabili che sfruttino velocità, sicurezza e affidabilità di tecnologie lato server.
Le applicazioni enterprise spesso interagiscono con altri software enterprise (sistemi legacy) e devono essere progettate, costruite e prodotte con meno soldi, con una maggiore velocità e con meno risorse.
Lo scopo di Java EE è quello di fornire agli sviluppatori un potente insieme di API che accorcino i tempi di sviluppo, riducano la complessità delle applicazioni e migliorino le prestazioni.
La piattaforma Java EE viene sviluppata attraverso il Java Community Process (JCP), che è il responsabile di tutte le tecnologie Java. Gruppi di esperti hanno creato Java Specification Requests (JSR) per definire le diverse tecnologie Java EE. Il lavoro della comunità Java nel programma JCP contribuisce a garantire gli standard di stabilità e la compatibilità tra piattaforme della tecnologia Java.
Il deployment descriptor in XML è opzionale. Uno sviluppatore può semplicemente inserire le informazioni come annotazioni, direttamente nel codice sorgente. Queste annotazioni sono generalmente utilizzate per incorporare in un programma dati che altrimenti sarebbero forniti in un deployment descriptor. (Le annotazioni sono più semplici, ma il file XML è più potente. Inoltre usando l’XML possiamo effettuare facilmente dei cambiamenti, mentre per effettuare modifiche con le annotazioni bisogna accedere al codice sorgente. L’XML sovrascrive le annotazioni).
Nella piattaforma Java EE, la dependency-injection può essere applicata a tutte le risorse necessarie a un componente, nascondendo la creazione e il lookup (ricerca) di risorse dal codice applicativo. La dependency-injection può essere utilizzata dagli Enterprise JavaBeans (EJB) container, web container e application client. La dependency-injection consente al container Java EE di inserire automaticamente riferimenti ad altri componenti o risorse necessari, utilizzando le annotazioni.
1.1 Java EE 7 Platform Highlights
L'obiettivo più importante della piattaforma Java EE 7 è quello di semplificare lo sviluppo fornendo una base comune per i diversi tipi di componenti della piattaforma Java EE. Gli sviluppatori traggono vantaggio dai miglioramenti della produttività con più annotazioni e meno configurazione XML, più Plain Old Java Object (POJO), e packaging semplificato.
1.2 Java EE Application Model
Java EE è progettato per supportare applicazioni che implementano servizi aziendali per clienti, dipendenti, fornitori, partner e altri. Sono applicazioni intrinsecamente complesse, potenzialmente accedono a dati provenienti da una varietà di fonti e distribuiscono applicazioni a una vasta gamma di client. Per migliorare il controllo e la gestione di queste applicazioni, le funzioni aziendali vengono condotte nel middle tier. Il middle tier rappresenta un ambiente strettamente controllato dal dipartimento informatico aziendale. Il middle tier è generalmente eseguito su un server dedicato e ha accesso ai servizi completi dell'enterprise.
Il modello di applicazione Java EE definisce un'architettura per l'implementazione di servizi come applicazioni multitier che offrono la scalabilità, l'accessibilità e la gestibilità necessarie per le applicazioni a livello enterprise. Il lavoro necessario per implementare un servizio multitier è diviso in:
La logica di business e di presentazione che lo sviluppatore deve implementare
I servizi di sistema standard forniti dalla piattaforma Java EE
Lo sviluppatore può contare sulla piattaforma per fornire soluzioni a problemi relativi allo sviluppo di un servizio multitier.
1.3 Distributed Multitiered Applications
La piattaforma Java EE utilizza un modello di applicazione distribuito multilivello di- stribuito per le applicazioni enterprise. La logica dell'applicazione è divisa in compo- nenti in base alla funzione e i componenti dell'applicazione che compongono un'ap- plicazione Java EE sono installati su varie macchine a seconda del livello nell'am- biente multiplo Java EE cui appartiene il componente dell'applicazione.
La logica dell’applicazione è suddivisa in component a seconda della loro funzione. I component che compongono un’applicazione Java EE vengono installati in varie macchine a seconda del tier nell'ambiente Java EE multitier a cui il component dell’applicazione appartiene.
La figura mostra due applicazioni Java EE multitier suddivise nei livelli descritti nell'elenco seguente.
Componenti del livello Client (Client-Tier) eseguiti sulla macchina client.
Componenti del livello Web (Web-tier) eseguiti sul server Java EE.
Componenti del livello Business (Business-Tier) eseguiti sul server Java EE.
Enterprise Information System (EIS)-Tier: software eseguito sul server EIS.
1.3.2 Java EE Components Le applicazioni Java EE sono costituite da Components. Un Java EE component è un’unità software funzionale self-contained assemblata in una Java EE application con classi e file, e che comunica con altre components.
La specifica Java EE definisce i seguenti componets:
Application clients e Applets sono components eseguiti sul client
Java Servlet, JavaServer Faces, e JavaServer Pages (JSP) sono web components eseguiti sul server
EJB components (enterprise beans) sono business components eseguti sul server.
I Components Java EE sono scritti nel linguaggio di programmazione Java e sono compilati allo stesso modo di qualsiasi programma di quel linguaggio. Le differenze tra i Java EE components e le classi Java "standard" sono che i components Java EE vengono assemblati in un'applicazione Java EE, viene verificato che siano conformi alla specifica Java EE, ne viene fatto il deploy e poi vengono eseguiti e gestiti dal server Java EE.
1.3.3 Java EE Clients Un client Java EE è solitamente un Web Client o un’Application Client.
1.3.3.1 Web Clients Un client web consiste di due parti:
- Pagine web dinamiche, contenenti vari tipi di linguaggi di markup(HTML, XML, ecc), generate dai web components eseguiti nel Web Tier
- Un Web Browser che fa il rendering delle pagine ricevute
Un client web è detto thin client perché non fa operazioni pesanti come query ad un database che invece sono a carico degli EJB eseguiti sul server.
1.3.3.2 Application Clients Un application client viene eseguito su una macchina client e fornisce agli utenti per gestire le attività che richiedono un'interfaccia utente più ricca di quanto possa essere fornito da un linguaggio di markup. Un Application Client ha in genere un'interfaccia utente grafica (GUI) Gli application client accedono direttamente agli Enterprise Beans eseguiti nel Business-Tier. Tuttavia, un application client può aprire una connessione http per stabilire la comunicazione con una servlet in esecuzione nel Web-Tier. Gli application
client scritti in linguaggi diversi da Java possono interagire con i server Java EE, consentendo alla piattaforma Java EE di interagire con sistemi legacy, client e linguaggi non java.
1.3.3.3 Applets Scritta in Java, un applet è una piccola applicazione client eseguita nella JVM installata nel browser. Per essere eseguito ha bisogno di un Plug-in java e di un file di security policy. I Web component sono preferiti per la creazione di un programma client web perché non sono necessari plug-in o file di policy. Inoltre, forniscono un modo per separare la programmazione dell’applicazione dal design delle pagine web.
1.3.3.4 The JavaBeans Component Architecture Server e client tier includono components basati su JavaBeans component architecture per gestire il flusso tra : Application Client o Applet e i Component eseguiti sul server Java EE. Server Components e database
JavaBeans components non sono considerati Java EE components. I componenti JavaBeans hanno attributi e hanno metodi get e set per l'accesso a quegli attributi.
1.3.3.5 Java EE Server Communications La figura mosta gli elementi del Client-Tier. Il client comunica con il Business Tier o direttamente o attraverso pagine web e servlet eseguite nel web tier.
1.3.5 Business Components Il business code è la logica che risolve o soddisfa le esigenze di un particolare dominio di business, come quello bancario, vendita al dettaglio o finanza, viene gestito dagli enterprise beans eseguiti nel Business Tier o nel Web Tier. La figura mostra come un enterprise bean riceve i dati dal client li processa e il manda all’Enterprise Information System Tier (EIS) per la memorizzazione. Inoltre un EJB riceve i dati dallo storage li processa e il rimanda al client
1.3.6 Enterprise Information System Tier L’ enterprise information system tier gestisce l’ EIS software e include, Enterprise Resource Planning, database, mainframe Transaction processing e altri sistemi legacy.
1.4 Java EE Containers
Normalmente, le applicazioni multilivello thin client sono difficili da scrivere perché coinvolgono molte linee di codice per gestire Transaction e la gestione dello stato, multithreading, pool di risorse e altri dettagli complessi di basso livello. L'architettura Java EE rende le applicazioni semplici da scrivere perché la business logic è organizzata in componenti riutilizzabili. Inoltre, il server Java EE fornisce i servizi sottostanti sotto forma di un Container per ogni tipo di Component. Così lo sviluppatore è libero di concentrarsi sulla soluzione del problema aziendale.
1.4.1 Container Services I container sono l'interfaccia tra un Component e la funzionalità di basso livello specifiche per la piattaforma. Per essere eseguito, un component (web, enterprise bean, application client) dev’essere assemblato in un modulo Java EE e dev’essere fatto il deploy nel suo container. Il processo di assemblaggio prevede la specifica delle impostazioni del Container per ciascun component nell’aapplicazione Java EE e per l'applicazione Java EE stessa. Le impostazioni del container personalizzano il supporto fornito dal server Java EE, come ad esempio sicurezza, gestione delle transaction, Java Naming and Directory Interface (JNDI), look-up, connessione remota.
Ecco i punti più importanti:
Java EE security model consente di configurare un web component o un enterprise bean in modo che le risorse siano accessibili solo da utenti autorizzati.
Java EE transaction model fa in modo che tutti i metodi in una transazione siano trattati come una singola unità.
I servizzi di Lookup JNDI forniscono un'interfaccia unificata a più servizi di naming in modo che i component possano accedere a questi servizi.
Java EE remote connectivity gestisce comunicazioni a basso livello tra client ed enterprise bean. Dopo aver creato un bean, un client invoca metodi su di esso come se fossero nella stessa macchina virtuale.
Poiché i servizi sono configurabili, i component possono comportarsi in modo diverso in base a dove vengono distribuiti. Ad esempio, un bean può avere impostazioni di protezione che consentono un certo livello di accesso al database in un ambiente e un altro livello di accesso al database in un altro ambiente. Il contenitore gestisce anche servizi non configurabili, come i cicli di vita di bean e servlet, database connection pool, la persistenza dei dati e l'accesso alle API della piattaforma Java EE.
1.6 Java EE Application Assembly and Deployment
Un’applicazione Java EE è packaged in una o più unità per il deployment su una Java EE platform. Ogni unità contiene: Uno o più functional component come enterprise bean, web page, servlet, o applet. Un deployment descriptor opzionale che ne descrive il contenuto. Il deployment tipicamente prevede l’uso di un deployment tool per specificare informazioni come la lista di utenti locali a cui è consentito l’accesso e il nome del database locale. Una volta fatto il deploy si può eseguire l’applicazione.
Context and Dependency Injection
La prima versione di Java EE ha introdotto il concetto di inversion of control (IoC), ciò significa che il container assume il controllo del business code e fornisce servizi tecnici (come transazione o gestione della sicurezza). Prendere il controllo ha significato gestire il ciclo di vita dei component, dependency injection e la configurazione dei components. Questi servizi sono stati integrati nel container ed i programmatori hanno dovuto attendere fino alle versioni successive di Java EE per potervi accedere. La configurazione dei component è stata resa possibile nelle prime versioni con i deployment descriptors XML, ma abbiamo dovuto attendere Java EE5 e Java EE6 per avere un’API semplice e robusta per la gestione del ciclo di vita e la dependency injection. Java EE6 ha introdotto Context and Dependency Injection per semplificare alcuni di questi problemi, ma soprattutto per renderla una specifica centrale che lega insieme tutti questi concetti. Oggi CDI trasforma quasi tutti i componenti Java EE in beans injectable (iniettabili), interceptable (intercettabili) e manageable (gestibili). CDI è costruito sul concetto di “loose coupling, strong typing”, ciò significa che i bean sono debolmente accoppiati ma viene mantenuta la tipizzazione forte. Il disaccoppiamento va ancora oltre grazie all’utilizzo di interceptor, decorator ed eventi sull’intera piattaforma. Allo stesso tempo, CDI unisce il livello web e il back-end, omogeneizzando gli ambiti.
Understanding Beans (Introduzione)
I POJO sono semplicemente classi java che vengono eseguite nella Java Virtual Machine (JVM). I Java Bean sono POJO che seguono determinate convenzioni (metodi getter e setter, costruttore di default) e vengono eseguiti nella JVM. Tutti gli altri components di JavaEE seguono un determinato pattern (ad esempio Enterprise JavaBean) e sono eseguiti in un container che fornisce dei servizi (ad esempio, il container EJB). Abbiamo dunque Managed Beans e Beans.
I Managed Beans sono oggetti gestiti dal container che supportano solo alcuni servizi di base: come resource injection, gestione del ciclo di vita e interception.
I Beans sono oggetti CDI basati sul modello dei Managed Beans. I Beans: hanno un ciclo di vita migliorato per oggetti stateful sono legati a contesti ben definiti. hanno un approccio typesafe alla dependency injection, interception e decoration specializzati con annotazioni qualifier possono essere usati in expression language (EL).
Infatti, con pochissime eccezioni, potenzialmente ogni classe Java che ha un costruttore di default e viene eseguito all'interno di un container è un bean. Quindi Java Beans e Enterprise Java Beans possono naturalmente trarre vantaggio da questi servizi CDI.
Scope and Context
I CDI Beans possono essere stateful e sono contestuali, il che significa che vivono in uno scope ben definito (CDI è dotato di scope predefiniti: request, session, application e conversation). Ad esempio, uno scope di sessione e i suoi bean esistono durante tutta la durata di una sessione HTTP. Durante questo tempo, gli injected references ai bean sono anche consapevoli del contesto, cioè l'intera catena delle dipendenze del bean è contestuale. Il container gestisce automaticamente tutti i bean all'interno dello scope e, alla fine della sessione, li distrugge automaticamente. A differenza dei componenti stateless (ad esempio, stateless session beans) o singleton (ad esempio, Servlets o singleton), i diversi client di un bean stateful vedono il bean in stati diversi. Quando un bean è stateful (session, application e conversation scope), è importante quale istanza del bean ha il client. I clienti eseguiti nello stesso contesto vedranno la stessa istanza del bean. Ma client in un contesto diverso potrebbero vedere un'altra istanza. In ogni caso non è il client a controllare il ciclo di vita dell’istanza, creandola e distruggendola: lo fa il container in base allo scopo.
Interception
Gli Interceptor sono utilizzati per interporsi prima dell’esecuzione di un business method. Da questo punto di vista è simile alla programmazione orientata agli aspetti (AOP). L'AOP è un paradigma di programmazione che separa le preoccupazioni trasversali dal business code. La maggior parte delle applicazioni ha codice comune che viene ripetuto tra i component. Questi potrebbero essere problemi come registrare l’entrata e l’uscita di ciascun metodo, registrare la durata di invocazione di un metodo, memorizzare statistiche sull’uso del metodo, ecc. o business concerns ( ad esempio eseguire controlli aggiuntivi se un cliente acquista più di $ 10.000 di articoli, inviare un ordine di ricarica quando il livello di inventario è troppo basso, ecc). Queste procedure possono essere applicate automaticamente tramite AOP all'intera applicazione o a un suo sottoinsieme. I Managed Beans supportano funzionalità AOP, fornendo la possibilità di intercettare l'invocazione del metodo tramite Interceptors. Questi vengono automaticamente invocati dal container quando viene richiamato un metodo.
Come mostrato in figura gli Interceptor possono essere concatenati e chiamati prima e/o dopo l'esecuzione di un metodo.
La Figura mostra un numero di Interceptor che vengono chiamati tra il client e i Managed Bean. Si potrebbe pensare a un contenitore EJB come a una catena di interceptor Quando si sviluppa un session bean ci si può concentrare sul business code ma, dietro le quinte, quando un client invoca un metodo sull’EJB, il container intercetta l'invocazione e applica diversi servizi (gestione del ciclo di vita, transazione, sicurezza, ecc.). Con gli Interceptor, si aggiungono i propri meccanismi in modo trasparente al business code.
Loose Coupling and Strong Typing
Gli Interceptors sono un modo molto efficace per disaccoppiare i problemi tecnici dalla logica di business. Contextual life-cycle management disaccoppia anche i bean dalla gestione dei propri cicli di vita. Con l’injection, un bean non è a conscenza dell’implementazione di qualsiasi bean con cui interagisce.I Beans possono usare evento notifications per disaccoppiare i produttori di eventi dai consumatori di eventi o Decorators per disaccoppiare i problemi di business. In altre parole, il basso accoppiamento è il DNA su cui è stato costruito CDI. E tutte queste strutture sono consegnate in modo tipicamente sicuro. CDI non si basa mai su identificatori basati su stringhe per determinare come gli oggetti si incastrano. CDI, invece, utilizza annotazioni fortemente tipizzate (ad es. Qualifiers, Stereotypes, e Interceptor bindings) per legare insieme i bean. L'utilizzo dei descrittori XML è ridotto ad informazioni veramente specifiche dell'implementazione
Deployment Descriptor
Quasi ogni specifica JavaEE ha un XML Deployment Descriptor opzionale. Di solito descrive come bisogna configurare un component, un modulo o un'applicazione. Con CDI, il Deployment Descriptor si chiama beans.xml ed è obbligatorio. Può essere utilizzato per configurare alcune funzionalità (Interceptors, Decorators, Alternatives, ecc.), ma è essenziale per abilitare CDI, questo perché il CDI ha bisogno di identificare i Beans nel class path. È durante la fase di Bean Discovery che avviene la magia: CDI trasforma un POJO in un CDI Bean. Al momento di deploy, il CDI controlla tutti i file jar e war dell’applicazione e ogni volta che trova un beans.xml gestisce tutti i POJOs facendoli diventare CDI Beans. Senza un file beans.xml nel class path (sotto la directory META-INF o WEB-INF), CDI non sarà in grado di utilizzare Injection, Interception, Decoration e così via. Se l’applicazione web contiene diversi file jar e si desidera avere CDI abilitati in tutta l'applicazione, ogni jar avrà bisogno del proprio beans.xml per attivare il rilevamento di CDI e bean discovery per ogni jar.
Dependency Injection
Java è un linguaggio di programmazione orientato agli oggetti, il che significa che il mondo reale viene rappresentato usando gli oggetti. Ad esempio, abbiamo una classe Book, un Cliente e un PurchaseOrder che indica che stai acquistando questo libro. Questi oggetti dipendono l'uno dall'altro: un libro può essere letto da un cliente e un ordine di acquisto si riferisce a diversi libri. Questa dipendenza è un valore del design orientato agli oggetti. Il processo di creazione di un libro (BookService) può essere ridotto all’istanziazione di un Book, generando un numero univoco usando un NumberGenerator e rendendo persistente il libro in un batabase. Il NumberGenerator può generare un ISBN (13 cifre) o un ISSN (8 cifre). Il BookService finirebbe quindi per dipendere da un IsbnGenerator o da un IssnGenerator in base a ciò che viene richiesto.
La Figura 2-3 mostra un diagramma di classe dell'interfaccia NumberGenerator con un metodo (String generateNumber ()) ed è implementato da IsbnGenerator e IssnGenerator. Il BookService dipende dall’interfaccia per generare un numero per un libro.
Come collegheresti un BookService all'implementazione ISBN dell'interfaccia NumberGenerator? Uno la soluzione è usare la parola chiave new come mostrato di seguito.
Il codice è piuttosto semplice, e fa il suo lavoro. Nel costuttore, il BookService crea un’istanza di IsbnGenerator e influisce sull'attributo numberGenerator. Invocando numeroGenerator.generateNumber () il metodo genererebbe un numero di 13 cifre. Ma cosa succede se si desidera scegliere tra le implementazioni e non essere collegati solo a IsbnGenerator? Una soluzione è passare l'implementazione al costruttore e lasciare ad una classe esterna di scegliere quale implementazione vuole usare (vedi codice seguente).
Ciò illustra l'inversione del controllo: il controllo della creazione della dipendenza tra BookService e NumberGenerator viene invertito perché è assegnato ad una classe esterna, non alla classe stessa. Dal momento che colleghiamo le dipendenze da soli si parla di construction by hand Nel codice precedente abbiamo usato il costruttore per scegliere l'implementazione (constructor injection), ma un altro modo comune è usare setter (setter injection). Tuttavia, invece di costruire dipendenze a mano, puoi lasciarlo fare a un iniettore (cioè, CDI).
Inject Point
L'annotazione @Inject definisce un punto di inject che viene iniettato durante l'istanziazione del bean. L'inject può avvenire tramite tre diversi meccanismi: proprietà(attributi), setter o costruttore. Fino ad ora, in tutti gli esempi di codice precedenti, hai visto l'annotazione @Inject sugli attributi (proprietà).
Si noti che non è necessario creare getter e etter per un attributo che usa l’injection. CDI può accedere ai campi inject direttamente (anche se è private), e ciò aiuta ad evitare ridondanza di codice. Si può anche usare @Inject sul costruttore:
Ma si può avere solo un costruttore con @Inject. È il container che istanzia i bean quindi è permesso un solo costruttore.
L'altra scelta è quella di usare setter injection, simile a un constructor injection. C’è solo bisogno di annotare il setter con @Inject.
Default Injection
Supponiamo che NumberGenerator abbia solo un'implementazione (IsbnGenerator). Il CDI sarà quindi in grado di iniettarlo semplicemente usando @Inject.
Questa è chiamata default injection. Ogni volta che un bean o punto di iniezione non dichiara esplicitamente un qualificatore, il conteiner assume il qualificatore @ javax.enterprise.inject.Default. Infatti, il codice seguente è identico a il precedente:
@Default è un qualificatore incorporato che informa CDI di iniettare l'implementazione bean di default. Se si definisce un bean senza qualificatore, il bean ha automaticamente il qualificatore @Default. Quindi il codice seguente è identico a quello precedente.
Quindi: @Inject da solo equivale a @Inject @Default. Se generiamo un Bean senza qualificatori viene considerato @Defalut. Se dobbiamo scegliere tra più implementazioni servono i qualificatori.
