RMI selama IIOP

Apakah RMI di atas IIOP?

RMI over IIOP (selanjutnya RMI-IIOP), dikembangkan bersama oleh IBM dan Sun, adalah versi baru dari RMI (Remote Method Invocation) untuk IIOP (Internet Inter-ORB Protocol) yang menggabungkan fitur pemrograman RMI yang mudah dengan interoperabilitas CORBA. Versi baru RMI ini secara resmi dirilis pada bulan Juni dan tersedia secara gratis dari situs Web Sun (lihat bagian Sumberdaya di bawah untuk informasi di mana Anda dapat mengunduhnya). Implementasi referensi Sun berjalan pada Windows 9x / NT dan Solaris. Ini adalah ekstensi standar yang mendukung JDK 1.1.6 dan Platform Java 2.

RMI dan CORBA telah berkembang secara independen sebagai model pemrograman objek terdistribusi. RMI, fondasi dari teknologi EJB dan Jini, diperkenalkan sebagai model pemrograman berbasis Java yang mudah digunakan untuk objek terdistribusi. CORBA (Arsitektur Broker Permintaan Objek Umum), yang ditentukan oleh OMG (Object Management Group), adalah model pemrograman objek terdistribusi terkenal yang mendukung sejumlah bahasa. Protokol IIOP menghubungkan produk CORBA dari vendor yang berbeda, memastikan interoperabilitas di antara mereka. RMI-IIOP, dalam arti tertentu, merupakan perkawinan antara RMI dan CORBA.

Untuk keperluan artikel ini, kami berasumsi bahwa Anda sudah terbiasa dengan dasar-dasar CORBA. Jika Anda membutuhkan bantuan lebih lanjut untuk mendapatkan informasi terbaru, ada tautan bermanfaat di bagian Sumber Daya di bawah ini.

Sebelum RMI-IIOP

Lihat Gambar 1 di bawah ini. Ruang di atas garis horizontal tengah mewakili domain asli RMI; wilayah bawah mewakili dunia CORBA dan IIOP. Dua dunia yang terpisah ini, setelah berkembang secara mandiri, secara historis tidak mampu berkomunikasi satu sama lain. Misalnya, protokol asli RMI, JRMP (Java Remote Method Protocol), tidak dapat terhubung dengan protokol lain.

Jika satu-satunya bahasa pemrograman yang Anda perlukan dalam proyek baru adalah Java, penggunaan RMI dan JRMP - kombinasi yang disebut sebagai RMI (JRMP) untuk sisa artikel ini - secara tradisional menjadi pilihan terbaik. Tidak seperti CORBA, yang membutuhkan penggunaan Interface Definition Language (IDL) yang agak rumit, RMI (JRMP) menawarkan pemrograman yang mudah untuk pecinta Java. CORBA, di sisi lain, memungkinkan pemrograman objek terdistribusi di berbagai platform dan bahasa pemrograman yang berbeda. Pengembang memerlukan pemrograman objek terdistribusi tidak hanya untuk proyek baru, tetapi juga untuk memanfaatkan sumber daya perangkat lunak lama. Tentu saja, perangkat lunak lawas dalam banyak kasus diprogram dalam bahasa selain Java; dalam situasi seperti itu, pengembang membutuhkan CORBA, bukan RMI (JRMP).

Jadi kami memiliki dilema utama kami: RMI (JRMP) memiliki keuntungan dari pemrograman yang mudah, sedangkan CORBA menyediakan interoperabilitas antara beberapa bahasa pemrograman di berbagai platform. Sayangnya, bagaimanapun, secara tradisional belum ada cara untuk menggunakan kedua teknologi yang sangat baik ini. Hal ini ditunjukkan oleh bagan pada Gambar 2, di mana lingkaran berarti situasi di mana klien dapat memanggil server, dan X berarti kasus di mana ini tidak mungkin

Terbaik dari kedua dunia

Dulu sulit untuk memilih antara RMI (JRMP) dan CORBA saat memulai proyek baru. Jika Anda memilih RMI (JRMP), Anda mendapatkan pemrograman yang mudah, tetapi kehilangan interoperabilitas di berbagai bahasa. Jika Anda memilih CORBA, Anda mendapatkan interoperabilitas, tetapi menghadapi tugas pemrograman yang lebih berat. Baik pengguna RMI (JRMP) dan CORBA, yang lelah membuat keputusan ini, berkata dengan satu suara: "Tolong hubungkan keduanya."

