BAB 2

ARSITEKTUR
Sistem terdistribusi mengeluarkan bagian perangkat yang rumit yang komponennya sesuai resolusi
didistribusikan di beberapa mesin. Untuk mengatur kerumitannya, sangat penting sistem ini dikelola dengan
baik. Ada berbagai cara tentang melihat organisasi sistem terdistribusi, tetapi yang jelas membuat perbedaan
antara organisasi logis dari seluruh komponen perangkat lunak dan di sisi lain.
Organisasi sistem terdistribusi besar tentang komponen perangkat lunak yang membentuk sistem.
Arsitektur perangkat lunak memberi tahu kami bagaimana berbagai komponen perangkat lunak mengatur
dan bagaimana mereka harus memfasilitasi. Dalam bab ini, pertama-tama kita akan membahas beberapa
yang biasa diterapkan untuk sistem komputer.
Realisasi aktual dari sistem terdistribusi memerlukan kami membuat instance dan menempatkan
komponen perangkat lunak pada mesin nyata. Ada banyak pilihan berbeda yang dapat dilakukan untuk
dilakukan. Instansiasi akhir arsitektur perangkat lunak juga disebut sebagai arsitektur sistem. Dalam bab ini
kita akan melihat ke arsitektur tradisional terpusat di mana satu server menerapkan sebagian besar
perangkat lunak (dan dengan demikian fungsionalitas), sementara klien jarak jauh dapat menggunakan
server menggunakan sarana komunikasi sederhana. Selain itu, kami membahas arsitektur terdesentralisasi
di mana mesin lebih atau kurang memainkan peran yang sama, serta organisasi hibrida.
Seperti yang kami jelaskan di Bab. Saya, tujuan penting dari sistem terdistribusi adalah untuk
mengubah aplikasi dari platform yang mendasarinya dengan menyediakan lapisan middleware.
Mengadopsi lapisan seperti itu adalah keputusan arsitektur yang penting, dan tujuan yang diminta
untuk memberikan persetujuan distribusi. Namun, perpindahan harus dilakukan untuk mencapai
persetujuan, yang telah menyebabkan berbagai teknik untuk membuat middleware adaptif. Kami membahas
beberapa yang diterapkan pada bab ini, karena mereka mempengaruhi organisasi middleware itu sendiri.
Dapat dipilih dengan sistem terdistribusi juga dapat disetujui dengan meminta sistem untuk memilih
perilakunya sendiri dan mengambil tindakan yang tepat jika diperlukan. Wawasan ini telah mengarah pada
kelas yang sekarang disebut sebagai sistem otonom. Sistem terdistribusi ini sering mengatur dalam lingkaran
kontrol umpan balik. yang membentuk elemen arsitektur penting selama desain sistem. Dalam bab ini, kami
menyediakan bagian untuk sistem otonom terdistribusi.

A. Macam Arsitektur
Kami memulai diskusi kami tentang arsitektur dengan terlebih dahulu membahas organisasi
logis dari sistem terdistribusi ke dalam komponen perangkat lunak, juga disebut sebagai arsitektur
perangkat lunak (Bass et al., 2003). Penelitian tentang arsitektur perangkat lunak telah dirilis jauh
dan sekarang diterima umum atau disetujui arsitektur sangat penting untuk disetujui pengembangan
sistem besar.
Untuk diskusi kita, arti tentang gaya arsitektur adalah penting. Gaya seperti itu dirumuskan
dalam komponen hal, cara komponen terhubung satu sama lain, data dipertukarkan antara
komponen. dan akhirnya bagaimana elemen-elemen ini dikonfigurasikan bersama ke dalam suatu
sistem. Komponen adalah unit modular dengan antarmuka yang diperlukan dan disediakan dengan
baik yang dapat diganti dalam Lingkungannya (OMG, 2004b). Seperti yang akan kita bahas di bawah
ini, masalah penting tentang komponen untuk sistem terdistribusi adalah bahwa ia dapat diganti,
asalkan kita setuju antarmuka-nya. Konsep yang agak lebih sulit untuk diterjemahkan adalah
konektor, yang dipublikasikan sebagai transisi yang memediasi komunikasi, koordinasi, atau kerja
sama antar komponen (Mehta et al., 2000; dan Shaw and Clements, 1997). Sebagai contoh,
Menggunakan komponen dan konektor, kita dapat menemukan berbagai konfigurasi, yang,
pada persetujuan telah disetujui ke dalam gaya arsitektur. Beberapa gaya sekarang telah dilaporkan,
mana yang paling penting untuk sistem terdistribusi adalah:
1. Arsitektur berlapis
2. Arsitektur berbasis objek
3. Arsitektur yang berpusat pada data
4. Arsitektur berbasis acara
Ide dasar untuk gaya selesai: komponen disusun lengkap di mana komponen pada lapisan
L; diizinkan untuk diizinkan komponen di lapisan yang mendasari Li: «, tetapi tidak berlawanan,
seperti yang dibahas pada Gambar. 2-I (a). Model ini telah banyak diadopsi oleh komunitas jejaring;
Kami memeriksanya secara singkat di Bab. 4. Pengamatan utama adalah kontrol umum dari lapisan
atas: permintaan hingga hierarki.
Organisasi yang lebih jauh membahas tentang objek wisata berbasis arsitektur, yang
diilustrasikan pada Gambar 2-1 (b). Pada dasarnya, setiap objek sesuai dengan apa yang telah kita
definisikan sebagai komponen, dan komponen-komponen ini terhubung melalui hubungan
pemindahan prosedur (jarak jauh). Tidak mengherankan, arsitektur perangkat lunak ini cocok
dengan arsitektur sistem client-server yang kami jelaskan di atas. Arsitektur berlapis dan berbasis
objek masih membentuk gaya yang paling penting untuk sistem perangkat lunak besar (Bass et aI.,
2003).

Gambar 2-1. Gaya Arsitektur (a) dan (b) Berbasis objek

Arsitektur yang berpusat pada data yang dikembangkan di sekitar yang membahas proses
komunikasi melalui repositori umum (pasif atau aktif). Dapat disetujui untuk sistem terdistribusi,
arsitektur ini sama pentingnya dengan arsitektur yang disediakan dan berbasis objek. Sebagai
contoh, banyak aplikasi jaringan yang telah dikembangkan yang bergantung pada file sistem
terdistribusi bersama di mana hampir semua komunikasi terjadi melalui file. Demikian pula, sistem
 terdistribusi berbasis web, yang kita bahas luas dalam Bab. 12, sebagian besar data-sentris: proses
penggunaan melalui layanan data berbasis sharedWeb.
Dalam arsitektur berbasis peristiwa, proses pada saat berkomunikasi melalui penyebaran,
yang didistribusikan juga membawa data, seperti yang diterbitkan pada Gambar. 2-2 (a). Untuk
sistem terdistribusi, acara umum diterbitkan dengan apa yang dikenal sebagai sistem
mempublikasikan / berlangganan (Eugster et aI., 2003). Ide dasarnya adalah proses penerbitan
acara setelah middleware memastikan bahwa hanya proses yang menyetujui acara yang akan
menerimanya. Keuntungan utama dari sistem dasar adalah proses yang digabungkan sepenuhnya.
Pada prinsipnya, mereka tidak perlu saling terkait secara eksplisit. Ini juga disebut sebagai
diselesaikan dalam ruang, atau sepenuhnya diselesaikan.

Gambar 2-2. (a) Berbasis acara dan (b) berbagi-gaya arsitektur ruang-data
Arsitektur berbasis data dapat digabungkan dengan arsitektur berpusat data, menghasilkan
apa yang juga dikenal sebagai ruang data bersama. Inti dari ruang bersama-sama adalah proses
sekarang juga diselesaikan dalam waktu: mereka tidak perlu aktif dengan komunikasi yang terjadi.
Selain itu, banyak ruang data bersama menggunakan antarmuka seperti SQL ke repositori bersama
dalam arti data dapat diakses menggunakan deskripsi tentang referensi eksplisit, seperti berbagi
dengan file. Kami mengabdikan Chap. Arsitektur gaya ini.
Apa yang membuat arsitektur perangkat lunak ini penting untuk sistem terdistribusi adalah
semua yang mereka butuhkan untuk mencapai (pada tingkat yang masuk akal) distribusi distribusi.
Namun, seperti yang telah kami katakan, meminta distribusi, mendukung, meminta, menginstal, dan
sebagainya. Karena tidak ada solusi tunggal yang akan memenuhi persyaratan untuk aplikasi
terdistribusi yang memungkinkan, para peneliti telah memutuskan bagaimana sistem terdistribusi
tunggal dapat digunakan untuk meningkatkan 90% dari semua kasus yang mungkin.

B. Arsitektur Sistem
Sekarang kita telah membahas beberapa gaya arsitektur umum, mari kita melihat
bagaimana banyak sistem terdistribusi sebenarnya mengatur dengan mempertimbangkan di mana
komponen perangkat lunak ditempatkan. Memutuskan komponen perangkat lunak, interaksinya,
dan penempatannya menyebabkan 10 contoh arsitektur perangkat lunak, juga disebut arsitektur
sistem (Bass et aI., 2003). Kita akan membahas organisasi yang tersentralisasi dan
terdesentralisasi, serta berbagai bentuk hibrida.
a) Arsitektur Terpusat
Meskipun kurangnya konsensus tentang banyak masalah sistem terdistribusi, ada
satu masalah yang disetujui oleh banyak peneliti dan praktisi: berpikir dalam hal klien
yang meminta layanan dari server membantu kita memahami dan mengelola
kompleksitas sistem terdistribusi dan itu adalah hal yang baik.
Dalam model client-server dasar, proses dalam sistem terdistribusi dibagi menjadi
dua kelompok (mungkin tumpang tindih). Server adalah sebuah proses yang
mengimplementasikan layanan tertentu, misalnya, layanan sistem file atau layanan
basis data. Klien adalah proses yang meminta layanan dari server dengan
mengirimkannya permintaan dan kemudian menunggu balasan server. Interaksi klien-
server ini, juga dikenal sebagai perilaku balasan-pertanyaan ditunjukkan pada Gambar
2-3

Gambar 2-3. Interaksi umum antara klien dan server.

Komunikasi antara klien dan server dapat diimplementasikan dengan
menggunakan protokol tanpa koneksi pada jaringan yang mendasarinya cukup andal
seperti banyak jaringan lokal. Dalam masalah ini, kompilasi klien meminta layanan, itu
hanya paket pesan untuk server, mendukung layanan yang diinginkan, bersama dengan
input data yang diperlukan. Pesan tersebut kemudian dikirim ke server. Yang terakhir,
pada persetujuan, akan selalu menunggu permintaan yang masuk, kemudian
diprosesnya, dan mengemas hasil dalam pesan yang kemudian dikirim ke klien.
Menggunakan protokol tanpa koneksi memiliki keuntungan yang jelas menjadi
efisien. Selama pesan tidak tersesat atau rusak, protokol permintaan / balasan yang
dibuat sketsa persiapan dengan baik. Sayangnya, membuat protokol yang tahan
terhadap transmisi transmisi sesekali tidak sepele. Satu-satunya hal yang dapat kita
lakukan adalah klien yang mengirim kembali permintaan kompilasi pesan noreply
masuk. Masalahnya, belum, adalah klien yang tidak dapat diproteksi pesan permintaan
asli yang hilang. , atau pengiriman balasan gagal. Jika dikembalikan itu hilang, maka
dikirim kembali dapat dikembalikan operasi dua kali. Jika operasi itu seperti
"mentransfer $ 10.000 dari rekening bank saya," maka jelas, lebih baik kita melaporkan
kesalahan saja. Di sisi lain, jika operasi itu "katakan menerima banyak uang yang
tersisa,
Sebagai alternatif, banyak sistem klien-server menggunakan protokol yang
berorientasi pada koneksi. Meskipun solusi ini tidak sesuai dengan jaringan daerah
karena kinerjanya yang relatif rendah, solusi ini bekerja dengan baik di area sistem yang
luas di mana komunikasi secara inheren tidak dapat diandalkan. Misalnya, hampir
semua protokol aplikasi Internet berdasarkan koneksi TCPIIP yang andal. Di dalam
kasus, setiap kali klien meminta layanan, pertama-tama mengatur koneksi ke server
 sebelum mengirim permintaan. Server umumnya menggunakan koneksi yang sama
