PERTEMUAN IV (SISTEM TERDISTRIBUSI)

BAB III
PROSES

3.2.2 Client - Side Software for Distribution Transparency

Seperti yang kita juga disebutkan dalam sec 1.5, perangkat lunak klien terdiri lebih bahwa hanya user interface. Dalam banyak kasus, bagian dari tingkat pengolahan dan data dalam aplikasi client server yang dijalankan pada sisi client juga. Kelas khusus yang dibentuk oleh perangkat lunak klien tertanam, seperti untuk anjungan tunai mandiri (ATM), cash register, pembaca barcode, TV set top box, dll Dalam kasus ini. Interface pengguna adalah bagian yang relatif kecil dari perangkat lunak klien, berbeda dengan pemrosesan lokal dan fasilitas comminications.

Selain user interface dan perangkat lunak aplikasi lainnya releted, perangkat lunak klien terdiri dari komponen untuk mencapai transparansi distribusi. Idealnya klien tidak boleh ware bahwa itu berkomunikasi dengan proses remote. Sebaliknya, distributiuon sering kurang transparan ke server untuk alasan kinerja dan kebenaran. Misalnya, dalam bab 6 kita akan menunjukkan bahwa server direplikasi kadang-kadang perlu untuk berkomunikasi dalam rangka untuk menetapkan bahwa operasi dilakukan dalam urutan tertentu di cach replika.

Transparansi akses umumnya ditangani melalui generasi dari sebuah rintisan klien dari definisi antarmuka dari server harus ofter. Rintisan ini menyediakan antarmuka yang sama seperti yang tersedia di server, namun menyembunyikan perbedaan mungkin dalam arsitektur mesin serta komunikasi yang sebenarnya.

Ada cara yang berbeda untuk menangani lokasi, migrasi, dan transparansi relokasi. Menggunakan sistem penamaan yang nyaman sangat penting karena kita juga akan lihat dalam bab berikutnya. Dalam banyak kasus, kerja sama dengan software sisi klien juga penting. Sebagai contoh, ketika klien yang alredy terikat ke server klien bisa langsung memberitahu lokasi server perubahan. Dalam kasus ini, middleware klien dapat menyembunyikan lokasi saat ini server dari pengguna dan juga transparan rebind ke server jika perlu. Paling buruk, aplikasi klien mungkin akan melihat kerugian sementara kinerja.

Dalam cara yang sama, sistem terdistribusi banyak menerapkan transparansi replikasi dengan cara solusi sisi klien. Misalnya bayangkan sebuah sistem terdistribusi dengan objek remote. Replikasi dari sebuah remote object dapat dicapai dengan meneruskan permintaan doa untuk setiap replika. Seperti yang ditunjukkan pada gambar 3-6. Proxy klien secara transparan dapat mengumpulkan semua tanggapan dan lulus nilai kembali tunggal untuk allpication klien.

a possible approach to transparent replication of a remote object using a client-side solution

Akhirnya, mempertimbangkan transparansi kegagalan. Kegagalan komunikasi Masking dengan server biasanya dilakukan melalui middleware klien. Sebagai contoh, klien middleware dapat dikonfigurasi untuk repeayedly mencoba untuk menghubungkan server, atau mungkin mencoba server lain setelah beberapa upaya. Bahkan ada situasi di mana klien middleware mengembalikan data itu cache selama sesi sebelumnya, seperti yang kadang-kadang dilakukan oleh browser web yang gagal untuk terhubung ke server.

Transparansi Concurrency dapat ditangani melalui server perantara khusus, terutama transaksi monitor dan membutuhkan dukungan kurang dari software.likewiss klien, ketekunan trasparancy sering sepenuhnya ditangani di server.

3.3 SERVER

Mari kita melihat lebih dekat pada organisasi server. Pada halaman berikut, pertama-tama kita berkonsentrasi pada sejumlah isu desain umum untuk server, yang akan diikuti dengan diskusi tentang server objek. Server Obyek penting karena mereka membentuk blok bangunan untuk menerapkan objek terdistribusi.

3.3.1 General desain Issues

Server adalah sebuah proses yang menerapkan layanan tertentu atas nama koleksi klien. Pada dasarnya, setiap server diatur dengan cara yang sama: ia menunggu permintaan masuk dari klien dan kemudian memastikan bahwa permintaan tersebut diurus, setelah itu menunggu permintaan masuk berikutnya.

Ada beberapa cara untuk mengatur server. Dalam kasus server interative, server sendiri menangani permintaan dan, jika perlu, mengembalikan respon ke klien meminta. Sebuah server konkuren tidak menangani permintaan sendiri, tapi lolos ke thread terpisah atau proses lain, setelah itu segera menunggu permintaan masuk berikutnya. Sebuah server multithreaded adalah contoh dari sebuah server bersamaan. Sebuah implementasi alternatif dari sebuah server bersamaan adalah untuk garpu proses baru untuk setiap permintaan yang masuk baru. Pendekatan ini follewed dalam sistem UNIX banyak. Benang atau proses yang menangani permintaan bertanggung jawab untuk mengembalikan respon ke klien meminta.
Lain masalah adalah di mana klien menghubungi server. Dalam semua kasus, klien mengirim permintaan ke endpoint, juga disebut pelabuhan, di mana mesin server berjalan. Setiap server mendengarkan titik akhir tertentu. Bagaimana klien tahu akhir-titik layanan? Satu pendekatan adalah untuk menetapkan global endpoint untuk terkenal layanan. Misalnya, server yang menangani internet permintaan FTP selalu mendengarkan TCP port 21. Demikian juga, sebuah server HTTP untuk world wide web akan selalu mendengarkan TCP port 80. Titik akhir telah ditetapkan oleh Otoritas internet Ditugaskan Nomor (IANA), dan didokumentasikan dalam (Reynolds dan Postel, 1994). Dengan endpoint ditetapkan, klien hanya perlu menemukan alamat jaringan dari mesin di mana server berjalan. Seperti yang kita jelaskan dalam bab berikutnya, layanan nama dapat digunakan untuk tujuan itu.

Ada banyak layanan yang tidak memerlukan endpoint preassigned. Sebagai contoh, server waktu-of-hari dapat menggunakan endpoint yang dinamis ditugaskan oleh sistem operasi lokal. Dalam hal ini, klien pertama akan harus mencari titik akhir. Salah satu solusi, seperti yang kita lihat di DCE, adalah memiliki daemon khusus yang berjalan pada setiap mesin yang menjalankan server. Daemon melacak titik akhir saat setiap layanan diimplementasikan oleh server colocated. Daemon itu diri mendengarkan titik akhir terkenal. Seorang klien pertama akan menghubungi daemon, meminta titik akhir, dan kemudian menghubungi server tertentu, seperti yang ditunjukkan pada figh. 3-7 (a). Adalah umum untuk menghubungkan titik akhir dengan layanan tertentu. Namun benar-benar menerapkan setiap layanan melalui server saparate mungkin membuang-buang sumber daya.

Gambar 3-7. (a) klien-ke-server mengikat menggunakan daemon seperti di DCE. (b). client-server mengikat menggunakan server super seperti di UNIX

Sebagai contoh, dalam sistem UNIX yang khas, adalah umum untuk memiliki banyak server yang berjalan secara bersamaan, dengan sebagian besar dari mereka pasif menunggu sampai permintaan klien masuk Istead karena harus melacak proses pasif begitu banyak, seringkali lebih efisien memiliki superserver tunggal mendengarkan setiap endpoint terkait dengan layanan tertentu, seperti ditunjukkan pada Gambar. 3-7 (b). Ini adalah pendekatan yang dilakukan, misalnya, dengan daemon inetd di UNIX. Inetd mendengarkan sejumlah terkenal port untuk layanan internet. Ketika permintaan datang, itu garpu proses untuk mengurus lanjut dari permintaan. Proses itu akan keluar setelah selesai.

Isu lain yang perlu dipertimbangkan ketika merancang server, adalah apakah dan bagaimana server dapat terganggu. Sebagai contoh, mempertimbangkan pengguna yang baru saja memutuskan untuk meng-upload file besar ke server FTP. Kemudian, tiba-tiba menyadari transmisi. Ada beberapa cara untuk melakukan hal ini. Salah satu pendekatan yang bekerja hanya terlalu baik di internet saat ini (dan kadang-kadang satu-satunya altrnative), adalah bagi pengguna untuk tiba-tiba keluar dari applicaqtion client (yang secara otomatis akan memutus koneksi ke server), segera restart, dan berpura-pura tidak ada yang terjadi . Server akhirnya akan meruntuhkan koneksi tua, berpikir klien telah jatuh.

Sebuah pendekatan yang lebih baik untuk menangani interrups komunikasi, adalah untuk mengembangkan klien dan server seperti bahwa adalah mungkin untuk mengirim out-of-band data, yaitu data yang akan diproses oleh server mendengarkan endpoint kontrol terpisah dimana klien mengirimkan out-of-band data, sementara pada saat yang sama mendengarkan (dengan prioritas yang lebih rendah) ke titik akhir melalui mana data normal lewat. Solusi lain adalah untuk mengirimkan out-of-band data seluruh sambungan yang sama melalui mana clien sedang mengirim permintaan yang asli, di TCP, misalnya, adalah mungkin untuk mengirimkan data mendesak. Ketika data penting yang diterima di server, yang terakhir terganggu (misalnya, melalui sinyal dalam sistem UNIX), setelah itu dapat memeriksa data dan menangani mereka sesuai.

Masalah, desain akhir yang penting, adalah apakah atau tidak server stateless. Sebuah server stateless tidak menyimpan informasi tentang keadaan klien, dan dapat mengubah keadaan sendiri tanpa harus menginformasikan klien (Birman, 1996). Sebuah server web, misalnya, adalah stateless. Ini hanya merespon permintaan HTTP yang masuk, yang bisa baik untuk meng-upload file ke server atau (paling sering) untuk klien sepenuhnya. Demikian juga, kumpulan file yang mengelola web server (mungkin bekerja sama dengan server file), dapat diubah tanpa klien harus diberitahu.

Dalam contracst, server stateful tidak memelihara informasi pada klien. Sebuah contoh yang khas adalah file server yang memungkinkan klien untuk menyimpan salinan lokal file, bahkan untuk melakukan perations update. Seperti server akan mempertahankan tabel yang berisi (client, file) entri. Seperti meja memungkinkan server untuk menjaga tarck dari mana klien saat ini memiliki izin update di mana file, dan dengan demikian mungkin juga versi terbaru dari file tersebut. Pendekatan ini dapat meningkatkan kinerja membaca dan menulis operasi seperti yang dirasakan oleh klien. performanceimprovement atas server stateless sering merupakan manfaat penting dari desain stateful. Namun, contoh ini juga menggambarkan kelemahan utama server stateful. Jika server crash, itu untuk memulihkan tabel dari (client, file) entri, atau jika tidak cannotguarantee yang telah diproses update terbaru pada sebuah file. Secara umum, server stateful perlu untuk memulihkan seluruh negara sebagai itu tepat sebelum kecelakaan itu. Seperti yang kita bahas dalam bab, 7, memungkinkan pemulihan dapat inroduce kompleksitas yang cukup besar. Dalam desain yang stateless, tidak ada langkah-langkah khusus harus diambil sama sekali untuk server jatuh untuk pulih. Ini hanya mulai berjalan lagi, dan menunggu permintaan klien untuk masuk

Ketika merancang server, pilihan untuk desain stateless atau stateful seharusnya tidak mempengaruhi layanan yang diberikan oleh server. Sebagai contoh, jika file harus dibuka sebelum mereka dapat dibaca dari atau ditulis untuk, maka server stateless harus satu cara atau yang lain meniru perilaku ini. Sebuah solusi umum, yang akan kita bahas secara lebih rinci dalam bab 10, adalah bahwa server merespon dengan membaca atau menulis operasi, dan segera menutup file lagi.

Dalam kasus lain, server mungkin ingin menyimpan catatan pada perilaku klien sehingga dapat lebih efektif merespon ti permintaannya. Misalnya. Server web sometimesoffer kemungkinan untuk segera mengarahkan klien ke halaman favoritnya. Pendekatan ini hanya mungkin jika server memiliki informasi sejarah pada klien itu. Solusi umum adalah untuk membiarkan klien mengirim sepanjang informasi tambahan mengenai akses sebelumnya. Ini informasi yang menarik bagi serve. Cookie tidak pernah dijalankan oleh browser, mereka hanya disimpan.

Pertama kali klien mengakses server, yang terakhir mengirimkan cookie bersama dengan halaman web yang diminta kembali ke browser, setelah itu browser aman lucks cookie pergi. Setiap kali berikutnya klien mengakses server, cookie untuk server yang dikirim bersama dengan permintaan. Meskipun pada prinsipnya, pendekatan ini bekerja dengan baik, fakta bahwa cookie dikirim kembali untuk menjaga aman oleh browser ofthen disembunyikan seluruhnya dari pengguna. Begitu banyak untuk privasi. Tidak seperti kebanyakan kue nenek, cookie ini umumnya harus tinggal di mana mereka dipanggang.

