Üzenetkezelés

Tartalom Célok RPC modell MOM modell JMS MSMQ Web-szolgáltatások és az üzenetkezelés

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 web-szolgáltatások viszonyának megértése: –mikor melyiket érdemes használni

RPC modell RPC, CORBA és bizonyos értelemben a WS over HTTP is ilyenek int Add(int left, int right) compiler Add stub Add stub Add skeleton Add skeleton int result = Add(5,8); int Add(int left, int right) { return left+right; } Kérés: Add Paraméterek: 5, 8 Kérés: Add Paraméterek: 5, 8 Válasz: 13

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

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

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), solicit-notify, request-async response 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

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

Üzenetkezelő-rendszer példák ÜzenetCél végpontFuttató környezet Fájl átvitel fájlkönyvtár a fájlrendszerben operációs rendszer Adatbázis rekordtáblaadatbázis postafiókSMTP szerver SOAP SOAP XMLtranszporttól függalkalmazás- szerver JMS/MSMQ byte, text, object, stream, map queue (point-to-point), topic (pub-sub) 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) üzenetek transzformációja, route-olása

Ü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 web-szolgáltatások transzportrétegtől függően támogatják mindkét modellt (ld. később)

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

JMS queue modell point-to-point queue receiver message receiver sender

JMS topic modell publish-subscribe topic durable subscriber (attached) durable subscriber (attached) message transient subscriber (attached) transient subscriber (attached) publisher durable subscriber (detached) durable subscriber (detached) transient subscriber (attached) transient subscriber (attached) ismételt csatlakozáskor

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

Programozási modell Connection Factory Connection Factory Connection Session Message Producer Message Producer Message Consumer Message Consumer Destination Message Listener Message Listener létrehozza ráépül aszinkron feldolgozás (callback) előállít szinkron feldolgozás (pollozás) aszinkron feldolgozás (callback)

Programozási modell BaseType(Unified Domain) Point-to-Point Domain Publish/Subscribe Domain DestinationQueueTopic ConnectionFactoryQueueConnection- Factory TopicConnection- Factory ConnectionQueueConnectionTopicConnection SessionQueueSessionTopicSession MessageProducerQueueSenderTopicPublisher MessageConsumerQueueReceiverTopicSubscriber -QueueRequestorTopicRequestor

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

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

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.

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);

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);

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

Üzenet fejlécei

Ü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

Ü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();

Ü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);

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);

Ü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

Ü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(); }

Ü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!

Ü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());

Ü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!

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);

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"); qsender.send(tm); // itt qsession.commit()-ra mindkét üzenet elküldésre kerülne // itt qsession.abort()-ra mindkét üzenet elveszne

MSMQ: Microsoft Message Queue

Microsoft operációs rendszereken Jelenlegi verzió: 4.0 –Windows Vista, Windows Server 2008 Támogatja a legfontosabb üzenetkezelési feladatokat: –szinkron és aszinkron működés –lazán- és erősen csatolt műveletek –tranzakciós küldés/fogadás –prioritások –határidők –szűrés.NET interfész: –Névtér: System.Messaging –DLL: System.Messaging.dll

Programozói modell Queue: –1. MessageQueue létrehozása –2. property-k, szűrők beállítása Küldés: –1. Message létrehozása, kitöltése –2. Send() Fogadás: –1. Formatter létrehozása –2. Message kiolvasása –3. kicsomagolás