Pada Gambar 3 di bawah ini, bagian atas mewakili model RMI (JRMP), bagian tengah model RMI-IIOP, dan bagian bawah model CORBA. Panah mewakili situasi di mana klien dapat memanggil server. RMI-IIOP termasuk dalam dunia IIOP di bawah garis horizontal. Yang mungkin terlihat aneh adalah panah diagonal yang melintasi perbatasan antara dunia JRMP dan dunia IIOP, yang menyiratkan bahwa klien RMI (JRMP) dapat memanggil server RMI-IIOP, dan sebaliknya. Wajar bagi pembaca untuk berpikir panah diagonal ini salah - lagipula, protokol yang berbeda tidak akan pernah dapat saling berbicara, bukan? Namun, anak panah ini sebenarnya berada di tempat yang tepat. RMI-IIOP mendukung protokol JRMP dan IIOP.

Biner server (yaitu, file kelas) yang dibuat menggunakan API RMI-IIOP dapat diekspor sebagai JRMP atau IIOP. Anda tidak perlu menulis ulang kode sumber Java-nya, atau mengkompilasinya ulang saat mengubah dari JRMP ke IIOP, atau sebaliknya. Anda hanya perlu mengubah parameter seperti properti sistem Java saat menjalankannya. Alternatifnya, Anda dapat menentukan protokol yang digunakan dengan menentukannya di kode sumber Java. Fleksibilitas yang sama berlaku untuk kode klien RMI-IIOP.

Ekspor ganda

Ada satu fakta penting yang perlu diingat saat memutuskan antara protokol JRMP dan IIOP. Saat Anda mengekspor objek RMI-IIOP di server, Anda tidak perlu memilih antara JRMP dan IIOP. Jika Anda memerlukan satu objek server untuk mendukung klien JRMP dan IIOP, Anda dapat mengekspor objek RMI-IIOP Anda ke JRMP dan IIOP secara bersamaan. Dalam terminologi RMI-IIOP, ini disebut ekspor ganda.

Panah diagonal pada Gambar 3 dimungkinkan karena RMI-IIOP API mendukung protokol JRMP dan IIOP. Artinya, tanpa menulis ulang kode sumber objek RMI (JRMP), ia dapat dipanggil oleh klien RMI-IIOP baru. Demikian pula, tanpa menulis ulang kode sumber klien RMI (JRMP), Anda dapat mengganti objek server RMI (JRMP) dengan objek RMI-IIOP baru yang juga dapat dipanggil oleh klien CORBA. Dengan demikian, RMI-IIOP mempertahankan investasi yang ada dalam biner RMI (JRMP), karena RMI-IIOP dapat berkomunikasi dengan mereka tanpa perubahan kode sumber atau kompilasi ulang.

Interoperabilitas dengan RMI (JRMP) ini adalah salah satu prinsip desain RMI-IIOP. Desainer RMI-IIOP menghindari godaan untuk menggantikan CORBA dan RMI dengan model pemrograman ketiga, karena ini hanya akan membingungkan programmer objek terdistribusi dan membuat migrasi dari RMI (JRMP) semakin sulit.

Interoperabilitas dengan CORBA

Lihat Gambar 3 lagi. Bagian di bawah garis horizontal adalah dunia IIOP, di mana klien RMI-IIOP memanggil server CORBA, dan klien CORBA memanggil server RMI-IIOP. Yang kami maksud dengan klien RMI-IIOP adalah program klien yang ditulis oleh programmer RMI yang tidak tahu apa-apa tentang CORBA atau IDL. Demikian juga dengan klien CORBAadalah program klien yang ditulis oleh programmer CORBA yang tidak mengetahui RMI. Pemisahan antarmuka dari implementasi adalah teknik mapan untuk memungkinkan pemrogram mengakses sumber daya yang berbeda tanpa perlu mengetahui bagaimana sumber daya tersebut diimplementasikan; jika teknik ini diikuti, pengguna RMI-IIOP dan CORBA dapat menggunakan layanan dari protokol lain, jika mereka bisa mendapatkan akses ke antarmukanya. File antarmuka Java RMI adalah antarmuka untuk pengguna RMI-IIOP, sedangkan IDL adalah antarmuka untuk pengguna CORBA; interoperabilitas antara RMI-IIOP dan CORBA pada Gambar 3 dicapai dengan menyediakan antarmuka yang diharapkan setiap pengguna, sambil tetap menyembunyikan implementasi aktual.