untuk mengirim pesan balasan, setelah itu koneksi dihancurkan. Masalahnya adalah
pengaturan dan penghancuran koneksi relatif mahal, terutama ketika permintaan dan
balasan pesan menjadi lebih ringan.
 Layering Aplikasi
Model client-server telah mengalami peningkatan dan kontroversi selama
bertambah-tahun. Salah satu masalah utama adalah cara menggambar yang jelas antara
klien dan server. Tidak mengherankan, sering kali tidak ada perbedaan yang jelas. Sebagai
contoh, server untuk basis data terdistribusi dapat melanjutkan permintaan klien Karena
meminta dari server file yang lebih baik yang diminta untuk mengimplementasikan tabel
database. Dalam masalah seperti itu, database server itu sendiri pada dasarnya tidak lebih
dari pemrosesan permintaan.
Database, mendukung server dukungan untuk pengguna akses ke database,
banyak orang mengijinkan perbedaan antara tiga tingkat, pada saat mengikuti mengikuti
gaya arsitektur yang kita bahas sebelumnya:
1. Tingkat antarmuka pengguna
2. Tingkat pemrosesan
3. Tingkat data
Tingkat antarmuka pengguna yang diperlukan Semua diperlukan untuk pengguna
langsung, seperti manajemen tampilan. Tingkat penggunaan Biasanya berisi aplikasi.
Tingkat data mengelola data aktual yang sedang ditindaklanjuti.
Klien biasanya menggunakan level antarmuka pengguna. Level ini terdiri dari
program yang memungkinkan pengguna akhir berkomunikasi dengan aplikasi. Ada
perbedaan yang cukup besar dalam program hal antarmuka pengguna yang canggih.
Program antarmuka pengguna yang paling sederhana tidak lebih dari layar berbasis
karakter. Antarmuka seperti itu biasanya digunakan di lingkungan mainframe. Dalam kasus-
kasus di mana mainframe mengendalikan semua interaksi, termasuk keyboard dan monitor,
orang tidak dapat berbicara tentang lingkungan client-server. Namun, dalam banyak kasus,
terminal pengguna melakukan beberapa dukungan lokal seperti menggaet tombol yang
diketik, atau mendukung antarmuka seperti di mana entri yang lengkap harus mati sebelum
mengirimnya ke komputer utama.
Saat ini, bahkan di Lingkungan mainframe, kami melihat antarmuka pengguna yang
lebih maju. Biasanya, mesin klien menawarkan layar grafis di mana menu pop-up atau pull-
down digunakan, dan yang banyak dari kontrol layar memilih melalui mouse, bukan
keyboard. Contoh khas dari antarmuka ini termasuk antarmuka X-Windows yang digunakan
di banyak lingkungan UNIX, dan antarmuka yang sebelumnya dikembangkan untuk PC-
DOS-DOS dan Apple Macintoshes.
Antarmuka pengguna modern yang menawarkan fungsionalitas yang jauh lebih
banyak dengan yang disediakan aplikasi jendela grafis tunggal, dan menggunakan jendela
itu untuk bertukar data melalui tindakan pengguna. Misalnya, untuk mengunduh file,
biasanya mungkin untuk memindahkan ikon yang mewakili file itu ke ikon yang mewakili
tempat sampah. Demikian juga, pengolah kata yang banyak membantu pengguna untuk
memindahkan teks dalam dokumen ke posisi lain hanya dengan menggunakan mouse.
Kami kembali ke antarmuka pengguna di Chap. 3.
Banyak aplikasi client-server dapat dibangun dari sekitar tiga bagian yang berbeda:
bagian yang terkait dengan pengguna, bagian yang digunakan pada database atau file
sistem, dan bagian tengah yang menyediakan fungsionalitas inti dari suatu aplikasi. Bagian
tengah ini disusun secara logis pada tingkat penempatan. Berbeda dengan antarmuka
pengguna dan data dasar, tidak ada banyak aspek pada tingkat pengaturan. Oleh karena
itu, kami akan memberikan beberapa contoh untuk membuat tingkat ini lebih jelas.
Sebagai contoh pertama, pertimbangkan mesin pencari Internet. Mengabaikan
semua spanduk animasi, gambar, dan pembalut jendela mewah lainnya, antarmuka
pengguna mesin pencari sangat sederhana: pengguna menelusurikan untaian kata kunci
dan kemudian disediakan dengan daftar judul halaman Web. Bagian belakang dibuat oleh
data dasar halaman web yang telah dibuat sebelumnya dan diindeks. Inti dari mesin pencari
adalah program yang mengubah string kata kunci pengguna menjadi satu atau lebih query
database. Selanjutnya peringkat hasil menjadi daftar, dan mengubah daftar itu menjadi
konversi halaman HTML. Di dalam model klien-server, bagian mengambil informasi ini
ditempatkan pada tingkat penyelesaian. Gambar 2-4 menunjukkan organisasi ini.

Gambar 2-4. Organisasi yang disederhanakan dari mesin pencari Internet

menjadi tiga lapisan yang berbeda.
Sebagai contoh kedua, menyetujui sistem pendukung keputusan untuk pialang
saham. Analog dengan mesin pencari, sistem seperti itu dapat dibagi menjadi ujung depan
menggunakan antarmuka pengguna, ujung belakang untuk mengakses database dengan
data keuangan, dan analisis program antara keduanya. Analisis data keuangan diperlukan
metode dan teknik canggih dari statistik dan kecerdasan buatan. Dalam beberapa kasus,
inti dari sistem pendukung Keputusan keuangan mungkin perlu dieksekusi pada komputer
berkinerja tinggi untuk mencapai throughput dan responsif yang diharapkan dari
penggunanya.
Sebagai contoh terakhir, jawab paket desktop biasa, yang terdiri dari pengolah kata,
aplikasi spreadsheet, fasilitas komunikasi, dan sebagainya. Suite "kantor" yang didukung
oleh pengguna umum yang mendukung dokumen majemuk, dan didukung pada file dari
direktori home pengguna. (Dalam lingkungan kantor, direktori rumah ini sering ditempatkan
pada file server jarak jauh.)
Tingkat data dalam model yang disediakan klien-server program yang
mempertahankan data aktual di mana aplikasi dioperasikan. Properti penting dari level ini
adalah data yang disetujui persisten, yaitu, bahkan jika tidak ada aplikasi yang sedang
berjalan, data akan disimpan di tempat untuk digunakan selanjutnya. Dalam bentuknya yang
paling sederhana, data level terdiri dari file sistem, tetapi lebih umum untuk menggunakan
database yang lengkap. Dalam model client-server, data level biasanya diimplementasikan
di sisi server.
Selain hanya menyimpan data, data level juga bertanggung jawab untuk data yang
dijamin di berbagai aplikasi. Pada basis data yang sedang digunakan, perhatikan
konsistensi maksud dari metadata seperti deskripsi tabel, batasan entri dan metadata
khusus aplikasi juga tergantung pada level ini. Misalnya, dalam kasus abank, kami mungkin
ingin membuat kompilasi kartu kredit yang sesuai dengan nilai tertentu. Jenis informasi ini
dapat diaktifkan melalui pemicu adat database yang mengaktifkan ahandler untuk pemicu
itu pada saat yang tepat.
Di sebagian besar lingkungan yang berorientasi bisnis, tingkat data diatur sebagai
basis data relasional. Kemandirian data sangat penting di sini .. Data mengatur aplikasi
independen membuat perubahan organisasi dalam tidak memengaruhi aplikasi, dan aplikasi
juga tidak memengaruhi data organisasi. Menggunakan basis data relasional dalam model
klien-server membantu mencapai tingkat data, proses dan data dianggap independen.
Namun, basis data relasional tidak selalu merupakan pilihan ideal. Fitur khas dari
banyak aplikasi adalah apa yang dikerjakan pada tipe data kompleks yang lebih mudah
dimodelkan dalam hal objek dari dalam hal hubungan. Contoh jenis data seperti ini dari
poligon dan lingkaran sederhana hingga representasi desain, seperti halnya dengan sistem
desain berbantuan komputer (CAD).
Dalam kasus-kasus di mana operasi data lebih mudah dinyatakan dalam hal
manipulasi objek, masuk akal untuk mengimplementasikan level data melalui database
berorientasi objek atau objek-relasional. Basis data tipe terbaru telah memperoleh
popularitas karena basis data ini dibangun di atas model data relasional yang tersebar luas,
sambil menawarkan keuntungan yang diberikan oleh objek-sponsor.
Perbedaan menjadi tiga level logis seperti yang dibahas pada edisi ini,
menunjukkan jumlah yang dihitung pada aplikasi client-server di beberapa mesin.
Organisasi paling sederhana hanya memiliki dua jenis mesin:
 1. Mesin klien yang hanya berisi program yang mengimplementasikan
(antarmuka dari) level pengguna antarmuka
2. Mesin server yang berisi diselesaikan, yaitu program yang
mengimplementasikan level pengumpulan dan data
Dalam organisasi ini semuanya diselesaikan oleh server. Sementara klien pada
dasarnya tidak lebih dari terminal bodoh, mungkin dengan antarmuka yang cukup grafis.
Ada banyak yang lain, di mana kami mencoba beberapa yang lebih umum di bagian ini.
Salah satu untuk server dan program adalah untuk memperbaharui program-
program di aplikasi lapisan sebelumnya di berbagai mesin, seperti yang dibahas pada
Gambar. 2-5 [lihat juga Umar (1997); dan Jing et al. (1999)]. Sebagai langkah pertama, kami
membuat perbedaan antara hanya dua jenis mesin: mesin klien dan mesin server, yang
mengarahkan ke apa yang juga disebut sebagai arsitektur twotier (secara fisik).

Gambar 2-5. Organisasi klien-server alternative (a)-(e).

