Enterprise Java Bean

Si parla di Enterprise Java Bean (EJB) nel campo della persistenza degli oggetti. La peristenza degli oggetti è una delle possibili tipologie di tecniche di persistenza assieme alla persistenza su file system o databases relazionali. La persistenza degli oggetti agisce sui cosidetti “DATABASE AD OGGETTI” (ODBMS). I database objected oriented sono più prestazionali rispetto i database relazionali (RDBMS) però sono meno diffusi sul mercato dato un piccolo gap di ulteriori conoscenze addizionali rispetto i database relazionali. Gli ODBMS sono indipendenti dal linguaggio e dalla piattaforma utilizzata, non a caso forniscono maggior interoperabilità tra i linguaggi utilizzati consentendo di poter progettare una piattaforma distribuita capace di erogare elevate prestazioni.
Dopo questa rapida introduzione torniamo a concentrarci sugli Enterprise Java Bean. Gli Enterprise JavaBean rappresentano un modello di componenti software che standardizzano, lato server, la logica di business di un’applicazione web all’interno dell’architettura Java EE (ossia i servizi dell’applicazione distribuita), favorendo alla parte di front-end la loro invocazione mediante un middleware che dispone su di esso tali procedure remote. Rappresentano dunque uno strato software residente su un application server all’interno di un’architettura software di tipo multi-tier.
Gli EJB per essere deployati necessitano di un EJB container tipicamente implementato all’interno degli application server assieme al servlet container per la parte di front-end.
» I componenti sono unità di deployment che forniscono servizi di business ai loro client.
» Un componente deve contenere il codice necessario all’implementazione dei suoi servizi.
» Gli EJB, ossia i servizi devono essere messi a disposizione dell’ambiente di esecuzione ossia il loro EJB Container.
» I container inseriscono, in modo trasparente, il codice per la gestione delle transazioni, della persistenza, della sicurezza, della distribuzione, ed altri servizi personalizzabili. I container
possono essere forniti indipendentemente dall’Application Server e dagli EJB provider.
» Una transazione è un’insieme di operazioni che o viene completata interamente (COMMIT) o viene annullata completamente (ROLLBACK). Le transazioni si basano sul principio ACID (Atomicity, Consistency, Isolation & Durability).
Attualmente secondo lo standard esistono tre tipi di Enterprise Java Bean:

  1. Message driven bean, bean con funzionamento asincrono, essi si attivano alla ricezione di un messaggio inviato all’argomento o alla coda a cui sono iscritti, per poi eseguirli in cascata fino allo svuotamento. Non richiedono una istanziazione da parte dei client.
  2. Session Bean, servono per gestire l’elaborazione delle informazioni sul server mediante un’interfaccia tra client e server.Essi a loro volta possono o meno possedere lo stato e prendono rispettivamente il nome di Statefull Session Bean e Stateless Session Bean. Gli statefull session bean mantengono lo stato sul client e possiedono un singolo thread. Gli stateless session bean non mantengono lo stato sul client e forniscono un servizio a livello di singolo utente.
  3. Entity Bean, rappresentano un tipo di dato persistente e possiedono un ciclo di vita più lungo rispetto ai message driven Message driven bean ed i Session bean. Inoltre non sono single-user in quanto possono essere condivisi da più client.

Gli Ejb in Java prevedono una distribuzione ed una invocazione remota dei servizi, garantendo così persistenza e scalabilità dell’applicazione distribuita. Storicamente gli ultimi introdotti su piattaforma J2EE sono stati i Message Driven Bean, essi si scambiano messaggi utilizzano la tecnologia JMS (Java Messagging Services).
In questo articolo ci limiteremo ad esplorare rapidamente gli stateless session bean
.

Strati applicazione Java distribuita

Architettura Enterprise Three-Tier

