Newsgroup: it.comp.java
Titolo: dubbi su EJB

ciao a tutti,
devo convertire un'applicazione monolitica in una distribuita usando EJB. Ho
studiato su varie fonti e ho più o meno compreso i concetti fondamentali. In
particolare, mi è chiara la trasformazione da una classe "normale" a
componente EJB (interfacce remote, home   + bean). Mi sfugge pero' come si
debba procedere a livello globale, quando si hanno molte classi.
Il mio caso: ho un package di servlet che usa classi in un package
"business"; le classi in "business" usano altri package e anche classi dello
stesso package "business".
Per convertire il tutto in EJB, e' corretto fare una terna (remote, home,
bean) per ogni classe di "business"? E se si', sono costretto a modificare
l'utilizzo di oggetti in "business" fatti dalle stesse classi "business"?
Io mi aspetto di non toccare i package sottostanti di accesso al database,
e' corretto?
Spero di essermi spiegato e spero in un vostro aiuto, anche un link con un
esempio (non di una singola classe, quello mi e' chiaro) sarebbe
graditissimo.
grazie comunque,
Federico.
---------------
Imparo!
---------------

accesso al database, e' corretto?
Ci sono vari dettagli noiosi da tener presenti.
1) Per ogni EJB che vuoi fare, devi creare le tre classi. :)
2) I metodi dell'interfaccia remota (quella che estende EJBObject)
*devono* fare il throw di RemoteException. Questo significa che non puoi
usare un'interfaccia "normale" e impacchettarla in un EJB: o la modifichi
(con le ovvie conseguenze su tutto il codice che ne fa uso); oppure
costruisci un'interfaccia mirror, con gli stessi metodi ma che lanciano
RemoteException. Solitamente, nel caso, io uso un sottopackage chiamato "ejb".
3) Se reimpacchetti una tua classe come EJB, ovviamente anche il codice
che la usa va cambiato: essenzialmente, le "new" si trasformano
lookup+create o lookup+findBy... Il dettaglio e' che *queste* possono
generare una RemoteException. Quindi, se esegui una new in un metodo
"implementativo" (che di norma *non* solleva RemoteExceptions, e che
nella tua logica originale non-RMI probabilmente non lo faceva nemmeno)
ti trovi nella bizzarra situazione di aver incapsulato l'interfaccia
origianale per evitare di dover trattare RemoteExceptions, ma in effetti
hai una RemoteException che *va* trattata. :) 
Soluzioni: per ogni EJB, rifattorizzi tutte le new, quando possibile, in
ejbCreate, convertendo eventuali RemoteException in CreateException, come
e' anche logicamente sensato; usi factory per creare gli oggetti,
trattando localmente le RemoteException; o ti rassegni ad aggiungere una 
catch(RemoteException) ovunque serve nel codice chiamante.
4) Costruttori. Il costruttore di un'implementazione EJB e', essenzialmente, un 
metodo ejbCreate. Quindi se le tue classi hanno costruttori con parametri o 
addirittura che lanciano eccezioni, ti trovi ad aver problemi: il server e' una 
factory per le tue istanza, non tu - e il server certo non tratta le tue 
eccezioni applicative. Ancora, incapsulare il tutto in opportuni wrapper aiuta.
5) Database. Di norma, ci si aspetta che un EJB faccia riferimento ad una 
Datasource dichiarata in configurazione (in default.properties con la reference 
implementation). Ma mica sempre, e le varie implementazioni differiscono un 
po'. Usare JDBC direttamente (DriverManager.getConnection("...") invece di 
(DataSource)context.getConnection(".."); non mi ha dato grossi problemi con la 
reference impl. e con Websphere, ma non saprei con altri server.
Queste sono alcune delle cose che mi vengono in mente.. se ce ne sono altre, le 
aggiungero'. :)
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

Cristiano,
tutti consigli preziosi che mi hanno fatto riflettere parecchio.
Ti rigrazio davvero,
Federico.