Satu organisasi yang mungkin memiliki hanya bagian terminal-dependen dari
antarmuka pengguna pada mesin klien, seperti yang antarmuka dalam Gambar. 2-5 (a),
dan menyediakan aplikasi jarak jauh ke atas penyajian data mereka. Alternatifnya
adalah menghubungkan seluruh perangkat lunak lalu lintas pengguna sisi klien, seperti
yang diminta pada Gambar 2-5 (b). Dalam kasus seperti itu, kami membagi aplikasi
menjadi front end grafis, yang berkomunikasi dengan seluruh aplikasi (yang berada di
server) melalui protokol khusus aplikasi. Dalam model ini, ujung depan (perangkat lunak
klien) tidak diperlukan selain yang diperlukan untuk aplikasi antarmuka.
Melanjutkan sepanjang garis hukuman ini, kita juga dapat memulai aplikasi ke
ujung depan, seperti yang pindah pada Gambar. 2-5 (c). Contoh di mana ini masuk akal
adalah di mana aplikasi menyediakan suatu bentuk yang perlu disediakan sebelum
dapat digunakan. Ujung depan kemudian dapat menyetujui kebenaran dan konsistensi
Formulir, dan di mana perlu keterlibatan dengan pengguna. Contoh lain dari organisasi
Gambar 2: .5 (c), adalah dari pengolah kata di mana pengeditan dasar dijalankan pada
sisi klien tempat mereka berkomunikasi pada data yang disimpan dalam cache, atau di
dalam memori lokal. Tapi di mana alat pendukung canggih seperti eksekusi ejaan dan
tata bahasa mengeksekusi di sisi server.
Dalam banyak lingkungan client-server, organisasi yang membahas Gambar 2-
5 (d) dan Gambar 2-5 (e) sangat populer. Organisasi-organisasi ini digunakan di mana
mesin klien adalah PC atau workstation, terhubung melalui jaringan ke sistem file atau
basis data terdistribusi. Pada dasarnya, sebagian besar aplikasi berjalan pada mesin
klien, tetapi semua operasi pada file atau entri database masuk ke server. Sebagai
contoh, banyak aplikasi perbankan dijalankan pada pengguna akhir di mana pengguna
menyediakan transaksi dan semacamnya. Setelah selesai, aplikasi menghubungi basis
data di server bank dan mengunggah transaksi untuk diproses lebih lanjut. Gambar 2-5
(e) mewakili disk di mana klien lokal berisi bagian dari data. Misalnya, saat menjelajah
Web,
Kami mengulas selama beberapa tahun terakhir telah ada di atas. Untuk
Gambar 2-5 (d) dan Gambar 2-5 (e) dalam hal itu perangkat lunak yang disediakan klien
pada mesin pengguna akhir. Dalam kasus ini, sebagian besar data yang disimpan dan
disimpan disimpan di sisi server. Alasannya sederhana: meskipun mesin klien
melakukan banyak hal, mereka juga lebih bermasalah untuk dikelola. Memiliki lebih
banyak fungsi pada mesin klien Membuat perangkat lunak sisi klien lebih rentan
terhadap masalah dan lebih bergantung pada platform yang mendasari klien (yaitu,
sistem operasi dan sumber daya). Dari perspektif manajemen sistem, memiliki apa yang
disebut klien gemuk tidak optimal. Alih-alih klien lebih banyak diwakili oleh organisasi
yang menyetujui Gambar 2-5 (a) - (c) jauh lebih mudah,
Meminta tren ini tidak hanya berarti kita tidak lagi membutuhkan sistem
terdistribusi. Memilih, yang kami lihat adalah solusi sisi server yang semakin
terdistribusi, satu server yang diganti oleh beberapa server yang berjalan pada mesin
yang berbeda. Secara khusus, kompilasi berbeda hanya mesin klien dan server seperti
yang telah kami perbaiki, kami yang menolak server kadang-kadang perlu dilakukan
sebagai klien, seperti yang dilakukan pada Gambar. 2-6, yang mengarah ke (arsitektur
fisik) tiga arsitektur berjenjang.
Dalam arsitektur ini, program yang membentuk bagian dari tingkat atas
ditempatkan pada server terpisah, tetapi juga dapat diberikan sebagian di seluruh mesin
klien dan server. Contoh khas di mana arsitektur tiga tingkat digunakan adalah
 Gambar 2-6. Contoh server yang bertindak sebagai klien.
dalam penyelesaian transaksi. Seperti yang kita bahas dalam Bab. 1, proses
terpisah, yang disebut monitor diselesaikan transaksi, mengoordinasikan semua
transaksi di server data yang mungkin berbeda.
Contoh lain, tetapi sangat berbeda di mana kita sering melihat arsitektur tiga
tingkat dalam situs web. Dalam hal ini, server Web bertindak sebagai titik masuk ke
situs, meminta permintaan server aplikasi tempat yang sedang terjadi. Server aplikasi
ini, pada dasarnya, dirancang dengan basis data server. Misalnya, aplikasi server
mungkin bertanggung jawab untuk menginstal kode untuk pembaruan yang tersedia
dari beberapa barang yang ditawarkan oleh toko buku elektronik. Untuk melakukan,
mungkin perlu dengan database yang menyediakan data mentah. Kami akan kembali
ke organisasi situs Web di Bab. 12.
b) Arsitektur Terdesentralisasi
Arsitektur server klien multitier adalah penyelesaian langsung dari aplikasi yang
menjadi antarmuka pengguna, komponen yang terkait, dan tingkat data. Tingkatan yang
berbeda langsung dengan pengaturan aplikasi yang logis. Di banyak Lingkungan bisnis,
disetujui terdistribusi atas kontribusi aplikasi klien-server untuk arsitektur multitier. Kami
menyebut jenis distribusi ini sebagai distribusi vertikal. Ciri khas dari distribusi vertikal
dapat dilakukan dengan menggunakan komponen yang berbeda pada mesin yang
berbeda. Istilah ini terkait dengan konsep fragmentasi vertikal seperti yang digunakan
dalam basis data relasional terdistribusi, di mana ini berarti tabel dibagi berdasarkan
kolom, dan kemudian didistribusikan di beberapa mesin (Oszu dan Valduriez, 1999).
Sekali lagi, dari perspektif manajemen sistem, memiliki distribusi vertikal dapat
membantu: fungsi lengkap dan fisik dibagi di beberapa mesin, di mana setiap mesin
disimpan ke grup fungsi tertentu. Namun, distribusi vertikal hanya satu cara aplikasi
klien-server. Dalam arsitektur modem, distribusi distribusi klien dan server yang
diperhitungkan, yang kami sebut distribusi horisontal. Dalam jenis distribusi ini, klien
atau server dapat secara fisik terpisah menjadi bagian-bagian yang sepenuhnya logis,
tetapi setiap bagian pada bagiannya sendiri dari kumpulan data lengkap, sehingga
menyeimbangkan beban. Pada bagian ini kita akan melihat kelas arsitektur sistem
modern yang mendukung distribusi horisontal, yang dikenal sebagai sistem peer-to-
peer.
Dari perspektif tingkat tinggi, proses yang membentuk sistem peer-to-peer
semuanya sama. Ini berarti fungsi yang perlu dilakukan diwakili oleh setiap proses yang
merupakan sistem terdistribusi. Sebagai akibatnya, banyak interaksi antara proses
simetris: setiap proses akan dilakukan sebagai klien dan server pada saat yang sama
(yang juga disebut sebagai tindakan sebagai servent).
Dengan adanya masalah simetris ini, arsitektur peer-to-peer mengembangkan
seputar pertanyaan bagaimana proses overlay jaringan, yaitu jaringan di mana simpul
yang dibuat oleh proses dan menghubungkan mewakili jaringan komunikasi yang
mungkin (yang dimaksud adalah terkait dengan koneksi a§TCP). Secara umum, suatu
proses tidak dapat berkomunikasi langsung dengan proses lain yang sewenang-
 wenang, tetapi diperlukan untuk mengirim pesan melalui saluran komunikasi yang
tersedia. Overlay jaringan: yang terstruktur dan yang tidak. Kedua jenis ini disurvei luas
di Lua et a1. (2005) bersama dengan banyak contoh. Aberer et a1. (2005) memberikan
referensi arsitektur yang memungkinkan untuk membandingkan formal dari berbagai
jenis sistem peer-to-peer.
 Arsitektur Peer-to-Peer Terstruktur
Dalam arsitektur peer-to-peer terstruktur, overlay jaringan dibangun menggunakan
prosedur deterministik. Sejauh ini prosedur yang paling banyak digunakan adalah proses
melalui tabel hash terdistribusi (DHT). Dalam sistem berbasis DHT, data item diberi kunci
acak dari ruang pengenal besar, seperti pengidentifikasi 128-bit atau 160-bit. Demikian juga,
simpul dalam sistem juga diberi nomor acak dari ruang pengidentifikasi yang sama. Inti dari
setiap sistem berbasis DHT adalah untuk mengimplementasikan yang efisien dan
deterministik yang unik memetakan data kunci ke pengidentifikasi hubungan berdasarkan
beberapa metrik jarak (Balakrishnan, 2003). Yang paling penting, kompilasi mencari data
barang, alamat jaringan dari perubahan yang bertanggung jawab untuk data data yang
diminta. Secara efektif,
Misalnya, dalam sistem Chord (Stoica et al., 2003) node secara logis diatur dalam
sebuah cincin sehingga item data dengan kunci k dipetakan ke node dengan id
pengidentifikasi terkecil. Node ini disebut sebagai penerus kunci k dan dilambangkan
sebagai succ (k), seperti yang ditunjukkan pada Gambar 2-7. Untuk benar-benar mencari
item data, aplikasi yang berjalan pada node sewenang-wenang kemudian akan memanggil
fungsi LOOKUP (k) yang kemudian akan memulai kembali alamat jaringan succ (k). Pada
titik itu, aplikasi dapat menghubungi node untuk mendapatkan data item acopy.

Gambar 2-7. Memetakan data barang ke simpul Chord.

Kami tidak akan masuk ke algoritma untuk mencari kunci sekarang, tetapi membuka
diskusi sampai Chap. 5 di mana kami menjelaskan detail berbagai sistem penamaan.
Sebagai gantinya, mari kita sepakat tentang simpul yang disediakan sendiri untuk overlay
jaringan, atau, dengan kata lain, manajemen asosiasi. Berikut ini, penting untuk dipahami
Itu mencari kunci tidak diambil organisasi logis dari node di ring dari Gambar. 2-7.
Diharapkan, setiap simpul akan mempertahankan pintasan ke simpul yang ada diselesaikan
sehingga dapat dilakukan dalam jumlah langkah O (log (N), di mana N adalah jumlah simpul
yang dihasilkan dalam overlay.
Sekarang menerima Chord lagi. Membuat sistem ingin bergabung dengan sistem,
dimulai dengan membuat pengidentifikasi acak. Berharap ruang pengenal cukup besar,
maka generator asalkan angka memiliki kualitas yang baik, probabilitasnya. Dari
menghasilkan pengidentifikasi yang sudah ditentukan Kemudian, simpul cukup melakukan
pencarian pada id, yang akan pindah alamat jaringan succiid). Pada titik itu, titik yang
tergabung dapat dengan mudah menghubungi succiid) dan pendahulunya dan
memasukkan cincin ke dalam. Tentu saja, diperlukan ini memerlukan setiap simpul juga
menyimpan informasi pada pendahulunya. Penyisipan juga menghasilkan setiap item data
yang kuncinya sekarang terkait dengan nodeid, ditransfer darisucciid).
Meninggalkan sama dengan mudahnya: simpul id mengirim kepergiannya ke
pendahulunya dan penggantinya, dan mentransfer item datanya ke succ (id).
DHT lainnya. Sebagai contoh, mengingat Content Addressable Network (CAN), yang
dibahas dalam Ratnasamy et a1. (2001). BISA mengeluarkan ruang koordinat Kartesius d-
dimensi, yang sepenuhnya dipartisi di antara semua simpul yang lengkap dalam sistem.
Untuk tujuan ilustrasi. mari kita bahas hanya edisi 2, yang contohnya dibahas pada Gambar
2-8.

Gambar 2-8. (a) Memetakan data barang ke simpul di CAN , (b) Memisahakan wilayah
kompilasi node bergabung
Gbr.2-8 (a) menggambarkan ruang dua dimensi [0, l] x [O, 1] dibagi di antara enam
simpul. Setiap node memiliki wilayah terkait. Setiap item data dalam BISA akan diberi titik
unik di ruang ini, setelah itu juga jelas menentukan mana yang bertanggung jawab atas
data tersebut (membahas item data yang berada di perbatasan beberapa wilayah, yang
digunakan aturan penetapan deterministik).
Membuat simpul P ingin bergabung dengan sistem CAN, ia mengambil titik arbitrer dari
ruang koordinat dan kemudian mencari simpul Q di wilayah mana titik itu jatuh. Pencarian
ini dilakukan melalui routing yang berbasis posisi. yang dibacanya ditangguhkan hingga
bab-bab selanjutnya. Node Q kemudian membagi wilayahnya menjadi dua bagian, seperti
yang dibahas pada Gambar 2-8 (b). dan satu setengah ditugaskan ke simpul P. Node
pelacakan tetangga mereka, yaitu, simpul yang bertanggung jawab untuk wilayah yang
 ditentukan. Saat membagi suatu wilayah, lingkaran yang tergabung dengan P dapat dengan
mudah mengetahui siapa tetangga barunya dengan mempertanyakan P. Seperti pada
Chord, data barang yang menjadi tanggung jawab lingkaran P sekarang ditransfer dari
lingkar Q.
Meninggalkan sedikit masalah dalam CAN. Asumsikan itu pada Gambar 2-8. simpul
dengan koordinat (0,6, 0,7) daun. Wilayahnya akan menetapkan salah satu tetangganya,
katakanlah lingkaran di (0.9.0.9), tetapi jelas bahwa hanya kumpulannya dan mendapatkan
persegi panjang tidak dapat dilakukan. Dalam hal ini, ganti di (0.9.0.9) akan dengan mudah
menjelaskan wilayah itu dan memberi tahu tetangga tentang fakta ini. Jelas sekali. hal ini
dapat menyebabkan pembagian ruang koordinat yang kurang simetris, untuk alasan tentang
proses latar belakang dimulai untuk mempartisi ulang seluruh ruang.
 Arsitektur Peer-to-Peer Tidak Terstruktur
