Możliwość kontroli aktualnego stanu aplikacji klienckiej przez część serwerową systemu klient-serwer może przynieść korzyści zarówno ich administratorom, jak i użytkownikom.

W lipcowym Raporcie Computerworld w artykule Monitorowanie klienta poruszałem tematykę kontrolowania poczynań stacji roboczych używających oprogramowania w technologii klient-serwer. Zaproponowałem w nim, aby działania rozproszonych aplikacji klienckich odnotowywać za pomocą przechowywanego na serwerze wspólnego dla nich pliku wymiany informacji. Temat zarysowany wówczas ogólnie przedstawiam niniejszym w formie bardziej szczegółowej, z punktu widzenia implementacji funkcji kontrolnych przez programistę. Organizacja pliku wymiany informacji może być dowolna. Na potrzeby niniejszego artykułu posłużę się przykładem implementacji dla bazy danych Microsoft SQL Server 2000, który można oczywiście przenieść na inne platformy.

W trosce o sieroty

Wszelkie informacje o stanie aplikacji na poszczególnych stacjach roboczych są gromadzone na serwerze w tabeli monitora (TM), której struktura jest przedstawiona w tabeli. Uruchomienie aplikacji na dowolnej stacji klienckiej powoduje wykreowanie dla niej w tabeli monitora rekordu RMK (rekord monitorujący klienta). Ponieważ rekord jest powiązany z komputerem przez jego unikalną nazwę (Host_Name), dla każdej stacji będzie istniał w tabeli tylko jeden wiersz - aż do czasu poprawnego zakończenia pracy z aplikacją.

Podany tu sposób ewidencji poprzez utworzenie rekordu podczas uruchamiania programu i jego usunięcie w chwili kończenia pracy aplikacji działa poprawnie, jeśli nie zajdą nieoczekiwane, aczkolwiek towarzyszące czasami środowisku przetwarzania, warunki niestabilności. Nieprzewidziane wyłączenie stacji roboczej spowoduje, że aplikacja nie będzie miała szans na usunięcie swego rekordu z tabeli monitorowania, co oznacza dalej, że pozostawi po sobie osierocony, zdezaktualizowany zapis. Aby uniknąć tego typu utrudnień, można zastosować pewne metody usuwania "zanieczyszczeń" informacyjnych.

Podczas uruchamiania, jeszcze przed założeniem swojego rekordu w tabeli, program sprawdza, czy nie widnieje tam już zapis komputera o tej samej nazwie, co oznaczałoby, że ma do czynienia z jego własnym rekordem osieroconym z poprzedniej nieprawidłowo zakończonej sesji. Jeśli więc taki napotka, usuwa go. Algorytm ten zdaje egzamin, jeśli po nie kontrolowanym przerwaniu pracy mamy okazję wznowić ją z tej samej stacji, albowiem jako unikalny identyfikator przyjęliśmy nazwę komputera. Jeśli jednak uszkodzeniu uległ komputer, na tyle że nie można go uruchomić, stacja kliencka nie będzie mogła usunąć własnego osieroconego zapisu.

Mając na uwadze tego typu przypadki, należy zastosować inne mechanizmy pozwalające na automatyczne usuwanie przez inne stacje wpisów osieroconych bez względu na ich prawo własności. Osiągniemy to, wprowadzając procedury kontrolne, które mają za zadanie usunąć z tabeli wszystkie wpisy o zbyt długim okresie nieaktywności. Czas ten definiuje się parametrycznie i może wynosić kilka godzin lub kilka dni.