Pesan Antrian vs. Layanan Web? [Tutup]

Dalam kondisi apa seseorang akan menyukai aplikasi yang berbicara melalui antrian pesan alih-alih melalui layanan web (maksud saya XML atau JSON atau YAML atau apa pun melalui HTTP di sini, bukan jenis tertentu)?

Saya harus berbicara antara dua aplikasi di jaringan lokal. Satu akan menjadi aplikasi web dan harus meminta perintah pada aplikasi lain (berjalan pada perangkat keras yang berbeda). Permintaan adalah hal-hal seperti membuat pengguna, memindahkan file, dan membuat direktori. Dalam kondisi apa saya lebih suka Layanan Web XML (atau TCP lurus atau sesuatu) daripada menggunakan antrian Pesan?

Aplikasi web adalah Ruby on Rails, tapi saya pikir pertanyaannya lebih luas dari itu.

Saat Anda menggunakan layanan web, Anda memiliki klien dan server:

1. Jika server gagal, klien harus bertanggung jawab untuk menangani kesalahan.
2. Ketika server bekerja kembali, klien bertanggung jawab untuk mengirimnya kembali.
3. Jika server memberikan respons terhadap panggilan dan klien gagal operasi hilang.
4. Anda tidak memiliki pendapat, yaitu: jika jutaan klien memanggil layanan web pada satu server dalam satu detik, kemungkinan besar server Anda akan turun.
5. Anda dapat mengharapkan respons langsung dari server, tetapi Anda juga dapat menangani panggilan tidak sinkron.

Saat Anda menggunakan antrian pesan seperti RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo Anda mengharapkan hasil yang berbeda dan lebih toleran terhadap kesalahan:

1. Jika server gagal, antrian tetap ada pesan (opsional, bahkan jika mesin dimatikan).
2. Ketika server bekerja kembali, ia menerima pesan yang tertunda.
3. Jika server memberikan respons terhadap panggilan dan klien gagal, jika klien tidak mengakui respons pesan tetap ada.
4. Anda memiliki pendapat, Anda dapat memutuskan berapa banyak permintaan yang ditangani oleh server (sebut saja pekerja itu).
5. Anda tidak mengharapkan respons sinkron langsung, tetapi Anda dapat menerapkan / mensimulasikan panggilan sinkron.

Antrian Pesan memiliki lebih banyak fitur, tetapi ini adalah aturan praktis untuk memutuskan apakah Anda ingin menangani sendiri kondisi kesalahan atau membiarkannya pada antrian pesan.

Sudah ada cukup banyak penelitian terbaru dalam mempertimbangkan bagaimana REST panggilan HTTP dapat menggantikan konsep antrian pesan.

Jika Anda memperkenalkan konsep proses dan tugas sebagai sumber daya, kebutuhan untuk lapisan olahpesan menengah mulai menguap.

Ex:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Suatu tugas dapat memiliki beberapa langkah untuk inisialisasi, dan suatu proses dapat mengembalikan status ketika disurvei atau POST ke URL panggilan balik saat selesai.

Ini sangat sederhana, dan menjadi sangat kuat ketika Anda menyadari bahwa Anda sekarang dapat berlangganan feed rss / atom dari semua proses dan tugas yang sedang berjalan tanpa lapisan tengah. Sistem antrian apa pun akan memerlukan semacam web front end, dan konsep ini telah membuatnya tanpa lapisan kode kustom lain.

Sumber daya Anda ada sampai Anda menghapusnya, yang berarti Anda dapat melihat informasi historis lama setelah proses dan tugas selesai.

Anda telah membangun dalam penemuan layanan, bahkan untuk tugas yang memiliki beberapa langkah, tanpa protokol yang rumit.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

Penemuan layanan Anda adalah bentuk HTML - format universal dan dapat dibaca manusia.

Seluruh aliran dapat digunakan secara terprogram atau oleh manusia, menggunakan alat yang diterima secara universal. Ini didorong oleh klien, dan karenanya tenang. Setiap alat yang dibuat untuk web dapat mendorong proses bisnis Anda. Anda masih memiliki saluran pesan alternatif dengan POST secara asinkron ke larik server log yang terpisah.

Setelah Anda mempertimbangkannya sebentar, Anda duduk dan mulai menyadari bahwa REST mungkin hanya menghilangkan kebutuhan untuk antrian pengiriman pesan dan ESB sama sekali.

http://www.infoq.com/presentations/BPM-with-REST

Antrian pesan sangat ideal untuk permintaan yang mungkin membutuhkan waktu lama untuk diproses. Permintaan diantrekan dan dapat diproses secara offline tanpa memblokir klien. Jika klien perlu diberitahu tentang penyelesaian, Anda dapat memberikan cara bagi klien untuk secara berkala memeriksa status permintaan.

Antrian pesan juga memungkinkan Anda untuk meningkatkan skala waktu. Ini meningkatkan kemampuan Anda untuk menangani semburan aktivitas berat, karena pemrosesan yang sebenarnya dapat didistribusikan sepanjang waktu.

Perhatikan bahwa antrian pesan dan layanan web adalah konsep ortogonal, yaitu mereka tidak saling eksklusif. Misalnya Anda dapat memiliki layanan web berbasis XML yang bertindak sebagai antarmuka ke antrian pesan. Saya pikir perbedaan yang Anda cari adalah Antrian Pesan versus Permintaan / Tanggapan, yang terakhir adalah ketika permintaan diproses secara serempak.

Antrian pesan asinkron dan dapat mencoba beberapa kali jika pengiriman gagal. Gunakan antrian pesan jika pemohon tidak perlu menunggu jawaban.

Ungkapan "layanan web" membuat saya berpikir tentang panggilan sinkron ke komponen yang didistribusikan melalui HTTP. Gunakan layanan web jika pemohon membutuhkan respons kembali.

Saya pikir secara umum, Anda menginginkan layanan web untuk tugas pemblokiran (tugas ini harus diselesaikan sebelum kami mengeksekusi lebih banyak kode), dan antrian pesan untuk tugas yang tidak menghalangi (bisa memakan waktu cukup lama, tapi kami tidak tidak perlu menunggu untuk itu).