VÝVOJ PODNIKOVÝCH APLIKACÍ NA PLATFORMĚ JAVA - PŘEDNÁŠKA Zbyněk Šlajchrt Část 10.

Odesílání a příjem zpráv 2

Synchronní komunikace  Doposud jsme se zabývali převážně synchronní komunikací  Klient zavolá business metodu a čeká na výsledek  Příjemce musí být dostupný v okamžiku volání  Klient se musí přizpůsobit charakteru příjemce Platforma Rozhraní Adresa + port Protokol komunikace  Pevná vazba (tight coupling)  Důsledky? 3

Asynchronní komunikace  Při integraci různorodých aplikací často  Není nutné čekat na výsledek  Odesílatel a příjemce nemusí být současně dostupní  Odesílatel "nezná" Platformu příjemce (integrované aplikace) Formu rozhraní na straně příjemce Fyzické umístění příjemce Specifický protokol vyžadovaný příjemcem  Slabá vazba (loose coupling)  Komunikaci zajišťuje "styčný důstojník" MOM  Message-oriented middleware, Provider 4

MOM architektura  Provider – zprostředkovává komunikaci  Producer – odesílatel zprávy  Consumer – příjemce (konzument) zprávy  Destination – úložiště zprávy 5 Producer Consumer Destination Message Provider Msg sendsreceives

Java Message Service (JMS)  Standardní API v Javě pro asynchronní komunikaci prostřednictvím zpráv ( , akt. verze 1.1)  Analogie JDBC – abstrakce databází  JMS – abstrakce MOM  OpenMQ (referenční impl.), MQSeries, SonicMQ a další  Součástí Java EE  Poměrně nízko-úrovňové, avšak dobře fungující API 6

Message Driven Beans (MDB)  Speciální EJB pro příjem zpráv (od EJB 2.0)  Před EJB 3.1 často používané pro asynchronní volání  Pozn.: Od verze EJB 3.1 lze používat asynchronní  MDB je obvykle napojeno na JMS destinaci  fronta, topik  lze teoreticky napojit na jiné protokoly – např. SMTP 7

Architektura JMS 8 Producer Consumer JMS Provide r JMS Provide r JNDI Directory lookup or injection produces a message consumes a message lookup or injection

Komponenty JMS  Provider  implementace JMS  Klienti  libovolná Java aplikace nebo komponenta využívající JSM k odesílání nebo přijímání zpráv producer, sender, publisher, consumer, receiver, subscriber  Zprávy  objekty které klienti posílají nebo přijímají  Administrované objekty  továrny připojení a destinace (fronty, topiky)  umístěny v JNDI 9

Příklad: injektáž 10

Příklad: odeslání zprávy z EJB 11

Příklad příjmu zprávy v EJB 12

JMS destinace  Point-to-point (P2P) model  úložiště se nazývá fronta  jeden klient odesílá zprávu  druhý klient přijímá zprávu  zpráva je po potvrzeném přijetí odstraněna  Publish-subscribe (pub-sub) model  úložiště se nazývá topik  klient odesílá zprávu  všichni klienti přihlášení k odebírání přijímají zprávu  zpráva se odstraní po předání všem odběratelům 13

Point-to-point  Určeno pro jednoho odesílatele a jednoho příjemce  Odeslaná zpráva leží ve frontě dokud ji příjemce nevybere  Odesílatel může odesílat zprávy, kdy se mu zachce  Příjemce může odebírat zprávy, kdy se mu zachce  přijímá i zprávy, které byly odeslány před jeho vytvořením 14 Producer Receiver Queue sends receives

Point-to-point: více příjemců  Nelze se spoléhat na pořadí zpráv  Ke frontě lze připojit více příjemců  Zprávu vždy obdrží pouze jeden  Pořadí předávání příjemcům je náhodné 15 Producer Receiver 1 Queue Receiver 2 M2 M1 M2

Publish-subscribe  V pub-sub je zpráva odesílána jedním klientem  Zpráva může být předána více klientům  pouze těm, co jsou momentálně připojeni  možno zaregistrovat tzv. trvalého příjemce  Příjemce může zprávy přijímat  asynchronně – přihlášení se k odběru, notifikace  synchronně – čekání na zprávu voláním receive() 16 Publisher Subscribe r M M M M subscribes receives publishes topic

Publish-subscribe: více příjemců 17 Publisher Subscriber 1 M2 topic M1 Subscriber 2 M2 M1

