Enterprise JavaBeans: differenze tra le versioni

Versione delle 17:15, 14 apr 2015

Versione delle 16:01, 22 mag 2015

Riga 75:

* [https://jcp.org/en/jsr/detail?id=318 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.

* [https://jcp.org/en/jsr/detail?id=345 JSR 345: Enterprise JavaBeans 3.2]

== Enterprise JavaBeans e microservices ==

Riguardo allo sviluppo di microservice attraverso l'utilizzo di Enterprise JavaBeans, Antonio Goncalves, Expert Member di CDI 2, Java EE 8 ed 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 microservice.

== Note ==