3.3.2 Object Server

Setelah mengambil melihat beberapa masalah desain umum, kita tidak mempertimbangkan jenis spesial dari server yang menjadi semakin penting. Sebuah server obyek server adalah server disesuaikan dengan suport objek terdistribusi. Perbedaan penting antara server objek umum dan lainnya (lebih tradisional) server yang, adalah bahwa server obyek dengan sendirinya tidak benar-benar memberikan server tertentu. Server tertentu yang dilaksanakan oleh thatreside objek dalam server. Pada dasarnya, server hanya menyediakan sarana untuk memanggil objek lokal, berdasarkan permintaan dari klien remote. Sebagai akibatnya, relatif mudah untuk mengubah layanan dengan hanya menambahkan dan menghapus objek.

Sebuah server objek sehingga bertindak sebagai tempat di mana objek hidup. Sebuah benda terdiri dari dua bagian: Data represeting negara dan kode membentuk penerapan metode nya. Apakah atau tidak bagian-bagian terpisah, atau apakah implementasi metode dibagi oleh beberapa objek, tergantung pada server objek. Juga, ada perbedaan dalam cara server objek memanggil objeknya. Misalnya, dalam sebuah server multithread, setiap objek dapat diberi benang terpisah, atau thread terpisah dapat digunakan untuk setiap permintaan doa. Ini dan lainnya isu-isu yang dibahas berikutnya.

Alternatif untuk mencari objek.

Untuk objek yang akan dipanggil, server objek perlu tahu kode untuk mengeksekusi, di mana data itu harus beroperasi, apakah harus memulai thread terpisah untuk mengurus invocatoin, dan sebagainya. Suatu pendekatan sederhana untuk mengasumsikan bahwa obyek semua terlihat sama dan itu thereis hanya salah satu cara untuk memanggil obyek. Apakah intinya, ini adalah apa yang DCE tidak. Sayangnya, pendekatan semacam ini pada umumnya tidak fleksibel dan sering tidak perlu menghambat pengembang objek terdistribusi.

Sebuah pendekatan yang lebih baik adalah untuk server untuk mendukung kebijakan perbedaan. Perhatikan, misalnya, objek transien. mengingat bahwa obyek trasient adalah Taht objek hanya ada selama server yang ada, tapi mungkin untuk waktu yang lebih singkat. Sebuah in-memory, read-only copy file biasanya dapat diimplementasikan sebagai objek trasiest. Demikian juga, kalkulator (mungkin berjalan pada server kinerja tinggi), juga bisa diimplementasikan sebagai objek trasient. Sebuah kebijakan yang masuk akal adalah untuk membuat objek trasient atas permintaan doa pertama, dan untuk menghancurkan secepat ada klien yang membutuhkan sumber daya server yang hanya selama obyek benar-benar diperlukan. Punggung menarik adalah bahwa sebuah doa dapat mengambil beberapa waktu untuk menyelesaikan, karena objek perlu dibuat terlebih dahulu. Oleh karena itu, alternatif kebijakan kadang-kadang untuk membuat semua objek trasient pada saat server intialized, pada biaya sumber daya mengkonsumsi bahkan ketika klien tidak ada memanfaatkan objek.
            Dengan cara yang mirip, server bisa mengikuti kebijakan bahwa setiap objeknya ditempatkan dalam segmen memori sendiri. Dalam kata lain saham, objek tidak kode atau data. Kebijakan seperti ini mungkin diperlukan ketika sebuah implementasi objek tidak terpisah kode dan data, atau ketika objek harus dipisahkan karena alasan keamanan. Dalam kasus terakhir, server akan perlu memberikan langkah-langkah khusus, atau memerlukan dukungan dari sistem operasi yang mendasarinya. Pendekatan alternatif adalah untuk membiarkan objek setidaknya berbagi kode mereka. Ketika permintaan untuk doa objek masuk, server hanya perlu fecth negara objek dari database dan menjalankan metode yang diminta.

Demikian juga, ada kebijakan yang berbeda sehubungan dengan threading. Pendekatan sederhana adalah untuk menerapkan srever dengan hanya satu thread kontrol. Atau, server mungkin memiliki beberapa thread, satu untuk masing-masing objeknya. Keuntungan dari pendekatan ini adalah bahwa objek secara otomatis dilindungi terhadap akses konkuren: semua invocatoins adalah serial melalui benang tunggal yang terkait dengan objek. Independen menggunakan thread per objek atau thread per metode adalah pilihan apakah benang yang dibuat pada permintaan atau server mempertahankan kolam benang. Umumnya tidak ada kebijakan tunggal terbaik.

Obyek Adapter

Keputusan tentang cara memanggil obyek yang sering disebut sebagai kebijakan aktivasi, untuk menekankan bahwa dalam banyak kasus obyek itu sendiri pertama harus dibawa ke server addres ruang (yaitu, diaktifkan) sebelum benar-benar dapat dipanggil.

apa yang dibutuhkan,  adalah mekanisme untuk kelompok objek per kebijakan. Seperti mechanicsm yang kadang-kadang disebut adaptor objek, atau pembungkus objek, tetapi sering hanya tersembunyi di set alat untuk membangun server objek. Kami addopt adaptor objek panjang. Adaptor objek terbaik bisa meskipun sebagai perangkat lunak menerapkan kebijakan aktivasi tertentu. Isu-isu utama, bagaimanapun, adalah bahwa adapter objek datang sebagai komponen generik juga membantu pengembang objek terdistribusi, dan yang hanya perlu dikonfigurasi untuk kebijakan tertentu.

Adaptor objek memiliki satu atau lebih obyek di bawah kendalinya. Karena server harus mampu secara simultan mendukung objek yang memerlukan kebijakan aktivasi yang berbeda, adapter beberapa objek dapat berada di server yang sama pada waktu yang sama. Ketika permintaan doa yang dikirimkan ke server, permintaan yang pertama kali dikirim ke adaptor objek approoriated, seperti yang ditunjukkan pada Gbr.3-8.

Sebuah pengamatan penting adalah bahwa adapter objek yang dilewati begitu saja oleh dari interface tertentu dari objek yang mereka kontrol. Jika tidak, mereka tidak akan pernah bisa generik. Satu-satunya masalah yang penting untuk adaptor obyek yang dapat mengekstrak sebuah referensi obyek dari permintaan doa, dan subsequency dispacth permintaan ke objek referensi. rintisan, juga disebut kerangka, biasanya dihasilkan dari definisi antarmuka objek, unmarshals permintaan dan memanggil metode yang disesuaikan.
Untuk berinteraksi dengan menjadi kerangka objek-spesifik yang marshal dan permintaan unmarshal, ia mengharapkan bahwa kerangka mengimplementasikan setiap operasi di mana in_args dalam array byte yang perlu unmarshaled oleh stub. format yang tepat dari array diketahui hanya pada rintisan yang juga bertanggung jawab atas doa yang sebenarnya, panjang array adalah spesifik oleh parameter output out_size. (Catatan yang memanggil adalah mirip dengan versi yang dibahas dalam bab sebelumnya, yang digunakan untuk inovation dinamis)

Bagian yang paling penting adalah defenition dari pesan pertukaran adaptor dengan klien remote. Setiap klien diharapkan dapat menyusun permintaan doa dalam pesan memiliki lima bidang. Sumber lapangan mengidentifikasi pengirim pesan. Input data yang akan dikirimkan ke stub, yang terkandung dalam data array yang Suze yang tepat diberikan oleh ukuran lapangan. Hasil dari pemanggilan tersebut sama kemudian dimasukkan ke dalam bidang data pesan baru.

File header juga berisi defenition dari apa adaptor harapkan dapat menghubungi di rintisan server-side dari obyek dengan cara defenition jenis METHOD_CALL.

Akhirnya, adaptor menyediakan dua prosedur yang dapat dipanggil oleh server untuk mendaftarkan objek pada adaptor. Pendaftaran berlangsung dengan melewatkan pointer ke objek-Implementasi spesifik dari prosedur memanggil, seperti yang diterapkan dalam rintisan objek. Tp unregister obyek, server hanya lewat nomor ini saat memanggil unregister_object. Hasilnya kemudian akan dimasukkan ke dalam buffer berbeda, seperti yang kita jelaskan berikutnya.

Struct THREAD benang Tipedef; * / defenition of thread Tersembunyi. * /

THREAD * create_thread (void (* body) (tid panjang), panjang thread_id);

/ * Buat thread dengan memberikan pointer ke fungsi yang mendefinisikan * aktual /

/ * Perilaku benang, bersama dengan integer yang digunakan untuk * /

/ * Unik mengidentifikasi benang. * /

Void get_msg (unsigned ukuran, char ** data);

Void put_msg (THREAD * receiver, ukuran unsigned, char * data);

/ * Memanggil blok get_msg benang sampai pesan telah dimasukkan ke dalam nya * /

/ * Buffer Associated, menempatkan pesan dalam buffer thread ini adalah nonblocking * /
/ * Operasi. * /

Gambar 3-10. file thread.h digunakan oleh adaptor untuk menggunakan benang.

Untuk menerapkan adaptor, kita asumsikan ada paket yang tersedia benang yang menyediakan fasilitas yang diperlukan untuk menciptakan (dan menghapus) benang dan untuk membiarkan berkomunikasi benang. Pesan yang ditambahkan ke buffer melalui put_msg operasi nonblocking. Bagian utama dari file header dari paket benang ditunjukkan pada gambar. 3-10.

Kita sekarang sampai pelaksanaan aktual dari adaptor, yang ditunjukkan pada gambar 3-11. Setiap benda memiliki thread sendiri terkait ditentukan oleh thread_per_object prosedur. Sebuah thread dimulai dengan clocking sampai permintaan doa telah dimasukkan ke dalam buffer yang terkait. Hasil dari pemanggilan objek dikembalikan dalam hasil variabel, dan kemudian harus disalin ke respon. Itu pesan respon dibangun dengan terlebih dahulu menetapkan bidang object_id dan method_id, dan kemudian menyalin hasil ke kolom data pesan. Pada saat itu, respon dapat diserahkan kepada demultiplexer. Seperti yang ditunjukkan pada Gambar. 3-8. Dalam contoh kita, demultiplexer ini dilaksanakan oleh thread terpisah dirujuk oleh akar variabel.

Pelaksanaan invoke_adapter sekarang sederhana. Thread memanggil (yaitu, demultiplexer pada contoh kita) menambahkan permintaan doa kepada penyangga benang yang berhubungan dengan objek yang diperlukan untuk dipanggil. Kemudian, demultiplexer dapat mengambil hasil dari buffer sendiri, setelah itu mereka dapat kembali ke klien yang awalnya diminta inovasi.

Penting untuk dicatat bahwa pelaksanaan adaptor adalah independen dari benda-benda yang menangani pemanggilan. Pada kenyataannya, tidak ada kode objek-spesifik telah dimasukkan dalam pelaksanaan contoh. Akibatnya, menjadi mungkin untuk membangun adaptor objek generik dan konseptual menempatkan adaptor ini dalam lapisan middleware. Pengembang dari server obyek kemudian perlu berkonsentrasi hanya pada pengembangan obyek, dan hanya menentukan adaptor harus mengontrol seruan objek tersebut.

Sebagai ucapan akhir, meskipun kami telah menunjukkan komponen demultiplexing terpisah di ara. 3-8 yang menangani pengiriman permintaan doa yang masuk ke adaptor objek yang sesuai, seperti demultiplexer sebenarnya tidak diperlukan. Sebaliknya, kita sama-sama bisa juga menggunakan adaptor objek untuk tujuan itu. Seperti yang kita bahas dalam chap.9, ini pendekatan kedua diikuti di COBRA.

3.4 KODE MIGRASI

Sejauh ini, kami telah terutama berkaitan dengan sistem terdistribusi di mana komunikasi terbatas pada data yang melewati. Namun, ada situasi di mana program lewat, kadang-kadang bahkan ketika mereka sedang dieksekusi, menyederhanakan desain sistem terdistribusi. Pada bagian ini, kita melihat rinci apa migrasi kode sebenarnya. Kita mulai dengan mempertimbangkan pendekatan yang berbeda untuk migrasi kode, diikuti dengan diskusi tentang bagaimana menangani sumber daya lokal yang bermigrasi menggunakan program. Sebuah masalah yang sangat keras bermigrasi kode dalam sistem heterogen, yang juga dibahas. Untuk membuat hal-hal konkret, kita membahas sistem D'Agen untuk agen mobile di akhir bagian ini. Perhatikan bahwa masalah keamanan mengenai migrasi ditangguhkan untuk chap8.

