PERBANDINGAN PENGGUNAAN 4 ORB BERBEDA PADA APLIKASI OBYEK TERDISTRIBUSI

Transkripsi

1 PERBANDINGAN PENGGUNAAN 4 ORB BERBEDA PADA APLIKASI OBYEK TERDISTRIBUSI Pranoto Suryo Hadi Teknik Elektro Politeknik Negeri Malang pranoto_sh@poltek-malang.ac.id, supitek@yahoo.com ABSTRAK CORBA (Common Request Broker Architecture) dan RMI (Remote Method Invocation) adalah dua tehnologi untuk komunikasi antar dua obyek terdistribusi melalui jaringan komputer. Dalam tehnologi tersebut, komunikasi antara client dengan server menggunakan semacam kanal yang disebut ORB (RequestBroker). Permasalahan muncul ketika pengembang dihadapkan pada pilihan implementasi CORBA yang akan digunakan, dimana tidak semua ORB bisa saling berinteraksi. Artikel ini memberikan informasi tentang hasil pengujian interoperabilitas dan membandingkan kecepatan transfer data, serta proses lookup obyek antar aplikasi yang menggunakan tehnologi ini. Sistem yang dibangun dengan beberapa konfigurasi dari empat implementasi CORBA bisa bekerja, dan menunjukkan pertambahan waktu proses jika menggunakan Implementasi Java. Kata Kunci: ORB, Obyek Terdistribusi 1. Pendahuluan 1.1. Latar Belakang Aplikasi terdistribusi memberikan manfaat yang cukup besar karena karakteristik yang dimilikinya yaitu bersifat multiuser, penggunaan resource bersama-sama, skalabilitas yang baik, efisien, toleransi terhadap kesalahan dan transparansi. Beberapa teknologi perangkat lunak yang dikembangkan dan mendukung aplikasi terdistribusi antara lain XML (extensible Markup Language), DCOM (Distributed Component Model), Java dengan JavaRMI dan CORBA (OMG). RMI didisain untuk Java dan diintegrasikan dengan JVM. Teknologi CORBA menggunakan pendekatan pemrograman netral yang memungkinkan jaringan obyek terdistribusi disusun lebih dari satu bahasa pemrograman. Pada jaringan CORBA, ORB menjadi media antara client dan server dengan ketentuan yang sudah dibuat standar. Komunikasi antar ORB menggunakan protokol Internet-Inter ORB Protocol (IIOP) yang merupakan protokol yang lebih tinggi dan berbasis TCP/IP Tujuan 1).Untuk menguji interoperabilitas antara beberapa ORB yang berbeda pada aplikasi terdistribusi. 2).Mengamati kecepatan operasi name lookup dan remote method invocation. 2. Tinjauan Pustaka 2.1. Common Request Broker (CORBA) Standard CORBA mendefinisikan suatu set komponen yang memungkinkan aplikasi client untuk melakukan invokasi operasi (op) dengan argument (args) pada implementasi obyek. Implementasi obyek dapat dikonfigurasi untuk berjalan secara lokal atau remote tanpa mempengaruhi implementasi atau fungsinya.[ Transparansi merupakan peranan kunci pada CORBA, yang terdiri dari dua macam,yaitu transparansi lokasi dan transparansi bahasa pemrograman[bao,2004:2]. Transparansi lokasi berarti bila suatu client melakukan pemanggilan obyek nonlokal maka hanya akan tampak seperti memanggil obyek lokal yang berada pada ruang alamat yang sama. Transparansi bahasa pemrograman mengindikasikan bahwa obyek yang dipanggil dapat diimplementasikan dengan bahasa pemrograman yang bebas tanpa harus diketahui oleh client. Transparansi lokasi diimplementasikan melalui suatu kode stub yang dibangkitkan oleh kompiler. Stub merupakan delegasi dari client dan bertanggung jawab untuk menemukan lokasi dari obyek yang dipanggil, dan juga untuk melewatkan parameter serta respon balik ke ORB. Transparansi bahasa dilakukan melalui maping bahasa yang terjadi ketika menjalankan IDL compiler[vinosky,1997:35]. Skeleton dan mapping bahasa yang lain, dihasilkan di sisi obyek, yang mungkin juga dilakukan oleh IDL compiler yang berbeda. Skeleton melakukan kebalikan dari apa yang dilakukan oleh stub. Gambar 1. menjelaskan komponen-komponen utama pada arsitektur CORBA. Fungsi dari komponen tersebut adalah: [ - Obyek Implementation: Mendefinisikan operasi yang mengimplementasikan suatu interface CORBA IDL. - Client: Melakukan invokasi operasi pada implementasi obyek.

2 - Obyek Request Broker(ORB): Jika suatu client melakukan invokasi terhadap suatu operasi, ORB bertanggung jawab untuk menemukan implementasi obyek, jika diperlukan akan sekaligus mengaktifkannya secara transparan, mengirimkan permintaan ke sebuah obyek, dan mengirimkan response dari server kembali ke client. - ORB Interface: Merupakan entitas yang bisa diimplementasikan dengan beberapa cara (satu atau lebih proses, atau satu set pustaka) - CORBA IDL stub dan skeleton: Beberapa aplikasi menggunakan IDL stub dan skeleton dalam CORBA Static Invocation Interface (SII). Komponen SII ini berfungsi sebagai penghubung antara aplikasi client dan server serta ORB. - Dinamic Invocation Interface (DII): Interface ini mengijinkan suatu client untuk mengakses secara langsung mekanisme request yang disediakan oleh ORB. - Dinamic Skeleton Interface (DSI): Merupakan analogi DII sisi client pada suatu server. - Obyek Adapter: Berfungsi mengasosiasikan implementasi obyek dengan ORB dan mengijinkan ORB dengan requestnya untuk mengaktifkan sebuah obyek. DII client IDL STUB ORB interface IDL skeleton Implementation DSI Adapter pakai, Kedua, portabilitas aplikasi ditingkatkan dengan menggunakan class-class yang sama disemua lingkungan pemrograman yang mendukung spesifikasi OMG. Fasilitas-fasilitas CORBA mendefinisikan layanan tingkat aplikasi yang menyediakan framework yang generik dan bangunan aplikasi level tinggi untuk penggunaan sistem berbasis CORBA. Dua macam fasilitas CORBA adalah fasilitas horisontal dan fasilitas vertikal. Fasilitas horisontal diintensifkan untuk kebutuhan domain aplikasi yang independen, seperti compound document, manajemen sistem, internasionalisasi, antarmuka user dan proses kerja. Fasilitas vertikal didisain untuk keperluan khusus seperti medikal dan finansial. 3. Pengujian Skenario dari interaksi antar obyek melalui integrasi beberapa ORB dijelaskan seperti dalam gambar 2. interface client name services Remote object RMI-IIOP (java) MICO (C++) omniorb (C++) java/idl tnameserv nsd (MICO) OmniNames Gambar 2. Skenario pengujian RMI-IIOP (java) MICO (C++) omniorb (C++) java/idl Tidak semua implementasi CORBA yang ada saat ini non-komersial, sehingga dalam artikel ini penulis memilih menggunakan implementasi CORBA yang bisa di peroleh secara gratis. Langkah dalam menyusun suatu aplikasi yang mengimplementasikan CORBA ditunjukkan dalam gambar 3. IDL Definition Request Broker Gambar 1. Arsitektur CORBA *) Dalam gambar 1. ditunjukkan kode stub, ORB dan kode skeleton. ORB (RequestBroker) adalah Software Bus atau semacam saluran yang digunakan bersama-sama oleh client dan server untuk pertukaran obyek. ORB menyimpan jalur pemanggilan dari obyek nonlokal pada server dan membuat lokal obyek tersedia sebagai server. Suatu ORB tidak berjalan seperti layaknya server standar, tetapi berada pada lapisan middleware yang sebagian berada pada client (stub) dan sebagian yang lain berada pada sisi server (skeleton). Layanan CORBA mendefinisikan layanan pada tingkat sistem yang ditambahkan pada ORB, seperti keamanan (security), penamaan (naming), dan transaksi. Layanan CORBA berguna pada dua aspek berikut; pertama, meningkatkan produktifitas pemrogram dengan menyediakan class yang siap Client Program Source Stub Source Java/C++ Compiler Client Program IDL Compiler Skeleton Source Java/C++ Compiler Implementation Implementation Source Gambar 3. Langkah penyusunan aplikasi CORBA *)[Harkey,1999:21] 3.1. Kebutuhan system Beberapa perangkat lunak/keras yang digunakan adalah: 1)Compiler C++, digunakan gcc versi 3.0 2)Perangkat lunak ORB, yaitu omniorb 4.0.3, MICO dan Java/IDL (JDK1.4.2) 3)System Operasi Windows dan linux kernel 2.4 4)Komputer Pentium III dan Pentium 233

