TUGAS SISTEM TERDISTRIBUSI

SISTEM TERDISTRIBUSI MIDDLEWARE

DIBUAT OLEH

BUDHI YANTO NIM 31815016

PROGRAM STUDI SISTEM KOMPUTER

STMIK INDONESIA

2018
SISTEM TERDISTRIBUSI MIDDLEWARE

EDA 390 – Komunikasi Komputer dan Sistem Terdistribusi

Chalmers University of Technology
2005-04-30
 BAB1

PENDAHULUAN

Kata "middleware" sekarang sangat populer untuk digunakan dalam teks teknis Hanya beberapa tahun
yang lalu istilah ini hampir tidak dapat ditemukan dalam ilmu computer kamus, kecuali untuk publikasi
terbaru, dan pencarian di Internet hanya akan menemukan beberapa ribu halaman web yang
menyebutkannya. Tapi, hari ini “middleware” menggunakan salah satu mesin pencari paling popular
Google.com menghasilkan jutaan klik. Ini menunjukkan peningkatan eksplosif minat untuk teknologi ini.
Sayangnya, "middleware" juga sering digunakan sebagai semboyan dan terkadang bahkan dalam
konteks yang salah.

Oleh karena itu, dapat membingungkan dan sulit untuk mencari tahu arti akronim ini. Laporan ini akan
focus menjelaskan konsep middleware (di bidang aplikasi terdistribusi pengembangan) dan memberikan
contoh berbagai jenis middleware. Akhirnya, perbandingan antara beberapa implementasi perangkat
lunak populer middleware akan dibuat.
Bab 2

Apa itu middleware?

Middleware sering secara informal disebut sebagai "pipa" karena menghubungkan bagian yang berbeda
dari aplikasi terdistribusi dengan pipa data dan kemudian melewatkan data diantara mereka. Penjelasan
ini tidak salah tetapi tidak menjelaskan kuncinya ide dengan middleware baik.

Fungsi komunikasi jaringan dasar ditawarkan oleh operasi sistem yang berjalan pada komputer dan
biasanya dapat diprogram seperti itu, untuk contoh dengan menggunakan konsep client / server dari
stack protokol TCP / IP. Namun, jenis pemrograman itu tidak sepele dan bisa sangat rawan kesalahan.
Selain itu, khusus untuk platform dan arsitektur yang digunakan dan itu tidak mendukung kompleksitas
penuh pemrograman berorientasi objek yang dibuat banyak aplikasi hari ini.

Middleware adalah kelas teknologi perangkat lunak yang dirancang untuk dipecahkan persis masalah ini
dengan menyembunyikan kompleksitas dan heterogenitas sistem terdistribusi. Ini didefinisikan sebagai
lapisan perangkat lunak di atas operasi sistem tetapi di bawah program aplikasi, sehingga memberikan
tingkat yang lebih tinggi kerangka pemrograman dari Application Programming Interfaces (APIs) seperti
itu sebagai soket. Ini mengurangi beban programmer dan memberikan lebih banyak fleksibilitas
(tergantung pada middleware yang digunakan).

Hardware dan heterogenitas jaringan selalu ditutupi oleh middleware tetapi sebagian besar kerangka
kerja juga menyembunyikan heterogenitas sistem operasi atau bahasa pemrograman, atau keduanya.
Beberapa, seperti CORBA, bahkan menyembunyikan heterogenitas antara implementasi vendor standar
middleware yang sama.
 Bab 3

Klasifikasi Middleware:
Lapisan perangkat lunak antara sistem operasi dan aplikasi yang memungkinkan interaksi komponen
aplikasi yang berpotensi terdistribusi, mencapai tingkat transparansi tertentu dan independensi dari
lingkungan runtime sekitarnya. Klasifikasi middleware Middleware adalah konsep yang luas dan definisi
ini cukup umum untuk mengklasifikasikan berbagai macam solusi perangkat lunak sebagai middleware.
Dengan demikian, banyak cara mengkategorikan mereka adalah mungkin. Salah satunya adalah Model
Gartner, yang membagi middleware menjadi tiga kategori:

1. Presentasi Middleware hanya peduli untuk menampilkan data dari jarak jauh. Web browser dan
komunikasi server melalui protokol HTTP (hypertext transfer protocol) misalnya dapat
diklasifikasikan ke dalam kategori ini.

2. Aplikasi Middleware digunakan untuk mendistribusikan logika dan fungsi aplikasi untuk
membuat platform pemrograman tujuan umum untuk didistribusikan aplikasi. Tujuannya adalah
untuk memungkinkan programmer membangun interaksi komponen tanpa harus detail khusus
sistem hardcode. Untuk Misalnya, middleware jenis ini dapat memberikan ilusi bekerja dengan
local objek ketika permintaan untuk sumber daya jarak jauh dibuat.