3.4.1 Pendekatan untuk Migrasi Kode

Sebelum mengambil melihat berbagai bentuk migrasi kode, mari kita pertama mempertimbangkan mengapa mungkin berguna untuk bermigrasi kode.

Alasan Migrasi Kode

Secara tradisional, kode migrasi dalam sistem terdistribusi mengambil sistem terjadi dalam bentuk migrasi proses di mana seluruh proses dipindahkan dari satu komputer ke komputer lain. Memindahkan proses yang berjalan ke mesin yang berbeda adalah tugas yang mahal dan rumit, dan ada yang lebih baik menjadi alasan yang baik untuk melakukannya. Itulah alasannya selalu kinerja. Ide dasarnya adalah bahwa kinerja sistem secara keseluruhan dapat ditingkatkan jika proses dipindahkan dari berat-ringan dimuat ke-loaded mesin. Beban sering dinyatakan dalam panjang antrian CPU atau pemanfaatan CPU, indikator kinerja lainnya bur digunakan juga.

Muat algoritma distribusi dengan mana keputusan dibuat mengenai alokasi dan redistribusi tugas sehubungan dengan satu set prosesor, memainkan peran penting dalam komputasi-intensif sistem. Namun, dalam banyak sistem terdistribusi modern, mengoptimalkan kapasitas komputasi les masalah daripada, misalnya, mencoba untuk meminimalkan komunikasi. Selain itu, karena heterogenitas dari platform yang mendasari dan jaringan komputer, peningkatan kinerja melalui migrasi kode sering didasarkan pada penalaran kualitatif, bukan model matematika.

Perhatikan, misalnya, sistem client-server di mana server mengelola database besar. Jika aplikasi klien perlu melakukan operasi database yang melibatkan sejumlah besar data, mungkin lebih baik untuk kapal bagian dari aplikasi client ke server dan mengirim hanya hasil di seluruh jaringan. Jika tidak, jaringan dapat dibanjiri dengan transfer data dari server ke klien. Dalam hal ini, migrasi kode didasarkan pada asumsi bahwa pada umumnya masuk akal untuk mengolah data dekat dengan tempat data tersebut berada.

Ini alasan yang sama dapat digunakan untuk migrasi bagian dari server ke klien. Misalnya, dalam banyak aplikasi database interaktif, klien harus mengisi formulir yang kemudian diterjemahkan ke dalam serangkaian operasi database. Pengolahan formulir di sisi client, dan mengirim hanya formulir yang telah diisi ke server, kadang-kadang dapat menghindari bahwa jumlah yang relatif besar pesan kecil perlu menyeberang jaringan. Hasilnya adalah klien yang merasakan kinerja yang lebih baik, sementara pada saat yang sama server menghabiskan waktu kurang pada pengolahan bentuk dan komunikasi.
Dukungan untuk migrasi kode juga dapat membantu meningkatkan kinerja dengan memanfaatkan paralelisme, tetapi tanpa kerumitan yang biasa berhubungan dengan pemrograman paralel. Sebuah contoh yang khas adalah mencari informasi di web. Hal ini relatif sederhana untuk menerapkan permintaan pencarian dalam bentuk program mobile kecil yang bergerak dari situs ke situs. Dengan membuat beberapa salinan dari suatu program, dan saling mengirim ke situs yang berbeda, kita mungkin dapat mencapai kecepatan-up linear dibandingkan dengan hanya menggunakan contoh program tunggal.

Selain meningkatkan kinerja, ada alasan lain untuk mendukung migrasi kode juga. Yang paling penting adalah bahwa fleksibilitas. Pendekatan tradisional untuk membangun aplikasi terdistribusi adalah untuk partisi aplikasi menjadi bagian-bagian yang berbeda, dan memutuskan di muka mana setiap bagian harus dieksekusi. Pendekatan ini, sebagai contoh, telah menyebabkan multitier yang berbeda aplikasi client-server dibahas dalam Chap1.
Namun, jika kode dapat bergerak di antara mesin yang berbeda, maka ada kemungkinan untuk secara dinamis mengkonfigurasi sistem terdistribusi. Misalnya, server mengimplementasikan antarmuka standar untuk sistem file. Untuk mengizinkan klien remote untuk mengakses sistem file, server yang menggunakan protokol proprietary. Biasanya, implementasi client-sisi antarmuka sistem file, yang didasarkan pada protokol itu, perlu dikaitkan dengan aplikasi client. Pendekatan ini diperlukan bahwa perangkat lunak akan tersedia untuk klien pada saat aplikasi klien sedang dikembangkan.

Alternatif adalah untuk membiarkan server menyediakan implementasi klien tidak lebih cepat dari yang dibutuhkan, yaitu ketika klien mengikat ke server. Pada saat itu, klien download dinamis pelaksanaan, berjalan melalui langkah-langkah yang diperlukan inisialisasi, dan kemudian memanggil server. Prinsip ini ditunjukkan pada Gbr.3-12. Model kode dinamis bergerak membentuk situs remote tidak mengharuskan protokol untuk men-download kode dan menginisialisasi kode standar. Juga, perlu bahwa kode download dapat dieksekusi pada mesin klien. Solusi yang berbeda dibahas di bawah ini dan-di bab berikutnya.

            Keuntungan penting dari model dinamis men-download client-side software, adalah bahwa klien tidak perlu memiliki semua perangkat lunak terinstal untuk berbicara dengan server. Sebaliknya, perangkat lunak dapat pindah jika diperlukan, dan juga, dibuang ketika tidak lagi diperlukan. Keuntungan lain adalah bahwa selama interface standar, kita dapat mengubah protokol client-server dan pelaksanaannya sesering kita suka. Perubahan tidak akan mempengaruhi aplikasi client yang sudah ada yang bergantung pada server. Ada, tentu saja, juga kerugian. Yang paling serius, yang kita bahas dalam chap8, berkaitan dengan keamanan. Membabi buta percaya bahwa kode download mengimplementasikan antarmuka hanya diiklankan saat mengakses hard disk Anda terlindungi dan tidak mengirim bagian juiciest ke surga-tahu-yang mungkin tidak selalu ide yang bagus.

Model untuk Migrasi Kode

Meskipun migrasi kode menunjukkan bahwa kita bergerak kode hanya antara mesin, istilah sebenarnya mencakup daerah yang jauh lebih kaya. Secara tradisional, komunikasi dalam sistem terdistribusi adalah berkaitan dengan pertukaran data antara proses. Kode migrasi dalam arti yang luas dengan penawaran bergerak program antara mesin, dengan maksud untuk memiliki program-program dilaksanakan pada target. Dalam beberapa kasus, seperti dalam proses migrasi, status pelaksanaan program, sinyal tertunda, dan bagian lain dari lingkungan harus dipindahkan juga.

Untuk mendapatkan pemahaman yang lebih baik dari model yang berbeda untuk migrasi kode, kita menggunakan kerangka kerja yang diuraikan dalam (Fugetta et al,. 1998). Dalam kerangka ini, proses terdiri dari tiga segmen. Segmen kode adalah bagian yang berisi set instruksi yang membentuk program yang sedang dijalankan. Segmen sumber daya berisi referensi ke sumber daya eksternal yang dibutuhkan oleh proses, seperti file, printer, perangkat, proses lainnya, dan seterusnya. Akhirnya, segmen eksekusi digunakan untuk menyimpan keadaan eksekusi dari sebuah proses, yang terdiri dari data pribadi, stack, dan program counter.

Minimal untuk migrasi kode adalah untuk menyediakan hanya mobilitas yang lemah. Dalam model ini, adalah mungkin untuk mentransfer hanya segmen kode, bersama dengan mungkin beberapa data inisialisasi. Sebuah fitur karakteristik mobilitas yang lemah adalah bahwa program ditransfer selalu dimulai dari awal dari keadaan awal. Inilah yang terjadi, misalnya, dengan applet java. Keuntungan dari pendekatan ini adalah kesederhanaannya. Mobilitas yang lemah hanya membutuhkan bahwa mesin target dapat mengeksekusi kode itu, yang pada dasarnya bermuara untuk membuat kode portabel. Kami kembali ke hal ini ketika membahas migrasi dalam sistem heterogen.

Berbeda dengan mobilitas yang lemah, dalam sistem yang mendukung mobilitas yang kuat segmen eksekusi dapat ditransfer juga. Fitur karakteristik mobilitas yang kuat adalah bahwa proses yang berjalan dapat dihentikan, kemudian pindah ke komputer lain, kemudian melanjutkan eksekusi di mana ia tinggalkan. Jelas, mobilitas yang kuat adalah Agen D', yang kita bahas nanti bagian ini.

Terlepas dari apakah mobilitas lemah atau kuat, perbedaan lebih lanjut dapat dibuat antara pengirim dan penerima-dimulai-dimulai migrasi. Dalam pengirim-diprakarsai migrasi, migrasi dimulai pada mesin di mana kode saat ini berada atau sedang dijalankan. Migrasi Biasanya, pengirim-diprakarsai dilakukan ketika meng-upload program ke komputer server. Contoh lain adalah mengirimkan sebuah program pencarian di internet ke server web database untuk melakukan query pada server. Dalam receiver-diprakarsai migrasi, inisiatif untuk migrasi kode diambil oleh mesin target. Applet Java adalah contoh dari pendekatan ini.
            Receiver-diprakarsai migrasi seringkali sederhana untuk diterapkan daripada migrasi pengirim-dimulai. Dalam banyak kasus, migrasi kode terjadi antara klien dan server, di mana klien mengambil inisiatif untuk migrasi. Aman meng-upload kode ke server, seperti yang dilakukan di migrasi pengirim-dimulai, seringkali mensyaratkan bahwa klien sebelumnya telah terdaftar dan dikonfirmasi pada server. Dengan kata lain, server diperlukan untuk mengetahui semua kliennya, alasannya karena adalah bahwa klien mungkin akan menginginkan akses ke sumber daya server seperti disk nya. Melindungi sumber daya tersebut sangat penting. Sebaliknya, kode download seperti pada receiver-diprakarsai kasus, sering dapat dilakukan anonim. Selain itu, server umumnya tidak tertarik pada sumber daya klien. Sebaliknya, kode migrasi ke klien dilakukan hanya untuk meningkatkan clientside kinerja. Untuk itu, hanya sejumlah terbatas sumber daya perlu dilindungi, seperti memori dan koneksi jaringan. Kami kembali untuk mengamankan kode migrasi luas di Chap. 8.

Dalam kasus mobilitas yang lemah, juga membuat perbedaan jika kode bermigrasi adalah dieksekusi oleh proses target, atau apakah proses yang terpisah dimulai. Misalnya, Java applet hanya didownload oleh browser Web dan dieksekusi di browser address space. Keuntungan dari pendekatan ini adalah bahwa tidak ada kebutuhan untuk memulai proses yang terpisah, sehingga menghindari komunikasi di mesin target. Kelemahan utama adalah bahwa proses sasaran perlu dilindungi berbahaya atau eksekusi kode sengaja. Solusi sederhana adalah untuk membiarkan sistem operasi mengurus hal itu dengan menciptakan proses yang terpisah untuk mengeksekusi kode bermigrasi.

Perhatikan bahwa solusi ini tidak memecahkan masalah sumber daya-akses disebutkan di atas. Mereka masih harus ditangani. Alih-alih bergerak proses yang berjalan, juga disebut sebagai proses migrasi, mobilitas yang kuat juga dapat didukung oleh kloning jarak jauh. Berbeda dengan memproses migrasi, kloning menghasilkan salinan persis dari proses aslinya, tapi sekarang berjalan pada mesin yang berbeda. Proses kloning dijalankan secara paralel dengan aslinya proses. Dalam sistem UNIX, kloning jarak jauh terjadi dengan forking dari sebuah proses anak dan membiarkan anak itu melanjutkan mesin remote. Manfaat dari kloning bahwa model mirip dengan salah satu yang telah digunakan dalam berbagai aplikasi. Satu-satunya perbedaan adalah bahwa proses kloning dijalankan pada mesin yang berbeda.

Dalam pengertian ini, migrasi dengan kloning adalah cara sederhana untuk meningkatkan transparansi distribusi.

3.4.2 Migrasi dan Sumber Daya Lokal

Sejauh ini, hanya migrasi kode dan segmen eksekusi telah diambil
diperhitungkan. Segmen sumber daya memerlukan beberapa perhatian khusus. yang sering membuat kode migrasi begitu sulit adalah bahwa segmen sumber daya tidak selalu bisa hanya ditransfer bersama dengan segmen lainnya tanpa berubah. Misalnya, misalkan proses memegang referensi ke port TCP tertentu di mana itu berkomunikasi dengan lainnya (remote) proses. Seperti referensi diadakan di nya sumber daya segmen. Ketika proses bergerak ke lokasi lain, maka harus menyerah pelabuhan dan meminta yang baru di tempat tujuan. Dalam kasus lain, mentransfer referensi tidak perlu menjadi masalah. Sebagai contoh, referensi ke sebuah file dengan sarana URL absolut akan tetap berlaku terlepas dari mesin mana proses yang memegang URL berada.