3 3.2. Pengkodean Langkah awal yang dilakukan adalah menyusun kode untuk Interface Definition Language (idl). File ini merupakan deklarasi dari frame implementasi object yang akan digunakan dalam aplikasi (invokasi oleh client). Server akan menyiapkan implementasi detil dari obyek-obyek yang nantinya akan di publikasikan melalui naming service sehingga bisa di akses dari sisi client. File idl yang akan digunakan didefinisikan seperti berikut ini: interface Hello string say_h(in string client); }; interface SiswaBayar boolean Kerja(); long getnomersiswa(); } public interface Acc extends java.rmi.remote float getsaldo(); string gettipe(); double getbatas(); } public interface Kertu extends java.rmi.remote int getnomer(); } Semua mempunyai nilai kembalian dengan tipe tertentu. Tidak ada parameter, dan tidak melakukan proses. Tujuannya untuk mengukur kinerja dari arsitektur sistem terdistribusi. Tipe data yang digunakan; integer, long, float, double, boolean dan string dalam beberapa ukuran. Mekanisme diatas akan diterapkan pada masing-masing ORB. Menjalankan Program Bagian ini menjelaskan bagaimana menjalankan program-program dalam konfigurasi yang berbeda. Sebenarnya ada banyak konfigurasi tapi tidak semua akan ditunjukkan. Ada tiga Naming Server (untuk setiap ORB), tiga server, dan juga tiga client. Konfigurasi yang dilakukan disini adalah: 1) Naming Server: omniorb, Server: omniorb, Client: omniorb/mico/java 2) Naming Server: omniorb, Server: MICO, Client: omniorb/mico/java 3) Naming Server: MICO, Server: omniorb, Client: omniorb/mico 4): Naming Server: tnameserv, Server: omniorb, Client: omniorb/mico Cara menjalankan Naming Service masing-masing ORB: omniorb(default port: 2809) $ omninames -logdir /tmp -start MICO $ nsd -ORBIIOPAddr inet:localhost:2809 Java $tnameserv -ORBInitialPort 2809 Cara menjalankan Server masingmasing ORB: omniorb/mico $./server -ORBInitRef NameService=corbaloc::localhost:2809/Na meservice Cara menjalankan client masingmasing ORB: omniorb/mico/java $./client -ORBInitRef NameService=corbaloc::localhost:2809/Na meservice $ java client -ORBInitRef NameService=corbaloc::localhost:2809/Na meservice 4. Pembahasan Introperabilitas Cukup banyak konfigurasi yang bisa dilakukan untuk memilih implementasi server dan client dari keempat tehnologi yang dipilih, tetapi tidak semua mendukung interoperasi satu dengan yang lain. Konfigurasi yang bisa dilakukan ditunjukkan dalam table 1. Sebagai implementasi standard CORBA diharapkan JavaIDL, RMI-IIOP, MICO dan omniorb bisa kompatibel satu dengan yang lain. Komunikasi antara RMI-IIOP dengan JavaIDL dikondisikan dengan membuka akses dari client terhadap class stub dari server obyek dan sebaliknya. Tabel 1. Interoperasi dengan Naming Service tnameserv client/serve r RMI - JavaID L omnior B MIC O IIOP RMI-IIOP JavaIDL omniorb MICO Tabel 2. Interoperasi dengan Naming Service nsd client/serve r RMI - IIOP JavaID L omnior B MIC O RMI-IIOP x x x x JavaIDL x x x x omniorb x x MICO x x Tabel 3. Interoperasi dengan Naming Service omninames client / server RMI- JavaIDL omniorb MICO IIOP RMI-IIOP JavaIDL omniorb MICO

