Haruskah Anda menggunakan JMS?

Pengembangan sistem terdistribusi berkembang pesat karena pengembang perangkat lunak membangun sistem yang harus mengikuti persyaratan yang terus meningkat yang diberlakukan oleh e-bisnis. Namun, belum pernah desain dan implementasi lapisan pemrosesan pesan dalam sistem terdistribusi menjadi serumit saat ini. Hal ini sebagian besar disebabkan oleh peningkatan dramatis dalam potensi fungsionalitas yang dimungkinkan oleh standar seperti Java Message Service (JMS) yang menghubungkan banyak teknologi vendor dalam satu sistem. Selain itu, penyebaran Internet telah memunculkan basis pengguna baru yang luas dan telah menyediakan beberapa protokol untuk komunikasi dalam sistem terdistribusi. Protokol tersebut termasuk CORBA IIOP (Internet Inter-ORB Protocol), Microsoft DCOM (Distributed Component Object Model), dan Java RMI (Remote Method Invocation).

Evolusi alami dari protokol ini telah menyebabkan pengenalan middleware berorientasi pesan (MOM), yang memungkinkan penggandengan yang lebih longgar dalam sistem terdistribusi dengan mengabstraksi terjemahan, keamanan, dan protokol komunikasi yang mendasari dari klien dan server. Solusi middleware termasuk SOAP (Simple Object Access Protocol) dan JMS. Pemrosesan transaksi lapisan menengah berpemilik telah ada sejak masa awal COBOL (Common Business Oriented Language), tetapi itu tidak terlalu rumit karena keterbatasan teknologi perpesanan awal.

Dengan munculnya standar seperti JMS, pengembang sekarang dapat menghubungkan berbagai teknologi. Keputusan desain sistem terdistribusi lebih sulit, dan implikasinya pada integritas dan distribusi data sangat penting untuk keberhasilan atau kegagalan sistem.

Asumsi yang meresap dan diam-diam adalah bahwa pengenalan teknologi adalah aset sementara kewajibannya seringkali diabaikan. Tidak memperhitungkan kewajiban sering kali menghasilkan sistem yang rumit dan / atau terlalu direkayasa. Pemahaman dasar tentang JMS dan kualitas inherennya (kualitas sistem-independen), diikuti dengan analisis yang cermat dalam kaitannya dengan skenario sistem terdistribusi tertentu dapat menunjukkan seberapa baik JMS dapat menyelesaikan persyaratan sistem versus mengubah masalah yang ada atau bahkan memperkenalkan masalah baru.

Ringkasan JMS

JMS, diperkenalkan oleh Sun Microsystems pada tahun 1999 sebagai bagian dari spesifikasi Java 2 Platform, Enterprise Edition (J2EE), adalah seperangkat standar yang menjelaskan fondasi untuk lapisan middleware pemrosesan pesan. JMS memungkinkan sistem untuk berkomunikasi secara sinkron atau asinkron melalui model point-to-point dan publish-subscribe. Saat ini, beberapa vendor menyediakan implementasi JMS seperti BEA Systems, Hewlett-Packard, IBM, Macromedia, dan Oracle, sehingga memungkinkan JMS untuk berinteraksi dengan berbagai teknologi vendor.

Gambar 1 menunjukkan sistem berbasis JMS sederhana dengan antrian keluar yang diisi dengan pesan untuk diproses klien, dan antrian masuk, yang mengumpulkan hasil pemrosesan klien untuk dimasukkan ke dalam database.

Seperti disebutkan di atas, MOM (seperti JMS) memungkinkan kopling yang lebih longgar dalam sistem terdistribusi dengan mengabstraksi terjemahan, keamanan, dan protokol komunikasi yang mendasari dari klien dan server. Salah satu aset utama lapisan pemrosesan pesan adalah, karena lapisan abstraksi ini diperkenalkan, implementasi klien atau server dapat berubah, terkadang secara radikal, tanpa memengaruhi komponen sistem lainnya.

Dua skenario khusus