Sistem peer-to-peer yang tidak terstruktur sebagian besar mengandalkan kerumitan
untuk membangun jaringan overlay. Gagasan peran adalah setiap simpul yang didukung
daftar tetangga, tetapi daftar ini dibangun dengan cara yang kurang acak. Demikian juga,
data barang diasumsikan ditempatkan secara acak pada simpul. Bantuan, kompilasi simpul
perlu menemukan data tertentu, satu-satunya hal yang dapat dilakukan efektif membanjiri
jaringan dengan permintaan pencarian (Risson and Moors, 2006). Kami akan kembali
mencari di jaringan hamparan tidak terstruktur di Bab. 5, dan untuk saat ini komposisi pada
manajemen keanggotaan.
Salah satu tujuan dari banyak sistem peer-to-peer yang tidak terstruktur membangun
overlay yang dirancang grafik acak. Model dasar adalah setiap simpul yang menyimpan
daftar tetangga c, di mana, idealnya, masing-masing tetangga mewakili node yang dipilih
secara acak dari set node saat ini. Daftar tetangga juga disebut sebagai tampilan sebagian.
Ada banyak cara untuk membangun seperti itu. Jelasity et al. (2004,2005a) telah
mengembangkan evaluasi kerja yang meningkatkan pengujian yang berbeda untuk
konstruksi overlay untuk memungkinkan evaluasi dan implementasi. Dalam pembahasan
kerja ini, diasumsikan bahwa simpul secara teratur bertukar entri dari pandangan parsial
mereka. Setiap entri menentukan titik yang ada di dalam jaringan, dan memiliki usia yang
sesuai yang diperhitungkan.
Utas aktif mengambil publikasi untuk berkomunikasi dengan putaran lain. Ini memilih
putaran itu dari tampilan parsial saat ini. Dengan menyetujui entri yang perlu diajukan ke
rekan yang dipilih, itu dibuat dengan membuat penyangga yang berisi entri c / 2 + I, termasuk
entri yang memfasilitasi sendiri. Entri diambil dari tampilan parsial saat ini.
W \ ne nocel ~ a \ ~ Mode OinpuU itu ~ l \\ ~ a \. \ 1m Q 'ieSp ~ il ~ e \ "' i ~ IDfue ~ e \
e '\: .. ~ \\ peer. Sebaya itu, sementara itu, juga akan membangun penyangga dengan cara
utas pasif yang sesuai dengan Gambar.2- 9 (b), yang kegiatannya sangat mirip dengan utas
aktif.
Poin krusial adalah pembangunan pandangan parsial baru. Pandangan ini, untuk
memulai dan juga untuk rekan yang dihubungi, akan berisi persis, c entri, yang sebagiannya
akan berasal dari buffer yang diterima. Intinya, ada dua cara untuk membangun pandangan
baru. Pertama, kedua node dapat memutuskan untuk membuang entri yang telah mereka
kirim ke toeach lainnya. Secara efektif, ini berarti bahwa mereka akan bertukar sebagian
dari pandangan asli mereka. Pendekatan kedua adalah membuang sebanyak mungkin entri
lama. Secara umum, ternyata kedua pendekatan tersebut saling melengkapi [lihat Jelasity
et al. (2005a) untuk detailnya]. Ternyata banyak protokol manajemen keanggotaan untuk
overlay yang tidak terstruktur cocok dengan kerangka kerja ini. Ada sejumlah pengamatan
menarik untuk dilakukan.
Pertama, mari kita asumsikan bahwa ketika sebuah simpul ingin bergabung, kontaklah
dengan simpul lain yang arbitrer, mungkin dari daftar titik akses yang terkenal. Jalur akses
ini hanyalah anggota reguler overlay, kecuali bahwa kami dapat menganggapnya sebagai
sangat Tindakan oleh utas aktif (berulang secara berkala):

Tindakan oleh utas pasif:

Gambar 2-9. (a) Langkah-langkah yang diambil oleh utas pasif.

tersedia. Dalam kasus ini, ternyata protokol yang menggunakan mode hanya push atau
hanya mode tarik dapat dengan mudah menyebabkan overlay terputus. Dengan kata lain,
kelompok node akan menjadi terisolasi dan tidak akan pernah dapat mencapai setiap node
lain dalam jaringan. Jelas, ini adalah fitur yang tidak diinginkan, untuk alasan itu lebih masuk
akal tolet node bertukar entri.
Kedua, meninggalkan jaringan ternyata menjadi operasi yang sangat sederhana
asalkan node bertukar pandangan parsial secara teratur. Dalam hal ini, sebuah simpul dapat
dengan mudah pergi tanpa memberitahukan simpul lain. Apa yang akan terjadi adalah
ketika sebuah simpul P memilih salah satu tetangganya yang tampak, katakan simpul Q,
 dan menemukan bahwa Q tidak lagi merespons, ia hanya menghapus entri dari tampilan
parsialnya untuk memilih rekan lain. Ternyata ketika membangun tampilan parsial baru,
sebuah simpul mengikuti kebijakan untuk membuang entri lama sebanyak mungkin, node
yang berangkat akan cepat dilupakan. Dengan kata lain, entri yang merujuk pada simpul
yang sudah disiapkan akan secara otomatis dihapus dari tampilan sebagian.
Namun, ada harga yang harus dibayar ketika strategi ini diikuti. Untuk menjelaskan,
pertimbangkan untuk node P set node yang memiliki entri dalam tampilan parsial mereka
yang mengacu pada P. Secara teknis, ini dikenal sebagai indegree dari sebuah node.
Semakin tinggi derajat simpul P adalah, semakin tinggi probabilitas bahwa beberapa simpul
lain akan memutuskan untuk menghubungi P. Dengan kata lain, ada bahaya bahwa P akan
menjadi simpul yang populer, yang dapat dengan mudah membawanya ke posisi yang tidak
seimbang mengenai beban kerja. Secara sistematis membuang entri lama ternyata
mempromosikan node ke entri yang memiliki derajat tinggi. Ada juga trade-off lainnya, yang
kami rujuk ke Jelasity et al. (2005a).
 Manajemen Topologi Jaringan Overlay
Meskipun akan terlihat bahwa sistem peer-to-peer terstruktur dan tidak terstruktur
membentuk kelas independen yang ketat, ini sebenarnya tidak terjadi [lihat juga Castro et
al. (2005)]. Salah satu pengamatan utama adalah bahwa dengan bertukar dan memilih
makanan dengan hati-hati dari pandangan parsial, adalah mungkin untuk membuat dan
memelihara topologi spesifik dari jaringan overlay. Manajemen topologi ini dicapai dengan
mengadopsi pendekatan dua lapis, seperti yang ditunjukkan pada Gambar. 2-10.

Gambar 2-10. Pendekatan dua lapis untuk membangun dan memelihara topologi overlay
spesifik menggunakan teknik dari sistem peer-to-peer yang tidak terstruktur.

Lapisan terendah merupakan sistem peer-to-peer tidak terstruktur di mana node

bertukar entri secara berkala dari pandangan parsial mereka dengan tujuan untuk
mempertahankan grafik acak yang akurat. Keakuratan dalam kasus ini merujuk pada
kenyataan bahwa tampilan parsial harus diisi dengan alamat yang merujuk ke node
langsung yang dipilih secara acak.
Lapisan terendah melewati tampilan parsialnya ke lapisan yang lebih tinggi, tempat
pemilihan entri tambahan dilakukan. Ini kemudian mengarah ke daftar kedua dari satu
pelabuhan yang sesuai dengan topologi yang diinginkan. Jelasity dan Babaoglu (2005)
mengusulkan untuk menggunakan fungsi peringkat dimana node dipesan sesuai dengan
beberapa kriteria relatif terhadap node yang diberikan. Fungsi peringkat sederhana adalah
 untuk memesan satu set node dengan meningkatkan jarak dari node yang diberikan P.
Dalam hal itu, node P akan secara bertahap membangun daftar tetangga terdekat, asalkan
lapisan terendah terus melewati node yang dipilih secara acak.
Sebagai ilustrasi, pertimbangkan kisi logika ukuran N x N dengan simpul ditempatkan
di setiap titik kisi. Setiap node diperlukan untuk memelihara daftar c tetangga terdekat, di
mana jarak antara node di (aJ.a2) dan (b1, b2) didefinisikan sebagai dl + d2, dengan d; =
min (N-1ai-bil , lai-bil). Jika lapisan terendah secara berkala mengeksekusi protokol seperti
yang diuraikan pada Gambar 2-9, topologi yang akan berkembang adalah torus, ditunjukkan
dalam Gambar. 2-11.

Gambar 2-11. Menghasilkan jaringan overlay tertentu menggunakan sistem peer-to-

peer dua lapis yang tidak terstruktur [diadaptasi dengan izin dari Jelasity dan Babaoglu
(2005)].
Tentu saja, fungsi peringkat yang sangat berbeda dapat digunakan. Khususnya yang
terkait untuk menangkap kedekatan semantik dari item data yang disimpan di peer node
adalah menarik. Kedekatan ini memungkinkan untuk pembangunan jaringan hamparan
semantik yang memungkinkan algoritma pencarian yang sangat efisien dalam sistem peer-
to-peer yang tidak terstruktur. Kami akan kembali ke sistem ini di Bab. 5 ketika kita
membahas penamaan berbasis atribut.
 Superpeers (Petugas super)
Khususnya dalam sistem peer-to-peer yang tidak terstruktur, menemukan item data
yang relevan dapat menjadi masalah ketika jaringan tumbuh. Alasan untuk masalah
skalabilitas ini sederhana: karena tidak ada cara deterministik untuk memintakan
permintaan penempatan ke item data tertentu, pada dasarnya satu-satunya teknik yang bisa
dilakukan sebuah node adalah membanjiri permintaan. Ada berbagai cara di mana banjir
dapat dibendung, seperti yang akan kita bahas dalam Bab. 5, tetapi sebagai alternatif
banyak sistem peer-to-peer telah mengusulkan untuk menggunakan node khusus yang
mempertahankan indeks item data.
Ada situasi lain di mana meninggalkan sifat simetris dari sistem rekan-rekan masuk akal.
Pertimbangkan kolaborasi node yang menawarkan sumber daya satu sama lain. Misalnya,
dalam jaringan pengiriman konten kolaboratif (CDN), node dapat menawarkan
penyimpanan untuk hosting salinan halaman Web yang memungkinkan klien Web untuk
mengakses halaman terdekat, dan dengan demikian untuk mengaksesnya dengan cepat.
Dalam hal ini simpul P mungkin perlu mencari sumber daya di bagian tertentu dari jaringan.
Dalam hal itu, memanfaatkan abroker yang mengumpulkan penggunaan sumber daya untuk
sejumlah node yang berdekatan satu sama lain akan memungkinkan untuk dengan cepat
memilih anoda dengan sumber daya yang memadai.
Node seperti yang mempertahankan indeks atau bertindak sebagai broker umumnya
disebut sebagai superpeers. Seperti namanya, superpeers sering juga diorganisir dalam
jaringan peer-to-peer, yang mengarah ke organisasi hierarkis seperti yang dijelaskan dalam
Yang dan Garcia-Molina (2003). Contoh sederhana dari organisasi seperti itu ditunjukkan
pada Gambar 2-12. Dalam organisasi ini, setiap rekan reguler terhubung sebagai klien ke
superpeer. Semua komunikasi dari dan ke rekan tetap berlanjut melalui superpeer terkait
rekan itu.

Gambar 2-12. Organisasi hierarki node menjadi jaringan superpeer.