3. Database Middleware dikerahkan untuk mengakses sistem manajemen basis data dari jarak
jauh. permintaan SQL dikirim ke DBMS dan mentransfer hasilnya kembali ke klien adalah tugas
khas untuk middleware database.

Teks ini terutama akan berkonsentrasi pada Aplikasi Middleware tetapi sebagian besar prinsip
mungkin juga dapat diterapkan pada presentasi dan basis data middleware. Selanjutnya, sistem
Aplikasi Middleware secara historis bergantung pada dua pendekatan dasar Remote Procedure
Call (RPC) dan Didistribusikan Computing Environment (DCE) yang akan dijelaskan di bab
berikutnya.
 Bab 4

Aplikasi Middleware
RPC (Remote Procedure Call) adalah middleware pertama yang diterima secara luas solusi untuk
pemrograman aplikasi terdistribusi. Yang paling awal implementasi RPC adalah dari tahun 1984 tetapi
yang paling populer dikirim oleh Sun pada tahun 1985. Sun RPC dikirim sebagai bagian dari Jaringan
Terbuka mereka Paket Computing (ONC). Salah satu aplikasi utama RPC adalah milik Sun Network File
System (NFS).

DCE, yang didasarkan pada RPC, memperkenalkan konsep baru secara hierarkis layanan terstruktur.
Meskipun DCE memiliki beberapa keterbatasan utama, gagasan tentang layanan itu penting dan
berfungsi sebagai landasan bagi middleware modern dijelaskan nanti dalam laporan ini. Panggilan

Prosedur Jarak Jauh Tujuan

RPC adalah membuat panggilan prosedur jarak jauh terlihat secara sintaksis identik dengan panggilan
lokal. Keuntungan utama dengan pendekatan ini mudah penanganan parameter yang memungkinkan
untuk pengecekan tipe statis pada waktu kompilasi, a fitur yang tidak diberikan dengan komunikasi
socket murni. Sayangnya, sintaks yang mirip dengan panggilan prosedur lokal tidak menyiratkan
semantik identik dalam sistem terdistribusi. Dengan kata lain, kelemahan utama dengan RPC adalah
bahwa itu tidak memperhitungkan bahwa semantik dapat berbeda host karena lingkungan runtime,
ruang alamat dan penjadwalan proses. Itu hasil dari ini adalah bahwa tidak mungkin untuk melewatkan
pointer menggunakan RPC dan karenanya metode ini tidak cocok untuk solusi yang sepenuhnya
berorientasi objek. Implementasi RPC didasarkan pada deskripsi antarmuka menggunakan Bahasa RPC
yang telah ditetapkan, dari mana bertopik dan kerangka untuk klien- dan sisi server dihasilkan dengan
kompiler RPC. Rintisan dan kerangka ini mengambil atas tugas pengepakan dan pengangkutan
parameter di sisi bilik, dan tentu saja menggunakan protokol yang mendasari seperti TCP atau UDP.
Akhirnya, RPC juga diterima sebagai standar (RFC 1831) oleh Internet Engineering Task Force (IETF)

Lingkungan Komputasi Terdistribusi

DCE adalah pengembangan Open Group. Tujuannya adalah menyediakan platform distribusi untuk
aplikasi klien / server. Ini dilakukan dengan mendefinisikan.
mengatur layanan berlapis, sehingga layanan tingkat yang lebih tinggi selalu dapat menggunakan tingkat
yang lebih rendah jasa. Layanan yang ditetapkan, dimulai dengan level tertinggi, adalah:

 Layanan RPC - komunikasi client-server.

 Layanan Keamanan - otentikasi, otorisasi, manajemen akun.
 Layanan Direktori - model penamaan tunggal di seluruh lingkungan.
 Layanan Waktu - sinkronisasi jam sistem dalam jaringan.
 Layanan Benang - memungkinkan pelaksanaan beberapa untaian terdistribusi.
 Layanan File Terdistribusi - menyediakan akses ke file di seluruh jaringan.