Pada bagian ini, saya menyajikan dua sistem terdistribusi yang merupakan kandidat potensial untuk JMS dan menjelaskan tujuan masing-masing sistem dan mengapa sistem tersebut merupakan kandidat JMS.

skenario 1

Kandidat pertama adalah sistem pengkodean terdistribusi (ditunjukkan pada Gambar 2). Sistem ini memiliki sekumpulan N klien yang mengambil pekerjaan encoding dari server database pusat. Klien kemudian mengeksekusi transformasi aktual (encoding) dari master digital ke file yang dikodekan, dan menyelesaikannya dengan melaporkan status pasca-pemrosesan mereka (misalnya, berhasil / gagal) kembali ke server database pusat.

Jenis pengkodean (misalnya, teks, audio, atau video) atau transformasi (misalnya, .pdfuntuk .xml, .wavuntuk .mp3, .aviuntuk .qt) tidak penting. Penting untuk dipahami bahwa encoding memerlukan banyak CPU dan memerlukan pemrosesan terdistribusi di beberapa klien untuk diskalakan.

Secara sekilas, sistem ini berpotensi menjadi kandidat JMS karena:

  • Pemrosesan harus didistribusikan karena sangat intensif prosesor (CPU)
  • Mungkin bermasalah, dari sudut pandang kinerja sistem, untuk menghubungkan beberapa klien secara langsung ke server database tunggal

Skenario 2

Sistem kandidat JMS kedua adalah sistem pendaftaran global untuk portal Internet. Pendaftaran global menangani permintaan pembuatan pengguna baru (pendaftaran), login, dan otentikasi.

Informasi registrasi khusus (misalnya, nama, alamat, warna favorit) dan metode otentikasi pengguna (misalnya, objek pengguna sisi server, cookie HTTP) tidak penting. Namun, skala sistem ini penting untuk menangani jutaan pengguna, dan pola penggunaan sulit, jika bukan tidak mungkin, untuk diprediksi. (Selama pertandingan Piala Dunia ESPN yang disiarkan televisi, penyiar berkata, "Masuk dan pilih dalam jajak pendapat online kami. Kami akan menyajikan hasilnya di akhir acara." Tiba-tiba, 500.000 pengguna masuk dalam tiga menit interval. 3 menit = 180 detik; 500.000 login pengguna / 180 detik = 2.778 login pengguna / detik.)

Sistem ini merupakan kandidat JMS potensial karena alasan berikut:

  • Sistem harus didistribusikan untuk mengukur volume transaksi
  • Transaksi bersifat atomik (mis., Login), jadi tidak berkewarganegaraan dan oleh karena itu kandidat untuk distribusi

Kedua sistem ini memiliki arsitektur yang sama. Beberapa mesin klien mengekstrak data dari server database pusat (mungkin direplikasi ke server database M read-only), menjalankan beberapa logika pada klien, dan kemudian melaporkan status kembali ke server database pusat. Satu sistem mengirimkan file yang dikodekan ke sistem file melalui UNC / FTP; yang lain mengirimkan konten HTML ke browser Web melalui HTTP. Kedua sistem tersebut didistribusikan.

Ini sejauh yang dilakukan oleh banyak insinyur dengan analisis mereka sebelum menerapkan JMS. Di sisa artikel ini, saya menjelaskan bahwa, meskipun sistem ini memiliki banyak karakteristik, kesesuaian JMS menjadi lebih jelas dan lebih berbeda saat kami memeriksa persyaratan masing-masing sistem, termasuk kinerja sistem, distribusi data, dan skalabilitas.

Analisis sistem: Untuk mengintegrasikan atau tidak mengintegrasikan