MessageQueue létrehozása Már léteznie kell a Queue-nak a gépen A MessageQueue csak egy csomagoló A Queue neve case-insensitive string queueName if (MessageQueue.Exists(queueName)) { using (MessageQueue myQ = new MessageQueue(queueName)) { //... }

Message létrehozása Message objektum példányosítása Tartalom kitöltése Label megadása: alkalmazás által definiált azonosító Extension megadása: alkalmazás által definiált plusz infó byte-tömbként // Konstruktorban feltöltve: using (MessageQueue myQ = new MessageQueue(queueName)) { Message msg = new Message("Hello, MSMQ!"); msg.Label = "Greetings"; } // Vagy a Body property-vel: using (MessageQueue myQ = new MessageQueue(queueName)) { Message msg = new Message(); msg.Body = "Hello, MSMQ!"; msg.Label = "Greetings"; }

Message elküldése MessageQueue.Send() átadva paraméterként az üzenetet Overload-olt változat: a Label is megadható –a Label-t az MSMQ figyelmen kívül hagyja, csak az alkalmazás számára releváns using (MessageQueue myQ = new MessageQueue(queueName)) { Message msg = new Message("Hello, MSMQ!"); myQ.Send(msg); myQ.Send(msg, "greetingmsg"); }

Message fogadása Formatter létrehozása Receive(), Peek() vagy GetAllMessages() meghívása a Body property kiolvasása using (MessageQueue myQ = new MessageQueue(queueName)) { myQ.Formatter = new XmlMessageFormatter(new Type[] {typeof(string)}); // első üzenet kiolvasása, de a sorban hagyása: Message msg = myQ.Peek(); // első üzenet kiolvasása és törlése a sorból: Message msg2 = myQ.Receive(); Console.WriteLine((string)(msg.Body)); }

Üzenetek szűrése A MessageReadPropertyFilter azt adja meg, mely property-ket szeretnénk kiolvasni A property értéke alapján nincs szűrés! using (MessageQueue myQ = new MessageQueue(queueName)) { myQ.Formatter = new XmlMessageFormatter(new Type[] {typeof(string)}); // A Label-t és az Extension-t is olvassa ki: myQ.MessageReadPropertyFilter.Label = true; myQ.MessageReadPropertyFilter.Extension = true; Message m = myQ.Receive(); Console.WriteLine(m.Label); // Az üzenet címkéje Console.WriteLine(m.Priority); // Mindig 0 lesz }

Request-response Message.ResponseQueue property tartalmazza a válasz queue-t A kérő a Send() meghívása előtt beállítja az értékét A válaszoló erre válaszol egy Receive() vagy Peek() után Teljesen alkalmazásszintű, alapértelmezett értéke null using (MessageQueue responseQueue = new using (MessageQueue senderQueue = new { responseQueue.Formatter = new XmlMessageFormatter(new Type[] { typeof(string) }); Message msg = new Message("Hello, there!"); msg.ResponseQueue = responseQueue; senderQueue.Send(msg); Message responseMsg = responseQueue.Receive(); Console.WriteLine(responseMsg.Body); }

Queue-k típusai Alkalmazás szintű sor (Application Queue) –adminisztrátorok vagy programozók által létrehozva –négy szerepkör: destination administration response report Rendszersor (System Queue) –az MSMQ hozza létre –típusai: dead-letter journal connector

Application Queues Destination Queues –tárolja az üzeneteket az alkalmazás számára –típusai: public: directory service-be regisztrált private: minimális directory overhead, nincs lookup Administration Queues –a rendszer által generált visszaigazolásokat tárolja Response Queues –a kérés üzenetekre küldött válaszokat tárolja Report Queues –publikus queue –monitorozó üzeneteket tárol a route-olásról

System Queues Dead-letter Queues –a kézbesíthetetlen üzenetek végső nyughelye –minden egyes queue-ra külön –csak olvasható, közvetlenül nem küldhető bele üzenet Journal Queues –az elküldött üzenetek másolatait tárolja –jobb QoS-t biztosít –csak olvasható, közvetlenül nem küldhető bele üzenet –olyan, mint az adatbázis log Connector Queues –route-olásnál használt –tárolásra és forward-olásra

Üzenet tartalma Bármilyen objektum lehet, ha a Formatter kezelni tudja Három lehetséges Formatter: –ActiveXMessageFormatter –BinaryMessageFormatter:.NET szerializálás –XmlMessageFormatter (ez az alapértelmezett):.NET XmlSerializer-t használ Küldéskor a Message.Formatter property-t kell beállítani Fogadáskor a MessageQueue.Formatter property-t

Aszinkron fogadás Eseménykezelés segítségével: ReceiveCompleted A fogadó szálat a nem blokkoló BeginReceive függvénnyel lehet elindítani A Delegate meghívódik egy thread-pool szálból –az EndReceive meghívásával kapja meg az üzenetet –utána explicit meg kell hívnia a BeginReceive-et is! Ugyanígy működik a PeekCompleted / BeginPeek / EndPeek hármas

Aszinkron fogadás public void ReceiveCallback(object src, ReceiveCompletedEventArgs a) { MessageQueue q = (MessageQueue)src; Message msg = q.EndReceive(a.AsyncResult); //...üzenet feldolgozása... q.BeginReceive(); // újra elindítani az aszinkron működést } using (MessageQueue myQ = MessageQueue.Create(queueName)) { myQ.Formatter = new XmlMessageFormatter(new Type[] { typeof(string) }); myQ.ReceiveCompleted += new ReceiveCompletedEventHandler(ReceiveCallback); myQ.BeginReceive(); }

Tranzakciók Üzenetek csoportosítása atomi feldolgozáshoz Kézbesítés garantált ACID feltételekkel MessageQueueTransaction scope használatával Commit() esetén minden üzenet kézbesítődik using (MessageQueue mq = new MessageQueue(queueName)) using (MessageQueueTransaction mqtx = new MessageQueueTransaction()) { mqtx.Begin(); Message msg1 = new Message("First message"); Message msg2 = new Message("Second message"); mq.Send(msg1, mqtx); Assert.IsTrue(mq.GetAllMessages().Length == 0); mq.Send(msg2, mqtx); Assert.IsTrue(mq.GetAllMessages().Length == 0); mqtx.Commit(); // vagy mqtx.Abort() Assert.IsTrue(mq.GetAllMessages().Length == 2); }

Web-szolgáltatások és az üzenetkezelés

Web-szolgá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

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

WS-* szabványok Web-szolgá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: nincs megoldás –Tranzakciók: WS-AtomicTransaction, WS-Coordination –Változtatás, fejlődés: a jó API segíthet

Alternatív megoldás HTTP transzport helyett JMS vagy MSMQ 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

MQ Eszközök 58

MQ Eszközök MSMQ: –Microsoft Message Queue JMS: –Sun: OpenMQ –IBM: WebSphere MQ –Oracle: Oracle AQ –Apache: ActiveMQ –Tibco –SonicMQ 59

Üzenetkezelés összefoglalás

MQ rendszerek problémái JMS, MSMQ: csak a kliens interfész adott Szerverek közti adatcsere nem szabványos MSMQ esetén ez nem gond: egy gyártó, egy implementáció JMS esetén azonban: sok gyártó, sokféle implementáció JMS és MSMQ között nincs átjárás 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

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

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

MSMQ A System.Messaging névtér kényelmes.NET API-t biztosít az MSMQ-hoz Támogatja a P2P és a Pub-Sub szemantikát A request/response segítségével szimulálni tudja az RPC-stílusú kommunikációt Nagyobb flexibilitást biztosít, mint a sima RPC

Web-szolgá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, MSMQ) ötvözni tudják az RPC és az MQ modell előnyeit, de ez az interoperabilitás rovására mehet Előbb-utóbb a megfelelő WS-* szabványok további előnyöket jelenthetnek