Java Message Service

Java Messaging Services se řadí do skupiny Message Oriented Middleware (dále MOM), jiným názvem také Enterprise Messaging System. MOM produkty se staly nedílnou součástí firemního software pro zajištění integrace aplikací. Umožňují různým byznys komponentám fungovat dohromady a tvořit tak ucelený, spolehlivý a pružný systém. Přestože se často jedná o naprosto odlišné komponenty, tak díky prostředníkovi (MOM) mohou tyto aplikace spolu komunikovat prostřednictvím zpráv. Jedním z možných řešení je právě JMS, které poskytuje kompletní API pro vývojáře a poskytuje tím možnost, jak psát programy v Javě, které dokáží vytvářet, posílat, přijímat a číst zprávy posílané mezi aplikacemi. Soubor rozhraní a přidružené logiky definuje jak v rámci JMS přistupuje klient k prostředkům MOM. Cílem JMS je poskytnout co nejvíce konceptů a rozhraní v takové podobě, aby se minimalizoval počet konceptů, které musí programátor Javy umět, aby mohl pracovat s MOM a zprávami. Programátor se díky JMS nemusí starat o technické pozadí za koloběhem zpráv.^[1][2][3]

JMS není emailové API, přestože funguje na podobném principu. Základem komunikace mezi klienty v rámci JMS jsou asynchronně posílané zprávy (požadavky, události, odpovědi atd.). Tyto zprávy jsou vytvářeny a užívány aplikacemi a obsahují informace, díky kterým tyto aplikace fungují, nastavují se a koordinují svou činnost v rámci celku. Emaily jsou posílány také mezi klienty, ale výsledným cílem je uživatel – člověk.^[1]

V oblasti MOM se běžně používají dva modely a to peer-to-peer (také point-to-point, dále P2P) a publish-subscribe (dále PS). Tyto dva modely se liší nejen počtem poskytovatelů a odběratelů zpráv, ale také způsobem jakým si odběratelé své zprávy vyzvedávají a jakým způsobem jsou zprávy publikovány. JMS dokáže pokrýt funkcionalitu obou modelů.^[3]

P2P je založen na frontách. Každá zpráva je přiřazena do určité fronty a klienti získávají z těchto front své zprávy. Není však přesně určeno kdy si klient má zprávu vyzvednout, třeba může nastat i případ, že si ji vůbec nevyzvedne. Tedy se v jedné frontě hromadí zprávy a mnoho uživatelů si je vyzvedává (one-to-many).^[3]

Oproti tomu PS model přiřazuje své zprávy určitému uzlu v kontextové hierarchii, ke kterému se odběratelé i publikovatelé přihlašují a odhlašují v průběhu doby trvání (many-to-many). Systém se stará o doručení zpráv od různých publikovatelů k mnoha různým odběratelům a systém také zajišťuje kdy a jak se zpráva odběrateli doručí.^[3]

Provider je entita, která implementuje MOM pro příslušný systém či aplikace. Provider může být implementován tak, jak ho definuje JMS (tedy Java implementace) a nebo je za providera považován adaptér na non-Java MOM, tedy lze zajistit i kompatibilitu Java aplikací s non-Java providerem.^[1]

Messages jsou hlavní podstatou MOM, tedy zprávy, kterými se zabývá provider a následně poskytovatel i konzument. Samotný JMS definuje soubor rozhraní pro zprávy, takže programátoři pracují s konzistentním API a mohou vytvářet a posílat zprávy nezávisle na druhu providera.^[1]

Domains(také Destinations) jsou buď point-to-point nebo publish-subscribe. Tyto domény byly vytvořeny jako reflexe dvou základních modelů MOM. JMS definuje různá rozhraní pro každou doménu a tím sice obtížně, ale přesto umožňuje propojení i různých modelů MOM najednou. Pro použití JMS není potřeba mít implementovány obě domény, stačí pouze jedna.^[1]

JMS neobsahuje:^[1]

• Load Balancing/Fault Tolerance – JMS API nedefinuje kooperaci mnoha klientů při poskytování jedné sjednocené služby.
• Error/Advisory Notification – JMS nedefinuje chybové či systémové zprávy pro klienty. Dle specifikací se klienti mohou těmto zprávám vyhnout a odstranit tak nebezpečí a omezení portability, které používání těchto zpráv přináší, protože většina MOM řeší tyto zprávy po svém.
• Administration – JMS nedefinuje API pro správu messaging produktů, zajišťuje pouze komunikaci.
• Security – Není specifikováno API pro zajištění bezpečnosti a integrity zpráv. JMS nechává bezpečnost na Providerovi a to jak distribuci klíčů klientům, tak i specifikaci digitálních podpisů.
• Wire Protocol – JMS ve specifikaci nedefinuje Wire Protocol(WP) a zároveň diktuje, aby posílání zpráv bylo možné i mezi implementacemi JMS od různých výrobců, což způsobuje problémy. WP je protokol, který se nachází mezi transportními protokoly (TCP/IP, UDP) a samotným JMS a zabývá se popisem formátu dat, která se posílají přes síť. Výběr a definici WP nechává JMS na implementátorovi.
• Message Type Repository – Není definováno repository pro ukládání definic typů zpráv a není definován ani jazyk pro vytváření definic typů.

JMS a Java API:^[1]

