ABSTRAK
Kemampuan untuk mengubah agen pengguna saat bekerja adalah mulai muncul dalam keadaan komputasi seni mobile karena proliferasi dari berbagai jenis perangkat, mulai dari perangkat nirkabel pribadi untuk komputer desktop, dan kebutuhan akibat dari migrasi bekerja sesi dari perangkat ke yang lebih tepat. Hasil Penelitian terkait dengan hand-off di tingkat rendah tidak cukup untuk memecahkan masalah di level aplikasi. Artikel ini menyajikan sebuah skema untuk sesi hand-off dalam aplikasi web yang memanfaatkan sebuah proxybased arsitektur, yang mampu bekerja tanpa intervensi yang terdapat pada kode.
1. PENDAHULUAN
Kemampuan untuk mengubah seluruh host yang digunakan oleh pengguna dapat menjadi isu yang sangat sentral dalam layanan jaringan generasi berikutnya. Sementara perangkat saat ini memiliki banyak tumpang tindih melebihi kemampuan (ponsel dapat menelusuri Web, PC dapat bertindak sebagai telepon, dan sebagainya). Dalam kenyataan sehari-hari, peningkatan penggunaan perangkat sangat pesat dengan kemampuan yang disesuaikan dengan tujuan yang masing-masing. Penelitian ini mengarah pada dua corollaries: (a) sangat mungkin untuk sesi komunikasi mengganggu gerakan aktivitas yang membutuhkan, (b) sering yang tidak terduga apa jenis perangkat yang tepat yang akan kita temukan lebih cocok dalam mengikuti sesi.
Beberapa contoh dapat menggambarkan pembauran di atas pertimbangan. Seorang pengemudi dapat mengatur jalan dengan menggunakan navigasi sistem mobilnya untuk menemukan kemudian bahwa bagian akhir dari jalan berada dalam zona pejalan kaki, di mana ia dapat menggunakan ponsel namun tidak dengan navigator mobil; pengguna internet dapat mulai menavigasi dari PDA dan perlu untuk melanjutkan navigasi pada PC jika ia menemukan bahwa klip membutuhkan layar yang lebih luas.
Semua skenario ini melibatkan kemampuan untuk melakukan sesi dari host ke yang lain. Tulisan ini meneliti kemampuan dan teknologi masa depan untuk memberikan jawaban atas skenario tersebut, untuk menilai kebutuhan pengguna dan keterbatasan teknologi dan untuk mengusulkan dan percobaan dengan solusi yang mungkin dalam konteks warisan aplikasi. Mengaktifkan sesi hand-off dalam aplikasi memungkinkan mereka untuk bersaing dengan yang lebih modern yang disebabkan oleh meningkatkannya kegunaan mereka. Namun, warisan kode pemilik sering takut untuk pemeliharaan proyek tambahan. Dengan demikian, kami menyajikan arsitektur dan protokol yang mampu memungkinkan warisan aplikasi untuk mengeksploitasi layanan sesi hand-off yang disertakan dengan minimal intervensi pada aplikasi.
Bagian berikut ini berbicarakan tentang arsitektur berbasis proxy dan fungsi proxy. Akhirnya, kami menjelaskan implementasi usaha, yang saat ini dalam proses.
2. PROXY-BASED SESSION HAND-OFF
Beberapa proposal berpusat pada skema arsitektur berbasis klien yang disajikan dalam literatur. Dengan pendekatan ini, kode bertanggung jawab untuk melacak dan menyimpan informasi sesi (handoff sesi komponen SHOC) yang dekat dengan klien.
Skema arsitektur berbasis proxy, sebaliknya, melibatkan penggunaan dari intermediate proxy, SHOC, antara klien dan server. Sejak interaksi antara klien dan server melintasi proxy, ia mampu untuk menyimpan semua informasi sesi bahkan dalam kasus di mana beberapa server digunakan untuk aplikasi.
Dalam arsitektur ini, ketika suatu masalah client hand-off, target klien dapat mengambil semua informasi yang dibutuhkan dari proxy.
Teknologi berbasis proxy memungkinkan untuk menambahkan layanan tanpa ada intervensi pada kedua klien dan server. Oleh karena itu, dapat digunakan di sebuah array besar dari aplikasi yang ada.
Walaupun HTTP adalah session-less protokol, aplikasi berbasis web pada HTTP diharapkan untuk mempertahankan state untuk sekelompok interaksi antara klien dan server. State dapat ditangani oleh server, oleh klien atau oleh keduanya. RFC-2965 telah memperkenalkan teknologi Cookie yang secara langsung mengalamatkan manajemen sesi dengan menyimpan informasi di sisi client. Sesi Informasi lain yang terkait dapat dibawa oleh permintaan dan tanggapan di otentikasi dan user agen identifikasi header.
Dengan mengadopsi arsitektur berbasis proxy, server melihat pengganti (agen pengguna dummy) dari klien pada proxy bahkan ketika klien bermigrasi dari perangkat ke yanglain.
Gambar 1 menggambarkan sesi hand-off dimana sesama pengguna dummy agent dihubungi oleh server sebelum dan sesudah hand-off. Untuk menjaga konsistensi komunikasi antara klien dan server, pengguna dummy agent harus mampu untuk menyimpan beberapa pertukarkan data antara client dan server dan untuk melakukan mekanisme otentikasi dari RFC-2617 dan bagian dari manajemen cookie RFC-2965.
Secara khusus, proxy harus melaksanakan kegiatan-kegiatan berikut:
� Otentikasi Pengguna: proxy membutuhkan otentikasi dari setiap pengguna untuk menghasilkan dummy user agent tertentu.
� Otentikasi Server: setiap kali server memerlukan otentikasi, proxy harus mengotentikasi pengguna dummy agent.
� Manajemen Cache: informasi yang dipertukarkan antara client dan server harus disimpan meskipun caching proxy arahan dan aturan.
� Manajemen Cookies: proxy harus menyimpan cookie untuk mengembalikan mereka dalam agen pengguna baru setelah hand-off.
Dalam model, hand-off terjadi ketika agen pengguna baru mengotentikasi dirinya sendiri pada proxy dengan account yang saat ini digunakan. Karena data otentikasi yang dimiliki oleh proxy cukup sederhana untuk masukkan kembali sesi otentikasi. Namun, sesi web tidak bisa benar-benar dikembalikan karena tidak menyadari cookie sebelumnya dipertukarkan oleh agen yang lain. Mengembalikan cookies pada klien baru penting untuk kelancaran migrasi pada sesi.
3. IMPLEMENTASI
Proxy disajikan dalam makalah ini, disebut MuffinSH, telah diimplementasikan di Jawa. Itu dibangun dengan memperluas sistem penyaringan, Muffin tersedia secara bebas di bawah GNU General Public License, dan mendukung HTTP/0.9, HTTP/1.0, HTTP/1.1 dan SSL.
MuffinSH menggunakan pewarisan filter dari Muffin interface untuk melaksanakan sesi hand-off. Antarmuka utama yang dilaksanakan oleh MuffinSH antara lain: RequestFilter, ReplyFilter, ContentFilter, HttpFilter, dan RedirectFilter.
Antarmuka RequestFilter dilaksanakan oleh filter yang menangani header permintaan; ReplyFilter digunakan untuk header respon; ContentFilter memproses isi tanggapan; HttpFilter digunakan untuk menghasilkan balasan untuk permintaan yang tidak perlu dikirim ke server; RedirectFilter mengalihkan URL yang lain. Dengan menggunakan filter, proxy dapat menyimpan, untuk setiap pengguna dan setiap domain, web konten dijawab oleh server untuk klien sebelum sesi user hand-off.
Antarmuka di atas dilaksanakan oleh filter berikut:
� ProxyAuthFilter: menerapkan HttpFilter, akan memverifikasi filter apakah semua permintaan mencapai berisi "Proxy-Authorization" header. Jika tidak ada atau username dan sandi tidak benar, filter memerlukan proxy-Otorisasi dengan skema otentikasi dasar dan tidak tidak meneruskan permintaan ke server. Jika user credentials benar, filter hanya memeriksa apakah otentikasi diterbitkan sebelum atau setelah hand-off.
� CachedReplyFilter: menerapkan HttpFilter, ketika pengguna memberikan permintaan setelah hand-off, filter memeriksa apakah domain sumber daya yang diminta ada di proxy cache dan, dalam kasus positif, menciptakan tanggapan untuk mengirim klien sumber daya yang tersimpan dalam cache.
� ServerAuthFilter: menerapkan RequestFilter dan ReplyFilter; bertindak ketika server meminta user untuk otentikasi.
� HeaderChangeFilter: menerapkan RequestFilter; itu mengubah permintaan header untuk memungkinkan server untuk mengenali klien dengan set baru header mewakili dummy user agent.
� CacheFilter: menerapkan ContentFilter, sebelum hand-off terjadi, filter ini bertindak pada isi tanggapan yang ditandai dengan tipe konten teks / html, ia menganalisis penerimaan tag html dan mendasarkan pada analisis ini mengelola halaman yang mengandung frame, halaman yang menerapkan frame berisi dan halaman disebut di dalam frame.
� UrlRedirectFilter: menerapkan RedirectFilter; ketika filter ini memotong di URL permintaan beberapa pengidentifikasi sebelumnya dimasukkan oleh CacheFilter, itu menghilangkan pengidentifikasi, menyimpan informasi terkait dan meneruskan permintaan ke server.
� RedFilter: menerapkan RedirectFilter; bekerja setelah terjadinya hand-off untuk melakukan redirection ke URL permintaan dari klien sebelum hand-off untuk mengingat semua cookie yang sebelumnya diterima oleh klien dalam tanggapan untuk permintaan itu.
4. REFERENSI
[1] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and Stewart, L. HTTP Authentication: Basic and Digest Access Authentication, RFC 2617, June 1999. http://www.rfc-editor.org/rfc/rfc2617.txt.
[2] Kristol, D., and Montulli, L. HTTP State Management Mechanism, RFC 2965, Octber 2000. http://www.rfceditor.org/rfc/rfc2965.txt.
[3] Muffin: World Wide Web Filtering System. http://muffin.doit.org.
[4] Song, H., Chu, H., Kurakake, S. Browser Session Preservation and Migration. In Poster Session of WWW 2002, Hawai, USA. 7-11. May, 2002. pp. 2.
Anggota Kelompok :
1. Erika Firstiana
2. Gita Ayuningtyas
3. Niken Ayu Ningthias
4. Nuraihan Shahab
Kelas : 4IA02
Tidak ada komentar:
Posting Komentar