Cerchiamo di capire cos'è e come funziona un oggetto distribuito. La comprensione di questo concetto è fondamentale per comprendere la logica che si nasconde dietro gli EJB.
Un EJB è un componente che risiede su una macchina server, quindi, programmato per effettuare delle funzioni sfruttando le risorse di tale macchina. Con la programmazione distribuita diamo la possibilità a dei client, esterni, rispetto alla macchina, di collegarsi ad essa e richiedere i servizi di quel componente. L'EJB elabora la richiesta, e fornisce in output un risultato.
Lo scambio di informazioni tra le due macchine avviene attraverso delle chiamate su protocolli di rete. La macchina client invia la richiesta al server. Il server elabora la richiesta e produce un risultato. Il server invia il risultato al client.
La cosa interessante è che utilizzando gli EJB, ed in generale degli oggetti distribuiti, non cambia il paradigma object oriented a cui siamo abituati. Lo sviluppatore non sa dove risiede il componente, ma, conoscendo le interfacce sa come richiamare i servizi e quali sono gli output attesi. I motivi per cui utilizzare un oggetto che risiede su un'altra macchina possono essere molteplici: performance, scalabilità, questioni di sicurezza.
Ora che sappiamo cos'è un oggetto distribuito (verrà trattato meglio nelle prossimi lezioni), vediamo il legame che intercorre tra esso ed il concetto di middleware. La traduzione italiana di middleware è "roba che sta in mezzo" e, direi, rende bene l'idea.
Il middleware, fornito dagli application server è infatti uno strato di logica applicativa invisibile ai nostri occhi che ci regala una serie di servizi utili ed automatici, soprattutto laddove lo sviluppo avviene in ambiente distribuito.
Ipotizziamo un generico componente distribuito che dobbiamo sviluppare. Tale componente per espletare le sue funzioni dovrà essere provvisto di routines per l'accesso al database, routines per la gestione della sicurezza e tanti altri servizi accessori dipendenti dal servizio stesso. Ciò implica che chi svilupperà il componente (l'EJB, quindi noi) dovrebbe preoccuparsi di sviluppare anche tali servizi (sono sempre gli stessi). Gli application server ci vengono in aiuto, provvedendo per noi allo sviluppo di tali servizi necessari alla produzione di applicazioni distribuite. Sarà nostra cura soltanto notificare all'application server di quali servizi abbiamo bisogno.
La presenza di middleware, fornito dagli application server, da la possibilità allo sviluppatore di concentrarsi esclusivamente alla logica applicativa, delegando alle procedure automatiche, tutte le operazioni di routines.
Abbiamo detto che è importante che lo sviluppatore conosca l'interfaccia dell'EJB per sapere come utilizzarlo e che deve definirne i servizi accessori notificandoli all'application server. Stiamo introducendo le componenti necessarie a sviluppare un EJB. Si tratta di una serie di interfacce e classi da estendere ed alcuni file xml in cui viene specificato quale servizio è necessario al funzionamento dell'EJB.
- Remote Interface:
javax.ejb.EJBObject. Definisce i servizi che quel bean deve implementare (metodi di logica); - Home Interface:
javax.ejb.EJBHome. La classe "Factory", cioè la classe che si occupa della creazione del bean; - Bean Class:
javax.ejb.SessionBean(javax.ejb.EntityBean). Questa classe deve riprendere i metodi della Remote Interface ed è questa che conterrà la logica applicativa vera e propria; - Local Interface: javax.ejb.EJBLocalObject. Come per Remote Interface, con la differenza che l'accesso non avviene su rete;
- Local Home: javax.ejb.EJBLocalHome. Come per Home Interface, con la differenza che l'accesso è diretto;
- Deployment Descriptor. Questo è un file xml in cui vengono definite le regole da applicare, è attraverso questo file che possiamo aggiungere al servizio delle funzionalità aggiuntive in maniera dinamica.
Accanto a questi spesso è necessario un descrittore di deployment specifico dell'application server scelto. In molti casi dove la logica distribuita non ha senso, cioè dove il client risiede sulla stessa macchina del server (ad esempio il web container, servlet o jsp che fanno uso di EJB) è buona norma provvedere alla presenza di interfacce "locali", che sono molto più performanti in quanto evitano l'accesso su rete.
Si capisce quindi come mai la Bean Class non viene forzata ad estendere dalla Remote Interface, poiché essa può riferirsi eventualmente all'interfaccia locale.
La presenza di tutte queste classi ed interfacce potrebbe spaventarvi, ma l'unica vera classe che dovrete scrivere sarà la Bean Class. I tool di sviluppo in questo senso ci daranno una mano riducendo al minimo il codice da scrivere.
L'insieme di questi pezzi da vita all'EJB attraverso la procedura di deploy.
In questa guida faremo riferimento alla versione 2.0 per quanto riguarda gli EJB, in modo da comprendere al meglio l'architettura. Dalla specifica 3.0 è infatti possibile definire questi componenti in maniera descrittiva, utilizzando dei tag di commento specifici (che però non ci permetterebbero di entrare nel merito dei componenti).
