Originariamente inviata da
tulipan
Io intendevo dire che mi hanno detto che gli EJB vengono salvati in una coda e quest'ultima ha a che fare con un oggetto proxy (il design pattern). Io vorrei sapere come avviene tutto il processo.
Non so se è chiaro quello che voglio dire!
Sì, ora è chiaro. E sì, riguardo gli EJB, il concetto di "proxy" c'entra eccome! Innanzitutto non è proprio corretto parlare di "coda" ma semmai di un "pool" di bean.
Prendiamo per esempio un bean EJB di tipo "stateless". Si fa prima la interfaccia locale di "business", es.:
codice:
@Local
public interface MessageSenderLocalBusiness {
void sendMessage(String text);
}
Poi si implementa il bean EJB vero e proprio:
codice:
@Stateless
public class MessageSenderBean implements MessageSenderLocalBusiness {
@Override
public void sendMessage(String text) {
// implementazione per mandare il messaggio da qualche parte ....
}
}
A quel punto si può "iniettare" ad esempio il riferimento all'interno di una Servlet, es.:
codice:
@WebServlet("/send-msg")
public class MessageSenderServlet extends HttpServlet {
@EJB
private MessageSenderLocalBusiness messageSender;
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
messageSender.sendMessage("Ciao");
messageSender.sendMessage("Hello");
// ....
}
}
Il @EJB indica di "iniettare" lì in quella variabile il riferimento al EJB. Ma il punto fondamentale è che quello che viene iniettato NON è direttamente una istanza della classe MessageSenderBean ma è un "proxy", cioè un oggetto che sicuramente implementa la interfaccia MessageSenderLocalBusiness ma non è il bean EJB e funge solo da tramite. Questo approccio permette al container di fornire tutta una serie di servizi ai bean EJB: security, transazionalità, interceptor, ecc...
La istanza della servlet di norma è una sola e il proxy iniettato quindi è uno solo ed è lo stesso e resta in "vita" per tutta la durata della servlet.
Con gli EJB stateless, il container degli EJB può creare molte istanze di MessageSenderBean e tenerle in un "pool" di bean. Ma potrebbe anche crearne uno "al volo" ad ogni necessità e poi distruggerlo subito dopo. Queste sono strategie che possono variare da un application server all'altro e possono anche eventualmente essere configurate in qualche modo.
Per il programmatore il concetto essenziale da sapere sugli EJB stateless è il seguente. Se ci sono nel pool 4 istanze di MessageSenderBean, #1, #2, #3 e #4, ad ogni invocazione di sendMessage il proxy sceglie un bean su cui dirottare la chiamata.
Ad una chiamata di doPost, il primo sendMessage("Ciao") potrebbe passare nel bean #1, il secondo sendMessage("Hello") potrebbe passare nel bean #3.
Ad una seconda chiamata di doPost, il primo sendMessage("Ciao") potrebbe passare nel bean #4, il secondo sendMessage("Hello") potrebbe passare nel bean #2.
Il senso di "stateless" è relativo al fatto che non deve essere mantenuto nel bean uno "stato" che sia usato per fare "conversazione" tra più chiamate al bean. Ogni chiamata di un metodo deve essere a sé stante, proprio perché il proxy può far passare la chiamata nel bean che preferisce.
Come il proxy venga creato e implementato da un application server, generalmente non è particolarmente importante per il programmatore. Per quanto ne so, se ben ricordo di aver letto, ad esempio JBoss sfrutta il dynamic proxy del JDK 1.3+ (java.lang.reflect.Proxy)