La base su cui è costruita la tecnologia degli EJB pilastro della logica applicativa dell'ambiente Java Enterprise è la tecnologia Java RMI (Remote Method Invocation) estesa, per poter essere fruita al di fuori di ambienti java, da RMI-IIOP (RMI - Internet Inter ORB Protocol).
Vista la complessità dell'argomento mi limiterò a spiegare in linee generali su quali idee si fonda la tecnologia di base RMI in modo che possano essere compresi i limiti e le peculiarità degli Enterprise Java Bean, dalla quale tecnologia dipendono.
La tecnologia RMI viene fornita con la distribuzione standard di java e risiede nel package java.rmi. Tale tecnologia eredita i concetti della tecnologia Remote Procedure Call (tipica dei linguaggi di programmazione procedurali) e la estende a livello di classi ed oggetti. Attraverso i meccanismi che andremo a vedere consente l'esecuzione dei metodi di un oggetto presente su un'altra macchina in rete.
Questa tecnologia fa ricorso alla pratica della separazione tra interfaccia (che definisce cosa fare) ed implementazione (che definisce come farlo). Un interfaccia definisce un metodo da eseguire (quindi valori di ritorno e parametri). La sua realizzazione concreta implementa tale interfaccia e definisce la logica del metodo. La realizzazione concreta (che chiameremo A) può essere sostituita da un'altra realizzazione concreta (che chiameremo A1) che esegua gli stessi compiti, facendo uso della stessa classe A.
È quanto accade agli oggetti distribuiti. Il client conosce l'interfaccia e concretamente esegue la classe A1 che risiede sulla macchina del client. A1 comunica via TCP/IP con A (che risiede sul server) in maniera opportuna per effettuare il metodo e restituire il risultato al client. Per il client tutte le operazioni saranno trasparenti in quanto esso conosce il tipo astratto (l'interfaccia). Esisterà un oggetto (A1) che farà da ponte tra il client ed il server gestendo le operazioni di rete.
RMI è la tecnologia che permette di creare in maniera automatica la comunicazione tra client e server mantenendo la trasparenza. L'oggetto che abbiamo chiamato A1, in realtà sono due oggetti, uno residente sul client, l'altro sul server che gestiscono le operazioni di scambio informativo.
Come vediamo dall'immagine tali oggetti prendono il nome di stub, dalla parte del client, e skeleton, dalla parte del server. Tali oggetti sono creati da un compilatore speciale (rmic) a partire dalla definizione dell'interfaccia remota. Affinché il client recuperi in maniera trasparente il tipo concreto da utilizzare (lo stub) è necessario che ci sia un oggetto, che interrogato, si occupi di questa funzione: a tal proposito è presente il registro di naming (java.rmi.Naming) che consente al server di registrare gli oggetti remoti ed al client di recuperarli (gli stub).
La discussione su questa tecnologia richiederebbe un'intera guida, per parlare del passaggio dei parametri, delle operazioni su rete, della gestione delle eccezioni.
Quello che è importante capire è come dal punto di vista di un'architettura di rete si pone la logica della programmazione distribuita. Gli EJB non sono altro che degli oggetti distribuiti secondo la logica RMI e pertanto presentano stessi pregi e difetti.
In particolar modo voglio sottolineare come il passaggio di parametri e la restituzione di valori di ritorno potrebbe implicare problemi di tipizzazione (interfacce diverse da quelle attese) e di serializzazione (tutti gli oggetti che viaggiano su stream bit-oriented, come la rete, devono estendere Serializable). Quindi, se prevediamo per un bean il passaggio di un parametro di un dato tipo, dobbiamo accertarci che quel dato tipo implementi l'interfaccia java.io.Serializable.
Dobbiamo anche considerare che gli oggetti distribuiti viaggiano su reti, quindi soggette a tutte le limitazioni di traffico e velocità del caso (scambiare un oggetto molto pesante con un server dall'altro lato del globo potrebbe essere un problema).
