SISTEM TERDISTRIBUSI

Inayatul Ummah – 207700398 – IFB/VII

Teknik Informatika
Universitas Islam Negeri Sunan Gunung Djati
Bandung

REMOTE PROCEDURE CALL (RPC) Sehingga pemrogram dapat berkonsentrasi pada

software logic, tidak perlu memikirkan low  level details
Adalah sebuah metode yang memungkinkan
seperti  socket, marshalling & unmarshalling.
kita untuk mengakses sebuah prosedur yang berada di
 Robust (Sempurna):
komputer lain. Untuk dapat melakukan ini sebuah 
Sejak th 1980-an RPC telah banyak digunakan dlm
server harus menyediakan layanan  remote procedure.
pengembangan mission- critical application yg
Pendekatan yang dilakuan adalah sebuah  server
memerlukan scalability, fault tolerance, & reliability.
membuka  socket, lalu menunggu client yang meminta
Kekurangan RPC
prosedur yang disediakan oleh server. Bila client tidak
 Tidak fleksibel terhadap perubahan:
tahu haruS menghubungi  port yang mana,  client bisa
Static relationship between client & server at run-
me-request kepada sebuah  matchmaker pada sebuah
time.
RPC  port yang tetap.  Matchmaker akan memberikan 
 Berdasarkan prosedural/structured
port apa yang digunakan oleh prosedur yang diminta
programming yang sudah ketinggalan
client.
jaman dibandingkan OOP.
RPC masih menggunakan cara primitif dalam
Struktur Protokol Message RPC
pemrograman, yaitu menggunakan paradigma
 Call Message
procedural programming. Hal itu membuat kita sulit
a. Dilakukan oleh klien, dimana meminta server
ketika menyediakan banyak  remote procedure. RPC
untuk mengeksekusi suatu prosedur.
menggunakan  socket untuk berkomunikasi dengan
b. Terdapat nilai-nilai unsigned integer yang
proses lainnya. Pada sistem seperti SUN, RPC secara
digunakan untuk mengidentifikasi
default sudah ter-install kedalam sistemnya, biasanya
prosedurremote yang diminta:
RPC  ini digunakan untuk administrasi sistem. Sehingga
1. Nomor Program
seorang administrator jaringan dapat mengakses
2. Nomor Versi dari Program
sistemnya dan mengelola sistemnya dari mana saja,
3. Nomor Prosedur
selama sistemnya terhubung ke jaringan
 Reply Message
Kelebihan RPC
 Dikirimkan oleh server jaringan, bervariasi
 Relatif mudah digunakan :
tergantung apakah call messages yang diminta
Pemanggilan remote procedure tidak jauh
klien diterima atau ditolak.
berbeda dibandingkan pemanggilan procedure.
 Mengandung informasi:
