PERBANDINGAN PENGGUNAAN 4 ORB BERBEDA PADA APLIKASI OBYEK TERDISTRIBUSI

Prosiding SENTIA 2009 – Politeknik Negeri Malang

PERBANDINGAN PENGGUNAAN 4 ORB BERBEDA PADA APLIKASI OBYEK TERDISTRIBUSI Pranoto Suryo Hadi Teknik Elektro Politeknik Negeri Malang [email protected], [email protected] ABSTRAK CORBA (Common Object 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 (ObjectRequestBroker). 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 Object 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. 1.2. 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 Object 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.[www.omg.org/library] 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: [www.org.omg] - Obyek Implementation: Mendefinisikan operasi yang mengimplementasikan suatu interface CORBA IDL. - Client: Melakukan invokasi operasi pada implementasi obyek.

Prosiding SENTIA 2009 – Politeknik Negeri Malang

- 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. Object Implementation

client

DII

IDL STUB

ORB interface

IDL skeleton

DSI

Object 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)

tnameserv

RMI-IIOP (java)

MICO (C++) omniORB (C++)

nsd (MICO)

MICO (C++)

OmniNames

omniORB (C++)

java/IDL

java/IDL

Gambar 2. Skenario pengujian 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

Object Request Broker IDL Compiler

Gambar 1. Arsitektur CORBA *)http://www.omg.org/library/csindex.html Dalam gambar 1. ditunjukkan kode stub, ORB dan kode skeleton. ORB (ObjectRequestBroker) 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

Skeleton Source

Java/C++ Compiler

Java/C++ Compiler

Client Program

Object Implementation

Object 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 2.3.7 dan Java/IDL (JDK1.4.2) 3)System Operasi Windows dan linux kernel 2.4 4)Komputer Pentium III dan Pentium 233

Prosiding SENTIA 2009 – Politeknik Negeri Malang

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:

$tnameserv -ORBInitialPort 2809

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(); }

$ ./client -ORBInitRef NameService=corbaloc::localhost:2809/Na meService $ java client -ORBInitRef NameService=corbaloc::localhost:2809/Na meService

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

Cara menjalankan Server masingmasing ORB: omniORB/MICO $ ./server -ORBInitRef NameService=corbaloc::localhost:2809/Na meService

Cara menjalankan client masingmasing ORB: omniORB/MICO/Java

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 RMI JavaID omniOR MIC r L B O IIOP RMI-IIOP √ √ √ √ JavaIDL √ √ √ √ omniORB √ √ √ √ MICO √ √ √ √ Tabel 2. Interoperasi dengan Naming Service nsd client/serve r

RMI JavaID omniOR MIC L B O IIOP 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 / RMI- JavaIDL omniORB MICO server IIOP RMI-IIOP √ √ √ √ JavaIDL √ √ √ √ omniORB √ √ √ √ MICO √ √ √ √

Prosiding SENTIA 2009 – Politeknik Negeri Malang

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 10000. 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 2,11 1,61 1,5 (1 karakter) 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,6 1.000 12,57 10,2 10 2.000 22,72 19,3 19,5 3.000 33,12 30,7 30,4 4.000 42,82 40,8 40,3 5.000 52,89 51,02 51,2 10.000 103,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.

Prosiding SENTIA 2009 – Politeknik Negeri Malang

Tabel 6. Hasil Waktu Untuk Skenario Tiga Client Dengan Tipe Data Berbeda Tipe Data Jumlah Client 1 2 3 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 2,5 ms 2,9 ms 3,3ms (1 Karakter) Tabel 7. Hasil Waktu Untuk Skenario Tiga Client Dengan Ukuran String Berbeda Ukuran Jumlah Client String 1 2 3 1 2,5 ms 2,7 ms 3 ms 1000 19 ms 20 ms 22 ms 2000 33 ms 37 ms 39 ms 3000 49 ms 50 ms 53 ms 4000 62 ms 63 ms 65 ms 5000 75 ms 78 ms 83 ms 10000 148 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 60000 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 Menjalankan program dengan jumlah

operasi.

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 1 11 111 1111 11111 111111

Total Waktu 209 242 579 2993 13925 122941

Rata-rata Durasi 209 21,7 5,25 2,72 1,25 1,08

Tabel 9. Rata-rata durasi untuk Operasi Pemanggilan Method Iterasi 1 20 300 4000 50000 600000

Total Waktu 10 30 320 2200 15310 169286

Rata-rata Durasi 10 1,5 1,07 0.53 0,32 0,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 111111, 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 60000 iterasi. Waktu eksekusi tergantung dari tehnologi yang diterapkan pada server. Konfigurasi dengan melibatkan omniORB

Prosiding SENTIA 2009 – Politeknik Negeri Malang

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

omniORB MICO RMI-IIOP Java IDL omniORB MICO RMI-IIOP Java IDL omniORB MICO RMI-IIOP Java IDL omniORB MICO RMI-IIOP Java IDL

Java IDL Java IDL Java IDL Java IDL RMI-IIOP RMI-IIOP RMI-IIOP RMI-IIOP omniORB omniORB omniORB omniORB MICO MICO MICO MICO

Rata-rata durasi tiap Lookup 1.01 1.003 2,6 1,42 1,03 1,05 2,52 1,43 0,93 0,9 1,89 1,35 0,922 0,901 1,9 1,83

Tabel 11. Durasi rata-rata per proses Remote Call dalam milidetik. Client

omniORB MICO RMI-IIOP Java IDL omniORB MICO RMI-IIOP Java IDL omniORB MICO RMI-IIOP Java IDL omniORB MICO RMI-IIOP Java IDL

Server

Java IDL Java IDL Java IDL Java IDL RMI-IIOP RMI-IIOP RMI-IIOP RMI-IIOP omniORB omniORB omniORB omniORB MICO MICO MICO MICO

Rata-rata durasi tiap remote call (client) 0,69 0,68 0,988 0,997 0,71 0,7 1,033 1,004 0,162 0,16 0,273 0,3085 0,163 0,164 0,26 0,29

Rata-rata durasi tiap remote call (server) 0,0096 0,0097 0,011 0,011 0,0094 0,0095 0,01 0,009 0,002 0,002 0,0028 0,0032 0,0021 0,0021 0,0027 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. 5.2. 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://www.uk.research. att.com/omniORBor omniORB.sourceforge.net. JavaTM Remote Method Invocation Documentation, http://java.sun.com/docs/guide/rmi/index.html JavaTM 2 SDK, Standard Edition Documentation, http://java.sun.com/j2se/1.4.2/docs/index.html Object Management Group CORBA Services Specification, http://www.omg.org/library/csindx.html Java 2 RMI and IDL Comparison, http://lisa.unimb.si/»juric/J2rmiidlc.pdf RMI-IIOP Programmer's Guide, http://java.sun.com/j2se/1.4.2/docs/guide/rmiiiop/rmi iiop pg.html Java RMI & CORBA A comparison of two competing technologies, http://www.javaco®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

Prosiding SENTIA 2009 – Politeknik Negeri Malang