Dalam banyak kasus, relasi klien-superpeer diperbaiki: setiap kali rekan biasa
bergabung dengan jaringan, itu melampirkan ke salah satu superpeers dan tetap melekat
sampai meninggalkan jaringan. Jelas, diharapkan superper adalah proses berumur panjang
dengan ketersediaan tinggi. Untuk mengimbangi kemungkinan perilaku tidak stabil dari
superpeer, skema cadangan dapat digunakan, seperti memasangkan setiap superpeer
dengan yang lain dan mengharuskan klien untuk melampirkan keduanya.
Memiliki hubungan tetap dengan superpeer mungkin tidak selalu menjadi solusi terbaik.
Misalnya, di dalam jaringan berbagi offile, mungkin lebih baik untuk melampirkan ke
superpeer yang menyimpan indeks file yang biasanya diminati oleh klien. Jika ada
kesempatan yang lebih besar bahwa ketika klien mencari file tertentu, superpeer-nya akan
tahu di mana menemukannya. Garbacki et al. (2005) menggambarkan skema yang relatif
sederhana di mana hubungan klien-superpeer dapat berubah ketika klien menemukan
superpeers yang lebih baik untuk bergaul. Secara khusus, superpeer yang mengembalikan
hasil operasi pencarian diberikan preferensi daripada superpeer lainnya.,
Seperti yang telah kita lihat, jaringan peer-to-peer menawarkan cara yang fleksibel bagi
node untuk bergabung dan meninggalkan jaringan. Namun, dengan jaringan superpeer
masalah baru diperkenalkan, yaitu bagaimana memilih node yang memenuhi syarat untuk
menjadi superpeer. Masalah ini terkait erat dengan masalah pemilihan pemimpin, yang kita
diskusikan di Chap. 6, ketika kita kembali untuk memilih superpeers di jaringan apeer-to-
peer.
 c) Arsitektur Hibrida
Sejauh ini, kami telah fokus pada arsitektur client-server dan sejumlah arsitektur
peer-peer. Banyak sistem terdistribusi menggabungkan fitur arsitektur, seperti yang
telah kita temui di jaringan superpeer. Pada bagian ini kita akan melihat beberapa kelas
spesifik dari sistem terdistribusi di mana solusi client-server dikombinasikan dengan
arsitektur terdesentralisasi.
 Sistem Edge-Server
Kelas penting dari sistem terdistribusi yang diatur menurut arsitektur hybrid dibentuk
oleh sistem server-tepi. Sistem ini digunakan di Internet di mana server ditempatkan "di
ujung" jaringan. Tepi ini dibentuk oleh batas antara jaringan perusahaan dan Internet yang
sebenarnya, misalnya, sebagaimana disediakan oleh Penyedia Layanan Internet (ISP).
Demikian juga, di mana pengguna akhir di rumah terhubung ke Internet melalui ISP mereka,
ISP dapat dianggap berada di ujung Internet. Ini mengarah ke organisasi umum yang
ditunjukkan pada Gambar. 2-13.

Gambar 2-13. Melihat Internet sebagai terdiri dari kumpulan server tepi.

Pengguna akhir, atau klien pada umumnya, terhubung ke Internet melalui server
tepi. Tujuan utama server tepi adalah untuk menyajikan konten, mungkin setelah
menerapkan fungsi filter dan transcoding. Lebih menarik adalah fakta bahwa kumpulan
server tepi dapat digunakan untuk mengoptimalkan konten dan distribusi aplikasi. Model
dasar adalah bahwa untuk organisasi tertentu, server satu tepi bertindak sebagai server asal
dari mana semua konten berasal. Server itu dapat menggunakan server tepi lain untuk
mereplikasi halaman Web dan semacamnya (Leff et aI., 2004: Nayate et aI., 2004; dan
Rabinovich and Spatscheck, 2002). Kami akan kembali ke sistem edge-server di Bab. 12
ketika kita membahas solusi berbasis web.
 Sistem Terdistribusi Kolaboratif
Struktur hybrid Terutama digunakan dalam sistem terdistribusi kolaboratif. Masalah
utama dalam banyak sistem ini untuk kali pertama memulai, yang sering kali menggunakan
klien-server tradisional. Setelah bergabung dengan sistem, ia dapat menggunakan yang
sepenuhnya terdesentralisasi untuk kolaborasi.
Untuk membuat hal-hal yang konkret, mari kita pertimbangkan sistem file-sharing
BitTorrent (Cohen, 2003). BitTorrent adalah sistem pengunduhan file apeer-to-peer. Kerja
utamanya ditunjukkan pada Gambar. 2-14 Gagasan dasarnya adalah bahwa ketika
pengguna akhir mencari file, ia mengunduh potongan file dari pengguna lain sampai
potongan yang diunduh dapat dikumpulkan bersama-sama menghasilkan file lengkap.
Tujuan desain yang penting adalah untuk memastikan kolaborasi. Dalam sebagian besar
sistem file-sharing, sebagian besar peserta hanya mengunduh file tetapi berkontribusi
hampir tidak ada (Adar dan Huberman, 2000; Saroiu et al., 2003; dan Yang et al., 2005).
Untuk tujuan ini, file hanya dapat diunduh ketika klien mengunduh menyediakan konten
kepada orang lain. Kami akan segera kembali ke perilaku "gayung bersambut" ini.

Gambar 2-14. Kerja utama BitTorrent [diadaptasi dengan izin dari Pouwelse et al.
(2004)].
Untuk mengunduh ame, pengguna perlu mengakses direktori global, yang
merupakan salah satu dari beberapa situs Web terkenal. Direktori semacam itu berisi
referensi ke apa yang disebut file .torrent. File .torrent berisi informasi yang diperlukan untuk
mengunduh file tertentu. Secara khusus, ini mengacu pada apa yang dikenal sebagai
pelacak, yang merupakan server yang menjaga akun akurat dari node aktif yang memiliki
(potongan) dari file yang diminta. Nodeone aktif yang sedang mengunduh file lain. Jelas,
akan ada banyak pelacak yang berbeda, meskipun (umumnya hanya akan ada satu pelacak
per file (atau koleksi file).
Setelah node telah diidentifikasi dari mana chunks dapat diunduh, node
pengunduhan secara efektif menjadi aktif. Pada titik itu, ia akan dipaksa untuk membantu
orang lain, misalnya dengan memberikan potongan file yang sedang diunduh yang belum
dimiliki orang lain. Penegakan ini berasal dari aturan sederhana: jika kode, perhatikan
bahwa node Q mengunduh lebih banyak daripada mengunggah, P dapat memutuskan untuk
mengurangi laju pengiriman data keQ. Skema ini berfungsi dengan baik asalkan P memiliki
sesuatu untuk diunduh dari Q. Untuk alasan ini, node sering diberikan dengan referensi ke
banyak node lain yang menempatkan mereka pada posisi yang lebih baik untuk
memperdagangkan data.
Jelas, BitTorrent menggabungkan solusi terpusat dengan desentralisasi. Ternyata,
hambatan dari sistem ini, tidak mengherankan, dibentuk oleh pelacak. Sebagai contoh lain,
pertimbangkan jaringan distribusi konten kolaboratif Globule (Pierre dan van Steen, 2006).
Globule sangat menyerupai arsitektur edgeerver yang disebutkan di atas. Dalam hal ini, alih-
alih server tepi, pengguna akhir (tetapi juga organisasi) secara sukarela menyediakan server
Web yang disempurnakan yang mampu berkolaborasi dalam replikasi halaman Web. Dalam
bentuknya yang paling sederhana, setiap server memiliki komponen berikut:
1. Komponen yang dapat mengarahkan permintaan klient ke server lain.
2. Komponen untuk menganalisis pola akses.
3. Komponen untuk mengelola aplikasi halaman Web.
 Server yang disediakan oleh Alice adalah server Web yang biasanya menangani
lalu lintas untuk situs Web Alice dan disebut server asal untuk situs itu. Ini berkolaborasi
dengan server lain, misalnya, yang disediakan oleh Bob, untuk meng-host halaman dari
situs Bob. Dalam hal ini, Globule adalah sistem terdistribusi yang terdesentralisasi.
Permintaan untuk situs Web Alice awalnya diteruskan ke servernya, pada titik mana mereka
dapat dialihkan ke salah satu server lain. Pengalihan terdistribusi juga didukung.
Namun, Globule juga memiliki komponen yang terpusat dalam bentuk brokernya.
Pialang bertanggung jawab untuk mendaftarkan server, dan membuat server ini diketahui
orang lain. Server berkomunikasi dengan broker sepenuhnya analog dengan apa yang
diharapkan dalam sistem client-server. Untuk alasan ketersediaan, broker dapat direplikasi,
tetapi seperti yang akan kita bahas nanti dalam buku ini, tipe replikasi ini diterapkan secara
luas untuk mencapai komputasi client-server yang andal.

C. Arsitektur versus Middleware

Ketika mempertimbangkan masalah arsitektur yang telah kita bahas dengan sofar,
pertanyaan yang muncul di benak adalah di mana middleware cocok. Seperti yang kita bahas dalam
Bab. 1, middleware membentuk lapisan antara aplikasi dan platform terdistribusi. seperti yang
ditunjukkan pada Gambar. 1-1. Tujuan penting adalah untuk memberikan tingkat transparansi
distribusi, yaitu sampai batas tertentu menyembunyikan distribusi data, pemrosesan, dan kontrol dari
aplikasi.
Apa yang biasa dilihat dalam praktik adalah bahwa sistem middleware sebenarnya
mengikuti sytle arsitektur tertentu. Sebagai contoh, banyak solusi middleware telah mengadopsi
gaya arsitektur berbasis objek, seperti CORBA (OMG. 2004a). Lainnya, seperti TIB / Rendezvous
(TIBCO, 2005) menyediakan middleware yang mengikuti gaya arsitektur berbasis acara. Dalam bab-
bab selanjutnya, kita akan menemukan lebih banyak contoh gaya arsitektur.
Memiliki middleware yang dibentuk sesuai dengan gaya arsitektur tertentu memiliki manfaat
bahwa mendesain aplikasi dapat menjadi lebih sederhana. Namun, kelemahan yang jelas adalah
bahwa middleware mungkin tidak lagi optimal untuk apa yang ada dalam pikiran seorang
pengembang aplikasi. Misalnya, COREA awalnya hanya menawarkan objek yang dapat dipanggil
oleh klien jarak jauh. Belakangan, dirasakan bahwa hanya dengan bentuk interaksi ini yang bersifat
restriktif, maka ditambahkan pola interaksi lain seperti perpesanan. Jelas, menambahkan fitur baru
dapat dengan mudah menyebabkan solusi middleware membengkak.
Selain itu, meskipun middleware dimaksudkan untuk memberikan transparansi distribusi,
pada umumnya dirasakan bahwa solusi spesifik harus dapat disesuaikan dengan persyaratan
aplikasi. Salah satu solusi untuk masalah ini adalah membuat beberapa versi sistem middleware, di
mana setiap versi dirancang untuk kelas aplikasi tertentu. Suatu pendekatan yang umumnya
dianggap lebih baik adalah membuat sistem middleware sehingga mereka mudah untuk
mengkonfigurasi, beradaptasi, dan menyesuaikan sesuai kebutuhan oleh suatu aplikasi. Akibatnya,
sistem sekarang sedang dikembangkan di mana pemisahan yang lebih ketat antara kebijakan dan
mekanisme sedang dibuat. Ini telah menyebabkan beberapa mekanisme yang dengannya perilaku
middleware dapat dimodifikasi (Sadjadi dan McKinley, 2003). Mari kita lihat beberapa pendekatan
yang biasa diikuti.
a) Interceptors (Pencegat)
Secara konseptual, pencegat tidak lain adalah perangkat lunak yang akan memutus
aliran kontrol yang biasa dan memungkinkan kode lain (khusus aplikasi) dieksekusi.
Untuk membuat pencegat generik mungkin memerlukan upaya implementasi yang
substansial, seperti yang diilustrasikan dalam Schmidt et al. (2000), dan tidak jelas
apakah dalam kasus-kasus seperti itu umum harus lebih disukai daripada penerapan
terbatas dan kesederhanaan. Juga, dalam banyak kasus hanya memiliki fasilitas
intersepsi terbatas akan meningkatkan manajemen perangkat lunak dan lubang sistem
terdistribusi.
Untuk membuat masalah menjadi konkret, pertimbangkan intersepsi sebagai
didukung dalam banyak sistem terdistribusi berbasis objek. Ide dasarnya sederhana:
objectA dapat memanggil metode yang menjadi milik objek B, sedangkan objectA
berada pada mesin yang berbeda daripadaA. Seperti yang akan kami jelaskan secara
terperinci nanti dalam buku ini, permohonan objek jarak jauh seperti itu dilakukan
sebagai pendekatan tiga langkah:
1. ObjectA menawarkan antarmuka lokal yang persis sama dengan antarmuka
yang ditawarkan oleh objek B. A hanya memanggil metode yang tersedia di
antarmuka itu.
2. Panggilan oleh A ditransformasikan menjadi pemanggilan objek generik,
dimungkinkan melalui antarmuka pemanggilan objek umum yang ditawarkan
oleh middleware pada mesin di mana A berada.
3. Akhirnya, pemanggilan objek generik diubah menjadi pesan yang dikirim
melalui antarmuka jaringan level transportasi seperti yang ditawarkan oleh
sistem operasi lokal A.
Skema ini ditunjukkan pada Gambar. 2-15.

