Lo scopo è stato quello di esaminare soluzioni software che permettano di testare il corretto funzionamento di metodi definiti all’interno di EJB3 locali. Prima di entrare nello specifico è necessario introdurre alcuni concetti fondamentali per capire quali possano essere le problematiche comuni ai diversi software.

Gli EJB sono componenti software che implementano, lato server, la logica di business all’interno dell’architettura JavaEE. Nella versione 3 dello standard EJB il componente altro non è che una classe Java, contrassegnata per mezzo di annotazioni (es. @Stateless) che implementa delle interfacce (che sono la lista dei metodi che il servizio espone) annotate con @Local e @Remote a seconda che la funzionalità sia disponibile anche al di fuori del container.

Il container di EJB (server J2EE) offre funzionalità legate al ciclo di vita dei componenti ed un servizio standard (servizio JNDI) che consente ad altri componenti software interni e non, di accedere all’interfaccia definita per l’EJB.

Il servizio JNDI restituisce, dato il nome con cui un servizio è stato registrato, il riferimento all’interfaccia locale o remota dell’EJB da invocare. Per connessioni al di fuori del container J2EE, il servizio JNDI permette l’invocazione dei soli metodi presenti per l’interfaccia remota. Questo significa che, per testare metodi definiti all’interno dell’interfaccia locale, è stato necessario installare un componente software all’interno del container J2EE dove girano gli EJB in questione.

I metodi definiti nell’interfaccia sono metodi standard Java che possono avere zero o più parametri in ingresso e valori in uscita. Ogni parametro è un oggetto Java che può essere un tipo base (stringa, intero, long, byte, double) oppure una sottoclasse di Object.

Perché un componente software possa creare dinamicamente un’interfaccia grafica per l’invocazione di metodi EJB è necessario conoscere la tipologia degli argomenti in ingresso e in uscita del metodo; purtroppo la cosa è resa difficoltosa dalle potenzialità del linguaggio Java per quanto riguarda ereditarietà e astrazione.

Infatti, poiché tutti gli oggetti in Java sono sottoclassi di Object, un metodo, il cui argomento in ingresso è di tipo Object (questo vale in generale per tutte le classi non dichiarate final), accetta in ingresso qualunque tipo di sua sottoclasse.

In tutte le soluzioni proposte i prerequisiti sono:

  1. Gli EJB da testare siano Stateless (non perché ci siano problemi dal punto di vista architetturale ma perché i test potrebbero fallire a causa di stati interni dell’EJB).
  2. Che gli argomenti dei metodi in generale siano JavaBean oppure interfacce adibite a trasportare dati e non logica (vedi Classi di CallBack).

La soluzione è stata quella di realizzare una applicazione J2EE custom, da installare sul server dove sono in esecuzione i componenti EJB3 da testare, e che, in modo totalmente automatico crea un WebService server utilizzabile con il prodotto WSE realizzato da T.A.I.