Layanan Threads didasarkan pada standar POSIX 1003.1c untuk ringan proses yang memungkinkan
untuk membangun sistem terdistribusi canggih itu memanfaatkan pembuatan / penghapusan,
manipulasi dan sinkronisasi atas. Bersama dengan lapisan layanan lainnya, ini membuat DCE cocok
untuk banyak orang berbagai jenis tugas tujuan umum. Namun, keterbatasan utama dengan DCE adalah
bahwa ia bergantung pada RPC sebagai satu-satunya mekanisme komunikasi, dan desain yang tidak
berorientasi objek (sekarang juga ada ekstensi berorientasi objek ke DCE). Namun demikian, yang
penting kontribusi DCE adalah konsep membagi fungsi middleware menjadi mengatur layanan dan fitur
yang terdesentralisasi. Ide-ide ini dapat ditemukan di banyak platform middleware modern.

Middleware Berorientasi Pesan

Middleware Berorientasi Pesan, IBU, mengambil alih tanggung jawab untuk mengandalkan data antara
dua aplikasi dengan memasukkannya ke dalam antrean pesan yang dapat diakses melalui jaringan.
Solusi ini benar-benar tidak lebih dari generalisasi prosedur yang dikenal mengirim dan mengambil e-
mail (menggunakan SMTP dan POP3). Komunikasi middleware asinkron ini kebanyakan digunakan
untukpertukaran cara data di mana waktu tidak menjadi masalah.

Middleware Obyek Terdistribusi

Objek Middleware Terdistribusi menyediakan abstraksi dari objek yang ada jauh tetapi metode yang
dapat dipanggil seperti yang dari objek lokal. Objek terdistribusi mendukung semua manfaat dari
pemrograman berorientasi objek teknik seperti enkapsulasi, pewarisan dan polimorfisme. Jadi,
menggunakan ini jenis middleware dalam pengembangan aplikasi terdistribusi baru adalah yang paling
banyak pendekatan umum. Di sisi lain, middleware berorientasi objek adalah perangkat lunak yang
kompleks. Bahkan jika programmer tidak perlu mempelajari bahasa pemrograman baru, tetapi
bisamenentukan antarmuka yang dapat diprogram dalam bahasa apa saja yang didukung oleh.
middleware, masih membutuhkan banyak waktu untuk menguasai perangkat lunak semacam ini. Oleh
karena itu, dalam beberapa kasus mungkin lebih tepat untuk memilih yang lebih sederhana (tapi lebih
membatasi) implementasi menggunakan RPC atau MOM sebagai gantinya. Middleware, dan terutama
middleware berorientasi objek, sering digunakan untuk mengintegrasikan komponen legacy. Artinya,
antarmuka middleware bias diprogram untuk menerjemahkan permintaan antara sistem yang awalnya
tidak bias untuk berkomunikasi karena masalah warisan. Arsitektur Broker Permintaan Obyek Umum
(CORBA) adalah standar untuk komputasi objek terdistribusi, dan oleh banyak orang dianggap sebagai
yang paling luas di ruang lingkup. Implementasi penting lainnya dari middleware berorientasi objek
adalah DCOM dan Java RMI dari Microsoft. Ini akan dijelaskan dan secara singkat dibandingkan di bab-
bab berikutnya.
 Bab 5

Sekilas tentang CORBA, DCOM dan Java RMI CORBA

COBRA
CORBA Arsitektur Broker Permintaan Obyek Umum adalah standar untuk bekerja dengan objek di atas
lingkungan terdistribusi. Itu bisa dilihat sebagai objek varian berorientasi RPC. Standar ini terdaftar oleh
anggota Object Kelompok Manajemen (OMG). Bagian tengah CORBA adalah Object Request Broker
(ORB). ORB berfungsi sebagai Bus Objek sentral di mana setiap objek CORBA dapat berinteraksi dengan
objek CORBA lainnya. Interaksi bersifat transparan dan objek bias terletak baik secara lokal atau jarak
jauh pada host lain. ORB mendukung pencarian metode, mengubah format, mengatur ulang parameter
dan sinkronisasi. Itu komunikasi antara ORB dilakukan melalui Inter-ORB Protocol Internet (IIOP).

Setiap objek server CORBA memiliki antarmuka dan memperlihatkan sekumpulan metode. Untuk
meminta layanan, klien CORBA memperoleh referensi objek ke CORBA objek server. Klien sekarang
dapat melakukan panggilan metode pada referensi objek sebagai jika objek server CORBA berada di
ruang alamat klien. ORB adalah bertanggung jawab untuk menemukan implementasi objek CORBA,
mempersiapkannya menerima permintaan, mengomunikasikan permintaan untuk itu dan membawa
balasan kembali ke klien.

