KOMUNIKASI BERORIENTASI PESAN

Panggilan prosedur jarak jauh dan pemanggilan objek jarak jauh berkontribusi pada menyembunyikan
komunikasi dalam sistem terdistribusi, yaitu, mereka meningkatkan transparansi akses.

Sayangnya, tidak ada mekanisme yang selalu sesuai. Secara khusus, ketika tidak dapat diasumsikan bahwa
pihak penerima mengeksekusi pada saat permintaan dikeluarkan, layanan komunikasi alternatif
diperlukan. Demikian juga, sifat sinkron inheren RPC, di mana klien diblokir sampai permintaannya
diproses, kadang-kadang perlu diganti dengan sesuatu yang lain.

Itu sesuatu yang lain adalah olahpesan. Pada bagian ini kami berkonsentrasi pada komunikasi yang
berorientasi pesan dalam sistem terdistribusi dengan terlebih dahulu melihat lebih dekat apa sebenarnya
perilaku sinkron dan apa implikasinya. Kemudian, kami membahas sistem pengiriman pesan yang
menganggap bahwa para pihak mengeksekusi pada saat komunikasi.

Akhirnya, kami akan memeriksa sistem antrian pesan yang memungkinkan proses untuk bertukar
informasi, bahkan jika pihak lain tidak melaksanakan pada saat komunikasi dimulai.

4.3.1 Komunikasi Transien Berorientasi Pesan

Banyak sistem dan aplikasi terdistribusi dibangun langsung di atas model berorientasi pesan sederhana
yang ditawarkan oleh lapisan transport. Untuk lebih memahami dan menghargai sistem yang berorientasi
pada pesan sebagai bagian dari solusi middleware, pertama-tama kita membahas pengiriman pesan
melalui soket tingkat transportasi.

Soket Berkeley

Perhatian khusus telah diberikan pada standardisasi antarmuka lapisan transport untuk memungkinkan
programmer menggunakan seluruh rangkaian protokol (pengiriman pesan) melalui serangkaian primitif
sederhana. Juga, antarmuka standar memudahkan port aplikasi ke mesin yang berbeda.

Sebagai contoh, kita secara singkat membahas antarmuka soket seperti yang diperkenalkan pada tahun
1970 di Berkeley UNIX. Antarmuka penting lainnya adalah XTI, yang merupakan singkatan dari X10pen
Transport Interface, yang sebelumnya disebut Transport Layer Interface (TLI), dan dikembangkan oleh
AT&T. Soket dan XTI sangat mirip dalam model pemrograman jaringan mereka, tetapi berbeda dalam set
primitif mereka.

Secara konseptual, soket adalah titik akhir komunikasi tempat aplikasi dapat menulis data yang akan
dikirim melalui jaringan yang mendasarinya, dan dari mana data yang masuk dapat dibaca. Soket
membentuk abstraksi atas titik akhir komunikasi aktual yang digunakan oleh sistem operasi lokal untuk
transportasi tertentu

protokol. Dalam teks berikut, kami berkonsentrasi pada soket primitif untuk TCP, yang ditunjukkan pada
Gambar. 4-14.

Server umumnya mengeksekusi empat primitif pertama, biasanya dalam urutan yang diberikan. Saat
memanggil soket primitif, pemanggil membuat titik akhir komunikasi baru untuk protokol transport
tertentu. Secara internal, membuat titik akhir komunikasi berarti bahwa sistem operasi lokal
mencadangkan sumber daya untuk mengakomodasi pengiriman dan penerimaan pesan untuk protokol
yang ditentukan.
Bind primitive mengaitkan alamat lokal dengan soket yang baru dibuat. Misalnya, server harus mengikat
alamat IP mesinnya bersama-sama dengan nomor port (mungkin terkenal) ke soket. Binding memberi
tahu sistem operasi bahwa server hanya ingin menerima pesan pada alamat dan port yang ditentukan.

Gambar 4-14. Soket primitif untuk TCP IP.

Primitif mendengarkan hanya disebut dalam kasus komunikasi berorientasi koneksi. Ini adalah panggilan
nonblocking yang memungkinkan sistem operasi lokal mencadangkan cukup buffer untuk jumlah koneksi
maksimum yang ditentukan yang bersedia diterima oleh penelepon.

Panggilan untuk menerima memblokir penelepon hingga permintaan koneksi tiba. Ketika permintaan
datang, sistem operasi lokal membuat soket baru dengan properti yang sama dengan yang asli, dan
mengembalikannya ke pemanggil. Pendekatan ini akan memungkinkan server, misalnya, memotong
proses yang selanjutnya akan menangani komunikasi aktual melalui koneksi baru. Server, sementara itu,
dapat kembali dan menunggu permintaan koneksi lain pada soket asli.

Mari kita lihat sisi klien. Di sini juga, soket harus dibuat terlebih dahulu menggunakan primitif soket, tetapi
mengikat soket secara eksplisit ke alamat lokal tidak diperlukan, karena sistem operasi dapat secara
dinamis mengalokasikan port ketika koneksi diatur. Connect primitive mensyaratkan bahwa penelepon
menentukan alamat tingkat transportasi tempat permintaan koneksi akan dikirim. Klien diblokir sampai
koneksi berhasil diatur, setelah itu kedua belah pihak dapat mulai bertukar informasi melalui mengirim
dan menerima primitif. Akhirnya, menutup koneksi adalah simetris ketika menggunakan soket, dan dibuat
dengan meminta klien dan server memanggil primitive tutup. Pola umum yang diikuti oleh klien dan server
untuk komunikasi berorientasi koneksi menggunakan soket ditunjukkan pada Gambar. 4-15. Rincian
tentang pemrograman jaringan menggunakan soket dan antarmuka lain dalam lingkungan UNIX dapat
ditemukan di Stevens (1998).
Antarmuka Message-Passing (MPI)