Untuk memahami implikasi bahwa migrasi kode memiliki pada segmen sumber daya, Fuggetta et al. (1998) membedakan tiga jenis proses-ke-sumber daya bindings. Pengikatan terkuat adalah ketika proses mengacu pada sumber daya dengan identifier nya. Dalam hal ini, proses ini membutuhkan sumber daya yang tepat direferensikan, dan tidak ada lain. Salah satu contoh seperti yang mengikat menurut pengenal adalah ketika proses menggunakan sebuah VRL untuk merujuk ke situs Web tertentu atau ketika mengacu ke server FRP dengan cara yang server alamat Internet. Pada baris yang sama penalaran, referensi untuk komunikasi lokal titik akhir juga menyebabkan mengikat menurut pengenal.

Sebuah bentuk yang lebih lemah dari proses-ke-sumber daya mengikat adalah ketika hanya nilai sumber daya dibutuhkan. Dalam hal ini, pelaksanaan proses tidak akan terpengaruh jika sumber daya lain yang akan memberikan nilai yang sama. Sebuah contoh khas mengikat dengan nilai adalah ketika program bergantung pada perpustakaan standar, seperti untuk pemrograman di C atau Java. Perpustakaan tersebut harus selalu tersedia secara lokal, namun mereka lokasi yang tepat dalam sistem file lokal mungkin berbeda antara situs. Bukan spesifik file, namun isinya sangat penting untuk pelaksanaan yang tepat dari proses.

Akhirnya, bentuk terlemah dari mengikat adalah ketika proses menunjukkan perlu hanya sumber daya dari jenis tertentu. Ini mengikat menurut jenis dicontohkan oleh referensi lokal perangkat, seperti monitor, printer, dan sebagainya.

Ketika migrasi kode, kita sering perlu mengubah referensi ke sumber daya,
tetapi tidak dapat mempengaruhi jenis proses-ke-sumber daya yang mengikat. Jika, dan persis bagaimana referensi harus diubah, tergantung pada apakah sumber daya yang dapat dipindahkan bersama dengan kode untuk mesin target. Lebih khusus lagi, kita perlu mempertimbangkan sumber daya-ke-mesin binding, dan membedakan kasus-kasus berikut. Lajang sumber daya dapat dengan mudah dipindahkan antara mesin yang berbeda, dan biasanya (data) file terkait hanya dengan program yang akan bermigrasi. Sebaliknya, memindahkan atau menyalin sumber daya diikat dimungkinkan, tetapi hanya pada relatif biaya tinggi. Contoh umum sumber daya diikat adalah database lokal dan menyelesaikan situs web. Meskipun sumber daya tersebut, dalam teori, tidak tergantung pada mesin mereka saat ini, seringkali tidak layak untuk memindahkan mereka ke lingkungan lain. Akhirnya, sumber daya tetap erat terikat ke mesin tertentu atau lingkungan dan tidak dapat dipindahkan. Sumber daya tetap sering perangkat lokal. contoh lain dari sumber daya tetap merupakan titik akhir komunikasi lokal.

Menggabungkan tiga jenis proses-ke-sumber daya binding, dan tiga jenis sumber daya ke-mesin binding, mengarah ke sembilan kombinasi yang kita perlu mempertimbangkanketika melakukan migrasi kode. Ini sembilan kombinasi ditunjukkan pada Gambar. 3-19. Mari kita pertama mempertimbangkan kemungkinan saat proses terikat ke sumber daya dengan identifier. Ketika sumber daya yang terikat, biasanya cara terbaik untuk memindahkannya bersama dengan kode bermigrasi. Namun, ketika sumber daya yang dimiliki oleh proses lainnya, alternatif adalah untuk membentuk suatu referensi global, yaitu acuan yang dapat lintas batas mesin. Salah satu contoh referensi adalah URL. Ketika sumber daya yang diikat atau tetap, solusi terbaik adalah juga untuk menciptakan sebuah referensi global.

Process-to-resource binding

	Unattached	Fastened	Fixed
By identifier By value By type	MV (or GR) CP ( or MV, GR) RB (or GR, CP)	GR (or MV) GR (or CP) RB (or GR, CP)	GR GR RB (or GR)

Gambar 3-14. Tindakan yang akan diambil sehubungan dengan referensi ke lokal
sumber daya ketika bermigrasi kode ke mesin lain

            Penting untuk menyadari bahwa membangun referensi global mungkin lebih dari hanya memanfaatkan URL, dan bahwa penggunaan seperti referensi kadang-kadang prohibitively mahal. Perhatikan, misalnya, sebuah program yang menghasilkan berkualitas tinggi gambar untuk workstation multimedia khusus. Fabrikasi gambar berkualitas tinggi secara real time adalah tugas menghitung-intensif, untuk alasan program mungkin pindah ke server menghitung performa tinggi. Membangun referensi global untuk workstation multimedia berarti menyiapkan jalur komunikasi antara menghitung server dan workstation. Selain itu, ada proses yang signifikan terlibat di kedua server dan workstation untuk memenuhi kebutuhan bandwidth mentransfer gambar. Hasil bersih mungkin bahwa memindahkan program ke server menghitung bukanlah ide yang bagus, hanya karena biaya global referensi terlalu tinggi.

            Contoh lain di mana membangun referensi global tidak selalu bahwa
mudah adalah ketika melakukan migrasi suatu proses yang memanfaatkan akhir komunikasi lokal titik. Dalam hal ini, kita berhadapan dengan sumber daya tetap yang prosesnya terikat oleh pengenal. Pada dasarnya ada dua solusi. Salah satu solusinya adalah dengan membiarkan proses mengatur koneksi ke mesin sumber setelah itu telah bermigrasi dan menginstal proses yang terpisah pada mesin sumber yang hanya meneruskan semua masukpesan. Kelemahan utama dari pendekatan ini adalah bahwa setiap kali mesin sumber malfungsi, komunikasi dengan proses bermigrasi mungkin gagal. Alternatif solusi adalah memiliki semua proses yang berkomunikasi dengan migrasi yang Proses, mengubah referensi global mereka, dan mengirim pesan ke komunikasi baru titik akhir di mesin target.

            Situasi ini berbeda ketika berhadapan dengan binding dengan nilai. Perhatikan dulusumber daya tetap. Kombinasi dari sumber daya tetap dan  mengikat dengan nilai terjadi, misalnya, ketika proses mengasumsikan memori yang dapat dibagi antara proses. Membangun referensi global dalam hal ini akan berarti bahwa kita perlu menerapkan bentuk didistribusikan memori bersama. Dalam banyak kasus, hal ini tidak benar-benar layak atau efisien solusi.

            Sumber daya mengikatkan yang disebut oleh nilai mereka, biasanya runtime perpustakaan. Biasanya, salinan sumber daya tersebut tersedia pada target mesin, atau harus disalin sebelum migrasi kode terjadi. Membangun referensi global adalah alternatif yang lebih baik ketika sejumlah besar data adalah untuk disalin, yang mungkin terjadi dengan kamus dan tesaurus dalam pengolahan teks sistem.

            Kasus paling mudah adalah ketika berhadapan dengan sumber daya terikat. Solusi terbaik adalah untuk menyalin (atau memindahkan) sumber daya untuk tujuan baru, kecuali dibagi oleh jumlah proses. Dalam kasus terakhir, mendirikan referensi global adalah satu-satunya option.

Kasus terakhir yang berhubungan dengan binding menurut jenis. Terlepas dari sumber daya-mesin untuk- mengikat. solusi yang jelas adalah untuk rebind proses untuk lokal yang tersedia sumber daya dari jenis yang sama. Hanya ketika seperti sumber daya tidak tersedia, akan kita perlu menyalin atau memindahkan yang asli ke tujuan baru, atau membentuk sebuah dunia referensi.

1.4.3   Migrasi dalam Sistem Heterogen

Sejauh ini, kami telah diam-diam mengasumsikan bahwa kode bermigrasi dapat dengan mudah dieksekusi di mesin target. Asumsi ini adalah dalam rangka ketika berhadapan dengan homogen sistem. Secara umum, bagaimanapun, sistem terdistribusi dibangun pada heterogen
koleksi platform, masing-masing memiliki sistem operasi mereka sendiri dan
arsitektur mesin. Migrasi dalam sistem tersebut mensyaratkan bahwa setiap platform adalah
didukung, yaitu, bahwa segmen kode dapat dijalankan pada platform masing-masing,
mungkin setelah mengkompilasi ulang sumber aslinya. Juga, kita perlu memastikan bahwa
segmen eksekusi dapat benar terwakili di setiap platform.

Masalah bisa agak berkurang ketika berhadapan hanya dengan mobilitas yang lemah.
Dalam hal ini, pada dasarnya tidak ada informasi runtime yang perlu ditransfer
antara mesin, sehingga cukup untuk mengkompilasi kode sumber, tapi menghasilkan yang berbeda kode segmen, satu untuk setiap platform target potensial.

Dalam kasus mobilitas yang kuat, masalah utama yang perlu diselesaikan adalah
mentransfer dari segmen eksekusi. Masalahnya adalah bahwa segmen ini sangat
tergantung pada platform di mana proses sedang dieksekusi. Bahkan, hanya
ketika mesin target memiliki arsitektur yang sama dan berjalan persis sistem operasi yang sama, apakah mungkin untuk bermigrasi segmen eksekusi tanpa harus mengubahnya. Segmen eksekusi berisi data yang bersifat pribadi untuk proses, saat ini stack, dan program counter. Tumpukan sebagian akan terdiri dari data sementara, seperti nilai-nilai variabel lokal, tetapi juga dapat berisi tergantung platform informasi seperti nilai register. Pengamatan penting adalah bahwa jika kita dapat menghindari setelah eksekusi tergantung pada platform-data spesifik, akan lebih mudah untuk mentransfer segmen ke mesin yang berbeda, dan melanjutkan eksekusi di sana.

Sebuah solusi yang bekerja untuk bahasa prosedural seperti C dan Java ditunjukkan pada Gambar. 3-10 dan bekerja sebagai berikut. Migrasi kode dibatasi untuk titik-titik tertentu di pelaksanaan program. Secara khusus, migrasi dapat terjadi hanya bila
subroutine selanjutnya disebut. Subrutin adalah sebuah fungsi dalam C, sebuah metode di Jawa, dan sebagainya. Sistem runtime mempertahankan salinan sendiri dari tumpukan program, tapi dengan cara-mesin independen. Kami mengacu pada salinan ini sebagai tumpukan migrasi. Tumpukan migrasi diperbarui ketika subrutin ini disebut, atau ketika eksekusi kembali dari subrutin.

Ketika subrutin ini disebut, sistem runtime marsekal data yang memiliki
telah didorong ke stack sejak panggilan terakhir. Data ini mewakili nilai-nilai lokal
variabel, bersama dengan nilai-nilai parameter untuk subrutin yang baru dipanggil. Itu
Data mengerahkan kemudian didorong ke stack migrasi, bersama dengan identifier
untuk subroutine disebut. Selain itu, alamat di mana eksekusi harus terus
ketika kembali dari pemanggil subrutin didorong dalam bentuk label melompat
ke tumpukan migrasi juga.

Jika migrasi kode terjadi pada titik di mana subrutin dipanggil, sistem runtime pertama marsekal semua program-spesifik data global membentuk bagian dari eksekusi segmen.Mesin-data spesifik diabaikan, serta arus stack. Data mengerahkan akan ditransfer ke tujuan, bersama dengan migrasi stack. Selain itu, tujuan beban segmen kode yang sesuai mengandung binari cocok untuk arsitektur mesin dan sistem operasi. Itu Data mengerahkan milik segmen eksekusi yang unmarshaled, dan setumpuk runtime baru dibangun oleh unmarshaling tumpukan migrasi. Eksekusi dapat kemudian dilanjutkan dengan hanya memasukkan subroutine yang dipanggil pada awal situs.

Jelas bahwa pendekatan ini bekerja hanya jika compiler menghasilkan kode untuk
memperbarui tumpukan migrasi setiap kali subrutin yang masuk atau keluar. Compiler
juga menghasilkan label dalam kode pemanggil memungkinkan kembali dari subrutin
untuk diimplementasikan sebagai lompatan (mesin-independent). Selain itu, kami juga membutuhkan cocok runtime sistem. Namun demikian, ada sejumlah sistem yang memiliki
berhasil mengeksploitasi teknik. Misalnya, Dimitrov dan Rego (1998) menunjukkan bagaimana migrasi C / C + + program dalam sistem heterogen dapat didukung
dengan sedikit memodifikasi bahasa, dan hanya menggunakan preprocessor untuk menyisipkan kode yang diperlukan untuk mempertahankan stack migrasi.

