Java Message Service

1 Intro
• •

JMS este un produs din categoria MOM – Message-Oriented Middleware. ca si alte produse Sun (e.g.: JCE), JMS este compus dintr-un set de interfete si semanticile asociate acestora; implementarile lor sunt oferite de 3rd party providers. Specificatia nu cere imperativ (desi recomanda acest lucru) ca implementarile providerilor JMS sa fie scrise integral in Java. JMS nu specifica aspecte legate de load balancing, toleranta la defecte, notificari in caz de erori, administrare sau securitate. Astfel de aspecte sunt lasate la latitudinea providerilor (si, intr-adevar, acestia – Sun in primul rand – ofera astfel de functionalitati in extensiile la implementarile lor de JMS, care extensii insa nu mai sunt gratuite). JMS este o componenta ceruta de specificatia J2EE.

2 Arhitectura JMS

O aplicatie JMS consta din:
• • •

un set de mesaje; o multime de clienti care comunica prin aceste mesaje; obiecte JMS administrate; acestea au rolul de a decupla (izola) clientul de aspectele providerilor dependente de implementare:

ConnectionFactory – folosit de client pentru a crea o conexiune cu un provider Destination – specifica destinatia mesajelor, dar si sursa acestora

Obiectele administrate sunt plasate (“bind”) intr-un spatiu de nume JNDI de catre un administrator, unde sunt cautate (“lookup”) de catre clienti.

Administrative Tool Bind JNDI Namespace L k oo up JMS Client Logical Connection JMS Provider • JMS suporta mesaje in modelele (“messaging domains”) Point-to-Point si Publish/Subscriber. exista un set de interfete comune. care suporta ambele modele (si a caror utilizare este incurajata in defavoarea celor specializate. cu scopul de a decupla clientul de modelul exact de mesaje). Exista un set de interfete specializate pentru trimiterea/receptionarea mesajelor in modelul Point-to-Point precum si un set de interfete pentru mesajele in modelul Pub/Sub. Aceste seturi de interfete sunt: PTP-specific Interfaces Pub/Sub-specific Interfaces QueueConnectionFactory QueueConnection Queue QueueSession QueueSender QueueReceiver. In plus. un mesaj ajuns la o destinatie de tip Topic se pierde daca nu exista deja un TopicSubscriber. anume bazata pe modelul Pub/Sub dar care pastreaza mesajele: este vorba de durable subscription. QueueBrowser TopicConnectionFactory TopicConnection Topic TopicSession TopicPublisher TopicSubscriber JMS Common Interfaces ConnectionFactory Connection Destination Session MessageProducer MessageConsumer • Un mesaj trimis la o destinatie PTP (Queue) este pastrat chiar daca nu exista in acel moment nici un QueueReceiver care sa-l preia. Exista si o configuratie cu ambele caracteristici. Relatiile intre obiectele JMS care implementeaza interfetele de mai sus sunt urmatoarele: • . Spre deosebire.