Detail terakhir yang akan dijelaskan pada Gambar 3 adalah panah bertitik yang menunjukkan klien RMI-IIOP yang memanggil server CORBA. Mengapa hanya panah ini yang bertitik? Klien RMI-IIOP tidak selalu dapat mengakses semua objek CORBA yang ada. Semantik objek CORBA yang didefinisikan dalam IDL adalah superset dari objek RMI-IIOP, itulah sebabnya IDL objek CORBA yang ada tidak selalu dapat dipetakan ke dalam antarmuka Java RMI-IIOP. Hanya ketika semantik objek CORBA tertentu kebetulan sesuai dengan yang ada di RMI-IIOP, klien RMI-IIOP dapat memanggil objek CORBA. Panah putus-putus menunjukkan koneksi yang terkadang - tetapi tidak selalu - memungkinkan.

Namun, ketidakcocokan di sini tidak boleh dilebih-lebihkan. Batasan yang ditunjukkan oleh panah putus-putus hanya berlaku saat menangani objek CORBA yang ada. Misalkan Anda mendesain objek terdistribusi baru dengan antarmuka Java RMI-IIOP. Dalam kasus ini, Anda dapat secara otomatis menghasilkan IDL yang sesuai denganrmicalat. Dari file IDL ini, Anda dapat mengimplementasikannya sebagai objek CORBA - di C ++, misalnya. Objek C ++ ini adalah objek CORBA murni yang dapat dipanggil oleh klien CORBA dan juga dapat dipanggil oleh klien RMI-IIOP tanpa batasan apa pun. Untuk klien RMI-IIOP, objek C ++ CORBA ini muncul sebagai objek RMI-IIOP murni karena ditentukan oleh antarmuka Java RMI-IIOP. Singkatnya, perbedaan antara objek CORBA dan objek RMI-IIOP hanyalah masalah implementasi. Demikian juga, jika sebuah objek diimplementasikan di RMI-IIOP, objek tersebut muncul sebagai objek CORBA ke klien CORBA karena klien CORBA mengaksesnya melalui IDL-nya.

Gambar 4 di bawah ini menunjukkan matriks yang merangkum panah pada Gambar 3. Lingkaran putus-putus memiliki arti yang sama dengan panah bertitik pada Gambar 3. Gambar 4 menunjukkan bahwa, jika Anda mengimplementasikan server Anda di RMI-IIOP, Anda memiliki pilihan terluas klien. Demikian pula, jika Anda mengimplementasikan klien Anda di RMI-IIOP, Anda dapat berbicara dengan rentang server terbesar, meskipun ada beberapa batasan dalam kasus objek CORBA yang ada, seperti yang ditunjukkan oleh lingkaran bertitik.

Kebijakan desain RMI-IIOP

Ada dua prasyarat utama yang membentuk desain protokol RMI-IIOP: semantik RMI harus dibiarkan seutuhnya, dan CORBA perlu ditingkatkan sehingga semantik RMI dapat diimplementasikan menggunakan infrastruktur CORBA. Ini lebih mudah diucapkan daripada dilakukan. Jika model pemrograman ketiga diperkenalkan, itu hanya akan membingungkan programmer. Untuk menghasilkan pernikahan yang bahagia antara RMI dan CORBA, diperlukan kompromi antara latar belakang yang berbeda dari pasangan pernikahan ini - jika kedua pasangan menolak kompromi, pernikahan tidak akan berhasil. Untungnya, komunitas CORBA menyadari hal ini dan menerima perubahan tertentu sehingga RMI-IIOP bisa menjadi kenyataan.