Dengan munculnya multikomputer berkinerja tinggi, pengembang telah mencari primitif berorientasi
pesan yang akan memungkinkan mereka untuk dengan mudah menulis aplikasi yang sangat efisien. Ini
berarti bahwa primitif harus pada tingkat abstraksi yang nyaman (untuk memudahkan pengembangan
aplikasi), dan bahwa mereka

Gambar 4-15. Pola komunikasi yang berorientasi koneksi menggunakan soket.

karena dua alasan. Pertama, mereka berada pada tingkat abstraksi yang salah dengan hanya mendukung
pengiriman dan penerimaan sederhana. Kedua, soket telah dirancang untuk berkomunikasi di seluruh
jaringan menggunakan tumpukan protokol tujuan umum seperti TCPIIP. Mereka tidak dianggap cocok
untuk protokol eksklusif yang dikembangkan untuk jaringan interkoneksi berkecepatan tinggi, seperti
yang digunakan dalam cluster server berkinerja tinggi. Protokol-protokol itu membutuhkan antarmuka
yang dapat menangani fitur-fitur yang lebih canggih, seperti berbagai bentuk buffering dan sinkronisasi.

Hasilnya adalah bahwa sebagian besar jaringan interkoneksi dan multikomputer berkinerja tinggi
dikirimkan dengan perpustakaan komunikasi berpemilik. Perpustakaan-perpustakaan ini menawarkan
kekayaan komunikasi primitif tingkat tinggi dan umumnya efisien. Tentu saja, semua perpustakaan tidak
saling kompatibel, sehingga pengembang aplikasi sekarang memiliki masalah portabilitas.

Kebutuhan untuk menjadi perangkat keras dan platform independen pada akhirnya mengarah pada
definisi standar untuk pengiriman pesan, cukup disebut Message-Passing Interface atau MPI. MPI
dirancang untuk aplikasi paralel dan karenanya dirancang untuk komunikasi sementara. Itu membuat
penggunaan langsung dari jaringan yang mendasarinya. Juga, diasumsikan bahwa kegagalan serius seperti
crash proses atau partisi jaringan berakibat fatal dan tidak memerlukan pemulihan otomatis.

MPI mengasumsikan komunikasi terjadi dalam kelompok proses yang diketahui. Setiap grup diberi
pengenal. Setiap proses dalam grup juga diberi pengidentifikasi (lokal). Pasangan (grup / D, proses / D)
karena itu secara unik mengidentifikasi sumber atau tujuan pesan, dan digunakan sebagai ganti alamat
tingkat transportasi. Mungkin ada beberapa kelompok proses yang mungkin tumpang tindih yang terlibat
dalam perhitungan dan yang semuanya mengeksekusi pada saat yang sama.
Inti dari MPI adalah pesan primitif untuk mendukung komunikasi sementara, yang mana yang paling
intuitif dirangkum dalam Gambar 4-16.

Komunikasi asinkron sementara didukung oleh MPI_bsend primitif. Pengirim mengirimkan pesan untuk
transmisi, yang umumnya disalin pertama kali ke buffer lokal di sistem runtime MPI. Ketika pesan telah
disalin. pengirim berlanjut. Sistem runtime MPI lokal akan menghapus pesan dari buffer lokal dan
menangani pengiriman segera setelah penerima memanggil primitif terima.

Gambar 4-16. Beberapa primitif pelintas pesan yang paling intuitif dari MPI.

Ada juga operasi pengiriman pemblokiran, yang disebut MPLsend, yang semantiknya bergantung pada
implementasi. MPLsend primitif dapat memblokir penelepon hingga pesan yang ditentukan telah disalin
ke sistem runtime MPI di sisi pengirim, atau sampai penerima memulai operasi penerimaan. Komunikasi
sinkron dimana pengirim memblokir sampai permintaannya diterima untuk diproses lebih lanjut tersedia
melalui MPI ~ sendend send primitive. Akhirnya, bentuk komunikasi sinkron terkuat juga didukung: ketika
pengirim memanggil MPLsendrecv, ia mengirim permintaan ke penerima dan memblokir sampai pengirim
membalas. Pada dasarnya, primitif ini berhubungan dengan RPC normal.

Baik MPLsend dan MPLssend memiliki varian yang menghindari penyalinan pesan dari buffer pengguna
ke buffer internal ke sistem runtime MPI lokal. Varian ini sesuai dengan bentuk komunikasi asinkron.
Dengan MPI_isend, pengirim mengirimkan pointer ke pesan setelah itu sistem runtime MPI menangani
komunikasi. Pengirim segera melanjutkan. Untuk mencegah menimpa pesan sebelum komunikasi selesai,
MPI menawarkan primitif untuk memeriksa penyelesaiannya, atau bahkan memblokir jika diperlukan.
Seperti MPLsend, apakah pesan sebenarnya telah ditransfer ke penerima atau hanya disalin oleh sistem
runtime MPI lokal ke buffer internal dibiarkan tidak ditentukan.

Demikian juga, dengan MPLissend, pengirim juga hanya meneruskan pointer ke sistem runtime MPI.
Ketika sistem runtime menunjukkan telah memproses pesan, pengirim kemudian dijamin bahwa
penerima telah menerima pesan dan sekarang sedang mengerjakannya.

Operasi MPLrecv dipanggil untuk menerima pesan; itu memblokir penelepon sampai pesan tiba. Ada juga
varian asinkron, yang disebut MPLirecv, di mana penerima menunjukkan bahwa disiapkan untuk
menerima pesan. Penerima dapat memeriksa apakah suatu pesan benar-benar telah tiba, atau memblokir
sampai ada pesan.
Semantik primitif komunikasi MPI tidak selalu langsung, dan primitif yang berbeda kadang-kadang dapat
dipertukarkan tanpa mempengaruhi kebenaran suatu program. Alasan resmi mengapa begitu banyak
bentuk komunikasi yang berbeda didukung adalah karena memberikan para pelaksana sistem MPI
kemungkinan yang cukup untuk mengoptimalkan kinerja. Orang-orang yang sinis mungkin mengatakan
komite tidak dapat mengambil keputusan kolektifnya, jadi mereka melemparkan semuanya. MPI telah
dirancang untuk aplikasi paralel berkinerja tinggi, yang membuatnya lebih mudah untuk memahami
keberagamannya dalam berbagai komunikasi primitif.

