Java Message Service

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 můžou 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.

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)