Dua perubahan utama yang diterima CORBA adalah Objects by Value dan spesifikasi Java-to-IDL Mapping . Yang pertama, sudah tersedia untuk pengguna RMI dalam bentuk serialisasi objek Java, adalah spesifikasi CORBA yang dimaksudkan untuk membuat bahasa lain mengimplementasikan kemampuan serupa. Yang terakhir adalah pemetaan yang digunakan untuk mengubah antarmuka Java RMI menjadi definisi IDL CORBA, dan tidak boleh disamakan dengan pemetaan IDL-ke-Java yang telah ditentukan dalam CORBA 2.2. (Lihat Sumberdaya untuk tautan ke dua spesifikasi CORBA baru ini.)

OMG telah secara resmi menerima kedua spesifikasi untuk CORBA 2.3, tetapi implementasi CORBA harus mengikuti versi baru ini sebelum perkawinan baru CORBA dan RMI yang dijelaskan di sini menjadi kenyataan yang tersebar luas. Misalnya, kompiler IDL-ke-Java yang sesuai dengan CORBA 2.3 tersedia dari Sun untuk digunakan bersama dengan RMI-IIOP ORB (perantara permintaan objek), tetapi saat ini versi akses awal yang hanya cocok untuk menjelajahi interoperabilitas dari CORBA dan RMI-IIOP, dan bukan untuk penggunaan produksi. Lebih lanjut, kompiler IDL-ke-Java yang didistribusikan oleh Sun untuk digunakan dengan Java IDL ORB di Java 1.2 tidak sesuai dengan CORBA 2.3, sehingga tidak dapat digunakan untuk menguji interoperabilitas dengan RMI-IIOP. Situasi ini akan teratasi dalam beberapa bulan ke depan karena vendor CORBA memperkenalkan versi baru produk mereka yang mendukung CORBA 2.3.Misalnya, rilis Platform Java 2 berikutnya, Edisi Standar akan menyertakan RMI-IIOP dan kompiler IDL-ke-Java berkualitas produksi yang mendukung CORBA 2.3.

Prosedur pengembangan

Gambar 5 di bawah ini menunjukkan prosedur pengembangan untuk server dan klien RMI-IIOP. Anda akan melihat bahwa mereka hampir sama dengan RMI (JRMP). Sama seperti di RMI (JRMP), definisi objek terdistribusi adalah antarmuka Java RMI-nya ( MyObject.javapada Gambar 5). Perbedaannya adalah -iiopparameter rmickompilator. Pilihan ini digunakan untuk rmicmenghasilkan stub dan pengikat yang mendukung protokol IIOP. Tanpa -iiopopsi ini , rmicmenghasilkan stub dan kerangka untuk protokol JRMP. Meskipun prosedur pengembangan untuk RMI-IIOP dekat dengan RMI (JRMP), lingkungan runtime berbeda dalam komunikasi yang dilakukan melalui ORB yang sesuai dengan CORBA 2.3, menggunakan IIOP untuk komunikasi antara server dan klien.

Jika Anda mempertimbangkan untuk mengubah kode RMI (JRMP) menjadi RMI-IIOP, Anda harus menyadari bahwa ada beberapa perbedaan implementasi saat menjalankan IIOP. Pengumpulan sampah terdistribusi tidak didukung oleh CORBA, yang menggunakan pemusnahan eksplisit dan referensi objek persisten dengan pasif dan aktivasi transparan. Registri RMI diganti oleh JNDI dengan CosNamingatau penyedia layanan LDAP, dan aktivasi RMI diganti dengan adaptor objek portabel. Referensi objek jarak jauh harus downcast menggunakan narrow()metode terprogram, bukan transmisi bahasa Java langsung. Semantik RMI lainnya, seperti serialisasi objek, didukung penuh melalui IIOP.

Prosedur interoperabilitas CORBA

Gambar 6 menunjukkan bagaimana mencapai interoperabilitas antara RMI-IIOP dan CORBA. Untuk membuat diskusi kita lebih sederhana, mari pertimbangkan dua aspek interoperabilitas tersebut: klien CORBA menggunakan objek RMI-IIOP, digambarkan di bagian paling kiri dari Gambar 6, dan klien RMI-IIOP menggunakan objek CORBA, yang digambarkan di bagian paling kanan. Di tengah gambar adalah proses bersama yang memungkinkan kedua bentuk interoperabilitas bekerja.