4 Kinerja Sistem Pengamatan bertujuan untuk mengukur kinerja yang terjadi pada proses invokasi dan penurunan kinerja sistem pada jumlah client yang banyak. Sehingga perlu dilakukan beberapa skenario untuk komunikasi antara obyek server dengan obyek client. Hal yang diperlukan untuk melakukan test adalah sebagai berikut; (a)hasil yang didapat bisa dibandingkan dengan sistem lain (b)skenario untuk client tunggal dan banyak client harus disimulasikan. (c)digunakan tipe data yang berbeda-beda. Article I. Metode Pengujian Dilakukan simulasi interaksi antara objek client dan server, yang banyak dijumpai pada aplikasi client/server. Sisi client akan melakukan koneksi ke server obyek dan melakukan invokasi pada server. Potongan program ditunjukkan pada listing dibawah ini. Mekanisme invokasi static yang digunakan adalah dua arah. Untuk simulasi transfer tipe string yang besar diukur waktu tanggapan untuk tiap ukuran string. Method Acc.getTipe() mengembalikan string dengan jumlah karakter 1, 1000, 2000, 3000, 4000, 5000 dan String acc_tipe = "1"; Acc_ku.setTipe(acc_tipe); for(int j=0;j<15;j++) long awaltime=system.currenttimemillis(); for (d=0;d<jml_iter;d++) acc_tipe=acc_ku.gettipe(); long akhirtime=system.currenttimemillis(); tmessage.append("waktu yang dipakai"+(akhirtime-awaltime)+"\n"); } Gambar 4. Penghitungan waktu pada sisi client (java) Waktu diukur dengan System.currentTimeMillis(), yang mengembalikan nilai waktu dalam milidetik. Untuk mendapatkan nilai pengukuran yang lebih baik maka semua invokasi diulang seribu kali. Hasil yang dilaporkan adalah rata-rata nilai lima belas repetisi. Tes dieksekusi dalam tiga skenario: (a) Objek Server dan client berjalan pada komputer yang sama. (b) Objek Server dan client berjalan pada komputer yang terpisah (c) Objek Server berjalan pada satu komputer, client secara simultan dieksekusi dari 1, 2, dan 3 client. Hasil dari (a) dan (b) menunjukkan kinerja sistem dalam jaringan, sedangkan perbandingan dari (b) dan (c) menunjukkan penurunan kinerja pada jumlah client yang semakin banyak. Article II. Kinerja Untuk Client Tunggal Didapatkan dari skenario tes berikut ini: (1) Server dan Client berjalan pada komputer yang sama, dan (2) Server dan Client berjalan pada komputer terpisah. Tes dilakukan berulang untuk: (a) Tipe data dasar (boolean, integer, long, float, double, 1 character string) (b) Tipe Strings dalam ukuran yang berbeda. Tabel 4. dan 5. menunjukkan hasil pengukuran waktu invokasi untuk server RMI-IIOP dan client omniorb, MICO, javaidl. Tabel 4. Waktu Invokasi Untuk Skenario Satu Client Dengan Tipe Data Dasar Tipe Data Waktu (milidetik) javaidl omniorb MICO Double 1,423 1,02 1,03 Float 1,4 1,02 1,0 Long 1,416 1,04 1,002 Integer 1,398 0,96 0,98 Boolean 1,399 0,9 0,99 String (1 karakter) 2,11 1,61 1,5 Tabel 5. Hasil Waktu Untuk Skenario Satu Client Dengan Ukuran String Berbeda Ukuran Waktu (milidetik) String javaidl omniorb MICO 1 2,10 1,59 1, ,57 10, ,72 19,3 19, ,12 30,7 30, ,82 40,8 40, ,89 51,02 51, ,67 99,6 99,1 Tabel 4. menunjukkan waktu yang dibutuhkan dari enam macam method untuk mengembalikan tipe-tipe data dasar. Hasil untuk boolean, integer, long, float dan double sangat dekat nilainya. Pada table 4. waktu rata-rata adalah 1.52(java), 1.09(omniORB) dan 1,08(MICO) milidetik. Hanya method dengan kembalian tipe string yang membutuhkan waktu lebih panjang, yaitu 2.11 (java), 1,6 (omniorb) dan 1,5 (MICO) milidetik. Pada Tabel 5. menunjukkan hasil untuk variasi ukuran string, waktu rata-rata adalah 38.55(java), 36,17(omniORB) dan 36,10(MICO) milidetik. Kinerja untuk scenario client server berjalan pada computer terpisah memberikan statistic hasil yang konsisten secara umum, perbedaan yang terjadi adalah waktu yang lebih panjang karena pengaruh proses pada protocol dibawahnya. Kinerja Dengan Banyak client Pada skenario banyak client tujuannya adalah mengamati penurunan kinerja pada jumlah client yang semakin banyak. Waktu invokasi untuk tiap client meningkat dengan pertambahan jumlah client. Dengan tiga client waktu rata-rata invokasi bertambah sekitar 36,4% dibandingkan dengan client tunggal, data 1 karakter string memerlukan waktu yang lebih lama dari tipe-tipe data dasar yang lain.