Conexiunile pot fi autentificate. ca si pentru mesaje. pentru MessageProducer si MessageConsumer. ci unei destinatii. prin specificarea unui username si a unei parole. 4. Connection este de asemenea un factory pentru Sessions.1. Din motive care tin de stabilirea conexiunii si alte aspecte precum autentificarea. Un mesaj nu este trimis direct unui consumator. Session permite lucrul in context tranzactional. Connection este conexiunea activa a unui client cu un provider. un Connection este un o resursa costisitoare si de aceea clientii prefera. de unde un potential consumator il poate obtine fie conectandu-se direct (modul sincron). tipic. ConnectionFactory incapsuleaza un set de parametri de configurare definiti de administrator. este implementatat ca o conexiune TCP/IP intre un client si provider. Session este la randul sau un factory. 2. tranzactii – este interzis explicit de specificatia JMS) care foloseste conexiunea pentru a produce si a consuma mesaje. reutilizarea conexiunilor. 3. tipic. O sesiune poate crea si deservi mai multi MessageProducer-i si . fie inregistranduse (“subscribe”) si asteptand sa-i fie trimis (modul asincron). Destinatia poate fi un Topic (in modelul Publish/Subscribe) sau un Queue (in modelul Point-to-Point). la crearea lor cu ConnectionFactory. Destination este un concept central in JMS. O sesiune este un context single-threaded (accesul multi-threaded la resursele unei sesiuni – conexiune.

6. cat si automat. corp – JMS defineste cateva tipuri standard de mesaje. la primirea mesajului. folosite pentru identificarea si rutarea mesajelor (ex.: JMSDestination. Un mesaj este compus din: • • header – campuri standard. nu utilizatorii umani (acesta este unul din motivele pentru care JMS nu poate fi asimilat. JMSMessageID. care functioneaza ca un filtru de mesaje. MapMessage – contine un set de perechi nume-valoare. JMSReplyTo.String. specifice aplicatiilor sau specifice providerilor. • • • • • • JMS suporta atat modul sincron cat si asincron de transmitere a mesajelor Se poate face o selectie (filtrare) a mesajelor.MessageConsumer-i. suportate de toti clientii. atat de catre aplicatia client. iar consumatorii lor sunt aplicatiile enterprise. fie asincron (prin inregistrarea unui MessageListener). MessageProducer este folosit de client pentru a trimite mesajele catre o Destination. de catre provider. definite de interfete specifice: • • • StreamMessage – este scris/citit secvential si contine un sir de valori primitive (tipuri primitive Java). TextMessage – contine un java. 'AU')”. Un consumator poate procesa mesajele fie sincron (cu blocare in asteptarea acestora). Ex. JMSTytpe. pot fi standard (definite de JMS ca extra campuri din header). “Country IN ('EN'. MessageConsumer este folosit de client pentru a primi mesajele de la o Destination. A fost introdus in ideea suportului pentru XML in corpul mesajelor. 3 Mesajele JMS • Mesajele JMS au formatul bine specificat.: “age NOT BETWEEN 22 AND 30”. JMSPriority). explicit. 5. Unui consumator i se poate specifica un selector. de exemplu. care este o interogare de tip SQL (un subset mai simplu al standardului SQL92). ObjectMessage – contine un obiect serializabil.lang. care insa trebuie folositi secvential in contextul sesiunii. Clientul poate specifica parametri precum prioritatea sau time-to-live pentru mesajele trimise. . proprietati – optionale. Sunt de tipul nume-valoare si permit clientilor sa-si filtreze mesajele la primire. BytesMessage – contine un stream de bytes neinterpretati. 'NZ'. cu un Mail API). folosind un MessageSelector.

3RC2.provider. crash. '_' este wildcard-ul pentru un singur caracter iar '%' este wildcard-ul pentru o secventa de oricate caractere. nu sunt persistente si nu vor fi accesibile dupa un restart al serverului. • Trimiterea mesajelor poate fi facuta persistent (providerul garanteaza ca mesajul nu este pierdut in timpul trimiterii datorita unei erori.jar. JBoss are propria sa implementare de JNDI. astfel. 4 Suportul JMS in JBoss AS In cele ce urmeaza.: “phone LIKE '072_123456'” este adevarat pentru '0729123456' si fals pentru '07223123456'. Similar. Semantica trimiterii unui mesaj non-persistent este at-most-once.properties: java. overheadul transmiterii mesajului este mai mic. “integerproperty >= 43”. etc. jboss-common-client. Semantica trimiterii unui mesaj persistent este once-and-only-once (presupunand ca time-to-live este suficient de lung astfel ca mesajul sa nu expire inainte sa ajunga la destinatie).jar.mq” (are operatii precum createQueue(String queueName)). Destinatiile (in ambele modele.jar. dar mesajul se poate pierde in cazul unui crash al providerului).jar. • Implementarea JBoss pentru ConnectionFactory se gaseste in JNDI sub numele “ConnectionFactory”.url=localhost • • • • O noua destinatie JMS se poate crea fie editand direct fisierele de configurare. De asemenea. Intr-un selector.naming. fie din consola JMX a serverului (accesibila prin http://localhost:8080/jmx-console (toate destinatiile preconfigurate de JBoss la startup sunt listate in sectiunea “jboss. jboss-system-client. PTP si Pub/Sub) sunt configurate prin intermediul MBean-urilor. Jar-urile necesare unei aplicatii JMS-JBoss sunt: jbossmq-client. se poate include si doar jbossallclient. Ex.jar. Destinatiile create dinamic. “phone LIKE '07%123456'” este adevarat pentru '0744123456'. jnp-client.destination”). ne vom referi la JBoss-4. .0. din consola JMX. (for the lazy. JBoss are un provider propriu de JMS. jboss-j2ee. a providerului) sau non-persistent (mesajul nu este logat pe suport persistent. Urmatoarea proprietate trebuie adaugata in jndi. prin intermediul linkului “service=DestinationManager” din sectiunea “jboss. numit JBossMQ.jar) Fisierul jndi.“propname IS NOT NULL”.properties cu care vine JBoss trebuie sa fie accesibil prin CLASSPATH.mq.

<line_no++> = INSERT INTO JMS_USERS (USERID. Modificarea consta in doua linii “POPULATE. 1. aceasta procedura ar putea trebui repetata..TABLES”.xml .Queue” name=”jboss. 'write' si 'create' pe topicul pe care vrem sa subscriem. 'james') (Nu e elegant. 'bond'. din cauza ca aplicatiile sender si receiver nu pot folosi acelasi username si parola pentru stabilirea unei conexiuni autentificate. un rol este un grup de useri care au aceleasi permisiuni): POPULATE. In versiunile anterioare ale JBoss.xml (dupa modelul userului “john”:”needle” existent deja acolo).mq. care e descris in fisierul jms/hsqldb-jdbc-state-service.TABLES.TABLES. o descriere similara celei de mai jos trebuie adaugata acolo: <mbean code=”org.server. el este inca prezent in sectiunea de documentatie si exemple. o cale de a introduce userul “james” cu parola “bond” este modificarea scriptului de initializare a bazei de date.Toate destinatiile preconfigurate sunt descrise in fisierul deploy/jms/jbossmq-destinations-service. In cazul in care si senderul are nevoie de autentificare. (Acum.<line_no++> = INSERT INTO JMS_ROLES (ROLEID. campul CLIENTID din query-ul de mai sus trebuie sa fie unic pentru fiecare pereche “username:parola”.name=myQueue”> </mbean> (exemplele MBean-urilor deja configurate acolo sunt suficiente). 'LPDSubscriberExample') POPULATE. desi fisierul nu mai exista in deployment. In plus.xml. PASSWD. In descrierea acestui topic din fisierul hsqldb-jdbc-state-service. in sectiunea <security>.jboss. si in definitiv este vorba de un fisier .mq.destination:service=Queue. dar functioneaza. in cazul folosirii unui durable subscription). una pentru adaugarea userului cu parola sa in baza de date si una pentru atribuirea unui rol userului (poate avea mai multe astfel de roluri simultan – practic.xml) Uzual (de exemplu. urmatoarea linie trebuie adaugata pentru ca exemplul nostru sa functioneze: <role name=”lpdPublisher” read=”true” write=”true” . O subscriptie durabila se poate face numai pe baza unui username si a unei parole. doar receiverul are nevoie de conexiuni autentificate. CLIENTID) VALUES ('james'.jmx. Pentru a adauga o noua destinatie persistenta. USERID) VALUES ('lpdPublisher'. exista un fisier “jbossmqstate.. Rolul 'lpdPublisher' introdus mai sus cu titlu de exemplu trebuie sa aiba permisiunile 'read'.) In versiunea curenta.xml” in care se puteau defini aceste credentials.

6. Se foloseste Connection pentru a crea unul sau mai multe obiecte Session.create=”true”/> Atat in cazul fisierului hsqldb-jdbc-state-service.xml cat si al fisierului jbossmq-destinations-service. astfel incat modificarea unei configurari nu necesita restartarea serverului.com/products/jms/docs. Se folosesc un obiect Session si unul sau mai multe Destination pentru a crea obiecte MessageProducer si MessageConsumer. 6 Bibliografie 1. 4. 2. Se foloseste JNDI pentru a gasi un obiect ConnectionFactory. JMS 1. JBoss isi actualizeaza configuratia la run-time. 5.html) 2. 3. Se activeaza trimiterea de mesaje prin Connection. Se foloseste ConnectionFactory pentru a crea un obiect Connection.xml.jboss. . 5 Pasii pentru scrierea unui client JMS 1. JBoss Application Server Guide si JBoss AS Getting Started Guide (http://www.sun.1 spec si JMS API Spec (http://java. Se foloseste JNDI pentru a gasi unul sau mai multe obiecte Destination.com/products/jbossas/docs) – contin si exemple cu JMS in diferite configuratii.

Sign up to vote on this title
UsefulNot useful