• JDBC – Klienti mohou použít JMS společně s JDBC v jedné transakci pro operace s databází, lze toho dosáhnout pomocí EJB, JTA.
• Java Bean – Java Beany mohou být použity s JMS pro posílání zpráv, ale JMS rozhraní nebyla vytvořena přímo pro tento způsob použití.
• Enterprise Java Bean --- JMS společně s JDBC a EJB tvoří silnou kombinaci pro vytváření enterprise services.
• Java Transaction – Klient JMS může použít JTA pro distribuované transakce. Nejedná se však o samotnou funkci JMS, ale o funkci transakčního prostředí ve kterém klient funguje.
• Java Transaction Service – Distribuované zpracování posílaných a přijímaných zpráv, které obsahují databázové updaty či další služby z oblasti JTS, může být explicitně naprogramováno, ale často je to řešeno automaticky pokud JMS klient běží v prostředí aplikačního serveru, tedy Enterprise Java Bean serveru, který je v souladu se specifikací.
• Java Naming and Directory Service – Klienti vyhledávají konfigurované JMS objekty pomocí JNDI. Přenecháním administrativních činností na JNDI se podporuje portabilita a tím jsou aplikace i lépe spravovatelné, protože tyto podpůrné činnosti (ohledně look up atd.) nejsou vloženy v kódu aplikací.

Typicky se JMS aplikace skládá z několika částí: JMS Clients, Non-JMS Clients, Messages, JMS Provider, Administered Objects.^[1]

Popis objektů JMS:^[1]

• ConnectionFactory je administrovaný objekt používaný k vytváření spojení (Connection).
• Connection představuje aktivní spojení s JMS providerem.
• Destination zapouzdřuje identitu cílového určení zprávy.
• Session je jednovláknový kontext pro posílání a přijímání zpráv.
• MessageProducer označuje objekt, který byl vytvořený Session a je používán pro posílání zpráva na cílovou Destination.
• MessageConsumer bývá vytvořen příkazem na Session a je používán pro přijímání zpráv na cílové Destination.

Souběžný přístup k objektům je v rámci JMS podporován pouze pro Destination, ConnectionFactory a Connection, tedy pro ty objekty, které přirozeně musí obsluhovat mnoho přístupů současně. Ostatní objekty jsou navrženy pro použití jen jedním logickým vláknem v určený čas. V případě Session je toto omezení uplatněno hlavně proto, že je velmi těžké implementovat mnohovláknové transakce a přineslo by to více škody než užitku. Pro složitější aplikace, které potřebují tuto funkcionalitu, je možné použít více Session najednou.^[1]

Prostředkem komunikace v messaging systémech jsou samozřejmě zprávy a v mnoha messaging systémech se forma i obsah zpráv dost liší. JMS poskytuje způsoby jak jednotně přistupovat ke zprávám a tedy jakou mají mít formu a druhy obsahu. Zpráva v JMS se skládá ze tří částí:^[1]

• Message header je používán pro identifikaci zprávy, například se tak určuje odběratel zprávy.
• Properties jsou místem pro různá aplikační, poskytovatelské a nepovinná nastavení.
• Body je část, která je tou samotnou zprávou. Je více typů zpráv a kromě dalších podporovaných se jedná především o TextMessages a ObjectMessages.

Takto se označují zprávy, které obsahují jednoduchý String a předpokládá se pouze posílání textu. Téměř ideální pro posílání zpráv pomocí XML, což je v podstatě pouhý text.^[3]

Používá se typ objektu TextMessage a s pomocí Session se vytvoří skrze createMessage(). Na vytvořené zprávě pak stačí zavolat metodu setText() do které se předá příslušný String. Dále už je zpráva hotova a může být předána messaging systému.^[3]

Tyto zprávy slouží k posílání entit typu Object, ale pouze serializovatelných. JMS umožňuje posílat i Collection objekt (např. List, Set), tedy soubor více serializovatelných objektů v jedné zprávě.^[3]

Používá se pro to typ objektu ObjectMessage a na Session je třeba zavolat metodu createObjectMessage(). Před odesláním je už jen třeba pomocí metody setObject(), zavolané na vytvořené ObjectMessage zprávě, nastavit požadovaný objekt k odeslání. Následně lze zprávu předat messaging systému.^[3]

Podstatou komunikace v MOM je asynchronní zpracování a posílání dat či informací mezi různými komponentami ve formě zpráv. Nejde ale pouze o textové řetězce, jak by napovídal název zpráva, ale lze posílat i celé objekty různých typů a také i kolekce objektů.

Příkladem použití asynchronních zpráv je komunikace mezi aplikacemi, sloužící k vytváření návrhů smluv. Tedy pracovník vytvoří smlouvu, připraví podklady a odešle ji ke schválení (tedy je publikovatelem – publisher). Technologicky se odešle v systému objekt Smlouva s určitými parametry ve zprávě typu ObjectMessage. Zde přichází ke slovu JMS a dle použitého modelu se Provider postará o doručení, publikování atd. O několik dní později, na jiném pracovišti, klidně i v jiném státě, si pracovník odpovědný za schvalování smluv příslušný návrh vyzvedne (jako odběratel – subscriber). Po schválení se ještě může nastavit jako další odběratel příslušný nadřízený kontroly kvality práce. Výsledkem je, že se zpráva (Smlouva) dostane na místo určení a i kdyby se původní místo odeslání odpojilo od sítě či internetu, tak stále, pokud bude provider v pořádku fungovat, je ta zpráva k dispozici.

• Java Message Service, java.sun.com, Oficiální stránky. (anglicky)