5 Tabel 6. Hasil Waktu Untuk Skenario Tiga Client Dengan Tipe Data Berbeda Tipe Data Jumlah Client Boolean 2,2 ms 2,7 ms 3 ms Integer 2,2 ms 2,7 ms 3 ms Long 2,2 ms 2,7 ms 3 ms Float 2,2 ms 2,7 ms 3 ms Double 2,2 ms 2,7 ms 3 ms String (1 Karakter) 2,5 ms 2,9 ms 3,3ms Tabel 7. Hasil Waktu Untuk Skenario Tiga Client Dengan Ukuran String Berbeda Ukuran Jumlah Client String ,5 ms 2,7 ms 3 ms ms 20 ms 22 ms ms 37 ms 39 ms ms 50 ms 53 ms ms 63 ms 65 ms ms 78 ms 83 ms ms 151ms 157 ms Dalam tabel 7. ditunjukkan waktu untuk invokasi method string secara linier tergantung pada ukuran string. Invokasi terdistribusi secara signifikan lebih lambat dari pada pemanggilan secara normal dalam satu mesin virtual. Ini disebabkan aliran data terdistribusi yang kompleks, antara lain karena proses seperti marshalling dan demarshalling. Pada RMI, array diserialisasi, sehingga panjang array ditulis terlebih dahulu baru kemudian masingmasing elemen diserialisasi. Serialisasi array dilakukan dengan merujuk pada spesifikasi serialisasi. Untuk tipe data Float dan Double selalu sedikit lebih lambat dari pada int/long dan long/long long, ini karena pada proses (de)multiplexing dimana nilai floating point pertama akan dikonversi ke integer menggunakan floattointbits() dan doubletointbits() untuk multiplexing, sedangkan intbitstofloat() dan intbitstodouble() untuk demultiplexing. Setelah itu baru akan diproses seperti pada int/long dan long/long long. Pengujian client dan server dieksekusi beberapa kali dengan jumlah iterasi berbeda untuk operasi name lookup dan pemanggilan remote method. Nilai iterasi dibuat dalam jangkauan nilai dari 1 sampai dengan perkalian kelipatan 10. Hasil yang dilaporkan disini dipilih dari proses dengan repetisi terbanyak. Tiga aspek yang dibahas dari hasil yang didapat adalah variasi dalam pengukuran, durasi proses name lookup, dan durasi pemanggilan obyek remote. Variasi dalam pengukuran Pengukuran difokuskan pada durasi operasi. Menjalankan program dengan jumlah Iterasi berbeda dalam kelipatan sepuluh, akan memperlihatkan operasi awal berjalan lebih lambat dari pada operasi berikutnya. Tabel dibawah ini memperlihatkan durasi rata-rata dari operasi lookup dan remote call yang diukur dengan jumlah repetisi yang bervariasi. Konfigurasi yang dipilih adalah RMI-IIOP untuk server dan JavaIDL untuk client, konfigurasi yang lain memberikan statistic yang cukup konsisten. Tabel 8. Rata-rata durasi untuk Operasi Lookup Iterasi Total Waktu Rata-rata Durasi , , , , ,08 Tabel 9. Rata-rata durasi untuk Operasi Pemanggilan Method Iterasi Total Waktu Rata-rata Durasi , , , ,29 Untuk kedua operasi diatas terlihat bahwa operasi pertama secara signifikan lebih lambat dari pada operasi berikutnya. Untuk Name Lookup, durasi operasi berkisar 1 milidetik dengan jumlah iterasi yang banyak. Pada iterasi 11, jika durasi operasi pertama dikurangi dengan total durasi dan rata-rata sisa operasi remote call yang lain dirata-rata, maka akan didapat nilai sekitar 3 milidetik untuk setiap operasi remote call. Nilai tersebut masih lebih besar dari 1 milidetik yang didapat dari nilai terakhir. Pengulangan operasi ini untuk baris yang lain akan memperlihat durasi name lookup yang menurun perlahan menuju nilai sekitar 1 milidetik, hal ini menunjukkan bahwa meskipun operasi awal lebih lambat, ada interferensi eksternal yang memperlambat proses komunikasi. Durasi NameLookup Tabel dibawah memperlihatkan pengukuran durasi name lookup dengan iterasi , yang juga memberi informasi bahwa durasi operasi lookup juga dipengaruhi tehnologi yang dipergunakan pada client. Konfigurasi yang melibatkan implementasi C++ CORBA secara konsisten memberikan hasil waktu yang lebih cepat dari pada yang lain. Durasi Pemanggilan Remote Method Tabel dibawah memberikan informasi hasil pengukuran durasi pemanggilan remote method untuk konfigurasi iterasi. Waktu eksekusi tergantung dari tehnologi yang diterapkan pada server. Konfigurasi dengan melibatkan omniorb