Gambar 2-15. Menggunakan pencegat untuk menangani doa objek jarak jauh.
 Setelah langkah pertama, panggilan B.do_something (value) ditransformasikan
menjadi panggilan umum seperti invoke (B, & do_something, value) dengan referensi
ke metode B dan parameter yang sesuai dengan panggilan. Sekarang bayangkan objek
B direplikasi. Dalam hal ini, setiap replika harus benar-benar dipanggil. Ini adalah titik
yang jelas di mana intersepsi dapat membantu. Apa yang akan dilakukan interseptor
tingkat-permintaan hanya memanggil invoke (B, & do_something, nilai) untuk masing-
masing replika. Keindahan dari ini adalah bahwa objek A tidak perlu mewaspadai
replikasi B, tetapi juga objek middleware tidak perlu memiliki komponen khusus yang
berhubungan dengan panggilan yang direplikasi ini. Hanya pencegat tingkat
permintaan, yang dapat ditambahkan ke middleware yang perlu tahu tentang replikasi
B.
Pada akhirnya, panggilan ke objek jarak jauh harus dikirim melalui jaringan. Dalam
praktiknya, ini berarti bahwa antarmuka pengiriman pesan seperti yang ditawarkan oleh
sistem operasi lokal perlu dipanggil. Pada tingkat itu, pencegat tingkat pesan dapat
membantu mentransfer permohonan ke objek target. Sebagai contoh, bayangkan
bahwa nilai parameter sebenarnya sesuai dengan sejumlah besar data. Dalam hal ini,
mungkin bijaksana untuk memecah-mecah data menjadi bagian-bagian yang lebih kecil
untuk dirakit kembali tempat tujuan. Fragmentasi semacam itu dapat meningkatkan
kinerja atau keandalan. Sekali lagi, middleware tidak perlu menyadari fragmentasi ini;
pencegat tingkat rendah akan secara transparan menangani sisa komunikasi dengan
sistem operasi lokal.
 Pendekatan Umum untuk Perangkat Lunak Adaptif
Apa yang sebenarnya ditawarkan pencegat adalah sarana untuk mengadaptasi
perangkat lunak mereka. Kebutuhan akan adaptasi datang dari kenyataan bahwa
lingkungan di mana aplikasi terdistribusi dieksekusi berubah secara terus menerus.
Perubahan termasuk yang dihasilkan dari mobilitas, variasi yang kuat dalam kualitas
layanan jaringan, perangkat keras yang gagal, dan drainase baterai, antara lain. Alih-alih
membuat aplikasi bertanggung jawab untuk bereaksi terhadap perubahan, tugas ini
ditempatkan di perangkat lunak.
Pengaruh kuat dari lingkungan ini telah membawa banyak perancang middleware
untuk mempertimbangkan pembangunan perangkat lunak adaptif. Namun, perangkat lunak
adaptif belum sesukses yang diperkirakan. Karena banyak peneliti dan pengembang
menganggapnya sebagai aspek penting dari sistem terdistribusi modern, mari kita
perhatikan sejenak. McKinley et al. (2004) membedakan tiga teknik dasar untuk adaptasi
perangkat lunak:
1. Pemisahan masalah
2. Refleksi komputasi
3. Desain berbasis komponen
Memisahkan kekhawatiran berkaitan dengan cara tradisional sistem modularisasi:
pisahkan bagian-bagian yang mengimplementasikan fungsionalitas dari hal-hal yang
mengurus hal-hal lain (dikenal sebagai fungsi ekstra) seperti keandalan, kinerja, keamanan,
dll. Orang dapat berpendapat bahwa mengembangkan middleware untuk aplikasi
 terdistribusi sebagian besar tentang penanganan fungsionalitas ekstra yang independen
dari aplikasi. Masalah utamanya adalah kita tidak dapat dengan mudah memisahkan
fungsionalitas ekstra ini dengan cara modularisasi. Sebagai contoh, hanya menempatkan
keamanan ke dalam modul terpisah tidak akan berhasil. Demikian juga, sulit untuk
membayangkan bagaimana toleransi kesalahan dapat diisolasi ke dalam kotak terpisah dan
dijual sebagai layanan independen. Memisahkan dan kemudian menenun keprihatinan
lintas sektor ini ke dalam sistem (didistribusikan) adalah tema utama yang ditangani oleh
pengembangan perangkat lunak berorientasi aspek (Filman et al., 2005). Namun, orientasi
aspek belum berhasil diterapkan untuk mengembangkan sistem terdistribusi skala besar,
dan dapat diharapkan bahwa masih ada jalan panjang untuk mencapai sebelum mencapai
tahap itu.
Refleksi komputasi mengacu pada kemampuan suatu program untuk memeriksa
dirinya sendiri dan, jika perlu, menyesuaikan perilakunya (Kon et al., 2002). Refleksi telah
dibangun ke dalam bahasa pemrograman, termasuk Java, dan menawarkan fasilitas yang
kuat untuk modifikasi runtime. Selain itu, beberapa sistem middleware menyediakan sarana
untuk menerapkan teknik reflektif. Namun, seperti halnya dalam hal orientasi aspek,
middleware reflektif belum membuktikan dirinya sebagai alat yang kuat untuk mengelola
kompleksitas sistem terdistribusi skala besar. Disebutkan oleh Blair et al. (2004),
menerapkan refleksi ke domain aplikasi yang luas harus dilakukan.
Akhirnya, desain berbasis komponen mendukung adaptasi melalui komposisi.
Suatu sistem dapat dikonfigurasi secara statis pada waktu desain, atau secara dinamis saat
runtime. Yang terakhir membutuhkan dukungan untuk pengikatan lambat, suatu teknik yang
telah berhasil diterapkan dalam lingkungan bahasa pemrograman, tetapi juga untuk sistem
operasi di mana modul dapat dimuat dan dibongkar sesuka hati. Penelitian saat ini sedang
berjalan dengan baik untuk memungkinkan pemilihan secara otomatis implementasi terbaik
dari suatu komponen selama runtime (Yellin, 2003), tetapi sekali lagi, prosesnya tetap
kompleks untuk sistem terdistribusi, terutama ketika mempertimbangkan bahwa
penggantian satu komponen perlu diketahui apa efeknya. penggantian komponen lain akan.
Dalam banyak kasus, komponen kurang independen seperti yang diperkirakan.
 Diskusi
Arsitektur perangkat lunak untuk sistem terdistribusi, terutama ditemukan sebagai
middleware, berukuran besar dan kompleks. Sebagian besar, kekakuan dan kompleksitas
ini muncul dari kebutuhan untuk bersikap umum dalam arti bahwa transparansi distribusi
perlu disediakan. Pada saat yang sama aplikasi memiliki persyaratan fungsional ekstra
spesifik yang bertentangan dengan tujuan untuk mencapai transparansi ini sepenuhnya.
Persyaratan yang saling bertentangan ini untuk generalisasi dan spesialisasi telah
menghasilkan solusi middleware yang sangat fleksibel. Namun, harga yang harus dibayar
adalah kompleksitas. Sebagai contoh, Zhang dan Jacobsen (2004) melaporkan peningkatan
50% dalam ukuran produk perangkat lunak tertentu hanya dalam empat tahun sejak
diperkenalkan, sedangkan jumlah total file untuk produk itu telah tiga kali lipat selama
periode yang sama. Jelas, ini bukan arahan yang mendorong.
 Mempertimbangkan bahwa hampir semua sistem perangkat lunak besar saat ini
diperlukan untuk dieksekusi dalam lingkungan jaringan, kita dapat bertanya pada diri sendiri
apakah kompleksitas sistem terdistribusi hanyalah fitur yang melekat dalam upaya membuat
distribusi transparan. Tentu saja, masalah-masalah seperti keterbukaan sama pentingnya,
tetapi kebutuhan akan fleksibilitas tidak pernah begitu lazim seperti dalam kasus
middleware. Coyler et al. (2003) berpendapat bahwa yang dibutuhkan adalah fokus yang
lebih kuat pada kesederhanaan (eksternal), cara yang lebih sederhana untuk membangun
middleware oleh komponen, dan independensi aplikasi. Apakah ada teknik yang disebutkan
di atas yang membentuk solusinya dapat diperdebatkan. Secara khusus, tidak ada teknik
yang diusulkan sejauh ini telah menemukan adopsi besar-besaran, atau mereka tidak
berhasil menerapkan sistem skala besar.
Asumsi yang mendasarinya adalah bahwa kita memerlukan perangkat lunak adaptif
dalam arti bahwa perangkat lunak tersebut harus dibiarkan berubah ketika lingkungan
berubah. Namun, orang harus mempertanyakan apakah beradaptasi dengan lingkungan
yang berubah adalah alasan yang bagus untuk mengadopsi perubahan perangkat lunak.
Perangkat keras yang rusak, serangan keamanan, drainase energi, dan sebagainya, semua
tampaknya merupakan pengaruh lingkungan yang dapat (dan harus) diantisipasi oleh
perangkat lunak.
Argumen terkuat, dan tentu saja paling valid, untuk mendukung perangkat lunak
adaptif adalah bahwa banyak sistem terdistribusi tidak dapat dimatikan. Kendala ini
membutuhkan solusi untuk mengganti dan meningkatkan komponen dengan cepat, tetapi
tidak jelas apakah salah satu solusi yang diusulkan di atas adalah yang terbaik untuk
mengatasi masalah perawatan ini. Apa yang tersisa adalah bahwa sistem terdistribusi harus
dapat bereaksi terhadap perubahan di lingkungan mereka dengan, misalnya, mengubah
kebijakan untuk mengalokasikan sumber daya. Semua komponen perangkat lunak untuk
mengaktifkan adaptasi semacam itu sudah akan tersedia. Algoritme yang terkandung dalam
komponen ini dan yang menentukan perilaku yang mengubah pengaturannya.
Tantangannya adalah membiarkan perilaku reaktif seperti itu terjadi tanpa campur tangan
manusia. Pendekatan ini terlihat lebih baik ketika membahas organisasi fisik sistem
terdistribusi ketika keputusan diambil tentang di mana komponen ditempatkan, misalnya.
Kami membahas masalah arsitektur sistem tersebut selanjutnya.
D. Manajemen Diri Dalam Sistem Terdistribusi
Sistem terdistribusi - dan terutama middleware terkait - perlu memberikan solusi umum
untuk melindungi fitur yang tidak diinginkan yang melekat pada jaringan sehingga mereka dapat
mendukung sebanyak mungkin aplikasi. Di sisi lain, transparansi distribusi penuh bukanlah yang
diinginkan sebagian besar aplikasi, menghasilkan solusi spesifik aplikasi yang perlu didukung juga.
Kami berpendapat bahwa, untuk alasan ini, sistem terdistribusi harus adaptif, tetapi terutama ketika
datang untuk menyesuaikan perilaku eksekusi mereka dan bukan komponen perangkat lunak yang
mereka buat. Ketika adaptasi perlu dilakukan secara otomatis, kami melihat interaksi yang kuat
antara arsitektur sistem dan arsitektur perangkat lunak. Di satu sisi, kita perlu mengatur komponen
sistem terdistribusi sehingga pemantauan dan penyesuaian dapat dilakukan, sementara di sisi lain
kita perlu memutuskan di mana proses yang akan dijalankan yang menangani adaptasi.
 Pada bagian ini kami memberikan perhatian eksplisit untuk mengatur sistem terdistribusi
