DISTRIBUTED SYSTEMS Concept and Design – Fifth Edition
George Coulouris
Cambridge University
Jean Dollimore
formerly of Queen Mary, University of London
Tim Kindberg
matter 2 media
Gordon Blair
Lancaster University
6.1 Pendahuluan
Komunikasi tidak langsung didefinisikan sebagai komunikasi antara entitas dalam sistem terdistribusi melalui perantara tanpa kopling langsung antara pengirim dan penerima (s). Sifat yang tepat dari perantara bervariasi dari pendekatan. Pendekatan, seperti yang akan terlihat di seluruh bab ini. Selain itu, sifat yang tepat dari kopling bervariasi secara signifikan antara sistem, dan lagi ini akan dibawa dalam Teks berikut. Perhatikan plural opsional terkait dengan penerima; ini menandakan bahwa
banyak paradigma komunikasi tidak langsung secara eksplisit mendukung satu-ke-banyak komunikasi.
Teknik dipertimbangkan dalam Bab 4 dan 5 semua didasarkan pada kopling langsung antara pengirim dan penerima, dan ini menyebabkan sejumlah kekakuan di sistem dalam hal berurusan dengan perubahan. Untuk menggambarkan hal ini, pertimbangkan sederhana client-server interaksi. Karena kopling langsung, lebih sulit untuk mengganti server dengan salah satu korban fungsi setara alternatif. Demikian pula, jika server gagal, ini langsung mempengaruhi klien, yang harus secara eksplisit berurusan dengan kegagalan. Sebaliknya, komunikasi tidak langsung menghindari kopling langsung ini dan karenanya mewarisi menarik properti. literatur mengacu pada dua sifat utama yang berasal dari penggunaan perantara:
Ruang uncoupling, di mana pengirim tidak tahu atau perlu tahu identitasdari penerima (s), dan sebaliknya. Karena ruang uncoupling ini, sistem pengembang memiliki banyak derajat kebebasan dalam menangani perubahan: peserta (pengirim atau penerima) dapat diganti, diperbarui, direplikasi atau bermigrasi. Waktu uncoupling, di mana pengirim dan penerima (s) dapat memiliki independen
masa hidup. Dengan kata lain, pengirim dan penerima (s) tidak perlu ada pada saat yang sama
waktu untuk berkomunikasi. Ini memiliki manfaat penting, misalnya, lebih stabil lingkungan di mana pengirim dan penerima dapat datang dan pergi. Untuk alasan ini, komunikasi tidak langsung sering digunakan dalam sistem terdistribusi di mana perubahan diantisipasi - misalnya, dalam lingkungan mobile di mana pengguna dapat dengan cepat menghubungkan dan memutuskan sambungan dari jaringan global - dan harus dikelola untuk memberikan layanan yang lebih dapat diandalkan. komunikasi tidak langsung juga banyak digunakan untuk acara diseminasi dalam sistem terdistribusi di mana penerima mungkin tidak diketahui dan bertanggung jawab untuk mengubah - misalnya, dalam mengelola event feed dalam sistem keuangan, seperti yang ditampilkan di
Bab 1. Komunikasi langsung juga dimanfaatkan dalam bagian kunci dari Google infrastruktur, seperti yang dibahas dalam studi kasus besar dalam Bab 21.
Gambar 6.1 Ruang dan waktu coupling dalam sistem terdistribusi
Waktu-coupled Waktu-coupled
kopling ruang Sifat: Komunikasi diarahkan
menuju receiver atau penerima diberikan;
receiver) harus ada pada saat itu di
waktu
Contoh: Pesan lewat, remote
doa (lihat Bab 4 dan 5) Sifat: Komunikasi diarahkan
menuju receiver atau penerima diberikan;
pengirim (s) dan penerima (s) dapat memiliki
tahan independen
Contoh: Lihat Latihan 6.3
ruang uncoupling Sifat: Pengirim tidak perlu
mengetahui identitas penerima (s);
penerima (s) harus ada pada saat itu di
waktu
Contoh: IP multicast (lihat Bab 4) Sifat: Pengirim tidak perlu tahu
identitas penerima (s); pengirim (s)
dan penerima (s) dapat memiliki independen
tahan
Contoh: komunikasi Kebanyakan tidak langsung
paradigma dibahas dalam bab ini
Diskusi di atas grafik keuntungan terkait dengan tidak langsung komunikasi. Kerugian utama adalah bahwa pasti akan ada kinerja overhead yang diperkenalkan oleh tingkat tambahan tipuan. Memang, kutipan di atas pada tipuan sering dipasangkan dengan kutipan berikut, disebabkan Jim Gray:
Tidak ada masalah kinerja yang tidak dapat diselesaikan dengan menghilangkan level tipuan.
Selain itu, sistem yang dikembangkan menggunakan komunikasi tidak langsung dapat lebih sulit untuk
manusia usia justru karena tidak adanya langsung (ruang atau waktu) kopling. Sebuah melihat lebih dekat pada ruang dan waktu uncoupling • Dapat diasumsikan bahwa tipuan menyiratkan ruang dan waktu uncoupling, tapi ini tidak selalu terjadi. Hubungan yang tepat diringkas dalam Gambar 6.1
Dari tabel ini, jelas bahwa sebagian besar teknik dipertimbangkan dalam buku ini baik ditambah di kedua ruang dan waktu atau memang uncoupled di kedua dimensi. Atas kiri kotak mewakili paradigma komunikasi ditampilkan dalam Bab 4 dan 5 di mana komunikasi adalah langsung tanpa ruang atau waktu uncoupling.
Sebagai contoh, pesan lewat adalah baik diarahkan tertentu entitas dan mengharuskan penerima hadir di saat pesan mengirim (tapi Lihat Latihan 6.2 untuk menambahkan dimensi diperkenalkan oleh DNS
resolusi nama). Jangkauan dari remote paradigma doa adalah juga ditambah di kedua ruang dan waktu.
Kanan bawah kotak mewakili utama tidak langsung komunikasi paradigma yang menunjukkan kedua sifat. Sejumlah kecil komunikasi paradigma duduk luar dua daerah ini:
IP multicast, seperti yang ditampilkan dalam Bab 4, ruang-uncoupled tapi kali digabungkan. Ini ruang-uncoupled karena pesan diarahkan kelompok multicast, tidak setiap penerima tertentu. Ini adalah waktu-coupled, meskipun, karena semua penerima harus ada di saat pesan kirim untuk menerima multicast tersebut. Beberapa implementasi dari kelompok komunikasi dan memang mempublikasikan-berlangganan sistem, juga termasuk dalam kategori ini (Lihat Bagian 6.6). Contoh ini menggambarkan pentingnya perketidak di saluran komunikasi untuk mencapai waktu uncoupling - yaitu, komunikasi
Paradigma harus menyimpan pesan sehingga mereka dapat disampaikan ketika penerima (s) siap untuk menerima. IP multicast tidak mendukung tingkat persistensi.
Kasus di mana komunikasi adalah ruang-digabungkan tapi kali-uncoupled lebih halus. Ruang kopling menyiratkan bahwa pengirim mengetahui identitas tertentu receiver atau penerima, tapi kali uncoupling menyiratkan bahwa penerima atau penerima tidak perlu ada pada saat pengiriman. Latihan 6.3 dan 6.4 mengundang pembaca untuk mempertimbangkan apakah paradigma tersebut ada atau dapat dibangun.
Kembali ke definisi kita, kita memperlakukan semua paradigma yang melibatkan perantara sebagai
tidak langsung dan mengakui bahwa tingkat yang tepat dari coupling akan bervariasi dari sistem ke sistem. Kami kembali sifat-sifat paradigma komunikasi tidak langsung yang berbeda dalam Bagian 6.6,
setelah kami memiliki kesempatan untuk mempelajari karakteristik yang tepat dari masing-masing pendekatan. Hubungan dengan komunikasi asynchronous • Perhatikan bahwa, untuk memahami ini
daerah, adalah penting untuk membedakan antara komunikasi asynchronous (sebagaimana didefinisikan dalam Bab 4) dan waktu uncoupling. Dalam komunikasi asynchronous, pengirim mengirimkan pesan dan kemudian berlanjut (tanpa menghalangi), dan karenanya tidak perlu untuk bertemu di time dengan penerima untuk berkomunikasi. Waktu uncoupling menambahkan dimensi ekstra yang pengirim dan penerima (s) dapat memiliki eksistensi independen; misalnya, penerima
mungkin tidak ada pada komunikasi waktu dimulai. Eugster et al. juga mengakui Perbedaan penting antara komunikasi asynchronous (sinkronisasi uncoupling) dan waktu uncoupling [2003]. Banyak teknik diperiksa dalam bab ini adalah waktu-uncoupled dan asynchronous, tetapi beberapa, seperti operasi MessageDispatcher dan RpcDispatcher di JGroups, dibahas dalam Bagian 6.2.3, menawarkan layanan sinkron lebih tidak langsung komunikasi. Sisa bab ini membahas contoh-contoh spesifik dari komunikasi tidak langsung dimulai dengan komunikasi kelompok dalam Bagian 6.2. Bagian 6.3 kemudian memeriksa
dasar mempublikasikan-berlangganan sistem, dengan Bagian 6.4 memeriksa kontras yang Pendekatan yang ditawarkan oleh antrian pesan. Setelah ini, Bagian 6.5 menganggap pendekatan berdasarkan abstraksi memori bersama, khususnya didistribusikan memori bersama dan tuple pendekatan berbasis ruang.
6.2 Komunikasi Kelompok
Komunikasi kelompok memberikan contoh pertama kami komunikasi tidak langsung paradigma. komunikasi kelompok menawarkan layanan dimana pesan dikirim ke grup dan kemudian pesan ini dikirim ke semua anggota kelompok. Dalam aksi ini, pengirim tidak menyadari identitas penerima. komunikasi kelompok merupakan abstraksi atas komunikasi multicast dan dapat dilaksanakan over IP multicast atau jaringan overlay setara, menambahkan nilai tambahan yang signifikan dalam hal pengelolaan keanggotaan kelompok, mendeteksi kegagalan dan memberikan keandalan dan memesan jaminan. Dengan jaminan menambahkan, komunikasi kelompok adalah untuk multicast IP apa TCP adalah dengan layanan point-to-point di IP.
Komunikasi kelompok merupakan blok bangunan penting untuk sistem terdistribusi, dan
sistem terdistribusi terutama terpercaya, dengan bidang utama aplikasi termasuk:
Penyebaran informasi yang dapat diandalkan ke nomor berpotensi besar klien, termasuk di industri
keuangan, di mana lembaga memerlukan akurat dan up-todate mengakses untuk variasi yang banyak sumber informasi;
Dukungan untuk aplikasi kolaboratif, di mana acara lagi harus disebarluaskan untuk beberapa pengguna untuk melestarikan pandangan pengguna umum - misalnya, di multiuser permainan, seperti dibahas dalam Bab 1;
Dukungan untuk berbagai strategi kesalahan-toleransi, termasuk update konsisten Data direplikasi (seperti yang dibahas secara rinci dalam Bab 18) atau pelaksanaan sangat tersedia (direplikasi) server;
• Dukungan untuk sistem pemantauan dan manajemen, termasuk misalnya beban menyeimbangkan strategi. Kami melihat komunikasi kelompok lebih rinci di bawah, memeriksa pemrograman Model yang ditawarkan dan isu-isu implementasi yang terkait. Kami memeriksa Jgroups toolkit sebagai studi kasus layanan komunikasi kelompok.
6.2.1 Model pemrograman
Dalam komunikasi kelompok, konsep sentral adalah bahwa dari kelompok dengan kelompok yang terkait keanggotaan, dimana proses dapat
bergabung atau meninggalkan grup. Proses kemudian dapat mengirim pesan ke grup ini dan telah itu disebarkan ke semua anggota kelompok dengan tertentu jaminan dalam hal kehandalan dan
pemesanan. Dengan demikian, alat komunikasi kelompok komunikasi multicast, di mana pesan dikirim ke semua anggota kelompok dengan operasi tunggal. Komunikasi untuk semua proses dalam sistem, sebagai lawan subkelompok dari mereka, dikenal sebagai broadcast, sedangkan komunikasi untuk proses tunggal dikenal sebagai unicast. Fitur penting dari komunikasi kelompok adalah bahwa proses mengeluarkan hanya satu Operasi multicast untuk mengirim pesan ke masing-masing kelompok proses (di Jawa ini operasi aGroup.send (aMessage)) bukannya mengeluarkan beberapa kirim operasi untuk
proses individual.
Penggunaan operasi multicast tunggal, bukan beberapa operasi send berjumlah lebih dari kenyamanan bagi programmer: itu memungkinkan implementasi efisien dalam pemanfaatan bandwidth. Hal ini dapat mengambil langkah-langkah untuk mengirim pesan tidak lebih dari sekali atas setiap link komunikasi, dengan mengirimkannya melalui pohon distribusi; dan dapat menggunakan dukungan hardware jaringan untuk multicast di mana hal ini tersedia. Implementasi ini juga dapat meminimalkan total waktu yang dibutuhkan untuk memberikan pesan ke semua tujuan, dibandingkan dengan transmisi secara terpisah dan serial. Untuk melihat keunggulan ini, membandingkan pemanfaatan bandwidth dan total
waktu transmisi diambil saat mengirim pesan yang sama dari komputer di London untuk
dua komputer pada Ethernet yang sama di Palo Alto, (a) dengan dua UDP terpisah mengirimkan, dan (b)
dengan operasi multicast IP tunggal. Dalam kasus yang pertama, dua salinan dari pesan yang dikirim
independen, dan yang kedua adalah tertunda pertama. Dalam kasus terakhir, satu set multicast-
router menyadari meneruskan satu salinan pesan dari London ke router pada LAN tujuan di California. router yang kemudian menggunakan hardware multicast (disediakan oleh Ethernet) untuk menyampaikan pesan untuk kedua tujuan sekaligus, daripada mengirim dua kali.
Penggunaan operasi multicast tunggal juga penting dalam hal pengiriman jaminan. Jika proses mengeluarkan beberapa operasi send independen untuk individu proses, maka tidak ada jalan bagi implementasi untuk memberikan jaminan yang mempengaruhi kelompok proses secara keseluruhan. Jika pengirim gagal di tengah jalan pengiriman, maka beberapa anggota kelompok mungkin menerima pesan sementara yang lainnya tidak. Selain itu, pemesanan relatif dari dua pesan dikirimkan ke dua anggota kelompok tidak terdefinisi. Komunikasi kelompok, bagaimanapun, memiliki potensi untuk menawarkan berbagai jaminan dalam hal keandalan dan pemesanan, seperti yang dibahas dalam Bagian
6.2.2 bawah.
Komunikasi kelompok telah menjadi subyek dari banyak proyek penelitian, termasuk
V-sistem [Cheriton dan Zwaenepoel 1985], Chorus [Rozier et al. 1988], Amoeba [Kaashoek et al. 1989; Kaashoek dan Tanenbaum 1991], Trans / Jumlah [Melliar-Smith et Al. 1990], Delta-4 [Powell 1991], Isis [Birman 1993], Horus [van Renesse et al. 1996], Totem [Moser et al. 1996] dan Transit [Dolev dan Malki 1996] - dan kami akan mengutip lainnya pekerjaan penting dalam perjalanan bab ini dan memang seluruh buku ini (terutama dalam Bab 15 dan 18).
Kelompok proses dan kelompok objek • Sebagian besar bekerja pada layanan kelompok berfokus pada Konsep kelompok proses, yaitu, kelompok mana entitas berkomunikasi yang proses. layanan tersebut relatif rendah tingkat di bahwa:
Pesan dikirim ke proses dan tidak ada dukungan lebih lanjut untuk pengiriman adalah disediakan.
• Pesan biasanya tidak terstruktur byte array tanpa dukungan untuk marshalling dari tipe data yang kompleks (seperti yang disediakan, misalnya, di RPC atau RMI - lihat Bab 5).
Tingkat layanan yang disediakan oleh kelompok proses Oleh karena itu mirip dengan soket,
seperti dibahas dalam Bab 4. Sebaliknya, kelompok objek menyediakan pendekatan-tingkat yang lebih tinggi untuk kelompok komputasi. Sebuah kelompok objek adalah koleksi benda-benda (biasanya contoh dari kelas yang sama) yang memproses set yang sama doa bersamaan, dengan masing-masing kembali tanggapan. benda klien tidak perlu menyadari replikasi. Mereka memanggil operasi pada satu, objek lokal, yang bertindak sebagai proxy untuk grup. proxy menggunakan kelompok sistem komunikasi untuk mengirim doa kepada anggota kelompok objek. Parameter objek dan hasilnya marshalled seperti dalam RMI dan panggilan terkait yang dikirim secara otomatis ke kanan objek tujuan / metode.
Electra [Maffeis 1995] adalah sistem CORBA-compliant yang mendukung objek kelompok. Sebuah kelompok Electra dapat dihubungkan ke aplikasi CORBA-compliant. Electra awalnya dibangun di atas Horus sistem komunikasi kelompok, yang menggunakan untuk mengelola keanggotaan grup dan doa multicast. Di 'Mode transparan', proxy lokal mengembalikan respon pertama yang tersedia ke objek klien. Dalam 'non-transparan mode', objek klien dapat mengakses semua tanggapan dikembalikan oleh
anggota kelompok. Electra menggunakan perluasan dari standar CORBA Object Request
antarmuka broker, dengan fungsi untuk menciptakan dan menghancurkan kelompok objek dan mengelola keanggotaan mereka. Kekal [Moser et al. 1998] dan Layanan Object Group [Guerraoui
et al. 1998] juga menyediakan dukungan CORBA-compliant untuk kelompok objek. Meskipun janji kelompok objek, namun, kelompok proses masih mendominasi di hal penggunaan. Sebagai contoh, JGroups toolkit populer, dibahas dalam Bagian 6.2.3, adalah klasik pendekatan kelompok proses.
Perbedaan utama lainnya :
Berbagai macam layanan komunikasi kelompok telah dikembangkan, dan mereka berbeda dalam asumsi mereka membuat: Tertutup dan terbuka kelompok: A Kelompok dikatakan tertutup jika hanya anggota kelompok mungkin multicast untuk itu (Gambar 6.2). Sebuah proses dalam kelompok tertutup memberikan kepada dirinya sendiri setiap pesan bahwa multicast ke grup. Sebuah kelompok adalah op
en jika proses di luar kelompok dapat mengirimkan untuk itu. (The kategori 'terbuka' dan 'tertutup' juga berlaku dengan analog makna untuk milis.) Grup tertutup dari proses berguna, misalnya, untuk
bekerja sama server untuk mengirim pesan satu sama lain bahwa hanya mereka harus menerima.
kelompok terbuka yang berguna, misalnya, untuk memberikan acara untuk kelompok tertarik
proses. Tumpang tindih dan non-tumpang tindih kelompok: Dalam kelompok Tumpang Tindih, entitas (proses atau benda) mungkin anggota dari beberapa kelompok, dan tidak tumpang tindih kelompok menyiratkan keanggotaan yang tidak tumpang tindih (bahwa adalah, setiap Proses milik paling banyak satu kelompok). Perhatikan bahwa dalam sistem kehidupan nyata, itu adalah realistis untuk
mengharapkan bahwa keanggotaan kelompok akan tumpang tindih. Sinkron dan asynchronous sistem: Ada persyaratan untuk mempertimbangkan kelompok komunikasi di kedua lingkungan. Perbedaan tersebut dapat memiliki dampak yang signifikan pada algoritma multicast yang mendasari.
Untuk Misalnya, beberapa algoritma menganggap bahwa kelompok ditutup. Efek yang sama seperti
keterbukaan dapat dicapai dengan kelompok tertutup dengan memilih anggota kelompok dan
mengirimnya pesan (satu-ke-satu) untuk itu untuk multicast untuk kelompoknya. Rodrigues et al. [1998]
membahas multicast untuk membuka kelompok. Isu yang terkait dengan membuka dan kelompok tertutup timbul dalam Bab 15, ketika algoritma untuk keandalan dan memesan dianggap. bab
juga mempertimbangkan dampak dari kelompok yang tumpang tindih dan apakah sistem ini sinkron
atau asynchronous pada protokol tersebut.
6.2.2 Masalah Implementasi
Kita sekarang beralih ke isu-isu implementasi untuk layanan komunikasi kelompok, membahas
sifat dari layanan multicast yang mendasari dalam hal keandalan dan pemesanan dan juga peran utama manajemen keanggotaan kelompok dalam lingkungan yang dinamis, di mana proses dapat bergabung dan meninggalkan atau gagal setiap saat. Keandalan dan pemesanan dalam multicast
Dalam komunikasi kelompok, semua anggota kelompok harus menerima salinan dari pesan yang dikirim ke grup, umumnya dengan pengiriman jaminan. Jaminan termasuk kesepakatan pada set pesan bahwa setiap proses dalam kelompok harus menerima dan pengiriman pemesanan seluruh anggota kelompok. Sistem komunikasi kelompok yang sangat canggih. Bahkan IP multicast, yang memberikan jaminan pengiriman minimal, memerlukan upaya rekayasa besar. Sejauh ini, kita telah membahas keandalan dan memesan secara agak umum. Kita sekarang terlihat lebih detail apa sifat seperti berarti.
Keandalan dalam satu-ke-satu komunikasi didefinisikan dalam Bagian 2.4.2 dalam hal dua sifat: integritas (pesan yang diterima adalah sama dengan yang dikirim, dan tidak ada Pesan yang disampaikan dua kali) dan validitas (setiap pesan keluar adalah akhirnya disampaikan). Interpretasi untuk multicast diandalkan dibangun di atas sifat ini, dengan integritas didefinisikan dengan cara yang sama dalam hal menyampaikan pesan dengan benar paling banyak sekali, dan validitas menjamin bahwa pesan yang dikirim pada akhirnya akan disampaikan. Untuk memperpanjang semantik untuk menutupi pengiriman ke beberapa penerima, properti ketiga ditambahkan - bahwa dari kesepakatan, yang menyatakan bahwa jika pesan dikirim ke satu proses, maka dikirim ke semua proses dalam kelompok.
Serta jaminan keandalan, komunikasi kelompok menuntut jaminan tambahan dalam hal pemesanan relatif pesan dikirim ke beberapa tujuan. Pemesanan tidak dijamin oleh mendasari primitif komunikasi antar. Sebagai contoh, jika multicast dilaksanakan oleh serangkaian pesan satu-ke-satu, mereka mungkin akan dikenakan penundaan sewenang-wenang. Masalah serupa dapat terjadi jika menggunakan IP multicast. Untuk mengatasi ini, layanan komunikasi kelompok menawarkan memerintahkan multicast, dengan pilihan satu atau lebih dari properti berikut (dengan solusi hybrid juga mungkin):
FIFO pemesanan: Pertama-in-first-out (FIFO) pemesanan (juga disebut sebagai sumber pemesanan) berkaitan dengan melestarikan perintah dari perspektif pengirim proses, dalam bahwa jika suatu proses mengirim satu pesan sebelum yang lain, itu akan disampaikan dalam Agar ini di semua proses dalam kelompok. Kausal pemesanan: kausal pemesanan memperhitungkan hubungan akun kausal antara
pesan, dalam bahwa jika pesan yang terjadi sebelum pesan lain di didistribusikan Sistem yang disebut hubungan sebab akibat ini akan dipertahankan dalam pengiriman pesan terkait di semua proses (lihat Bab 14 untuk pembahasan rinci dari yang berarti dari 'terjadi sebelum'). Jumlah pemesanan: Total pemesanan, jika pesan yang disampaikan sebelum pesan lain pada satu proses, maka urutan yang sama akan dipertahankan pada semua proses. Keandalan dan pemesanan adalah contoh dari koordinasi dan kesepakatan di didistribusikan sistem, dan pertimbangan maka ini lebih lanjut ditangguhkan Bab 15, yang berfokus eksklusif pada topik ini. Secara khusus, Bab 15 memberikan definisi yang lebih lengkap
integritas, validitas, perjanjian dan berbagai sifat pemesanan dan juga meneliti secara rinci algoritma untuk mewujudkan handal dan memerintahkan multicast. manajemen keanggotaan kelompok
Elemen-elemen kunci dari komunikasi kelompok manajemen dirangkum dalam Gambar 6.3, yang menunjukkan kelompok terbuk. Diagram ini menggambarkan peran penting dari manajemen
keanggotaan kelompok dalam mempertahankan pandangan yang akurat dari keanggotaan saat ini,
mengingat bahwa entitas dapat bergabung, meninggalkan atau memang gagal. Secara lebih rinci, layanan keanggotaan grup memiliki empat tugas utama:
Menyediakan sebuah antarmuka untuk perubahan keanggotaan grup: Layanan keanggotaan
menyediakan operasi untuk membuat dan menghancurkan kelompok proses dan untuk menambah atau menarik sebuah proses ke atau dari kelompok. Pada kebanyakan sistem, proses tunggal mungkin milik beberapa kelompok pada waktu yang sama (tumpang tindih kelompok, seperti dijelaskan di atas). Hal ini berlaku dari IP multicast, misalnya.
Kegagalan deteksi: Layanan memonitor anggota kelompok tidak hanya dalam kasus mereka harus kecelakaan, tetapi juga dalam hal mereka harus menjadi tidak terjangkau karena kegagalan komunikasi. detektor menandai proses sebagai Tersangka atau disangka. Layanan ini menggunakan detektor kegagalan untuk mencapai keputusan tentang kelompok keanggotaan: itu tidak termasuk proses dari keanggotaan jika diduga telah gagal atau telah menjadi tidak terjangkau.
Memberitahukan anggota perubahan keanggotaan kelompok: Layanan memberitahu kelompok
anggota ketika proses ditambahkan, atau ketika proses dikecualikan (melalui kegagalan atau
ketika proses ini sengaja ditarik dari kelompok). Pertunjukan ekspansi alamat grup: Ketika proses multicast pesan, itu perbekalan pengenal kelompok daripada daftar proses dalam kelompok. Itu
layanan manajemen keanggotaan memperluas identifier ke dalam kelompok saat ini
Keanggotaan untuk pengiriman. Layanan dapat berkoordinasi pengiriman multicast dengan
perubahan keanggotaan dengan mengendalikan ekspansi alamat. Artinya, bisa memutuskan
konsisten di mana untuk menyampaikan pesan tertentu, meskipun keanggotaan mungkin
menjadi berubah saat melahirkan.
Perhatikan bahwa IP multicast adalah kasus yang lemah dari layanan keanggotaan kelompok, dengan beberapa tapi tidak semua sifat ini. Ini memungkinkan proses untuk bergabung atau meninggalkan kelompok dinamis dan ia melakukan ekspansi alamat, sehingga pengirim hanya perlu memberikan IP multicast tunggal mengatasi sebagai tujuan untuk pesan multicast. Tapi IP multicast tidak sendiri
menyediakan anggota kelompok dengan informasi tentang keanggotaan saat ini, dan multicast
pengiriman tidak dikoordinasikan dengan perubahan keanggotaan. Mencapai sifat ini adalah kompleks dan membutuhkan apa yang dikenal sebagai komunikasi kelompok pandangan-sinkron.
Pertimbangan lebih lanjut dari masalah penting ini ditangguhkan untuk Bab 18, yang membahas
pemeliharaan kelompok memandang dan bagaimana untuk mewujudkan tampilan grup-sinkron
komunikasi dalam rangka mendukung replikasi dalam sistem terdistribusi. Secara umum, kebutuhan untuk mempertahankan keanggotaan kelompok memiliki dampak yang signifikan pada utilitas pendekatan berbasis kelompok. Secara khusus, komunikasi kelompok yang paling efektif di skala kecil dan statis sistem dan tidak beroperasi dengan baik dalam skala besar lingkungan atau lingkungan dengan tingkat volatilitas yang tinggi. Hal ini dapat ditelusuri kebutuhkan untuk bentuk asumsi sinkron. Ganesh et al [2003] menyajikan lebih Pendekatan probabilistik untuk anggota grup dirancang untuk beroperasi di lebih skala besar dan lingkungan yang dinamis, menggunakan protokol gosip yang mendasari (lihat Bagian 10.5.3). Para peneliti juga telah mengembangkan protokol keanggotaan kelompok khusus untuk ad hoc jaringan dan lingkungan mobile [Prakash dan Baldoni 1998; Roman et al. 2001; Liu et al. 2005].
6.2.3 Studi Kasus: toolkit Jgroups
JGroups adalah toolkit untuk komunikasi kelompok terpercaya ditulis di Jawa. toolkit adalah
bagian dari garis keturunan alat komunikasi kelompok yang muncul dari Cornell Universitas, membangun konsep dasar yang dikembangkan di ISIS [Birman 1993], Horus [van Renesse et al. 1996] dan Ensemble [van Renesse et al. 1998]. Toolkit ini sekarang dipelihara dan dikembangkan oleh komunitas open source yang Jgroups [ www.jgroups.org ], Yang merupakan bagian dari komunitas middleware JBoss, seperti yang dibahas di Bab 8 [www.jboss.org ]. JGroups mendukung kelompok proses di mana proses dapat bergabung atau meninggalkan kelompok, mengirim pesan ke semua anggota kelompok atau memang untuk anggota tunggal, dan menerima pesan dari grup. toolkit mendukung berbagai keandalan dan memesan jaminan, yang dibahas lebih rinci di bawah, dan juga menawarkan sebuah kelompok layanan keanggotaan. Arsitektur JGroups ditunjukkan pada Gambar 6.4, yang menunjukkan utama komponen pelaksanaan JGroups:
Saluran mewakili antarmuka yang paling primitif untuk pengembang aplikasi, menawarkan fungsi inti bergabung, meninggalkan, mengirim dan menerima.
Blok Bangunan menawarkan abstraksi tingkat tinggi, membangun layanan yang mendasari yang ditawarkan oleh saluran.
Protokol tumpukan memberikan protokol komunikasi yang mendasari, dibangun sebagai tumpukan lapisan protokol composable. Kami melihat satu per satu di bawah ini. Saluran
Sebuah proses berinteraksi dengan kelompok melalui objek saluran, yang bertindak sebagai
menangani ke grup. Ketika dibuat, itu terputus, tetapi menghubungkan berikutnya operasi mengikat yang menangani untuk kelompok bernama tertentu; jika kelompok bernama tidak ada, itu secara implisit dibuat pada saat connect pertama. Untuk meninggalkan kelompok, Proses mengeksekusi operasi putuskan sesuai. Operasi dekat juga disediakan untuk membuat saluran tidak dapat digunakan. Perhatikan bahwa saluran hanya dapat dihubungkan ke satu kelompok pada suatu waktu; jika suatu proses ingin terhubung ke dua atau lebih kelompok, itu harus membuat beberapa saluran. Ketika terhubung, proses dapat mengirim atau menerima melalui saluran. Pesan yang dikirim oleh multicast handal, dengan semantik yang tepat didefinisikan oleh stack protokol dikerahkan (seperti dibahas lebih lanjut di bawah). Berbagai operasi lain didefinisikan pada saluran, terutama untuk kembali
manageme Informasi nt terkait dengan saluran. Misalnya, getView mengembalikan tampilan saat didefinisikan dalam hal daftar anggota saat ini, sementara getState mengembalikan negara aplikasi historis yang terkait dengan kelompok (ini dapat digunakan, misalnya, dengan anggota kelompok baru untuk mengejar ketinggalan dengan peristiwa sebelumnya). Perhatikan bahwa ch jangka annel tidak harus bingung dengan publishsubscribe berbasis channel-, seperti yang diperkenalkan di Bagian 6.3.1.
saluran di Jgroups identik dengan sebuah contoh dari kelompok sebagaimana didefinisikan di bagian
6.2.1.
Kami menggambarkan penggunaan saluran lebih lanjut dengan contoh sederhana, sebuah layanan dimana alarm kebakaran cerdas dapat mengirim "Api!" pesan multicast untuk setiap penerima yang terdaftar. Kode untuk alarm kebakaran seperti yang ditunjukkan pada Gambar 6.5
Ketika alarm dinaikkan, langkah pertama adalah untuk membuat contoh baru dari JChannel (yang
kelas yang mewakili saluran dalam JGroups) dan kemudian terhubung ke sebuah kelompok yang disebut
AlarmChannel. Jika ini adalah pertama connect, maka kelompok akan dibuat pada tahap ini
(Mungkin dalam contoh ini, atau alarm tidak akan sangat efektif). Constructor untuk pesan mengambil tiga parameter: tujuan, sumber dan payload. Didalam kasus, tujuan adalah nol, yang menentukan bahwa pesan tersebut akan dikirim ke semua anggota (Jika alamat yang ditentukan, itu dikirim ke alamat yang hanya). Sumber itu juga null; ini tidak perlu diberikan dalam JGroups karena akan dimasukkan secara otomatis. payload adalah terstruktur array byte yang dikirimkan ke semua anggota kelompok melalui send metode. kode untuk membuat sebuah instance baru dari kelas FireAlarmJG dan kemudian menaikkan alarm akan:
FireAlarmJG alarm = baru FireAlarmJG ();
alarm.raise ();
Yang sesuai kode untuk penerima akhir memiliki struktur yang sama dan ditampilkan di Gambar 6.6. Dalam kasus ini, bagaimanapun, setelah menghubungkan r Metode eceive disebut. Ini Metode mengambil satu parameter, timeout. Jika diatur ke nol; seperti dalam kasus ini, menerima
pesan akan memblokir sampai pesan diterima. Perhatikan bahwa dalam pesan masuk JGroups
buffer dan menerima pengembalian unsur atas dalam buffer. Jika tidak ada pesan yang hadir,
kemudian menerima blok menunggu pesan berikutnya. Tegasnya, terima dapat mengembalikan
berbagai jenis objek - misalnya, pemberitahuan perubahan dalam keanggotaan atau dari
dicurigai kegagalan anggota kelompok (maka pemain untuk Pesan di atas).
Sebuah penerima diberikan harus menyertakan kode berikut untuk menunggu alarm:
Fire Alarm Consumer JG alarmCall = baru FireAlarmConsumerJG ();
String msg = alarmCall.await ();
System.out.println ("Alarm diterima:" + msg);
Blok bangunan • blok bangunan adalah abstraksi tingkat yang lebih tinggi di atas saluran kelas dibahas di atas. Saluran serupa di tingkat ke soket. Bangunan blok analog dengan paradigma komunikasi yang lebih canggih dibahas dalam Bab 5, menawarkan dukungan untuk sering terjadi pola komunikasi (tetapi dalam hal ini ditargetkan pada komunikasi multicast). Contoh blok bangunan di JGroups adalah:
• Olahpesan eDispatcher adalah yang paling intuitif blok bangunan yang ditawarkan di JGroups. Dalam komunikasi kelompok, seringkali berguna untuk pengirim untuk mengirim pesan untuk kelompok dan kemudian menunggu untuk beberapa atau semua balasan. MessageDispatcher mendukung ini dengan menyediakan metode castMessage yang mengirim pesan ke grup dan blok sampai jumlah tertentu balasan diterima (misalnya, sampai jumlah tertentu n, mayoritas, atau semua pesan yang diterima).
• RpcDisp Atcher mengambil metode tertentu (bersama-sama dengan parameter opsional dan
hasil) dan kemudian memanggil metode ini pada semua benda yang berhubungan dengan kelompok. Sebagai dengan MessageDispatcher, penelepon dapat memblokir menunggu beberapa atau semua balasan.
• Pemberitahuan Bus merupakan implementasi dari bus acara didistribusikan, di mana acara adalah setiap objek Java serializable. Kelas ini sering digunakan untuk melaksanakan konsistensi di cache direplikasi.
Protokol tumpukan • JGroups mengikuti arsitektur yang ditawarkan oleh Horus dan Ensemble dengan membangun tumpukan protokol dari protokol lapisan (awalnya disebut sebagai microprotocols
di dalam literatur [Van Renesse et Al.1996, 1998]). Dalam pendekatan ini, sebuah protokol aku s dua arah sebuah tumpukan lapisan protokol dengan masing-masing lapisan mengimplementasikan pengikut dua metode:
Obyek publik up (EVT acara);
Obyek publik bawah (EventID EVT);
pengolahan protokol karena itu terjadi dengan melewati peristiwa naik dan turun stack. Di
JGroups, peristiwa mungkin pesan yang masuk atau keluar atau acara manajemen, untuk
Misalnya terkait untuk melihat perubahan. Setiap lapisan dapat melaksanakan pengolahan sewenang-wenang pada pesan, termasuk memodifikasi isinya, menambahkan header atau memang menjatuhkan atau penataan kembali pesan.
Untuk menggambarkan konsep lebih lanjut, mari kita amati tumpukan protokol yang ditunjukkan pada Gambar 6.4. Hal ini menunjukkan sebuah protokol yang terdiri dari lima lapisan:
Lapisan disebut sebagai UDP adalah transportasi lapisan paling umum di JGroups. Catatan bahwa, meskipun nama, hal ini tidak sepenuhnya setara dengan protokol UDP; agak, layer menggunakan IP multicast untuk mengirim ke semua anggota dalam kelompok dan UDP datagrams khusus untuk komunikasi point-to-point. Lapisan ini karena mengasumsikan bahwa IP multicast tersedia. Jika tidak, lapisan dapat dikonfigurasi untuk mengirimkan serangkaian pesan unicast kepada anggota, mengandalkan lapisan lain untuk Penemuan keanggotaan (khususnya, lapisan dikenal sebagai PING). Untuk skala yang lebih besar sistem operasi melalui jaringan luas, lapisan TCP mungkin lebih disukai (menggunakan protokol TCP untuk mengirim pesan unicast dan lagi mengandalkan PING untuk
Penemuan keanggotaan).
Frag mengimplementasikan pesan packetization dan dikonfigurasi dalam hal ukuran pesan maksimum (8192 bytes secara default).
MERGE adalah protokol yang berhubungan dengan partisi jaringan tak terduga dan penggabungan berikutnya dari subkelompok setelah partisi. Serangkaian merge alternatif lapisan benar-benar tersedia, mulai dari yang sederhana hingga orang yang menangani, untuk Misalnya, transfer negara.
• RUPS mengimplementasikan protokol keanggotaan kelompok untuk mempertahankan tampilan yang konsisten keanggotaan di grup (lihat Bab 18 untuk informasi lebih lanjut algoritma untuk
manajemen keanggotaan kelompok).
PENYEBAB mengimplementasikan pemesanan kausal, diperkenalkan dalam Bagian 6.2.2 (dan dibahas
lebih lanjut dalam Bab 15).
Berbagai macam lapisan protokol lain yang tersedia, termasuk protokol untuk FIFO dan Total pemesanan, untuk penemuan keanggotaan dan deteksi kegagalan, untuk enkripsi pesan dan untuk menerapkan strategi aliran-kontrol (lihat situs web JGroups untuk Rincian [www.jgroups.org
]). Perhatikan bahwa karena semua lapisan mengimplementasikan antarmuka yang sama, mereka dapat dikombinasikan dalam urutan apapun, meskipun banyak dari tumpukan protokol yang dihasilkan akan
tidak masuk akal. Semua anggota kelompok harus berbagi stack protokol yang sama.
6.3 Publish-Subscribe Sistem
Kami sekarang mengalihkan perhatian kita ke daerah mempublikasikan-berlangganan sistem [Baldoni dan Virgillito 2005], kadang-kadang juga disebut sebagai sistem terdistribusi berbasis event [Muhl et
Al. 2006]. Ini yang paling banyak digunakan dari semua teknik komunikasi tidak langsung dibahas dalam bab ini. Bab 1 telah menyoroti bahwa banyak kelas sistem secara fundamental berkaitan dengan komunikasi dan pengolahan peristiwa (untuk Misalnya sistem perdagangan keuangan). Lebih khusus, sedangkan banyak sistem alami peta ke permintaan-balasan atau pola remote doa interaksi seperti yang dibahas di Bab 5, banyak yang tidak dan lebih alami dimodelkan dengan lebih dipisahkan dan
gaya reaktif pemrograman yang ditawarkan oleh peristiwa.
Sebuah sistem mempublikasikan-berlangganan adalah sistem di mana penerbit menerbitkan terstruktur peristiwa ke layanan acara dan pelanggan mengungkapkan minat dalam acara-acara tertentu melalui langganan yang dapat pola sewenang-wenang atas peristiwa terstruktur. Misalnya, pelanggan bisa mengekspresikan minat dalam semua kegiatan yang terkait dengan buku ini, seperti
ketersediaan edisi baru atau update ke situs web terkait. Tugas mempublikasikan berlangganan
sistem untuk langganan pertandingan terhadap diterbitkan peristiwa dan memastikan benar
pengiriman acara pemberitahuan.
Sebuah acara yang diberikan akan disampaikan berpotensi banyak pelanggan, dan karenanya mempublikasikan-berlangganan aku s fundamental satu-ke-banyak komunikasi paradigma.
Aplikasi mempublikasikan-berlangganan sistem • Publish-subscribe sistem yang digunakan dalam
Berbagai macam aplikasi domain, terutama yang terkait dengan skala besar penyebaran peristiwa. Contoh termasuk:
Sistem informasi keuangan;
Daerah lain dengan live feed data real-time (termasuk RSS feed);
Dukungan untuk kerja kooperatif, di mana sejumlah peserta harus informasi peristiwa kepentingan bersama;
• Dukungan untuk komputasi di mana-mana, termasuk pengelolaan acara yang berasal dari infrastruktur di mana-mana (misalnya, peristiwa lokasi);
Seperangkat luas dari aplikasi monitoring, termasuk pemantauan jaringan di Internet.
Mempublikasikan-berlangganan juga merupakan komponen kunci dari infrastruktur Google, termasuk untuk contoh penyebaran kegiatan yang terkait dengan iklan, seperti 'klik iklan', untuk
pihak yang berkepentingan (lihat Bab 21). Untuk menggambarkan konsep lebih lanjut, kita mempertimbangkan sistem dealing room sederhana sebagai contoh dari kelas yang lebih luas dari sistem informasi keuangan.
Berurusan sistem kamar: Pertimbangkan sebuah sistem dealing room sederhana yang tugasnya adalah untuk memungkinkan dealer menggunakan komputer untuk melihat informasi terbaru tentang harga pasar dari saham mereka berurusan. Harga pasar untuk saham bernama tunggal diwakili oleh
objek yang terkait. Informasi tiba di dealing room dari beberapa yang berbeda sumber eksternal dalam bentuk update untuk beberapa atau semua benda yang mewakili saham dan dikumpulkan oleh proses yang kita sebut penyedia informasi. Dealer biasanya hanya tertarik pada saham spesialis mereka sendiri. Sebuah sistem dealing room bisa dilaksanakan oleh proses dengan dua tugas yang berbeda:
• Sebuah proses penyedia informasi terus menerus menerima informasi perdagangan baru dari sumber eksternal tunggal. Setiap update dianggap sebagai suatu peristiwa. Itu penyedia informasi menerbitkan peristiwa tersebut ke sistem mempublikasikan-berlangganan pengiriman ke seluruh dealer yang telah menyatakan minat dalam yang sesuai saham. Akan ada proses penyedia informasi terpisah untuk setiap eksternal sumber.
Sebuah proses penyalur menciptakan langganan yang mewakili masing-masing saham yang bernama bahwa pengguna meminta telah ditampilkan. Setiap langganan mengungkapkan minat dalam acara
terkait dengan saham tertentu pada penyedia informasi yang relevan. Ini kemudian menerima semua
informasi yang dikirim ke dalam pemberitahuan dan menampilkannya kepada pengguna.
Karakteristik mempublikasikan-berlangganan sistem • Publish-subscribe sistem memiliki dua
karakter utama:
Heterogenitas: Ketika pemberitahuan acara digunakan sebagai alat komunikasi,
komponen dalam sistem terdistribusi yang tidak dirancang untuk beroperasi dapat
dibuat untuk bekerja bersama-sama. Semua yang diperlukan adalah bahwa acara-menghasilkan objek mempublikasikan jenis peristiwa yang mereka tawarkan, dan benda-benda lain berlangganan pola peristiwa dan menyediakan sebuah antarmuka untuk menerima dan menangani pemberitahuan yang dihasilkan. Untuk Misalnya, Bates et al. [1996] menggambarkan bagaimana mempublikasikan-
berlangganan sistem dapat digunakan untuk menghubungkan komponen heterogen di Internet. Mereka menggambarkan sistem di mana Aplikasi dapat dibuat sadar lokasi dan kegiatan pengguna, seperti menggunakan komputer, printer atau buku tag elektronik. Mereka membayangkan penggunaan masa depan dalam konteks jaringan rumah perintah seperti mendukung: 'jika anak-anak datang rumah, menyalakan pemanas sentral '.
Asynchronicity: Pemberitahuan akan dikirim asynchronous oleh acara-pembangkit publishers untuk semua pelanggan yang telah menyatakan minat mereka untuk mencegah penerbit perlu melakukan sinkronisasi dengan pelanggan - penerbit dan pelanggan butuhkan harus dipisahkan. Jamur [Kindberg et al. 1996] adalah publish- berbasis objek berlangganan sistem yang dirancang untuk mendukung kerja kolaboratif, di mana user interface menampilkan objek yang mewakili pengguna dan informasi objek seperti dokumen dan notes dalam ruang kerja bersama yang disebut tempat jaringan. Negara masing-masing tempat adalah direplikasi di komputer pengguna saat ini di tempat itu. Peristiwa digunakan untuk menggambarkan perubahan objek dan fokus pengguna yang menarik. Sebagai contoh, sebuah acara bisa menentukan bahwa pengguna tertentu telah memasuki atau meninggalkan tempat atau telah melakukan tindakan tertentu pada objek. Setiap replika objek apapun yang jenis tertentu
Peristiwa relevan mengungkapkan minat mereka melalui berlangganan dan menerima notifikasi ketika mereka terjadi. Tapi pelanggan peristiwa yang dipisahkan dari benda-benda mengalami peristiwa, karena pengguna yang berbeda aktif pada waktu yang berbeda. Selain itu, berbagai jaminan pengiriman yang berbeda dapat diberikan untuk pemberitahuan - Salah satu yang dipilih harus tergantung pada persyaratan aplikasi. Sebagai contoh, jika IP multicast digunakan untuk mengirim pemberitahuan kepada sekelompok penerima, model kegagalan akan berhubungan dengan yang dijelaskan untuk IP multicast dalam Bagian 4.4.1 dan tidak akan menjamin bahwa setiap penerima tertentu akan menerima pesan notifikasi tertentu. Ini adalah cukup untuk beberapa aplikasi - misalnya, untuk memberikan negara terbaru dari pemain di Internet permainan - karena update berikutnya kemungkinan untuk melewati.
Namun, aplikasi lain memiliki persyaratan yang lebih kuat. Pertimbangkan dealing aplikasi ruang: untuk bersikap adil terhadap dealer tertarik dalam saham tertentu, kami mengharuskan semua dealer untuk saham yang sama menerima informasi yang sama. Ini berarti bahwa protokol multicast handal harus digunakan. Dalam sistem Jamur yang disebutkan di atas, pemberitahuan tentang perubahan objek
negara disampaikan andal ke server, yang tanggung jawabnya adalah untuk mempertahankan up-to-date salinan dari objek. Namun, pemberitahuan juga dikirim ke objek replika di pengguna ' komputer dengan cara multicast tidak dapat diandalkan; dalam hal yang terakhir kehilangan pemberitahuan,
mereka dapat mengambil negara obyek dari server. Ketika aplikasi memerlukan itu, pemberitahuan dapat dipesan dan dikirim andal untuk objek replika.
Beberapa aplikasi telah real-time requirements.These mencakup peristiwa dalam nuklir
pembangkit listrik atau monitor pasien rumah sakit. Hal ini dimungkinkan untuk merancang protokol multicast yang memberikan jaminan real-time serta keandalan dan pemesanan dalam sistem yang
memenuhi sifat-sifat dari sistem terdistribusi sinkron. Kami membahas mempublikasikan-berlangganan sistem secara lebih rinci di bagian berikut, mengingat model pemrograman yang mereka tawarkan sebelum memeriksa beberapa kunci tantangan implementasi, khususnya yang berkaitan dengan penyebaran skala besar peristiwa di Internet.
6.3.1 Model Pemrograman
Model pemrograman di mempublikasikan-berlangganan sistem didasarkan pada set kecil operasi, ditangkap di Gambar 6.8. Penerbit menyebarluaskan acara e melalui mempublikasikan (e) operasi dan pelanggan mengungkapkan minat dalam rangkaian peristiwa melalui langganan. Secara khusus, mereka mencapai ini melalui berlangganan (f) operasi di mana f mengacu pada filter - yaitu, pola didefinisikan lebih himpunan semua peristiwa yang mungkin. Itu ekspresi dari filter (dan karenanya langganan) ditentukan oleh berlangganan model; yang kita bahas lebih rinci di bawah. Pelanggan kemudian dapat mencabut bunga ini melalui unsubscribe (f) operasi yang sesuai. Ketika peristiwa tiba di pelanggan,
peristiwa disampaikan menggunakan notify (e) operasi.
Beberapa sistem melengkapi set atas operasi dengan memperkenalkan konsep iklan. Dengan iklan-iklan, penerbit memiliki pilihan untuk menyatakan sifat peristiwa masa depan melalui beriklan (f) operasi. Iklan didefinisikan dalam hal jenis peristiwa yang menarik (ini terjadi untuk mengambil bentuk yang sama seperti filter).
Dengan kata lain, pelanggan menyatakan minat mereka dalam hal langganan dan
penerbit opsional menyatakan gaya peristiwa mereka akan menghasilkan melalui iklan. Iklan dapat dicabut melalui panggilan unadvertise (f). Seperti disebutkan di atas, ekspresi dari publish-berlangganan sistem ini ditentukan oleh langganan (filter) model, dengan sejumlah skema didefinisikan dan
dipertimbangkan di sini dalam rangka meningkatkan kecanggihan:
Channel berbasis: Dalam pendekatan ini, penerbit menerbitkan acara untuk saluran bernama dan pelanggan kemudian subscribe ke salah satu saluran bernama untuk menerima semua peristiwa mengirim ke saluran itu. Ini adalah skema agak primitif dan satu-satunya yang mendefinisikan
saluran fisik; semua skema lainnya menggunakan beberapa bentuk penyaringan atas konten
peristiwa seperti yang akan kita lihat di bawah. Meski sederhana, skema ini telah digunakan
berhasil dalam CORBA acara Service (lihat Bab 8).
Topik berbasis (juga disebut sebagai subjek-based): Dalam pendekatan ini, kita membuat
pantat umption bahwa setiap notifikasi dinyatakan dalam sejumlah bidang, dengan satu lapangan yang menunjukkan topik. Langganan kemudian didefinisikan dalam hal topik bunga. Pendekatan ini setara dengan pendekatan berbasis channel-, dengan Perbedaan yang topik secara implisit didefinisikan dalam kasus saluran tetapi secara eksplisit dinyatakan sebagai salah satu bidang dalam pendekatan berbasis topik-. Ekspresi dari topicbased Pendekatan juga bisa ditingkatkan dengan memperkenalkan
hirarkis organisasi topik. Sebagai contoh, mari kami pertimbangkan mempublikasikan-berlangganan sistem untuk buku ini. Langganan bisa menjadi didefinisikan dalam istilah dari indirect_communication
atau indirect_communication / mempublikasikan-berlangganan. Pelanggan mengekspresikan bunga
dalam bekas akan menerima semua kegiatan yang terkait dengan bab ini, sedangkan dengan yang terakhir pelanggan bukannya bisa mengungkapkan minat dalam topik yang lebih spesifik publish subscribe.
Berbasis topik pendekatan berbasis konten adalah generalisasi dari: konten berbasis
pendekatan yang memungkinkan ekspresi langganan selama berbagai bidang dalam sebuah acara
pemberitahuan. Lebih khusus, filter berbasis konten adalah query didefinisikan dalam hal
komposisi kendala atas nilai atribut acara. Misalnya, pelanggan bisa mengungkapkan minat dalam acara yang berhubungan dengan topik mempublikasikan-berlangganan sistem, dimana sistem yang dimaksud adalah 'CORBA Acara Layanan' dan mana Penulis adalah 'Tim Kindberg' atau 'Gordon Blair'. Kecanggihan terkait bahasa query bervariasi dari sistem ke sistem, tetapi secara umum pendekatan ini adalah
secara signifikan lebih ekspresif daripada pendekatan channel- atau topik-based, tapi dengan
tantangan yang signifikan baru pelaksanaan (dibahas di bawah). Jenis-berdasarkan: Pendekatan ini secara intrinsik terkait dengan pendekatan berbasis objek di mana benda memiliki jenis tertentu. Dalam berdasarkan jenis-pendekatan, langganan didefinisikan dalam hal jenis acara dan pencocokan didefinisikan dalam hal jenis atau subtipe dari filter yang diberikan. Pendekatan ini dapat mengungkapkan berbagai filter, dari coarsegrained penyaringan berdasarkan di secara keseluruhan
nama jenis untuk pertanyaan lebih halus mendefinisikan atribut dan metode dari diberikan objek. Seperti itu berjaringan halus filter serupa di ekspresi pendekatan berbasis konten. Itu Keuntungan dari jenis berbasis pendekatan yang mereka dapat diintegrasikan elegan dalam bahasa pemrograman
dan mereka dapat memeriksa jenis kebenaran langganan, menghilangkan beberapa jenis abonemen
kesalahan.
Serta kategori-kategori klasik, sejumlah sistem komersial didasarkan pada berlangganan langsung ke obyek yang menarik. Sistem seperti ini mirip dengan mengetik berbasis pendekatan dalam bahwa mereka secara intrinsik terkait pendekatan berbasis obyek untuk, meskipun mereka berbeda dengan berfokus pada perubahan keadaan obyek yang menarik daripada predikat terkait dengan jenis objek. Mereka memungkinkan satu objek untuk bereaksi terhadap mengubah terjadi di objek lain. Pemberitahuan dari peristiwa asynchronous danditentukan oleh penerima mereka. Secara khusus, dalam aplikasi interaktif, tindakan yang pengguna melakukan pada objek - misalnya, dengan memanipulasi tombol dengan mouse atau memasukkan teks dalam kotak teks melalui keyboard - dilihat sebagai peristiwa yang menyebabkan perubahan dalam objek yang mempertahankan negara dari aplikasi. Benda-benda yang bertanggung jawab untuk menampilkan pemandangan keadaan saat diberitahu setiap kali perubahan negara.
Rosenblum dan Serigala [1997] menggambarkan arsitektur umum untuk gaya ini mempublikasikan-berlangganan sistem. Komponen utama dalam arsitektur mereka adalah layanan acara yang memelihara database pemberitahuan acara dan kepentingan pelanggan. Acara layanan diberitahu tentang peristiwa yang terjadi pada objek intetest. Pelanggan menginformasikan acara layanan tentang jenis acara mereka tertarik. Ketika suatu peristiwa terjadi pada objek yang menarik pesan yang berisi pemberitahuan tersebut dikirim langsung ke pelanggan dari jenis acara.
The Jini didistribusikan spesifikasi acara dijelaskan oleh Arnold et al. [1999] adalah salah satu
contoh dari pendekatan ini, dan studi kasus pada Jini, memimpin bersama-sama dengan lebih
latar belakang informasi tentang gaya pendekatan, dapat ditemukan di web pendamping
situs untuk buku [www.cdk5.net/rmi]. Catatan, bagaimanapun, bahwa Jini adalah relatif primitif
contoh dari sistem berbasis event terdistribusi yang memungkinkan konektivitas langsung antara
produsen dan konsumen peristiwa (maka mengorbankan waktu dan ruang uncoupling).
Sejumlah pendekatan yang lebih eksperimental juga sedang diselidiki. Untuk Sebagai contoh, beberapa peneliti sedang mempertimbangkan ekspresi menambahkan konteks [Frey dan Roman 2007, Meier dan Cahill 2010]. Konteks dan konteks kesadaran yang besar konsep dalam komputasi mobile dan di mana-mana. Konteks didefinisikan dalam Bab 19 sebagai aspek keadaan fisik relevansi dengan perilaku sistem. satu intuitif contoh konteks adalah lokasi, dan sistem tersebut memiliki potensi bagi pengguna untuk berlangganan untuk acara yang berkaitan dengan lokasi tertentu - misalnya, pesan darurat
terkait dengan bangunan di mana pengguna berada. Silia et al. [2004] juga telah memperkenalkan konsep berbasis model berlangganan dimana filter yang dinyatakan dalam semantik serta sintaks peristiwa. Lebih khusus, item data memiliki konteks semantik terkait yang menangkap makna dari barang-barang, memungkinkan untuk interpretasi dan terjemahan mungkin ke dalam format data yang berbeda, sehingga menangani heterogenitas.
Untuk beberapa kelas aplikasi, seperti sistem perdagangan keuangan dijelaskan dalam Bab 1, itu tidak cukup untuk langganan untuk mengekspresikan query atas peristiwa individu.
Sebaliknya, ada kebutuhan untuk sistem yang lebih kompleks yang dapat mengenali peristiwa yang kompleks pola. Misalnya, Bab 1 memperkenalkan contoh jual beli saham berdasarkan mengamati urutan temporal dari kegiatan yang terkait dengan berbagi harga, menunjukkan kebutuhan untuk pengolahan event yang kompleks (atau acara deteksi komposit, karena kadang-kadang bernama). Kompleks pengolahan acara memungkinkan spesifikasi pola peristiwa yang terjadi di lingkungan terdistribusi - misalnya, 'memberitahu saya jika tingkat air naik di Setidaknya 20% di Sungai Eden dalam setidaknya tiga tempat dan model simulasi juga melaporkan risiko banjir '. Contoh lebih lanjut dari pola acara muncul di Bab 1, prihatin dengan mendeteksi pergerakan harga saham selama periode waktu tertentu. Secara umum, pola bisa logis, temporal atau spasial. Untuk informasi lebih lanjut tentang peristiwa yang kompleks pengolahan, lihat Muhl et al. [2006].
6.3.2 Masalah Implementasi
Dari uraian di atas, tugas sistem mempublikasikan-berlangganan jelas: untuk memastikan bahwa Peristiwa dikirim efisien untuk semua pelanggan yang telah filter didefinisikan yang sesuai dengan
peristiwa. Ditambahkan ke ini, mungkin ada persyaratan tambahan dalam hal keamanan,
skalabilitas, penanganan kegagalan, concurrency dan kualitas layanan. Hal ini membuat pelaksanaan mempublikasikan-berlangganan sistem agak rumit, dan ini telah menjadi daerah penyelidikan intens dalam komunitas riset. Kami menganggap pelaksanaan kunci masalah di bawah, yang memeriksa terpusat dibandingkan implementasi didistribusikan sebelum pindah untuk mempertimbangkan arsitektur sistem secara keseluruhan yang diperlukan untuk melaksanakan mempublikasikan-berlangganan sistem (implementasi didistribusikan terutama dari pendekatan berbasis konten). Kami
menyimpulkan bagian dengan meringkas ruang desain sistem mempublikasikan-berlangganan,
dengan pointer terkait literatur.
Sentralisasi versus implementasi didistribusikan • Sejumlah arsitektur untuk pelaksanaan mempublikasikan-berlangganan sistem telah diidentifikasi. yang paling sederhana Pendekatan adalah untuk memusatkan pelaksanaan di node tunggal dengan server pada node yang bertindak sebagai event broker. Penerbit kemudian mempublikasikan peristiwa (dan opsional mengirim iklan) untuk broker ini, dan pelanggan mengirimkan langganan ke broker dan menerima pemberitahuan imbalan. Interaksi dengan broker kemudian melalui serangkaian pesan point-to-point; ini dapat diimplementasikan dengan menggunakan pesan lewat atau remote doa.
Pendekatan ini sangat mudah untuk diterapkan, tetapi desain kekurangan ketahanan dan skalabilitas, karena broker terpusat merupakan satu titik untuk sistem potensial kegagalan dan hambatan kinerja. implementasi akibatnya, didistribusikan mempublikasikan-berlangganan sistem juga tersedia. Dalam skema tersebut, broker terpusat digantikan oleh jaringan broker yang bekerja sama untuk menawarkan fungsi yang diinginkan sebagai diilustrasikan pada Gambar 6.9
Pendekatan tersebut memiliki potensi untuk bertahan hidup kegagalan node dan telah terbukti dapat beroperasi baik dalam penyebaran internet skala.
Mengambil langkah lebih lanjut, adalah mungkin untuk memiliki sepenuhnya peer-to-peer
penerapan sistem mempublikasikan-berlangganan. Ini adalah implementasi yang sangat populer
Strategi untuk sistem baru-baru ini. Dalam pendekatan ini, tidak ada perbedaan antara penerbit,
pelanggan dan broker; semua node bertindak sebagai broker, kooperatif menerapkan diperlukan event fungsi routing yang (seperti yang dibahas lebih lanjut di bawah).
Secara keseluruhan arsitektur sistem • Seperti disebutkan di atas, pelaksanaan terpusat skema relatif mudah, dengan layanan pusat mempertahankan repositori langganan dan pemberitahuan acara yang sesuai dengan set ini langganan. Demikian pula, implementasi dari skema berbasis channel-atau topik berbasis relatif mudah. Misalnya, implementasi didistribusikan dapat dicapai dengan pemetaan
saluran atau topik ke kelompok yang sesuai (sebagaimana disebutkan dalam Pasal 6.2) dan kemudian menggunakan fasilitas komunikasi multicast yang mendasari untuk menyampaikan peristiwa kepada pihak yang berkepentingan (bernyanyi handal dan memerintahkan varian, yang sesuai). pelaksanaan didistribusikan konten berbasis (atau dengan ekstrapolasi, jenis-based) pendekatan yang lebih kompleks dan layak dipertimbangkan lebih lanjut. Berbagai pilihan arsitektur untuk seperti pendekatan ditangkap pada Gambar 6.10 (diadaptasi dari Baldoni dan Virgillito [2005]). Di lapisan bawah, mempublikasikan-berlangganan sistem membuat kita e dari berbagai interprocess layanan komunikasi, seperti TCP / IP, IP multicast (jika tersedia) atau lebih layanan khusus, seperti yang ditawarkan misalnya dengan jaringan nirkabel. Jantung arsitektur disediakan oleh lapisan acara routing yang didukung oleh overlay jaringan
infrastruktur. Routing acara melakukan tugas memastikan bahwa pemberitahuan acara yang diarahkan seefisien mungkin untuk pelanggan yang tepat, sedangkan overlay infrastruktur mendukung ini dengan menyiapkan jaringan yang sesuai dari broker atau rekan-to-peer struktur. Untuk pendekatan berbasis konten, masalah ini disebut sebagai konten berbasis routing (CBR), dengan tujuan menjadi untuk mengeksploitasi informasi konten untuk secara efisien dengan peristiwa ke tujuan diperlukan mereka. Lapisan atas mengimplementasikan pencocokan - yaitu, memastikan bahwa peristiwa cocok langganan diberikan. Sementara ini dapat diimplementasikan sebagai lapisan diskrit, sering pencocokan didorong ke dalam acara routing yang mekanisme, seperti yang akan menjadi jelas segera.
Dalam arsitektur keseluruhan ini, ada Berbagai macam penerapan pendekatan. Kami melangkah melalui serangkaian pilih dari implementasi untuk menggambarkan umum prinsip di balik berbasis routing konten: Banjir: Pendekatan paling sederhana didasarkan pada flooding, yaitu, mengirim sebuah acara
pemberitahuan ke semua node dalam jaringan dan kemudian melaksanakan sesuai pencocokan pada akhir subsciber. Sebagai alternatif, banjir dapat digunakan untuk mengirim langganan kembali ke semua penerbit mungkin, dengan pencocokan dilakukan di penerbitan end dan acara cocok dikirim langsung ke pelanggan yang relevan dengan menggunakan komunikasi point-to-point. Banjir dapat diimplementasikan menggunakan mendasari menyiarkan atau fasilitas multicast. Atau, broker dapat diatur dalam asiklik grafik di mana setiap meneruskan pemberitahuan acara masuk ke semua tetangganya (Efektif menyediakan overlay multicast, seperti yang dibahas dalam Bagian 4.5.1). Ini
Pendekatan memiliki manfaat kesederhanaan tetapi dapat mengakibatkan banyak jaringan yang tidak perlu lalu lintas. Oleh karena itu, skema alternatif yang dijelaskan di bawah mencoba untuk mengoptimalkan jumlah pesan dipertukarkan melalui pertimbangan konten. Filtering: Satu prinsip yang mendasari banyak pendekatan adalah untuk menerapkan filtering di jaringan broker. Hal ini disebut sebagai routing yang berbasis filtering. broker maju pemberitahuan melalui jaringan hanya di mana ada jalan untuk pelanggan yang valid.
Hal ini dicapai dengan menyebarkan informasi berlangganan melalui jaringan terhadap penerbit potensial dan kemudian menyimpan terkait negara pada setiap broker. Lebih khusus, setiap node harus mempertahankan daftar tetangga yang berisi daftar semua tetangga yang terhubung dalam jaringan broker, daftar langganan yang berisi daftar semua langsung terhubung pelanggan dilayani oleh node ini, dan tabel routing.
Krusial, tabel routing ini menyimpan daftar tetangga dan langganan berlaku untuk bahwa jalur.
Pendekatan ini juga membutuhkan penerapan pencocokan pada setiap node di jaringan broker: khususnya, fungsi pertandingan membutuhkan pemberitahuan acara tertentu dan daftar node bersama dengan langganan terkait dan mengembalikan satu set node di mana pemberitahuan cocok berlangganan. Algoritma khusus untuk ini Pendekatan penyaringan ditangkap pada Gambar 6.11 (diambil dari Baldoni dan Virgillito [2005]). Ketika broker menerima mempublikasikan req
uest dari node yang diberikan, itu harus lulus pemberitahuan ini ke semua node terhubung di mana ada yang cocok sesuai berlangganan dan juga memutuskan di mana untuk menyebarkan acara ini melalui jaringan broker. Baris 2 dan 3 mencapai tujuan pertama dengan mencocokkan acara terhadap
daftar langganan dan kemudian meneruskan acara untuk semua node dengan pencocokan
langganan (yang matchlist). Baris 4 dan 5 kemudian menggunakan fungsi pertandingan lagi, ini
waktu yang cocok dengan acara terhadap tabel routing dan forwarding hanya untuk jalan yang mengarah pada langganan (fwdlist yang). Broker juga harus berhadapan dengan masuk peristiwa berlangganan. Jika acara langganan dari segera terhubung pelanggan, maka langganan ini harus dimasukkan dalam tabel langganan (baris 7 dan 8). Jika tidak, broker adalah node perantara; node ini sekarang tahu bahwa jalur ada terhadap langganan ini dan karenanya entri yang tepat ditambahkan ke
tabel routing (line 9). Dalam kedua kasus, acara langganan ini kemudian diteruskan ke semua tetangga terpisah dari node berasal (baris 10).
Iklan: Pendekatan berbasis penyaringan murni yang dijelaskan di atas dapat menghasilkan banyak lalu lintas karena propagasi langganan, dengan langganan dasarnya menggunakan pendekatan banjir kembali ke semua penerbit mungkin. Dalam sistem dengan iklan beban ini dapat dikurangi dengan menyebarkan iklan terhadap pelanggan dalam yang sama (sebenarnya, simetris) cara untuk propagasi
langganan. Ada yang menarik trade-off antara dua pendekatan, dan beberapa sistem mengadopsi kedua pendekatan di tandem [Carzaniga et al. 2001].
Rendezvous: Pendekatan lain untuk mengontrol penyebaran langganan (dan untuk mencapai load balancing alami) adalah pendekatan pertemuan. Untuk memahami hal ini Pendekatan, perlu untuk melihat set dari semua peristiwa yang mungkin sebagai ruang acara dan untuk partisi tanggung jawab untuk ruang acara ini antara set broker di jaringan. Secara khusus, pendekatan ini mendefinisikan node rendezvous, yang broker node bertanggung jawab untuk subset tertentu dari ruang acara. Untuk mencapai hal ini, diberikan algoritma routing berbasis rendezvous harus menentukan dua fungsi. Pertama, SN (s) mengambil diberikan langganan, s, dan mengembalikan satu atau lebih node pertemuan yang mengambil tanggung jawab untuk berlangganan itu. Setiap node pertemuan seperti memelihara
daftar langganan seperti dalam pendekatan penyaringan di atas, dan ke depan semua acara pencocokan
untuk set berlangganan node. Kedua, ketika sebuah peristiwa e diterbitkan, fungsi EN (e) juga mengembalikan satu atau lebih node rendezvous, kali ini bertanggung jawab untuk pencocokan e terhadap langganan dalam sistem. Perhatikan bahwa kedua SN (s) dan EN (e) kembali lebih dari satu simpul jika keandalan adalah kekhawatiran. Perhatikan juga bahwa pendekatan ini hanya bekerja jika
persimpangan EN (e) dan SN (s) adalah non-kosong untuk e diberikan yang cocok s (dikenal sebagai persimpangan aturan pemetaan, seperti yang didefinisikan oleh Baldoni dan Virgillito [2005]). Itu
kode yang sesuai untuk routing berbasis rendezvous ditunjukkan pada Gambar 6.12 (lagi diambil dari Baldoni dan Virgillito [2005]). This waktu, kita meninggalkan penafsiran algoritma sebagai latihan bagi pembaca (lihat Latihan 6.11).
Salah satu interpretasi yang menarik routing berbasis pertemuan adalah untuk memetakan acara ruang ke sebuah tabel hash didistribusikan (DHT). tabel hash didistribusikan diperkenalkan singkat dalam Bagian 4.5.1 dan diperiksa secara lebih rinci dalam Bab 10. A didistribusikan tabel hash adalah gaya
overlay jaringan yang mendistribusikan tabel hash lebih satu set node dalam jaringan peer-to-peer. Pengamatan kunci untuk routing berbasis pertemuan adalah bahwa Fungsi hash dapat digunakan untuk memetakan kedua peristiwa dan langganan ke yang sesuai simpul pertemuan untuk pengelolaan langganan tersebut. Hal ini dimungkinkan untuk menggunakan pendekatan peer-to-peer middleware lainnya untuk mendukung Acara routing dalam mempublikasikan-berlangganan sistem. Memang, th
adalah merupakan daerah yang sangat aktif penelitian dengan banyak proposal baru dan menarik yang muncul, terutama untuk sangat besar-besaran sistem [Carzaniga et al. 2001]. Salah satu pendekatan khusus adalah untuk mengadopsi bergosip sebagai sarana mendukung acara routing. Pendekatan berbasis gosip adalah mekanisme populer bagi mencapai multicast (termasuk multicast terpercaya), seperti yang dibahas dalam Bagian 18.4.1. Mereka beroperasi dengan node di jaringan secara berkala dan peristiwa probabilistically bertukar (atau data) dengan node tetangga. Melalui pendekatan ini, adalah mungkin untuk menyebarkan peristiwa efektif melalui jaringan tanpa struktur yang dikenakan oleh pendekatan-pendekatan lain. SEBUAH Pendekatan gosip murni efektif strategi alternatif untuk melaksanakan banjir, seperti dijelaskan di atas. Namun, adalah mungkin untuk mempertimbangkan informasi lokal dan, di tertentu, konten untuk mencapai apa yang disebut gosip sebagai informasi. pendekatan tersebut dapat sangat menarik dalam lingkungan yang sangat dinamis di mana jaringan atau node churn bisa tinggi [Baldoni et al. 2005].
6.3.3 Contoh Mempublikasikan-Berlangganan Sistem
Kami menyimpulkan bagian ini dengan membuat daftar beberapa contoh utama dari sistem mempublikasikan-berlangganan, menyediakan referensi untuk membaca lebih lanjut (lihat Gambar 6.13). Angka ini juga menangkap desain ruang untuk mempublikasikan-berlangganan sistem, menggambarkan betapa berbedanya des IGNS dapat mengakibatkan dari keputusan langganan dan distribusi model dan, terutama, yang mendasari Acara Routing strategi. Perhatikan bahwa acara routing tidak diperlukan untuk skema terpusat, maka kosong entri dalam tabel.
6.4 Antrian Pesan
Pesan antrian (atau lebih tepatnya, didistribusikan antrian pesan) yang lebih jauh kategori penting dari sistem komunikasi tidak langsung. Sedangkan kelompok dan mempublikasikan berlangganan menyediakan satu-ke-banyak gaya komunikasi, antrian pesan menyediakan sebuah poin ke poin layanan
menggunakan konsep dari pesan antre sebagai tipuan, sehingga mencapai sifat yang diinginkan dari ruang dan waktu uncoupling. Mereka point-to-point di bahwa tempat pengirim itu pesan ke dalam antrian, dan kemudian dihapus oleh sebuah tunggal proses. Pesan antrian juga disebut sebagai Middleware pesan-Oriented. Ini adalah kelas utama middleware komersial dengan implementasi utama termasuk IBM WebSphere MQ, MSMQ Microsoft dan Oracle Streaming Advanced Queuing (AQ). Penggunaan utama dari produk tersebut adalah untuk mencapai Aplikasi Enterprise Integrasi (EAI) -yaitu, integrasi antara aplikasi dalam sebuah perusahaan tertentu - tujuan yang dicapai oleh kopling longgar melekat dari antrian pesan. Mereka juga secara ekstensif digunakan sebagai dasar untuk sistem pemrosesan transaksi komersial karena mereka dukungan intrinsik untuk transaksi, dibahas lebih lanjut dalam Bagian 6.4.1. Kami memeriksa antrian pesan lebih rinci di bawah, mengingat pemrograman
Model yang ditawarkan oleh pesan sistem antrian sebelum membahas isu-isu implementasi.
Bagian ini kemudian menyimpulkan dengan menghadirkan Java Messaging Service (JMS) sebagai
contoh dari antrian pesan spesifikasi middleware mendukung (dan juga publishsubscribe).
6.4.1 Model Pemrograman
Model pemrograman yang ditawarkan oleh antrian pesan sangat sederhana. Ini menawarkan pendekatan untuk komunikasi dalam sistem terdistribusi melalui antrian. Khususnya, proses produsen dapat mengirim pesan ke antrian khusus dan lainnya (konsumen) Proses kemudian dapat menerima pesan dari antrian ini. Tiga gaya terimaumumnya didukung:
Blocking receive, yang akan memblokir sampai pesan yang tepat tersedia;
A-blocking non menerima (operasi polling), yang akan memeriksa status antrian dan kembali pesan jika tersedia, atau indikasi tidak tersedia sebaliknya;
Sebuah memberitahu operasi, yang akan mengeluarkan pemberitahuan acara ketika pesan adalah
tersedia dalam antrian terkait.
Pendekatan keseluruhan ini ditangkap pictorially pada Gambar 6.14. Sejumlah proses dapat mengirim pesan ke antrian yang sama, dan juga seorang jumlah penerima dapat menghapus pesan dari antrian. Kebijakan antrian biasanya pertama-in-first-out (FIFO), tetapi kebanyakan implementasi antrian pesan juga mendukung konsep prioritas, dengan pesan yang lebih tinggi-prioritas disampaikan pertama. proses konsumen juga dapat memilih pesan dari antrian berdasarkan sifat dari pesan. Lebih detail, pesan terdiri dari tujuan (yaitu, pengenal unik menunjuk antrian tujuan), metadata yang terkait dengan pesan, termasuk bidang-bidang seperti prioritas pesan dan modus pengiriman, dan juga tubuh pesan. Itu
Tubuh biasanya buram dan tak tersentuh oleh sistem antrian pesan. Terkait konten serial menggunakan salah satu pendekatan standar yang dijelaskan dalam Bagian 4.3; bahwa adalah, marshalled tipe data, serialisasi objek atau pesan terstruktur XML. Pesan ukuran yang dapat dikonfigurasi dan dapat menjadi sangat besar - misalnya, pada urutan 100 Mbytes Mengingat fakta bahwa tubuh pesan yang buram, pilihan pesan biasanya dinyatakan melalui predikat didefinisikan melalui metadata. Oracle AQ memperkenalkan twist yang menarik pada ide dasar ini untuk achieve lebih baik integrasi dengan (relasional) database; di Oracle AQ, pesan yang baris dalam database meja, dan antrian adalah tabel database yang dapat dilihat dengan menggunakan kekuatan penuh dari bahasa query database.
Salah satu properti penting dari sistem antrian pesan adalah bahwa pesan yang gigih - yaitu, antrian pesan akan menyimpan pesan tanpa batas (sampai mereka dikonsumsi) dan juga akan melakukan pesan ke disk untuk memungkinkan pengiriman yang handal. Khususnya, Berikut definisi dari komunikasi yang handal dalam Bagian 2.4.2, pesan yang dikirim adalah akhirnya menerima (validitas) dan pesan yang diterima adalah identik dengan yang dikirim, dan tidak ada pesan yang disampaikan dua kali (integritas). Oleh karena itu sistem pesan antrian menjamin bahwa pesan akan dikirimkan (dan disampaikan sekali) tetapi tidak bisa mengatakan apa-apa tentang waktu pengiriman.
Pesan lewat sistem juga dapat mendukung fungsi tambahan:
Kebanyakan sistem yang tersedia secara komersial menyediakan dukungan untuk mengirim atau menerima dari pesan yang akan terkandung dalam transaksi. Tujuannya adalah untuk memastikan bahwa semua langkah-langkah dalam transaksi selesai, atau transaksi tidak berpengaruh sama sekali (yang 'Semua atau tidak' properti). Ini bergantung pada berinteraksi dengan transaksi eksternal layanan, yang disediakan oleh lingkungan middleware. pertimbangan rinci transaksi ditangguhkan sampai Bab 16.
• A Sejumlah sistem juga mendukung transformasi pesan, dimana sewenang-wenang Transformasi dapat dilakukan pada pesan tiba. Yang paling umum penerapan konsep ini adalah untuk mengubah pesan antara format untuk menangani heterogenitas dalam representasi data yang mendasarinya. Ini bisa sesederhana mengubah dari satu urutan byte yang lain (big-endian little-endian) atau lebih
kompleks, melibatkan misalnya transformasi dari satu data eksternal representasi yang lain (seperti SOAP untuk IIOP). Beberapa sistem juga memungkinkan programmer untuk mengembangkan transformasi khusus aplikasi mereka sendiri dalam menanggapi untuk memicu dari sistem pesan antrian yang mendasari. Transformasi pesan adalah alat penting dalam menangani heterogenitas umumnya dan mencapai Integrasi Aplikasi Enterprise tertentu (seperti dibahas di atas). Perhatikan bahwa broker pesan Istilah ini sering digunakan untuk menunjukkan layanan bertanggung jawab untuk pesan transformasi.
• Beberapa implementasi antrian pesan juga menyediakan dukungan untuk keamanan. Untuk Misalnya, WebSphere MQ menyediakan dukungan untuk transmisi rahasia dari Data menggunakan Secure Sockets Layer (SSL) bersama-sama dengan dukungan untuk otentikasi dan kontrol akses. Lihat Bab 11. Sebagai kata akhir pada abstraksi pemrograman yang ditawarkan oleh antrian pesan, akan sangat membantu
untuk membandingkan gaya pemrograman dengan paradigma komunikasi lainnya. Pesan antrian serupa dalam banyak cara untuk sistem pesan-lewat dipertimbangkan dalam Bab 4. Perbedaannya adalah bahwa sementara sistem pesan-lewat memiliki antrian implisit terkait dengan pengirim dan penerima (misalnya, pesan buffer di MPI), pesan sistem antrian memiliki antrian eksplisit yang berbadan pihak ketiga, yang terpisah dari pengirim dan penerima. Ini adalah perbedaan utama ini yang membuat pesan antrian sebuah paradigma komunikasi tidak langsung dengan sifat-sifat penting dari ruang dan waktu
uncoupling.
6.4.2 Implementasi Masalah
Masalah penerapan kunci untuk sistem antrian pesan adalah pilihan antara implementasi terpusat dan terdistribusi konsep. Beberapa implementasi yang terpusat, dengan satu atau lebih pesan antrian dikelola oleh manajer antrian yang terletak di node yang diberikan. Keuntungan dari skema ini adalah kesederhanaan, namun manajer tersebut dapat menjadi agak komponen kelas berat dan memiliki potensi untuk menjadi hambatan atau titik kegagalan. Akibatnya, implementasi yang lebih terdistribusi telah diusulkan. Untuk menggambarkan arsitektur terdistribusi, kita secara singkat mempertimbangkan pendekatan diadopsi dalam WebSphere MQ sebagai wakil dari negara-of-the-art di daerah ini.
Studi kasus: WebSphere MQ • WebSphere MQ adalah middleware yang dikembangkan oleh IBM berbasis pada konsep antrian pesan, menawarkan tipuan antara pengirim dan penerima pesan [www.redbooks.ibm.com]. Antrian di WebSphere MQ dikelola oleh manajer antrian yang tuan rumah dan mengelola antrian dan memungkinkan aplikasi untuk mengakses antrian melalui Message Queue Interface (MQI). The MQI adalah antarmuka yang relatif sederhana memungkinkan aplikasi untuk melaksanakan operasi seperti menghubungkan atau melepaskan dari antrian (MQCONN dan MQDISC) atau mengirim / menerima pesan ke / dari antrian (MQPUT dan MQGET). manajer antrian beberapa dapat berada pada server fisik tunggal. Aplikasi client mengakses manajer antrian mungkin berada pada fisik yang sama Server. Lebih umum, meskipun, mereka akan berada di mesin yang berbeda dan kemudian harus berkomunikasi dengan manajer antrian melalui apa yang dikenal sebagai saluran klien. Klien saluran mengadopsi konsep yang agak akrab proxy, seperti yang diperkenalkan dalam Bab 2 dan 5,
dimana perintah MQI dikeluarkan pada proxy dan kemudian dikirim transparan ke manajer antrian untuk eksekusi menggunakan RPC. Contoh konfigurasi seperti ditunjukkanpada Gambar 6.15. Dalam konfigurasi ini, aplikasi client mengirimkan pesan ke remote manajer antrian dan beberapa layanan (pada yang sama mesin sebagai server) kemudian mengkonsumsi pesan masuk. Ini adalah penggunaan yang sangat sederhana WebSphere MQ, dan dalam prakteknya lebih umum bagi manajer antrian akan dihubungkan bersama-sama ke dalam struktur federasi, mencerminkan Pendekatan yang sering diadopsi dalam mempublikasikan-berlangganan sistem (dengan jaringan broker). Untuk mencapai hal ini, MQ memperkenalkan konsep saluran pesan sebagai searah hubungan antara dua manajer antrian yang digunakan untuk meneruskan pesan asynchronous dari satu antrian ke yang lain. Catatan terminologi di sini: pesan channel adalah koneksi antara dua manajer antrian, sedangkan saluran klien adalah hubungan antara aplikasi client dan manajer antrian. Saluran Pesan dikelola oleh agen saluran pesan (MCA) pada setiap akhir. Dua agen yang bertanggung jawab untuk membangun dan mempertahankan saluran, termasuk negosiasi awal setuju pada sifat-sifat saluran (termasuk sifat keamanan). tabel routing juga termasuk dalam setiap manajer antrian, dan bersama-sama dengan saluran ini memungkinkan topologi sewenang-wenang yang akan dibuat.
Kemampuan untuk membuat topologi disesuaikan sangat penting untuk WebSphere MQ,
memungkinkan pengguna untuk menentukan topologi yang tepat untuk domain aplikasi mereka, misalnya untuk memberikan persyaratan tertentu dalam hal skalabilitas dan kinerja. alat-alat yang tersedia untuk sistem administrator untuk membuat topologi yang cocok dan untuk menyembunyikan
kompleksitas membangun saluran pesan dan routing strategi. Berbagai macam topologi dapat dibuat,
termasuk pohon, jerat atau bus berbasis konfigurasi. Untuk menggambarkan konsep topologi lanjut, kami menyajikan salah satu contoh topologi sering digunakan dalam WebSphere penyebaran MQ, topologi hub-dan-berbicara.
Pendekatan hub-dan-berbicara: Dalam topologi hub-dan-berbicara, seorang manajer antrian ditunjuk sebagai hub. hub host berbagai layanan. aplikasi client tidak terhubung langsung ke hub ini melainkan terhubung melalui manajer antrian ditunjuk sebagai jari-jari. pesan estafet jari ke antrian pesan dari hub untuk diproses oleh berbagai layanan. Jari ditempatkan strategis di sekitar jaringan untuk mendukung berbagai klien. hub ditempatkan di suatu tempat yang tepat dalam jaringan, pada node dengan sumber daya yang cukup untuk menangani volume lalu lintas. Sebagian besar aplikasi dan layanan terletak pada hub, meskipun juga mungkin untuk memiliki beberapa layanan yang lebih lokal pada jari-jari. Topologi ini banyak digunakan dengan WebSphere MQ, terutama di skala besar penyebaran meliputi wilayah geografis yang signifikan (dan mungkin menyeberang batas-batas organisasi). Kunci untuk pendekatan ini adalah untuk dapat terhubung ke lokal berbicara melalui sambungan bandwidth tinggi, misalnya melalui jaringan area lokal (jari-jari bahkan mungkin ditempatkan di mesin fisik yang sama seperti aplikasi client untuk meminimalkan latency). Ingatlah bahwa komunikasi antara aplikasi client dan penggunaan manajer antrian RPC, sedangkan komunikasi internal antara manajer antrian adalah asynchronous (nonblocking). Ini berarti bahwa aplikasi klien hanya diblokir sampai itu pesan setor di itu
lokal antre manajer (itu lokal berbicara); berikut pengiriman, berpotensi lebih lebar jaringan area,adalah asynchronous tapi dijamin menjadi terpercaya oleh itu WebSphere MQ middleware. Jelas, kelemahan dari arsitektur ini adalah bahwa hub dapat menjadi potensi hambatan dan titik tunggal kegagalan. WebSphere MQ juga mendukung fasilitas lainnya untuk mengatasi masalah ini, termasuk kelompok manajer antrian, yang memungkinkan beberapa contoh layanan yang sama harus didukung oleh manajer antrian berganda dengan implisit load balancing seluruh instantiations yang berbeda [www.redbooks.ibm.com].
6.4.3 Studi Kasus: Java Messaging Service (JMS)
Java Messaging Service (JMS) [java.sun.com XI] adalah spesifikasi dari cara standar untuk program Java didistribusikan untuk berkomunikasi secara tidak langsung. Paling terutama, seperti yang akan dijelaskan, spesifikasi menyatukan mempublikasikan-berlangganan dan paradigma antrian pesan setidaknya dangkal dengan mendukung topik dan antrian sebagai tujuan alternatif pesan. Berbagai implementasi dari umum Spesifikasi sekarang tersedia, termasuk Yoram dari OW2, Jawa Messaging
JBoss, Sun Open MQ, Apache ActiveMQ dan OpenJMS. platform lainnya, termasuk WebSphere MQ, juga menyediakan antarmuka JMS untuk infrastruktur dasar mereka. JMS membedakan antara peran utama sebagai berikut:
Seorang klien JMS adalah program Java atau komponen yang menghasilkan atau mengkonsumsi pesan, produsen JMS adalah sebuah program yang menciptakan dan memproduksi pesan dan JMS konsumen adalah program yang menerima dan mengkonsumsi pesan.
Sebuah penyedia JMS adalah salah satu dari beberapa sistem yang menerapkan JMS spesifikasi.
• Sebuah pesan JMS adalah obyek yang digunakan untuk berkomunikasi informasi antaraJMS klien (dari produsen ke konsumen).
Sebuah tujuan JMS adalah obyek yang mendukung komunikasi tidak langsung di JMS. ini
baik topik JMS atau antrian JMS.
Pemrograman dengan JMS • Model pemrograman yang ditawarkan oleh API JMS ditangkap pada Gambar 6.16 Untuk berinteraksi dengan penyedia JMS, pertama-tama perlu untuk membuat hubungan antara program klien dan penyedia. Hal ini diciptakan melalui koneksi pabrik (layanan bertanggung jawab untuk menciptakan hubungan dengan yang dibutuhkan properti). Koneksi yang dihasilkan adalah saluran logis antara klien dan pemberi; pelaksanaan yang mendasari mungkin, misalnya, peta ke TCP / IP socket jika diterapkan melalui Internet. Perhatikan bahwa dua jenis koneksi dapat dibuat, a TopicConnection atau QueueConnection, sehingga menegakkan pemisahan yang jelas antara
dua mode operasi dalam koneksi yang diberikan.Koneksi dapat digunakan untuk membuat satu atau lebih session - sesi adalah serangkaian operasi yang melibatkan penciptaan, produksi dan konsumsi pesan terkait dengan tugas logis. Objek sesi dihasilkan juga mendukung operasi untuk membuat transaksi, mendukung semua-atau-tidak pelaksanaan serangkaian operasi, seperti yang dibahas dalam Bagian 6.4.1. Ada perbedaan yang jelas antara topik sessions dan sesi antrian di yang Topic Connection bisa dukungan satu atau topik yang lebih sesi dan QueueConnection kaleng mendukung satu atau lebih sesi antrian, tetapi tidak mungkin untuk mencampur gaya sesi dalam koneksi. Dengan demikian, dua gaya operasi yang terintegrasi dalam cara yang agak dangkal. Objek sesi merupakan pusat operasi JMS, mendukung metode untuk penciptaan pesan, produsen pesan dan konsumen pesan:
• Dalam JMS, pesan terdiri dari tiga bagian: header, satu set properti dan tubuh pesan. Header berisi semua informasi yang diperlukan untuk mengidentifikasi dan rute pesan, termasuk tujuan (referensi ke salah satu topik atau antrian), prioritas pesan, tanggal kadaluarsa, ID pesan dan timestamp. Sebagian besar bidang ini diciptakan oleh sistem yang mendasarinya, tetapi beberapa dapat diisi secara khusus melalui metode konstruktor terkait. Properti semua dan ditetapkan pengguna dapat digunakan untuk menghubungkan aplikasi-spesifik lainnya elemen metadata dengan pesan. Misalnya, jika menerapkan konteks-sadar sistem (seperti dibahas dalam Bab 19), sifat dapat digunakan untuk mengekspresikan
konteks tambahan yang terkait dengan pesan, termasuk bidang lokasi. Seperti dalam gambaran umum sistem antrian pesan, tubuh ini adalah buram dan tak tersentuh oleh sistem. Di JMS, tubuh dapat menjadi salah satu dari pesan teks, aliran byte, objek Java serial, aliran nilai Java primitif atau lebih
set terstruktur dari pasangan nama / nilai.
Seorang produser pesan adalah obyek yang digunakan untuk mempublikasikan pesan di bawah topik tertentu atau untuk mengirim pesan ke antrian.
A consum pesaner adalah obyek yang digunakan untuk berlangganan pesan yang bersangkutan dengan diberikan topik atau menerima pesan dari antrian. konsumen lebih rumit dari produsen, karena dua alasan. Pertama, adalah mungkin untuk mengasosiasikan filter dengan konsumen pesan dengan menentukan apa yang dikenal sebagai pemilih pesan-Predikat didefinisikan melalui nilai-nilai dalam header dan sifat bagian dari Pesan (tidak tubuh). Sebuah subset dari SQL bahasa query database yang digunakan untuk menentukan sifat. Ini bisa digunakan, misalnya, untuk menyaring pesan dari mengingat lokasi pada contoh konteks-sadar atas. Kedua, ada dua mode disediakan untuk menerima pesan: program baik dapat memblokir menggunakan menerima operasi atau dapat membangun objek pesan pendengar yang harus memberikan Metode onmessage yang dipanggil setiap kali pesan sesuai diidentifikasi. Contoh sederhana • Untuk menggambarkan penggunaan JMS, kita kembali ke contoh kita Seksi 6.2.3, layanan alarm kebakaran, dan menunjukkan bagaimana ini akan dilaksanakan di JMS. Kami
memilih topik berbasis mempublikasikan-berlangganan layanan seperti ini secara intrinsik satu-ke-banyak aplikasi, dengan alarm memproduksi pesan alarm ditargetkan terhadap banyak konsumen
aplikasi. Kode untuk objek alarm kebakaran ditunjukkan pada Gambar 6.17. Hal ini lebih rumit
dari contoh JGroups setara terutama karena kebutuhan untuk membuat sambungan, sesi, penerbit dan pesan, seperti yang ditunjukkan pada baris 6-11. Ini relatif langsung terlepas dari parameter createTopicSession, yang apakah sesi harus transaksional (palsu dalam kasus ini) dan modus mengakui
Pesan (AUTO_ACKNOWLEDGE dalam contoh ini, yang berarti sesi otomatis mengakui penerimaan pesan). Ada kompleksitas tambahan terkait dengan menemukan pabrik koneksi dan topik dalam lingkungan terdistribusi (Kompleksitas menghubungkan ke saluran yang disebutkan dalam JGroups semua tersembunyi di connect metode). Hal ini dicapai dengan menggunakan JNDI (Penamaan Jawa dan Directory Interface) di baris 2 sampai 5. Hal ini termasuk untuk kelengkapan dan diasumsikan bahwa pembaca dapat menghargai tujuan baris kode tanpa penjelasan lebih lanjut. Baris 12 dan 13 berisi
kode penting untuk membuat pesan baru dan kemudian mempublikasikannya ke topik yang sesuai. Itu
kode untuk membuat contoh baru dari kelas FireAlarmJMS dan kemudian mengangkat alarm adalah:
FireAlarmJMS alarm = FireAlarmJMS baru ();
alarm.raise ();
Yang sesuai kode untuk akhir penerima sangat mirip dan ditunjukkan pada Gambar 6.18. Baris 2-9 adalah identik dan membuat koneksi dan sesi yang diperlukan, masing-masing. Kali ini, meskipun, sebuah objek dari tipe TopicSubscriber yang berikutnya (line 10) dibuat, dan Metode mulai di line 11 mulai berlangganan ini, memungkinkan pesan yang akan diterima. Itu memblokir menerima sejalan 12 kemudian menunggu pesan masuk dan garis 13 hasil tersebut Isi tekstual pesan ini sebagai string. Kelas ini digunakan sebagai berikut oleh konsumen:
FireAlarmConsumerJMS alarmCall = FireAlarmConsumerJMS baru ();
String msg = alarmCall.await ();
System.out.println ( "Alarm diterima:" + msg);
Secara keseluruhan studi kasus ini telah menggambarkan bagaimana kedua mempublikasikan berlangganan dan antrian pesan dapat didukung oleh solusi middleware tunggal (dalam hal ini JMS), menawarkan programmer pilihan satu-ke-banyak atau varian point-to-point tidak langsung
komunikasi, masing-masing.
6.5 Pendekatan Memori Bersama
Pada bagian ini, kita memeriksa paradigma komunikasi tidak langsung yang menawarkan sebuah abstraksi dari memori bersama. Kami melihat sebentar di didistribusikan teknik memori bersama yang
dikembangkan terutama untuk komputasi paralel sebelum pindah ke ruang tupel komunikasi, pendekatan yang memungkinkan programmer untuk membaca dan menulis tupel dari bersama ruang tupel. Sedangkan didistribusikan memori bersama beroperasi pada tingkat membaca dan menulis byte, ruang tuple menawarkan perspektif-tingkat yang lebih tinggi dalam bentuk semi terstruktur data. Sebagai tambahan, sedangkan didistribusikan memori bersama diakses oleh alamat, tuple,ruang adalah asosiatif, persembahan bentuk konten-addressable memori [Gelernter 1985].
Bab 18 dari edisi keempat buku ini tersedia mendalam cakupan didistribusikan memori bersama, termasuk model konsistensi dan beberapa studi kasus. Ini bab dapat ditemukan di situs web pendamping untuk buku [www.cdk5.net/dsm].
6.5.1 Distributed Memori Bersama
Didistribusikan memori bersama (DSM) adalah sebuah abstraksi yang digunakan untuk berbagi data antara komputer yang tidak berbagi memori fisik. Proses mengakses DSM oleh membaca dan
update untuk apa yang tampaknya menjadi memori biasa dalam ruang alamat mereka. Namun,
sistem runtime yang mendasari memastikan transparan bahwa proses mengeksekusi pada berbagai
komputer mengamati update yang dibuat oleh satu sama lain. Seolah-olah akses proses
shared memori tunggal, tetapi sebenarnya memori fisik didistribusikan (lihat Gambar 6.19).
Titik utama dari DSM adalah bahwa hal itu suku cadang programmer keprihatinan pesan melewati saat menulis aplikasi yang mungkin harus menggunakannya. DSM terutama alat untuk aplikasi paralel atau untuk setiap aplikasi terdistribusi atau kelompok aplikasi di mana individu bersama item data dapat diakses langsung. DSM pada umumnya kurang tepat dalam sistem client-server, di mana klien biasanya melihat sumber daya server-diadakan sebagai data abstrak dan mengaksesnya dengan permintaan (untuk alasan modularitas dan perlindungan). Pesan lewat tidak dapat dihindari sama sekali dalam sistem terdistribusi: di ketiadaan dari fisik memori bersama, dukungan DSM runtime harus mengirim pembaruan di pesan antar komputer. sistem DSM mengelola data direplikasi: setiap komputer memiliki
salinan lokal dari item data yang baru diakses disimpan dalam DSM, untuk kecepatan akses. Itu masalah pelaksanaan DSM terkait dengan isu-isu replikasi yang akan dibahas dalam Bab 18, serta orang-orang dari caching berbagi file, dibahas dalam Bab 12. Salah satu contoh penting pertama dari implementasi DSM adalah Apollo sistem file domain [Leach et al. 1983], di mana proses-proses yang diselenggarakan oleh berbagai workstation berbagi file dengan memetakannya secara bersamaan ke dalam ruang alamat mereka. Ini contoh menunjukkan bahwa didistribusikan memori bersama dapat terus-menerus. Artinya, mungkin hidup lebih lama dr pelaksanaan proses atau kelompok proses yang mengakses dan dibagi oleh
kelompok yang berbeda dari proses dari waktu ke waktu.
Signifikansi DSM pertama tumbuh bersama pengembangan bersama-memori multiprocessors (dibahas lebih lanjut dalam Bagian 7.3). Banyak penelitian telah pergi ke menyelidiki algoritma cocok untuk komputasi paralel pada multiprocessors ini. Di hardware tingkat arsitektur, perkembangan mencakup strategi caching dan cepat interkoneksi prosesor-memori, yang bertujuan untuk memaksimalkan jumlah prosesor yang dapat dipertahankan sementara mencapai memori akses cepat latency dan throughput [Dubois et al. 1988]. Di mana proses yang terhubung ke modul memori lebih
bus umum, batas praktis di urutan 10 prosesor sebelum kinerja degradasi drastis karena pertentangan bus. Prosesor berbagi memori umumnya dibangun dalam kelompok empat, berbagi modul memori melalui bus pada sirkuit tunggal naik. Multiprocessors dengan sampai 64 prosesor total dibangun dari seperti papan dalam arsitektur Non-Uniform Memory Access (NUMA). Ini adalah hirarkis arsitektur di mana papan empat prosesor yang terhubung menggunakan performa tinggi beralih atau bus tingkat yang lebih tinggi. Dalam arsitektur NUMA, prosesor melihat satu alamat ruang yang berisi semua memori dari semua papan. Tetapi akses latency untuk on-board memori kurang dari itu untuk modul memori pada papan yang berbeda - maka nama Othis arsitektur. Dalam Multiprocessors didistribusikan-memori dan cluster komponen komputasi off-the-rak (sekali lagi, lihat Bagian 7.3), prosesor tidak berbagi memori tetapi terhubung dengan jaringan kecepatan yang sangat tinggi. Sistem ini, seperti tujuan umum sistem terdistribusi, dapat skala ke nomor jauh lebih besar dari prosesor dari memori bersama multiprocessors 64 atau lebih. Sebuah pusat pertanyaan bahwa telah ditempuh oleh DSM
dan multiprosesor masyarakat penelitian adalah apakah itu investasi dalam pengetahuan oshared
ingatan algoritma dan terkait perangkat lunak dapat langsung ditransfer untuk lebih memori terdistribusi scalable arsitektur.
Pesan lewat vs DSM • Sebagai mekanisme komunikasi, DSM sebanding dengan message passing bukan dengan komunikasi request-reply berbasis, sejak aplikasi untuk pemrosesan paralel, khususnya, memerlukan penggunaan asynchronous komunikasi. DSM dan pesan-passing pendekatan untuk pemrograman dapat kontras sebagai berikut:
Layanan yang ditawarkan: Berdasarkan model message-passing, variabel harus marshalled dari satu proses, ditransmisikan dan unmarshalled ke variabel lain di penerima yang proses. Sebaliknya, dengan memori bersama proses yang terlibat variabel pangsa langsung, sehingga tidak ada marshalling diperlukan - bahkan dari pointer ke variabel bersama – dan sehingga tidak ada operasi komunikasi yang terpisah diperlukan. kebanyakan implementasi memungkinkan variabel yang disimpan dalam DSM diberi nama dan diakses sama ke biasa variabel pembagiannya. Dalam mendukung pesan lewat, di sisi lain, adalah bahwa hal itu memungkinkan proses untuk berkomunikasi sementara dilindungi dari satu sama lain dengan memiliki pribadi ruang alamat, sedangkan proses berbagi DSM dapat, misalnya, menyebabkan satu sama lain gagal dengan keliru mengubah data. Selanjutnya, ketika pesan lewat digunakan antara komputer heterogen, marshalling mengurus perbedaan dalam data perwakilan; tapi bagaimana bisa memori dibagi antara komputer dengan, misalnya, representasi bilangan bulat yang berbeda?
Sinkronisasi antara proses dicapai dalam model pesan melalui pesan lewat primitif sendiri, menggunakan teknik seperti server kunci implementasi dibahas dalam Bab 16. Dalam kasus DSM, sinkronisasi via konstruksi normal untuk pemrograman bersama-memori seperti kunci dan Semaphore
(Meskipun ini memerlukan implementasi yang berbeda di memori terdistribusi lingkungan Hidup). Bab 7 membahas tentang objek sinkronisasi seperti dalam konteks pemrograman dengan benang.
Akhirnya, karena DSM dapat dibuat gigih, proses-proses berkomunikasi melalui DSMcdapat melakukan dengan masa hidup yang tidak tumpang tindih. Sebuah proses dapat meninggalkan data dalam disepakati lokasi memori untuk yang lain untuk memeriksa ketika berjalan. Sebaliknya, proses
berkomunikasi melalui pesan lewat harus mengeksekusi pada waktu yang sama. Efisiensi: Percobaan menunjukkan bahwa program paralel tertentu dikembangkan untuk DSM dapat dibuat untuk melakukan sekitar serta program fungsional setara ditulis untuk pesan-lewat platform pada hardware yang sama [Carter et al. 1991] - setidaknya di kasus nomor yang relatif kecil dari komputer (10 atau lebih). Namun, hasil ini tidak bisa disamaratakan. Kinerja program berdasarkan DSM tergantung pada banyak faktor, seperti yang akan kita bahas di bawah - terutama pola berbagi data (seperti apakah item diperbarui oleh beberapa proses). Ada perbedaan dalam visibilitas biaya yang terkait dengan dua jenis pemrograman. Dalam pesan lewat, semua akses data remote yang eksplisit dan karena itu programmer selalu menyadari apakah operasi tertentu di-proses atau melibatkan biaya komunikasi. Menggunakan DSM, bagaimanapun, setiap membaca tertentu atau memperbarui mungkin atau mungkin tidak melibatkan komunikasi dengan dukungan runtime yang mendasari. Apakah itu tidak atau tidak tergantung pada faktor-faktor seperti apakah data telah diakses sebelum dan pola pembagian antara proses di komputer yang berbeda. Tidak ada jawaban pasti apakah DSM adalah lebih baik untuk pesan lewat untuk aplikasi tertentu. DSM tetap alat yang statusnya utama tergantung padaefisiensi dengan yang dapat diimplementasikan.
6.5.2 Komunikasi Ruang Tupel
Ruang tupel pertama kali diperkenalkan oleh David Gelernter dari Yale University sebagai sebuah novel
bentuk komputasi terdistribusi berdasarkan apa yang ia sebut sebagai komunikasi generatif [Gelernter 1985]. Dalam pendekatan ini, proses berkomunikasi secara tidak langsung dengan menempatkan tupel
dalam ruang tupel, dari mana proses lain dapat membaca atau menghapusnya. Tupel tidak memiliki alamat tetapi diakses oleh pencocokan pola pada konten (konten-addressable memori, seperti yang dibahas oleh Gelernter [1985]). Resultan model pemrograman Linda telah sangat berpengaruh dan telah menyebabkan perkembangan yang signifikan dalam didistribusikan pemrograman termasuk sistem seperti Agora [Bisiani dan Untuk tahun 1988] dan, lebih secara signifikan, JavaSpaces dari Sun (dibahas di bawah) dan IBM TSpaces. ruang tupel komunikasi juga telah berpengaruh dalam bidang komputasi di mana-mana, untuk alasan yang dieksplorasi secara mendalam pada Bab 19. Bagian ini memberikan pemeriksaan paradigma ruang tuple yang berlaku untuk komputasi terdistribusi. Kita mulai dengan memeriksa model pemrograman yang ditawarkan oleh tuple spasi sebelum sebentar mempertimbangkan isu-isu implementasi yang terkait. Bagian ini kemudian menyimpulkan dengan memeriksa JavaSpaces spesifikasi sebagai studi kasus, menggambarkan bagaimana ruang tuple telah berevolusi untuk merangkul dunia berorientasi objek. Model pemrograman • Dalam tuple model pemrograman ruang, proses berkomunikasi melalui ruang tuple - koleksi bersama tupel. Tupel pada gilirannya terdiri dari urutan bidang satu atau lebih diketik data seperti < "fred", 1958>, < "sid" 1964>
dan <4, 9,8, "Ya">. Kombinasi dari jenis tupel mungkin ada dalam tuple yang sama ruang. Memproses data saham dengan mengakses ruang tuple yang sama: mereka menempatkan tupel di tuple ruang menggunakan operasi menulis dan membaca atau ekstrak mereka dari ruang tupel menggunakan membaca atau mengambil operasi. Operasi tulis menambahkan tuple tanpa mempengaruhi tupel yang ada di uang angkasa. Operasi read mengembalikan nilai satu tuple tanpa mempengaruhi
Isi ruang tupel. Operasi take juga kembali tupel, tetapi dalam kasus ini juga menghapus tupel dari ruang tupel. Ketika membaca atau menghapus tupel dari ruang tuple, proses menyediakan tupel spesifikasi dan ruang tuple mengembalikan setiap tuple yang cocok spesifikasi yang – sebagai disebutkan di atas, ini adalah jenis asosiatif menangani. Untuk memungkinkan proses untuk sinkronisasi kegiatan mereka, membaca dan mengambil operasi kedua blok sampai ada tuple yang cocok di ruang tuple. Spesifikasi tupel meliputi jumlah bidang dan nilai-nilai yang diperlukan atau jenis bidang. Misalnya, mengambil (<String, integer>) bisa ekstrak baik < "fred" 1958> atau < "sid" 1964>; mengambil (<String, 1958>) akan mengambil hanya < "Fred" 1958> dari dua. Dalam paradigma ruang tupel, tidak ada akses langsung ke tupel dalam ruang tuple diperbolehkan dan proses harus mengganti tupel dalam ruang tuple bukannya memodifikasi mereka. Demikian, tupel yang berubah. Anggaplah, misalnya, bahwa serangkaian proses mempertahankan bersama meja di ruang tuple. Hitungan saat ini (katakanlah, 64) adalah dalam tuple < "counter", 64>. SEBUAH Proses harus mengeksekusi kode dari form berikut untuk kenaikan counter di
myTS ruang tuple: <S, hitung>: = myTHS.take (< "counter", integer>); myTS.write (< "counter", hitung + 1>); Sebuah ilustrasi lebih lanjut dari paradigma ruang tuple adalah diberikan pada Gambar 6.20. tuple ini ruang berisi berbagai tupel yang mewakili informasi geografis tentang negara di Inggris, termasuk populasi dan kota-kota besar. Take operasi mengambil (<String, "Skotlandia", String>) akan cocok < "Modal", "Skotlandia", "Edinburgh">, sedangkan mengambil (<String, "Skotlandia", Integer>) akan cocok < "Penduduk", "Skotlandia", 5168000>. Operasi tulis menulis (< "Penduduk", "Wales, 2900000>) akan menyisipkan tuple baru di ruang tuple dengan informasi tentang populasi Wales. Akhirnya, membaca (< "Penduduk", String, Integer) dapat cocok dengan tupel setara untuk populasi Inggris, Skotlandia atau memang Wales, jika operasi ini dijalankan setelah write operasi yang sesuai. Satu akan dipilih nondeterministically oleh tupel implementasi ruang dan, dengan ini menjadi operasi baca, tuple akan tetap di ruang tupel. Perhatikan bahwa menulis, membaca dan mengambil dikenal sebagai keluar, rd dan di Linda; kita menggunakan mantan nama yang lebih deskriptif dalam buku ini. Terminologi ini juga digunakan dalam JavaSpaces, dibahas dalam studi kasus di bawah ini. Properti yang berhubungan dengan ruang tuple: Gelernter [1985] menyajikan beberapa menarik properti yang berhubungan dengan komunikasi ruang tuple, menyoroti khususnya kedua ruang dan waktu uncoupling seperti yang dibahas dalam Bagian 6.1: Ruang uncoupling: Sebuah tuple ditempatkan di ruang tupel dapat berasal dari sejumlah Proses pengirim dan dapat dikirimkan ke salah satu dari sejumlah calon penerima.
Properti ini juga disebut sebagai penamaan didistribusikan di Linda. Waktu uncoupling: Sebuah tuple ditempatkan di ruang tuple akan tetap berada di ruang yang tuple sampai dihapus (berpotensi tanpa batas), dan karenanya pengirim dan penerima tidak perlu tumpang tindih dalam waktu. Bersama-sama, fitur ini memberikan pendekatan yang sepenuhnya didistribusikan dalam ruang dan waktu dan juga menyediakan untuk bentuk berbagi didistribusikan variabel dibagi melalui ruang tupel. Gelernter [1985] juga mengeksplorasi berbagai sifat lain yang terkait dengan bukan gaya fleksibel penamaan yang digunakan dalam Linda (disebut penamaan bebas). Itu pembaca yang tertarik diarahkan ke kertas Gelernter untuk informasi lebih lanjut tentang topik ini. Variasi pada tema: Sejak diperkenalkannya Linda, perbaikan telah diusulkan untuk model asli:
Model Linda asli mengusulkan, ruang tuple tunggal global. Ini bukan optimal dalam sistem yang besar, karena mengarah ke bahaya aliasing yang tidak diinginkan dari tupel: sebagai jumlah tupel dalam ruang tuple meningkat, ada peluang peningkatan membaca atau mengambil pencocokan tuple oleh kecelakaan. Hal ini sangat mungkin ketika pencocokan pada jenis, seperti dengan mengambil (<String, integer>), seperti yang disebutkan di atas. Mengingat ini, sejumlah sistem telah diusulkan beberapa ruang tuple, termasuk kemampuan untuk secara dinamis menciptakan ruang tuple, memperkenalkan tingkat scoping ke sistem (lihat, misalnya, studi kasus JavaSpaces bawah).
• Linda diantisipasi untuk dilaksanakan sebagai entitas terpusat tapi kemudian sistem telah bereksperimen dengan implementasi didistribusikan ruang tuple (termasuk strategi untuk memberikan toleransi kesalahan lebih). Mengingat pentingnya topik ini untuk buku ini, kita fokus pada ini dalam isu-isu implementasi ayat di bawah ini.
• Para peneliti juga telah bereksperimen dengan memodifikasi atau memperluas operasi tersedia di ruang tuple dan beradaptasi semantik yang mendasari. satu agak Usulan menarik adalah untuk menyatukan konsep tupel dan ruang tuple oleh pemodelan segala sesuatu sebagai (unordered) set - yaitu, ruang tuple adalah set tupel dan tupel adalah set nilai-nilai, yang mungkin sekarang juga mencakup tupel. Varian ini dikenal sebagai Bauhaus Linda [Carriero et al. 1995].
• Mungkin yang paling menarik, implementasi terbaru dari ruang tuple telah pindah dari tupel item diketik data ke objek data (dengan atribut), memutar tupel ruang ke ruang objek. Proposal ini diadopsi, misalnya, dalam berpengaruh JavaSpaces sistem, dibahas lebih rinci di bawah.
masalah pelaksanaan • Banyak implementasi dari ruang tuple mengadopsi solusi terpusat di mana sumber daya ruang tuple dikelola oleh satu server. Ini memiliki kelebihan dalam hal kesederhanaan, namun solusi tersebut jelas tidak kesalahan toleran dan juga tidak akan skala. Karena itu, solusi didistribusikan telah diusulkan. Replikasi: Beberapa sistem telah mengusulkan penggunaan replikasi untuk mengatasi masalah yang diidentifikasi di atas [Bakken dan Schlichting 1995, Bessani et al. 2008, Xu dan Liskov 1989]. Proposal dari Bakken dan Schlichting [1995] dan Bessant et al. [2008] mengadopsi pendekatan yang sama untuk replikasi, disebut sebagai pendekatan mesin negara dan dibahas lebih lanjut dalam Bab 18. Pendekatan ini mengasumsikan bahwa ruang tuple berperilaku seperti mesin negara, mempertahankan negara dan mengubah negara ini dalam menanggapi peristiwa diterima
dari replika lain atau dari lingkungan. Untuk memastikan konsistensi replika (i) harus mulai di negara yang sama (ruang tupel kosong), (ii) harus mengeksekusi peristiwa dalam urutan yang sama dan (iii) harus bereaksi deterministik untuk setiap peristiwa. Sifat kedua kunci dapat dijamin dengan mengadopsi algoritma multicast benar-benar memerintahkan, seperti yang dibahas dalam Bagian 6.2.2.
Xu dan Liskov [1989] mengadopsi pendekatan yang berbeda, yang mengoptimalkan replikasi Strategi dengan menggunakan semantik dari ruang operasi tuple tertentu. Dalam proposal ini, update dilakukan dalam konteks tampilan saat (set disepakati replika) dan tupel juga dibagi menjadi tupel set yang berbeda berdasarkan nama logis mereka terkait (Ditunjuk sebagai field pertama di tupel). Sistem ini terdiri dari satu set pekerja melaksanakan perhitungan pada ruang tuple, dan satu set replika ruang tupel. A diberikan simpul fisik dapat berisi sejumlah pekerja, replika atau memang keduanya; diberikan
pekerja karena mungkin atau mungkin tidak memiliki replika lokal. Node dihubungkan oleh jaringan komunikasi yang mungkin kalah, menduplikasi atau menunda pesan dan dapat memberikan pesan rusak. partisi jaringan juga dapat terjadi. Operasi write diimplementasikan dengan mengirimkan pesan multicast atas saluran komunikasi tidak dapat diandalkan untuk semua anggota dari pandangan. Pada penerimaan, anggota menempatkan tuple ini ke replika mereka dan mengakui penerimaan. Permintaan tulis diulang sampai semua pengakuan diterima. Untuk operasi yang benar dari protokol, replika harus mendeteksi dan mengakui duplikat permintaan, tetapi tidak melaksanakan Operasi tulis terkait. Operasi read terdiri dari mengirim pesan multicast untuk semua replika. Setiap replika mencari kecocokan dan mengembalikan pertandingan ini ke situs yang meminta. Tupel pertama Returned disampaikan sebagai hasil dari membaca. Ini mungkin berasal dari simpul lokal, tetapi mengingat bahwa banyak pekerja tidak akan memiliki replika lokal, ini tidak dijamin.
Operasi mengambil lebih kompleks karena kebutuhan untuk menyepakati tuple ke diseleksi dan untuk menghapus tupel ini setuju dari semua salinan. Algoritma hasil di dua fase. Pada tahap 1, spesifikasi tuple dikirim ke semua replika, dan replika upaya untuk memperoleh kunci pada tuple set terkait cerita bersambung permintaan take pada replika (menulis dan membaca operasi tidak terpengaruh oleh kunci); jika kunci tidak bisa diperoleh, permintaan take ditolak. Setiap replika yang berhasil memperoleh kunci merespon dengan himpunan tupel yang cocok. Langkah ini diulang sampai semua replika memiliki
menerima permintaan dan merespon. Proses memulai kemudian dapat memilih salah satu tuple dari
persimpangan semua balasan dan kembali ini sebagai hasil dari permintaan take. Jika memang tidak mungkin untuk mendapatkan mayoritas kunci, replika diminta untuk melepaskan kunci mereka dan
Tahap 1 mengulangi. Pada fase 2, tuple ini harus dihapus dari semua replika. Hal ini dicapai dengan
diulang multicast ke replika dalam tampilan sampai semua telah mengakui penghapusan. Sebagai
dengan permintaan menulis, perlu untuk replika untuk mendeteksi permintaan berulang dalam fase 2 dan hanya mengirim pengakuan lain tanpa melakukan penghapusan lain (Jika tidak beberapa tupel bisa keliru dihapus pada tahap ini). Langkah-langkah yang terlibat untuk setiap operasi dirangkum dalam Gambar 6.21. Perhatikan bahwa algoritma yang terpisah diperlukan untuk mengelola lihat perubahan jika kegagalan node terjadi atau partisi jaringan (lihat Xu dan Liskov [1989] untuk rincian). Algoritma ini dirancang untuk meminimalkan penundaan diberikan semantik dari tiga tuple s operasi kecepatan: baca operasi hanya memblokir sampai replika pertama merespon permintaan. mengambil operasi memblokir sampai akhir fase 1, ketika tuple yang akan dihapus telah sepakat. Operasi tulis dapat kembali segera.
Gambar 6.21 Replikasi dan operasi ruang tuple [Xu dan Liskov 1989]
Menulis 1. situs yang meminta multicast permintaan menulis ke semua anggota dari pandangan;
2. Pada menerima permintaan ini, anggota masukkan tuple ke dalam replika mereka dan mengakui aksi ini;
3. Langkah 1 diulang sampai semua pengakuan diterima.
Baca baca
1. Situs yang meminta multicast permintaan membaca untuk semua anggota dari pandangan;
2. Pada menerima permintaan ini, anggota yang mengembalikan tuple yang cocok untuk pemohon;
3. Pemohon mengembalikan tupel pencocokan pertama yang diterima sebagai hasil dari operasi (mengabaikan orang lain);
4. Langkah 1 diulang sampai setidaknya satu respon diterima.
mengambil
Tahap 1: Memilih tuple yang akan dihapus
1. situs yang meminta multicast permintaan take kepada semua anggota dari pandangan;
2. Pada menerima permintaan ini, masing-masing replika memperoleh kunci pada tuple set terkait dan, jika kunci tidak dapat diperoleh, permintaan take ditolak;
3. Semua anggota menerima membalas dengan himpunan semua tupel yang cocok;
4. Langkah 1 diulang sampai semua situs telah menerima permintaan dan merespon dengan set mereka tupel dan persimpangan adalah non-null;
5. Sebuah tuple tertentu dipilih sebagai hasil dari operasi (yang dipilih secara acak dari persimpangan
dari semua jawaban);
6. Jika hanya minoritas menerima permintaan, minoritas ini diminta untuk melepaskan kunci mereka dan fase 1 mengulangi.
Tahap 2: Melepaskan tuple yang dipilih
1. situs meminta multicast permintaan hapus untuk semua anggota pandangan mengutip tuple yang akan dihapus;
2. Pada menerima permintaan ini, anggota menghapus tupel dari replika mereka, mengirim pengakuan
dan melepaskan kunci;
3. Langkah 1 diulang sampai semua pengakuan diterima.
Ini, meskipun, memperkenalkan tingkat yang tidak dapat diterima concurrency. Misalnya, membaca sebuah operasi dapat mengakses tuple yang seharusnya dihapus dalam tahap kedua take a operasi. Oleh karena itu tingkat tambahan kontrol konkurensi yang diperlukan. Khususnya, Xu dan Liskov [1989] memperkenalkan kendala tambahan berikut:
• Operasi setiap pekerja harus dijalankan pada setiap replika dalam urutan yang sama karena mereka dikeluarkan oleh pekerja ;.
• Operasi tulis tidak harus dijalankan di replika sampai semua take sebelumnya operasi yang dikeluarkan oleh pekerja sama telah menyelesaikan semua replika di lihat pekerja.
Contoh lebih lanjut dari menggunakan replikasi disediakan dalam Bab 19, di mana kami menyajikan
L 2 Pendekatan imbo, yang menggunakan replikasi untuk menyediakan ketersediaan tinggi di ponsel
lingkungan [Davies et al. 1998]. pendekatan lain: Berbagai pendekatan lain telah digunakan dalam
pelaksanaan abstraksi ruang tuple, termasuk partisi ruang tupel atas sejumlah node dan pemetaan ke peer-to-peer hamparan:
• The Linda Kernel dikembangkan di University of York [Rowstron dan Kayu 1996] mengadopsi pendekatan yang tupel yang dipartisi di berbagai tersedia server ruang tuple (TSSs), seperti digambarkan pada Gambar 6.22. Tidak ada replikasi tupel; yaitu, hanya ada satu salinan dari setiap tuple.
motivasi adalah untuk meningkatkan kinerja dari ruang tupel, terutama untuk paralel yang sangat
computation.When tupel ditempatkan dalam ruang tuple, algoritma hashing digunakan untuk
pilih salah satu server ruang tuple yang akan digunakan. Pelaksanaan membaca atau mengambil sedikit lebih kompleks, sebagai spesifikasi tuple disediakan yang dapat menentukan jenis atau nilai-nilai dari bidang terkait. Algoritma hashing menggunakan ini tupel, dan pencarian linear kemudian harus bekerja sampai tuple pencocokan ditemukan. Perhatikan bahwa karena hanya ada satu salinan dari tuple tertentu, pelaksanaan take sangat sederhana. Beberapa implementasi dari ruang tuple telah mengadopsi pendekatan peer-to-peer di yang semua node bekerja sama untuk menyediakan layanan ruang tupel. Pendekatan ini sangat menarik mengingat ketersediaan intrinsik dan skalabilitas dari peer-to-peer solusi. Contoh peer-to-peer implementasi mencakup PeerSpaces [Busi et Al. 2003], yang dikembangkan menggunakan JXTA peer-to-peer middleware [jxta.dev.java.net], KAPUR dan TOTA (yang terakhir dua sistem fitur dalam Bab 19). Studi kasus: JavaSpaces • JavaSpaces adalah alat untuk komunikasi ruang tuple dikembangkan oleh Sun [java.sun.com X, [Java.sun.com VI]. Lebih khusus, Sun menyediakan spesifikasi layanan JavaSpaces, dan pihak ketiga pengembang kemudian bebas untuk
Penawaran implementasi JavaSpaces (implementasi yang signifikan termasuk GigaSpaces www.gigaspaces.com] Dan Blitz [www.dancres.org]). Alat ini sangat tergantung pada Jini (penemuan layanan Sun, dibahas lebih lanjut dalam Bagian 19.2.1), seperti yang akan menjadi jelas di bawah ini. The Jini Teknologi Starter Kit juga mencakup pelaksanaan JavaSpaces, disebut sebagai Outrigger.
Tujuan dari teknologi JavaSpaces adalah: untuk offer platform yang menyederhanakan desain aplikasi terdistribusi dan jasa; untuk sederhana dan minim dalam hal jumlah dan ukuran kelas yang terkait dan
memiliki footprint kecil untuk memungkinkan kode untuk dijalankan pada perangkat terbatas sumber daya (seperti sebagai ponsel cerdas); untuk memungkinkan implementasi replikasi dari spesifikasi (walaupun dalam prakteknya sebagian besar implementasi yang terpusat).
Pemrograman dengan JavaSpaces: JavaSpaces memungkinkan programmer untuk membuat sejumlah contoh dari ruang, di mana ruang adalah bersama, repositori terus-menerus dari objek (dengan demikian menawarkan ruang objek dalam terminologi diperkenalkan di atas). Lebih khusus, sebuah item dalam JavaSpace suatu disebut sebagai entri: sekelompok obyek yang terkandung dalam kelas yang mengimplementasikan net.jini.core.entry.Entry. Perhatikan bahwa dengan entri yang berisi benda-benda (bukan dari tupel), adalah mungkin untuk mengasosiasikan perilaku sewenang-wenang dengan entri, sehingga secara signifikan meningkatkan kekuatan ekspresif dari pendekatan. Operasi didefinisikan pada JavaSpaces dirangkum dalam Gambar 6.23 (menunjukkan tanda tangan penuh dari masing-masing operations) dan dapat digambarkan sebagai berikut:
• Sebuah proses dapat menempatkan masuk ke contoh JavaSpace dengan metode menulis. Sebagai
dengan Jini, entri dapat memiliki sewa terkait (lihat Bagian 5.4.3), yang merupakan waktu yang akses diberikan ke objek terkait. Hal ini dapat selamanya(Lease.FOREVER) atau dapat menjadi nilai numerik yang ditentukan dalam milidetik. Setelah
• Periode ini, entri ini hancur. Menulis operasi juga dapat digunakan dalam konteks transaksi, seperti yang dibahas di bawah ini (nilai nol menunjukkan bahwa ini adalah bukan operasi transaksional). Operasi tulis mengembalikan nilai sewa mewakili sewa yang diberikan oleh JavaSpace (yang mungkin kurang dari waktu diminta). Sebuah proses dapat mengakses entri dalam JavaSpace dengan baik membaca atau mengambil operasi; membaca kembali salinan entri yang cocok dan mengambil menghapus pencocokan entri dari JavaSpace (seperti pada model pemrograman umum disajikan di atas). Persyaratan yang cocok ditentukan oleh template, yang merupakan tipe entri. bidang tertentu dalam template dapat diatur ke nilai-nilai tertentu dan lain-lain dapat dibiarkan tidak ditentukan. Sebuah pertandingan kemudian didefinisikan sebagai entri yang dari kelas yang sama sebagai
template (atau subclass valid) dan di mana ada yang sama persis untuk set nilai yang ditentukan. Seperti menulis, membaca dan mengambil dapat dilakukan dalam konteks transaksi tertentu (dibahas di bawah). Dua operasi juga memblokir; parameter akhir menentukan batas waktu yang mewakili panjang maksimum waktu bahwa proses tertentu atau benang akan memblokir, misalnya untuk menangani kegagalan dari proses penyediaan entri yang diberikan. The readIfExists dan takeIfExists operasi setara dengan membaca dan mengambil, masing-masing, namun operasi ini akan mengembalikan
cocok dengan entri jika ada; jika tidak, mereka akan kembali nol.
• Tidak Operasi ify menggunakan Jini acara didistribusikan pemberitahuan, disebutkan dalam Bagian
6.3 untuk mendaftarkan minat pada acara tertentu - dalam kasus ini, kedatangan entri pencocokan template yang diberikan. pendaftaran ini diatur oleh sewa, yaitu,length waktu pendaftaran harus bertahan dalam JavaSpace. Pemberitahuan adalah melalui antarmuka RemoteEventListener ditentukan. Sekali lagi, operasi ini dapat dilakukan dalam konteks transaksi tertentu. Seperti disebutkan seluruh pembahasan di atas, operasi di JavaSpaces dapat berlangsung dalam konteks transaksi, memastikan bahwa baik semua atau tidak ada operasi akan dieksekusi. Transaksi didistribusikan entitas dan dapat span beberapa JavaSpaces dan beberapa proses yang berpartisipasi. Diskusi konsep umum transaksi adalah ditangguhkan sampai Bab 16. Contoh sederhana: Kami menyimpulkan penelitian dari JavaSpaces dengan menghadirkan Misalnya, contoh alarm kebakaran cerdas pertama kali diperkenalkan dalam Bagian 6.2.3 dan ditinjau kembali dalam Bagian 6.4.3. Dalam contoh ini, ada perlu menyebarkan pesan darurat untuk semua penerima ketika peristiwa kebakaran terdeteksi. Kita mulai dengan mendefinisikan sebuah objek masuknya Jenis AlarmTupleJS, seperti yang ditunjukkan pada Gambar6.24. Ini relatif mudah dan menunjukkan penciptaan entri baru dengan satu lapangan, alarmType. Kode alarm kebakaran yang terkait ditunjukkan pada Gambar 6.25 langkah dalam meningkatkan alarm untuk mendapatkan akses ke yang sesuai Misalnya dari JavaSpace (disebut "AlarmSpace"), yang kita asumsikan sudah dibuat. Sebagian besar implementasi dari JavaSpaces menyediakan fungsi utilitas untuk ini dan, untuk kesederhanaan, ini adalah apa yang kami tampilkan di kode ini, menggunakan SpaceAccessor kelas utilitas dan metode findSpace sebagaimana diatur dalam GigaSpaces (untuk kenyamanan, salinan kelas ini disediakan di situs web pendamping untuk buku [www.cdk5.net]). Entri ini kemudian dibuat sebagai turunan dari sebelumnyadidefinisikan AlarmTupleJS. Catatan ini hanya memiliki satu bidang, string disebut alarmType, dan ini Pertama diatur ke "Api!" ". Akhirnya, entri ini ditempatkan ke dalam JavaSpace menggunakan metode menulis, di mana ia akan tetap selama satu jam. Kode ini kemudian dapat disebut menggunakan berikut: FireAlarmJS alarm = FireAlarmJS baru (); alarm.raise ();
Akses ke JavaSpace tepat diperoleh dengan cara yang sama. Berikut ini, template adalah dibuat, bidang tunggal diatur ke "Api!", dan metode membaca terkait dipanggil. Catatan bahwa dengan menetapkan lapangan untuk "Api!", kami memastikan bahwa hanya entri dengan jenis dan thisvalue akan dikembalikan (meninggalkan bidang kosong akan membuat masuknya jenis AlarmTupleJS pertandingan valid). Hal ini disebut sebagai berikut di konsumen: Yang sesuai kode untuk konsumen akhir ditunjukkan pada Gambar 6.26 FireAlarmConsumerJS alarmCall = FireAlarmConsumerJS baru ();
String msg = alarmCall.await ();
System.out.println ( "Alarm diterima:" + msg);
Contoh sederhana ini menggambarkan betapa mudahnya untuk menulis aplikasi multi menggunakan
JavaSpaces yang baik waktu dan ruang-uncoupled.
6.6 Ringkasan
Bab ini telah diperiksa komunikasi tidak langsung secara detail, melengkapi penelitian paradigma remote doa dalam bab sebelumnya. Kami mendefinisikan langsung komunikasi dalam hal komunikasi melalui perantara, dengan resultan a uncoupling antara produsen dan konsumen pesan. Hal ini menyebabkan menarik properti, khususnya dalam hal berurusan dengan perubahan dan membangun toleransi kegagalan strategi.
Kami telah mempertimbangkan lima gaya komunikasi tidak langsung dalam bab ini:
komunikasi kelompok;
mempublikasikan-berlangganan sistem;
antrian pesan;
didistribusikan memori bersama;
ruang tupel.
Diskusi telah menekankan kesamaan mereka dalam hal semua pendukung tidak langsung komunikasi melalui bentuk perantara termasuk kelompok, saluran atau topik, antrian, memori bersama atau tuple ruang. Konten berbasis mempublikasikan-berlangganan sistem berkomunikasi melalui sistem mempublikasikan-berlangganan secara keseluruhan, dengan langganan efektif mendefinisikan logical channel dikelola oleh routing yang berbasis konten. Serta berfokus pada kesamaan, itu adalah pelajaran untuk mempertimbangkan kunci perbedaan antara berbagai pendekatan. Kita mulai dengan mempertimbangkan tingkat ruang dan waktu uncoupling, memilih di diskusi dalam Bagian 6.1. Semua teknik dipertimbangkan dalam ruang pameran bab ini uncoupling dalam pesan diarahkan ke
perantara dan tidak setiap penerima atau penerima tertentu. Posisi sehubungan dengan Waktu uncoupling lebih halus dan tergantung pada tingkat persistensi di paradigma. Pesan antrian, didistribusikan memori bersama dan tuple ruang sepanjang waktu pameran
uncoupling. Paradigma lain mungkin, tergantung pada pelaksanaannya. Sebagai contoh, dalam komunikasi kelompok, mungkin dalam beberapa implementasi untuk penerima untuk bergabung dengan kelompok di sembarang titik dalam waktu dan untuk dibawa up-to-date sehubungan dengan sebelumnya pertukaran pesan (ini merupakan fitur opsional di JGroups, misalnya, dipilih oleh
membangun sebuah stack protokol yang sesuai). Banyak sistem mempublikasikan-berlangganan tidak
dukungan persistensi peristiwa dan karenanya tidak waktu-uncoupled, tetapi ada pengecualian. JMS, misalnya, tidak mendukung acara terus-menerus, sesuai dengan yang integrasi mempublikasikan-berlangganan dan pesan antrian.
Pengamatan berikutnya adalah bahwa awal tiga teknik (kelompok, mempublikasikan-berlangganan
dan antrian pesan) menawarkan model pemrograman yang menekankan komunikasi (Melalui pesan atau peristiwa), sedangkan didistribusikan memori bersama dan tuple ruang menawarkan lebih berbasis negara abstraksi. Ini adalah perbedaan mendasar dan salah satu yang memiliki dampak yang signifikan dalam hal skalabilitas; secara umum, komunikasi berbasis abstraksi memiliki potensi untuk skala untuk
sangat skala besar sistem dengan sesuai rute infrastruktur (meskipun ini aku s tidak itu kasus untuk kelompok komunikasi karena dari kebutuhan untuk mempertahankan keanggotaan kelompok, seperti yang dibahas dalam Bagian 6.2.2).Di kontras, dua Pendekatan berbasis negara memiliki keterbatasan
dengan sehubungan dengan scaling. Ini batang dari kebutuhan untuk mempertahankan tampilan yang konsisten dari negara bersama, sebagai contoh antara kelipatan pembaca dan penulis shared ingatan. Situasi dengan spasi tuple adalah sedikit lebih halus mengingat sifat kekal dari tupel. Masalah utama terletak pada melaksanakan operasi membaca destruktif, mengambil, dalam sistem skala besar; ini adalah sebuah pengamatan yang menarik bahwa tanpa operasi ini, ruang tuple terlihat sangat banyak seperti mempublikasikan-berlangganan sistem (dan karenanya berpotensi sangat scalable). Sebagian besar sistem di atas juga menawarkan satu-ke-banyak gaya komunikasi, yang adalah, multicast dalam hal layanan komunikasi berbasis dan akses global untuk bersama nilai dalam abstraksi berbasis negara. The pengecualian pesan antrian, yang fundamental point-to-point (dan karenanya sering ditawarkan dalam kombinasi dengan publish- berlangganan sistem di middleware komersial), ruang tuple, yang dapat berupa satu-ke banyak atau point-to-point tergantung pada apakah menerima proses menggunakan membaca atau mengambil operasi, masing-masing. Ada juga perbedaan dalam maksud di berbagai sistem. komunikasi kelompok terutama dirancang untuk mendukung sistem terdistribusi dapat diandalkan, dan karenanya penekanannya pada memberikan dukungan algoritmik untuk keandalan dan pemesanan pengiriman pesan. Menariknya, algoritma untuk menjamin kehandalan dan pemesanan (terutama yang terakhir) dapat memiliki efek negatif yang signifikan pada skalabilitas untuk alasan yang sama untuk mempertahankan pandangan konsisten negara bersama. Mempublikasikan-berlangganan sistem sebagian besar telah ditargetkan di penyebaran informasi (misalnya, dalam sistem keuangan) dan untuk Enterprise Integrasi Aplikasi. Akhirnya, pendekatan memori bersama umumnya telah diterapkan dalam pemrosesan paralel dan terdistribusi, termasuk dalam komunitas Grid (Meskipun ruang tuple telah digunakan secara efektif di berbagai aplikasi domain). Kedua mempublikasikan-berlangganan sistem dan komunikasi ruang tuple telah ditemukan mendukung dalam komputasi mobile dan di mana-mana karena dukungan mereka untuk volatil lingkungan (seperti dibahas dalam Bab 19). Salah satu isu penting lainnya terkait dengan lima skema ini yang berbasis konten baik mempublikasikan-berlangganan dan ruang tuple menawarkan bentuk asosiatif pengalamatan berdasarkan konten, sehingga pencocokan pola antara langganan dan peristiwa atau template terhadap tupel, masing-masing. Pendekatan lain tidak. Diskusi ini diringkas dalam Gambar 6.27.
Kami belum dianggap masalah yang berkaitan dengan kualitas pelayanan dalam analisis ini. Banyak
sistem antrian pesan menawarkan dukungan intrinsik untuk keandalan dalam bentuk transaksi. Lebih umum, namun, kualitas layanan tetap menjadi tantangan utama bagi paradigma komunikasi tidak langsung. Memang, ruang dan waktu uncoupling oleh mereka sangat alam membuat sulit untuk alasan tentang sifat end-to-end dari sistem, seperti realtime perilaku atau keamanan, dan karenanya ini area penting untuk lebih lanjut penelitian.
No comments:
Post a Comment