Apa itu Java Message Service

1. Apa itu Messaging

Messaging yang dimaksud di sini sederhananya adalah cara bagaimana satu aplikasi berkomunikasi dengan aplikasi yang lainnya dimana antar keduanya terpisah ( Sistem terdistribusi ).

Contoh :

• Misal 1 aplikasi di toko cabang ( toko cabang surabaya ) ingin berkomunikasi dengan aplikasi di toko pusat ( toko cabang jombang ) untuk untuk meminta daftar stok barang atau mengirim order dari cabang ke aplikasi pusat.
• Atau pada ATM dimana ATM di banyak daerah ingin mengakses atau mendapat informasi saldo dari satu rekening dari sistem pusat.

2. Message Oriented Middleware ( MOM )

Message Oriented Middleware itu software yang menjadi jembatan antar aplikasi untuk berkirim pesan a.k.a berkomunikasi.

Deskripsi mudahnya :

Aplikasi di toko cabang surabaya ingin mengirim data pesanan dari pelanggan di toko pusat Jombang. Aplikasi di toko cabang surabaya itu akan mengirim pesan ke software MOM, berikutnya MOM ini yang akan memberitau aplikasi toko pusat di Jombang.

Kenapa harus menggunakan MOM ? Kenapa tidak langsung dari aplikasi ke aplikasi ?

Kenapa :

* Pesan dijamin sampai
Pesan yang dikirim dari aplikasi cabang dijamin akan diterima oleh aplikasi tujuan meski pada waktu itu aplikasi di pusat sedang off alias tidak jalan. MOM akan segera mengirimkan pesannya ke pusat ketika aplikasi pusat dijalankan.

* Asynchronous

Ini maksudnya adalah aplikasi di toko cabang surabaya tidak perlu sama-sama jalan dalam waktu yang sama dengan aplikasi di toko pusat jombang.

* Mendukung Transaksi

MOM juga menyediakan mode transacted dimana masing-masing aplikasi yang menerima pesan dari MOM bisa menentukan apaka aplikasi ini valid. Jika valid tinggal di commit dan pesan akan dihapus dari MOM dan jika tidak valid tinggal di rollback kembali dan pesan akan dikirimka ulang. Ini sangat berguna ketika operasi pemrosesan di aplikasi client tiba-tiba gagal sehingga kita butuh pemrosesan ulang dan pesan dari MOM juga dikirim ulang.

* One time, in-order delivery

MOM memastikan bahwa tidak ada duplikasi pesan yang artinya pesan yang sama tidak akan dikirim dua kali ke client. Satu kali dan hanya satu kali kirim sesuai dengan urutan waktu pesan dikirim.

Sesuai urutan ? Apa pesan di MOM ada banyak ?

Tentu! pesan tidak bisa jadi tidak hanya satu tapi banyak sekali pesan yang masuk dalam 1 detik karena mungkin aplikasi toko cabang yang ingin berkomunikasi dengan pusat tidak hanya satu.

* Loosely coupled

Satu aplikasi tidak perlu tau detail implementasi dari aplikasi lain yang menerima pesan. 

Ini berbeda dengan metode RPC seperti CORBRA dan RMI dimana antar aplikasi yang ingin berkomunikasi harus mengetahui di aplikasi lain misal aplikasi toko pusat jombang untuk mengakses daftar stok barang metode apa yang harus di akses, ketika sudah tau metodenya/fungsinya maka aplikasi di toko cabang surabaya harus membuat metode yang mirip baik dari segi jumlah parameter dan nilai kembalian dalam aplikasi cabang. Jadi antar aplikasi sangat terikat sekali.

Berbeda dengan Message oriented dimana aplikasi cukup mengirim pesan ke MOM tidak perduli aplikasi yang menerima bentuk dan rupanya seperti apa.

3. Kalau gitu kenapa tidak pakai email ?

Email itu ditujukan untuk komunikasi antar manusia atau antar mesin ( Aplikasi ) dengan manusia. Tidak akan muda bagi mesin ( aplikasi ) untuk membaca maksud pesan yang sebenarnya ditujukan manusia.

Sedang Message Oriented itu ditujukan untuk komunikasi antar aplikasi dengan format pesan yang masing masing aplikasi mengerti format pesannya. Itu inti utamanya sebenarnya meski banyak lagi alasannya.

4. Java Message Service

JMS muncul karena metode sebelumnya RMI/CORBRA dan sebangsanya terlalu tightly-coupled dan synchronous. Lalu datanglah era Middleware ( MOM ), tapi karena produk middleware tidak hanya satu sehinggan tidak ada standarisasi yang umum gitu. Jadi kalau kita memakai sati provider MOM maka code kita akan sangat terikat dengan code native yang spesifik dengan MOM tersebut sehingga akan gagal berantakan kalau MOM kita ganti dengan produk lain, untuk itu lahirlah JMS.

Ingat! JMS itu hanya spesifikasi bukan implementasi. Jadi JMS mendefinisikan cara nya gimana untuk melakukan komunikasi. Jadi dibutuhkan semacam implementor dan inilah yang diistilahkan dengan JMS Provider/Provide/Broker/MOM.

Contoh JMS Provider :

* ActiveMQ dari apache ( ini yang ane pakai )

* IBM MQSeries

* Fiorano MQ

* Sun Java Message Queue

Ini gambarnya modelnya :