JMS memiliki kualitas intrinsik, sistem-independen. Beberapa dari kualitas ini (pro dilambangkan dengan +, kontra dilambangkan dengan -) yang berlaku untuk kedua sistem meliputi:

  • (+) JMS adalah seperangkat standar yang dibuat oleh implementasi beberapa vendor; oleh karena itu, Anda menghindari masalah penguncian vendor yang ditakuti .
  • (+) JMS memungkinkan abstraksi (melalui API generik) antara klien dan server; Anda dapat mengubah skema database atau platform tanpa mengubah lapisan aplikasi (tersirat di sini adalah perubahan sistem potensial lainnya, diisolasi satu sama lain oleh lapisan pesan).
  • (+) / (-) JMS dapat membantu skala sistem (pro). Kerugiannya adalah bahwa sistem apa pun yang diskalakan dengan JMS dapat diskalakan tanpanya.
  • (-) JMS itu rumit. Ini adalah lapisan yang sama sekali baru dengan serangkaian server baru. Manajemen peluncuran perangkat lunak, pemantauan server, dan keamanan hanyalah beberapa dari masalah nontrivial yang terkait dengan peluncuran JMS. Biaya juga harus dipertimbangkan.
  • (-) Vendor tidak selalu menafsirkan dan karena itu menerapkan standar dengan cara yang persis sama, sehingga terdapat perbedaan di antara berbagai penerapan.
  • (-) Dengan JMS, Anda memerlukan lebih banyak pemeriksaan dan saldo sistem. Anda tidak hanya memperkenalkan lapisan baru, Anda juga memperkenalkan distribusi dan pengakuan data asinkron, yang memiliki kerumitan tambahan dari pemberitahuan asinkron.
  • (-) Tidak ada pelaporan pesan / update / antrian pemantauan tanpa software kustom.

JMS juga memiliki kualitas yang bergantung pada sistem. Kesesuaian JMS bergantung pada seberapa baik kualitas ini dipetakan ke kumpulan masalah yang Anda coba selesaikan. Beberapa dari kualitas ini dan bagaimana mereka berhubungan dengan dua sistem minat adalah sebagai berikut:

Caching

Caching adalah pertimbangan utama untuk perencanaan kapasitas dalam sistem terdistribusi apa pun. JMS memiliki banyak fitur yang memungkinkan penggunaannya sebagai teknologi caching (terutama yang terdistribusi, sinkron atau asinkron, dan pertukaran data sebagai objek dalam pesan). Oleh karena itu, penginstalan JMS yang ada dapat dimanfaatkan sebagai infrastruktur cache jika diperlukan.

Saat mempertimbangkan sistem pengkodean, caching umumnya tidak berguna untuk meningkatkan kinerja sistem secara keseluruhan, karena sebagian besar transformasi file dijalankan satu kali dan pindah ke fasilitas hosting atau SAN (jaringan area penyimpanan), dan ada sedikit konten yang tumpang tindih di antara pelanggan. Pendaftaran global adalah kandidat utama untuk cache informasi pengguna, karena pengguna biasanya masuk, menelusuri, dan kemudian keluar. Login membuat entri cache pengguna, dan objek ini menyediakan otentikasi pengguna berikutnya saat pengguna berada di situs.

Memproses pesanan

Dalam sistem registrasi global, tidak ada penjadwalan dan / atau perintah untuk pemrosesan transaksi. Pengguna pseudo-random memasuki sistem pada interval pseudo-random setelah login, menelusuri konten (dan oleh karena itu diautentikasi saat mereka mengakses konten dan / atau aplikasi yang dibatasi), lalu keluar.

Dalam sistem pengkodean, pemrosesan dipesan. Konten dikelompokkan ke dalam grup untuk pengiriman tergantung pada ketersediaan penyimpanan yang dapat dilepas (misalnya, Penyimpanan Solusi DLT atau Peralatan Jaringan). Konten tidak akan dikirim sampai batch selesai, jadi batch harus dijalankan secara berurutan (meskipun transformasi dalam batch berpotensi tidak diurutkan). Penerapan antrean prioritas dalam JMS untuk mempertahankan urutan pemrosesan dimungkinkan, tetapi mempertahankan urutan kumpulan pesan ini antara beberapa server JMS dan beberapa antrean menjadi cukup rumit. Server database relasional dengan dukungan untuk transaksi adalah teknologi yang lebih cocok untuk mengelola alur kerja ini.

Keamanan