Masalah yang berasal dari heterogenitas dalam banyak hal sama dengan
orang portabilitas. Tidak mengherankan, solusi juga sangat mirip. Misalnya,
pada akhir tahun 1970-an, solusi sederhana untuk mengurangi banyak masalah
Pascal port ke mesin yang berbeda adalah untuk menghasilkan mesin-independen antara
kode untuk mesin virtual abstrak (Barron, 1981). Bahwa mesin, dari
Tentu saja, perlu untuk diterapkan pada banyak platform, tetapi kemudian akan memungkinkan Program pascal untuk dijalankan di mana saja. Meskipun ide sederhana ini secara luas digunakan selama beberapa tahun, tidak pernah benar-benar tertangkap sebagai solusi umum untuk portabilitas masalah untuk bahasa lain, terutama C.

Sekitar 20 tahun kemudian, kode migrasi dalam sistem heterogen sedang
diserang oleh bahasa scripting dan bahasa yang sangat portabel seperti Jawa. Semua
solusi tersebut memiliki kesamaan bahwa mereka bergantung pada mesin virtual yang baik
langsung menafsirkan kode sumber (seperti dalam kasus bahasa scripting), atau sebaliknya
menafsirkan kode menengah dihasilkan oleh kompilator (seperti di Jawa). Berada di
tempat yang tepat pada waktu yang tepat juga penting untuk pengembang bahasa.

Satu-satunya kelemahan serius dari pendekatan virtual-mesin adalah bahwa kita
umumnya terjebak dengan bahasa tertentu, dan sering tidak satu yang telah digunakan
sebelumnya. Untuk alasan ini, penting bahwa bahasa untuk mobilitas menyediakan antarmuka dengan bahasa yang ada.

1.4.4    Contoh: Agen D'

Untuk menggambarkan migrasi kode, sekarang mari kita melihat platform middleware
yang mendukung berbagai bentuk migrasi kode. Agen D'sebelumnya disebut Agen
Tcl, adalah sebuah sistem yang dibangun di sekitar konsep agen. Seorang agen di D'Agen
adalah sebuah program yang dapat bermigrasi antara mesin dalam sistem heterogen. Di sini,
kita berkonsentrasi hanya pada kemampuan migrasi Agen D', dan kembali ke
lebih umum diskusi tentang agen perangkat lunak pada bagian berikutnya. Juga, kita mengabaikan keamanan sistem dan menunda pembahasan lebih lanjut untuk Chap. 8. Informasi lebih lanjut pada Agen D'dapat ditemukan dalam (Gray, 1996b;. Kotz et al, 1997).
Sekilas Migrasi Kode di D'Agen Seorang agen di D'Agen adalah sebuah program yang dapat bermigrasi antara berbaga mesin. Pada prinsipnya, program dapat ditulis dalam bahasa apapun, asalkan mesin target dapat mengeksekusi kode bermigrasi. Dalam prakteknya, ini berarti bahwa program-program Agen di D'ditulis dalam bahasa ditafsirkan, terutama, Alat
Komando Bahasa, yaitu, Tcl (Ousterhout, 1994), Java, atau Scheme (Rees dan
Clinger, 1986). Menggunakan hanya bahasa ditafsirkan membuatnya lebih mudah untuk mendukung sistem heterogen.

Sebuah program, atau agen, dijalankan dengan proses menjalankan juru bahasa untuk
bahasa yang program ini ditulis. Mobilitas didukung dalam tiga yang berbeda
cara: pengirim yang diprakarsai mobilitas yang lemah, mobilitas yang kuat dengan proses migrasi, dan kuat mobilitas dengan kloning proses.

Lemahnya mobilitas diimplementasikan dengan cara perintah agent3submit. Sebuah identifier dari mesin target diberikan sebagai parameter, serta script yang akan dieksekusi pada mesin itu. Sebuah skrip hanyalah urutan instruksi.

Script ditransfer ke esin m sasaran bersama dengan definisi prosedur
dan salinan dari variabel yang mesin target harus mengeksekusi script.
Pada mesin target, proses yang berjalan juru tepat subse Pada mesin target, proses yang berjalan penafsir yang sesuai kemudian mulai menjalankan script. Dalam hal alternatif untuk migrasi kode yang disebutkan dalam Gambar. 3-8, D'Agen sehingga memberikan dukungan untuk pengirim-diprakarsai lemah mobilitas, di mana kode bermigrasi dijalankan dalam proses terpisah.

Untuk memberikan contoh mobilitas lemah di D'Agen, Gambar. 3-11 menunjukkan bagian dari sederhana Tcl agen yang mengajukan naskah ke mesin remote. Di agen, prosedur
faktorial mengambil parameter tunggal dan mengevaluasi ekspresi rekursif
yang menghitung faktorial dari nilai parameter. Jumlah variabel dan
Mesin diasumsikan benar diinisialisasi (misalnya, dengan meminta pengguna untuk nilai-nilai), setelah agen panggilan agent3submit. Script faktorial $ nomor dikirim ke mesin target disebut dengan mesin variabel, bersama dengan deskripsi prosedur faktorial dan nilai awal dari jumlah variabel.D'Agen otomatis mengatur bahwa hasil dikirim kembali ke agen. Panggilan Untuk agent3receive menetapkan bahwa agen mengirimkan diblokir sampai hasil
perhitungan telah diterima.

Sender-diprakarsai mobilitas yang kuat juga didukung, baik dalam bentuk proses
migrasi dan proses kloning. Untuk bermigrasi agen berjalan, agen panggilan agent3jump menentukan mesin target yang harus bermigrasi. Ketika agent3jump disebut, pelaksanaan agen pada mesin sumber ditangguhkan dan sumber daya segmennya, segmen kode, dan segmen eksekusi yang mengerahkan menjadi pesan yang kemudian dikirim ke mesin target. Setibanya itu pesan, sebuah proses baru menjalankan interpreter yang tepat dimulai. Proses
unmarshals pesan dan berlanjut pada instruksi setelah panggilan sebelumnya untuk agent3jump. Proses yang menjalankan agen pada mesin sumber, keluar.
Contoh migrasi zat diberikan pada Gambar. 3-12, yang menunjukkan disederhanakan
versi agen yang tahu mana pengguna sedang login dengan mengeksekusi
UNIX perintah yang pada setiap host. Perilaku agen diberikan
oleh semua prosedur 3users. Ia memelihara daftar pengguna yang awalnya kosong. Itu
set host yang harus mengunjungi diberikan oleh mesin parameter. Agen
melompat ke setiap host, menempatkan hasil yang mengeksekusi dalam pengguna variabel, dan menambahkan bahwa ke dalam daftar. Dalam program utama, agen dibuat pada saat mesin dengan penyerahan, yaitu, dengan menggunakan mekanisme yang sebelumnya dibahas untuk lemah mobilitas. Dalam hal ini, agent3submit diminta untuk menjalankan script
semua 3users $ mesin dan diberikan prosedur dan mengatur semesta alam sebagai parameter tambahan.