Objek CORBA berinteraksi dengan ORB baik melalui antarmuka ORB atau melalui Adaptor Objek – baik
Basic Object Adapter (BOA) atau Portable Adaptor Objek (POA).
Menurut spesifikasi CORBA, adaptor objek bertanggung jawab atas fungsi-fungsi berikut:

 Generasi dan interpretasi referensi objek

 Doa Metode
 Keamanan interaksi
 Aktivasi objek dan implementasi dan penonaktifan
 Memetakan referensi objek ke implementasi objek yang sesuai
 Pendaftaran implementasi

Untuk menentukan antarmuka objek, Antarmuka Definisi Bahasa (IDL) digunakan. Ini memungkinkan
bjek yang ditulis dalam bahasa yang berbeda untuk berkomunikasi satu sama lain. Untuk setiap objek
yang ditentukan dengan IDL, sebuah Stub dihasilkan. Stub terhubung dengan klien di kompilasi dan
berfungsi sebagai gambar klien dari server. Kesetaraan pada sisi server disebut kerangka. Keduanya klien
dan server menggunakan antarmuka yang disebut antarmuka ORB saat mereka menginginkannya untuk
menggunakan metode yang persediaan ORB. Koneksi statis antar server dan klien di CORBA cepat tetapi
memiliki kelemahan bahwa setiap kali server antarmuka perubahan klien harus dikompilasi ulang. Oleh
karena itu CORBA juga bias digunakan dalam koneksi yang dinamis. Dalam koneksi dinamis, Dinamis
Invocation Interface (DII) dan Dynamic Skeleton Interface (DSI) digunakan. DII dan DSI digunakan untuk
membuat antarmuka secara dinamis selama waktu proses daripada membuatnya di kompilasi. Karena
CORBA hanyalah spesifikasi, itu dapat digunakan pada berbagai platform sistem operasi dari mainframe
ke UNIX kotak untuk mesin Windows ke perangkat genggam selama ada ORB implementasi untuk
platform itu.

DCOM
DCOM, Distributed Component Object Model adalah perpanjangan dari Microsoft Component Object
Model (COM). COM mendefinisikan bagaimana komponen dan komponennya klien berinteraksi.
Interaksi ini didefinisikan sedemikian rupa sehingga klien dan komponen dapat terhubung tanpa perlu
sistem perantara komponen. DCOM memperluas protokol sehingga komponen dan klien tidak harus
berada di komputer yang sama.
DCOM menjalankan protokol Object Remote Procedure Call (ORPC) untuk mendukung komunikasi
Antara dua mesin. ORPC dibangun di atas DCE RPC dan berinteraksi dengan layanan run-time COM.
Server DCOM adalah segmen kode bahwa itu dapat melayani objek dari tipe tertentu pada saat runtime.
Setiap server DCOM objek dapat mendukung beberapa antarmuka yang masing-masing antarmuka
mewakili yang berbeda perilaku objek. Seorang klien DCOM panggilan ke metode terbuka dari Server
DCOM dengan memperoleh penunjuk ke salah satu antarmuka objek server. Objek klien sekarang dapat
memanggil metode terpapar objek server melalui penunjuk antarmuka yang didapat seolah-olah objek
server berada di ruang alamat klien. Untuk menentukan antarmuka untuk objek DCOM dan RPC
Antarmuka Microsoft Definisi Bahasa (MIDL) digunakan. MIDL mendukung dua bentuk berbeda deskripsi
antarmuka, antarmuka COM dasar IUnknown dan OLE antarmuka otomatisasi IDispatch. Setiap objek
DCOM harus mengimplementasikan Antarmuka IUnknown. Antarmuka IDispatch merupakan
perpanjangan dari IUnknown dan dapat dilihat sebagai pintu gerbang ke lebih banyak antarmuka. Ketik
informasi dari objek disimpan dalam pustaka tipe (.tlb) yang dibuat oleh kompilator MIDL. Tipe pustaka
digunakan untuk secara dinamis memanggil objek yang menerapkan IDispatch antarmuka.
Pengidentifikasi Unik Universal (UUID) digunakan untuk mengidentifikasi secara unik setiap kelas dan
antarmuka di COM. Karena spesifikasi COM berada pada level biner, ini memungkinkan server DCOM
komponen yang akan ditulis dalam bahasa pemrograman yang berbeda. Perangkat keras platform harus
mendukung layanan COM untuk menyediakan DCOM.