Keamanan bukan bagian dari spesifikasi JMS. Masalah keamanan tidak perlu diubah dengan implementasi berbasis JMS (jika Anda memiliki persyaratan keamanan sebelum JMS, Anda akan memiliki persyaratan keamanan yang serupa setelah JMS). Mengetahui hal ini, penting untuk memahami bagaimana JMS dapat dikaitkan dengan keamanan infrastruktur yang ada.

Secara umum, semakin banyak teknologi yang Anda gunakan, semakin rentan sistem Anda terhadap peretas dan pelanggaran keamanan. Karena server aplikasi pendaftaran global menghadap ke Web, kelemahan keamanan yang ditemukan dalam implementasi JMS vendor Anda dan dipublikasikan di grup berita Internet dengan cepat menjadi kewajiban keamanan untuk situs Anda. Selain itu, karena JMS adalah API umum, JMS lebih rentan terhadap pelanggaran keamanan daripada sistem berpemilik yang menggunakan API yang tidak dipublikasikan.

Meskipun Anda dapat memanfaatkan firewall yang ada dan keamanan jaringan berbasis IP untuk melindungi aplikasi back-end (baca: tidak menghadap Web — pun dimaksudkan) server database dari pelanggaran keamanan, ada risiko keamanan yang signifikan yang dibuat dengan mengekspos server aplikasi JMS langsung ke Internet.

Sistem pengkodean umumnya ada di jaringan yang sama (juga jaringan yang diisolasi dari Internet). Jadi, tidak ada yang melekat pada topografi jaringan sistem ini yang berhubungan dengan JMS dan memanfaatkan topografi ini untuk memberikan keamanan (ada persyaratan keamanan yang jauh lebih sedikit untuk sistem pengkodean, karena tidak menghadap web).

Skalabilitas

Karena sistem registrasi global tunduk pada keinginan basis pengguna yang besar dan mengklik secara tak terduga, persyaratan skalabilitas sistem menjamin JMS. JMS tidak hanya akan membantu menskalakan sistem, tetapi juga akan mengantri transaksi, meskipun tidak akan banyak membantu ketika permintaan pengguna membanjiri sistem.

Karena sistem pengkodean terdistribusi telah mengatur lalu lintas data dengan hati-hati (karena mungkin merupakan sistem mandiri), persyaratan skalabilitas sistem tidak terlalu tangguh. Untuk encoding terdistribusi, Anda dapat menghubungkan O[100]klien Anda langsung ke database dan membatasi lalu lintas mereka untuk menyeimbangkan throughput encoding dengan performa server database.

Performa

Pengenalan server JMS tunggal dapat mengubah masalah kinerja daripada menyelesaikannya. Untuk alasan ini, sistem JMS harus dirancang dengan beberapa server JMS (dan karena itu banyak antrian). Gambar 4 menunjukkan mengapa masalah kinerja diubah alih-alih diselesaikan. Ini menggambarkan lapisan pemrosesan yang diperlukan untuk server data generik untuk menanggapi permintaan koneksi klien:

Pertukaran data antara klien dan server adalah proses dua bagian, apakah ini server klien-ke-database atau klien-ke-JMS:

  1. Akses data
  2. Manajemen utas dan soket, penggabungan, dan caching

JMS dan server database terlihat persis sama (Gambar 4). Mereka menangani koneksi soket, manajemen utas, dan akses ke data server.

Dengan hanya satu server JMS, masalah kinerja potensial cukup bolak-balik dari server database ke server JMS. Selain kemungkinan penurunan kinerja yang terkait dengan peralihan konteks dalam server database Anda, masalah kinerja sekarang berpotensi lebih besar karena masalah kinerja JVM dalam server JMS Anda.

Satu server JMS menambahkan kompleksitas yang signifikan ke sistem Anda dan mungkin juga menimbulkan masalah kinerja yang terkait dengan koneksi beberapa klien ke satu server. Dampak dari beberapa server JMS pada desain sistem dan aliran data Anda dapat menyebabkan perbedaan antara peluncuran sistem yang berhasil atau gagal.

Singkatnya, fitur versus potensi dampak JMS terlihat seperti ini:

Fitur versus dampak JMS