sebagai sistem kontrol umpan balik tingkat tinggi yang memungkinkan adaptasi otomatis terhadap
perubahan. Fenomena ini juga dikenal sebagai komputasi otonom (Kephart, 2003) atau sistem
self..star (Babaoglu et al., 2005). Nama yang terakhir menunjukkan berbagai variasi yang dengannya
adaptasi otomatis ditangkap: pengelolaan diri, penyembuhan diri, konfigurasi diri, optimalisasi diri,
dan sebagainya. Kami hanya menggunakan nama sistem manajemen mandiri dari banyak varian
mereka.
 Model Kontrol Umpan Balik
Ada banyak pandangan berbeda tentang sistem pengelolaan diri, tetapi apa yang
paling umum miliki (baik secara eksplisit maupun implisit) adalah asumsi bahwa adaptasi
terjadi melalui satu atau lebih loop kontrol umpan balik. Dengan demikian, sistem yang
diorganisasikan melalui loop semacam itu disebut sebagai sistem umpan balik COl. Kontrol
umpan balik telah sejak lama diterapkan di berbagai bidang teknik, dan fondasi yang
sistematis secara bertahap juga menemukan jalan mereka dalam sistem komputasi
(Hellerstein et al., 2004; dan Diao et al., 2005). Untuk sistem yang dikelola sendiri, masalah
arsitektur pada awalnya adalah yang paling menarik. Ide dasar di balik organisasi ini cukup
sederhana, seperti yang ditunjukkan pada Gambar 2-16.

Gambar 2-16. Organisasi logis dari sistem kontrol umpan balik.

Inti dari sistem kontrol umpan balik dibentuk oleh komponen yang perlu dikelola.
Komponen-komponen ini diasumsikan didorong melalui parameter input yang dapat
dikontrol, tetapi perilakunya dapat dipengaruhi oleh semua jenis input yang tidak dapat
dikendalikan, juga dikenal sebagai input gangguan atau noise. Meskipun gangguan akan
sering datang dari lingkungan di mana sistem terdistribusi mengeksekusi, mungkin terjadi
interaksi komponen yang tidak terduga menyebabkan perilaku yang tidak terduga. Pada
dasarnya ada tiga elemen yang membentuk loop kontrol umpan balik. Pertama, sistem itu
sendiri perlu dipantau, yang mensyaratkan bahwa berbagai aspek sistem perlu diukur.
Dalam banyak kasus, mengukur perilaku lebih mudah diucapkan daripada dilakukan.
Misalnya, keterlambatan bolak-balik di Internet dapat sangat bervariasi, dan juga tergantung
pada apa yang sebenarnya diukur. Dalam kasus seperti itu, memperkirakan keterlambatan
yang akurat mungkin memang sulit. Masalah menjadi lebih rumit ketika sebuah node A perlu
memperkirakan latensi antara dua node B dan C yang sama sekali berbeda, tanpa dapat
mengganggu kedua node tersebut. Untuk alasan seperti ini, loop kontrol umpan balik
umumnya berisi komponen estimasi metrik alogis.
 Bagian lain dari loop kontrol umpan balik menganalisis pengukuran dan
membandingkannya dengan nilai referensi. Komponen analisis umpan balik ini membentuk
jantung dari loop kontrol, karena akan berisi algoritma yang memutuskan kemungkinan
adaptasi. Kelompok komponen terakhir terdiri dari berbagai mekanisme untuk secara
langsung mempengaruhi perilaku sistem. Mungkin ada banyak mekanisme berbeda:
menempatkan replika, mengubah prioritas penjadwalan, mengganti layanan, memindahkan
data karena alasan "ketersediaan, mengarahkan permintaan ke server yang berbeda, dll.
Komponen analisis perlu mengetahui mekanisme ini dan efeknya (diharapkan) pada
perilaku sistem, oleh karena itu, akan memicu satu atau beberapa mekanisme, untuk
kemudian mengamati efeknya.
Pengamatan yang menarik adalah bahwa loop kontrol umpan balik juga cocok
dengan manajemen manual sistem. Perbedaan utama adalah bahwa komponen analisis
digantikan oleh administrator manusia. Namun, untuk mengelola sistem terdistribusi dengan
benar, administrator ini akan membutuhkan peralatan pemantauan yang layak serta
mekanisme yang layak untuk mengendalikan perilaku sistem. Harus jelas bahwa
menganalisis data yang diukur dengan tepat dan memicu tindakan yang benar membuat
pengembangan sistem pengelolaan mandiri menjadi sulit. Harus ditekankan bahwa
Gambar.2-16 menunjukkan organisasi logis dari sistem yang mengatur sendiri, dan dengan
demikian sesuai dengan apa yang telah kita lihat ketika membahas arsitektur perangkat
lunak. Namun, organisasi fisik mungkin sangat berbeda. Sebagai contoh, komponen analisis
dapat sepenuhnya didistribusikan di seluruh sistem. Demikian juga, melakukan pengukuran
kinerja biasanya dilakukan pada setiap mesin yang merupakan bagian dari sistem
terdistribusi. Mari kita lihat beberapa contoh konkret tentang cara memantau, menganalisis,
dan memperbaiki sistem terdistribusi secara otomatis. Contoh-contoh ini juga akan
menggambarkan perbedaan antara organisasi logis dan fisik ini.
 Contoh: Pemantauan Sistem dengan Astrolabe
Sebagai contoh pertama, kami mempertimbangkan Antrolabe (Van Renesse et aI.,
2003), yang merupakan sistem yang dapat mendukung pemantauan umum sistem
terdistribusi yang sangat besar. Dalam konteks sistem pengelolaan diri, Astrolabe harus
diposisikan sebagai alat umum untuk mengamati perilaku sistem. Outputnya dapat
digunakan untuk memberi makan komponen analisis untuk memutuskan tindakan korektif.
Astrolabe mengorganisasi sejumlah besar host ke dalam hierarki zona. Zona level terendah
hanya terdiri dari satu host, yang kemudian dikelompokkan menjadi zona dengan ukuran
yang semakin besar. Zona tingkat atas mencakup semua host. Setiap host menjalankan
proses Astrolabe, yang disebut agen, yang mengumpulkan informasi tentang zona di mana
host itu terkandung. Agen juga berkomunikasi dengan agen lain dengan tujuan untuk
menyebarkan informasi zona di seluruh sistem arsip.
Setiap host memelihara seperangkat atribut untuk mengumpulkan informasi lokal.
Misalnya, sebuah host dapat melacak file tertentu yang disimpannya, penggunaan sumber
dayanya, dan begitu seterusnya. Hanya atribut yang dipelihara secara langsung oleh host,
yaitu, pada level hierarki terendah yang dapat ditulis. Setiap zona juga dapat memiliki koleksi
atribut, tetapi nilai atribut ini dihitung dari nilai zona level bawah. Pertimbangkan contoh
sederhana berikut yang ditunjukkan pada Gambar. 2-17 dengan tiga host, A, B, dan Cg
dikelompokkan ke dalam zona. Setiap mesin melacak alamat IP, beban CPU, memori bebas
yang tersedia. dan jumlah proses aktif. Masing-masing atribut ini dapat ditulis secara
langsung menggunakan informasi lokal dari setiap host. Di tingkat zona, hanya informasi
agregat yang dapat dikumpulkan, seperti rata-rata beban CPU, atau rata-rata jumlah proses
aktif.

Gambar 2-17. Pengumpulan data dan agregasi informasi di Astrolabe.

Gambar 2-17 menunjukkan bagaimana informasi yang dikumpulkan oleh setiap
mesin dapat dilihat sebagai catatan dalam database, dan bahwa catatan ini bersama-sama
membentuk suatu relasi (tabel). Representasi ini dilakukan dengan sengaja: ini adalah cara
Astrolabe melihat semua data yang dikumpulkan. Namun, informasi per zona hanya dapat
dihitung dari catatan dasar sebagaimana dijaga oleh host. Informasi agregat diperoleh
dengan fungsi agregasi yang dapat diprogram, yang sangat mirip dengan fungsi yang
tersedia dalam bahasa database relasional SQL. Sebagai contoh, dengan asumsi bahwa
informasi host dari Gambar 2-17 dipertahankan dalam tabel lokal yang disebut hostinfo, kita
dapat mengumpulkan jumlah rata-rata proses untuk zona yang berisi mesin A, B, dan C,
melalui kueri SQL sederhana

Dikombinasikan dengan beberapa peningkatan pada SQL, tidak sulit untuk

membayangkan bahwa pertanyaan yang lebih informatif dapat dirumuskan. Pertanyaan
seperti ini terus dievaluasi oleh setiap agen yang berjalan di setiap host. Jelas, ini hanya
mungkin jika informasi zona disebarkan ke semua node yang terdiri dari Astrolabe. Untuk
tujuan ini, anagent yang berjalan pada host bertanggung jawab untuk menghitung bagian-
bagian tabel dari zona terkaitnya. Catatan yang tidak dipikul tanggung jawab komputasi
kadang-kadang dikirimkan melalui prosedur pertukaran yang sederhana namun efektif yang
dikenal sebagai gosip. Protokol gosip akan dibahas secara rinci dalam Bab. 4. Demikian
juga, agen juga akan memberikan hasil yang dihitung ke agen lain juga. Hasil dari
pertukaran informasi ini adalah bahwa pada akhirnya, semua agen yang diperlukan untuk
membantu dalam memperoleh beberapa informasi yang dikumpulkan akan melihat hasil
yang sama (asalkan tidak ada perubahan yang terjadi pada saat itu).
 Contoh: Membedakan Strategi Replikasi di Globule
Mari kita lihat Globule, jaringan distribusi konten kolaboratif (Pierre dan van Steen,
2006). Globule bergantung pada server pengguna akhir yang ditempatkan di Internet, dan
bahwa server ini berkolaborasi untuk mengoptimalkan kinerja melalui replikasi halaman
Web. Untuk tujuan ini, setiap server asal (mis., Server yang bertanggung jawab menangani
pembaruan situs Web tertentu), melacak pola akses berdasarkan per halaman. Pola akses
dinyatakan sebagai operasi baca dan tulis untuk satu halaman, setiap operasi diberi cap
waktu dan dicatat oleh server asal untuk halaman itu. Dalam bentuknya yang paling
sederhana, Globule mengasumsikan bahwa Internet dapat dipandang sebagai sistem
server-tepi seperti yang kami jelaskan sebelumnya. Secara khusus, ini mengasumsikan
bahwa permintaan selalu dapat melewati server tepi yang sesuai, seperti yang ditunjukkan
pada Gambar. 2-18. Model sederhana ini memungkinkan server asal untuk melihat apa
yang akan terjadi jika ia meletakkan replika pada server tepi tertentu. Di satu sisi,
menempatkan replika lebih dekat ke klien akan meningkatkan latensi yang dirasakan klien,
tetapi ini akan mendorong lalu lintas antara server asal dan server tepi itu untuk menjaga
agar replika tetap konsisten dengan halaman asli.

Gambar 2-18. Model edge-server diasumsikan oleh Globule.

