Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial
  • Lezione 37 di 68
  • livello ninja
Indice lezioni

Stateless Session Bean

Primo esempio pratico: sviluppo di un bean di sessione di tipo stateless (un server time remoto)
Primo esempio pratico: sviluppo di un bean di sessione di tipo stateless (un server time remoto)
Link copiato negli appunti

Come primo esempio applicativo vedremo il più semplice degli EJB, creeremo uno stateless session bean, con un metodo che restituirà la data del server su cui esso verrà installato.

L'architettura degli EJB è stata discussa nel capitolo precedente, qui vediamo cosa ci fornisce la tecnologia J2EE e cosa invece dobbiamo scrivere noi. La discussione è riferita al caso specifico degli stateless session bean ma può essere estesa a tutti i tipi di EJB di tipo session.

Figura 1. Architettura di un EJB stateless session bean
Architettura di un EJB stateless session bean

Per comodità ci poniamo nel caso in cui dovremo scrivere solo le interfacce remote. Ciò che viene fornito dalla tecnologia J2EE lo abbiamo visto nel capitolo precedente: si tratta di interfacce necessarie per aderire al framework degli EJB. Come vediamo, queste, sono delle estensioni dell'interfaccia java.rmi.Remote (tecnologia Java Standard), la cui spiegazione è presente nell'appendice B. Il nostro compito sarà di scrivere le unità colorate di verde e di azzurro, nell'immagine in alto, più un descrittore XML. Dopodiché compatteremo tutto in un archivio JAR che installeremo su un application server (vedi appendice D per il dettaglio).

L'application server genererà delle classi che gestiranno il ciclo di vita del componente e la logica che noi abbiamo scritto. Ultimo passo sarà quello di creare un client per vedere se il nostro componente funziona.

La prima unità di compilazione che dovremo scrivere sarà ServerTime, l'interfaccia remota che estende EJBObject che definisce i metodi di business che vogliamo implementare (nel nostro caso, il metodo getTime()).

Listato 1. Recupera la data e la restituisce come stringa

package it.html.ejb.session.stateless;

// Remote interface for ServerTime
public interface ServerTime
  extends javax.ejb.EJBObject{
  
  // Il metodo recupera la data corrente e la restituisce sotto forma di stringa
  public java.lang.String getTime( )
    throws java.rmi.RemoteException;
}

Nel caso in cui prevediamo un accesso locale sarà bene creare un'interfaccia analoga, che questa volta erediterà da EJBLocalObject.

La seconda unità di compilazione è la classe ServerTimeHome, che prevede la presenza di almeno un metodo create(), utilizzato per la creazione di un'istanza di ServerTime.

Listato 2. Home interface per ServerTime

package it.html.ejb.session.stateless;

public interface ServerTimeHome
  extends javax.ejb.EJBHome{
  public static final String COMP_NAME="java:comp/env/ejb/ServerTime";
  public static final String JNDI_NAME="ServerTime";
  
  public it.html.ejb.session.stateless.ServerTime create()
    throws javax.ejb.CreateException,java.rmi.RemoteException;

}

Come per l'interfaccia locale, nel caso in cui accediamo il componente dallo stesso container servirà la classe Home erede di EJBLocalHome.

Ultima classe che dovremo scrivere sarà quella che contiene la logica di business vera e propria, ServerTimeBean. Oltre al metodo getTime(), dovrà essere presente un metodo ejbCreate() che ricalca il metodo create presente nella Home.

Listato 3. Il bean di tipo stateless espone il metodo getTime() (Guarda il codice completo)

..//
  public void ejbCreate() {
  ..//
  public String getTime() {
  ..//
  public void ejbActivate() throws EJBException, RemoteException {
  ..//
  public void ejbPassivate() throws EJBException, RemoteException {
  ..//
  public void ejbRemove() throws EJBException, RemoteException {
  ..//
  public void setSessionContext(SessionContext arg0) throws EJBException,
  ..//
  public ServerTimeBean() {  }
}

I diversi metodi presenti ricalcano il ciclo di vita dei bean quindi verranno richiamati dal container quando necessario. È evidente, inoltre, che ogni bean può presentare diversi metodi di logica.

L'ultima cosa che dovremo scrivere, prima di effettuare l'operazione di deploy, è il descrittore XML, che ha il compito di definire i servizi da implementare per questo componente, oltre a specificare al container l'associazione tra classi ed il nome del componente stesso.

Listato 4. Descrittore XML (Guarda il codice completo)

<?xml version="1.0" encoding="UTF-8"?>

<ejb-jar id="ejb-jar_1" xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd" version="2.1">

  ..//
  <enterprise-beans>
  
    <session id="Session_ServerTime">
      ..//
    </session>
  
  </enterprise-beans>
  
..//
</ejb-jar>

Ora abbiamo tutto il necessario per installare il componente sull'application server. Dobbiamo quindi creare un package jar delle classi sopra descritte e del descrittore XML (più eventualmente altri descrittori specifici dell'application server utilizzato). Questa operazione può essere fatta a mano, utilizzando il comando jar, presente in qualsiasi SDK, oppure, utilizzando i tanti tool che si trovano navigando in rete: su tutti consiglio il WTP di Eclipse.

In realtà, se non per scopi didattici, è un'operazione inutile e tediosa dover scrivere a mano tutte le unità di compilazione. I tool, tra cui quello suggerito, vi consentono la creazione dei componenti in maniera visuale, preoccupandovi di scrivere solo la logica dei metodi di business.

L'operazione di deploy (installazione del componente sull'application server) è fortemente dipendente dall'application server che utilizzerete. Alcuni application server hanno un pannello con un wizard che vi aiuta nell'operazione, in altri dovrete copiare ed incollare il JAR in directory specifiche. L'operazione generalmente notifica la riuscita o meno dell'installazione del componente.

Ti consigliamo anche