Administrované objekty  Objekty konfigurované administrátorsky, coby protiklad k objektům konfigurovaným programově  JMS provider umožňuje jejich správu a zveřejnění v JNDI  Továrny připojení  Tyto objekty využívají klienti pro připojení k destinacím  Destinace  Zařízení sloužící k příjmu, dočasnému ukládání a distribuci zpráv.  Destinace může být fronta (P2P) nebo topik (pub-sub) 18

JMS API 19

javax.jms.ConnectionFactory  Továrny připojení jsou administrované objekty umožňující klientovi připojit se k JMS poskytovateli  Typy továren připojení  javax.jms.ConnectionFactory rozhraní pro vytváření spojení pro P2P i sub-pub komunikaci  javax.jms.QueueConnectionFactory rozhraní pro vytváření spojení pro P2P komunikaci  javax.jms.TopicConnectionFactory rozhraní pro vytváření spojení pro pub-sub komunikaci 20

Získání továrny připojení 21 Vyhledáním v JNDI: Injektáží:

Konfigurace v Glassfish v3 22

javax.jms.Destination  Administrovaný objekt, který identifikuje JMS destinaci, tj. frontu nebo topik  Různí provideři vyžadují různé konfigurace  Programátorovi jsou tato specifika skryta  Dvě rozhraní, která rozšiřují javax.jms.Destination  javax.jms.Queue  javax.jms.Topic 23

Získání destinací 24 Vyhledáním v JNDI: Injektáží:

Konfigurace v Glassfish v3 25

javax.jms.Connection  Thread-safe spojení s destinacemi  Lze jej sdílet mezi vlákny  Důvod: otevření spojení se považuje za náročnou operaci  Vlastní komunikace probíhá v rámci tzv. session  Connection::createSession()  Jedno-vláknový objekt  Metody start(), stop()  Spuštění a zastavení příjmu zpráv  Metoda close()  Uzavření spojení 26

Otevření spojení 27

javax.jms.Session  Poskytuje kontext pro odesílání nebo přijímání zpráv v rámci jednoho vlákna  Session může být transakční  všechny zprávy jsou odeslány až při volání commit()  Pozn.: v CMT se commit provádí automaticky  nebo ne-transakční  každá zprávy je odeslána okamžitě 28 příznak "transakčnosti" session potvrzovací mod

javax.jms.Session - potvrzování  Potvrzovací mod (acknowledge mode)  Specifikuje, jakým způsobem provider zjistí, že zpráva byla klientem zpracována AUTO_ACKNOWLEDGE předání zprávy klientovi se považuje za potvrzení přijetí CLIENT_ACKNOWLEDGE klient musí zavolat na zprávě acknowledge() DUPS_OK_ACKNOWLEDGE session posílá potvrzení v dávkách, nikoliv jednotlivě jako AUTO_ACKNOWLEDGE zlepšuje výkon může docházet k opakovanému přijetí stejné zprávy 29

javax.jms.Session – jako továrna  Továrna na  Zprávy – createMessage()  Odesílatele (Producers) – createProducer()  Příjemce (Consumers) – createConsumer()  Možno použít obecnou Session pro práci s oběma typy komunikace (P2P, pub-sub)  Specializovaná rozhraní pro typ komunikace  javax.jms.QueueSession  javax.jms.TopicSession 30

Zprávy  Struktura zprávy  Hlavička Obsahuje metadata zprávy ve formě párů klíč-hodnota Klíče jsou standardizovány (viz tabulka na dalším snímku) Některé nastavuje provider, jiné aplikace  Vlastnosti Aplikační metadata Lze na ně aplikovat tzv. selektory zpráv  Tělo (nepovinné) Data přenášené zprávou StreamMessage, MapMessage, TextMessage, ObjectMessage, BytesMessage 31

Hlavičky zprávy  JMSDestination  Destinace, na kterou je zpráva odeslána (P)  JMSMessageID  Jednoznačný identifikátor zprávy (A)  JMSExpiration  Doba vypršení platnosti zprávy (A)  JMSTimestamp  Okamžik předání zprávy poskytovateli (P)  JMSPriority  Priorita zprávy (0-9) (A) 32

javax.jms.MessageProducer  Používá se k odesílání zpráv  Vytváří jej Session::createProducer  V P2P se mu přezdívá sender implementuje QueueSender  V pub-sub se mu přezdívá publisher implementuje TopicPublisher  Může specifikovat  prioritu  dobu platnosti  mód doručení – PERSISTENT nebo NON_PERSISTENT 33

MessageProducer - příklad 34

