Enterprise JavaBeans: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
mNessun oggetto della modifica |
ortografia |
||
(49 versioni intermedie di 29 utenti non mostrate) | |||
Riga 1:
Le specifiche per gli EJB definiscono diverse proprietà che questi devono rispettare, tra cui la [[persistenza (informatica)|persistenza]], il supporto alle [[Transazione (basi di dati)|transazioni]], la gestione della [[concorrenza (informatica)|concorrenza]] e della [[sicurezza informatica|sicurezza]] e l'integrazione con altre tecnologie, come [[Java Message Service|JMS]], [[JNDI]], e [[CORBA]]. Lo [[Norma tecnica|standard]] attuale, EJB 3.2, completato nella primavera del 2013<ref>[https://jcp.org/en/jsr/detail?id=345 JSR 345: Enterprise JavaBeansTM 3.2]</ref>, differisce notevolmente dalla versione 2.1 delle specifiche, in quanto introduce la possibilità di effettuare ''[[dependency injection]]'' e di effettuare mediante [[Annotazione (Java)|annotationi]] le configurazioni che precedentemente avvenivano mediante [[XML]]. Gli EJB necessitano di un ''EJB container'' tipicamente implementato all'interno degli ''application server'' assieme al ''[[servlet]] container'' per la parte di front-end.
== Motivazioni ==
Le specifiche Enterprise JavaBean intendono fornire una metodologia standard per implementare la logica di funzionamento delle [[applicazione (informatica)|applicazioni]] di tipo ''enterprise'', applicazioni cioè che forniscono servizi via [[Internet]] su larga scala. Per realizzare applicazioni di questo tipo è necessario affrontare una serie di problematiche tecniche che possono rivelarsi molto complesse e laboriose da risolvere. Gli Enterprise JavaBean intendono fornire una soluzione a questi problemi in modo da semplificare lo sviluppo di questo tipo di applicazioni.
Le specifiche Enterprise JavaBean descrivono in dettaglio come realizzare un ''application server'' che fornisca le seguenti funzionalità:
* [[Persistenza (informatica)|Persistenza]];
* Elaborazione delle [[Transazione (basi di dati)|transazioni]];
* Controllo della [[concorrenza (informatica)|concorrenza]];
* [[Programmazione a eventi]] tramite il [[Java Message Service]];
* [[Servizio di directory]] per elencare e nominare gli EJB ([[JNDI]]);
* [[Sicurezza informatica|Sicurezza]] ([[Java Cryptography Extension]]<ref>{{en}} [https://docs.oracle.com/javase/7/docs/technotes/guides/security/jaas/JAASRefGuide.html Java Authentication and Authorization Service (JAAS) Reference Guide]</ref> e [[Java Authentication and Authorization Service]]);
* [[Installazione (informatica)|Installazione]] di componenti software in un ''application server'';
* [[Chiamata di procedura remota|Invocazione di procedure remote]] tramite l'utilizzo di [[RMI-IIOP]] o [[CORBA]];
* Fornire [[web service|servizi web]].
Inoltre le specifiche definiscono il ruolo del contenitore di Enterprise JavaBean e di come far comunicare il contenitore con gli EJB.
== Tipologie ==
Fino alla versione 2.1 della specifica esistevano tre tipi di Enterprise JavaBeans, dalla versione 3.0 in poi ne esistono soltanto due, in quanto gli ''Entity Bean'' sono stati deprecati. Per completezza vengono riportati tutti i tipi di EJB.
=== EJB di sessione ===
Detti anche ''Session EJB''. Gestiscono l'[[elaborazione dati|elaborazione]] delle informazioni sul [[server]]. Generalmente sono una [[interfaccia (informatica)|interfaccia]] tra i ''client'' e i servizi offerti dai componenti disponibili sul server. Ne esistono di due tipi: con stato e senza stato.
Dalla versione 3.2 dello standard EJB possono essere invocati in modo asincrono. L'invocazione asincrona avrà come valore di ritorno una variabile di tipo <code>Future<V></code>, che permetterà al chiamante di conoscere l'effettivo valore di ritorno, verificare l'eventuale presenza di eccezioni e annullare una chiamata in corso.
==== Con stato ====
Vengono anche detti ''stateful''. I ''bean'' di sessione con stato sono oggetti distribuiti che possiedono uno stato. Lo stato non è persistente, però l'accesso al ''bean'' è limitato a un unico [[client]].
Un esempio di bean con stato è:
<syntaxhighlight lang="java" line="1" copy=1>
@Stateful
public class Contatore {
private int totale = 0;
public int totale() {
return totale;
}
public void incrementa() {
totale = totale + 1;
}
public void azzera() {
totale = 0;
}
}
</syntaxhighlight>
==== Senza stato ====
Detti anche ''stateless''. I ''bean'' di sessione senza stato sono oggetti distribuiti senza uno stato associato, questa caratteristica permette un accesso concorrente alle funzionalità offerte dal ''bean''. Non è garantito che il contenuto delle variabili di istanza si conservi tra diverse chiamate ai metodi del ''bean''.
Un esempio di ''bean'' senza stato è:
<syntaxhighlight line="1" copy=1 lang="java">
@Stateless
public class SalutoBean {
public String salutaUtente() {
return "Benvenuto!";
}
}
</syntaxhighlight>
=== EJB guidati da messaggi ===
Detti anche ''Message driven EJBs''. Erano gli unici ''bean'' con funzionamento asincrono (dalla versione 3.2 dello standard anche EJB di sessione possono essere invocati in modo asincrono). Tramite il Java Message Service (JMS), si iscrivono a un argomento ({{Inglese|topic}}) o a una coda ({{Inglese|queue}}) e si attivano alla ricezione di un messaggio inviato all'argomento o alla coda a cui sono iscritti. Non richiedono una istanziazione da parte dei client.
=== EJB di Entità ===
Vengono detti anche ''Entity EJB''. Non sono più supportati, in quanto con la versione 2.0 e 2.1 dello standard EJB avevano delle prestazioni molto basse e i programmatori preferivano utilizzare chiamate [[JDBC]] dirette o ''[[framework]]'' di persistenza come [[Hibernate]] o MyBatis. Per ovviare a questo problema, sono state introdotte le [[Java Persistence API]].
Il loro scopo era di inglobare gli oggetti sul lato server che memorizzano i dati. Gli ''entity bean'' fornivano la caratteristica della [[persistenza (informatica)|persistenza dei dati]]:
* Persistenza gestita dal contenitore (CMP): il contenitore si incarica della memorizzazione e del recupero dei dati relativi a un oggetto utilizzando una [[tabella (basi di dati)|tabella]] di una [[base di dati]].
* Persistenza gestita dal bean (BMP): in questo caso è il ''bean'' a occuparsi del salvataggio e recupero dei dati a cui fa riferimento, il salvataggio può avvenire in una base di dati o con qualsiasi altro meccanismo perché è il programmatore che si incarica di realizzare il meccanismo della persistenza dei dati.
== Versioni ==
* JSR 19: Enterprise JavaBeans 2.0
* JSR 153: Enterprise JavaBeans 2.1
* JSR 220: Enterprise JavaBeans 3.0 introduce la possibilità di dichiarare e configurare gli Enterprise JavaBeans mediante il meccanismo delle annotazioni. Da questa versione in poi, un EJB non deve più estendere alcuna classe specifica. Tale modifica viene spesso citata come [[Plain Old Java Object]] (POJO). Vengono introdotti i primi meccanismi di ''dependency injection''. Per la persistenza vengono abbandonati gli Entity Bean e ci sono le Java Persistence API (JPA).
* JSR 318: Enterprise JavaBeans 3.1 va nella direzione della semplificazione. Tale direzione è obbligata dalla fortissima diffusione dello Spring Framework. Introduce il cosiddetto Lite EJB, ovvero la possibilità di inserire degli Enterprise JavaBeans all'interno di un Web Archive, che finora poteva contenere unicamente servlet, ma non EJB. Ora è possibile invocare gli EJB da una applicazione Java SE, senza dover usare ''servlet container'' o ''application server''. I ''session bean'' possono essere invocati in modo asincrono e c'è la possibilità di creare degli EJB Timer.
* JSR 345: Enterprise JavaBeans 3.2 introduce la possibilità di invocare i ''bean'' di sessione in modo asincrono.
== Enterprise JavaBeans e microservizi ==
Riguardo allo sviluppo di [[Microservizio|microservizi]] attraverso l'utilizzo di Enterprise JavaBeans, Antonio Goncalves, Expert Member di CDI 2, Java EE 8 e autore di numerosi libri su Java EE, scrive:
{{citazione| Java EE needs a simple Java SE Container API that we could easily bootstrap. Most of EE specs are already "embeddable" anyway and the ones you mentioned are or will be (CDI 2.0 with have a Java SE bootstrap API in Java EE 8). But I'm less confident about EJBs. EJBs are not "that micro", they are a bit fat (and I'm just talking about the number of services they bundle). I would prefer to see the Java EE Concurrency updated (to have asynchronous invocation out of EJBs), and focus on CDI, JTA, Concurrency, JPA and JAX-RS (but again, why not adding Bean Validation and servlets, if we have JAX-RS ?). | Antonio Goncalves, ''[https://java.net/projects/javaee-spec/lists/users/archive/2015-02/message/57 One container to rule them all]''}}
Ciò che intende sottolineare è che il numero di servizi che la specifica Enterprise JavaBeans porta con sé è elevato, quindi non è consigliabile quando si vogliano creare dei microservizi.
== Note ==
<references/>
== Voci correlate ==
* [[Java Persistence API]]
* [[Java EE]]
* [[Application server]]
* [[Spring framework]]
== Collegamenti esterni ==
* {{Collegamenti esterni}}
* {{FOLDOC}}
{{Portale|informatica}}
[[Categoria:Java EE]]
|