Pertanyaan Java: RMI vs Layanan Web


Saya perlu membuat aplikasi terdistribusi yang terdiri dari beberapa klien yang mengirim file (ditambah info tentang file) ke satu server, juga query server itu.

Klien harus mengakses ke Server Web tersebut dari dalam perusahaan untuk mengirim file. Namun, terkadang beberapa pertanyaan khusus harus dijalankan di luar perusahaan.

Saya pikir, mengingat apa yang saya tahu, bahwa RMI adalah cara (operasi) yang lebih cepat untuk menghubungkan klien desktop dengan mesin pengindeksan plus mesin penyimpanan. Dan saya percaya bahwa membuat Layanan Web yang menyediakan lapisan akses ke mesin pencari juga merupakan keputusan yang baik, karena akan berjalan di luar jaringan perusahaan.

Apa yang Anda pikirkan? Apakah pendekatan yang baik atau apakah Anda memiliki beberapa alternatif harus dipertimbangkan.

Terima kasih sebelumnya.


10
2017-12-21 17:31


asal


Jawaban:


RMI dapat di-tunnel melalui HTTP (lihat sini), jadi jangan biarkan itu mempengaruhi keputusan Anda terlalu banyak.

Jika kedua ujungnya dapat berbicara RMI, maka RMI mungkin adalah apa yang harus Anda gunakan; jauh lebih mudah untuk bekerja daripada layanan web.


7
2017-12-21 17:41



Hati-hati di sini, saya mengembangkan solusi serupa baru-baru ini dan menemukan bahwa soket adalah cara yang paling efisien dan perfomant untuk mentransfer file, sementara RMI bagus untuk panggilan metode sederhana (seperti pertanyaan). Saya juga mengalami kesulitan mengatur RMI, konfigurasi dapat membingungkan kadang-kadang dan tidak ada banyak dokumentasi di luar sana pada subjek.

Saya yakin bahwa RMI akan memberi Anda kinerja yang lebih baik daripada layanan web; tetapi layanan web mungkin akan lebih mudah dipelihara dan fleksibel untuk kebutuhan di masa mendatang.


7
2017-12-24 04:35



Apa yang membuat Anda berpikir bahwa RMI lebih cepat? Dari pengalaman saya, itu bisa lambat, sulit dikonfigurasi, sulit untuk aman dan umumnya tidak menyenangkan untuk diajak bekerja sama.

Karena layanan web pada umumnya hanya XML melalui HTTP, Anda biasanya dapat merancang solusi yang akan menjadi lebih baik.


5
2017-12-21 17:41



Jika API yang ingin Anda dukung dengan layanan tidak memetakan dengan baik ke HTTP, saya mungkin akan memilih RMI (tetapi waspadai ulang-alik yang tidak perlu.)

Jika itu memetakan ke HTTP dengan baik, saya akan memilih untuk pergi dengan REST yang pada dasarnya adalah HTTP Servlet yang mengimplementasikan API Anda sebagai tindakan. Jika sebagian besar lalu lintas adalah pengunggahan / pengunduhan file yang Anda sebutkan dikombinasikan dengan beberapa panggilan API, ini mungkin cara untuk pergi.

Btw, pengalaman Anda bahwa RMI lebih cepat daripada layanan web bertepatan dengan saya. (Keduanya dapat diimplementasikan dengan kinerja yang lambat sebagai hasilnya, terutama berkaitan dengan perjalanan pulang-pergi dalam API yang dirancang dengan buruk.)


3
2017-12-21 17:56



Ini tidak pernah mengakhiri perdebatan. Inilah pendapat saya:

  • Layanan web memungkinkan arsitektur yang digabungkan longgar. Dengan RMI, Anda harus mengkompilasi semua bahkan jika ada perubahan terkecil (karena UUID seri kelas dan apa pun).
  • WS memungkinkan koeksistensi yang lebih mudah dengan komponen perusahaan lain (ESB, SSO, Identity Management, load balancing, filter keamanan, sertifikat keamanan) karena HTTP merupakan protokol jaringan yang mendasarinya.
  • Refleksi dalam RMI (dan dalam EJB) tampaknya lebih mahal daripada protokol HTTP itu sendiri.

Jika Anda berpikir tentang EJB sebagai lebih cocok untuk lingkungan server aplikasi dan mudah untuk membandingkan dengan WS dan CORBA sesuai artikel Anda, (EJB mendukung manajemen transaksi, manajemen kacang; WS memiliki WS + ekstensi (keamanan, transaksi)):

  • EJB lebih lambat dari WS menurut artikel: Remote EJB 3x lebih lambat dari WebService di 7.1
  • ketika mengkompilasi / membangun EJBs kami harus menggunakan versi server aplikasi yang sama persis termasuk patch pada dev dan produksi untuk menghindari kesalahan run-time produksi yang meragukan (ini hanya terlihat mudah - tim produksi (datacenter) tidak selalu mengatakan patch yang mereka miliki, ketika kami melakukan perbaikan untuk aplikasi kami selalu harus meminta kembali versi server yang tepat).
  • perbaikan parsial aplikasi tidak begitu mudah, jika EJB dibangun kembali karena perbaikan kecil, guci klien harus dibangun kembali, oleh karena itu aplikasi yang menggunakan guci klien perlu pemindahan.

(Ini adalah masalah dari pengalaman saya, mungkin orang lain lebih beruntung)

Saya akan menyimpulkan bahwa WebServices lebih fleksibel, menggunakan lebih sedikit refleksi, dan semoga lebih cepat jika dirancang dengan hati-hati. Jika RESTful digunakan dalam pengendali MVC sebagai hasilnya, ESB dapat membantu dengan menawarkan transformasi (kode kurang, hanya mengubah) dan injeksi keamanan langsung ke header HTTP (mis. Ivheader, ivgroup - jika menggunakan ibm web seal, Tivoli access manager). Menggunakan SAML XACML hanya mungkin bila menggunakan WS sebagai asersi berfungsi dengan XML. Oleh karena itu untuk aplikasi perusahaan yang didistribusikan dan dislokasi WS lebih fleksibel karena disebutkan di atas.

Artikel yang Anda sebutkan mengatakan bahwa WS tidak memiliki transaksi tetapi hanya proposal. Artikel itu salah atau terlalu tua. Lihat OASIS WSAT 1.0 dan WSAT 2.0. Microsoft, JBoss, Oracle dan beberapa lainnya mendukung teknologi di luar kotak di server aplikasi mereka. Apache Metro tampaknya mendukungnya dengan baik (harap verifikasi).


2
2017-07-22 11:14



RMI pada dasarnya untuk aplikasi kecil. Ya itu lebih cepat tetapi dari waktu ke waktu Anda akan merasa bahwa untuk melakukan lebih banyak peningkatan dalam aplikasi Anda ketika lalu lintas meningkat, jejaring lebih mudah dipelihara daripada RMI dan jika Anda memilih layanan web REStFull yang akan menjadi pilihan terbaik.

Terima kasih


1
2018-06-26 15:42