Lebih lanjut tentang MPI dapat ditemukan di Gropp et aI. (l998b) Referensi lengkap di mana lebih dari 100
fungsi dalam MPI dijelaskan secara rinci, dapat ditemukan di Snir et al. (1998) dan Gropp et al. (l998a)

4.3.2 Komunikasi Persisten Berorientasi Pesan

Kami sekarang datang ke kelas penting dari layanan perangkat menengah berorientasi pesan, umumnya
dikenal sebagai sistem antrian pesan, atau hanya Pesan-Berorientasi Middleware (MOM). Sistem antrian
pesan memberikan dukungan luas untuk komunikasi asinkron yang persisten. Inti dari sistem ini adalah
bahwa mereka menawarkan kapasitas penyimpanan jangka menengah untuk pesan, tanpa mengharuskan
pengirim atau penerima untuk aktif selama pengiriman pesan. Perbedaan penting dengan soket Berkeley
dan MPI adalah bahwa sistem antrian pesan biasanya ditargetkan untuk mendukung transfer pesan yang
diizinkan untuk mengambil menit alih-alih detik atau milidetik. Kami pertama-tama menjelaskan
pendekatan umum untuk sistem pengiriman pesan, dan menyimpulkan bagian ini dengan
membandingkannya dengan sistem yang lebih tradisional, terutama sistem email Internet.

Model Antrian Pesan

Ide dasar di balik sistem antrian pesan adalah bahwa aplikasi berkomunikasi dengan memasukkan pesan
dalam antrian tertentu. Pesan-pesan ini diteruskan melalui serangkaian server komunikasi dan akhirnya
dikirim ke tujuan, bahkan jika itu turun ketika pesan itu dikirim. Dalam praktiknya, sebagian besar server
komunikasi terhubung langsung satu sama lain. Dengan kata lain, pesan umumnya ditransfer langsung ke
server tujuan. Pada prinsipnya, setiap aplikasi memiliki antrian pribadi sendiri yang dapat digunakan oleh
aplikasi lain untuk mengirim pesan. Antrian hanya dapat dibaca oleh aplikasi terkait, tetapi juga
memungkinkan bagi beberapa aplikasi untuk berbagi antrian tunggal.

Aspek penting dari sistem antrian pesan adalah bahwa pengirim pada umumnya hanya diberikan jaminan
bahwa pesannya pada akhirnya akan dimasukkan ke dalam antrian penerima. Tidak ada jaminan yang
diberikan tentang kapan, atau bahkan jika pesan itu benar-benar akan dibaca, yang sepenuhnya
ditentukan oleh perilaku penerima.

Semantik ini memungkinkan komunikasi secara longgar digabungkan dalam waktu. Dengan demikian
tidak perlu bagi penerima untuk mengeksekusi ketika pesan sedang dikirim ke antriannya. Demikian juga,
pengirim tidak perlu mengeksekusi pada saat pesannya diambil oleh penerima. Pengirim dan penerima
dapat mengeksekusi sepenuhnya secara independen satu sama lain. Faktanya, begitu sebuah pesan
disimpan dalam antrian, pesan itu akan tetap di sana sampai dihapus, terlepas dari apakah pengirim atau
penerimanya dieksekusi. Ini memberi kita empat kombinasi sehubungan dengan mode eksekusi pengirim
dan penerima, seperti yang ditunjukkan pada Gambar 4-17.
Gambar 4-17. Empat kombinasi untuk komunikasi yang digabungkan secara longgar menggunakan
antrian.

Pada Gbr.4-17 (a), pengirim dan penerima mengeksekusi selama keseluruhan transmisi pesan. Gambar.
4-17 (b), hanya pengirim yang mengeksekusi, sedangkan penerima pasif, yaitu, dalam keadaan di mana
pengiriman pesan tidak dimungkinkan. Meskipun demikian, pengirim tetap dapat mengirim pesan.
Kombinasi pengirim pasif dan penerima yang menjalankannya diperlihatkan pada Gambar 4-17 (c). Dalam
hal ini, penerima

dapat membaca pesan yang dikirim kepadanya, tetapi tidak perlu 'bahwa pengirimnya juga mengeksekusi.
Akhirnya, pada Gambar 4-17 (d), kita melihat situasi bahwa sistem menyimpan (dan mungkin
mentransmisikan) pesan bahkan ketika pengirim dan penerima pasif.

Pesan pada prinsipnya dapat berisi data apa pun. Satu-satunya aspek penting dari perspektif middleware
adalah bahwa pesan-pesan ditangani dengan benar. Dalam praktiknya, pengalamatan dilakukan dengan
memberikan nama unik antrian tujuan sistem. Dalam beberapa kasus, ukuran pesan mungkin terbatas,
meskipun ada kemungkinan juga bahwa sistem yang mendasarinya menangani pengelompokan dan
pemasangan pesan besar dengan cara yang benar-benar transparan untuk aplikasi. Efek dari pendekatan
ini adalah bahwa antarmuka dasar yang ditawarkan untuk aplikasi bisa sangat sederhana, seperti yang
ditunjukkan pada Gambar. 4-18.

Put primitive dipanggil oleh pengirim untuk mengirimkan pesan ke sistem yang mendasarinya yang akan
ditambahkan ke antrian yang ditentukan. Seperti yang kami jelaskan. ini adalah sebuah
Gambar 4-18. Antarmuka dasar ke antrian dalam sistem antrian pesan.

panggilan nonblocking. Get primitive adalah panggilan pemblokiran yang dengannya proses yang
diotorisasi dapat menghapus pesan tertunda terpanjang dalam antrian yang ditentukan. Proses diblokir
hanya jika antrian kosong. Variasi pada panggilan ini memungkinkan pencarian pesan tertentu dalam
antrian, misalnya menggunakan prioritas, atau pola yang cocok. Varian nonblocking diberikan oleh primitif
polling. Jika antrian kosong, atau jika pesan tertentu tidak dapat ditemukan, proses panggilan hanya
berlanjut.