javax.jms.MessageConsumer  Používá se k přijímání zpráv  Vytváří jej Session::createConsumer  V P2P se mu přezdívá receiver Implementuje QueueReceiver  V pub-sub se mu přezdívá subscriber Implementuje TopicSubscriber  Zprávy lze přijímat dvěma způsoby  synchronně  asynchronně 35

Synchronní příjem zpráv  V tomto případě příjemce zavolá na připojení metodu start() a čeká na zprávu voláním metody receive() na rozhraní MessageConsumer  Více variant metody receive  Message receive() blokuje vlákno dokud nedorazí zpráva  Message receive(long timeout) blokuje vlákno dokud nedorazí zpráva nebo nevyprší časový limit (vrací null)  Message receiveNoWait() neblokující metoda, vrací okamžitě zprávu nebo null 36

Synchronní příjem: příklad 37

Asynchronní příjem zpráv  Klient zaregistruje posluchače prostřednictvím rozhraní MessageConsumer::setMessageListener()  Až po registraci se zahájí příjem zpráv voláním Session::start()  Při přijetí zprávy poskytovatel zavolá na posluchači metodu onMessage(Message message)  Tato strategie je využívána v MDB 38

Asynchronní příjem: příklad 39

Selektory  Někdy je zapotřebí filtrovat přijímané zprávy  Důvod může být například snížení zatížení sítě  Klient může při vytváření objektu MessageConsumer specifikovat kritéria pro přijímané zprávy  Kritéria lze klást na  Hlavičky (JMS... páry)  Vlastnosti (aplikační údaje)  Kritérium je vyjádřeno výrazem podmínky  podmnožina syntaxe podmínky z SQL 92 40

Selektory: příklad 41 Příjemce: Odesílatel: Operátory Logické: NOT, AND, OR Porovnávací: =, >, >=, Aritmetické: +, -, *, / Výrazy [NOT] BETWEEN, [NOT] IN, [NOT] LIKE, IS [NOT] NULL

Durable Subscribers  Nevýhoda pub-sub modelu je, že odběratel přijímá zprávy odeslané pouze v době, kdy je připojen  JMS umožňuje vytvořit tzv. trvalý zápis (durable subscription)  session.createDurableSubscriber(topic, "subscriberID")  V tomto případě provider ukládá zprávy pro odběratele, pokud není zrovna on-line  Nejvíce jeden posluchač může být on-line  Zrušení trvalého zápisu session.unsubscribe("subscriberID") vypršení 42

Non-durable subscription 43

Durable subscription 44

Message Driven Beans (MDB)  Další typ EJB  Určen k asynchronnímu přijímání zpráv  Není volán přímo jako ostatní EJB  Funguje jako posluchač na vybrané JMS destinaci  Blízký příbuzný bez-stavového EJB  Zjednodušuje jinak poměrně složitý programovací model JMS 45

Podpora ze strany kontejneru  Můžeme použít skoro všechny "vychytávky", které známe z ostatních EJB  Injection  CMT  Vláknová bezpečnost - podobně jako u ostatních EJB  Interceptory  Callback metody 46

Příklad jednoduchého MDB 47

Programovací model  MDB neimplementuje ani lokální ani vzdálené rozhraní  Implementuje javax.jms.MessageListener  Třída MDB je anotovaná  Musí mít public no-arg konstruktor  Dodatečná konfigurace možná v ejb-jar.xml nebo pomocí anotací 48

@javax.ejb.MessageDriven  Indikuje MDB  Důležité atributy  mappedName JNDI jméno destinace konfigurované na serveru jednoduché, avšak není přenositelné, jelikož jméno je poplatné konkrétnímu serveru přenositelný odkaz pomocí konfigurace v ejb-jar.xml  activationConfig Dodatečná konfigurace 0 nebo více vlastností 49

Dodatečná konfigurace 50

Konfigurační položky pro OpenMQ  destinationType TOPIC nebo QUEUE  destination název destinace  messageSelector JMS selektor  acknowledgeMode mod doručení  subscriptionDurability NON_DURABLE (default), DURABLE  subscriptionName identifikáto trvalého přihlášení k odběru 51

Životní cyklus MDB 52 Does Not Exist Method-Ready Class.newInstance() onMessage

Transakce v MDB  Jednodušší situace v případě transakcí řízených kontejnerem (CMT)  Pouze dva transakční atributy mají smysl REQUIRED – onMessage() bude běžet v transakci NOT_SUPPORTED – onMessage() nebude běžet v transakci 53

Zdroje  Burke, Bill – Monson-Haefel, Richard; Enterprise Java Beans 3.0; O'Reilly  Goncalves, Antonio; Beginning Java EE 6 Platform With GlassFish 3; APRESS 54