MDB: Cosa sono

Di solito le comunicazioni fra i componenti di un’applicazione sono sincrone, ossia l’oggetto che effettua la chiamata e l’oggetto che viene invocato devono essere entrambi presenti affinché la comunicazione possa avvenire.
Un message-oriented middleware (MOM) è un software che consente a due componenti di comunicare in maniera asincrona. Java Messaging Service (JMS) fornisce uno standard di accesso ai MOM che costituisce un’alternativa all’utilizzo di API proprietarie; ad eccezione di Microsoft Message Queuing, la maggior parte dei prodotti MOM infatti supporta JMS. Il client notifica una certa operazione al server inviando un messaggio (il client in questo caso è detto producer). Il server inserisce i messaggi in un canale sulla quale stanno in ascolto altri client che prelevano il messaggio ed eseguono le operazioni richieste (i componenti in ascolto vengono detti consumer).
Un modello di messaging definisce il modo in cui il processo di messaging coinvolge mittenti e destinatari. I due modelli più popolari, standardizzati in Java EE, sono il point-to-point e il pubish-subscribe.
Nello schema point to point il mittente (Producer) invia un messaggio verso una particolare destinazione. Il ricevente (Consumer) sta in ascolto e riceve i messaggi su quella destinazione(chiamata coda o queue). L’intento del producer è inviare un messaggio ad uno specifico consumer che sarà l’unico a riceverlo, anche se al momento dell’invio non è disponibile. (ci sarà solo un consumer per quella coda queue). Sarà infatti il JMS Broker (servizio che gestisce lo scambio dei messaggi) a tenerlo in coda finché non sarà prelevato dal consumer.
Nello schema publish-subscribe un singolo produttore invia un messaggio ad una destinazione ( che prende il nome di topic) e tutti i consumatori che sono registrati presso quel topic possono riceverlo. Questo modello lavora si adatta particolarmente bene nel caso in sui si voglia effettuare il broadcasting di informazioni verso diversi sistemi.
Un Message-Driven Bean (MDB) è un componente EJB che consuma messaggi da una queue/topic, inviati da un valido client JMS. Per crearlo è sufficiente usare l’annotation:

@MessageDriven

e implementare l’interfaccia MessageListener.

MDB: Esempio

Leggi tutto “MDB (Message Driven Bean) in 5 minuti”

EJB Session Staleless: cosa sono

Gli EJB Session Bean sono delle classi con dei metodi invocabili da remoto (semplificando molto possiamo dire che sono come le servlet, ma le servlet hanno solo due metodi doget e dopost, i session invece possono avere tutti i metodi che vogliamo). Sono composti da una classe e due interfacce. Per poter invocare un EJB Session bisogna avere una delle interfacce. Le interfacce sono dette locali o remote, in basa a dove permettono di richiamare il session. Da remoto vengono utilizzati i protocolli distribuiti come RMI-IIOP (Remote Method Invocation o RMI è una tecnologia che consente l’invocazione remota dei metodi);
Gli EJB Session sono transazionali, ossia permettono di gestire le transazioni.
Esistono due tipi di session bean:

• stateful:  viene memorizzato lo stato fra una richiesta e l’altra del client, ossia garantisce che tutti i campi   dell’EJB Session saranno salvati per la successiva richiesta dello stesso client.
• stateless: non viene mantenuto alcun stato e vengono utilizzati per modellare quelle elaborazioni che si completano con una sola richiesta

EJB Session Staleless: esempio

Leggi tutto “Ejb Session Stateless Esempio”