RMI ini versi Java-nya Remote Procedure Call (RPC)<\/a>, tapi punya kelebihan: bisa ngirim objek bersamaan dengan permintaan. Komunikasi antar aplikasi<\/a> remote ini dilakukan lewat dua objek utama: stub dan skeleton. RMI udah termasuk dalam paket bawaan Java Development Kit (JDK<\/a>) dari Sun Microsystems lewat package Secara teknis, permintaan RMI di Java itu sama kayak kita memanggil method biasa dari objek lokal. Bedanya, objeknya berada di komputer lain. Objek ini bisa mengirim data atau perilaku ke remote computer. Sun menyebut ini sebagai \u201cmoving behavior\u201d, dan proses ngoper objeknya disebut object serialization<\/i>.<\/p>\n Contohnya, user di komputer A mengisi form pengeluaran. Program Java di A bisa pakai RMI untuk ngobrol ke program Java di komputer B, yang punya aturan terbaru soal laporan pengeluaran. Komputer B ngasih balik objek berisi aturan terbaru, dan program di A langsung bisa validasi form sesuai kebijakan terbaru \u2014 tanpa harus update program di A. Cukup update di B aja.<\/p>\n Dalam pengembangan aplikasi Java yang terdistribusi, kita butuh akses ke method yang ada di remote server. Kita juga perlu bisa komunikasi dengan objek remote dan load class<\/a> miliknya. Nah, semua itu dijembatani oleh RMI.<\/p>\n RMI memungkinkan komunikasi client-server<\/a> lewat internet. Client bisa kirim request ke server, lalu server membalas sesuai logic-nya. Dengan RMI, programmer Java bisa bikin objek remote yang dapat diakses publik. Objek ini bisa dipanggil dari client cukup dengan method biasa. Komunikasi ini bisa dilakukan via URL<\/a> dan HTTP<\/a>.<\/p>\n RMI dirancang untuk mempertahankan model objek Java di jaringan, tetap aman, tetap konsisten, dan tetap enak dipakai \u2014 baik untuk objek lokal maupun remote.<\/p>\n RMI diimplementasikan lewat tiga lapisan utama:<\/p>\n 1. Stub Program.<\/b> Stub berada di sisi client, dan terlihat seperti objek asli buat program yang memanggil. Di sisi server-nya ada pasangan yang disebut skeleton. Stub juga bisa disebut proxy<\/i>.<\/p>\n 2. Remote Reference Layer (RRL).<\/b> Layer ini menangani referensi objek remote. Bisa satu target, bisa multicast. Dia juga yang mengatur aliran request dan response.<\/p>\n 3. Transport Connection Layer.<\/b> Layer ini yang ngurus koneksi jaringan antara stub di client dan skeleton di server. Dia nge-handle request biar bisa nyebrang dari client ke server dan sebaliknya.<\/p>\n Stub dan skeleton adalah dua objek RMI yang memfasilitasi komunikasi antar JVM. Stub itu gateway-nya client, sementara skeleton gateway-nya server.<\/p>\n Ketika method dipanggil lewat stub, stub bakal konek ke JVM, ngirim parameter, nunggu hasil atau exception, lalu ngasih balik ke caller.<\/p>\n Skeleton menerima request, baca parameternya, panggil objek sesungguhnya di server, lalu kirim hasilnya ke client.<\/p>\n Jadi dalam aplikasi RMI, kita butuh dua program: satu di client, satu di server. Di server dibuat objek remote, lalu referensinya bisa diakses oleh program client. RRL menghubungkan client dan server seolah-olah mereka terkoneksi secara virtual<\/a>.<\/p>\n Misalnya, ada aplikasi word processor yang terinstall di server. Client cukup klik ikon di desktop atau lewat command line untuk akses. Saat klik, client mengirim request ke objek remote di server.<\/p>\n Request ini lewat stub \u2192 masuk ke RRL di client \u2192 diteruskan ke RRL di server \u2192 dikirim ke skeleton \u2192 objek di server dijalankan \u2192 hasilnya dikirim balik ke client. User bisa langsung pakai software<\/a> itu di komputernya tanpa install lokal.<\/p>\n Waktu stub di client ngirim parameter ke JVM remote, proses ini disebut marshaling<\/i>. Parameternya bisa berupa tipe primitif atau objek. Biasanya dibungkus dulu jadi satu paket (termasuk header dan serialisasi untuk objek).<\/p>\n Skeleton di server juga melakukan marshaling saat mengirim hasil kembali ke client.<\/p>\n Begitu hasil sampai ke stub, proses unmarshaling<\/i> dimulai \u2014 yaitu membuka kembali data dan memberikan hasil ke pemanggil. Sama juga saat server nerima paket parameter dari client.<\/p>\n RMI Registry adalah namespace di sisi server yang nyimpen semua objek remote. Tiap objek punya nama unik. Client bisa ambil referensinya lewat Sebelum jalanin registry, pastikan window\/shell tempat kamu jalanin Secara default, registry ini jalan di port<\/a> 1099, tapi kamu bisa ganti asal konsisten antara client dan server code<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Apa itu Remote Method Invocation (RMI)? Remote Method Invocation atau disingkat RMI adalah sebuah API di dalam bahasa dan lingkungan pengembangan Java. RMI memungkinkan objek pada satu komputer atau JVM (Java Virtual Machine) berkomunikasi dengan objek lain yang berjalan di JVM berbeda dalam jaringan terdistribusi. Bisa dibilang, RMI itu cara mudah untuk bikin aplikasi Java […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[271],"tags":[168,167],"class_list":["post-5137","post","type-post","status-publish","format-standard","hentry","category-software-development","tag-back-end-and-middle-tier-frameworks","tag-front-end"],"yoast_head":"\njava.rmi<\/code>.<\/p>\nKenapa Perlu Remote Method Invocation?<\/h2>\n
![\"Depiction](\"https:\/\/www.theserverside.com\/rms\/onlineimages\/client_and_server_requests_and_responses-f_mobile.png\")
Model Implementasi Tiga Layer<\/h2>\n
Stub dan Skeleton di RMI<\/h2>\n
Cara Kerja Aplikasi RMI<\/h2>\n
Marshaling dan Unmarshaling di RMI<\/h2>\n
RMI Registry<\/h2>\n
lookup()<\/code> dengan nama yang udah di-bind()<\/code> atau reBind()<\/code>.<\/p>\nrmiregistry<\/code> nggak punya variabel CLASSPATH yang mengarah ke class remote. Kalau registry nemu class-nya di awal, dia nggak bakal load ulang dari server VM, dan client jadi nggak bisa download<\/a> class remote itu.<\/p>\n