Akhirnya, sebagian besar sistem antrian juga memungkinkan proses untuk menginstal handler sebagai
fungsi callback, yang secara otomatis dipanggil setiap kali pesan dimasukkan ke dalam antrian. Panggilan
balik juga dapat digunakan untuk secara otomatis memulai proses yang akan mengambil pesan dari
antrian jika tidak ada proses yang sedang dijalankan. Pendekatan ini sering dilaksanakan dengan
menggunakan daemon di sisi penerima yang terus-menerus memonitor antrian untuk pesan masuk dan
menangani sesuai.

Arsitektur Umum dari Sistem Antrian Pesan

Mari kita lihat lebih dekat seperti apa sistem antrian pesan secara umum. Salah satu batasan pertama
yang kami buat adalah bahwa pesan dapat dimasukkan hanya 'ke dalam antrian yang bersifat lokal bagi
pengirim, yaitu, antrian pada mesin yang sama, atau tidak lebih buruk daripada pada mesin di dekatnya
seperti pada LAN yang sama yang dapat dapat dicapai secara efisien melalui RPC. Antrian seperti itu
disebut antrian sumber. Demikian juga, pesan hanya dapat dibaca dari antrian lokal. Namun, pesan yang
dimasukkan ke dalam antrian akan berisi spesifikasi antrian tujuan yang harus ditransfer. Merupakan
tanggung jawab sistem antrian pesan untuk memberikan antrian kepada pengirim dan penerima dan
berhati-hati agar pesan ditransfer dari sumbernya ke antrian tujuan mereka.

Penting untuk menyadari bahwa kumpulan antrian didistribusikan di beberapa mesin. Akibatnya, untuk
sistem antrian pesan untuk mentransfer pesan, harus mempertahankan pemetaan antrian ke lokasi
jaringan. Dalam praktiknya, ini berarti bahwa ia harus memelihara database (mungkin didistribusikan)
nama antrian ke lokasi jaringan, seperti yang ditunjukkan pada Gambar. 4-19. Perhatikan bahwa
pemetaan semacam itu sepenuhnya analog dengan penggunaan Sistem Nama Domain (DNS) untuk email
masuk

Internet. Misalnya, saat mengirim pesan ke alamat surat logis steen@cs.vu.nl, sistem pengiriman akan
meminta DNS untuk menemukan alamat jaringan (mis., IP) dari server surat penerima untuk digunakan
untuk transfer pesan yang sebenarnya.
Gambar 4-19. Hubungan antara pengalamatan level antrian dan pengalamatan level jaringan.

Antrian dikelola oleh manajer antrian. Biasanya, manajer antrian berinteraksi langsung dengan aplikasi
yang mengirim atau menerima pesan. Namun, ada juga manajer antrian khusus yang beroperasi sebagai
router, atau relay: mereka meneruskan pesan masuk ke manajer antrian lainnya. Dengan cara ini, seorang
pengirim pesan

sistem secara bertahap dapat tumbuh menjadi jaringan overlay, tingkat aplikasi, lengkap, di atas jaringan
komputer yang ada. Pendekatan ini mirip dengan pembangunan MBone awal melalui Internet, di mana
proses pengguna biasa dikonfigurasikan sebagai router multicast. Ternyata, multicasting melalui jaringan
overlay masih penting karena akan kita bahas nanti dalam bab ini.

Relai bisa nyaman karena sejumlah alasan. Misalnya, dalam banyak sistem antrian pesan, tidak ada
layanan penamaan umum yang tersedia yang secara dinamis dapat mempertahankan pemetaan qneue-
to-Iocation. Sebaliknya, topologi jaringan antrian bersifat statis, dan setiap manajer antrian memerlukan
salinan pemetaan antrian-tolokasi. Tidak perlu dikatakan bahwa dalam sistem antrian skala besar.
Pendekatan ini dapat dengan mudah menyebabkan masalah manajemen jaringan.

Salah satu solusinya adalah dengan menggunakan beberapa router yang tahu tentang topologi jaringan.
Ketika pengirim A menempatkan pesan untuk tujuan B dalam antrian lokalnya, pesan itu pertama-tama
ditransfer ke router terdekat, katakan Rl, seperti yang ditunjukkan pada Gambar 4-20. Pada titik itu, router
tahu apa yang harus dilakukan dengan pesan dan meneruskannya ke arah B. Misalnya, Rl dapat berasal
dari nama B bahwa pesan tersebut harus diteruskan ke router R2. Dengan cara ini, hanya router yang
perlu diperbarui ketika antrian ditambahkan atau dihapus. sementara setiap manajer antrian lainnya
hanya tahu di mana router terdekat berada.

Relay dengan demikian secara umum dapat membantu membangun sistem antrian pesan yang dapat
diskalakan. Namun, seiring tumbuhnya jaringan antrian, jelaslah bahwa konfigurasi manual jaringan akan
dengan cepat menjadi tidak terkendali. Satu-satunya solusi adalah mengadopsi skema perutean dinamis
seperti yang dilakukan untuk jaringan komputer. Dalam hal itu, agak mengejutkan bahwa solusi semacam
itu belum terintegrasi ke dalam beberapa sistem antrian pesan populer.
Gambar 4 · 20. Organisasi umum sistem antrian pesan dengan router.

Alasan lain mengapa relay digunakan adalah memungkinkan relay untuk pemrosesan pesan sekunder.
Misalnya, pesan mungkin perlu dicatat karena alasan keamanan atau toleransi kesalahan. Suatu bentuk
relai khusus yang kita bahas di bagian berikutnya adalah yang bertindak sebagai gateway, mengubah
pesan menjadi format yang dapat dipahami oleh penerima.

Akhirnya, relay dapat digunakan untuk tujuan multicasting. Dalam hal itu, pesan masuk cukup dimasukkan
ke dalam setiap antrian kirim.

Pialang Pesan