1. RPM mengeksekusi call message dengan sukses. Prinsip RPC dalam program Client-Server
2. Implementasi remote tidak sesuai dengan
protokol yang digunakan (versi yang lebih tinggi
atau lebih rendah ditolak).
3. Program remote tidak tersedia pada sistem
remote.
4. Program remote tidak mendukung versi yang
diminta klien.
5. Nomor prosedur yang diminta tidak ada
Fitur dalam RPC
1. Batching Calls
Skema RPC ini dilakukan juga pada proses-
Mengijinkan klien untuk mengirim message calls
proses yang running di komputer  berlainan
ke server dalam jumlah besar secara berurutan.
2. Broadcasting Calls
Menijinkan klien untuk mengirimkan paket data
ke jaringan dan menunggu balasan dari network.
3. Callback Procedures
Mengijinkan server untuk bertindak sebagai klien
dan melakukan PRC callback ke proses yang
dijalankan klien.  Sebelum mekanisme RPC digunakan, data
4. Select Subrutin harus di-packaging ke dalam formattransimisi.
Memeriksa deskripsi suatu file dan messages Langkah ini dinamakan marshalling
dalamantrian untuk melihat apakah siap dibaca  Proxy bertanggung jawab untuk marshalling
atau ditulis,atau ditahan. (mengijinkan server data, kemudian mengirimkan data dan meminta
untuk menginterupsi suatu aktivitas. instans dari komponen (remote)
 Stub menerima request, unmarshall data, dan
memanggil method yang diminta. Kemudian
proses mengembalikan nilai yang diinginkan .
Langkah-langkah dalam RPC
  Callback ProcedureS: Fitur Callback
Procedures mengijinkan server untuk bertindak
sebagai
 Menggunakan select SubrutiN: Fitur ini akan
memeriksa deskripsi dari suatu file dan messages
dalamantrian untuk melihat apakah mereka siap
untuk dibaca (diterima) atauditulis (dikirim), atau
1. Prosedur client memanggil client stub.
mereka dalam kondisi ditahan sementara.
2. Client stub membuat pesan dan memanggil OS
Prosedurini mengijinkan server untuk
client.
menginterupsi suatu aktivitas, memeriksadatanya,
3. OS client mengirim pesan ke OS server.
dan kemudian melanjutkan proses aktivitas
4. OS server memberikan pesan ke server stub.
tersebut.
5. Server stub meng-unpack parameter-parameter
untuk memanggil server.
6. Server mengerjakan operasi, dan mengembalikan COMMON OBJECT REQUEST BROKER
hasilnya ke server stub. ARCHITECTURE (CORBA)
7. Server stub mem-pack hasil tsb dan memanggil OS
Interoperabilitas adalah kemampuan saling
server.
bekerjasama antar sistem komputer. Sebenarnya
8. OS server mengirim pesan (hasil) ke OS client.
interoperabilitas bukanlah barang baru, karena
9. OS client memberikan pesan tersebut ke client
protokol komunikasi datapun (TCP/IP misalnya) pada
stub
dasarnya diciptakan untuk mewujudkan
10. Client stub meng-unpack hasil dan
interoperabilitas. Yang belum banyak dikenal adalah
mengembalikan hasil tersebut ke client
interoperabilitas pada level perangkat lunak aplikasi.
Fitur dalam RPC
Dalam konteks sistem komputer terdistribusi,
 Batching Calls: Fitur Batching calls mengijinkan
meskipun komponen-komponen aplikasi dibuat dengan
klien untuk mengirim message calls ke server
bahasa pemrograman yang berbeda, menggunakan
dalam jumlah besar secara sequence ( berurutan )
development tools yang berbeda, dan beroperasi di
 Broadcasting Call: Fitur Broadcasting
lingkungan yang beragam, mereka tetap harus dapat
mengijinkan klien untuk mengirimkan paket data
saling bekerjasama.
kejaringan dan menunggu balasan dari network.
Interoperabilitas perangkat lunak menuntut
FItur ini menggunakanprotokol yang berbasiskan
homogenitas pada suatu level tertentu. Untuk itu
paket data seperti UDP/IP sebagai
diperlukan semacam 'standarisasi'. Berawal dari
mediumnya.Broadcast RPC membutuhkan
keperluan ini lahirlah CORBA (Common Object Request
layanan port mapper RPC
Broker Architecture). CORBA adalah hasil 'kesepakatan'
untukmengimplementasikanfung sinyA
antara sejumlah vendor dan pengembang perangkat
lunak terkenal seperti IBM, Hewlett-Packard, dan DEC,
yang tergabung dalam sebuah konsorsium bernama
OMG (Object Management Group).
CORBA adalah sebuah arsitektur software yang
berbasis pada teknologi berorientasi obyek atau Object
Oriented (OO) dengan paradigma client-server. Dalam
terminologi OO, sebuah obyek berkomunikasi dengan
obyek lain dengan cara pengiriman pesan (message
passing). Konteks komunikasi ini kemudian dipetakan
Gambar 1. Komunikasi dari client ke implementasi
ke dalam model client-server: satu obyek berperan
obyek
sebagai client (si pengirim pesan) dan yang lain
Tidak seperti pada lazimnya bahasa OO (C++
bertindak sebagai server (yang menerima pesan dan
atau Java), proses pengiriman pesan dari client ke
memroses pesan yang bersangkutan). Sebagai contoh,
implementasi obyek tidak dilakukan secara langsung.
dalam ilustrasi di awal tulisan ini, jika si pasien
Pertama, stub dan skeleton "mengisolasi" client dan
memerlukan obat tertentu, maka obyek aplikasi di
implementasi obyek dari tugas-tugas level rendah
tempat praktek dokter berlaku sebagai client dan
seperti proses marshalling dan unmarshalling data.
mengirim pesan ke obyek aplikasi di apotik guna
Selanjutnya ORB berfungsi sebagai "pialang" yang
mengetahui apakah obat yang diperlukan tersedia di
menjembatani heterogenitas antara kedua obyek. ORB
sana.
menangani perbedaan platform, pelacakan lokasi
Keunikan dari CORBA adalah kemampuannya
obyek, dan proses transfer pesan sedemikian rupa
dalam menangani heterogenitas antara client dan
sehingga transparan terhadap kedua obyek. Dengan
server (dalam terminologi CORBA, obyek server
demikian pemrograman client dan implementasi obyek
dinamakan implementasi obyek (object
bisa berkonsentrasi sepenuhnya pada aspek
implementation). Keduanya dapat saja
fungsionalitas keduanya.
diimplementasikan dalam hardware, sistem operasi,
Mekanisme yang ditunjukkan pada Gambar 1
bahasa pemrograman, dan di lokasi yang berbeda,
merupakan dasar operasi sistem berbasis CORBA.
tetapi tetap bisa saling berkomunikasi. Kuncinya ada
Sebagai contoh, dalam kasus si A di atas, program di
pada sebuah lapisan software yang disebut dengan
tempat praktek dokter bertindak sebagai client bagi
ORB(Object Request Broker). Arsitektur CORBA dan
program di rumah sakit. Bila si A perlu dirawat di rumah
ORBnya ditunjukkan pada gambar 1.
sakit, maka program sang dokter akan mengirimkan
pesan ke program di rumah sakit melalui ORB.
Menariknya, kedua program tersebut dapat
dikembangkan tanpa perlu banyak ikatan antara
keduanya, misalnya menggunakan bahasa
pemrograman apa, sistem operasi apa, dan sebagainya.
Cukup berangkat dari sebuah 'kesepakatan' yang ada kode program untuk fungsi checkHarga dan
dituangkan dalam sebuah interface (lihat bagian checkTersedia ! Perlu diingat bahwa interface hanya
tentang Pemrograman Berbasis CORBA), maka kedua menyatakan apa yang tersedia (aspek what), tidak
program tersebut bisa dikembangkan secara menyebutkan bagaimana menyediakannya (aspek
independen. how). Kita tidak akan membahas sintaks IDL dalam
Pemrograman Berbasis CORBA kesempatan ini. Fokus kita adalah bagaimana
Bagaimana mungkin dua obyek yang menggunakan spesifikasi interface yang dibuat dengan
dikembangkan secara terpisah, dengan perangkat dan IDL ini untuk membuat client dan implementasi obyek
bahasa yang berbeda, serta dijalankan di komputer dalam aplikasi.
yang berbeda pula bisa saling berkomunikasi? Apa yang Interface yang ditulis dengan IDL hanya
bisa "mempertemukan" perbedaan-perbedaan itu? merupakan kerangka bagi program client dan
Kuncinya adalah konsep tentang interface. Dalam implementasi obyek. Pemrogram masih harus mengisi
teknologi OO, interface dapat dikatakan sebagai "ikatan detil-detil keduanya sehingga membentuk program
kontrak" antara dua obyek yang akan berkomunikasi. yang utuh. Pada contoh interfacecheckObat di atas
Bagi obyek server, interface berfungsi sebagai "iklan" misalnya, fungsi-fungsi checkHarga dan checkTersedia
tentang apa saja yang bisa dikerjakannya. Bagi client, harus diimplementasikan.
interface berfungsi untuk mengetahui layanan-layanan Yang perlu diperhatikan dalam pemrograman
apa yang disediakan oleh server. Dalam CORBA, client dan implementasi obyek adalah bahasa
spesifikasi interface merupakan hal yang pertama kali pemrograman yang digunakan. Bahasa yang bisa
dilakukan, layaknya dalam kehidupan nyata di mana digunakan adalah yang memiliki pemetaan (mapping)
sebelum terjadi transaksi, dibuat dulu kontraknya. dengan IDL. Pemetaan ini menyebutkan ekuivalensi
Spesifikasi interface dibuat menggunakan sebuah tipe data, fungsi, dan konstruksi pemrograman IDL
bahasa khusus yang bersifat standar yang disebut lainnya dalam konstruksi pemrograman bahasa yang
Interface Definition Language (IDL). bersangkutan. Pada umumnya bahasa pemrograman
Sintaks IDL sendiri mirip dengan sintaks bahasa populer seperti C, C++, Java, Smalltalk, dan COBOL
C++. Berikut ini contoh sebuah spesifikasi interface telah memiliki pemetaan ini. Seperti telah dijelaskan di
untuk layanan yang disediakan oleh obyek aplikasi di depan, client dan implementasi obyek dapat
apotik. Ingat bahwa spesifikasi ini berlaku baik untuk menggunakan bahasa pemrograman yang berbeda.
client maupun implementasi obyek. Langkah selanjutnya adalah kompilasi program.
interface checkObat { Program client, implementasi obyek, dan spesifikasi
float checkHarga(in string namaObat); interface dikompilasi. Spesifikasi interface dikompilasi
boolean checkTersedia(in string namaObat); dengan kompiler IDL, menghasilkan kode stub (untuk
}; client) dan skeleton (untuk implementasi obyek). Tiap
Sekilas definisi di atas mirip dengan definisi kelas bahasa yang didukung memiliki kompiler IDL sendiri.
dalam C++. Perbedaan yang paling nyata adalah tidak Selanjutnya dilakukan proses linking untuk
menghasilkan program yang bisa dieksekusi. Proses ini dituntut untuk bisa berkomunikasi dengan ORB lainnya,
ditunjukkan oleh gambar 2 berikut ini. untuk memfasilitasi komunikasi antar program yang
Sampai sejauh ini kita bisa melihat bahwa IDL berjalan di atasnya.
menyelesaikan masalah heterogenitas dan distribusi Interoperabilitas dapat dilakukan secara efisien
lokasi obyek. Masih ada hal yang belum terpecahkan: dan sederhana dengan mengharuskan dua ORB untuk
bagaimana client dapat mengakses implementasi "berbicara" dengan protokol yang sama. Internet
obyek? Lazimnya dalam bahasa-bahasa pemrograman Interoperable Protocol (IIOP) adalah protokol standar
hal ini dilakukan melalui nama (pengidentifikasi) obyek. yang harus dimiliki ORB agar bisa disebut "selaras
Tapi bagaimana jika implementasi obyek terletak di dengan CORBA" (CORBA-compliant). Dengan kata lain,
komputer yang berbeda dan dibuat dengan bahasa IIOP adalah "bahasa komunikasi standar" bagi ORB.
yang berbeda pula? CORBA menggunakan referensi Interoperabilitas juga dapat dicapai melalui
obyek untuk tujuan ini. Tiap implementasi obyek penjembatanan (bridging). Penjembatanan
memiliki sebuah referensi obyek sebagai handle untuk memungkinkan komunikasi dilakukan oleh ORB dengan
mengakses dirinya. Referensi obyek dibuat oleh ORB protokol yang berbeda. Cara ini memberikan
pada saat obyek tersebut diciptakan, bersifat unik, dan keleluasaan kepada implementor apabila metode
tetap valid selama obyek tersebut ada. Referensi obyek pertama tidak mungkin atau sulit diterapkan, misalnya
juga menyembunyikan lokasi fisis dari obyek yang karena alasan tuntutan solusi komputasi yang paling
bersangkutan. Dengan referensi obyek, client dapat cost-effective. Kerugiannya, arsitektur sistem
mengakses sebuah implementasi obyek tanpa harus keseluruhan menjadi lebih kompleks karena diperlukan
mengetahui di mana persisnya lokasi obyek tersebut. jembatan-jembatan antar ORB.
Referensi obyek dapat dikirimkan ke aplikasi lain, Sepintas model ini terlihat rumit, tapi dari sisi
disimpan dalam basis data, atau diberikan kepada aplikasi tidak ada pengaruhnya sedikitpun.
seorang pelanggan untuk digunakan dalam Transparansi terjaga penuh, client tidak perlu tahu
programnya. sedikitpun apakah implementasi obyek terletak di
Interoperabilitas ORB lingkup ORB yang sama atau tidak. Jika tidak, ORBnya
Ruang lingkup komputasi berbasis CORBA tidak secara otomatis akan melemparkan pesannya ke ORB
hanya terbatas pada satu ORB saja. Antara satu ORB di mana implementasi obyek berada. Dalam contoh
dengan ORB yang lain bisa juga berkomunikasi. Model kasus kita, jika permintaan tentang suatu obat tidak
ini sangat bermanfaat untuk komputasi berskala bisa dipenuhi oleh obyek di apotik X, maka ORB di
enterprise dengan lingkup distribusi yang sangat luas. tempat itu dapat meneruskan pesan permintaan ini ke
Dalam situasi seperti ini, tidak mungkin untuk ORB di apotik Y misalnya.
menggunakan hanya satu ORB untuk setiap program OMA
yang ada. Pendekatan yang logis adalah dengan Sejauh ini, kita hanya membicarakan
melakukan clustering, dan sebuah cluster ditangani interoperabilitas pada level obyek. Pada kenyataannya,
oleh sebuah ORB. Dengan mekanisme ini, tiap ORB interoperabilitas pada level aplikasi jauh lebih
kompleks. Keterkaitan antara satu program dengan fasilitas: horizontal, yang diperlukan oleh berbagai jenis
program yang lain begitu beragam, hal ini menyulitkan domain (misalnya, user-interface), dan vertikal, yang
penyediaan dukungan yang lebih komprehensif secara berlaku khusus untuk domain tertentu (misalnya,
terstruktur. Dengan teknologi berbasis CORBA, OMG dalam kasus kita, domain kesehatan). Fasilitas
mencoba menuangkan visinya tentang aplikasi horizontal fungsinya mirip dengan layanan CORBA,
terdistribusi dalam sebuah arsitektur yang disebut tetapi beroperasi pada level yang lebih tinggi karena
Object Management Architecture (OMA). OMA berhubungan langsung dengan aspek fungsional dari
mengelompokkan jenis-jenis interaksi antar program aplikasi. OMG secara terus-menerus melakukan
untuk memudahkan penyediaan dukungan. Gambar 3 standarisasi terhadap interface untuk komponen-
menggambarkan konsep OMA. komponen di masing-masing kategori. Semakin banyak
layanan dan fasilitas yang distandarisasi, semakin
mudah untuk mencapai komputasi terdistribusi
berbasis komponen dalam berbagai bidang secara
plug-and-play, tanpa terganggu oleh masalah
heterogenitas.
CORBA di Linux
Gambar 3. Konsep Object Management Architecture
Dewasa ini cukup banyak perangkat
(OMA)
pengembangan berbasis CORBA yang dapat dijalankan
OMA melakukan strukturisasi dunia aplikasi ke
di sistem operasi Linux. Hampir semua paket hanya
dalam dua kelompok besar: kategori layanan CORBA
mendukung satu pemetaan bahasa saja, kecuali paket
(CORBA services) dan kategori fasilitas CORBA (CORBA
Inter-Language Unification (ILU) dari Xerox PARC yang
facilities). Layanan CORBA menyediakan fungsi-fungsi
mendukung beberapa bahasa sekaligus (ANSI C, C++,
dasar yang digunakan oleh hampir setiap obyek dalam
Python, Java, dsb). Tapi konsep ILU sendiri agak
berbagai aplikasi. Fungsi-fungsi ini biasanya bersifat
berbeda dengan CORBA, karena fokusnya adalah pada
generik dan tidak tergantung pada jenis domain
integrasi pada level bahasa pemrograman. Meskipun
aplikasi. Sebagai contoh adalah layanan penamaan
demikian, pendekatannya mirip, bahkan interface pada
(naming service). Bayangkan bila kita memerlukan
ILU dapat pula dispesifikasikan dengan menggunakan
sebuah layanan tapi tidak tahu ke mana harus mencari
IDL.
server yang menyediakan layanan tersebut. Layanan
Beberapa contoh perangkat pengembangan
penamaan dapat membantu kita layaknya sebuah
berbasis CORBA yang berjalan di Linux antara lain:
"halaman kuning" (yellow pages); dia bisa menyiarkan
MICO dari mico.org (bahasa yang didukung: C++),
direktori layanan yang terdaftar padanya. Karena
Fnorb dari DSTC, Australia (Python), JacORB oleh
sifatnya yang generik, layanan penamaan dapat
Gerard Brose dari Freie Universitat, Berlin (Java),
digunakan oleh aplikasi dari berbagai domain.
OmniORB2 dari AT&T (C++), serta tak ketinggalan pula
Fasilitas CORBA lebih tinggi levelnya. Ia
menyediakan layanan pada level aplikasi. Ada dua jenis
ORBit keluaran laboratorium riset RedHat (mendukung memanggil prosedur lokal, padahal argumen dari
bahasa C) yang dipakai dalam proyek Gnome. prosedur lokal tersebut dipaketkan dan dikirimkan ke
TAO (The ACE ORB) dari Washington University tujuan jarak jauh. Tapi RPC tidak bisa langsung dipakai
adalah implementasi ORB yang dikembangkan dengan dalam sistem objek terdistribusi. Dalam sistem objek
pendekatan yang berbeda. TAO tidak semata-mata terdistribusi, diperlukan komunikasi antara objek-objek
merupakan sistem ORB sederhana, tetapi ia dirancang yang ada di level program, yang berada dibanyak
untuk bekerja pada lingkungan real-time dengan tempat. Oleh karena itu, sistem objek terdistribusi
batasan-batasan (constraints) yang lebih ketat memerlukan suatu Remote Method Invocation (RMI).
dibandingkan dengan sistem terdistribusi biasa. Pada sistem yang memakai RMI, sebuah objek lokal
Konsekuensinya TAO lebih memfokuskan diri pada yang dinamakan stub mengurus pemanggilan method
dukungan terhadap aspek real-time dan koneksi pada objek jarak jauh.
berkecepatan tinggi, yang diimplementasikan ke dalam RMI (Remote Method Invocation) adalah cara
arsitektur inti ORB dan modul-modul pendukungnya. programmer Java untuk membuat program aplikasi
Jika anda memiliki lingkungan komputasi Java to Java yang terdistribusi. Program-program yang
terdistribusi di rumah, di kantor, atau di sekolah, anda menggunakan RMI bisa menjalankan metode secara
bisa mencoba melakukan pemrograman sistem jarak jauh, sehingga program dari server bisa
terdistribusi berbasis CORBA. Yang perlu anda lakukan menjalankan method di komputer klien, dan begitu
adalah men-download salah satu perangkat juga sebaliknya.
pengembangan di atas, memasangnya di sistem anda, Java RMI yang ada pada bahasa Java telah
dan mengikuti petunjuk/ tutorial pemrograman yang didesain khusus sehingga hanya bisa bekerja pada
diberikan. Jika petunjuk yang ada belum cukup lingkungan Java. Hal ini berbeda dengan sistem RMI
memadai, anda bisa mencari tutorial pemrograman lainnya, misalnya CORBA, yang biasanya didesain untuk
CORBA melalui Internet. Salah satu koleksi titik akses bekerja pada lingkungan yang terdiri dari banyak
yang cukup lengkap terdapat di situs Cetus (titik akses bahasa dan heterogen. Pemodelan objek pada CORBA
diberikan di bagian pustaka). tidak boleh mengacu pada bahasa tertentu.
Sistem RMI terdiri atas tiga layer/lapisan, yaitu :

REMOTE METHOD INVOCATION (RMI) a. Stub/skeleton layer, yaitu stub pada sisi klien
(berupa proxy), dan skeleton pada sisi server.
Java Remote Method Invocation (RMI) system
b. Remote reference layer, yaitu perilaku remote
memungkinkan object yang running di satu JVM untuk
reference (misalnya pemanggilan kepada suatu
memanggil suatu metode dar satu object yang running
objek).
di JVM yang lain. RMI memungkinkan komunikasi
c. Transport layer, yaitu set up koneksi,
remote antar program JAVA. Remote Procedure Call
pengurusannya dan remote object tracking.
(RPC), yang mengabstraksi interface komunikasi ke
level pemanggilan procedure. Programmer tidak akan
menangani socket secara langsung, dan seolah-olah

Batas antar masing-masing layer disusun oleh
interface dan protokol tertentu, yaitu tiap layer bersifat
independen terhadap layer lainnya, dan bisa diganti
oleh implementasi alternatif tanpa mengganggu layer
lainnya. Sebagai contoh, implementasi transport yang
digunakan RMI adalah yang berbasis TCP
(menggunakan Java socket), tapi bisa digantikan
dengan menggunakan UDP.
Keuntungan RMI
• Salahsatu keuntungan RMI adalah
kemampuan untuk download bytecodes (code)
dari suatu object's class, jika class tsb tidak
terdefinisikan di VM-nya penerima.
• Type-type dan metode-metode object (class),
yang terletak dalam satu VM, dapat dikirim ke VM
yang lain, yang mungkin saja remote.
• Sifat-sifat object yang terkirim ini tidak
berubah sama sekali
Arsitektur RMI
Dalam RMI, pendefinisian interface (behavior)
dan penerapan dari interface tersebut merupakan dua
konsep yang berbeda, artinya keduanya dapat berjalan
pada dua JVM yang berbeda.
Sebuah interface pada Java, hanyalah berisi
definisi method apa saja yang dapat digunakan oleh
suatu objek dan tidak berisi kode logika perintah yang
digunakan. Agar sebuah interface dapat diberikan
logika perintahnya, maka harus dibuat sebuah class
yang menerapkan (implementation) dari interface
tersebut.
Pada RMI dimungkinkan untuk membuat dua
class yang menerapkan dari satu interface yang telah
didefinisikan. Satu class menerapkan behavior dari
interface tersebut (berjalan di sisi server), dan satu
class lagi bertindak sebagai proxy untuk remote service
(server object) yang berjalan di client.
Contoh implementasi dari RMI di antaranya :
a. Perusahaan programming Avitek yang berlokasi di
Amerika Serikat, membuat program sistem
accounting untuk intranet yang memungkinkan
klien untuk meng-update dan mengubah data
dengan mudah. Tujuan dari proyek ini adalah
untuk membuat dan mendukung pembuatan dari
bukti nyata untuk konsep penggunaan Java yang
dikombinasikan dengan database.
b. Perusahaan CEAS Consulting yang menyediakan
jasa custom re-engineering dan otomasi proses
untuk perusahaan-perusahaan manufakturing dan
teknik, telah membuat program sistem
terdistribusi untuk klien mereka. Gambaran
program mereka adalah seperti berikut :
 Meskipun teknologi RPC ini relatif sudah memberikan
kenyamanan bagi developer, tapi perkembangan yang
terjadi di bidang pemrograman berorientasi objek
akhirnya menuntut kehadiran teknologi baru. Sederet
teknologi akhirnya benar-benar muncul, antara
lain;RMI (Remote Method Invocation), CORBA
(Common Object Request Broker Architecture), dan
SOAP (Simple Object Access Protocol).
Komputasi terdistribusi merupakan sesuatu yang

MESSAGE BROKER amat kompleks, apalagi jika ruang lingkupnya sangat

luas (pada level enterprise misalnya). CORBA
Salah satu masalah dalam pertukaran pesan
membantu menyederhanakan persoalan dengan
adalah perbedaan format yang mungkin di antara
menyembunyikan berbagai detail pekerjaan pada level
aplikasi-aplikasi yang bergabung dalam suatu utilitas
rendah dan heterogenitas sistem dan platform. Lebih
tambahan yang dikenal sebagai message broker.
lanjut, arsitektur OMA menyediakan sebuah
Message Broker bertindak sebagai gateway yang
framework pengembangan sistem terdistribusi yang
bergerak di laposan aplikasi untuk menangani
konsisten, sehingga heterogenitas tetap dapat dikelola
perbedaan fomat pesan. Pada umumnya message
dengan baik. Dengan semakin banyaknya pemain
broker adalah sebuah aplikasi tambahan yang bersifat
teknologi informatika yang terjun ke dunia CORBA,
opsional sehingga tidak bisa dianggap sebagai bagian
agaknya contoh ilustrasi di awal tulisan ini dalam waktu
integral dari sebuah queuing System
yang relatif tidak terlalu lama akan dapat direalisasikan.

REFERENSI
[1] RPC
 http://blog.uad.ac.id/heri_triyanto/2010/10/01/r
emote-procedure-call-rpc-tugas1-sistem-
distribusi/
[2] CORBA
 www.komputasi.lipi.go.id/utama.cgi?cetakartikel
 http://www.cs.wustl.edu/~schmidt/corba-
overview.html
 http://mala06-telematika-
telematika.blogspot.com/2009/12/middleware-
KESIMPULAN
telematika.html
[3] RMI
  http://mala06-telematika-
telematika.blogspot.com/2009/12/middleware-
telematika.html
 lecturer.ukdw.ac.id/budsus/java/RMI2.doc
 opensource.telkomspeedy.com/.../sekilas-
tentang-java-rmi-1998.rtf
[4] MESSAGE BROKER
 courseware.politekniktelkom.ac.id/BUKU_TK/.../Si
stem%20Tersebar.pdf