6 atau MICO sebagai server secara signifikan lebih cepat dari pada konfigurasi yang lain. Kecepatan tersebut karena implementasinya menggunakan C++ sehingga program tersebut bersifat native dan teroptimasi, berbeda dengan java yang menerapkan interpreter byte code. Tabel 10. Durasi rata-rata per proses Name Lookup Dalam Milidetik Client Server Rata-rata durasi tiap Lookup omniorb Java IDL 1.01 MICO Java IDL RMI-IIOP Java IDL 2,6 Java IDL Java IDL 1,42 omniorb RMI-IIOP 1,03 MICO RMI-IIOP 1,05 RMI-IIOP RMI-IIOP 2,52 Java IDL RMI-IIOP 1,43 omniorb omniorb 0,93 MICO omniorb 0,9 RMI-IIOP omniorb 1,89 Java IDL omniorb 1,35 omniorb MICO 0,922 MICO MICO 0,901 RMI-IIOP MICO 1,9 Java IDL MICO 1,83 Tabel 11. Durasi rata-rata per proses Remote Call dalam milidetik. Client Server Rata-rata durasi tiap remote call (client) Rata-rata durasi tiap remote call (server) omniorb Java IDL 0,69 0,0096 MICO Java IDL 0,68 0,0097 RMI-IIOP Java IDL 0,988 0,011 Java IDL Java IDL 0,997 0,011 omniorb RMI-IIOP 0,71 0,0094 MICO RMI-IIOP 0,7 0,0095 RMI-IIOP RMI-IIOP 1,033 0,01 Java IDL RMI-IIOP 1,004 0,009 omniorb omniorb 0,162 0,002 MICO omniorb 0,16 0,002 RMI-IIOP omniorb 0,273 0,0028 Java IDL omniorb 0,3085 0,0032 omniorb MICO 0,163 0,0021 MICO MICO 0,164 0,0021 RMI-IIOP MICO 0,26 0,0027 Java IDL MICO 0,29 0,0028 Hasil lain yang bisa diamati adalah meskipun Implementasi obyek mengeksekusi kode yang sama pada semua konfigurasi, durasi waktu yang dihasilkan dipengaruhi oleh ORB yang digunakan. 5. Penutup 5.1. Kesimpulan Dari hasil pengujian dan pembahasan maka dapat disimpulkan: 1) MICO Naming Service (nsd) tidak interoperable dengan java. 2) Integrasi implementasi CORBA dengan MICO, omniorb, Java IDL, RMI-IIOP bisa dilakukan. 3) Waktu yang dibutuhkan untuk proses remote method call pada Java server oleh client dengan Implementasi CORBA C++ rata-rata 30% lebih cepat dibandingkan Implementasi CORBA menggunakan Java. 4) Rata-rata waktu proses remote call pada server dibawah 0,01 milidetik 5) Terjadi peningkatan waktu invokasi ratarata 26,6% untuk setiap penambahan jumlah client Saran Dalam pengembangan aplikasi CORBA perlu dipertimbangkan masalah biaya (lisensi), dimana walaupun hasil percobaan menunjukkan bahwa implementasi ORB menggunakan java memberikan hasil yang tidak lebih bagus dari pada C++ tetapi java didistribusikan secara bebas, sedangkan implementasi C++ kebanyakan tidak (komersil). Dari sisi pengalaman, pengembangan menggunakan tool dan bahasa pemrograman serta platform yang sudah dikenal akan memberikan hasil yang lebih baik dan cepat dari pada menggunakan platform baru yang membutuhkan waktu untuk penyesuaian. 6. Daftar Pustaka Harkey O.,1999, Client/server programming with Java and Corba, John Wiley AT&TCambridgeLaboratoryhttp:// att.com/omniorbor omniorb.sourceforge.net. JavaTM Remote Method Invocation Documentation, JavaTM 2 SDK, Standard Edition Documentation, Management Group CORBA Services Specification, Java 2 RMI and IDL Comparison, RMI-IIOP Programmer's Guide, iiop pg.html Java RMI & CORBA A comparison of two competing technologies, eebreak.com/articles/rmi corba/ BAO RuiXian, Distributed Computing via RMI and CORBA, University of Helsinki, Maret 2004 Qusay H.Mahmoud, 1999, Distributed Programing with Java, Manning, Greenwich

7