Area aplikasi penting dari sistem antrian pesan adalah mengintegrasikan aplikasi yang ada dan yang baru
ke dalam sistem informasi terdistribusi yang koheren. Integrasi mengharuskan aplikasi dapat memahami
pesan yang mereka terima. Dalam praktiknya, ini mengharuskan pengirim untuk memiliki pesan keluar
dalam format yang sama dengan penerima.

Masalah dengan pendekatan ini adalah bahwa setiap kali aplikasi ditambahkan ke sistem yang
membutuhkan format pesan terpisah, setiap penerima potensial harus disesuaikan untuk menghasilkan
format itu.

Alternatifnya adalah menyetujui format pesan umum, seperti yang dilakukan dengan protokol jaringan
tradisional. Sayangnya, pendekatan ini umumnya tidak akan berfungsi untuk sistem antrian pesan.
Masalahnya adalah tingkat abstraksi di mana Gambar 4-21 ini. Organisasi umum pialang pesan dalam
sebuah pengirim pesan
sistem. Pialang pesan dapat sesederhana reformatter untuk pesan. Sebagai contoh, anggap pesan masuk
berisi tabel dari database, di mana catatan dipisahkan oleh pembatas akhir-oj-catatan khusus dan bidang
dalam catatan memiliki panjang tetap yang diketahui. Jika aplikasi tujuan mengharapkan pembatas yang
berbeda antara catatan, dan juga mengharapkan bahwa bidang memiliki panjang variabel, broker pesan
dapat digunakan untuk mengonversi pesan ke format yang diharapkan oleh tujuan. Dalam pengaturan
yang lebih lanjut, broker pesan dapat bertindak sebagai gateway tingkat aplikasi, seperti yang menangani
konversi antara dua aplikasi database yang berbeda. Dalam kasus seperti itu, seringkali tidak dapat dijamin
bahwa semua sistem informasi beroperasi. Format pesan umum hanya masuk akal jika kumpulan proses
yang menggunakan format itu memang memiliki cukup banyak kesamaan. Jika kumpulan aplikasi yang
membentuk sistem informasi terdistribusi sangat beragam (yang sering terjadi), maka format umum
terbaik mungkin tidak lebih dari urutan byte.

Meskipun beberapa format pesan umum untuk domain aplikasi tertentu telah ditentukan, pendekatan
umumnya adalah belajar hidup dengan format yang berbeda, dan mencoba menyediakan cara untuk
membuat konversi sesederhana mungkin. Dalam sistem antrian pesan, konversi ditangani oleh node
khusus dalam jaringan antrian, yang dikenal sebagai perantara pesan. Pialang pesan bertindak sebagai
gateway tingkat aplikasi dalam sistem antrian pesan. Tujuan utamanya adalah untuk mengubah pesan
yang masuk sehingga mereka dapat dipahami oleh aplikasi tujuan. Perhatikan bahwa untuk sistem antrian
pesan, broker pesan hanyalah aplikasi lain. seperti yang ditunjukkan pada Gambar. 4-21. Dengan kata lain,
broker pesan biasanya tidak dianggap sebagai bagian integral dari sistem antrian.

Gambar 4-21. Organisasi umum pialang pesan dalam sistem antrian pesan.

Pialang pesan dapat sesederhana reformatter untuk pesan. Sebagai contoh, anggap pesan masuk berisi
tabel dari database, di mana catatan dipisahkan oleh pembatas akhir-oj-catatan khusus dan bidang dalam
catatan memiliki panjang tetap yang diketahui. Jika aplikasi tujuan mengharapkan pembatas yang
berbeda antara catatan, dan juga mengharapkan bahwa bidang memiliki panjang variabel, broker pesan
dapat digunakan untuk mengonversi pesan ke format yang diharapkan oleh tujuan.

Dalam pengaturan yang lebih lanjut, broker pesan dapat bertindak sebagai gateway tingkat aplikasi,
seperti yang menangani konversi antara dua aplikasi database yang berbeda. Dalam kasus seperti itu,
seringkali tidak dapat dijamin bahwa semua sistem informasi beroperasi. Format pesan umum hanya
masuk akal jika kumpulan proses yang menggunakan format itu memang memiliki cukup banyak
kesamaan. Jika kumpulan aplikasi yang membentuk sistem informasi terdistribusi sangat beragam (yang
sering terjadi), maka format umum terbaik mungkin tidak lebih dari urutan byte. Meskipun beberapa
format pesan umum untuk domain aplikasi tertentu telah ditentukan, pendekatan umumnya adalah
belajar hidup dengan format yang berbeda, dan mencoba menyediakan cara untuk membuat konversi
sesederhana mungkin. Dalam sistem antrian pesan, konversi ditangani oleh node khusus dalam jaringan
antrian, yang dikenal sebagai perantara pesan. Pialang pesan bertindak sebagai gateway tingkat aplikasi
dalam sistem antrian pesan. Tujuan utamanya adalah untuk mengubah pesan yang masuk sehingga
mereka dapat dipahami oleh aplikasi tujuan. Perhatikan bahwa untuk sistem antrian pesan, broker pesan
hanyalah aplikasi lain. sebagai

ditunjukkan pada Gambar. 4-21. Dengan kata lain, broker pesan biasanya tidak dianggap sebagai bagian
integral dari sistem antrian. yang terkandung dalam pesan masuk sebenarnya bisa ditransformasikan
menjadi sesuatu yang sesuai untuk pesan keluar.

Namun, yang lebih umum adalah penggunaan broker pesan untuk integrasi aplikasi perusahaan tingkat
lanjut (EAI) seperti yang kita bahas dalam Bab. 1. Dalam hal ini, alih-alih (hanya) mengonversi pesan,
broker bertanggung jawab untuk mencocokkan aplikasi berdasarkan pesan yang dipertukarkan. Dalam
model seperti itu, yang disebut publish / subscribe, aplikasi mengirim pesan dalam bentuk publikasi.
Secara khusus, mereka dapat mempublikasikan pesan tentang topik X, yang kemudian dikirim ke broker.
Aplikasi yang telah menyatakan minatnya pada pesan pada topik X, yaitu, yang telah berlangganan pesan
tersebut, kemudian akan menerima pesan ini dari broker. Bentuk-bentuk mediasi yang lebih maju juga
dimungkinkan, tetapi kami akan menunda diskusi lebih lanjut sampai Bab. 13.

