Dopo RMI e RMI-IIOP, l'articolo propone una panoramica sui componenti EJB per la programmazione distribuita.

RMI, RMI-IIOP, CORBA: i motori degli oggetti distribuiti

Negli ultimi tre numeri di MokaByte sono stati affrontati i temi di RMI e RMI-IIOP, sia da un punto di vista teorico sia con semplici esempi.

Riassumendo brevemente:

• RMI è una soluzione full-Java che permette in maniera semplice la realizzazione di architetture distribuite mediante il protocollo JRMP
• CORBA è una soluzione language-neutral, più versatile e potente ma anche più complessa di RMI
• RMI-IIOP è una nuova versione di RMI che permette di utilizzare oltre a JRMP anche il protocollo IIOP per comunicare con applicazioni CORBA, fungendo da ponte tra due mondi fino ad allora incompatibili

Differenza tra RMI e EJB

Come spiegato nell'articolo richiamato in bibliografia, la differenza fondamentale tra EJB da una parte e RMI, CORBA, RMI-IIOP dall'altra è data dal supporto per la realizzazione di applicazioni distribuite.

Mentre RMI e CORBA sono semplicemente motori di oggetti e i cosiddetti distributed object services devono essere implementati a mano, nel modello EJB tutto quello che riguarda la gestione dei servizi è disponibile e utilizzabile in maniera del tutto automatica e trasparente agli occhi del client.

EJB si appoggia a RMI, utilizzandone le funzionalità e la filosofia di base per realizzare strutture distribuite, ma dà come valore aggiunto la gestione automatica dei servizi, transazioni, sicurezza, scalabilità.

L'architettura EJB

L'architettura EJB è basata essenzialmente su tre componenti:

• un server
• i container
• i client

EJB Container

I container EJB offrono un sistema automatico per la gestione del lifecycle dei vari componenti, delle transazioni e della sicurezza, offrendo flessibilità e scalabilità in funzione del traffico dati e del numero dei client.

Un client non accede mai direttamente al componente, bensì interagisce sempre con l'EJB container.

Componenti

Il componente non è altro che il codice sviluppato dal programmatore che viene ospitato all'interno del container.

Lo sviluppatore di un componente EJB può concentrarsi sui dettagli implementativi della business logic, tralasciando gli aspetti legati alla gestione che sono a carico del container.

Quando si sviluppa un componente bisogna implementare due interfacce ed una classe:

• Home interface, che fornisce i metodi per creare un'istanza del componente
• Remote interface, che definisce i metodi di business
• bean implementation class, che implementa la logica applicativa della remote interface

Stateless Session Bean

Gli stateless session bean sono componenti che non memorizzano alcun tipo di informazione al loro interno fra una invocazione e l'altra da parte del client.

Essi non implementano quindi nessuna logica conversazionale e, per certi versi, possono essere considerati come semplici contenitori di servizi.

Un EJB stateless può essere visto come l'equivalente di una classe che non possiede attributi ma solo metodi.

Conclusioni

L'articolo usa il Session EJB come punto di ingresso pratico al mondo EJB, mettendolo a confronto con i modelli già visti in precedenza.

Il risultato è un quadro chiaro: EJB non sostituisce il motore di comunicazione remota, ma lo ingloba in un'infrastruttura più ampia, dove container e servizi di piattaforma cambiano radicalmente il modo in cui si costruiscono componenti distribuiti.