Supponendo di aver a che fare con architettura enterprise distribuita a strati (Layered Architecture, Three Tier) basata sul pattern di sviluppo MVC (Model View Controller) strutturata come nell’immagine di fianco avremo che gli “Stateless Session Bean” si collocano tra lo stato di Presentation e di Model, ossia nel SERVICE LAYER. Attenzione i tre livelli non sono Model, View e Controller ma Presentation Layer, Service Layer (o Business Logic) e Business Model. Ok! Ora abbiamo visto il layering dell’architettura ma ciò non è altro che la punta dell’iceberg in quanto è di fondamentale importanza la dinamica degli Enterprise Java Bean all’interno del suo container, ossia l’EJB container.
L’EJB Container è una parte fondamentale del server EJB, in quanto serve per:

  • Gestire i bean.
  • Gestire il lifecycle ed il deployment.
  • Eseguire i threads
  • Intercettare le chiamte remote ed iniettare l’infrastruttura del servizio.
  • Gestire le invocazioni dei client mediante un proxy.
  • Assicurare il funzionamento delle transazioni.

Quindi si può brevemente affermare che l’EJB Container è l’ambiente di deployment degli Enterprise Java Bean, ragion per cui la programmazione EJB-based si dice single thread, in quanto il multi-threading è a carico dell’EJB Container. Pertanto, quando un client richiama un metodo su di un bean, il container garantisce in prima instanza la persistenza per poi occuparsi dell’esecuzione del bean.

Funzionamento dell'EJB Container

Gestione dei bean da parte dell’EJB Container

Un Enterprise Java Bean non può assolutamente funzionare se non all’interno dell’EJB Container. Nell’immagine infatti è facile comprendere che:

  • Il client richiama un metodo del bean, l’EJB Container gestisce persistenza, sicurezza e le transazioni
  • Dopo l’invocazione dell’apposito EJB, si ha una callback ossia un ritorno dal metodo, che può essere il dato desiderato oppure una failure.

Dinamica degli EJB e Session Bean

Dinamica degli EJB

Gli Enterprise Java Bean in Java funzionano quindi mediante interfacce remote e locali.
» Per consntire l’accesso remoto bisogna utilizzare la @Remote annotation

@Remote
public interface InterfaceName{...}

» Per specificarne poi la classe remota avremo.

@Remote(InterfaceName.class)
public class BeanName implements InterfaceName {...}

L’interfaccia utilizzata da Java per distribuire un oggetto in un differente spazio (processo o macchina) è Java RMI (Remote Method Invocation).
L’immagine degli Enterprise Java Bean sul server è detta Skeleton, al suo interno lo Skeleton possiede lo Stub, che è l’oggetto vero e proprio sul quale vengono invocati i metodi remoti, una sorta di Middle-Tier.

Funzionamento dello Stub

Funzionamento dello Stub

Lo stub quindi non è altro che un proxy, cioè un sostituito dell’oggetto remoto che viene utilizzato come oggetto locale, fungendo così da intermediario tra il chiamante dallo strato di presentation e la logica di business.
Lo stub è associato alla risorsa JNDI (Java Naming and Directory Interface), perchè il client non deve mai vedere la realizzazione dei bean e l’architettura deve essere distribuita altrimenti non avrebbe senso l’architettura di per sè progettata. Infatti la chiamata JNDI permette il collegamento tra il bean locale ed il suo contesto, simulando l’architettura distribuita come una richiesta locale ma su server diversi presentation su un server e logica su un altro se prevediamo solo due livelli, ma la stratificazione può essere ulteriore avendo bean dislocati su più server avremo solo più risorse jndi. Prevedo di realizzare a breve un tutorial pratico sulla realizzazione di alcuni Enterprise Java Bean 3.0, utilizzando Hibernate come ODMS per il momento vi invito a consultare questi altri tutorial in materia:
Java Web Tier
Passaggio da Web Application J2EE a web app distribuita con ejb deployati su Glassfish
Call Ejb Tomcat Glassfish

Enterprise Java Bean ultima modidfica: 2015-01-13T12:35:52+01:00 da Gianluca Di Vincenzo