Di jantung pialang pesan terletak repositori aturan dan program yang dapat mengubah pesan tipe TI ke
salah satu dari tipe T2. Masalahnya adalah mendefinisikan aturan dan mengembangkan program.
Sebagian besar produk broker pesan dilengkapi dengan alat pengembangan yang canggih, tetapi intinya
masih bahwa repositori perlu diisi oleh para ahli. Di sini kita melihat contoh sempurna di mana produk
komersial sering dikatakan menyesatkan untuk memberikan "kecerdasan," di mana, pada kenyataannya,
satu-satunya kecerdasan dapat ditemukan di kepala para ahli itu.

Catatan tentang Sistem Antrian Pesan

Mempertimbangkan apa yang telah kami katakan tentang sistem antrian pesan, akan tampak bahwa
mereka telah lama ada dalam bentuk implementasi untuk layanan email. Sistem email umumnya
diterapkan melalui kumpulan server email yang menyimpan dan meneruskan pesan atas nama pengguna
di host yang terhubung langsung ke server. Rute umumnya ditinggalkan, karena sistem e-mail dapat
langsung menggunakan layanan transportasi yang mendasarinya.

Misalnya, dalam protokol surat untuk Internet, SMTP (Postel, 1982), pesan ditransfer dengan mengatur
koneksi TCP langsung ke server surat tujuan. Apa yang membuat sistem e-mail istimewa dibandingkan
dengan sistem antrian pesan adalah bahwa mereka terutama ditujukan untuk memberikan dukungan
langsung bagi pengguna akhir. Ini menjelaskan, misalnya, mengapa sejumlah aplikasi groupware
didasarkan langsung pada sistem email (Khoshafian dan Buckiewicz 1995). Selain itu, sistem email
mungkin memiliki persyaratan yang sangat spesifik seperti pemfilteran pesan otomatis, dukungan untuk
database perpesanan tingkat lanjut (mis., Untuk dengan mudah mengambil pesan yang disimpan
sebelumnya), dan sebagainya.

Sistem antrian pesan umum tidak ditujukan untuk mendukung hanya pengguna akhir. Masalah penting
adalah bahwa mereka diatur untuk memungkinkan komunikasi yang berkelanjutan antara proses,
terlepas dari apakah suatu proses menjalankan aplikasi pengguna. menangani akses ke database,
melakukan perhitungan, dan sebagainya. Pendekatan ini mengarah pada serangkaian persyaratan yang
berbeda untuk sistem antrian pesan daripada sistem email murni. Sebagai contoh, sistem email umumnya
tidak perlu memberikan pengiriman pesan yang terjamin, prioritas pesan, fasilitas logging, multicasting
yang efisien, penyeimbangan muatan, toleransi kesalahan, dan sebagainya untuk penggunaan umum.

Oleh karena itu, sistem antrian pesan untuk keperluan umum memiliki beragam aplikasi, termasuk email,
workflow, groupware, dan pemrosesan batch. Namun, seperti yang telah kami nyatakan sebelumnya,
area aplikasi yang paling penting adalah integrasi kumpulan (mungkin tersebar luas) database dan aplikasi
ke dalam sistem informasi gabungan (Hohpe dan Woolf, 2004). Misalnya, memperluas beberapa
permintaan basis data mungkin perlu dipecah menjadi beberapa subquery yang diteruskan ke basis data
tersendiri. Sistem antrian pesan membantu dengan menyediakan sarana dasar untuk mengemas setiap
subquery ke dalam pesan dan mengarahkannya ke database yang sesuai. Fasilitas komunikasi lain yang
telah kita bahas dalam bab ini jauh kurang tepat.

4.3.3 Contoh: Sistem Antrian Pesan WebSphere IBM

Untuk membantu memahami bagaimana sistem antrian pesan bekerja dalam praktiknya, mari kita lihat
satu sistem khusus, yaitu sistem antrian pesan yang merupakan bagian dari produk WebSphere IBM.
Dahulu dikenal sebagai MQSeries, sekarang disebut sebagai WebSphere MQ. Ada banyak dokumentasi di
Web Sphere MQ, dan berikut ini kami hanya dapat menggunakan prinsip-prinsip dasar. Banyak detail
arsitektur mengenai jaringan antrian pesan dapat ditemukan di IBM (2005b, 2005d). Memprogram
jaringan antrian pesan bukanlah sesuatu yang dapat dipelajari pada hari Minggu sore, dan panduan
pemrograman MQ (IBM, 2005a) adalah contoh yang baik yang menunjukkan bahwa beralih dari prinsip
ke praktik mungkin memerlukan upaya yang substansial.

Gambaran

Arsitektur dasar jaringan antrian MQ cukup mudah, dan ditunjukkan pada Gambar 4-22. Semua antrian
dikelola oleh manajer antrian. Manajer antrian bertanggung jawab untuk menghapus pesan dari antrian
kirimnya, dan meneruskannya ke manajer antrian lainnya. Demikian juga, manajer antrian bertanggung
jawab untuk menangani pesan masuk dengan mengambilnya dari jaringan yang mendasarinya dan
kemudian menyimpan setiap pesan dalam antrian input yang sesuai. Untuk memberi kesan arti pesan:
pesan memiliki ukuran default maksimum 4 MB, tetapi ini dapat ditingkatkan hingga 100 MB. Antrian
biasanya dibatasi hingga 2 GB data, tetapi tergantung pada sistem operasi yang mendasarinya, maksimum
ini dapat dengan mudah diatur lebih tinggi.

