BAB 13 SISTEM TERDISTRIBUSI BERBASIS KORDINASI

Dalam bab sebelumnya kita mengambil melihat pendekatan yang berbeda untuk sistem ter-distribusi, di setiap bab memfokuskan pada tipe data tunggal sebagai dasar untuk distribusi. Tipe data, yang baik obyek, file dokumen, atau (web), memiliki asalusul dalam sistem nondistributed. Hal ini disesuaikan untuk sistem terdistribusi sedemikian rupa sehingga banyak masalah tentang distribusi dapat dibuat transparan bagi pengguna dan pengembang. Dalam Bab ini kita mempertimbangkan generasi sistem terdistribusi yang menganggap bahwa berbagai komponen dari suatu sistem pada dasarnya terdistribusi dan bahwa masalah nyata dalam mengembangkan sistem seperti itu terletak pada koordinasi dan kegiatan yang berbeda kata lain components.In, bukan berkonsentrasi pada

transparandistribusi komponen, penekanan terletak pada koordinasi kegiatan antar komponen-komponen. Kita akan melihat bahwa beberapa aspek koordinasi telah menyentuh di dalam bab-bab sebelumnya, apalagi jika mengingat acara-sistem berbasis. Ternyata, banyak sistem terdistribusi konvensional secara bertahap menggabungkan mekanisme yang memainkan peran penting dalam koordinasi sistem berbasis.

13.1 PENDAHULUAN UNTUK MODEL KOORDINASI