Bisa dilihat diatas bahwa JMS Client ( aplikasi di cabang di berbagai daerah ) berkomunikasi dengan MOM ( JMS Provider/Messaging Server ) melalui JMS API tidak peduli provider nya dari produk mana apa itu dari ActiveMQ, Fiorano MQ atau IBM MQSeries.

5. Kapan harus menggunakan JMS atau MOM secara umum ?

Jika :

* Aplikasi terdistribusi di berbagai tempat yang tidak perlu tau bagaimana bentuk dan rupa aplikasi di tempat lain ( Loosely coupled )

* Ketika kita ingin aplikasi satu mengirim pesan tanpa perlu syarat bahwa yang menerima harus hidup ( asynchronous ).

* Jika ingin agar aplikasi kita bisa tetap jalan walau pesan yang kita kirimkan ke aplikasi client yang lain tidak langsung dibalas, jadi tidak perlu langsung dapat balasan tapi aplikasi tetap bisa jalan tanpa crash.

6. Element JMS

Element yang menyusun JMS :

* JMS Provider/Broker/Messaging Server/MOM

Seperti dijelaskan diatas, ini contohnya ActiveMQ dan teman-temannya.

* JMS Client

Aplikasi client yang berkomunikasi dengan JMS Provider menggunakan JMS API, jadi ini pasti aplikasi yang dibangun dengan Java.

* Message

Pesan yang dikirim oleh JMS Client ke JMS Provider.

* Administered Object

Preconfigured-object yang dibuat oleh admin dari JMS Provider untuk digunakan oleh JMS Client.

Contoh :

• Connection
• Destination

Ada juga istilah Native Client yang maksudnya adalah aplikasi ini berkomunikasi dengan JMS Provider menggunakan API Native dari JMS Provider jadi tidak menggunakan JMS API jadi aplikasi tersebut bisa jadi dibangun dengan selain Java.

7. Messaging Domain

* Point-to-Point Messaging

• PTP berkisar antara 3 istilah ini Sender/Producer, Message Queue, Receiver/Consumer. Sender mengirim pesan dengan ke JMS Provider, setelah itu JMS Provider menyimpan pesan tersebut dalam Message Queue, ketika ada Receiver yang sedang terhubung ke JMS Provider, maka JMS Provider akan mengirimkan pesan itu ke Receiver lalu setelah diterima pesan tersebut dihapus dari Message Queue oleh JMS Provider.
• Pesan yang dikirim melalui PTP hanya boleh di terima oleh satu Receiver, kok bisa? itu karena ketika pesan sudah dikirim ke satu client maka akan langsung dihapus jadi client yang lain tidak akan bisa menerima lagi... lha wong sudah dihapus kok.
• Sender mengirim pesan dengan subjek queue tertentu dan Receiver dapat menerimanya dengan terhubung ke JMS Provider dengan subjek queue tersebut. Subjek Queue ini yang dimaksud dengan preconfigured-object destination diatas. Artinya admin JMS Provider membuat satu anam queue tertentu dimana itu yang akan digunakan sebagai jembatan client yang satu dengan yang lain berkomunikasi.
• Multiple sender bisa mengirim dengan subjek queue yang sama tapi tetap hanya satu receiver yang akan menerima satu pesan.

* Publish-Subsribe Messaging

• Publish / Subscribe berkisar antara 3 istilah yaitu Publisher, Topic dan Subscriber. Subscriber ( Consumer ) mendaftarkan dirinya untuk sebuah Topic dan ketika ada satu atau lebih Publisher yang mengirim pesan untuk Topic tersebut maka JMS Provider akan mengirimkan pesan tersebut ke semua subscriber yang telah mendaftar. Satu pesan bisa di pakai atau dikirim ke banyak subscriber.
• Timing-Dependency. Untuk model Publish/Subscribe terdapat timing-dependency, artinya seperti ini Jika publisher mengirim pesan terlebih dahulu kemudian subscriber baru dijalankan, kita mungkin berharap bahwa pesan tersebut akan dikirim oleh JMS Provider seperti dalam model PTP, tapi kenyataan tidak seperti itu. Agar subscriber menerima pesan maka dia harus dijalankan terlebih dahulu sebelum publisher. Ketika publisher running terlebih dahulu dan subscriber belum running maka JMS Provider menganggap pesan pada topic tersebut tidak ada subscribernya dan logika itu memang masuk akal karena waktu publisher mengirim pesan memang belum ada subscriber yang mendaftar karena belum jalan sehingga pesna akan dihapus oleh JMS Provider karena tidak ada yang subscribe. Coba bandingkan dengan subscriber lebih dahulu running, maka JMS Provider akan menganggap ada satu/lebih subscriber yang menunggu ada pesan masuk untuk Topic tersebut sehingga ketika Publisher mengirim pesan untuk Topic tersebut maka JMS Provider tau kalau ada beberapa subscriber yang dari tadi sudah menunggu pesan untuk Topic tersebut. Lah kalau gitu melanggar aturan asynchronous dong!! Tunggu sebentar lah, baca dibawah.
• Jika mengunakan Durable-Subscriber maka ini berjalan seperti mode PTP yang artinya ketika Publisher mengirim pesan dan durable-subscriber belum running, dan ketika dia running JMS Provider akan mengirim pesan yang dikirim oleh Publisher tadi. Tapi ingat!! Durable-Subscriber harus didaftarkan lebih dahulu sebelum Publisher tadi mengirim pesan.

Note :

* Baik nama queue, nama topic atau disebut destination bisa dibuat oleh admin JMS Provider itu atau langsung dibuat dari aplikasi client tergantung pengatura di masing-masing JMS Provider.