Akhirnya, proses kloning didukung oleh sarana perintah agent3fork.
Perintah ini berperilaku hampir sama dengan agent3jump, kecuali bahwa proses
menjalankan agen di mesin sumber hanya berlanjut dengan instruksi berikut
nya panggilan ke agent3fork. Seperti operasi garpu di UNIX, agent3fork kembali
nilai dimana pemanggil dapat memeriksa apakah itu adalah versi kloning
(Sesuai dengan anak'''' di UNIX), atau pemanggil asli (yaitu, orang tua'''').
Implementasi Masalah Untuk menjelaskan beberapa rincian implementasi internal, pertimbangkan agen yang telah ditulis dalam Tcl. Secara internal, D'Agen sistem terdiri dari lima lapisan, seperti yang ditunjukkan pada Gambar. 3-13. Lapisan terendah adalah sebanding dengan soket Berkeley di arti bahwa ia menerapkan antarmuka umum untuk fasilitas komunikasi jaringan yang mendasarinya. Dalam Agen D', diasumsikan bahwa sistem yang mendasari menyediakan fasilitas untuk menangani pesan TCP dan e-mail.

Gambar 3-13. Arsitektur dari sistem Agen D'.

Lapisan berikutnya terdiri dari sebuah server yang berjalan pada setiap mesin di mana D'Agen agen mengeksekusi. Server bertanggung jawab untuk agen, otentikasi manajemen,
dan manajemen komunikasi antara agen. Untuk yang terakhir, server
memberikan pengenal lokasi-unik untuk setiap agen. Menggunakan alamat jaringan
server, setiap agen kemudian dapat disebut oleh pasangan-(alamat, lokal-id). Ini
tingkat rendah Nama digunakan untuk mengatur komunikasi antara dua agen.

Lapisan ketiga adalah jantung dari sistem Agen D', dan terdiri dari
bahasa-independen inti yang mendukung model dasar agen. Misalnya,
Lapisan ini berisi implementasi untuk memulai dan mengakhiri agen, implementasi dari
operasi migrasi berbagai dan fasilitas untuk komunikasi interagent.
Jelas, inti beroperasi erat dengan server, namun, berbeda dengan server, adalah
tidak bertanggung jawab untuk mengelola koleksi agen berjalan pada mesin yang sama.

Lapisan keempat terdiri dari penerjemah, satu untuk setiap bahasa yang didukung oleh
D'Agen. Interpreter Masing-masing terdiri dari komponen untuk interpretasi bahasa,
modul keamanan, sebuah antarmuka untuk lapisan inti, dan modul yang terpisah untuk menangkap keadaan agen berjalan. Ini modul terakhir sangat penting untuk mendukung kuat
mobilitas, dan dibahas secara lebih rinci di bawah ini.

Lapisan tingkat tertinggi terdiri dari agen yang ditulis di salah satu didukung
bahasa. Setiap agen di D'Agen dieksekusi oleh proses yang terpisah. Misalnya,
ketika agen berpindah ke mesin A, server ada garpu proses yang
akan mengeksekusi penerjemah yang tepat untuk agen migrasi. Proses baru
kemudian diserahkan keadaan agen migrasi, setelah itu berlanjut di mana Agen sebelumnya tinggalkan. Server melacak proses itu diciptakan menggunakan pipa lokal, sehingga dapat melewati panggilan masuk ke proses yang sesuai.

Bagian yang lebih sulit dalam pelaksanaan Agen D', adalah menangkap
keadaan sebuah negara yang menjalankan agen dan pengiriman ke komputer lain. Dalam kasus Tcl, keadaan agen terdiri dari bagian-bagian yang ditunjukkan pada Gambar. 3-14. Pada dasarnya, ada empat tabel yang berisi definisi global variabel dan skrip, dan dua
tumpukan untuk melacak status eksekusi.

Ada meja untuk menyimpan variabel global yang dibutuhkan oleh penerjemah. Untuk
Sebagai contoh, mungkin ada event handler mengatakan penafsir yang prosedur untuk panggilan saat pesan dari agen tertentu tiba. Seperti (event, handler)-pair adalah
disimpan dalam tabel interpreter. Meja lain berisi variabel sistem global untuk
menyimpan kode kesalahan, kesalahan string, kode hasil, hasil string, dll Ada juga
terpisah tabel yang berisi semua user-defined variabel program global. Akhirnya, sebuah
tabel terpisah berisi definisi dari prosedur yang berhubungan dengan agen.

Definisi-definisi prosedur perlu untuk bermigrasi bersama dengan agen untuk memungkinkan interpretasi pada mesin target. Bagian yang lebih menarik yang berkaitan dengan migrasi agen adalah dua tumpukan oleh yang account yang akurat disimpan dari status pelaksanaan aktual dari agen. Pada dasarnya, agen dianggap sebagai serangkaian perintah Tcl, mungkin tertanam dalam konstruksi seperti loop, laporan kasus, dan sebagainya. Selain itu, perintah dapat dikelompokkan ke dalam prosedur. Seperti biasa untuk setiap bahasa ditafsirkan, suatu Agen dijalankan perintah dengan perintah.

Pertama mempertimbangkan apa yang terjadi ketika perintah Tcl dasar dijalankan, yaitu, perintah yang bukan merupakan panggilan ke prosedur yang ditetapkan pengguna. Penafsir mem-parsing perintah dan membangun rekor yang akan didorong ke apa yang disebut perintah stack. Seperti catatan berisi semua bidang yang diperlukan untuk benar-benar melaksanakan perintah, seperti nilai-nilai parameter, pointer ke sebuah prosedur pelaksanaan perintah, dan sebagainya. Rekor ini kemudian didorong ke stack, setelah itu
dapat diserahkan kepada komponen yang bertanggung jawab untuk benar-benar melaksanakan perintah. Dengan kata lain, tumpukan perintah memberikan rekening yang tepat dari saat ini pelaksanaan status agen. Tcl juga mendukung user-defined prosedur. Selain tumpukan perintah, lingkungan runtime Agen D'melacak setumpuk catatan aktivasi, juga disebut frame panggilan. Sebuah bingkai panggilan di D'Agen berisi tabel variabel lokal untuk prosedur, bersama dengan nama-nama dan nilai-nilai parameter dengan prosedur yang dipanggil. Sebuah bingkai panggilan dibuat hanya sebagai hasil dari prosedur panggilan, dan dengan demikian berhubungan dengan perintah prosedur-panggilan sebagai didorong ke perintah tumpukan. Bingkai panggilan menyimpan referensi untuk perintah yang terkait.
Sekarang perhatikan apa yang terjadi, misalnya, ketika seorang agen panggilan
agent3jump, dimana agen berpindah ke komputer lain. Pada saat itu, keadaan lengkap
dari agen seperti yang baru saja dijelaskan mengerahkan menjadi serangkaian byte. Dengan kata lain, semua empat meja dan dua tumpukan disatukan ke dalam array tunggal byte dan dikirim ke mesin target. D'Agen server pada mesin target selanjutnya membuat proses baru menjalankan interpreter Tcl. Proses yang diserahkan data mengerahkan, yang kemudian unmarshals ke negara agen berada di ketika itu disebut agent3jump. Dengan hanya muncul perintah dari atas perintah tumpukan, eksekusi berlanjut persis di mana itu telah meninggalkan off.

3.5  Agen Perangkat Lunak

Menurut Nwana, konsep agent sudah dikenal lama dalam bidang AI, tepatnya dikenalkan oleh seorang peneliti bernama Carl Hewitt dengan concurrent actor model-nya pada tahun 1977. Dalam modelnya Hewitt mengemukakan teori tentang suatu obyek yang yang dia sebut actor, yang mempunyai karakteristik menguasai dirinya sendiri, interaktif, dan bisa merespon pesan yang datang dari lain obyek sejenis. Dari berbagai penelitian berhubungan dengan hal diatas, kemudian lahirlah cabang ilmu besar yang merupakan turunan dari AI yaitu Distributed Artificial Intelligence (DAI), yang antara lain membawahi bidang penelitian,Distributed Problem Solving (DPS), Parallel Artificial Intelligence(PAI), dan Multi Agent System (MAS).

Masa ini terkenal dengan masa generasi pertama penelitiansoftware agent, yaitu periode 1970-1990. Pada umumnya konsentrasi penelitian pada periode ini tertuju ke arah: pemodelan internal agent secara simbolik, isu-isu makro mengenai interaksi, koordinasi, dan komunikasi antar agent dalam kerangka MAS. Tujuan utamanya adalah untuk menganalisa, mendesain, dan mengintegrasikan system dalam kerangka agent yang bisa berkolaborasi satu dengan yang lain. Berbagai macam penelitian yang dilakukan pada generasi pertama (1970-1990) itu terangkum secara lengkap dan terorganisir dengan baik dalam buku-buku yang dieditori oleh Bond dan Gasser, Gasser dan Huns, dan Chaib-draa. Kemudian masa generasi kedua dari penelitian agent adalah periode tahun 1990 sampai saat ini. Konsentrasi penelitian pada periode ini khususnya adalah pada: pengembangan dan penelitian teori agent (agent theory), arsitektur agent (agent architecture) dan bahasa pemrograman yang digunakan (agent language). Terangkum dengan baik dalam buku-buku dan makalah-makalah oleh Wooldridge dan Jennings.

Sejauh ini, kita telah melihat proses dari sudut yang sangat berbeda. Pertama, kami berkonsentrasi pada salah satu masalah penting, yaitu thread (s) dari kontrol dalam proses. Dari perspektif komunikasi, kami melihat lebih dekat pada organisasi umum dari klien serta server. Akhirnya, kami menganggap mobilitas program dan proses. Pandangan ini lebih atau kurang independen pada proses dalam apa yang sering disebut sebagai agen perangkat lunak : unit otonom mampu melakukan tugas bekerja sama dengan lainnya.
Agen yang memainkan peran yang semakin penting dalam sistem terdistribusi. Namun, sangat mirip dengan fakta bahwa ada hanya gagasan intuitifdari proses itu, agen perangkat lunak belum didefinisikan secara tegas..

3.5.1 Software dalam Sistem Terdistribusi

Sesuai dengan deskripsi yang diberikan dalam (Jennings dan Woolridge, 1998), kita mendefinisikan agen perangkat lunak sebagai proses otonom yang mampu bereaksi dan memulai perubahan, lingkungannya, kemungkinan bekerja sama dengan pengguna dan agen lainnya. Fitur yang membuat agen lebih dari sekedar proses adalah kemampuan untuk bertindak sendiri, dan khususnya untuk mengambil inisiatif mana yang sesuai.

Definisi tentang agen software agak luas, dan berbagai jenis proses dengan mudah bisa disebut agen. Alih-alih mencoba untuk datang ke definisi yang lebih baik, akan lebih masuk akal untuk melihat berbagai jenis agen. Sekali lagi, beberapa upaya dalam literatur telah dilakukan untuk mengembangkan taksonomi dari agen perangkat lunak, tetapi tampaknya sulit bagi peneliti untuk mencapai kesepakatan pada taksonomi tunggal.

Selain menjadi otonom, merupakan aspek penting dari agen adalah bahwa mereka juga harus mampu bekerja sama dengan agen lainnya. Kombinasi otonomi dan kerjasama mengarah ke kelas agen kolaboratif (Nwana, 1996). Seorang agen kolaboratif merupakan agen yang merupakan bagian dari sistem multiagen, di mana agen berusaha untuk mencapai beberapa tujuan bersama melalui kolaborasi. Sebuah aplikasi khas di mana agen-agen kolaboratif dapat digunakan adalah mengatur pertemuan. Setiap peserta diwakili oleh agen yang memiliki akses ke agenda pengguna pribadi. Mengingat semua kendala individu terhadap waktu, perjalanan, tempat, dan seterusnya, para agen yang terpisah akan berkolaborasi dalam mendirikan pertemuan. Dari perspektif pengembangan sistem terdistribusi, tepatnya mana informasi dipertukarkan, dan bagaimana yang diproses adalah kurang perhatian. Penting adalah bagaimana komunikasi terjadi. Kami kembali ke komunikasi interagent bawah.

Banyak penelitian juga memisahkan agen mobile dari jenis agen lainnya. Seorang agen mobile hanyalah agen memiliki kemampuan untuk bergerak di antara mesin yang berbeda. Dalam hal diskusi tentang migrasi kode di bagian sebelumnya, agen mobile sering membutuhkan dukungan untuk mobilitas yang kuat, meskipun hal ini tidak benar-benar diperlukan. Persyaratan untuk mobilitas yang kuat berasal dari fakta bahwa agen yang otonom dan aktif berinteraksi dengan lingkungannya. Pindah agen untuk komputer lain tidak dapat dilakukan tanpa mempertimbangkan kondisi pelaksanaannya. Namun, seperti yang ditunjukkan oleh sistem Agen D', kombinasi dari agen dan mobilitas yang lemah juga berguna. Perhatikan bahwa mobilitas adalah fitur dari agen pada umumnya dan tidak mengarah ke kelas eksklusif sendiri. Misalnya, masuk akal untuk berbicara tentang agen kolaboratif mobile. Sebuah contoh yang baik, penggunaan praktis agen mobile diberikan dalam (Brewington et al, 1999), di mana penulis menggambarkan bagaimana agen mobile yang digunakan untuk mengambil informasi didistribusikan di seluruh jaringan heterogen besar seperti internet.

Kemampuan untuk berkolaborasi dengan agen lain atau untuk bergerak di antara mesin yang berbeda adalah sistem sifat agen. Mereka menjelaskan kepada kita tentang apa yang agen dapat lakukan. Ketika mengambil melihat fungsi agen ini, kelas lain dapat dibedakan juga. Sebuah kelas umumnya diakui dibentuk oleh agen antarmuka, yang merupakan agen yang membantu pengguna akhir dalam penggunaan satu atau lebih aplikasi. Sebuah properti yang membedakan berlaku umum dari agen antarmuka, adalah bahwa ia telah belajar kemampuan (Maes, 1994; Nwana, 1996). Semakin sering berinteraksi dengan pengguna, bantuan yang lebih baik menjadi. Dalam konteks sistem terdistribusi, contoh agen antarmuka yang menarik adalah mereka yang mencari interaksi dengan agen bagi pengguna dalam komunitas yang sama. Misalnya, agen antarmuka khusus ada yang aktif mencari untuk membawa pembeli dan penjual bersama-sama. Dengan mendapatkan pemahaman yang semakin baik dari apa pemiliknya sedang mencari, atau ditawarkan, seperti agen antarmuka harus memperbaiki memilih kelompok teman sebaya yang tepat.

Terkait erat dengan agen antarmuka adalah agen informasi. Fungsi utama dari agen adalah untuk mengelola informasi dari berbagai sumber. Mengelola informasi meliputi pemesanan, penyaringan, menyusun, dan sebagainya. Apa yang membuat agen informasi penting dalam sistem terdistribusi, adalah bahwa mereka beroperasi pada informasi dari sumber-sumber fisik yang berbeda. Agen informasi stasioner biasanya beroperasi pada aliran data yang masuk. Misalnya, agen email mungkin mampu menyaring surat yang tidak diinginkan dari kotak surat pemiliknya, atau secara otomatis mendistribusikan surat masuk ke dalam mata pelajaran khusus sesuai kotak surat. Sebaliknya, agen informasi yang mobile umumnya berkeliaran jaringan atas nama pemilik mereka untuk mengumpulkan informasi yang diperlukan.

Singkatnya, agen sering dapat dicirikan oleh sejumlah properti. Perbedaan lebih lanjut antara agen yang dibuat dengan mengambil melihat bagaimana mereka benar-benar beroperasi dari perspective kecerdasan buatan.

Property	Common to all agents ?	Description
Otonomi	Ya	Bisa bertindak sendiri
Reaktif	Ya	Merespon tepat waktu terhadap perubahan dalam lingkungannya
Proaktif	Ya	Memulai tindakan yang mempengaruhi lingkungan
Komunikatif	Ya	Dapat bertukar informasi dengan pengguna dan agen lainnya
Continuous	No	Memiliki rentang hidup yang relative panjang
Mobile	No	Dapat bermigrasi dari satu situs ke situs lainnya
Adaptive	No	Mampu belajar

Some important properties by which different types of agents can be distinguished

3.5.2 Agen Teknologi

Setelah hanya gagasan tentang apa agen yang tidak benar-benar membantu jika tidak ada avalaible dukungan untuk benar-benar mengembangkan sistem agen. Suatu hal yang penting kemudian jika kita dapat mengisolasi komponen umumnya digunakan-agen dalam sistem terdistribusi, dan memasukkan komponen ke dalam, misalnya: middleware. Sebagai titik awal, Yayasan Agen Fisik Cerdas (FIPA) sedang mengembangkan model umum untuk agen perangkat lunak. Dalam model ini, agen terdaftar di, dan beroperasi di bawah rezim platform agen. Sebuah platform agen menyediakan layanan dasar yang dibutuhkan untuk setiap sistem multiagen. Fasilitas ini termasuk untuk membuat dan menghapus agen, fasilitas untuk mencari agen, dan fasilitas untuk komunikasi interagent.

Komponen manajemen agen melacak agen untuk platform terkait. Ini menyediakan fasilitas untuk membuat dan menghapus agen, tetapi juga untuk mencari titik akhir saat agen tertentu. Dalam hal ini, ia menyediakan layanan penamaan oleh pengenal global yang unik dipetakan ke titik akhir komunikasi lokal. Layanan nama dibahas secara rinci dalam bab berikutnya.

Ada juga layanan direktori terpisah lokal dimana agen dapat melihat apa yang agen lain pada platform tawarkan. Layanan direktori dalam model FIPA didasarkan pada penggunaan atribut. Apa artinya ini adalah bahwa agen menyediakan deskripsi layanan dalam hal nama atribut, bersama dengan nilai tertentu kepada agen itu. Ini sangat mirip dengan cara yang "halaman kuning" beroperasi. Layanan direktori dapat diakses oleh agen terpencil, yaitu agen yang berada pada platform agen yang berbeda.

The general model of an agent platform (adapted from FIPA, 1998)

Salah satu komponen penting dari sebuah platform agent dibentuk oleh saluran komunikasi agen, atau ACC untuk pendek. Dalam model yang paling untuk sistem multiagen, agen berkomunikasi dengan bertukar pesan. Model FIPA tidak terkecuali, dan memungkinkan sebuah kepedulian ACC dari semua komunikasi antara platform agen yang berbeda. Secara khusus, ACC bertanggung jawab untuk diandalkan dan memerintahkan point-to-point komunikasi dengan platform lain. Sebuah ACC hanya dapat diimplementasikan sebagai server mendengarkan port tertentu untuk pesan masuk yang akan diteruskan ke server lain atau agen yang merupakan bagian dari platform agen. Untuk menjamin interoperabilitas antara platform, komunikasi antara Accs pada platform yang berbeda berikut apa yang disebut internet. Inter-ORB Protocol (IIOP).

Agen Komunikasi Bahasa

Sejauh ini, hampir tak ada sesuatu khusus untuk platform agen. Perbedaan dengan pendekatan lain untuk sistem terdistribusi menjadi jelas ketika melihat jenis informasi yang agen benar-benar berkomunikasi. Komunikasi antara agen berlangsung melalui suatu protokol komunikasi aplikasi-tingkat, yang disebut sebagai bahasa komunikasi agen (ACL). Dalam sebuah ACL, pemisahan yang ketat dibuat antara tujuan pesan, dan isinya. Sebuah pesan hanya dapat memiliki sejumlah tujuan. Sebagai contoh, tujuan dari pesan dapat meminta penerima untuk menyediakan layanan tertentu. Demikian juga, pesan dapat memiliki tujuan untuk menanggapi pesan permintaan dikirim sebelumnya. Sebagai contoh lain, beberapa pesan dapat dikirim untuk menginformasikan penerima dari suatu peristiwa atau mengusulkan sesuatu dalam tindakan negosiasi. Beberapa purposeof pesan dalam ACL dikembangkan oleh FIPA

Message purpose	Description	Message Content
INFORM	Inform that a given proposition is true	Proposition
QUERY-IF	Query whether a given proposition is true	Proposition
QUERY-REF	Query for a given object	Expression
CFP	Ask for a proposal	Proposal Specifics
PROPOSE	Provide a proposal	Proposal
ACCEPT-PROPOSAL	Tell that a given proposa is accepted	Proposal ID
REJECT-PROPOSAL	Tell that a given proposal is rejected	Proposal ID
REQUEST	Request that an action be performed	Action Specification
SUBSCRIBE	Subscribe to an information source	Reference to source

Examples of different message types in the FIPA ACL (FIPA,1998), giving the purpose of a message, along with the description of the actual message content

Inti dari ACL adalah, tentu saja, bahwa agen pengirim dan penerima keduanya memiliki setidaknya pemahaman yang sama tentang tujuan pesan. Selain itu, tujuan dari pesan sering menentukan reaksi dari penerima. Sebagai contoh, ketika diminta untuk proposal melalui pesan memiliki CFP di header nya, penerima diharapkan untuk benar-benar merespon dengan proposal, yaitu pesan dengan tujuan USULAN. Dalam pengertian ini, ACL benar-benar mendefinisikan aa tingkat tinggi protokol komunikasi antara kumpulan agen.

Seperti protokol komunikasi yang paling, pesan ACL terdiri dari header dan konten yang sebenarnya. Header berisi bidang yang mengidentifikasi tujuan pesan, bersama dengan kolom untuk mengidentifikasi pengirim dan penerima. Juga seperti protokol komunikasi banyak, isi pesan dipisahkan dari, dan independen dari sisanya. Dengan kata lain, isi pesan diasumsikan khusus untuk agen berkomunikasi. ACL tidak meresepkan format atau bahasa di mana isi pesan diungkapkan.

Apa yang diperlukan kemudian, adalah bahwa informasi yang cukup diberikan untuk memungkinkan agen penerima untuk benar menafsirkan isi. Untuk itu, sebuah header pesan ACL juga dapat berisi kolom untuk mengidentifikasi bahasa atau skema pengkodean untuk konten. Pendekatan ini bekerja dengan baik asalkan pengirim dan penerima memiliki pemahaman yang sama bagaimana menafsirkan data, atau lebih tepatnya, simbol dalam pesan. Ketika tidak ada pemahaman umum seperti, lapangan tambahan kadang-kadang digunakan untuk mengidentifikasi pemetaan standar simbol artinya. Seperti pemetaan sering disebut sebagai ontologi.

Field	Value
Purpose	INFORM
Sender	max@http://fanclub-beatrix.royalty-spotters.nl:7239
Receiver	elke@iiop://royalty-watcher.uk:5623
Bahasa	Prolog
Ontology	Genealogy
Content	Female(beatrix),parent(Beatrix,Juliana,Bernhard)

. A simple example of a FIPA ACL message sent between two agents using prolog to express genealogy information

Untuk memberikan contoh sederhana, digunakan untuk menginformasikan agen tentang hubungan royalti Belanda. Untuk mengidentifikasi pengirim dan penerima agen, agen masing-masing memiliki nama yang terdiri dari beberapa komponen. Misalnya, max @ http://fanclub-beatrix.royalty-spotters.nl:7239 dapat digunakan untuk merujuk ke sebuah gent disebut max berada pada platform agen dengan nama DNS fanclub-beatrix.royalty-spotters.nl. Untuk berkomunikasi dengan agen, nama platform pertama harus diselesaikan oleh DNS ke alamat IP. Selanjutnya, nama menentukan bahwa komunikasi harus dilanjutkan dengan mengirimkan pesan HTTP ke server pada host yang mendengarkan nomor port 7239. Dalam contoh kita, agen max mengirimkan na pesan informasi untuk agen yang disebut elke, yang berada di sebuah platform bernama royalti-watcher.uk. Pesan harus dikirim menggunakan protokol IIOP dan dikirim ke nomor port 5623.

Bidang lain dalam pesan yang berhubungan dengan isinya. Bidang Bahasa menetapkan bahwa isi pesan dinyatakan sebagai serangkaian pernyataan Prolog, sedangkan bidang ontologi mengidentifikasi bahwa laporan keuangan tersebut Prolog harus semantik diartikan sebagai informasi silsilah. Akibatnya, agen menerima sekarang harus tahu bahwa pernyataan itu.
     Perempuan (Beatrix)            Berarti Beatrix adalah nama seorang wanita, sedangkan

     Induk (Beatrix, Juliana, Bernhard)   Berarti ibu Beatrix bernama Juliana dan bahwa ayah bernama Bernhard

   Definisi Software Agent

Di dalam kamus Webster’s New World Dictionary [Guralnik, 1983], agent didefinisikan sebagai:

1. Agent mempunyai kemampuan untuk melakukan suatu tugas/pekerjaan.
2. Agent melakukan suatu tugas/pekerjaan dalam kapasitas untuk sesuatu, atau untuk orang lain.

Didapat dari point-point diatas Caglayan mendefinisikansoftware agent sebagai suatu entitas software komputer yang memungkinkan user (pengguna) untuk mendelegasikan tugas kepadanya secara mandiri (autonomously).

Kemudian beberapa peneliti lain menambahkan satu point lagi, yaitu bahwa agent harus bisa berjalan dalam kerangka lingkungan jaringan (network environment). Definisi agent dari para peneliti lain pada hakekatnya adalah senada, meskipun ada yang menambahkan atribut dan karakteristik agent ke dalam definisinya.

    Karakteristik dan Atribut Software Agent

Untuk memperdalam pemahaman tentang software agent, fungsi, peran, dan perbedaan mendasar dikaitkan software program yang ada, berikut ini akan dijelaskan tentang beberapa atribute dan karakteristik yang dimiliki oleh software agent. Tentu tidak semua karakteristik dan atribut terangkum dalam satu agent. Pada hakekatnya daftar karakteristik dan atribut dibawah adalah merupakan hasil survey dari karakteristik yang dimiliki oleh agent-agent yang ada pada saat ini.

1. Autonomy

Agent dapat melakukan tugas secara mandiri dan tidak dipengaruhi secara langsung oleh user, agent lain ataupun oleh lingkungan (environment). Untuk mencapai tujuan dalam melakukan tugasnya secara mandiri, agent harus memiliki kemampuan kontrol terhadap setiap aksi yang mereka perbuat, baik aksi keluar maupun kedalam. Dan satu hal penting lagi yang mendukung autonomy adalah masalah intelegensi (intelligence) dari agent.

2. Intelligence, Reasoning, dan Learning

Setiap agent harus mempunyai standar minimum untuk bisa disebut agent, yaitu intelegensi (intelligence). Dalam konsep intelligence, ada tiga komponen yang harus dimiliki: internal knowledge base, kemampuan reasoning berdasar pada knowledge base yang dimiliki, dan kemampuan learning untuk beradaptasi dalam perubahan lingkungan.

3. Mobility dan Stationary

Khusus untuk mobile agent, dia harus memiliki kemampuan yang merupakan karakteristik tertinggi yang dia miliki yaitu mobilitas. Berkebalikan dari hal tersebut adalahstationary agent. Bagaimanapun juga keduanya tetap harus memiliki kemampuan untuk mengirim pesan dan berkomunikasi dengan agent lain.

4. Delegation

Sesuai dengan namanya dan seperti yang sudah kita bahas pada bagian definisi, agent bergerak dalam kerangka menjalankan tugas yang diperintahkan oleh user. Fenomena pendelegasian (delegation) ini adalah karakteristik utama suatu program disebut agent.

5. Reactivity

Karakteristik agent yang lain adalah kemampuan untuk bisa cepat beradaptasi dengan adanya perubahan informasi yang ada dalam suatu lingkungan (enviornment). Lingkungan itu bisa mencakup: agent lain, user, adanya informasi dari luar, dsb.

6. Proactivity dan Goal-Oriented

Sifat proactivity boleh dikata adalah kelanjutan dari sifat reactivity. Agent tidak hanya dituntut bisa beradaptasi terhadap perubahan lingkungan, tetapi juga harus mengambil inisiatif langkah penyelesaian apa yang harus diambil. Untuk itu agent harus didesain memiliki tujuan (goal) yang jelas, dan selalu berorientasi kepada tujuan yang diembannya (goal-oriented).

7. Communication and Coordination Capability

Agent harus memiliki kemampuan berkomunikasi dengan user dan juga agent lain. Masalah komunikasi dengan user adalah masuk ke masalah user interface dan perangkatnya, sedangkan masalah komunikasi, koordinasi, dan kolaborasi dengan agent lain adalah masalah sentral penelitian Multi Agent System (MAS). Bagaimanapun juga untuk bisa berkoordinasi dengan agent lain dalam menjalankan tugas, perlu bahasa standard untuk berkomunikasi. Tim Finin dan Yannis Labrou adalah peneliti software agent yang banyak berkecimpung dalam riset mengenai bahasa dan protokol komunikasi antar agent. Salah satu produk mereka adalahKnowledge Query and Manipulation Language (KQML). Kemudian masih berhubungan dengan ini komunikasi antar agent adalahKnowledge Interchange Format (KIF).

     Klasifikasi Software Agent Menurut Karakteristik Yang Dimiliki

Teknik klasifikasi agent menurut karakteristik dipelopori oleh Nwana. Menurut Nwana, agent bisa diklasifikasikan menjadi delapan berdasarkan pada karakteristiknya, yaitu :

1. Collaborative Agent

Agent yang memiliki kemampuan melakukan kolaborasi dan koordinasi antar agent dalam kerangka Multi Agent System (MAS).

2. Interface Agent

Agent yang memiliki kemampuan untuk berkolaborasi dengan user, melakukan fungsi monitoring danlearning untuk memenuhi kebutuhan user.

3. Mobile Agent

Agent yang memiliki kemampuan untuk bergerak dari suatu tempat ke tempat lain, dan secara mandiri melakukan tugas ditempat barunya tersebut, dalam lingkungan jaringan komputer.

4. Information dan Internet Agent

Agent yang memiliki kemampuan untuk menjelajah internet untuk melakukan pencarian, pemfilteran, dan penyajian informasi untuk user, secara mandiri. Atau dengan kata lain, memanage informasi yang ada di dalam jaringan Internet.

5. Reactive Agent

Agent yang memiliki kemampuan untuk bisa cepat beradaptasi dengan lingkungan baru dimana dia berada.

6. Hybrid Agent

Kita sudah mempunyai lima klasifikasi agent. Kemudian agent yang memiliki katakteristik yang merupakan gabungan dari karakteristik yang sudah kita sebutkan sebelumnya adalah masuk ke dalam hybrid agent.

7. Heterogeneous Agent System

Dalam lingkungan Multi Agent System(MAS), apabila terdapat dua atau lebih hybrid agent yang memiliki perbedaan kemampuan dan karakteristik, maka sistem MAS tersebut kita sebut dengan heterogeneous agent system.

   Klasifikasi Software Agent Menurut Lingkungan Dimana Dijalankan

Caglayan membuat suatu klasifikasi yang menarik mengenaiagent, yang berdasar kepada lingkungan (environment) dimanaagent dijalankan.

Dari sudut pandang dimana dijalankan, software agent bisa diklasifikasikan sebagai desktop agent, internet agent danintranet agent. Lebih jelasnya, daftar dibawah menguraikan klasifikasi tersebut secara mendetail.

1. Desktop Agent

Agent yang hidup dan bertugas dalam lingkunganPersonal Computer (PC), dan berjalan diatas suatu Operating System (OS). Termasuk dalam klasifikasi ini adalah:

• Operating System Agent
• Application Agent
• Application Suite Agent

2. Internet Agent

Agent yang hidup dan bertugas dalam lingkungan jaringan Internet, melakukan tugas memanage informasi yang ada di Internet. Termasuk dalam klasifikasi ini adalah:

• Web Search Agent
• Web Server Agent
• Information Filtering Agent
• Information Retrieval Agent
• Notification Agent
• Service Agent
• Mobile Agent

3. Intranet Agent

Agent yang hidup dan bertugas dalam lingkungan jaringan Intranet, melakukan tugas memanage informasi yang ada di Intranet. Termasuk dalam klasifikasi ini adalah:

• Collaborative Customization Agent
• Process Automation Agent
• Database Agent
• Resource Brokering Agent

   Bidang Ilmu dan Penelitian yang Terkait dengan SOftware Agent

Sudah menjadi hal yang diketahui umum bahwa masalahlearning, intelligence, dan juga proactivity serta reactivity adalah bidang garapan AI klasik. Kemudian penelitian dalam bidang DAI pada umumnya adalah berkisar ke masalah koordinasi, komunikasi dan kerjasama (cooperation) antar agent dalam Multi Agent System (MAS). Dengan perkembangan penelitian di bidangdistributed network dan communication system, membawa peran penting dalam mewujudkan agent yang mempunyai kemampuan mobilitas dan komunikasi dengan agent lain.

Pesatnya perkembangan penelitian tentang software agenttak lepas dari pengaruh bidang ilmu psikologi yang banyak mengupas agent secara teori dan filosofi, kemudian juga software engineering yang berperan dalam menyediakan metodologi analisa dan desain, serta implementasi dari software agent. Dan yang terakhir adalah bidang decision theory dengan kupasan tentang bagaimana agent harus menentukan strategi dalam menjalankan tugas secara mandiri (autonomously).

    Bahasa Pemrograman

Pada bagian ini akan dibahas tentang bahasa pemrograman yang banyak dipakai untuk tahap implementasi dari software agent. Bagaimanapun juga setiap bahasa pemrograman memiliki karakteristik sendiri sesuai dengan paradigma pemrograman yang dia anut. Sehingga pemakaian bahasa permrograman yang kita pakai akan menentukan keberhasilan dalam implementasi agent sesuai yang kita harapkan.

Beberapa peneliti memberikan petunjuk tentang bagaimana karakteristik bahasa pemrorgaman yang sebaiknya kita pakai. Petunjuk-petunjuk tersebut adalah:

·      Object-Orientedness: Karena agent adalah berhubungan dengan obyek, bahkan beberapa peneliti menganggap agent adalah obyek yang aktif, maka bagaimanapun juga agent harus diimplementasikan kedalam pemrorgaman yang berorientasi obyek (object-oriented programming language).

·      Platform Independence: Seperti sudah dibahas pada bagian sebelumnya, bahwa agent hidup dan berjalan diatas berbagai lingkungan. Sehingga idealnya bahasa pemrograman yang dipakai untuk implementasi adalah yang terlepas dari platform, atau dengan kata lain program tersebut harus bisa dijalankan di platformapapun (platform independence).

·      Communication Capability: Pada saat berinteraksi dengan agentlain dalam suatu lingkungan jaringan (network environment), tentu saja diperlukan kemampuan untuk melakukan komunikasi secara fisik. Sangat lebih baik seandaianya bahasa pemrograman mensupport pemrograman untuk network dan komunikasinya.

·      Security: Faktor keamanan (security) juga hal yang harus diperhatikan dalam memilih bahasa pemrorgaman untuk implementasi software agent. Terutama untuk mobil agent, diperlukan bahasa pemrograman yang mensupport level-level keamanan yang bisa membuat agent bergerak dengan aman.

·      Code Manipulation: Beberapa aplikasi software agent memerlukan manipulasi kode program secara runtime. Bahasa pemrograman untuk software agent sebaiknya juga harus bisa memberikan support terhadap masalah ini.

Ditarik dari beberapa petunjuk diatas, para peneliti merekomendasikan bahasa pemrograman berikut untuk mengimplementasikan software agent:

1. Java
2. Telescript

    Riset dan Aplikasi Software Agent

Ada dua tujuan dari survey tentang riset dan aplikasisoftware agent. Yang pertama adalah, untuk mengeidentifikasi sampai sejauh mana teknologi agent sudah diaplikasikan dengan memberikan pointer berupa contoh-contoh aplikasi sistem yang sudah ada. Yang kedua adalah, untuk memberikan gambaran ke depan, masalah-masalah apa yang sudah dan belum terpecahkan dan membuka peluang untuk mencoba mengaplikasikan teknologi agent ke masalah baru yang timbul. Jennings merangkumkan riset dan aplikasi software agent yang ada kedalam beberapa bidang. Disini kami akan mengupas beberapa riset dan aplikasi software agent dalam bidang industri, internet/bisnis, entertainment, medis, dan bidang pendidikan.

   Riset dan AplikasiSoftware Agent di Dunia Industri

Dewasa ini teknologi agent sudah diaplikasikan secara luas di dunia Industri. Bagaimanapun juga harus diakui bahwa secara sejarah penelitian, selain dunia Internet dan bisnis, teknologi agent banyak didesain untuk dimanfaatkan di bidang industri.

·      Manufacturing: Parunak mempelopori proyek penelitian yang dia sebut YAMS (Yet Another Manufacturing System), dimana dia berusaha mengaplikasikan protokol contract net untuk proses kontrol di manufacturing. Untuk mengatasi masalah kompleks dalam proses manufacturing, YAMS mengadopsi pendekatan MAS, dimana setiap pabrik dan komponen dari pabrik adalah direpresentasikan sebagai agent. Aplikasi lain yang menggunakan teknologi agent dalam area ini adalah: konfigurasi dan desain untuk product manufacturing, pendesainan secara kolaboratif, pengontrolan dan penjadwalan operasi manufacturing, dsb.

·      Process Control: Process control secara sistem merupakan sistem yang harus bisa bekerja secara mandiri dan bersifat reactive. Hal ini sesuai dengan karakteristik dari agent, sehingga bukan sesuatu yang mengejutkan kalau banyak muncul pengembangan aplikasiprocess control yang berbasis ke teknologi agent. Beberapa contoh penelitian dan aplikasi yang berada dalam area ini adalah: proyek ARCHON yang diaplikasikan untuk manajemen transportasi listrik dan kontrol untuk percepatan partikel, kemudian juga: pengontrolan iklim, pengontrolan spacecraft, dsb.

·      Telecommunications: Sistem telekomunikasi pada umumnya bergerak dalam skala besar, dan komponen-komponen telekomunikasi yang terhubung, terdistribusi dalam jaringan. Untuk itu diperlukan sistem monitoring dan manajemen dalam kerangkareal-time. Dengan semakin tingginya tingkat kompetisi untuk menyediakan sistem komunikasi yang terbaik, diperlukan pendekatan komputerisasi dan software paradigma yang sesuai. Disinilah teknologi agent diperlukan. Beberapa riset dan aplikasi dalam area ini adalah: pengontrolan jaringan, transmisi danswitching, service management, dan manajemen jaringan, dsb.

·      Air Traffic Control: Ljunberg mengemukakan sistem pengontrolan lalu lintas udara berbasis agent yang terkenal dengan nama OASIS. OASIS sudah diujicoba di bandar udara Sydney di Australia. OASIS diimplemantasikan menggunakan sistem yang disebut DMARS.

·      Transportation System: Beberapa contoh aplikasi teknologi agentyang ada dalam area ini adalah: aplikasi pencarian sistem transportasi dan pemesanan tiket dengan menggunakan MAS, kemudian aplikasi lain adalah seperti yang dikemukakan oleh Fischer.

   Riset dan AplikasiSoftware Agent di Dunia Internet dan Bisnis

Seperti sudah disebutkan diatas, boleh dikatakan teknologiagent paling banyak diaplikasikan dalam dunia Internet dan bisnis ini. Bagaimanapun juga ini tak lepas dari maju dan berkembang pesatnya teknologi jaringan komputer yang membuat perlunya paradigma baru untuk menangani masalah kolaborasi, koordinasi dalam jarak yang jauh, dan salah satu yang penting lagi adalah menangani kendala membengkaknya informasi.

1. Information Management

Ada dua tema besar dalam manajemen informasi dan peran teknologi agent untuk mengatasi masalahinformation overload karena perkembangan teknologi jaringan dan Internet.

• Information Filtering: Proyek MAXIMS, kemudian WARREN adalah contoh aplikasi di bidang information filtering.
• Information Gathering: Banyak sekali aplikasi yang masuk areainformation gathering baik gratis maupun komersil. Contohnya adalah proyek WEBMATE, pencarian homepage dengansoftbot, proyek LETIZIA, dsb.

2. Electronic Commerce

Tema riset kearah desain dan implementasi untuk mengotomatisasi jual-beli, termasuk didalamnya adalah implementasi strategi dan interaksi dalam jual-beli, tawar-menawar, teknik pembayaran, dsb. merealisasikan sistem pasar elektronik dalam sistem yang disebut dengan KASBAH. Dalam sistem ini disimulasikan buyer agent dan seller agent yang melakukan transaksi jual-beli, tawar-menawar, dan masing-masingagent mempunyai strategi jual beli untuk mendapatkan yang termurah atau teruntung. Aplikasi agent lainnya adalah BargainFinder, JANGO, MAGMA, dsb.

3. Distributed Project Management

Untuk meningkatkan produktivitas dalam kerja yang memerlukan kolaborasi antar anggota tim dalam kerangka teamwork, mau tidak mau harus dipikirkan kembali model software yang mempunyai karakteristik bisa melakukan kolaborasi dan koordinasi secara mandiri, untuk membantu tiap anggota dalam melakukan tugas yang menjadi tanggung jawabnya. Salah satu approach adalah dengan mengimplemantasikan teknologi agent dalam software sistem yang dipakai untuk berkolaborasi. Anumba memberikan kontribusi dalam pengembangan decision support system untuk designer dalam mendesain bangunan dalam kerangka teamwork. Riset dan aplikasi lain adalah RAPPID, PROCESSLINK, dan juga OOEXPERT yang memberikan solusi dan metodologi dalam pemecahan masalah object model creation process dalam OOAD, dan implementasi dengan menggunakan pendekatan Multi Agent System (MAS).

   Riset dan AplikasiSoftware Agent di DuniaEntertainment

Komunitas informatika dan ilmu komputer sering tidak menjamah dengan serius industri-industri yang bersifat lebih ke arah rekreasi dan kesenangan (Leisure Industri). Misalnya adalah masalah industri game, teater dan sinema, dsb. Dengan adanya software agent, memungkinkan komunitas informatika dan komputer untuk ikut andil merealisasikan pemikirannya.

1. Games

Software agent berperan penting dalam pengembangan game modern, misalnya dengan membawa paradigma agentkedalam karakter manusia atau sesuatu dalam game tersebut sehingga lebih hidup. Beberapa riset yang sudah sampai pada tahap implementasi adalah misalnya aplikasi game yang dikembangkan oleh Grand dan Cliff, kemudian juga, dsb.

2. Interactive Theatre and Cinema

   Riset dan AplikasiSoftware Agent di Dunia Medis

Dunia medis adalah bidang yang akhir-akhir ini sangat gencar dilakukan komputerisasi terhadapnya. Tidak ketinggalan, teknologi agent pun dicoba untuk diimplementasikan dalam rangka mencoba mengatasi masalah-masalah yang berhubungan dengan monitoring pasien, manajemen kesehatan dari pasien, dsb.

   Riset dan AplikasiSoftware Agent di Dunia Pendidikan

Dengan perkembangan teknologi jaringan komputer, dunia pendidikan pun salah satu yang merasakan manfaatnya. Sistem pengajaran pun mengalami perkembangan kearah lebih modern dengan memanfaatkan teknologi jaringan.

Daftar Pustaka

Andrew S. Tanenbaum & Maarten Van Steen. 2002. Distributed Systems Principles And Paradigms. New Jersey 07458: Prentice Hall.

http://baskarapunya.blogspot.com/2011/10/sistem-terdistribusi-bab-iii.html

http://arsyapasha.blogspot.com/2012/01/thread-pada-sistem-terdistribusi.html

http://irpantips4u.blogspot.com/2012/11/Software-Agent-Sistem-Terdistribusi-Definisi-Karakteristik.html