Kunci untuk pendekatan diikuti dalam sistem koordinasi-berbasis pemisahan antara perhitungan bersih dan koordinasi. Jika kita melihat sistem terdistribusi sebagai koleksi (mungkin proses multithreaded, maka bagian komputasi dari sistem terdistribusi dibentuk oleh proses, masing-masing terkait dengan aktivitas komputasi spesifik, yang pada prinsipnya, dilakukan secara independen dari kegiatan lainnya proses.

Dalam model ini, bagian koordinasi sistem terdistribusi menangani komunikasi kerja sama antara proses. Membentuk perekat yang mengikat kegiatan yang dilakukan oleh proses menjadi keseluruhan (Gelernter dan Carriero, 1992). Dalam didistribusikan

koordinasi sistem berbasis, fokusnya adalah pada bagaimana koordinasi antara proses berlangsung. Cabri dkk. (2000) memberikan taksonomi model koordinasi untuk agen mobile yang dapat applled sama untuk jenis lain dari sistem terdistribusi. Beradaptasi terminologi untuk sistem terdistribusi pada umumnya, kami membuat perbedaan antara model bersama dua dimensi yang berbeda, temporal dan referensial, seperti ditunjukkan pada Gambar. 13-1.

Ketika proses yang temporal dan refentially digabungkan, koordinasi berlangsung dalam cara yang langsung, disebut sebagai koordinasi langsung. Kopling referensial umumnya muncul dalam bentuk referensi eksplisit pada komunikasi. Sebagai contoh, sebuah proses dapat berkomunikasi hanya jika ia tahu nama atau pengenal yang lain yang ingin bertukar informasi dengan. Kopling temporal berarti bahwa proses yang berkomunikasi akan baik harus bangun dan berjalan. Kopling ini analog dengan pesanberorientasi sementara komunikasi kita bahas pada Chapter.4. Sebuah berbagai jenis koordinasi terjadi ketika proses yang temporal dipisahkan, namun referentially digabungkan, yang kita sebut sebagai koordinasi kotak surat.Dalam kasus ini, tidak ada kebutuhan untuk dua proses berkomunikasi untuk mengeksekusi pada saat yang sama dalam rangka untuk membiarkan komunikasi berlangsung. Sebaliknya, komunikasi terjadi dengan meletakkan pesan dalam kotak surat (pssibly bersamasama). Situasi ini analog dengan gigih pesan komunikasi berorientasi seperti yang dijelaskan dalam Bab. 4. Hal ini dipertukarkan. Akibatnya, ada kopling referensial.

Kombinasi sistem referentialy dipisahkan dan temporal digabungkan membentuk kelompok model untuk memenuhi berorientasi koordinasi. Dalam sistem referentially dipisahkan, proses ini tidak mengenal satu sama lain secara eksplisit. Dengan kata lain, ketika sebuah proses ingin untuk mengkoordinasikan kegiatan dengan proses lainnya, tidak dapat langsung merujuk ke yang lain proceses. Sebaliknya, ada konsep sebuah pertemuan dimana processe sementara kelompok bersama-sama untuk mengkoordinasikan kegiatan mereka. Mode mengatur bahwa proses pertemuan mengeksekusi pada saat yang sama. Rapat-bassed sistem ini sering dilakukan dengan cara peristiwa, seperti yang didukung oleh objek berbasis didistribusikan systemsIn bab ini, kita membahas mekanisme lain untuk melaksanakan pertemuan. Yaitu mempublikasikan / subcribe sistem. Dalam sistem ini, proses dapat berlangganan pesan yang berisi informasi pada mata pelajaran tertentu, sementara proses lainnya menghasilkan (i, e.. Mempublikasikan) pesan tersebut. Kebanyakan mempublikasikan / berlangganan sistem mengharuskan proses berkomunikasi yang aktif pada saat yang sama: maka ada kopling temporal.Namun, proses komunikasi dinyatakan mungkin tetap Anonymouse. Model koordinasi yang paling banyak dikenal adalah kombinasi dari proses dipisahkan referentially dan temporal, dicontohkan oleh komunikasi generatif sebagaimana diperkenalkan dalam sistem pemrograman Linda oleh Gelermter (1985). Ide kunci dalam komunikasi generatif adalah bahwa kumpulan proses independen membuat penggunaan dataspace terus-menerus bersama tupel. Tupel ditandai catatan data yang terdiri dari sejumlah (tapi mungkin nol) bidang diketik. Proses dapat menempatkan setiap jenis catatan ke dataspace bersama (i, e.. Mereka menghasilkan catatan

komunikasi). Berbeda halnya dengan papan tulis, tidak perlu setuju dalam lanjutan pada struktur tupel. Hanya tag digunakan untuk membedakan antara tupel yang mewakili berbagai jenis informasi.

Sebuah fitur menarik dari Dataspaces bersama adalah bahwa mereka menerapkan mekanisme pencarian asosiatif untuk tupel. Dengan kata lain, ketika proses ingin mengekstrak sebuah tuple dari dataspace. Ini dasarnya menentukan (beberapa dari) nilai bidang itu tertarik Setiap tupel yang cocok spesifikasi yang kemudian dikeluarkan dari

dataspace dan diteruskan ke proses. Jika pertandingan tidak dapat ditemukan proses dapat memilih untuk memblokir sampai ada tupel yang cocok. Kami menunda rincian tentang model koordinasi untuk kemudian ketika membahas sistem beton. Kami mencatat bahwa komunikasi generatif dan dataspace bersama sering juga dianggap bentuk o fpublish / berlangganan sistem. Dalam apa yang berikut, kita akan mengadopsi persamaan ini juga. Sebuah gambaran yang baik dari mempublikasikan / berlangganan sistem (dan mengambil perspektif yang agak luas) dapat ditemukan di Eugster dkk. (2003). Dalam bab ini kita mengambil pendekatan bahwa dalam sistem ini setidaknya ada decoupling referensial antara proses, tetapi sebaiknya juga decoupling temporal.

13.2 Arsitektur

Sebuah aspek penting dari sistem koordinasi-berbasis bahwa komunikasi terjadi dengan menjelaskan karakteristik dari item data yang akan dipertukarkan. Akibatnya, penamaan memainkan peran penting. Kami kembali ke penamaan kemudian dalam bab ini, tapi untuk saat ini masalah penting adalah bahwa dalam banyak kasus, item data tidak secara eksplisit diidentifikasi oleh pengirim yang receievers.

13.2.1 Pendekatan Keseluruhan

Mari kita asumsikan bahwa item data dijelaskan oleh serangkaian atribut. Sebuah iems data dikatakan diterbitkan ketika dibuat tersedia bagi proses lain untuk membaca.Untuk itu, berlangganan perlu diteruskan ke middleware, yang berisi deskripsi biasanya terdiri dari beberapa (atttribute, nilai) pasangan, mungkin dikombinasikan dengan (atttribute, kisaran) pasangan. Dalam kasus kemudian, atribut tertentu diharapkan untuk mengambil nilai-nilai dalam kisaran tertentu. Deskripsi kadang bisa diberikan dengan menggunakan segala macam predikat dirumuskan atas atribut, sangat mirip di alam ke SQL seperti query dalam kasus database relasional. Kita akan menemukan jenis deskriptor kemudian dalam bab ini.

Kita sekarang dihadapkan dengan situasi di mana langganan harus dicocokkan item data, seperti ditunjukkan pada Gambar. 13-2. Ketika pencocokan berhasil, ada dua skenario yang mungkin. Dalam kasus pertama, middleware dapat memutuskan untuk meneruskan data yang diterbitkan untuk mengatur saat ini dari pelanggan, yaitu, proses dengan berlangganan cocok.Sebagai alternatif, middleware juga dapat mengajukan pemberitahuan titik mana pelanggan ca melaksanakan operasi membaca untuk mengambil item data yang diterbitkan.

Gambar 13-2 prinsip pertukaran data antara penerbit item dan pelanggan.

Dalam kasus-kasus di mana data item yang segera diteruskan ke pelanggan, middleware umumnya tidak akan menawarkan penyimpanan data. Penyimpanan adalah baik secara eksplisit ditangani oleh layanan yang terpisah, atau tanggung jawab pelanggan. Dengan kata lain, kami memiliki sistem referentially dipisahkan, tetapi temporal ditambah. Situasi ini berbeda ketika pemberitahuan dikirim sehingga pelanggan perlu secara eksplisit membaca data yang diterbitkan. Tentu, middleware akan memiliki untuk menyimpan item data. Dalam situasi ini ada operasi tambahan untuk pengelolaan data.Hal ini juga mungkin untuk melampirkan kontrak untuk item data tersebut bahwa ketika sewa berakhir bahwa item data secara otomatis delleted.

Dalam model yang digambarkan sejauh ini, kita telah mengasumsikan bahwa ada seperangkat tetap n atribut a1,. . . , Suatu yang digunakan untuk menggambarkan item data. Secara khusus, setiap item data yang dipublikasikan diasumsikan memiliki vektor terkait <(a1, v1 ),...,( sebuah, vn)> dari (atribut, nilai) pasang. Di banyak koordinasi-berbasis sistem, asumsi ini salah. Sebaliknya, apa yang terjadi adalah bahwa peristiwa yang diterbitkan, yang dapat dipandang sebagai item data hanya dengan atribut tertentu tunggal. Acara menyulitkan pengolahan langganan. Untuk mengilustrasikan, pertimbangkan berlangganan seperti "memberitahu ketika ruang R4.20 yang kosong dan pintu tidak terkunci." Biasanya, sebuah sistem terdistribusi mendukung seperti langganan taksi dilaksanakan dengan menempatkan sensor pemantauan independen untuk hunian kamar (misalnya, sensor gerak) dan orang-orang untuk mendaftarkan status sebuah kunci pintu. Mengikuti pendekatan sketsa sejauh ini, kita perlu menulis peristiwa primitif tersebut menjadi data item diterbitkan yang kemudian dapat berlangganan proses. Komposisi acara ternyata menjadi tugas yang sulit, terutama ketika peristiwa primitif yang dihasilkan dari sumber tersebar di seluruh sistem terdistribusi. Jelas, dalam sistem koordinasi-berbasis seperti ini. Isu penting adalah implementasi yang efisien dan terukur yang cocok langganan untuk item data, bersama dengan pembangunan dari item data yang relevan. Dari sisi luar, pendekatan koordinasi menyediakan banyak potensi untuk membangun sangat besar-besaran sistem terdistribusi karena decoupling kuat proses. Di sisi lain, sebagaimana akan kita se berikutnya, merancang implementasi terukur tanpa kehilangan kemerdekaan ini bukan axercise sepele.

13.2.2 Arsitektur Tradisional

Solusi yang paling sederhana untuk pencocokan item data terhadap langganan adalah memiliki arsitektur client-server terpusat. Ini adalah solusi yang khas saat ini diadopsi oleh banyak mempublikasikan / berlangganan sistem. Termasuk IBM WebSphere (IBM, 2005c) dan implementasi populer untuk Sun JMS (Sun Microsystems 2004a). Demikian pula, implementasi untuk model yang lebih rumit komunikasi generatif seperti Jini (Sun Microsystems, 2005b) dan JavaSpaces (Freeman dkk,. 1999) yang sebagian besar didasarkan pada server pusat. Mari kita lihat dua contoh khas.

Contoh: Jini dan JavaSpaces

Jini adalah sistem terdistribusi yang terdiri dari campuran elemen yang berbeda tetapi terkait. Hal ini sangat terkait dengan bahasa pemrograman Java, meskipun banyak prinsip yang dapat diterapkan sama baiknya dalam bahasa lain. Suatu bagian penting dari sistem dibentuk oleh model model koordinasi untuk komunikasi generatif. Jini Menyediakan decoupling temporal dan referensial proses melalui sistem koordinasi yang disebut JavaSpaces (Freeman dkk., 1999), berasal dari Linda. JavaSpace adalah dataspace bersama yang menyimpan tupel mewakili satu set diketik refereces ke obyek Jawa. Beberapa javaSpaces dapat hidup berdampingan dalam sistem Jini tunggal. Tuple disimpan dalam bentuk serial. Dengan kata lain, setiap kali sebuah proses ingin menyimpan sebuah tuple, tupel yang pertama mengerahkan, menyiratkan bahwa semua field yang mengerahkan juga. Akibatnya, ketika sebuah tuple berisi dua bidang yang berbeda yang merujuk ke objek yang sama. Para tuple sebagai disimpan dalam implementasi JavaSpace akan terus mengerahkan dua salinan objek itu.

Tupel adalah dimasukkan ke dalam JavaSpace dengan cara menulis operasi, yang pertama marsekal tupel sebelum menyimpannya. Setiap kali menulis operasi disebut pada sebuah tuple, salinan lain mengerahkan tupel yang disimpan dalam JavaSpace, seperti ditunjukkan pada Gambar. 13-3. Kita akan menyebut setiap salinan mengerahkan sebagai contoh tupel.

Gambar 13-3 Organisasi umum JavaSpace di Jini

Yang menarik dari komunikasi sdpect generatif dalam Jini adalah cara bahwa kasus tupel dibaca dari sebuah JavaSpace. Untuk membaca contoh tupel, proses memberikan tupel lain yang menggunakan sebagai template untuk pencocokan contoh tuple sebagai disimpan dalam sebuah JavaSpace. Seperti tupel lain, tupel template satu set referensi jenis objek. Contoh tupel Hanya dari jenis yang sama sebagai template dapat dibaca dari JavaSpace, A lapangan di tupel template yang baik berisi referensi ke objek yang sebenarnya atau berisi nilai NULL. Sebagai contoh, perhatikan kelas

Class public Tuple implements Entry { Public Integer id, value; Public Tuple(Integer id, Integer value){this.id = id; this.value = value} }

Then a template declared as

Tuple template =new Tuple(null, new Integer(42)) Will match the tuple Tuple item = new Tuple(MyName, new Integer(42))

Untuk pertandingan misalnya tuple dalam aJavaSpace againsr tupel template, nantinya sudah mengerahkan seperti biasa, termasuk bidang NULL nya. Untuk setiap contoh tupel dari jenis yang sama sebagai template, sebuah perbandingan dengan lapangan-lapangan dibuat dengan tupel template. Dua bidang cocok jika mereka berdua memiliki acopy dari referensi yang sama atau jika lapangan di tupel template NULL. Sebuah contoh tupel template yang cocok dengan tupel jika ada jika cocok berpasangan bidang masing-masing. Ketika contoh tupel ditemukan yang cocok dengan template yang memberikan tupel sebagai bagian dari operasi baca. Itu misalnya tuple unmarshaled dan kembali ke proses membaca. Ada juga sebuah operasi mengambil tambahan operasi menghilangkan blok contoh tupel dari JavaSpace cocok

tersebut. Kedua

pemanggil

sampai

tupel

yang

ditemukan. Hal ini dimungkinkan untuk menentukan waktu memblokir maksimal. Selain itu, ada varian yang hanya kembali segera jika tidak ada tupel yang cocok ada. Proses yang menggunakan JavaSpaces tidak perlu hidup berdampingan pada waktu yang sama. Bahkan, jika JavaSpace adalah diimplementasikan

menggunakan persistent storage, sistem Jini lengkap dapat diturunkan dan kemudian restart tanpa kehilangan tupel. Meskipun Jini tidak mendukung itu. Harus jelas bahwa memiliki server pusat memungkinkan subcriptions menjadi cukup rumit. Sebagai contoh, pada saat dua pertandingan itu nonnull bidang mereka adalah identik. Namun, menyadari bahwa bidang masing-masing mewakili sebuah objek. Pencocokan juga bisa dievaluasi dengan mengeksekusi operator perbandingan objek khusus [se juga Picco dkk.(2005)]. Bahkan, jika seperti operator dapat diganti oleh aplikasi. lebih-atau-kurang semantik perbandingan sewenang-wenang dapat diimplementasikan. Hal ini penting untuk tidak bahwa perbandingan tersebut mungkin memerlukan sebuah pencarian ekstensif melalui item data yang tersimpan saat ini. Pencarian tersebut tidak dapat dengan mudah efisien diterapkan dalam cara didistribusikan. Hal ini persis untuk alasan ini bahwa ketika aturan pencocokan rumit didukung kita umumnya hanya akan melihat implementasi terpusat. Keuntungan lain dari memiliki implementasi terpusat adalah bahwa hal itu menjadi lebih mudah untuk menerapkan sinkronisasi primitif. Misalnya, fakta bahwa suatu proses dapat memblokir sampai item data yang sesuai diterbitkan. Dan kemudian selanjutnya mengeksekusi membaca destruktif dimana tupel pencocokan dihapus. Menawarkan fasilitas untuk sinkronisasi proses tanpa proses perlu saling mengenal. Sekali lagi, sinkronisasi dalam sistem desentralisasi inheren sulit karena kami juga dibahas dalam Bab 6. Kami akan kembali untuk sinkronisasi di bawah ini.

Contoh: TIB / Rendezvous

Sebuah solusi alternatif untuk menggunakan server pusat untuk segera menyebarkan item data yang diterbitkan ke pelanggan yang tepat dengan

menggunakan multicasting.Prinsip ini digunakan dalam TIB / Rendezvous, yang arsitektur dasar ditunjukkan dalam Gambar 13-4 (TIBCO. 2005) Dalam item data approach.a adalah pesan ditandai dengan kata kunci yang menjelaskan konten senyawa, seperti news.comp. os.books.Sebagai pelanggan menyediakan (bagian dari) kata kunci, atau menunjukkan pesan yang ingin menerima, seperti buku news.comp .*.. Kata kunci ini dikatakan untuk menunjukkan subjek pesan. Mendasar untuk pelaksanaannya adalah penggunaan penyiaran umum di lokal area jaringan, meskipun juga menggunakan fasilitas komunikasi yang lebih efisien bila memungkinkan.

Gambar 13- 4. Prinsip dari sistem mempublikasikan / berlangganan seperti yang diterapkan dalam TIB / Rendezvous.

Sebagai contoh, jika diketahui persis di mana pelanggan berada, pointto-point pesan umumnya akan digunakan. Setiap host pada jaringan tersebut akan menjalankan daemon pertemuan, yang mengurus bahwa pesan yang dikirim dan dikirim sesuai dengan subjek mereka. Setiap kali sebuah pesan diterbitkan. Ini adalah multicast untuk setiap host pada jaringan menjalankan daemon pertemuan. Biasanya, multicasting diimplementasikan menggunakan

fasilitas yang ditawarkan oleh jaringan yang mendasari, seperti multicasting IP atau penyiaran perangkat keras.

Proses yang berlangganan subjek lulus langganan mereka untuk daemon lokal mereka.Daemon membangun sebuah tabel (proses, subjek), entri dan setiap kali pesan tiba pada subjek S, daemon hanya memeriksa dalam tabel untuk pelanggan lokal, dan meneruskan pesan ke masing-masing. Jika tidak ada pelanggan untuk S, pesan tersebut akan dibuang segera. Bila menggunakan multicasting seperti yang dilakukan di TIB / Rendezvous, tidak ada alasan mengapa subcriptions tidak dapat rumit dan lebih dari perbandingan string seperti saat ini terjadi. Pengamatan penting di sini adalah bahwa karena pesan akan diteruskan ke setiap node pula, pencocokan berpotensi kompleks data yang diterbitkan terhadap langganan dapat dilakukan sepenuhnya secara lokal tanpa komunikasi jaringan lebih lanjut. Namun, seperti
yang akan kita bicarakan kemudian, aturan perbandingan sederhana yang diperlukan setiap kali pencocokan seluruh jaringan yang luas diperlukan.

13.2.3 Peer-to-peer Arsitektur

Arsitektur tradisional diikuti oleh kebanyakan sistem koordinasi-berbasis menderita masalah skalabilitas (meskipun vendor komersial mereka akan menyatakan otherwhise) Jelas,. Memiliki server pusat untuk pencocokan langganan data yang dipublikasikan tidak dapat skala melampaui beberapa ratus clients.Likewise,

menggunakan multicasting membutuhkan khusus langkah-langkah untuk melampaui ranah lokal area networks.Moreover, jika skalabilitas harus dijamin, pembatasan lebih lanjut mengenai langganan menggambarkan dan item data mungkin diperlukan. Banyak penelitian telah dihabiskan untuk mewujudkan koordinasi sistem berbasis menggunakan peer-to-peer keluar technology.Straightforward implementasi bagi kasus di

mana kata kunci yang digunakan, karena ini dapat hash untuk pengidentifikasi unik untuk pendekatan data.This diterbitkan juga telah digunakan untuk pemetaan (atribut, nilai) pasang untuk identifiers.In kasus ini, cocok untuk mengurangi lookup langsung dari indentifier, yang dapat effienciently diimplementasikan dalam pendekatan system.This DHT berbasis bekerja dengan baik untuk lebih konvensional mempublikasikan / berlangganan sistem seperti yang digambarkan oleh Tam dan Jacobsen (2003), tetapi juga untuk komunikasi generatif (Bustet al., 2004) Hal-hal menjadi rumit untuk lebih diuraikan pencocokan schemes.Notoriusly sulit adalah kasus di mana rentang perlu didukung dan hanya sangat sedikit usulan exist.In following.we mendiskusikan satu proposal tersebut, dirancang oleh salah satu penulis dan rekan-rekannya (Voulgaris et al, 2006).

Contoh : Sebuah Gossip Berbasis Publish / Subscribe Sistem

Pertimbangkan sebuah sistem mempublikasikan / berlangganan di mana data dapat dijelaskan oleh item berarti N atribut a1 aN yang nilainya bisa langsung dipetakan ke contoh floating-point nilai include.for number.such, ...... mengapung, bilangan bulat, enumerations , boolean, dan string. Sebuah subcription s mengambil bentuk tupel (atribut, nilai / rentang) pairs.such sebagai

s = <a1 -> 3.0. a4 -> [0,0. 0,5)>

Dalam exaple ini, s menetapkan bahwa a1 harus sama dengan 3,0 dan a4 harus terletak pada interval [0.0,0.5) atribut lain diperbolehkan untuk mengambil pada setiap kejelasan value.For., Menganggap bahwa setiap node hanya saya memasuki s1 berlangganan. Perhatikan bahwa setiap s1 berlangganan sebenarnya menetapkan sebuah int subset S1 ruang dimensi N floating-point numbers.Such subset juga disebut hyperspace.For sistem secara awhole, hanya data yang dipublikasikan yang deskripsi jatuh di S serikat = Osi ini hyperspaces adalah seluruh ide interest.the adalah untuk secara otomatis partisi S ke M menguraikan hyperspaces S1 ...... SM seperti bahwa setiap jatuh

sepenuhnya dalam salah satu hyperspaces berlangganan S1 dan bersama-sama mereka ciover subscriptions.More semua formallly, kita mendapati bahwa

(Sm

Si) => (Sm si C)

Terlebih lagi, sistem terus M minimal dalam arti bahwa ada tidak dalam partitiening dengan bagian-bagian yang lebih sedikit Sm. Seluruh ide untuk mendaftar, untuk setiap Sm hyperspace persis mereka node i yang Sm C S1.In bahwa kasus ketika item daa diterbitkan , sistem hanya butuh menemukan Sm yang item yang belongs.from mana titik itu dapat meneruskan item ke node yang terkait. Untuk tujuan ini, node pertukaran langganan teratur menggunakan epidemi protocol.If dua node i dan j masing-masing melihat bahwa langganan intersect.that adalah Sij Si O Sj mereka akan merekam fakta ini dan terus refrences untuk setiap other.If Sk O, tiga dari mereka akan

mereka temukan k simpul ketiga dengan Sijk - Sij

menghubungkan satu sama lain sehingga item data d dari Sijk dapat efisien disseminated.Note bahwa jika Sij - Sijk O, node i dan j milik kelompok yang sama jika dan hanya jika langganan mereka Si dan Sj intersect.Moreover, node dalam kelompok yang sama harus diatur dalam suatu jaringan overlay yang akan memungkinkan efisien penyebaran item data dalam hyperscape associatted dengan situasi group. ini untuk satu atribut adalah Sketsa pada Gambar 13-5.

Gambar 13-5. Pengelompokan node untuk mendukung berbagai query secara peer-topermempublikasikan / berlangganan sistem.

Di sini, kita melihat total tujuh node di mana garis horizontal untuk node i indiscates jangkauan jika bunga cemara nilai attribute.Also sibgle ditampilkan adalah pengelompokan node ke dalam rentang menguraikan kepentingan untuk nilai dari contoh attributte.For , NPDES 3,4,7 dan 10 akan dikelompokkan bersama-sama mewakili interval [16.5,21.0] Setiap item data dengan nilai dalam rentang ini harus disebarluaskan hanya empat node.. Untuk contruct kelompok ini, node diorganisir ke dalam gosip simpul network.Each terstruktur berbasis menyimpan daftar referensi untuk tetangga lainnya (yaitu, pandangan parsial), yang periodacally pertukaran dengan salah satu tetangganya seperti yang dijelaskan dalam Chap.2. seperti pertukaran akan memungkinkan sebuah node node lain belajar tentang acak di node system.Every melacak node ia menemukan dengan interes yang tumpang tindih (yaitu, dengan berlangganan berpotongan).

Pada saat tertentu, setiap node saya umumnya akan memiliki referensi ke node lain dengan tumpang tindih bagian interest.As bertukar informasi dengan simpul j, node i perintah node ini dengan pengidentifikasi mereka dan memilih satu dengan pengidentifikasi terendah i |> j, seperti bahwa perusahaan langganan tumpang tindih dengan node j, yaitu, Sj.i Si Sj O.

Yang berikutnya yang akan dipilih adalah i2> i4 seperti yang langganan perusahaan juga tumpang tindih dengan yang j, tetapi hanya jika mengandung unsurunsur yang belum tercakup oleh kata simpul i4.In lain, kita harus memiliki Sj.i4.i2 (Si2 - Sj2i4) 0.This Sj proses diulang sampai semua node yang telah tumpang tindih

kepentingan dengan simpul saya telah diperiksa, menyebabkan ordered list i4 <i2 <....< in.Note bahwa ik node dalam daftar ini karena mencakup daerah R kepentingan umum untuk simpul i dan j yang belum tercakup oleh node joinyly dengan pengenal yang lebih rendah daripada ik, Akibatnya, simpul ik adalah node pertama yang harus maju simpul j item data yang jatuh dalam hal ini yang unik R. wilayah Prosedur ini dapat diperluas untuk membiarkan node i contruct sebuah ring.Such dua arah cincin juga ditampilkan dalam Fig.13-5. Setiap kali butir a d data dipublikasikan, disebarluaskan secepat mungkin untuk setiap modus yang tertarik it.As ternyata out.with informasi avaible di setiap node

menemukan node i tertarik it.As ternyata out.with yang avaible hanya maju d sepanjang cincin pelanggan untuk rentang tertentu yang d jatuh into.To mempercepat diseminasi, potongan pendek dipertahankan untuk cincin setiap well.Details dapat ditemukan di Voulgaris et al. (2006) informasi.

Diskusi

Sebuah pendekatan yang agak mirip dengan ini solusi berbasis gosip dalam arti bahwa ia mencoba untuk menemukan partisi ruang tertutup oleh nilai-nilai atribut, tetapi yang menggunakan s DHT berbasis sistem dijelaskan dalam Gupta et al. (2004).Dalam proposal lain yang dijelaskan dalam Bharambe (2004), masing-masing atribut a1 genggam oleh P1 proses yang terpisah, yang mengubah partisi kisaran attributte di seluruh processes.When mutiple item data d dipublikasikan, forrwarde ke P1 masingmasing, di mana selanjutnya disimpan di proses yang bertanggung jawab untuk nilai d 's a1. Semua pendekatan ini ilustrasi untuk kompleksitas saat memetakan sistem mempublikasikan / berlangganan montrivial untuk peer-to-peer esensi network.In, kompleksitas ini berasal dari fakta bahwa mendukung pencarian di attributte sistem berbasis penamaan inheretly sulit untuk membangun dalam desentralisasi fashion.We lagi akan menemukan kesulitan-kesulitan ketika membahas replikasi.

13.2.4 Mobilitas dan Koordinasi

Sebuah topik yang telah menerima banyak perhatian dalam literatur adalah bagaimana menggabungkan mempublikasikan / berlangganan solusi dengan kasus mobility.In banyak simpul, diasumsikan bahwa ada infrastruktur dasar tetap dengan poin acces untuk nodes.Under ponsel asumsi ini, masalah ini menjadi bagaimana memastikan bahwa pesan-pesan yang diterbitkan tidak disampaikan lebih dari sekali untuk seorang pelanggan yang switch solusi akses points.One pratical untuk masalah ini adalah untuk membiarkan pelanggan melacak pesan-pesan mereka telah menerima dan membuang simpliy duplicates.Alternative, namun solusi yang lebih rumit terdiri dari router yang

melacak pesan mana yang telah dikirim ke mana pelanggan (lihat, misalnya, Caporusicio dkk .. 2003).

Contoh: Lime

Dalam kasus komunikasi generatif, beberapa solusi telah diusulkan untuk mengoperasikan dataspace bersama di mana (somef dari) node mobile. Sebuah contoh canonial dalam hal ini adalah Kapur (Murphy et al .., 2001), yang stringly menyerupai model JavaSpace kita bicarakan sebelumnya.

Dalam Lime, setiap proses memiliki dataspace sendiri terkait, tapi ketika proses dalam setiap kedekatan lain seperti yang mereka terhubung, dataspace mereka menjadi shared.Theroretically, yang terhubung dapat berarti bahwa ada rute dalam jaringan yang mendasari sendi yang memungkinkan dua proses untuk pertukaran data.Dalam prakteknya, jaringan yang mendasari sendi yang memungkinkan dua proses untuk berlatih data.In pertukaran, bagaimanapun, baik berarti bahwa dua proses sementara terletak pada host fisik yang sama, atau masing-masing host dapat berkomunikasi satu sama lain melalui (hop tunggal) wirelles link. Secara formal, proses harus menjadi anggota dari protokol comunication kelompok yang sama.

Gambar 13-6. transien berbagi ruangdata lokal di Lime

Para Dataspaces lokal proses terhubung membentuk Dataspaces transiently bersama yang akan memungkinkan proses untuk tupel pertukaran, seperti yang ditunjukkan pada Gambar. 13-6. Misalnya, ketika proses mengeksekusi P operasi menulis, tupel yang terkait disimpan dalam dataspace lokal proses itu. Pada prinsipnya, itu tetap ada sampai ada operasi mengambil yang cocok, mungkin dari proses lain yang sekarang dalam kelompok yang sama dengan P. Dalam cara ini, kenyataan bahwa kita sebenarnya berurusan dengan dataspace bersama sepenuhnya terdistribusi adalah transparan untuk berpartisipasi prosess . Namun, Kapur juga memungkinkan melanggar transparansi ini dengan menentukan tepatnya untuk siapa sebuah tuple dimaksudkan. Demikian juga, membaca dan mengambil operasi dapat memiliki parameter tambahan dari proses yang menentukan sebuah tuple diharapkan. Untuk lebih mengontrol bagaimana tupel didistribusikan, Dataspaces dapat melakukan yang dikenal sebagai reaksi. Reaksi yang menentukan tindakan yang akan dieksekusi wheb tupel pencocokan template yang diberikan ditemukan di Dataspaces lokal.Setiap kali perubahan dataspace, sebuah reaksi executeable dipilih secara acak, sering mengarah ke modifikasi lebih lanjut dari Dataspaces. Reaksi rentang bahwa mereka dapat dijalankan secara efisien. Misalnya, dalam kasus reaksi yang lemah, hanya dijamin bahwa tindakan yang terkait yang akhirnya dieksekusi, asalkan pencocokan data masih dapat diakses. Ide reaksi telah diambil langkah lebih lanjut dalam tota. Mana tupel eacch memiliki sebuah fragmen kode yang terkait mengatakan persis bagaimana tupel yang harus dipindahkan antara Dataspaces, possibily juga termasuk tranformations (Mamei dan Zambonelli, 2004).

13.3 PROSES

Tidak ada yang

benar-benar spesial tentang proses yang digunakan dalam

mempublikasikan / berlangganan sistem. Dalam kebanyakan kasus, mekanisme yang efisien perlu dikerahkan untuk mencari di koleksi berpotensi besar data. Masalah utama adalah merancang skema Thet bekerja dengan baik dalam lingkungan terdistribusi. Kita kembali ke masalah ini di bawah ini ketika membahas konsistensi dan replikasi.

13.4 KOMUNIKASI

Komunikasi dalam banyak mempublikasikan / berlangganan sistem relatif sederhana.Misalnya, di hampir setiap sistem berbasis java, semua komunikasi berlangsung melalui doa metode remote. Satu masalah imporrtant yang perlu ditangani ketika mempublikasikan / berlangganan sistem tersebar di seluruh sistem luas-adalah bahwa data yang dipublikasikan harus mencapai hanya pelanggan yang relevan. Seperti yang kita dijelaskan di atas, menggunakan metode mengorganisir diri dengan mana node dalam sistem peer-to-peer secara otomatis berkerumun, setelah penyebaran terjadi per cluster merupakan salah satu solusi. Sebuah solusi alternatif adalah untuk menyebarkan konten-based routing.

13.4.1 Content Berbasis Routing

Dalam konten berbasis routing, sistem ini diasumsikan akan dibangun di atas jaringan piont-ke-titik di mana pesan yang secara eksplisit diarahkan antara node. Penting dalam setup ini adalah bahwa router dapat mengambil keputusan routing dengan mempertimbangkan isi pesan. Lebih presicely, adalah diasumsikan bahwa pesan masingmasing membawa deskripsi isinya, dan bahwa deskripsi ini dapat digunakan untuk memotong-off rute yang diketahui bahwa mereka tidak menyebabkan penerima tertarik pada pesan itu. Pendekatan particial terhadap konten berbasis routing diusulkan dalam Carzaniga dkk, (2004). Pertimbangkan sebuah sistem mempublikasikan / subscibe consistong server N yang klien (i, e., aplikasi) dapat mengirim pesan, atau dari mana mereka dapat membaca pesan masuk. Kami berasumsi bahwa untuk membaca pesan, aplikasi akan memiliki sebelumnya diberikan server dengan deskripsi dari jenis data itu tertarik Server, pada gilirannya, akan memberitahukan aplikasi ketika data yang relevan telah tiba. Carzaniga dkk, mengusulkan skema dua lapis routing di mana lapisan terendah terdiri dari pohon siaran bersama menghubungkan server N. Ada berbagai cara untuk membuat seperti pohon, mulai dari jaringan-tingkat dukungan multicast untuk aplikasi-tingkat

pohon multicast seperti yang kita bahas dalam Bab. 4. Di sini, kita juga mengasumsikan bahwa seperti pohon telah dibentuk dengan server N sebagai node akhir, bersama dengan colletion node intermidiate membentuk router. Perhatikan bahwa perbedaan antara server dan router hanya satu logis: sebuah mesin tunggal dapat menjadi tuan rumah kedua macam proses. Pertimbangkan pertama dua ekstrem untuk konten berbasis routing, dengan asumsi kita perlu mendukung hanya sederhana subjek berbasis mempublikasikan / berlangganan di mana setiap pesan ditandai dengan kata kunci (noncompound) yang unik. Salah satu solusi ekstrim untuk mengirim setiap pesan diterbitkan untuk setiap server, dan kemudian membiarkan server memeriksa apakah setiap klien harus berlangganan ke subjek dari pesan tersebut. Pada dasarnya, ini adalah pendekatan yang diikuti dalam TIB / Rendezvous.

Gambar 13-7.Nave konten routing berbasis

Solusi ekstrim lainnya adalah untuk membiarkan server setiap siaran langganan untuk semua server lainnya. Akibatnya, setiap server akan dapat mengkompilasi sebuah daftar (subjek, tujuan) pasangan. Kemudian, setiap kali sebuah aplikasi menyampaikan pesan pada subjek s, server yang terkait yang menambahkan header server tujuan untuk pesan itu. Ketika pesan mencapai router, yang terakhir dapat menggunakan daftar untuk memutuskan jalur bahwa pesan harus mengikuti, seperti ditunjukkan pada Gambar. 13-7. Mengambil pendekatan terakhir sebagai titik awal kita, kita dapat memperbaiki

kemampuan router untuk memutuskan di mana untuk meneruskan pesan ke. Untuk itu, setiap server siaran berlangganan di seluruh jaringan sehingga router dapat membuat rute filter. Sebagai contoh, asumsikan bahwa simpul 3 pada Gambar. 13-7 berlangganan pesan yang atribut terletak dalam rentang [0,3], tapi itu simpul 4 ingin pesan dengan [2,5]. Dalam kasus ini, router R 2 akan membuat filter routing yang sebagai meja dengan sebuah entri untuk setiap link keluar (dalam hal ini tiga: satu untuk simpul 3, satu ke node 4, dan satu ke arah router R 1 ), seperti ditunjukkan pada Gambar. 13.8

Antarmuka Ke node 3 Ke node 4 Menuju router R 1 a

Filter [0,3]

a [2,5] (tidak ditentukan)

Gambar 13-8. Sebuah tabel routing terisi sebagian

Lebih menarik adalah apa yang terjadi pada router R 1. Dalam contoh ini, langganan dari node 3 dan 4 mendikte bahwa setiap pesan dengan berbaring dalam interval [0,3] [2,5] = [0,5] harus diteruskan sepanjang jalan ke router R 2, dan ini justru informasi bahwa R 1 akan menyimpan dalam tabel. Tidaklah sulit untuk membayangkan bahwa komposisi berlangganan lebih rumit dapat didukung. Ini contoh sederhana juga menggambarkan bahwa setiap kali sebuah node daun sistem, atau ketika tidak lagi tertarik pada pesan tertentu, harus membatalkan langganan dan pada dasarnya informasi ini disiarkan ke semua router. Pembatalan ini, pada gilirannya, dapat menyebabkan routing yang menyesuaikan berbagai filter.Penyesuaian akhir akan paling buruk menyebabkan lalu lintas yang tidak perlu sebagai pesan dapat diteruskan sepanjang jalur yang ada pelanggan tidak lagi. Namun demikian, penyesuaian tepat waktu dibutuhkan untuk menjaga kinerja pada tingkat yang dapat diterima. Salah satu masalah dengan konten berbasis routing bahwa meskipun prinsip filter routing yang menyusun sederhana, mengidentifikasi link sepanjang yang pesan yang masuk harus diteruskan dapat menghitung-intensif. Kompleksitas komputasi berasal dari

pelaksanaan pencocokan nilai atribut untuk langganan, yang pada dasarnya bermuara pada sebuah perbandingan entri-entri-oleh. Bagaimana perbandingan ini dapat dilakukan secara efisien dijelaskan dalam Carzaniga dkk. (2003).

13.4.2 Komposit Langganan Pendukung

Contoh-contoh sejauh bentuk ekstensi yang relatif sederhana untuk tabel routing.Ekstensi ini cukup ketika langganan mengambil bentuk vektor (atribut, nilai / range) pasangan. Namun, sering kali ada kebutuhan untuk ekspresi yang lebih canggih dari langganan. Sebagai contoh, mungkin akan mudah untuk mengungkapkan komposisi subcriptions di mana proses menentukan dalam langganan tunggal yang tertarik pada jenis yang sangat berbeda dari item data. Untuk menggambarkan, proses mungkin ingin melihat item data saham dari IBM dan data tentang pendapatan mereka, tetapi mengirimkan item data hanya satu jenis tidak berguna. Untuk menangani komposisi berlangganan, Li dan Jacobsen (2005) mengusulkan untuk merancang router analog dengan aturan database. Akibatnya, subcriptions diubah menjadi aturan menyatakan dalam kondisi diterbitkan data harus diteruskan, dan sepanjang yang link keluar. Tidaklah sulit untuk membayangkan bahwa hal ini dapat menyebabkan routing berbasis konten filter routing yang dijelaskan di atas. Mendukung komposisi berlangganan adalah sangat terkait dengan masalah penamaan dalam sistem koordinasi-berbasis, yang akan kita bahas berikutnya.

13.5 Penamaan Mari kita sekarang membayar perhatian lebih untuk penamaan dalam sistem koordinasi berbasis. Sejauh ini, kita sebagian besar telah diasumsikan bahwa setiap item data publisbed dengan predikat menentukan lebih dari nilai-nilai atribut. Secara umum, skema ini penamaan dapat segera diterapkan. Meskipun sistem berbeda sehubungan dengan tipe atribut, nilai, dan predikat yang dapat digunakan. Misalnya, dengan JavaSpaces kami melihat bahwa perbandingan pada dasarnya hanya untuk kesetaraan didukung. Meskipun hal ini dapat relatif mudah diperluas dalam

aplikasi-spesifik cara. Demikian juga, banyak komersial mempublikasikan / berlangganan sistem dukungan hanya agak primitif string operator perbandingan. Salah satu masalah yang kita telah disebutkan adalah bahwa dalam banyak kasus kita tidak dapat sumply menganggap bahwa setiap item data yang ditandai dengan nilainilai untuk semua atribut. Secara khusus, kita akan melihat bahwa item data yang hanya memiliki satu terkait (atribut, nilai) pasangan, dalam hal ini juga disebut sebagai sebuah event. Dukungan untuk berlangganan peristiwa. Dan peristiwa terutama komposit sebagian besar menentukan diskusi tentang isu penamaan dalam mempublikasikan / berlangganan sistem. Apa yang telah kita bahas sejauh harus consicered sebagai sarana yang lebih primitif untuk mendukung koordinasi dalam sistem terdistribusi. Kita sekarang alamat di acara lebih mendalam dan komposisi acara. Ketika berhadapan dengan peristiwa komposit. Kita perlu mengambil dua isu yang berbeda ke account. Yang pertama adalah untuk menggambarkan komposisi. Deskripsi tersebut membentuk dasar untuk langganan. Isu kedua adalah bagaimana mengumpulkan (primitif) peristiwa dan kemudian mencocokkan mereka untuk langganan. Pietzuch dkk. (2003) telah mengusulkan kerangka umum untuk komposisi acara di sistem terdistribusi. Kami mengambil kerangka kerja ini sebagai dasar untuk diskusi kita.

13.5.1 Menjelaskan Komposit Acara Mari kita pertama mempertimbangkan beberapa contoh peristiwa komposit untuk memberikan ide yang lebih baik dari kompleksitas yang kita mungkin perlu untuk menangani. Gambar 13-9 menunjukkan contoh kejadian komposit semakin kompleks. Dalam contoh ini, R4.20 bisa menjadi ruang komputer ber-AC dan aman.

Gambar 13-9

Dua yang pertama subcsriptions yang relaitively mudah. S1 adalah contoh yang dapat ditangani oleh sebuah kejadian diskrit primitif, sedangkan S2 adalah komposisi sederhana dari dua kejadian diskrit. S3 berlangganan adalah lebih kompleks karena membutuhkan bahwa sistem juga dapat melaporkan waktu-peristiwa terkait. Hal-hal yang lebih rumit jika melibatkan nilai-nilai dikumpulkan langganan diperlukan untuk gradien komputasi (S4) atau rata-rata (S5). Perhatikan bahwa dalam kasus S5 kita membutuhkan pemantauan terus menerus dari sistem dalam rangka untuk mengirim pemberitahuan pada waktunya. Ide dasar dibalik bahasa acara-komposisi untuk sistem terdistribusi adalah untuk memungkinkan perumusan langganan dalam hal kejadian primitif. Dalam kerangka kerja mereka, Pietzuch dkk. menyediakan bahasa yang relatif sederhana untuk jenis diperpanjang terbatas-negara mesin (FSM). Ekstensi memungkinkan untuk spesifikasi kali persinggahan di negara-negara, serta generasi baru (komposit) peristiwa. Rincian yang tepat dari bahasa mereka tidak penting untuk diskusi kita di sini. Yang penting adalah bahwa langganan dapat diterjemahkan ke dalam FSMs. Untuk memberikan contoh, Gambar. 13-10 menunjukkan FSM untuk S3 berlangganan dari Gambar. 13-9. Kasus khusus diberikan oleh negara waktunya, ditandai dengan label "t = 10s" yang menentukan bahwa transisi ke keadaan akhir dibuat jika pintu tidak terkunci dalam waktu 10 detik.

Gambar 13-10

Subxcriptions kompleks jauh lebih dapat dijelaskan. Sebuah aspek penting adalah bahwa FSMs sering dapat didekomposisi menjadi FSMs kecil yang berkomunikasi dengan melewatkan peristiwa satu sama lain. Perhatikan bahwa seperti aktivitas komunikasi biasanya akan memicu transisi negara di FSM yang acara yang dimaksudkan. Sebagai contoh, asumsikan bahwa kita ingin secara otomatis mematikan lampu di ruang R4.20 setelah 2 detik ketika kita yakin bahwa tidak ada ada lagi (dan pintu terkunci). Dalam hal ini, kita dapat menggunakan kembali FSM dari Gambar. 13-10 jika kita membiarkannya menghasilkan sebuah acara untuk FSM kedua yang akan memicu pencahayaan, seperti yang ditunjukkan pada Gambar. 13-11.

Gambar 13-11 Pengamatan penting di sini adalah bahwa kedua FSMs dapat diimplementasikan sebagai proses terpisah dalam sistem terdistribusi. Dalam hal ini, FSM untuk mengendalikan pencahayaan akan berlangganan ke acara terdiri yang dipicu ketika R4 20 adalah kosong dan pintu terkunci. Hal ini me-nyebabkan detektor terdistribusi yang akan kita bahas berikutnya.

13.5.2 Pencocokan Acara dan Langganan

Sekarang perhatikan mempublikasikan / berlangganan sistem pendukung acara komposit. Setiap langganan disediakan dalam bentuk ekspresi yang dapat diterjemahkan ke dalam mesin negara yang terbatas (FSM). Negara transisi yang pada dasarnya dipicu oleh peristiwa primitif yang terjadi, seperti meninggalkan ruangan atau mengunci pintu. Untuk pertandingan peristiwa dan langganan, kita dapat mengikuti implementasi, sederhana naif di mana setiap pelanggan menjalankan proses pelaksanaan mesin negara yang terbatas terkait dengan langganan nya. Dalam kasus itu, semua peristiwa primitif yang relevan untuk berlangganan tertentu akan harus diteruskan ke pelanggan. Jelas, ini umumnya tidak akan sangat efisien. Sebuah pendekatan yang lebih baik adalah dengan mempertimbangkan koleksi lengkap langganan, dan membusuk langganan ke negara berkomunikasi mesin yang terbatas, sehingga beberapa FSMs dibagi antara langganan yang berbeda. Contoh. Dari berbagi ini ditunjukkan pada Gambar. 13-11. Pendekatan terhadap langganan penanganan mengarah pada apa yang dikenal sebagai detektor acara didistribusikan. Perhatikan bahwa adistribution detektor acara serupa di alam untuk resolusi nama didistribusikan dalam sistem penamaan berbagai. Peristiwa primitif menyebabkan transisi negara di mesin terbatas relatif sederhana negara, pada gilirannya memicu generasi peristiwa komposit. Yang terakhir ini kemudian dapat menyebabkan transisi negara di FSMs lainnya, sekali lagi mungkin mengarah ke generasi acara lebih lanjut. Tentu saja, peristiwa menerjemahkan pesan yang dikirim melalui jaringan ke proses yang berlangganan kepada mereka. Selain mengoptimalkan melalui berbagi, mogok langganan ke FSMs berkomunikasi juga memiliki keunggulan potensi mengoptimalkan penggunaan jaringan. Pertimbangkan lagi peristiwa yang terkait dengan pemantauan ruang komputer. Seperti penempatan akan mencegah harus mengirim peristiwa primitif di seluruh jaringan. Terlebih lagi, ketika mempertimbangkan Gambar. 13-9, kita melihat bahwa kita mungkin hanya perlu perlu mengirim alarm ketika melihat bahwa ruangan tidak dihuni selama 10 detik saat pintu

dibuka. Peristiwa seperti umumnya akan jarang terjadi dibandingkan dengan, misalnya, (un) mengunci pintu. Membusuk langganan ke detektor acara didistribusikan, dan kemudian secara optimal menempatkan mereka di sebuah sistem terdistribusi adalah masih tunduk pada banyak penelitian. Sebagai contoh, kata terakhir pada bahasa berlangganan belum dikatakan, dan terutama trade-off antara ekspresi dan efisiensi implementasi akan menarik banyak perhatian. Dalam kebanyakan kasus, bahasa lebih ekspresif adalah, semakin tidak mungkin akan ada implementasi didistribusikan efisien. Saat ini usulan seperti dengan Demers dll al. (2006) dan oleh Liu dan Jacobsen (2004) menegaskan hal ini. Ini akan memakan beberapa tahun sebelum kita melihat teknik-teknik yang diterapkan untuk komersial mempublikasikan / berlangganan sistem.

13.5.3 Sinkronisasi Sinkronisasi koordinasi sistem berbasis umumnya dibatasi untuk mendukung sistem komunikasi generatif. Hal-hal yang relatif mudah ketika hanya server tunggal yang digunakan. Dalam hal ini, prosesses dapat hanya diblokir sampai tupel menjadi tersedia, tetapi juga mudah untuk menghapusnya. Hal-hal menjadi rumit ketika dataspace bersama direplikasi dan didistribusikan di beberapa server, seperti yang kita gambarkan berikutnya.

13.5.4 KONSISTENSI DAN REPLIKASI Replikasi memainkan peran kunci dalam skalabilitas koordinasi berbasis sistem, dan terutama mereka untuk komunikasi generatif. Dalam berikut, pertama kita mempertimbangkan beberapa pendekatan standar sebagaimana telah dieksplorasi di sejumlah sistem seperti JavaSpaces. Selanjutnya, kami menjelaskan beberapa hasil terakhir yang memungkinkan untuk penempatan dinamis dan otomatis tupel tergantung pada pola akses mereka. Contoh yang dikirim, mereka diperlakukan seperti lokal menulis dan contoh yang efektif dipindahkan dari mesin yang mereka yang melakukan permintaan. Bahkan sistem runtime bahkan dapat memindahkan tupel sekitar sendiri

untuk menyeimbangkan beban. Carrier dan Gelernter (1986) menggunakan metode ini untuk menerapkan ruang tupel Linda pada sebuah LAN. Kedua metode dapat dikombinasikan untuk menghasilkan sistem dengan replikasi parsial. Sebagai contoh sederhana, bayangkan bahwa semua mesin logis membentuk kotak persegi panjang, seperti yang ditunjukkan pada Gambar. 13-14. Ketika sebuah proses pada mesin A ingin melakukan menulis, siaran (atau mengirim oleh titik-to-point pesan) tupel untuk semua mesin di baris atas grid. Ketika aprocess pada mesin B ingin membaca atau mengambil contoh tupel, itu siaran tupel template untuk semua mesin di kolomnya. Karena geometri, akan selalu ada tepat satu mesin yang melihat kedua contoh tupel dan tupel template (C dalam contoh ini), dan mesin yang membuat pertandingan dan mengirim contoh tupel untuk proses meminta untuk itu. Pendekatan ini mirip dengan menggunakan kuorum berbasis replikasi seperti yang kita bahas dalam Bab. 7. Implementasi yang telah kita bahas sejauh ini memiliki masalah skalabilitas yang serius yang disebabkan oleh fakta bahwa multicasting diperlukan baik untuk menyisipkan sebuah tuple ke ruang tupel, atau menghapus satu. Wide-area implementasi ruang tupel tidak ada. Paling-paling, beberapa ruang tupel yang berbeda dapat hidup berdampingan dalam satu sistem, di mana setiap ruang tupel sendiri diimplementasikan pada server tunggal atau pada jaringan lokal-daerah. Pendekatan ini digunakan, misalnya, dalam PageSpaces (Ciancarini dkk., 1998) dan WCL (Rowstron dan Wray, 1998). Setiap server Tupel-ruang bertanggung jawab untuk seluruh ruang tupel. Dengan kata lain. Sebuah proses akan selalu diarahkan ke exaxtly satu server. Namun, adalah mungkin untuk bermigrasi ruang tupel ke server yang berbeda untuk meningkatkan kinerja. Bagaimana mengembangkan sebuah implementasi yang efisien wilayah luas ruang tupel masih merupakan pertanyaan terbuka.

13.7.2 replikasi dinamis

Replikasi dalam sistem berbasis koordinasi umumnya terbatas pada kebijakan statis untuk aplikasi paralel seperti yang dibahas di atas. Dalam aplikasi komersial, kami juga skema yang relatif sederhana di mana ruang data seluruh bagian dinyatakan statis standar data set tunduk pada kebijakan tunggal (gigaspaces, 2005). Terinspirasi oleh

replikasi fine-grained dari dokumen web di globul, peningkatan kinerja juga dapat dicapai saat replikasi membedakan antara berbagai jenis menyimpan data dalam sebuah ruang data. diferensiasi ini didukung oleh GSpace, yang kita bahas secara singkat dalam bagian ini. Gspace ikhtisar Gspace adalah sistem koordinasi berbasis terdistribusi yang dibangun di atas ruang java (rusello et al,. 2004,2006). Distribusi dan replikasi tupel dalam gspace dilakukan untuk dua alasan yang berbeda: meningkatkan kinerja dan ketersediaan. Sebuah elemen kunci dalam pendekatan ini adalah pemisahan keprihatinan: tupel yang perlu direplikasi untuk ketersediaan mungkin perlu mengikuti strategi yang berbeda daripada yang digunakan kinerja yang dipertaruhkan. Untuk alasan ini, arsitektur dari gspace telah dibentuk untuk mendukung berbagai kebijakan replikasi, dan seperti tupel yang berbeda dapat mengikuti kebijakan yang berbeda.

Applicatio n

Dataspaces slice

Distribution manager

Invocation handler

Policy table

Local OS

Figure 13-15. Internal Organization of a GSpace kernel

Kerja utama relatif sederhana, setiap aplikasi ditawarkan antar muka dengan membaca, menulis, dan mengambil antar muka, mirip dengan apa yang ditawarkan oleh ruang java. Namun, setiap panggilan dijemput oleh handler doa lokal yang mendongak kebijakan yang harus diikuti untuk panggilan tertentu. Kebijakan dipilih berdasarkan

jenis dan isi dari tupel / template yang dilewatkan sebagai bagian dari panggilan. Setiap kebijakan diidentifikasi dengan template, mirip dengan cara yang digunakan template untuk memilih tuple di lain Dataspaces berbagi berbasis java seperti yang kita diskusikan sebelumnya. Hasil seleksi ini adalah referensi ke manajer distribusi, yang

mengimplementasikan antarmuka yang sama, tapi sekarang bukan menurut kebijakan replikasi tertentu. Sebagai contoh, jika seorang master / slave kebijakan telah dilaksanakan, sebuah operasi baca dapat dilakukan dengan segera membaca sebuah tuple dari dataspace lokal yang tersedia. Demikian juga, menulis operasi mungkin mengharuskan pemain depan manajer distribusi update ke node master dan menunggu pengakuan sebelum melakukan operasi lokal. Akhirnya, setiap kernel gspace memiliki dataspace lokal, yang disebut slice, yang diimplementasikan sebagai versi, penuh nondistributed dari javaspaces.

Dalam arsitektur (yang beberapa komponen tidak ditampilkan untuk kejelasan), deskriptor kebijakan dapat ditambahkan pada saat runtime, dan juga, manajer distribusi dapat diubah juga. Pengaturan ini memungkinkan untuk tuning fine-grained dari distribusi dan replikasi tuple, dan seperti yang ditunjukkan dalam al et rusello. (2004), seperti fine-tuning memungkinkan untuk kinerja yang jauh lebih tinggi daripada yang dicapai dengan strategi, tetap global yang diterapkan untuk semua tupel dalam sebuah dataspace. Replikasi adaptif Namun, aspek yang paling penting dengan sistem seperti GSpaces adalah bahwa manajemen replikasi adalah otomatis, dengan kata lain, bukan membiarkan sosok pengembang aplikasi menebak kombinasi kebijakan mana yang terbaik, lebih baik

membiarkan sistem memonitor pola akses dan perilaku dan kemudian mengadopsi kebijakan-kebijakan yang diperlukan. Untuk tujuan ini, GSpace mengikuti pendekatan yang sama seperti di globul: secara berkesinambung mengukur latency bandwidth jaringan yang dikonsumsi, dan memori penggunaan dan tergantung pada metrik ini dianggap paling penting, tempat tupel pada node yang berbeda dan memilih cara yang paling tepat untuk menjaga replika konsisten. Evaluasi kebijakan adalah yang terbaik untuk sebuah tupel tertentu dilakukan

dengan cara koordinator pusat yang hanya mengumpulkan jejak dari node yang merupakan sistem GSpaces. Sebuah aspek yang menarik adalah bahwa dari waktu ke waktu kami mungkin perlu untuk beralih dari satu kebijakan replikasi yang lain. Ada beberapa cara yang seperti transisi yang dapat berlangsung. Sebagai gspace bertujuan untuk memisahkan mekanisme dari kebijakan sebaik mungkin, juga dapat menangani kebijakan transisi yang berbeda. Kasus umum untuk sementara membekukan semua usaha untuk jenis tertentu tuple, menghapus semua replika dan memasukkan kembali tuple ke dalam dataspace bersama tapi sekarang mengikuti kebijakan replikasi yang baru dipilih. Namun, tergantung pada kebijakan replikasi baru, dengan cara yang berbeda untuk membuat transisi dapat dibuat (dan lebih murah). Misalnya, ketika beralih dari bukan replikasi ke replikasi master/slave, satu pendekatan bisa juga untuk menyalin tupel ke slave ketika mereka pertama kali diakses.

13.8 Toleransi Kesalahan

Ketika mempertimbangkan bahwa toleransi kesalahan fundamental bagi setiap sistem terdistribusi, agak mengejutkan betapa relatif sedikit perhatian telah dibayarkan kepada toleransi kesalahan dalam sistem koordinasi-berbasis, termasuk dasar mempublikasikan / berlangganan sistem serta komunikasi generatif yang mendukung, dalam banyak kasus, perhatian berfokus pada keandalan efisien memastikan pengiriman data, yang pada dasarnya bermuara untuk menjamin komunikasi yang handal. Ketika middleware juga diharapkan untuk menyimpan item data, seperti halnya dengan komunikasi generatif, beberapa upaya dibayarkan untuk penyimpanan yang handal, mari kita lihat lebih dekat pada kedua kasus.

13.8.1 komunikasi langganan publish yang dapat diandalkan

Di dalam sistem berbasis koordinasi dimana

item data yang diumumkan

dicocokan hanya terhadap pelanggan hidup. komunikasi handal memainkan peran

penting. Dalam hal ini, toleransi kesalahan Yang Sering di terapkan melewati pelaksanaan sistem multicast handal yang mendasari aktual mempublikasikan / berlangganan perangkat lunak. Ada beberapa isu yang umumnya diurusi. Pertama, independen dari cara yang berbasis konten routing yang terjadi, saluran multicast dapat diandalkan sudah diatur. Kedua, proses toleransi kesalahan perlu ditangani. Mari kita lihat bagaimana masalah tersebut dibahas dalam TIB / pertemuan.

Contoh: toleransi kesalahan dalam TIB / pertemuan

TIB / pertemuan mengasumsikan fasilitas Komunikasi Dari jaringan yang mendasarinya secara inheren tidak dapat diandalkan. Untuk mengkompensasi hal ini tidak dapat diandalkan, setiap kali bertemu menerbitkan daemon pesan ke daemon lain, itu menjaga pesan setidaknya selama 60 detik. Ketika menerbitkan sebuah Pesan , daemon melekatkan nomor urutan (subjek independen) untuk pesan itu. Sebuah daemon yang telah terkirim bisa mendeteksi pesannya Yang Hilang dengan Melihat Nomor urutan (memanggil Pesan Yang dikirimkan ke semua daemon). Ketika pesan hilang, daemon yang telah diterbitkan meminta untuk mengulang mengirimkan pesan kembali. Bentuk komunikasi regular tidak Bisa mencegah pesan Masih Bisa Hilang. Contohnya, jika daemon yang telah diterima meminta mengirimkan kembali pesan yang telah diterbitkan lebih dari 60 detik lalu, daemon yang telah terbit umumnya tidak akan dapat membantu memulihkan pesan yang hilang. Dibawah keadaan normal, penerbitan dan aplikasi berlangganan akan diberitahu bahwa kesalahan komunikasi telah terjadi. Kesalahan penanganan ini kemudian diserahkan kepada aplikasi untuk menanganinya. Banyak keandalan komunikasi dalam TIB / berdasarkan pertemuan kehandalan Dari ditawarkan oleh jaringan yang mendasarinya. TIB / pertemuan juga menyediakan multicasting handal menggunakan multicasting IP (yang tidak dapat diandalkan) sebagai sarana komunikasi yang mendasarinya. Skema ini diikuti dalam TIB / rendezvous adalah multicast level transport protokol dikenal sebagai pragmatis multicast Umum (PGM). Yang dijelaskan dalam al et Speakman. (2001) kita akan membahas secara singkat PGM. PGM tidak memberikan jaminan keras bahwa ketika sebuah pesan multicast pada akhirnya akan dikirim ke setiap penerima. Gambar 13-16 (a) menunjukkan situasi di

mana pesan telah dimulticast sepanjang pohon, tetapi belum disampaikan kepada dua penerima. PGM bergantung pada receiver mendeteksi bahwa mereka telah kehilangan pesan yang mereka akan mengirim permintaan men transmit kembali (a NAK) ke pengirim. Seperti ditunjukan pada gambar (13-16(b). Permintaan ini dikirim sepanjang reverse path di pohon multicast berakar pada pengirim, seperti makan node, node yang mungkin dapat memiliki cache pesan yang diminta, di mana titik itu akan menangani transmisi ulang tersebut. Jika tidak, hanya meneruskan NAK node ke node berikutnya menuju pengirim. Pengirim pada akhirnya bertanggung jawab mentransmisi pesan PGM mengambil beberapa langkah untuk memberikan solusi yang scalable untuk multicasting yang handal. Pertama, jika sebuah node intermediate menerima permintaan pengiriman ulang beberapa pesan yang sama persis, hanya satu permintaan retransmission diteruskan menuju ke pengirim. sender
Multicast tree

PGM router
Receivers missed Message (a) Send NACK (b)

Only one NACK is forwarded Retransmission only to complaining receivers (c)

Figure 13-16. the principle of PGM . (a) A message is sent along a multicast tree. (b) a router will pass only a single NAK for each message. (c) a message is retransmitted only to receivers that have asked for it

cara ini, upaya dilakukan untuk memastikan bahwa hanya satu mencapai NAK pengirim, sehingga ledakan umpan balik dihindari. Kami sudah membahas masalah ini dalam bab. 8 ketika membahas isu-isu skalabilitas dalam multicasting yang handal.

Ukuran kedua diambil oleh PGM adalah untuk mengingat jalan melalui mana NAK suatu melintasi dari penerima ke pengirim, seperti yang ditunjukkan pada Gambar. 13-16 (c). ketika akhirnya memancarkan kembali pengirim pesan permintaan, PGM menjaga bahwa

pesan multicast hanya untuk orang-orang penerima yang telah meminta pengiriman ulang. Akibatnya, penerima dimana pesan telah berhasil dikirim tidak terganggu oleh transmisi ulang oleh orang yang tidak memintanya. Selain skema keandalan dasar dan multicasting handal melalui PGM. TIB / Rendezvous menyediakan reliabilitas lebih lanjut dengan cara pengiriman pesan bersertifikat. Dalam hal ini, proses menggunakan saluran komunikasi khusus untuk mengirim atau menerima pesan. Saluran ini memiliki fasilitas yang terkait, yang disebut buku besar. Untuk melacak pesan bersertifikat yang dikirim dan diterima. Sebuah proses yang ingin menerima pesan bersertifikat mendaftarkan diri dengan pengirim pesan tersebut. Akibatnya, pendaftaran memungkinkan saluran untuk menangani masalah keandalan lebih lanjut yang daemon pertemuan memberikan dukungan tidak. Sebagian besar masalah ini tersembunyi dari aplikasi dan akan ditangani oleh pelaksanaan saluran. Ketika buku diimplementasikan sebagai file, maka ada kemungkinan untuk memberikan pengiriman pesan handal bahkan di hadapan kegagalan proses. Sebagai contoh, ketika proses craches menerima, semua pesan yang hilang sampai sembuh lagi disimpan dalam buku besar pengirim. Setelah pemulihan, penerima hanya mengontak buku dan permintaan pesan yang terlewatkan untuk dipancarkan kembali. Untuk mengaktifkan masking kegagalan proses, TIB / Rendezvous menyediakan kesederhanaan maksudnya untuk proses otomatis aktif atau menonaktifkan. Dalam konteks ini, sebuah proses aktif biasanya merespon semua pesan yang masuk, sementara yang tidak aktif, suatu proses yang tidak aktif adalah sebuah proses yang berjalan yang hanya dapat menangani acara khusus seperti yang kita jelaskan sebentar lagi. Proses dapat diatur dalam kelompok, dengan setiap proses memiliki peringkat unik yang terkait dengan itu. Pangkat proses ditentukan oleh (tugas manual) yang berat, tetapi tidak ada dua proses di grup yang sama mungkin memiliki peringkat yang sama. Untuk setiap kelompok, TIB / Rendezvous akan mencoba untuk memiliki nomor khusus kelompokproses yang aktif, yang disebut tujuan aktif kelompok. Dalam mungkin hal ini, tujuan aktif diatur ke satu sehingga semua komunikasi dengan kelompok mengurangi ke berbasis protokol primer yang dibahas dalam bab 7

Suatu proses yang aktif secara teratur mengirim pesan ke semua anggota lain dalam kelompok untuk mengumumkan bahwa masih berdiri dan berjalan. Setiap kali seperti pesan detak jantung yang hilang, middleware akan secara otomatis mengaktifkan proses peringkat tertinggi yang saat ini tidak aktif. Aktivasi dilakukan dengan sebuah panggilan balik untuk operasi tindakan bahwa setiap anggota kelompok diharapkan untuk melaksanakan. Selanjutnya, pada saat proses sebelumnya dipulih kembali dan menjadi aktif, peringkat terendah-proses yang sedang aktif akan secara otomatis dinonaktifkan. Untuk tetap konsisten dengan proses aktif, langkah-langkah khusus perlu diambil oleh proses tidak aktif sebelum dapat menjadi aktif. Suatu pendekatan sederhana adalah membiarkan proses aktif berlangganan ke pesan yang sama seperti anggota kelompok lainnya. Sebuah pesan yang masuk diproses seperti biasa, tetapi tidak ada reaksi yang menegaskan diterbitkan, tidak bahwa skema ini mirip dengan replikasi aktif.

13.8.2 toleransi kesalahan di dalam dataspaces bersama Ketika menangani komunikasi Artikel Baru generatif, hal-hal menjadi lebih rumit. Sebagaimana juga dicatat dalam TOlksdorf dan Rowstron (2000), segera setelah toleransi kesalahan perlu dimasukkan dalam Dataspaces bersama, solusi sering dapat menjadi begitu tidak efisien yang hanya implementasi terpusat yang layak. Dalam kasus tersebut, solusi tradisional diterapkan, terutama menggunakan server pusat yang didukung yang tidak menggunakan protokol primer-backup sederhana, dalam kombinasi dengan checkpointing. Alternatif adalah untuk menyebarkan replikasi lebih agresif dengan menempatkan salinan item data di berbagai mesin. Pendekatan ini telah diadopsi di GSpace, menyebarkan dasarnya mekanisme yang sama menggunakan untuk meningkatkan kinerja melalui replikasi. Untuk tujuan ini, setiap node menghitung ketersediaan, yaitu yang digunakan dalam perhitungan ketersediaan item (direplikasi) data tunggal (Russello et al, 2006.). Untuk menghitung ketersediaannya, sebuah node secara teratur menulis timestamp untuk penyimpanan persisten, yang memungkinkan untuk menghitung waktu ketika sudah habis, dan waktu ketika turun. Lebih tepatnya, ketersediaan dihitung dari segi waktu berarti kegagalan (MTTF) dan waktu rata-rata untuk perbaikan (MTTR):

Untuk menghitung MTTF dan MTTR, sebuah node hanya melihat cap waktu login, seperti ditunjukkan pada Gambar. 13-17. Hal ini akan memungkinkan untuk menghitung rata-rata untuk waktu antar kerusakan, yang menyebabkan ketersediaan:

Perhatikan bahwa perlu untuk secara teratur log cap waktu dan yang

dapat diambil

hanya sebagai perkiraan terbaik saat kecelakaan terjadi. Namun, ketersediaan dihitung sehingga akan menjadi pesimis, karena waktu aktual yang simpul jatuh untuk kali k akan sedikit lebih dari . Juga, bukannya mengambil rata-rata sejak awal, juga

memungkinkan untuk mengambil hanya crash terakhir N ke akun. Time to failure Time to repair

Gambar 13-17. The timeline of node experiencing failures Dalam Gspaces, setiap jenis item data memiliki node utama terkait yang bertanggung jawab untuk komputasi yang sejenis itu. Mengingat bahwa item data direplikasi di node m, ketersediaan perusahaan dihitung dengan mempertimbangkan ketersediaan a1 dari masing-masing node m mengarah ke:

Dengan hanya mengambil ketersediaan sebuah item data ke dalam account, serta orangorang dari semua node, utama dapat menghitung penempatan optimal untuk sebuah item

data yang akan memenuhi persyaratan ketersediaan item data. Selain itu, juga dapat mengambil faktor-faktor lain ke account, seperti penggunaan bandwitch dan beban CPU. Perhatikan bahwa penempatan dapat berubah dari waktu ke waktu jika faktor-faktor ini berfluktuasi. 13.9 KEAMANAN Keamanan dalam sistem koordinasi berbasis menimbulkan masalah yang sulit. Di satu sisi kita telah menyatakan bahwa proses harus referentially dipisahkan, namun di sisi lain kita juga harus menjamin integritas dan kerahasiaan data. keamanan ini biasanya dilakukan melalui saluran aman (multicast), yang secara efektif memerlukan pengirim dan penerima dapat mengotentikasi satu sama lain. Pengesahan tersebut melanggar decoupling referensial. Untuk mengatasi masalah ini ada pendekatan yang berbeda. Salah satu pendekatan umum adalah untuk mengatur jaringan broker yang menangani pengolahan data dan langganan. proses Klien kemudian akan menghubungi broker, yang kemudian mengurus otentikasi dan otorisasi. Perhatikan bahwa pendekatan semacam ini memerlukan bahwa kepercayaan klien broker. Namun, seperti yang akan kita lihat nanti, dengan membedakan antara jenis broker, tidak perlu bahwa klien harus mempercayai semua broker yang terdiri dari sistem. Dengan sifat koordinasi data, otorisasi secara alami diterjemahkan menjadi masalah kerahasiaan. Sekarang kita akan melihat lebih dekat masalah ini, mengikuti diskusi yang disajikan pada wang et al. (2002).

SISTEM TERDISTRIBUSI BERBASI KORDINASI

Mengatasi masalah ini ada pendekatan yang berbeda. Salah satu pendekatan umum adalah untuk mendirikan sebuah jaringan yang rusak yang menangani pengolahan data dan langganan. Proses Klien kemudian akan menghubungi broker, yang kemudian mengurus otentikasi dan otorisasi. Perhatikan bahwa pendekatan semacam ini memerlukan bahwa kepercayaan klien broker. Namun, seperti yang akan kita lihat nanti.

Dengan membedakan antara jenis broker, itu tidak perlu bahwa klien harus mempercayai semua broker yang terdiri dari sistem. Dengan sifat koordinasi data, otorisasi secara alami diterjemahkan menjadi masalah kerahasiaan. Sekarang kita akan melihat lebih dekat masalah ini, mengikuti diskusi yang disajikan pada wang ****( 2002).

13.9.1 Kerahasiaan Salah satu perbedaan penting antara sistem distribusi cukup banyak dan koordinasi yang berbasis bahwa untuk memberikan efisiensi, middleware perlu memeriksa isi data yang diterbitkan. Tanpa bisa melakukannya, middleware dapat dasarnya hanya banjir data untuk semua pelanggan potensial. Yang menimbulkan masalah kerahasiaan informasi yang mengacu pada kenyataan bahwa kadang-kadang penting untuk tidak mengizinkan middleware untuk memeriksa data yang dipublikasikan. Masalah ini dapat dielakkan melalui enkripsi end-to-end, sedangkan substrat routing hanya melihat sumber dan alamat tujuan. Jika menerbitkan data item yang terstruktur dalam arti bahwa setiap item berisi berbagai bidang, adalah mungkin untuk menyebarkan kerahasiaan parsial. Misalnya, data mengenai real estate mungkin perlu dikirim antara agen dari kantor yang sama dengan cabang-cabang di lokasi yang berbeda, tetapi tanpa mengungkapkan alamat yang tepat dari properti. Untuk memungkinkan untuk konten berbasis routing, field alamat yang akan dienkripsi, sedangkan deskripsi properti bisa diterbitkan dalam jelas. Untuk tujuan ini, Khurana dan Kovela (2006) mengusulkan untuk menggunakan skema enkripsi perbidang yang diperkenalkan pada Betino Dan Ferrari (2002). Dalam hal ini, para agen termasuk dalam cabang yang sama akan berbagi kunci rahasia untuk mendekripsi field alamat. Tentu saja, ini melanggar decoupling referensial, tetapi kita akan membahas solusi potensial untuk masalah ini nanti. Lebih bermasalah adalah kasus ketika tidak ada bidang dapat diungkapkan dengan middleware pada plaintext. Satu-satunya solusi yang tersisa adalah bahwa konten berbasis routing terjadi pada data dienkripsi. Sebagai router bisa melihat data hanya dienkripsi, kemungkinan pada basis per-bidang, langganan perlu dikodekan sedemikian rupa sehingga pencocokan sebagian dapat terjadi. Perhatikan bahwa sebagian adalah

dasar bahwa pengguna router untuk menentukan link keluar sebuah item data yang dipublikasikan harus untuk sipir di. Masalah ini sangat dekat dengan query dan mencari melalui data dienkripsi, sesuatu yang jelas tidak mungkin untuk dicapai. Ternyata, mempertahankan tingkat tinggi kerahasiaan sementara masih menawarkan kinerja wajar dikenal sangat sulit (Kantarcioglu dan Clifton 2005). Salah satu masalah adalah bahwa jika per-bidang enkripsi yang digunakan, menjadi jauh lebih mudah untuk mencari tahu apa data adalah semua tentang. Setelah bekerja dengan data dienkripsi juga membawa masalah kerahasiaan langganan, yang mengacu pada fakta bahwa langganan mungkin tidak diungkapkan untuk middleware baik. Dalam kasus skema pengalamatan berbasis subjek, satu solusi adalah dengan hanya menggunakan enkripsi per bidang dan menerapkan pencocokan secara lapangan-dengan-lapangan yang ketat. Pencocokan sebagian dapat ditampung dalam kasus senyawa kunci-kata, yang dapat direpresentasikan sebagai bentuk terenkripsi dari konstituen tersebut dan membiarkan router memeriksa keanggotaan, seperti juga yang disarankan oleh Raiciu dan Rosenblum (2005). Karena ternyata, bahkan dimungkinkan untuk mendukung berbagai pertanyaan, memberikan skema yang efisien dapat dibuat untuk mewakili interval. Sebuah solusi potensial dibahas dalam Li et al. (2004a). Akhirnya, kerahasiaan publikasi juga masalah. Dalam hal ini, kita menyentuh pada mekanisme kontrol akses tradisional di mana proses tertentu yang seharusnya tidak diizinkan untuk melihat pesan tertentu. Dalam hal demikian, penerbit mungkin ingin membatasi secara eksplisit kelompok pelanggan mungkin. Dalam banyak kasus, kontrol ini dapat diberikan out-of-band pada tingkat penerbitan dan aplikasi berlangganan. Namun, mungkin nyaman bahwa middleware menawarkan layanan untuk menangani kontrol akses tersebut.

Decoupling penerbit dari Pelanggan Jika diperlukan untuk melindungi data dan langganan dari Khurana middleware dan Koleva (2006) mengusulkan untuk memanfaatkan layanan akuntansi khusus (AS), yang pada dasarnya duduk antara klien (penerbit dan pelanggan) dan aktual

mempublikasikan / berlangganan middleware. Ide dasarnya adalah untuk memisahkan penerbit dari pelanggan tetap menyediakan kerahasiaan informasi. Dalam skema mereka, pelanggan mendaftarkan minat mereka dalam item data tertentu, yang kemudian disalurkan seperti biasa. Item Data diasumsikan mengandung lapangan yang telah dienkripsi. Untuk memungkinkan untuk dekripsi, sekali pesan harus disampaikan ke pelanggan, router meneruskannya ke layanan akuntansi mana itu berubah menjadi sebuah pesan bahwa pelanggan hanya dapat mendekripsi. Skema ini menunjukkan pada gambar. 13-18. Sebuah penerbit register itu sendiri pada setiap node jaringan mempublikasikan / berlangganan, yaitu, di broker. Pemain depan broker informasi pendaftaran ke layanan akuntansi yang kemudian menghasilkan sebuah kunci publik yang akan digunakan oleh penerbit, dan yang ditandatangani oleh AS. Tentu saja, AS menjaga kunci pribadi terkait dengan dirinya sendiri. Ketika register pelanggan, menyediakan kunci enkripsi yang diteruskan oleh broker. Hal ini diperlukan untuk melalui fase otentikasi terpisah untuk memastikan bahwa pelanggan hanya sah mendaftar. Sebagai contoh, broker umumnya harus tidak diizinkan untuk berlangganan data dipublikasikan.

Figure 13.18. Decoupling penerbit dari pelanggan menggunakan layanan tambahan terpercaya terpercaya.

Mengabaikan banyak detail, ketika sebuah item data yang dipublikasikan, itu bidang kritis akan telah dienkripsi oleh penerbit. Ketika item data tiba di broker yang ingin mengirimkannya kepada pelanggan, permintaan mantan AS untuk mengubah pesan dengan pertama decrypting, dan kemudian mengenkripsi dengan kunci yang diberikan oleh pelanggan. Dengan cara ini, para broker tidak akan pernah bisa tahu tentang konten yang harus dirahasiakan, sementara pada saat yang sama, penerbit dan pelanggan tidak perlu berbagi informasi kunci. Tentu saja, sangat penting bahwa akuntansi servis itu sendiri dapat skala. Berbagai upaya dapat diambil, tetapi satu pendekatan yang masuk akal adalah untuk memperkenalkan alam dalam cara yangyang sama Kerberos tidak . Dalam hal ini, pesan dengan cara transmisi perlu diubah oleh re-encrypting mereka menggunakan kunci publik jasa akuntansi asing. Untuk informasi rinci, kita lihat pembaca tertarik untuk (Khurana dan Koleva, 2006).

13.9.2 Aman Berbagi Dataspace Sangat sedikit pekerjaan yang telah dilakukan ketika datang untuk membuat bersama Dataspaces aman. Pendekatan yang umum adalah untuk hanya mengenkripsi bidang item data dan membiarkan pencocokan dilakukan hanya ketika dekripsi berhasil dan sesuai isi dengan berlangganan. Pendekatan ini dijelaskan dalam vitek et al (2003). Salah satu masalah utama dengan pendekatan ini adalah bahwa kunci mungkin perlu dibagi antara penerbit dan pelanggan, atau bahwa kunci dekripsi dari penerbit harus diketahui untuk pelanggan yang berwenang. Tentu saja, jika Dataspaces bersama dipercaya (ic, proses pelaksanaan Dataspaces diijinkan untuk melihat isi tupel), hal-hal menjadi lebih sederhana. Menimbang bahwa sebagian besar implementasi menggunakan hanya satu server tunggal, memperluas bahwa server dengan mekanisme otentikasi dan otorisasi seringkali merupakan pendekatan dalam praktek.

13.10 RINGKASAN

Koordinasi sistem terdistribusi berbasis memainkan peran penting dalam membangun aplikasi terdistribusi, Sebagian besar dari sistem ini fokus pada uncoupling referensial proses, yang berarti bahwa proses tidak perlu secara eksplisit merujuk kepada satu sama lain untuk mengaktifkan komunikasi. Selain itu, juga memungkinkan untuk memberikan decoupling temporal dimana proses tidak harus hidup berdampingan untuk berkomunikasi. Sebuah kelompok penting dari sistem koordinasi berbasis dibentuk oleh sistemsistem yang mengikuti mempublikasikan / berlangganan paradigma seperti yang dilakukan di TIB / Rendezvous. Dalam model ini, pesan tidak membawa alamat penerima mereka (s), tetapi ditangani oleh subjek. Proses yang ingin menerima pesan harus berlangganan untuk subyek tertentu; middleware akan menjaga bahwa pesan yang dikirimkan dari penerbit untuk pelanggan. Lebih canggih adalah sistem menggunakan komunikasi generatif, yang mengambil pelanggan dapat merumuskan predikat atas atribut item data dipublikasikan. Dalam hal demikian, kita berhadapan dengan berbasis konten mempublikasikan / berlangganan sistem. Untuk efisiensi, adalah penting bahwa router dapat memasang filter seperti yang diterbitkan data diteruskan hanya di link tersebut keluar yang diketahui bahwa ada pelanggan. Kelompok lain sistem koordinasi berbasis menggunakan komunikasi generatif, yang berlangsung dengan cara dataspace bersama tuple. Tuple adalah struktur data diketik serupa untuk merekam. Untuk membaca sebuah tuple dari ruang tuple, suatu proses yang menentukan apa yang sedang mencari dengan menyediakan tupel template. Sebuah tuple yang cocok dengan yang template kemudian dipilih dan kembali ke proses meminta. Jika pertandingan tidak dapat ditemukan, blok proses. Koordinasi sistem berbasis berbeda dari banyak sistem terdistribusi lain di bahwa mereka berkonsentrasi penuh pada penyediaan cara yang mudah untuk proses untuk berkomunikasi tanpa mengenal satu sama lain terlebih dahulu. Selain itu, komunikasi dapat terus dengan cara anonim. Keuntungan utama dari pendekatan ini adalah fleksibilitas karena menjadi lebih mudah untuk memperpanjang atau mengubah sistem sementara itu terus beroperasi.

Prinsip-prinsip sistem terdistribusi seperti yang dijelaskan dalam bagian pertama buku ini berlaku juga untuk sistem koordinasi-berbasis, meskipun caching dan replikasi memainkan peranan kurang menonjol dalam implementasi saat ini. Dalam audisi penamaan adalah sangat terkait dengan atribut berbasis pencarian yang didukung oleh layanan direktori. Bermasalah adalah dukungan untuk keamanan, karena pada dasarnya melanggar decoupling antara penerbit dan pelanggan. Masalah ini semakin diperburuk ketika middleware harus terlindung dari isi data yang diterbitkan, sehingga jauh lebih sulit untuk memberikan solusi yang efisien.

PERMASALAHAN 1. Apa jenis model koordinasi yang akan Anda mengklasifikasikan sistem pesanantrian dibahas dalam Bab. 4? 2. Garis besar pelaksanaan mempublikasikan / berlangganan sistem yang didasarkan pada sistem pesan-antrian seperti itu dari IBM WebSphere. 3. Jelaskan mengapa sistem koordinasi berbasis desentralisasi memiliki masalah skalabilitas yang melekat. 4. Untuk apa itu surai subjek dalam TIB / Rendezvous benar-benar diselesaikan, dan bagaimana resolusi nama terjadi? 5. Garis Besar implementasi sederhana untuk pengiriman pesan benar-benarmemerintahkan dalam sistem / TIB Rendezvous. 6. Dalam berbasis konten routing seperti yang digunakan dalam sistem *****, yang kita digambarkan dalam teks, kita mungkin dihadapkan dengan masalah manajemen yang serius. Yang masalah adalah bahwa? 7. Asumsikan proses digandakan di sistem / TIB Rendezvous. Berikan dua solusi untuk menghindari sehingga pesan dari proses direplikasi tidak dipublikasikan lebih dari sekali. 8. Sejauh mana kita perlu benar-benar-memerintahkan multicasting ketika proses direplikasi dalam sistem / TIB Rendezvous? 9. Gambarkan skema sederhana untuk PGM yang akan memungkinkan penerima untuk mendeteksi pesan-pesan yang hilang, bahkan yang terakhir dalam seri.

10. Bagaimana model koordinasi yang didasarkan pada komunikasi generatif diterapkan di TIB / Rendezvous? 11. Masa sewa guna usaha di jin selalu ditetapkan sebagai durasi dan bukan sebagai waktu mutlak di mana sewa berakhir. Mengapa hal ini dilakukan? 12. Apakah masalah skalabilitas yang paling penting dalam Jini? 13. Pertimbangkan implementasi didistribusikan dari JavaSpace di mana tupel adalah direplikasi di beberapa mesin. Berikan protokol untuk menghapus tuple seperti kondisi ras dihindari ketika dua proses mencoba untuk menghapus tuple yang sama. 14. Misalkan transaksi T dalam Jini membutuhkan kunci pada objek yang sedang dikunci oleh transaksi lain 'T. Jelaskan apa yang terjadi? 15. Misalkan suatu cache klien jini tupel yang diperoleh dari JavaSpace sehingga dapat menghindari keharusan pergi pada JavaSpace waktu berikutnya. Apakah caching ini masuk akal? 16. Jawab pertanyaan sebelumnya, tapi sekarang untuk kasus yang cache klien hasil yang dikembalikan oleh sebuah layanan pencarian. 17. Garis Besar implementasi sederhana dari sebuah JavaSpace fault-tolerant. Dalam beberapa subjek berbasis mempublikasikan / berlangganan sistem, solusi aman dicari di enkripsi end-to-end antara penerbit dan pelanggan. Namun, pendekatan ini mungkin melanggar tujuan desain awal sistem koordinasi-ber