Előadást letölteni
Az előadás letöltése folymat van. Kérjük, várjon
1
Java Message Service Simon Balázs
Robotzsaru oktatás Java Message Service Simon Balázs
2
Tartalom Célok RPC modell MOM modell JMS
Webszolgáltatások és az üzenetkezelés
3
Célok RPC problémáinak bemutatása
Üzenetkezelő rendszerek működésének megértése A legfontosabb üzenetkezelő API-k megismerése Előnyök és hátrányok RPC, MOM és webszolgáltatások viszonyának megértése: mikor melyiket érdemes használni
4
RPC modell RPC, CORBA és bizonyos értelemben a WS over HTTP is ilyenek
int Add(int left, int right) compiler int Add(int left, int right) { return left+right; } int result = Add(5,8); Kérés: Add Paraméterek: 5, 8 Add skeleton Add stub Válasz: 13
5
Problémák A modell nem oldja meg a következő problémákat:
A hálózati kapcsolat megszakad, kihagyások vannak (pl. WLAN) Üzemszünet a kiszolgáló oldalán Burst jellegű kérések (pl. adóbevallás) Skálázás Prioritások Tranzakciók Változtatás, fejlődés
6
Az RPC problémái Egyszerű kommunikáció, amelynek ára van:
kérés/válasz kommunikáció: minden kérésre választ várunk a kliens blokkolódik a válasz megérkezéséig a szervernek mindig elérhetőnek kell lennie a servant-ok és stub-ok fordítási időben fixálódnak az erős típusosság megkönnyíti a programozást de a változtatás nehezebb az RPC alapja a viselkedés
7
Megoldás: üzenetkezelés
Szedjük szét az RPC-t: RPC = kérés üzenet + válasz üzenet kezeljük külön a kettőt különböző MEP-ek (Message Exchange Pattern): request-response, one-way (fire-and-forget) Az üzenetkezelés alapja az adat üzenetből indulunk ki, nem contract-ból a contract-ot igazítjuk az üzenethez megjegyzés: kicsit hasonlít az RPC-hez pl. UjUgyfel típusú üzenet hatására létrehozunk egy új ügyfelet probléma: állapottal rendelkező kapcsolat
8
Mi az üzenetkezelés? Üzenet: fejlécek + tartalom
az átvitel lehet aszinkron a tartalom formátuma nincs megkötve Cél végpont: névkatalógus alapján szétcsatolja a producer-t és a consumer-t az üzenetek átirányítása, route-olása egyszerűbb Futtató környezet: különböző átviteli módszerek megbízható, tranzakciós, prioritásos, határidős, publish-subscribe egy vagy több csatornát biztosít a továbbításra
9
Üzenetkezelő-rendszer példák
Cél végpont Futtató környezet Fájl átvitel fájl könyvtár a fájlrendszerben operációs rendszer Adatbázis rekord tábla adatbázis postafiók SMTP szerver SOAP SOAP XML transzporttól függ alkalmazás-szerver JMS/MSMQ byte, text, object, stream, map queue (point-to-point), topic (pub-sub) MOM
10
MOM MOM = Message Oriented Middleware Előnyök: flexibilitás
többfajta MEP (one-way, multicast, disconnected, ...) üzenetek transzformációja, route-olása könnyebb karbantartás, változtatás (az üzenet formátuma változhat: nem kell minden klienst újrafordítani) dead-lock elkerülése (ld. RPC blokkolódás) burst terhelés kezelése a queue-k tárolják az üzeneteket a feldolgozók olyan gyorsan dolgozhatnak, ahogy szeretnének újabb feldolgozók hozzáadhatók vagy megvárható, amíg a terhelés alábbhagy integráció az üzenet maga a típus nem szükséges szorosan csatolt API különböző rendszerek között is jó (pl. XML a .NET és Java között)
11
Üzenetkezelő-rendszer problémák
A kommunikáció egy queue-val történik, nem egy objektummal kétirányú kommunikáció legalább két queue-t igényel Nincs állapot az üzenetek sorrendje nem garantált szinkron kommunikáció emulálása plusz munkát igényel Az objektumok nem azonosíthatók az üzenetek egy queue-ba érkeznek, nem egy objektumhoz nem hagyományos kliens-szerver inkább termelő-fogyasztó jellegű Kérés-válasz típusú kommunikáció esetén maradjunk az RPC modellnél! Megjegyzés: a webszolgáltatások transzportrétegtől függően támogatják mindkét modellt (ld. később)
12
JMS: Java Message Service
13
JMS: Java Messaging System
Üzenetkezelés kliens oldali interfészét specifikálja Java-ban verziók: 1.0.2b, 1.1 package: javax.jms.* Támogatja a legfontosabb üzenetkezelési feladatokat: szinkron és aszinkron működés lazán- és erősen csatolt műveletek point-to-point és publish-subscribe garantált vagy gyors átvitel tranzakciós küldés/fogadás prioritások határidők szűrés
14
JMS Eszközök Sun: OpenMQ IBM: WebSphere MQ Oracle: Oracle AQ
Apache: ActiveMQ Tibco SonicMQ
15
JMS queue modell point-to-point sender receiver queue receiver sender
message message message sender receiver
16
JMS topic modell publish-subscribe durable subscriber (attached)
transient subscriber (detached) publisher topic message message message transient subscriber (attached) publisher durable subscriber (detached) ismételt csatlakozáskor
17
Programozási modell Mindkét modellre hasonló:
Factory: JNDI alapján kikeresve Connection: fizikai kapcsolat a JMS provider-hez Session: szál szintű környezet küldéshez és fogadáshoz Destination: a végpont, JNDI alapján kinyerhető A Factory és a Destination ún. adminisztrált objektumok (Administered Object) felvételük: rendszeradminisztrátorok által, nem programozók által néhány JMS provider biztosít ehhez API-t is
18
Programozási modell Connection Factory Connection Message Producer
létrehozza Connection Message Producer előállít létrehozza létrehozza ráépül Session Destination Message szinkron feldolgozás (pollozás) aszinkron feldolgozás (callback) ráépül létrehozza Message Consumer Message Listener aszinkron feldolgozás (callback)
19
Programozási modell BaseType (Unified Domain) Point-to-Point Domain
Publish/Subscribe Domain Destination Queue Topic ConnectionFactory QueueConnection-Factory TopicConnection-Factory Connection QueueConnection TopicConnection Session QueueSession TopicSession MessageProducer QueueSender TopicPublisher MessageConsumer QueueReceiver TopicSubscriber - QueueRequestor TopicRequestor
20
Connection létrehozása
ConnectionFactory kikeresése Connection létrehozása A start()-ot utoljára hívjuk meg! Általában egy Connection példány egy JVM-ben elég // A nevet a rendszeradminisztrátor választja: String qfname = "jms/MyQueueConnectionFactory"; Context ctx = new InitialContext(); QueueConnectionFactory qfac = (QueueConnectionFactory)ctx.lookup(qfname); QueueConnection qcon = qfac.createQueueConnection(); // ...egyéb beállítások... qcon.start(); // üzenetek fogadásának kezdete
21
Session létesítése Létrehozás a Connection segítségével
Csak az adott szálra biztonságos! Opciók: tranzakció (JTA) visszaigazolás típusa AUTO_ACKNOWLEDGE CLIENT_ACKNOWLEDGE DUPS_OK_ACKNOWLEDGE QueueConnection qcon = ...; // korábbról QueueSession qsession = qcon.createQueueSession( false, // tranzakció? Session.AUTO_ACKNOWLEDGE); // visszaigazolás módja
22
Visszaigazolás típusa
AUTO_ACKNOWLEDGE Minden egyes üzenet automatikusan visszaigazolásra kerül. A Session szál blokkolódik, amíg a broker feldolgozza a visszaigazolást. CLIENT_ACKNOWLEDGE A kliens explicit igazolja vissza az üzeneteket az üzenet acknowledge() függvényével. Minden eddig átvett üzenet visszaigazolódik. A Session szál blokkolódik, amíg a broker feldolgozza a visszaigazolást. DUPS_OK_ACKNOWLEDGE A Session 10 üzenet után igazol vissza, a szál nem blokkolódik. Üzenet nem veszik el, de lehetséges, hogy többször is kézbesítődik.
23
Destination kikeresése
JNDI alapján A nevet az adminisztrátor állítja be Tipikus prefix: „jms/” (de nem kötelező) Context ctx = ...;// korábbról // A nevet a rendszeradminisztrátor választja: String qname = "jms/MyQueue"; Queue queue = (Queue)ctx.lookup(qname);
24
Producer létrehozása Ahhoz a Session-höz kötődik, amelyik létrehozta
Ez küldi az üzeneteket QueueSession qsession = ...; // korábbról Queue queue = ...; // korábbról QueueSender qsender = qsession.createSender(queue);
25
Message felépítése Három rész:
headers: fejlécek a JMS számára route-oláshoz properties: tulajdonságok az alkalmazás számára body: az üzenet törzse, a tényleges adat
26
Üzenet fejlécei Fejléc Leírás Ki adja meg? JMSDestination
Megadja a célt, ahova az üzenetet továbbítani kell. provider JMSDeliveryMode Megadja, hogy az üzenet perzisztens-e. (PERSISTENT, NON_PERSISTENT) alapértelmezettként: provider de a kliens felülbírálhatja JMSExpiration Megadja milliszekundumokban, mikor jár le az üzenet. (Ha 0, akkor sosem jár le.) JMSPriority Megadja az üzenet prioritását: 0 (alacsony) - 9 (magas). JMSMessageID A provider környezetében az üzenet egyedi azonosítója. JMSTimestamp Megadja, hogy a provider mikor vette át az üzenetet kézbesítésre. JMSCorrelationID A kliens ezen keresztül adhatja meg, hogy egy válaszüzenet mely üzenethez tartozik. kliens JMSReplyTo Megadja azt a célt, ahova a választ kell küldeni. JMSType Egy üzenetszűrő által feldolgozható fejléc. JMSRedelivered Megadja, hogy az üzenetet már kézbesítették-e, de még nem volt rá visszaigazolás.
27
Üzenet tartalma A Session hozza létre az üzenetet Fajtái:
StreamMessage: a tartalom DataOutputStream-ként jelenik meg, feltölthető Java primitívekkel MapMessage: rendezetlen név-érték párok TextMessage: Java String, pl. egy XML ObjectMessage: sorosított Java objektum BytesMessage: byte-tömb Message: nincs törzs, csak fejlécek és property-k
28
Üzenetek előállítása StreamMessage sm = qsession.createStreamMessage(); sm.writeString("foo"); sm.writeInt(7); sm.writeDouble(2.5); MapMessage mm = qsession.createMapMessage(); mm.setInt("num1", 7); mm.setString("name", "foo"); mm.setDouble("num2", 2.5); TextMessage tm = qsession.createTextMessage(); tm.setText("hello"); ObjectMessage om = qsession.createObjectMessage(); MyObject obj = new MyObject("foo", 7, 2.5); om.setObject(obj); BytesMessage bm = qsession.createBytesMessage(); byte[] data = new byte[3]; bm.writeBytes(data); Message m = qsession.createMessage();
29
Üzenet elküldése A Producer küldi el A fejlécek felülbírálhatók:
deliveryMode: perzisztens-e PERSISTENT: megbízható, pontosan egyszeri továbbítás, lassabb NON_PERSISTENT: nem megbízható (üzenetek elveszhetnek), legfeljebb egyszeri továbbítás, gyorsabb priority: prioritás (0 – alacsony, ..., 9 – magas) timeToLive: élettartam milliszekundumokban (ha 0, akkor nem jár le) Message msg = ...; // korábbról QueueSender qsender = ...; // korábbról qsender.send(msg); int priority = 0; long timeToLive = 0; qsender.send(msg, DeliveryMode.PERSISTENT, priority, timetolive); int priority = 9; long timeToLive = 10*1000; qsender.send(msg, DeliveryMode.NON_PERSISTENT, priority, timetolive);
30
Consumer létrehozása A Session hozza létre
A Session-höz és a Destination-höz kötődik QueueSession qsession = ...; // korábbról Queue queue = ...; // korábbról QueueReceiver qreceiver = qsession.createReceiver(queue);
31
Üzenet fogadása (szinkron)
pollozás a receive() függvénnyel: blokkol paraméterként megadható a time-out milliszekundumokban pollozás a receiveNoWait() függvénnyel: nem blokkol, azonnal visszatér ha nincs üzenet null a visszatérési érték visszatérési érték típusa: Message igény esetén cast-olni kell
32
Üzenet fogadása (szinkron)
while (true) { Message m = qreceiver.receive(); if (m instanceof BytesMessage) BytesMessage bm = (BytesMessage)m; byte data []; int len = bm.readBytes(data); } else if (m instanceof TextMessage) TextMessage tm = (TextMessage)m; StringBuffer sb = tm.getText(); else if (m instanceof ObjectMessage) ObjectMessage om = (ObjectMessage)m; MyObject obj = (MyObject)om.getObject(); String s = obj.getFoo(); int i = obj.getNum();
33
Üzenet fogadása (aszinkron)
Regisztrálni kell egy MessageListener interfészt implementáló osztályt a Consumer-nél Minden onMessage() hívás külön szálon fut!
34
Üzenet fogadása (aszinkron)
class MyListener implements MessageListener { public void onMessage(Message m) try if (m instanceof StreamMessage) //... } else if (m instanceof MapMessage) catch (Throwable t) // Hiba a feldolgozás során qreceiver.setMessageListener(new MyListener());
35
Üzenetek szűrése Egy selector segítségével szűrhetők a beérkező üzenetek A feltételek a header és a property fejlécekre vonatkozhatnak Nyelv: SQL-92 egy részhalmaza Relációs és boolean operátorok Részletek: JMS 1.1 specifikáció 3.8-as pont // Küldő: TextMessage tm = qsession.createTextMessage(); tm.setText("hello"); tm.setStringProperty("name", "fred"); qsender.send(tm); // Fogadó: QueueReceiver qr = qsession.createReceiver(q, "name='fred'"); TextMessage tm = (TextMessage)qr.receive(); String data = tm.getText(); // tm.getStringProperty("name").equals("fred") -- garantált!
36
Request-response Szinkron hívás szimulálása
Egy TemporaryQueue (vagy TemporaryTopic) jön létre, a JMSReplyTo automatikusan erre mutat A fogadó kinyeri a fejlécet és oda válaszol // Kérő: QueueRequestor qreq = new QueueRequestor(qsession, queue); TextMessage tmin = qsess.createTextMessage(); tmin.setText("Hello"); TextMessage tmout = (TextMessage)qreq.request(tmin); // blokkol // Válaszoló: Message msg = qreceiver.receive(); Destination reply = msg.getJMSReplyTo(); TextMessage tmout = qsess.createTextMessage(); tmout.setText("Hi yourself"); QueueSender qs = qsess.createSender((Queue)reply); qs.send(tmout);
37
Tranzakciók Üzenetek csoportosítása atomi feldolgozáshoz
Kézbesítés garantált ACID feltételekkel Tranzakciós Session JTA-val integrálható (elosztott tranzakció) Commit-ra: mindel elküldött üzenet kézbesítésre kerül minden fogadott üzenet visszaigazolásra kerül boolean tx = true; int ackmode = Session.AUTO_ACKNOWLEDGE; QueueSession qsession = qcon.createQueueSession(tx, ackmode); TextMessage tm = qsession.createTextMessage(); tm.setText("hello"); qsender.send(tm); tm = qsession.createTextMessage(); tm.setText("world"); // itt qsession.commit()-ra mindkét üzenet elküldésre kerülne // itt qsession.abort()-ra mindkét üzenet elveszne
38
Webszolgáltatások és az üzenetkezelés
39
Webszolgáltatások Ezek is üzenetkezelésre épülnek
SOAP üzenetekkel kommunikálnak A WS-* szabványok is üzenet és nem API szinten specifikáltak Támogatják a request-reply (~ RPC modell) és a one-way (~ MQ modell) üzenetkezelést Az üzenetküldési garanciák erősen függnek a használt transzportrétegtől és a felhasznált WS-* szabványoktól
40
Ismétlés: RPC Problémák
Az RPC modell nem oldja meg a következő problémákat: A hálózati kapcsolat megszakad, kihagyások vannak (pl. WLAN) Üzemszünet a kiszolgáló oldalán Burst jellegű kérések (pl. adóbevallás) Skálázás Prioritások Tranzakciók Változtatás, fejlődés
41
WS-* szabványok Webszolgáltatások: tipikusan HTTP transzport felett
A WS-* szabványok próbálják megoldani az RPC problémáit Megoldások (megoldási kísérletek): Hálózati kihagyások, üzemszünet: WS-ReliableMessaging: de perzisztens implementáció kell mindkét oldalon! Burst jellegű kérések, skálázás: nincs megoldás Prioritások: Tranzakciók: WS-AtomicTransaction, WS-Coordination Változtatás, fejlődés: a jó API segíthet
42
Alternatív megoldás HTTP transzport helyett JMS használata Előny:
minden problémát megold, amit egy MQ rendszer megold Hátrányok: nem szabványos binding nem interoperábilis: csak egyetlen MQ implementáción belül működik
43
Üzenetkezelés összefoglalás
44
MQ rendszerek problémái
JMS: csak a kliens interfész adott Szerverek közti adatcsere nem szabványos sok gyártó, sokféle implementáció Két JMS közötti átjárás: JMS-bridge segítségével kliensként viselkedik mindkét irányban problémák: route-olás tranzakciók kézbesítési garanciák nagyon nehéz konfigurálni
45
MQ rendszerek Az üzenetkezelés: rugalmas skálázható
több csatornán keresztül működik több programozói munkát igényel többfajta üzenetcsere-mintát támogat
46
JMS A JMS API kényelmes Java alapú hozzáférést biztosít az implementációhoz Támogatja a P2P és a Pub-Sub szemantikát A Requestor segítségével szimulálni tudja az RPC-stílusú kommunikációt Nagyobb flexibilitást biztosít, mint a sima RPC
47
Webszolgáltatások A JAX-WS (Java) és a WCF (.NET) API kényelmes
Támogatják a Request-Response típusú (~RPC) működést Támogatják a One-way típusú (~MQ) működést Megfelelő transzport réteggel (JMS) ötvözni tudják az RPC és az MQ modell előnyeit, de ez az interoperabilitás rovására mehet
Hasonló előadás
© 2024 SlidePlayer.hu Inc.
All rights reserved.