Manajer antrian terhubung secara berpasangan melalui saluran pesan, yang merupakan abstraksi dari
koneksi level transportasi. Saluran pesan adalah koneksi searah, dapat diandalkan antara pengirim dan
manajer antrian penerima, di mana pesan antrian diangkut. Misalnya, saluran pesan berbasis Internet
diimplementasikan sebagai koneksi TCP. Masing-masing dari dua ujung saluran pesan dikelola oleh agen
saluran pesan (MCA). Pengiriman: MCA pada dasarnya tidak melakukan apa-apa selain memeriksa antrian
pengiriman untuk pesan, membungkusnya ke dalam paket tingkat transportasi, dan mengirimkannya
sepanjang koneksi ke MCA penerima terkait. Demikian juga, tugas dasar dari MCA penerima adalah
mendengarkan paket yang masuk, membuka bungkusnya, dan kemudian menyimpan pesan yang belum
dibuka ke dalam antrian yang sesuai.

Gambar 4-22. Organisasi umum sistem antrian pesan IBM.

Manajer antrian dapat dihubungkan ke proses yang sama dengan aplikasi yang digunakannya mengelola
antrian. Dalam hal ini, antrian disembunyikan dari aplikasi di belakang antarmuka standar, tetapi secara
efektif dapat dimanipulasi secara langsung oleh aplikasi. Organisasi alternatif adalah organisasi di mana
manajer antrian dan aplikasi dijalankan pada mesin yang berbeda. Dalam hal ini, aplikasi ditawarkan
antarmuka yang sama seperti ketika manajer antrian ditempatkan di mesin yang sama. Namun,
antarmuka diimplementasikan sebagai roxy yang berkomunikasi dengan manajer antrian menggunakan
komunikasi sinkron tradisional berbasis RPC. Dengan cara ini, MQ pada dasarnya mempertahankan model
yang hanya dapat diakses oleh antrian lokal untuk suatu aplikasi.

Saluran

Komponen penting dari MQ dibentuk oleh saluran pesan. Setiap saluran pesan memiliki tepat satu antrian
pengiriman terkait yang darinya ia mengambil pesan yang harus ditransfer ke ujung lainnya. Transfer di
sepanjang saluran hanya dapat dilakukan jika MCA pengiriman dan penerimaannya beroperasi dan
berjalan. Terlepas dari memulai kedua MCA secara manual, ada beberapa cara alternatif untuk memulai
saluran, beberapa di antaranya akan kita bahas selanjutnya.

Salah satu alternatif adalah memiliki aplikasi yang secara langsung memulai akhir saluran dengan
mengaktifkan MCA pengiriman atau penerimaan. Namun, dari sudut pandang transparansi, ini bukan
alternatif yang sangat menarik. Pendekatan yang lebih baik untuk memulai MeA pengiriman adalah
mengkonfigurasi antrian pengiriman saluran untuk memicu pemicu ketika sebuah pesan pertama kali
dimasukkan ke dalam antrian. Pemicu itu dikaitkan dengan penangan untuk memulai pengiriman MCA
sehingga dapat menghapus pesan dari antrian pengiriman.

Alternatif lain adalah memulai MCA melalui jaringan. Secara khusus, jika satu sisi saluran sudah aktif, ia
dapat mengirim pesan kontrol yang meminta agar MCA lainnya dimulai. Pesan kontrol seperti itu dikirim
ke daemon mendengarkan alamat terkenal di mesin yang sama dengan di mana MCA lain akan dimulai.

Saluran dihentikan secara otomatis setelah waktu yang ditentukan berakhir, dan tidak ada lagi pesan yang
dikirim ke antrian kirim.

Setiap MCA memiliki satu set atribut terkait yang menentukan perilaku keseluruhan saluran. Beberapa
atribut tercantum pada Gambar 4-23. Nilai atribut MCA pengiriman dan penerimaan harus kompatibel
dan mungkin dinegosiasikan terlebih dahulu sebelum saluran dapat diatur. Sebagai contoh, kedua MCA
jelas harus mendukung protokol transportasi yang sama. Contoh atribut yang tidak dapat dinegosiasikan
adalah apakah atau tidak pesan akan dikirim dalam urutan yang sama seperti mereka dimasukkan ke
dalam antrian pengiriman. Jika satu MCA menginginkan pengiriman FIFO, yang lain harus mematuhi.
Contoh nilai atribut yang dapat dinegosiasikan adalah panjang pesan maksimum, yang hanya akan dipilih
sebagai nilai minimum yang ditentukan oleh salah satu MCA.

Gambar 4-23. Beberapa atribut yang terkait dengan agen saluran pesan.

Transfer Pesan

Untuk mentransfer pesan dari satu manajer antrian ke manajer antrian yang lain (mungkin jauh), setiap
pesan harus membawa alamat tujuan, di mana tajuk transmisi digunakan. Alamat dalam MQ terdiri dari
dua bagian. Bagian pertama terdiri dari nama manajer antrian di mana pesan akan dikirimkan. Bagian
kedua adalah nama antrian tujuan resoring di bawah manajer yang pesannya akan ditambahkan.

Selain alamat tujuan, perlu juga untuk menentukan rute yang harus diikuti oleh pesan. Spesifikasi rute
dilakukan dengan memberikan nama antrian kirim lokal tempat pesan akan ditambahkan. Dengan
demikian tidak perlu memberikan rute lengkap dalam sebuah pesan. Ingatlah bahwa setiap saluran pesan
memiliki antrian pengiriman yang tepat. Dengan memberi tahu pengirim antrian mana pesan harus
ditambahkan, kami secara efektif menentukan kepada manajer antrian mana pesan akan diteruskan.

Dalam kebanyakan kasus, rute secara eksplisit disimpan di dalam manajer antrian di tabel perutean. Entri
dalam tabel perutean adalah pasangan (destQM, sendQ), di mana destQM adalah nama manajer antrian
tujuan, dan sendQ adalah nama antrian pengiriman lokal tempat pesan untuk manajer antrian tersebut
harus ditambahkan. (Entri tabel routing disebut alias di MQ.)
Ada kemungkinan bahwa sebuah pesan perlu ditransfer ke beberapa manajer antrian sebelum mencapai
tujuannya. Setiap kali manajer antrian menengah tersebut menerima pesan, itu hanya mengekstrak nama
manajer antrian tujuan dari header pesan, dan melakukan pencarian tabel-routing untuk menemukan
antrian pengiriman lokal tempat pesan harus ditambahkan.

