Implementasi Synchronous Groupware
Sistem groupware mengalami masalah pada implementasi sistem yang sinkron dan lebih sulit dibandingkan sistem yang singe-user. Misalnya dalam menangani update dari beberapa user seperti tidak mendapatkan struktur data internal atau layar user yang berantakan.Belum lagi ditambah dengan bandwudth yang terbatas dan penundaan dari jaringan yang digunakan untuk menghubungkan computer dan asumsi single-user dalam membangun tool grafik.
- Feedback and network delays
Suatu pesan ketika dikirim dalam suatu jaringan maka tidak dapat secara langsung diterima oleh komunikan di tempat lain karena ada jeda yang terjadi pada jaringan. Lama waktu yang terjadi sesuai dengan jenis jaringan yang digunakan, bahkan bila terjadi request time out (RTO) kemungkinan besar pesan tidak sampai ke penerima.
- Architectures for groupware
Terdapat dua alternative arsitektur untuk groupware yakni centralized (client-server architecture) dan replicated dengan beberapa variasi dari kedua bentuk tadi.
Arsitektur terpusat merupakan kopi tunggal aplikasi dan data.Seperti Contoh :
- Client server è Kasus yang paling sederhana (berlawanan dengan X Windows Client Server)
- Master-slave è Kasus khusus pada client-server (server digabungkan dengan satu klien)
NB : Server dipadukan dengan seorang klien.
Replikasi, yang merupakan kopi untuk setiap workstation.
- Replikasi juga sering disebut dengan peer to peer.
- Local feedback.
- Race condition.
Arsitektur setengah jalan :
- Local copy application + central database
- Cache data lokal untuk umpan balik.
- Beberapa hidden locking.
Arsitektur shared window merupakan suatu aplikasi yang tak memperhatikan kolaborasi (non-collaboration aware) dengan pendekatan klien/ server dan berhubungan dengan masalah umpan balik serta tidak ada ‘fungsionalitas’ dalam aplikasi. Seperti contoh :
- Single copy pada real application.
- User stub untuk setiap user act yang bertindak sebagai X application (X client).
- Satu application stub acts seperti X server untuk real application.
- User stub passes events ke single application stub.
- Stubs menge X events masuk dan replicated X lib memanggil keluar (strictly protocol)
- Feedthrough and network traffic
Perlu untuk memberikan informasi pada semua klien yang lain mengenai perubahan yang terjadi. Hanya sedikit jaringan yang mendukung pesan broadcast sehingga n partisipan è n -1 network messages!
Solusinya adalah dengan meningkatkan granularitas dan mengurangi frekuensi umpan balik, tetapi umpan lewat yang buruk akan kehilangan konteks (shared contetx). Perimbangannya adalah timeliness vs lalu lintas jaringan.
- Graphical Toolkits
Sebelumnya telah dibahas beberapa widget yang ditemukan pada graphics toolkit atau window manager seperti menu,button,kotak dialog serta teks dan graphic region. Semua ini berguna untuk membuat interface single user dan salah satunya menggunakan komponen yang sama untuk membentuk sistem groupware. Beberapa widget dapat menangani control aplikasi, misalnya pada menu pop-up berikut :
| Sel = do_pop_up(‘new”,”save”,”exit”,0); |
Secara fundamental fungsionalitas dari widget toolkit tidak mencukupi untuk groupware.
- Robustness dan Skalabilitas
Yang perlu diperhatikan pada masalah robustness dan skalabilitas adalah masalah crash / tabrakan. Jika terjadi tabrakan pada interface single user maka hanya ada satu user yang merasakannya, tetapi jika terjadi tabrakan pada interface untuk multiuser, hal itu merupakan bencana bagi desainer interface.
Groupware merupakan sesuatu yang kompleks, yang terdiri dari gabungan elemen jaringan, grafik dan lain sebagainya, dan mempunyai skala user yang besar sehingga perlu lebih sering dilakukan pengujian dan debugging untuk menimalkan terjadinya kesalahan.
Ada beberapa tip yang berhubungan dengan groupware, diantaranya adalah :
- Network atau sever fail :
Masalah paling besar terjadi pada sistem yang berbasiskan pada client-server adalah bila terjadi tabrakan server, baik pada software maupun hardware.
Kerusakan ini berupa kesalahan kode karena sangat kompleks, misalnya penggunaan program yang menangani interkasi user dan dibuat dengan menggunakan graphical toolkit yang kompleks. Tentu saja program harus dibuat secara hati-hati untuk menghindari kesalahan tetapi pengalaman menunjukkan bahwa hal itu sulit dihindari. Pencegahan dilakukan secepat mungkin dan bila menggunakan arsitektur client-server maka terdapat tiga “R” untuk server yakni :
- Robust
Server seharusnya dapat mempertahankan klien yang tabrakan atau dengan kata lain kerusakan pada klien seharusnya tidak menyebabkan server menjadi hang. Secara khusus server tidak boleh menunggu respon dari klien.
2. Reconfigure
Mendeteksi dan mengantisipasi kesalahan atau dengan kata lain server harus mendeteksi kesalahan yang terjadi pada klien dan mengkonfigurasi ulang atas keseluruhan sistem. Konfigurasi ulang meliputi set ulang dari struktur data internal dan mengonfirmasikan partisipan lain bahwa partisipan yang lain tidak ada dan alasannya.
3. Resychronise
Ketika workstation/client me-recover maka server harus mengirimkan informasi yang cukup untuk menyusul. Secara normal server mengirimkan informasi yang selalu bertambah sehingga membuat server selalu berada pada posisinya untuk dikirimkan ke klien yang diperbaiki.
- Kesalahan dalam pemrograman:
Berbagai aplikasi yang bertabrakan tidak menyebabkan aplikasi itu menjadi rusak dan mungkin akan menyebabkan lebih sulit lagi untuk mendeteksinya. Sebagai contoh struktur data anatara replicates atau antara klien dan server mungkin akan menyebabkan tidak konsisten. Hal ini tidak mungkin terjadi jika:
- Pemrograman bertahan (defensive).
- Algoritma sederhana.
- Metode formal.
- Rangkaian kejadian tak terlihat:
Pemrograman terdistribusi banyak mengalami masalah yang dikenal dengan istilah deadlock. Hal ini terjadi jika dua atau lebih proses, masing-masing saling menunggu untuk melakukan sesuatu. Kemungkinan deadlock sering tidak terdeteksi selama pengujian karena sistem operasi dan buffer jaringan.Aturan pertama untuk mencegah deadlock adalah jangan pernah menghalangi input atau output, yaitu dengan menggunakan pewaktuan.
- Testing for Robustness
Terkadang fungsi dari suatu aplikasi diuji dengan menggunakan beberapa window pada workstation yang sama, yang masing-masing bertindak sebagai user yang berbeda. kerusakan dan beberapa kesalahan yang penting dapat disimulasikan dengan mencoba melakukan reboot dari workstation atau melepaskan konektor jaringan atau cara yang lebih halus dengan cara menghentikan proses suatu client dan melihat efeknya pada server. Cara yang lain adalah simulasi untuk ‘race condition’ dan urutan yang ganjil dengan menajalankan sistem diantara 2 workstation kemudian tekan kunci panel secara simultan.
najlah rawter 