message dalam java
TRANSCRIPT
KOMUNIKASI
SISTEM TERDISTRIBUSI
Outline
Komunikasio Jenis IPC (Inter Process Communication)o Arsitektur Komunikasi dengan Protokol Berlapiso Jenis Komunikasi Protokol High Level
RPC RMI MOM Streaming
IPC(Inter Process Communication)
Secara Garis besar ada 2 macam IPC dasar:o Shared Memory
Terutama pada sistem yang dimana proses yang saling berkomunikasi terletak pada satu node komputer
o Message Passing Mekanisme yang dipakai untuk berkomunikasi antar proses yang terletak
pada node komputer yang sama maupun berbeda. Pada sistem Terdistribusi, IPC pada level bawah hanya dimungkingkan dengan message
passing.
Interprocess Communication (IPC)
“Jantungnya” dari setiap sistem terdistribusi Pertanyaan: Bagaimana proses-proses pada mesin komputer yang berbeda saling
mempertukarkan informasi? Jawaban: dengan susah payah ? Menggunakan fasilitas jaringan komputer terlalu kuno, menghasilkan suatu sistem
terdistribusi yang sangat sukar untuk dikembangkan. Jadi suatu model baru butuh dikembangkan.
Ada 4 model IPC yang popular:o RPCo RMIo MOMo Streams
Protokol Berlapis
Lapisan, antarmuka dan protokol pada Model OSI.
TCP Client-Server
Normal operation of TCP. Transactional TCP.
Protokol Middleware
Model referensi adaptasi untuk komunikasi jaringan
RPC: Remote Procedure Call
Dikemukakan oleh Birrell and Nelson (1984)
“Mengizinkan program untuk memanggil prosedur yang terletak pada komputer lain”
Secara efektif membebaskan programmer dari kerumitan berurusan dengan detil pemrograman jaringan (tidak perlu pusing tentang pemakaian socket)
Komplikasi pada RPC
Arsitektur antar 2 mesin yang berbeda mungkin tidak sama.
Tiap mesin memiliki ruang alamat yang berbeda.
Bagaimana parameter (tipe yang kompleks dan beragam) dilewatkan dari/ke prosedur remote.
Apa yang akan terjadi jika, salah satu mesin atau bahkan keduanya crash prosedur lagi dipanggil.
Bagaiamana RPC bekerja: Bagian 1
Bagi pemrograman, pemanggilan prosedur remote harus kelihatan bekerja seperti halnya pemanggilan prosedur lokal.
Dengan cara ini, maka tranparansi tercapai
Sebelum melihat Aksi RPC, mari kita pertimbangkan sebuah pemanggilan prosedur lokal konvensional.
Pemanggilan Prosedur lokal “Konventional”
Pelewatan parameter pada prosedur lokal:
Keadaan stack sebelum prosedur dipanggil Isi stack ketika prosedur lokal lagi aktif.
Bagaimana RPC bekerja: Bagian 2
Prosedur ini dibagi menjadi 2 bagian.o Stub CLIENT – mengimplementasikan antarmuka pada mesin lokal untuk
memanggil fungsi remoteo Stub SERVER – mengimplementasikan fungsionalitas yang
sesungguhnya.
Parameter di “marshal” oleh client sebelum ditransmisikan ke server.
Stub Client dan Server
Prinsip RPC antara program client dan server
10 Langkah RPC
Prosedur client memanggil stub client secara normal Stub client membentuk pesan, memanggil OS lokal OS client mengirimkan pesan ke OS remote OS remote meneruskan pesan ke stub Server Stub server melakukan “unpacking” parameter dan memanggil server. Server melakukan kerja (kerja prosedur) dan hasilnya dikembalikan ke stub. Stub server meng-”pack” ke dalam pesan, dan memanggil OS lokal (server) OS server mengirimkan pesan ke OS Client OS Client meneruskan pesan ke stub client Stub client meng-”unpack” hasil prosedur dan mengembalikan ke client.
Langkah-langkah RPC
Masalah RPC: Passing Value Parameter
RPC bekerja sangat baik jika semua mesinnya adalah sama Komplikasi muncul ketika dua mesin menggunakan pengkodean karakter yang
berbeda seperti EBCIDC atau ASCII Pengurutan byte juga menjadi satu masalah:
o Mesin Intel menggunakan “big-endian”.o Mesin Sun Sparc menggunakan “little-endian”.
Mekanisme tambahan butuh dimasukkan ke mekanisme RPC untuk menangani kondisi seperti diatas (ini menambah kompleksitas)
Masalah RPC: Passing Value Parameter
Pesan asli pada Mesin Intel (Pentium) Pesan setelah diterima pada Mesin SPARC Pesan setelah dibalik – dimana tetap belum benar sebagaimana seharusnya.
Nb: bilangan dalam kotak menunjukkan alamat dari tiap byte.
Variasi RPC Pada mesin lokal: Doors
Prinsip penggunaan doors sebagai mekanisme IPC:o Proses-proses berada pada mesin yang sama
Keuntungan: mekanisme tunggal untuk pemrograman Sistem Terdistribusi Kekurangan: kehilangan akan transparansi transparensi
RPC Asinkron
Interkoneksi antara client dan server pada RPC tradisional – perhatikan – BLOCKING terjadi – client harus menunggu
Interaksi dengan menggunakan RPC asinkron – tidak ada BLOCKING; berguna jika client tidak memerlukan/mengharapkan adanya hasil kembalian.
2-12
RPC Asinkron: RPC Sinkron Tertunda
Client dan server berinteraksi lewat dua RPC asinkron- mengizinkan client untuk melakukan kerja lainnya ketika menunggu hasil kembalian.
Interface Definition Language (IDL)
RPC umumnya memerlukan pengembangan antarmuka (interface) protokol kustom agar bisa efektif.
Antarmuka protokol dideskripsikan dengan menggunakan sebuah Bahasa Definisi Antarmuka atau Interface Definition Language (IDL).
IDL netral terhadap bahasa tertentu – yaitu tidak mengasumsikan pemakaian bahasa pemrograman tertentu.
Namun, kebanyakan IDL nampak seperti C….
Contoh RPC : DCE
Merupakan standar Open Group untuk mekanisme RPC Selain RPC, DCE juga menyediakan :
o Distributed File Service.o Directory Service (name lookups).o Security Service.o Distributed Time Service.
DCE: Menulis Client dan Server
Langkah-langkah menulis client dan server pada RPCE DCE
DCE: “Binding” Client ke Server
Binding (pengikatan) client ke server pada DCEo Sebuah “directory service”menyediakan cara bagi client untuk
menemukan server
Ringkasan RPC
Merupakan standar defacto Sistem Terdistribusi untuk komunikasi dan aplikasi terdistribusi ( pada level prosedural)
Sudah matang
Mudah dimengerti
Bekerja dengan baik.
RMI: Remote Method Invocation
“Objek Remote” dapat dipikir sebagai ekpansi dari mekanisme RPC ( untuk mendukung sistem OO ).
Salah satu aspek pentind ari objek adalah definisi dari antarmuka untuk menyembunyikan fungsionalitas.
Pemanggilan method mendukung perubahan state dalam objek lewat antarmuka yang terdefinisi.
Semua objek dapat menawarkan sejumlah antarmuka. Sebuah antarmuka dapat diimplementasikan oleh sejumlah objek. Dalam Sistem Terdistribusi, sebuah antarmuka objek berada pada satu mesin
dan implementasi objek berada pada mesin lainnya.
Objek Terdistribusi
Pengaturan umum untuk objek remote disisi client adalah “proxy” Proxy dapat dibayangkan sebagai stub client Skeleton dapat dibayangkan sebagai stub server
Objek Compile-time vs. Objeyk Run-time
Objek compile-time tedistribusi umumnya mengasumsikan penggunaan suatu bahasa pemrograman (java atau C++)
Hal diatas sering dipandang sebagai kelemahan (tidak fleksibel)
Objek run-time terdistribusi menyediakan adaptor objek bagi objek-objek, yang dirancang untuk meniadakan batasan bahasa pemrograman dari objek compile-time
Menggunakan adaptor objek memungkinkan implementasi objek dikembangkan dengan sembarang cara- sepanjang implementasi yang dihasilkan tampak sebagai objek, maka segala sesuatu dianggap baik-baik saja.
Objek Persistent vs Objek Transient
Objek persistent terdistribusi tetap ada bahkan setelah tidak berada lagi dalam ruang alamat server.
Objek persistent disimpan (mungkin pada storage sekunder) dan dapat diinstanisasi lagi di waktu lain dengan proses server yang baru
Objek transient terdistribusi tidak terus menerus ada. Begitu server berhenti, objek transient turut dimusnahkan
Mana yang lebih baik masih menjadi subjek perbantahan
Invokasi Static vs Invokasi Dinamis
Definisi antarmuka yang terdefinisi sebelumnya mendukung invokasi statis: Semua antarmuka harus diketahui terlebih dulu Perubahan pada antarmuka memerlukan semua aplikasi (client) untuk
dikompilasi ulang.
Invokasi dinamis membentuk method pada saat run-time Antarmuka dapat “datang dan pergi” seperlunya Antarmuka dapat berubah tanpa perlu memaksa aplikasi client untuk dikompilasi
ulang.
Objek Remote: Parameter Passing
Situasi ketika melewatkan objek secara referensi atau dengan nilai
o Catatan: O1 dilewatkan dengan nilai; O2 dilewatkan dengan referensi
Contoh : Objek remote DCE
Mekanisme RPC DCE dikembangkan lebih lanjut untuk mendukung invokasi method secara remote
Objek DCE = xIDL plus C++. Yaitu , IDL DCE telah diperluas untuk mendukung objek yang diimplementasikan
dalam C++ Dua tipe Objek DCE yang didukung:
o Objek Dinamis Terdistribusi – sebuah objek private yang dibuat oleh server untuk client
o Objek Bernama terdistribusi – sebyag objek yang dipakai bersama yang hidup pada server dan dapat diakses oleh lebih dari satu client.
Model Objek Terdistribusi DCE
Ada dua macam Objek DCE :
Objek dinamis (Dynamic Object) – permintaan pembuatan objek lewat RPC Objek bernama (Named Object)– diregister ke suatu layanan penamaan (naming
service)
Contoh: Java RMI
Dalam java, objek terdistribusi dapat diintegrasikan ke dalam bahasa yang jelas Ini menghasilkan transparensi distribusi yang sangat tinggi (kecuali jika ada
pertimbangan perbaikan efisiensi) Java tidak mendukung RPC, tetapi hanya objek terdistribusi State dari objek terdistribusi disimpan di server, dengan antarmuka dibuat dapat
diakses lewat client remote ( proxi objek terdistribusi)
Untuk membangun aplikasi sistem terdistribusi, programmer hanya butuh mengimplementasikan proxy client sebagai kelas dan skeleton server sebagai kelas lainnya.
Pertanyaan 1
Berikut yang bukan fungsi dari Stub dan Skeleton pada Arsitektur Remote Invocation!
o Mengubah parameter fungsi ke bentuk message maupun sebaliknyao Mengirimkan atau menerima message ke/dari mesin remoteo melakukan pemanggilan ataupun eksekusi kode fungsi.
Pertanyaan 2
Proses marshalling adalah proses:
o Meneruskan pemanggilan fungsi ke proxyo Mengubah parameter fungsi ke bentuk messageo Mengirim message ke proxy (stub atau skeleton)
Pertanyaan 3
Objek diatas adalah jenis objek:
o Named Objecto Dynamic Objecto Static Object
Object
Message-Oriented Middleware: MOM
Sebagai mekanisme komunikasi, RPC/RMI sering dianggap tidak tepat pada kondisi tertentu.
Contoh: apa yang terjadi jika kita tidak dapat mengandaikan sisi penerima dapat keadaan “siap” dan menunggu untuk berkomunikasi.
Juga: sifat default “ Sinkron, blocking” dari RPC/RMI sering terlalu membatasi Sesuatu yang lain dibutuhkan : MESSAGING
Terminologi Komunikasi Sistem Terdistribusi
Komunikasi persistent:o Sekali dikirim, pengirim dapat berhenti mengeksekusi. Penerima tidak
mesti sedang beroperasi – sistem komunikasi menampung pesan seperlunya (sampai dapat dikirimkan ke pengirim)
o [Apa contohnya?]
Kebalikannya, Komunikasi Transiento Pesan hanya disimpan sepanjang pengirim dan penerima lagi berjalan.
Jika masalah timbul, pesan dibuang begitu saja.
Terminologi Komunikasi Sistem Terdistribusi
Komunikasi Asinkrono Pengirim meneruskan kerja lainnya segera setelah mengirim pesan ke
penerima
Komunikasi Sinkron:o Pengirim memblok, menunggu balasan dari penerima sebelum bisa
melakukan kerja lainnya. (Ini cenderung menjadi model default untuk teknologi RPC/RMI)
Klasifikasi Komunikasi Terdistribusi
Komunikasi Asinkron persistent Komunikasi Sinkron persistent
Klasifikasi Komunikasi Terdistribusi
Komunikasi Asinkron Transient Komunikasi Sinkron Transient berbasis penerimaan
Klasifikasi Komunikasi Terdistribusi
Komunikasi sinkron transient berbasis pengiriman pada pengiriman pesan Komunikasi sinkron transient berbasis tanggapan
Sistem Message Passing (MP)
Secara fundamental pendekatan yang berbeda
Semua operasi komunikasi didefinisikan dalam konteks penyampaian pesan
Awalnya sistem MP adalah transient, tetapi ini tidak skala baik secara geografi
Sekarang ini, penekanannya pada solusi persistent.
Komunikasi transient berorientasi Pesan/Message
Usaha awal bergantung pada API Socket
Bagaimanapun, Pengembang Sistem Terdistribusi menolak Socket
Level abstraksi yang salah (hanya “send” dan “receive’) Terlalu tergantung pada jaringan TCP/IP – tidak cukup divergen
The Message-Passing Interface (MPI)
Vendor middleware umumnya menyediakan abstraksi level tinggi. Tiap vendor menggunakan mekanisme yang tersendiri.
Hal ini mengakibatkan masalah portabilitas karena tidak ada produk vendor yang antarmukanya sama
solusinya?o “Message-Passing Interface” (MPI).
The MPI API
Beberapa operasi message-passing yang berguna (nb: masih banyak lagi selain yang dibawah ini)
Check if there is an incoming message, but do not block.
MPI_irecv
Receive a message; block if there are none.
MPI_recv
Pass reference to outgoing message, and wait until receipt starts.
MPI_issend
Pass reference to outgoing message, and continue.
MPI_isend
Send a message and wait for reply.
MPI_sendrecv
Send a message and wait until receipt starts.
MPI_ssend
Send a message and wait until copied to local or remote buffer.
MPI_send
Append outgoing message to a local send buffer.
MPI_bsend
Makna
Operasi
Komunikasi Persistent berorientasi message
Dikenal juga sebagai : “message-queuing systems”.
Sistem ini mendukung komunikasi asinkron persisten Umumnya, transpor dapat berlangsung bermenit-menit (jam –jaman) ,
bandingkan dengan umumnya yang hanya dalam jangka detik/milidetik.
Konsep dasar; aplikasi berkomunikasi dengan memasukkan dan mengambil pesan dari antrian pesan (“message queue”)
Hanya memastikan: suatu message pada akhirnya akan masuk ke antrian pesan penerima
Ini memimpin kepada komunikasi yang bersifat longgar (loosely-coupled)
Model Message-Queuing
Empat kombinasi komunikasi terikat longgar menggunakan antrian pesan (message queque)
API dari Message-Queuing
Antarmuka dasar dari antrian pada sistem messae queuing : sangat sederhana namun merupakan abstraksi yang bagus
Install a handler to be called when a message is put into the specified queue.
Notify
Check a specified queue for messages, and remove the first. Never block.
Poll
Block until the specified queue is nonempty, and remove the first message.
Get
Append a message to a specified queue.
Put
Makna
Operasi
Arsitektur sistem Message-Queuing
Pesan diletakkan pada antrian sumber Pesan pada akhirnya harus diambil dari suatu antrian tujuan
Jelasnya harus ada mekanisme untuk memindahkan pesan dari antrian sumber ke antrian tujuan.
Ini adalah tugas dari Manager antrian (Queue Manager)
Manager antrian ini berupa relay antrian pesan yang berinteraksi dengan aplikasi terdistribusi dan juga satu sama lain. Ini sama halnya pada router yang menggunakan lapisan jaringan.
Arsitektur sistem Message-Queuing
Hubungan antara pengalamatan level antrian dan pengalamatan level jaringan. Lapisan antrian berada pada abstraksi yang lebih tinggi dari lapisan dibawahnya.
Arsitektur sistem Message-Queuing
Konfigurasi umum dari sistem messaged-queuing dengan router. Manager antrian terletak dalam router dan juga pada ujung-ujung dari sistem terdistribusi.
The general organization of a message-queuing system with routers. The Queue Managers can reside within routers as well as within the DS end-systems.
Peran dari Message Brokers (Makelar pesan)
Sering kali ada kebutuhan untuk mengintegrasikan aplikasi baru ataupun yang sudah ada ke dalam Sistem Informasi terdistribusi yang tunggal dan menyatu.
Masalah: ada berbagai macam format pesan dalam sistem yang lama . (dimasa lalu, kerjasama dan acuan terhadap standar terbuka bukanlah sesuatu yang umum)
Mungkin tidak enak untuk memaksa sistem lama untuk mengacu pada format pesan yang tunggal dan global.
Sering kali terpaksa harus menerima perbedaan-perbedaan tersebut
Bagaimana caranya? Menggunakan “Message Broker”.
Konfigurasi Message Broker
Message broker sering juga disebut degan “interface engine”.
Aplikasi Message-Queuing (MQ)
Sistem MQ mendukung berbagai macam aplikasi termasuk:o Electronic mail.o Workflow.o Groupware.o Batch Processing.
Area aplikasi MQ yang paling penting :o Integrasi koleksi aplikasi basisdata yang tersebar dimana-mana ( yang
tidak mampu dilakukan oleh RPC/RMI)
Contoh : IBM MQSeries
Arsitektur IBM MQSeries
IBM MQSeries: Message Channel (Saluran pesan)
Sejumlah atribut yang berhubungan dengan MCA (Message Channel Agent)
Jumlah percobaan maksimum MCA mencoba meletakkan pesan yang diterima ke dalam antrian.
Delivery retries
Menentukan jumlah percobaan maksimum untuk memulai MCA remote
Setup retry count
Panjang maksimum dari pesan tunggal.
Message length
Menunjukkan pesan disampaikan dalam urutan yang sama dengan urutan pengirimannya.
FIFO delivery
Menentukan protokol transport yang digunakan
Transport type
Deskripsi
Atribut
IBM MQSeries: Message Transfer
Operation ini didukung pada Antarmuka MQ dari IBM MQseries
Mengambil pesan dari sebuah antrian lokal.
MQget
Meletakkan pesan ke dalam antrian yang terbuka
MQput
Menutup antrian
MQclose
Membuka sebuah antrian (bisa remote)
MQopen
Deskrpsi
Operasi
Komunikasi berorientasi stream
Dengan RPC, RMI dan MOM, efek ketepatan waktu tidaklah penting.
Namun, data audio dan video adalah aliran data yang tergantung pada waktu. Jika pewaktu dimatikan, maka output yang dihasilkan dari sistem bakalan salah.
Informasi yang tergantung pada waktu (time-dependent) dikenal sebagai komunikasi media kontinyu.
Contoh : voice: PCM: interval waktu 1/44100 detik saat dimainkan Contoh: video: 30 frames per detik (30-40 milidetik per gambar).
Inti masalah :Waktu adalah sangat krusial !
Mode Transmisi
Mode transmisi asinkron – data stream di transmisi dalam urutan yang benar, namun tidak ada batasan waktu ditetapkan pada penyampaian yang sesungguhnya (contoh FTP)
Mode transmisi sinkron – delay maksimum dari titik ke titik didefinisikan (data harus bisa ditransmisikan secepatanya.)
Mode transmisi Isokron data ditransfer tepat waktu – ada delay maksimum dan minimum antar titik (bounded jitter)
o Dikenal sebagai “streams” – transmisi isokron (isochoronous) sangat berguna untuk sistem multimedia.
Tipe stream
Stream sederhana – runtun data tunggal contoh voice (suara)
Stream Kompleks – sejumlah runtun data (substream) yang saling berhubungan secara waktu. (Misalkan movie dengan suara dan sub title)
o Ini memunculkan masalah sinkronisasi, yang sangat tidak mudah ditangani.
Sinkronisasi Eksplisit
Prinsip sinkronisasi eksplisit pada level unit data untuk stream jamak (substream)
Sinkronisasi Level tinggi.
Prinsip sinkronisasi yang didukung oleh antarmuka level tinggi dibangun sebagai suatu set layanan streaming middleware multimedia.
Sinkronisasi
Pertanyaan kunci:o Dimanakah sinkronisasi terjadi ?
Pada sisi pengirim ? Atau pada sisi penerima ?
Pikirkan keuntungan dan kerugiaannya masing-masing!
Komponen dari stream
Ada 2 bagian : “source” dan “sink”: Keduanya dapat berupa perangkat jaringan (a) ataupun perangkat akhir (b)
Data stream Partai jamak
Contoh stream multicasting ke sejumlah penerima. Ini adalah komunikasi partai jamak- kecepatan transfer yang berbeda mungkin dibutuhkan untuk perangkat akhir yang berbeda.
Quality of Service (QoS)
Definisi: “memastikan bawhwa hubungan waktu dalam stream dapat terpenuhi”.
QoS memperhatikan 3 hal: (a) Tepat waktu (b) Volume dan c) Keandalan.
Tetapi bagaiman Qos dispesifikasikan?
Celakanya, semua sistem memakai caranya sendiri-sendiri.
Menspesifikasikan QoS dengan Spesifikasi Flow
Spesifikasi Flow – salah satu cara untuk menspesifikasikan QoS – sedikit kompleks, tetapi bekerja baik (tapi bukan lewat antarmuka yang dikontrol oleh pengguna).
Loss sensitivity (bytes) Loss interval (sec) Burst loss sensitivity (data units) Minimum delay noticed (sec) Maximum delay variation (sec) Quality of guarantee
maximum data unit size (bytes) Token bucket rate (bytes/sec) Toke bucket size (bytes) Maximum transmission rate (bytes/sec)
Layana yang dibutuhkan
Karakteristik INput
Pendekatan implementasi QoS
Prinsip “ token bucket algorithm” – teknik klasik untuk mengontrol aliran data ( dan mengimplementasikan karakteristik Qos)
Managemen Stream
Mengelola stream adalah tentang mengelola bandwith, buffer dan kapasitas pemrosesan serta prioritas penjadwalan – yang semuanya itu diperlukan untuk menjamin QoS.
Tidak tidak semudah kedengarannya, tidak ada kesepakatan bagaimana seharusnya hal ini dapat terlaksana.
Contoh : Qos dari ATM dari ATM terbuka tidak bekerja (susah diimplementasikan)
Teknik lain adalah RSVP internet.
QoS dari RSVP Internet
Konfigurasi dasar RSVP untuk reservasi resource pada suatu sistem terdistribusi – protokol kontrol level transport untuk memungkinkan reservasi resource pada router jaringan. Karakteristik menarik: Pengerima diinisiasi.
Ringkasan
Kekuatan dan fleksibilitas adalah penting, sedangkan operasi pemrograman jaringan terlalu kuno (kaku)
Komunikasi middleware. Mekanime – menyediakan dukungan abstraksi level tinggi.
RPC dan RMI: disinkronisasi, transient. MOM: nyaman, asinkron, persistent. Streams: kasus khusus, berguna untuk menangani “data yang terikat waktu”
(sangat susah).
Pertanyaan?
Andaikan dalam suatu sistem, kita hanya bisa menggunakan operasi komunikasi sinkron. Bagaimana kita bisa mengimplementasikan operasi komunikasi transient asinkron?
Jelaskan mengapa komunikasi sinkron transient memiliki masalah skalabilitas!