Ketika server asal menerima permintaan untuk sebuah halaman, itu mencatat
alamat IP dari mana permintaan itu berasal, dan mencari ISP atau jaringan perusahaan
terkait dengan permintaan itu menggunakan layanan Internet WHOIS (Deutsch et aI., 1995).
Server asal kemudian mencari server replika terdekat yang ada yang dapat bertindak
sebagai server tepi untuk klien itu, dan kemudian menghitung latensi ke server tersebut
bersama dengan bandwidth maksimal. Dalam konfigurasi yang paling sederhana, Globule
mengasumsikan bahwa latensi antara server replika dan mesin pengguna yang meminta
tidak dapat diabaikan, dan juga bahwa bandwidth antara keduanya sangat banyak. Setelah
cukup banyak permintaan untuk satu halaman telah dikumpulkan, server asal melakukan
"analisis bagaimana-jika" yang sederhana. Analisis seperti itu bermuara pada evaluasi
beberapa kebijakan replikasi, di mana kebijakan menggambarkan di mana halaman tertentu
direplikasi, dan bagaimana halaman itu tetap konsisten. Setiap kebijakan replikasi
dikenakan biaya yang dapat diekspresikan sebagai fungsi linier sederhana:
 di mana mk menunjukkan metrik kinerja dan Wk adalah bobot yang menunjukkan
betapa pentingnya metrik itu. Metrik kinerja umum adalah penundaan agregat antara klien
dan server replika saat mengembalikan salinan halaman Web, total bandwidth yang
dikonsumsi antara server asal dan server replika untuk menjaga agar replika tetap
konsisten, dan jumlah salinan basi yang (diizinkan untuk be) dikembalikan ke klien (Pierreet
aI., 2002). Sebagai contoh, asumsikan bahwa penundaan khas antara waktu klien C
mengeluarkan permintaan dan ketika halaman itu dikembalikan dari server replika terbaik
adalah de ms. Perhatikan bahwa server replika terbaik, ditentukan oleh kebijakan replikasi.
Biarkan m1 menunjukkan penundaan agregat selama periode waktu tertentu, yaitu, m1 =
Lde. Jika server asal ingin mengoptimalkan latensi yang dirasakan klien, ia akan memilih
nilai W-W yang relatif tinggi. Sebagai konsekuensinya, hanya kebijakan yang meminimalkan
m1 yang akan menunjukkan biaya relatif rendah.
Di Globule, server asal secara teratur mengevaluasi beberapa puluh kebijakan
replikasi menggunakan simulasi jejak, untuk setiap halaman Web secara terpisah. Dari
simulasi ini, kebijakan terbaik dipilih dan kemudian ditegakkan. Ini mungkin menyiratkan
bahwa replika baru dipasang di server tepi yang berbeda, atau bahwa cara yang berbeda
untuk menjaga replika konsisten dipilih. Pengumpulan jejak, evaluasi kebijakan replikasi,
dan penegakan kebijakan yang dipilih semuanya dilakukan secara otomatis. Ada sejumlah
masalah halus yang perlu ditangani. Untuk satu hal, tidak jelas berapa banyak permintaan
yang perlu dikumpulkan sebelum evaluasi kebijakan saat ini dapat dilakukan. Untuk
menjelaskan, misalkan pada waktu T; server asal memilih policyp untuk periode berikutnya
sampai'Ii + I 'Pilihan ini terjadi berdasarkan serangkaian permintaan sebelumnya yang
dikeluarkan antara' Ii-1 dan 'Ii. Tentu saja, jika ditinjau pada waktu '1i + I, server dapat
sampai pada kesimpulan bahwa ia seharusnya memilih policyp * mengingat permintaan
aktual yang dikeluarkan antara' Ii dan 'Ii + I. Ifp * berbeda dari compomp, maka pemilihan p
at'Iiwas salah.
Seperti ternyata, persentase prediksi yang salah bergantung pada panjang seri
permintaan (disebut panjang jejak) yang digunakan untuk memprediksi dan memilih

Gambar 2-19. Ketergantungan antara akurasi prediksi dan panjang jejak.

kebijakan selanjutnya. Ketergantungan ini digambarkan pada Gambar 2-19. Yang
terlihat adalah bahwa kesalahan dalam memprediksi kebijakan terbaik akan meningkat jika
jejaknya tidak cukup lama. Ini mudah dijelaskan oleh fakta bahwa kita memerlukan cukup
banyak permintaan untuk melakukan evaluasi yang tepat. Namun, kesalahan juga
 meningkat jika kami menggunakan terlalu banyak permintaan. Alasan untuk ini adalah
bahwa jejak yang sangat panjang menangkap begitu banyak perubahan dalam pola akses
yang memprediksi kebijakan terbaik untuk diikuti menjadi sulit, jika bukan tidak mungkin.
Fenomena ini terkenal dan analog dengan mencoba memprediksi cuaca untuk besok
dengan melihat apa yang terjadi selama 100 tahun sebelumnya. Prediksi yang jauh lebih
baik dapat dibuat hanya dengan melihat masa lalu yang baru saja terjadi. Menemukan
panjang jejak optimal dapat dilakukan secara otomatis juga. Kami membiarkannya sebagai
latihan untuk membuat sketsa solusi untuk masalah ini.
 Contoh: Manajemen Perbaikan Komponen Otomatis di Jade
Saat memelihara kelompok komputer, masing-masing menjalankan server yang
canggih, penting untuk mengatasi masalah manajemen. Salah satu pendekatan yang dapat
diterapkan ke server yang dibangun menggunakan pendekatan berbasis komponen, adalah
untuk mendeteksi kegagalan komponen dan meminta mereka secara otomatis diganti.
Sistem Jade mengikuti pendekatan ini (Bouchenak et al., 2005). Kami jelaskan secara
singkat di bagian ini. Jade dibangun pada model komponen Fractal, sebuah implementasi
Java dari suatu kerangka kerja yang memungkinkan komponen untuk ditambahkan dan
dihapus pada saat runtime (Bruneton et al., 2004). Komponen dalam Fractal dapat memiliki
dua jenis antarmuka. Antarmuka server digunakan untuk memanggil metode yang
diterapkan oleh komponen itu. Antarmuka klien digunakan oleh suatu komponen untuk
memanggil komponen lain. Komponen terhubung satu sama lain dengan mengikat
antarmuka. Sebagai contoh, antarmuka klien dari komponen C1 dapat diikat ke antarmuka
server dari komponen C2 'Pengikatan primitif berarti bahwa panggilan ke antarmuka klien
secara langsung mengarah pada panggilan yang dibatasi antarmuka server. Dalam kasus
pengikatan komposit, panggilan dapat diproses melalui satu atau lebih komponen lainnya,
misalnya, karena antarmuka klien dan server tidak cocok dan beberapa konversi perlu
dilakukan. Alasan lain mungkin karena komponen yang terhubung terletak pada mesin yang
berbeda.
Jade menggunakan gagasan tentang domain manajemen perbaikan. Domain
tersebut terdiri dari sejumlah node, di mana setiap node mewakili server bersama dengan
komponen yang dieksekusi oleh server itu. Ada manajer simpul terpisah yang bertanggung
jawab untuk menambah dan menghapus node dari domain. Manajer simpul mungkin
direplikasi untuk memastikan ketersediaan tinggi. Setiap node dilengkapi dengan detektor
kegagalan, yang memantau kesehatan sebuah node atau salah satu komponennya dan
melaporkan setiap kegagalan kepada manajer node. Biasanya, detektor ini
mempertimbangkan perubahan luar biasa dalam keadaan komponen, penggunaan sumber
daya, dan kegagalan komponen yang sebenarnya. Perhatikan bahwa yang terakhir
sebenarnya berarti bahwa amachine telah jatuh.
Ketika kegagalan telah terdeteksi, prosedur perbaikan dimulai. Prosedur seperti itu
digerakkan oleh kebijakan perbaikan, sebagian dilaksanakan oleh manajer simpul.
Kebijakan dinyatakan secara eksplisit dan dijalankan tergantung pada kegagalan yang
terdeteksi. Misalnya, anggap kegagalan simpul telah terdeteksi. Dalam hal itu, kebijakan
perbaikan mungkin menetapkan bahwa langkah-langkah berikut harus dilakukan:
 1. Hentikan setiap pengikatan antara komponen pada simpul yang tidak rusak,
dan komponen pada simpul yang gagal.
2. Minta manajer simpul untuk memulai dan menambahkan simpul baru ke
domain.
3. Konfigurasikan simpul baru dengan komponen yang persis sama dengan yang
ada pada simpul yang macet.
4. Membangun kembali semua ikatan yang sebelumnya diakhiri.
Dalam contoh ini, kebijakan perbaikannya sederhana dan hanya akan berfungsi bila
tidak ada data penting yang hilang (komponen yang rusak dikatakan sebagai stateless).
Pendekatan yang diikuti oleh Jade adalah contoh dari manajemen diri: setelah pendeteksian
kegagalan, kebijakan arepair secara otomatis dieksekusi untuk membawa sistem secara
keseluruhan ke dalam keadaan di mana ia sebelum crash. Menjadi sistem berbasis
komponen, perbaikan otomatis ini membutuhkan dukungan khusus untuk memungkinkan
komponen ditambahkan dan dihapus pada saat runtime. Secara umum, mengubah aplikasi
lama menjadi sistem yang mengatur sendiri tidak mungkin.
 RINGKASAN
Sistem terdistribusi dapat diatur dalam berbagai cara. Kita dapat membuat
perbedaan antara arsitektur perangkat lunak dan arsitektur sistem. Yang terakhir
mempertimbangkan di mana komponen yang merupakan sistem terdistribusi ditempatkan
di berbagai mesin. Yang pertama lebih peduli tentang organisasi logis dari perangkat lunak:
bagaimana komponen berinteraksi, bagaimana cara mereka disusun, bagaimana mereka
dapat dibuat mandiri, dan sebagainya.
Gagasan kunci ketika berbicara tentang arsitektur adalah gaya arsitektur. Gaya
mencerminkan prinsip dasar yang diikuti dalam mengatur interaksi antara komponen
perangkat lunak yang terdiri dari sistem terdistribusi. Gaya penting termasuk layering,
orientasi objek, orientasi peristiwa, dan orientasi ruang data. Ada banyak organisasi sistem
distribusi yang berbeda. Kelas penting adalah di mana mesin dibagi menjadi klien dan
server. Klien mengirim permintaan ke server, yang kemudian akan menghasilkan hasil yang
dikembalikan ke klien. Arsitektur client-server mencerminkan cara tradisional memodulasi
perangkat lunak di mana modul memanggil fungsi yang tersedia di modul lain. Dengan
menempatkan berbagai komponen pada mesin yang berbeda, kami memperoleh distribusi
fungsi fisik secara alami di sekumpulan mesin.
Arsitektur client-server seringkali sangat terpusat. Dalam arsitektur desentralisasi
kita sering melihat peran yang sama dimainkan oleh proses yang merupakan sistem
terdistribusi, juga dikenal sebagai sistem peer-to-peer. Dalam sistem peer-to-peer, proses
disusun menjadi jaringan overlay, yang merupakan jaringan logis di mana setiap proses
memiliki daftar lokal dari rekan-rekan lain yang dapat berkomunikasi dengannya. Jaringan
hamparan dapat disusun, dalam hal ini skema deterministik dapat digunakan untuk
merutekan pesan antar proses. Dalam jaringan yang tidak terstruktur, daftar rekan sebaya
kurang lebih acak, menyiratkan bahwa algoritma pencarian perlu digunakan untuk mencari
data atau proses lainnya.
Sebagai alternatif, sistem terdistribusi swakelola telah dikembangkan. Sistem ini,
sampai batas tertentu, menggabungkan ide dari arsitektur sistem dan perangkat lunak.
Sistem yang dikelola sendiri dapat secara umum diatur sebagai loop kontrol-umpan balik.
Loop tersebut berisi komponen pemantauan dengan perilaku sistem terdistribusi diukur,
komponen analisis untuk melihat apakah ada sesuatu yang perlu disesuaikan, dan
kumpulan berbagai instrumen untuk mengubah perilaku. Feedback -control loops dapat
diintegrasikan ke dalam sistem terdistribusi di banyak tempat. Banyak penelitian masih
diperlukan sebelum pemahaman bersama bagaimana loop seperti itu dikembangkan dan
digunakan tercapai.