PERBANDINGAN PENGGUNAAN 4 ORB BERBEDA PADA APLIKASI OBYEK TERDISTRIBUSI

(1)

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.

(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.

Object Request Broker DII

client Object Implementation

IDL

STUB ORB interface

Object Adapter IDL

skeleton DSI

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

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.

RMI-IIOP (java) omniORB (C++) MICO (C++) tnameserv OmniNames nsd (MICO) interface RMI-IIOP (java) omniORB (C++) MICO (C++) client name services Remote object

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

Client Program

Source

Stub Source Skeleton Source Object Implementation Source Client Program Object Implementation IDL Compiler Java/C++ Compiler Java/C++ Compiler

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

(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 masing-masing ORB:

omniORB/MICO

$ ./server -ORBInitRef

NameService=corbaloc::localhost:2809/Na meService

Cara menjalankan client masing-masing ORB:

omniORB/MICO/Java

$ ./client -ORBInitRef

$ java client -ORBInitRef

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 -IIOP JavaID L omniOR B MIC O 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-IIOP

JavaIDL omniORB MICO

RMI-IIOP √ √ √ √

JavaIDL √ √ √ √

omniORB √ √ √ √

(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 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 (1 karakter) 2,11 1,61 1,5

Tabel 5. Hasil Waktu Untuk Skenario Satu Client Dengan Ukuran String Berbeda

Ukuran String

Waktu (milidetik)

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.

(5)

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 (1 Karakter) 2,5 ms 2,9 ms 3,3ms

Tabel 7. Hasil Waktu Untuk Skenario Tiga Client Dengan Ukuran String Berbeda

Ukuran String Jumlah Client 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 masing-masing 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 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

1 209 209 11 242 21,7 111 579 5,25 1111 2993 2,72 11111 13925 1,25 111111 122941 1,08

Tabel 9. Rata-rata durasi untuk Operasi Pemanggilan Method

Iterasi Total Waktu Rata-rata Durasi

1 10 10 20 30 1,5 300 320 1,07 4000 2200 0.53 50000 15310 0,32 600000 169286 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

(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 1.003

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 rata-rata 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.uni-mb.si/»juric/J2rmiidlc.pdf RMI-IIOP Programmer's Guide,

http://java.sun.com/j2se/1.4.2/docs/guide/rmi-iiop/rmi iiop pg.html

Java RMI & CORBA A comparison of two competing technologies,

http://www.javaco®eebreak.com/articles/rmi