Penting untuk disadari bahwa setiap manajer antrian memiliki nama unik seluruh sistem yang secara
efektif digunakan sebagai pengidentifikasi untuk manajer antrian itu. Masalah dengan menggunakan
nama-nama ini adalah bahwa mengganti manajer antrian, atau mengubah namanya, akan memengaruhi
semua aplikasi yang mengirim pesan kepadanya. Masalah dapat diatasi dengan menggunakan alias lokal
untuk nama manajer antrian. Alias yang ditentukan dalam manajer antrian Ml adalah nama lain untuk
manajer antrian M2, tetapi hanya tersedia untuk aplikasi yang berinteraksi dengan Ml. Alias
memungkinkan penggunaan nama (logis) yang sama untuk antrian, bahkan jika manajer antrian
perubahan antrian itu. Mengubah nama manajer antrian mengharuskan kami mengubah alias di semua
manajer antrian. Namun, aplikasi dapat dibiarkan tidak terpengaruh.

Gambar 4-24. Organisasi umum dari jaringan antrian MQ menggunakan tabel routing dan alias.

Prinsip penggunaan tabel routing dan alias ditunjukkan pada Gambar. 4-24. Misalnya, aplikasi yang
ditautkan ke manajer antrian QMA dapat merujuk ke manajer antrian jarak jauh menggunakan alias lokal
LAJ. Manajer antrian pertama-tama akan mencari tujuan sebenarnya di tabel alias untuk menemukannya
adalah manajer antrian QMC. Rute ke QMC ditemukan di tabel perutean, yang menyatakan bahwa pesan
untuk QMC harus ditambahkan ke antrian SQl keluar, yang digunakan untuk mentransfer pesan ke
manajer antrian QMB. Yang terakhir akan menggunakan tabel peruteannya untuk meneruskan pesan ke
QMC.

Mengikuti pendekatan perutean dan aliasing ini mengarah ke antarmuka pemrograman yang, pada
dasarnya, relatif sederhana, yang disebut Antarmuka Antrian Pesan (MQI). Primitif terpenting dari MQI
diringkas dalam Gambar 4-25.
Gambar 4-25. Primitif tersedia di antarmuka antrian pesan.

Untuk memasukkan pesan ke dalam antrian, aplikasi memanggil primitif MQopen, menentukan antrian
tujuan di manajer antrian tertentu. Manajer antrian dapat dinamai menggunakan alias yang tersedia
secara lokal. Apakah antrian tujuan sebenarnya jauh atau tidak sepenuhnya transparan untuk aplikasi.
MQopen juga harus dipanggil jika aplikasi ingin mendapatkan pesan dari antrian lokalnya. Hanya antrian
lokal yang dapat dibuka untuk membaca pesan masuk. Ketika aplikasi selesai dengan mengakses antrian,
itu harus menutupnya dengan memanggil MQclose.

Pesan dapat ditulis ke, atau dibaca dari, antrian menggunakan MQput dan MQget, masing-masing. Pada
prinsipnya, pesan dihapus dari antrian berdasarkan prioritas. Pesan dengan prioritas yang sama dihapus
pada dasar masuk pertama, keluar pertama, yaitu, pesan tertunda terlama dihapus terlebih dahulu.
Dimungkinkan juga untuk meminta pesan tertentu. Akhirnya, MQ menyediakan fasilitas untuk memberi
sinyal aplikasi ketika pesan telah tiba, sehingga menghindari aplikasi yang harus terus-menerus melakukan
polling antrian pesan untuk pesan yang masuk.

Mengelola Jaringan Hamparan

Dari uraian sejauh ini, harus jelas bahwa bagian penting dari pengelolaan sistem MQ adalah
menghubungkan berbagai manajer antrian ke jaringan overlay yang konsisten. Terlebih lagi, jaringan ini
perlu dipertahankan dari waktu ke waktu. Untuk jaringan kecil, pemeliharaan ini tidak akan memerlukan
lebih dari pekerjaan administrasi rata-rata, tetapi masalah menjadi rumit ketika antrian pesan digunakan
untuk mengintegrasikan dan menghancurkan sistem besar yang ada.

Masalah utama dengan MQ adalah bahwa jaringan overlay perlu diadministrasikan secara manual.
Administrasi ini tidak hanya melibatkan membuat saluran antara manajer antrian, tetapi juga mengisi
tabel routing. Jelas, ini bisa tumbuh menjadi mimpi buruk. Sayangnya, dukungan manajemen untuk sistem
MQ hanya maju dalam arti bahwa administrator dapat mengatur hampir setiap atribut yang mungkin, dan
mengubah setiap konfigurasi yang masuk akal. Namun, intinya adalah bahwa saluran dan tabel perutean
perlu dikelola secara manual.

Inti dari manajemen overlay adalah komponen fungsi kontrol saluran, yang secara logis berada di antara
agen saluran pesan. Komponen ini memungkinkan operator untuk memantau apa yang sedang terjadi di
dua titik akhir saluran. Selain itu, digunakan untuk membuat saluran dan tabel perutean, tetapi juga untuk
mengelola manajer antrian yang meng-host agen saluran pesan. Di satu sisi, pendekatan ini untuk
manajemen overlay sangat mirip dengan manajemen server cluster di mana server administrasi tunggal
digunakan. Dalam kasus terakhir, server pada dasarnya hanya menawarkan shell jarak jauh untuk setiap
mesin di cluster, bersama dengan beberapa operasi kolektif untuk menangani kelompok mesin. Kabar
baiknya tentang manajemen sistem terdistribusi adalah bahwa ia menawarkan banyak peluang jika Anda
mencari area untuk mengeksplorasi solusi baru untuk masalah serius.