Java RMI
Java RMI, Java Remote Method Invocation adalah standar yang dikembangkan oleh JavaSoft. RMI
menggunakan protokol yang disebut Java Remote Method Protocol (JRMP). Ini tergantung pada Java
Object Serialization untuk mengirim objek sebagai aliran. Ini berarti bahwa kedua objek server RMI dan
objek klien harus ditulis di Jawa. Setiap objek server RMI mendefinisikan antarmuka yang akan
digunakan mengakses objek di luar Java Virtual Machine (JVM) saat ini.
JVM lain yang dapat ditemukan di komputer lain. Mesin server memiliki sebuah RMIRegistry di mana ia
menyimpan informasi tentang objek server yang tersedia dan menyediakan layanan penamaan untuk
RMI. Seorang klien RMI mengakuisisi suatu objek referensi ke objek server RMI dengan melakukan
pencarian untuk Objek Server referensi dan memanggil metode pada objek server seolah-olah objek
server RMI tinggal di ruang alamat klien. Objek server diberi nama menggunakan URL dan ketika klien
ingin mendapatkan objek yang ditentukan dengan menggunakan URL alamat.

Ketika klien Java / RMI meminta layanan dari server Java / RMI, hal itu pengikut:

 Memulai koneksi dengan JVM jarak jauh yang berisi objek jarak jauh,
 Marshals parameter ke JVM jarak jauh,
 Menunggu hasil dari pemanggilan metode,
 Unmarshals mengembalikan nilai atau pengecualian, dan
 Mengembalikan nilai ke pemanggil.

Penggunaan serialisasi berarti bahwa data dan kode dapat dilewatkan antara server dan klien. Ini juga
berarti bahwa contoh yang berbeda dari suatu objek dapat berjalan di kedua mesin server dan klien.
Karena Java RMI bergantung pada Java, ia dapat digunakan pada banyak operasi yang berbeda platform
sistem selama ada implementasi JVM yang sudah ada untuk PLATFORM.
 Bab 6

Perbandingan CORBA, DCOM dan Java RMI

Bahasa pemrograman
Karena CORBA adalah spesifikasi, itu tidak tergantung hanya pada satu bahasa. Apa saja bahasa dapat
digunakan selama ada implementasi ORB untuk itu bahasa. DCOM adalah standar biner dan mendukung
banyak program bahasa. Java RMI di sisi lain hanya dapat digunakan sebagai middleware antara klien
dan server yang diimplementasikan di Jawa. Ini tentu saja Kelemahan utama dengan Java RMI
dibandingkan dengan CORBA dan DCOM.

Definisi Antarmuka
CORBA dan DCOM sangat mirip di area ini. Mereka berdua menawarkan sebuah bahasa definisi
antarmuka (IDL) untuk menggambarkan antarmuka untuk masing-masing objek. IDL dalam kedua kasus
adalah bahasa netral yang digunakan untuk mendefinisikan pemetaan antara bahasa pemrograman
yang berbeda, meskipun ada beberapa perbedaan dalam semantik dan notasi antarmuka. Java RMI
berbeda meski tidak memiliki IDL. Sebaliknya ia telah mendefinisikan deklarasi antarmuka sebagai
konsep yang terpisah dalam bahasa dan antarmuka disimpan sebagai file .java. Objek Java adalah dapat
akses oleh klien Java jarak jauh jika mengimplementasikan java.rmi.Remote antarmuka.

Dukungan Berorientasi Objek

DCOM dan Java RMI keduanya memiliki dukungan untuk beberapa antarmuka untuk suatu objek. Setiap
antarmuka mewakili pandangan atau perilaku objek yang berbeda. Sebelumnya versi CORBA tidak
memiliki fitur ini tetapi sekarang diimplementasikan dalam versi yang lebih baru.

Objek server DCOM dapat membuat beberapa instance objek dari beberapa DCOM kelas objek
tergantung pada jumlah antarmuka yang digunakan. Objek dalam CORBA atau Java RMI di sisi lain
melayani oleh satu contoh objek server yang dapat mewakili banyak contoh objek lainnya.
Identifikasi Antarmuka
Dalam antarmuka DCOM secara unik ditentukan oleh UUID yang terdaftar diregistri sistem Windows.
UUID memungkinkan server untuk memperpanjang fungsionalitas dengan mengimplementasikan
antarmuka baru dengan UUID baru. CORBA menggunakan nama antarmuka untuk mengidentifikasi
antarmuka dan implementasi oleh pemetaan dalam Repositori Pelaksanaan. Java RMI mengidentifikasi
kelas berdasarkan nama dan implementasi oleh pemetaan ke URL di registri RMI.

Platform yang didukung

Ini adalah kelemahan di DCOM karena didukung terutama pada Windows peron. Upaya untuk
menjalankan DCOM pada platform lain belumlah sangat sukses. CORBA dan Java RMI tidak memiliki
kelemahan ini, mereka didukung di hampir semua platform.