1. Klient/serwer: spełnienie oczekiwań?

Koncepcja architektur klient/serwer pojawiła się, jako odpowiedź, na narastającą potrzebę tworzenia systemów informatycznych dla dużych organizacji, działających w zdecentralizowanym, rozproszonym środowisku, efektywnie realizujących dostęp do zasobów danych, wspomagających zarządzanie oraz zwiększających wydajność pracy i satysfakcję użytkowników. Chcemy, by mogły być one tworzone szybko i przy niskich kosztach, przez sprawnie zorganizowane zespoły informatyków współpracujących z klientem. Chcemy by ich pielęgnacja i rozbudowa nie nastręczała problemów. Chcemy też, by powstające rozwiązania były otwarte, czyli nie uzależnione ściśle i na zawsze od konkretnych rozwiązań sprzętowych, systemów baz danych. Od systemów biznesowych oczekujemy wreszcie bezpieczeństwa, niezawodności i użyteczności.

Jak architektura klient/serwer pozwala sprostać tym oczekiwaniom? Spróbujmy ocenić jej możliwości i związane z nią bariery rozwoju systemów.

2. Dwie warstwy to za mało

Najprostszy wariant architektury klient/serwer to architektura dwuwarstwowa. Typowy system złożony jest z aplikacji klienckich - działających z reguły na komputerach osobistych stojących na biurkach użytkowników - oraz serwerów danych, pracujących na komputerach osobistych, minikomputerach lub (rzadziej) mainframe. Większość - ok. 90%, według Gartner Group - używanych dziś systemów klient/serwer ma taką właśnie architekturę.

Wariant dwuwarstwowy ma wiele zalet. Środowisko implementacji systemu to zwykle jeden z wielu wygodnych pakietów typu visual 4GL, a więc silne i wygodne środowisko konstrukcyjne. Najpoważniejszy problem techniczny związany z architekturą klient/serwer - właściwe rozproszenie komponentów aplikacji - w tym wariancie praktycznie nie występuje. Tworzenie serwera bazy danych ogranicza się do zaprojektowania odpowiedniej struktury podstawowych jej obiektów - tablic, perspektyw, indeksów i praw dostępu. Wszystko to sprawia, że wariant dwuwarstwowy jest idealny przy realizacji pilotowych projektów systemów dla niedużych grup roboczych niezbyt silnie obciążonych transakcjami. Nie jest to jednak na ogół rozwiązanie wystarczająco dobre dla większych systemów (duża liczba użytkowników, większa częstotliwość transakcji, duże wymagania co do niezawodności). System informatyczny organizacji ma za zadanie nie tylko przechowywanie i udostępnianie danych.

Ważniejsze jest aktywne wspomaganie działalności organizacji przez implementowanie związanych z nią zasad, procedur i strategii. Te zasady, zwane często regułami biznesowymi, standaryzują procesy biznesowe organizacji - zarządzanie, obsługę klienta, produkcję itp. Ich obrazem w systemach informatycznych jest zwykle logika aplikacji i statyczne więzy nakładane na strukturę bazy danych, tzw. więzy integralności. W architekturze dwuwarstwowej reguły, wykraczające poza więzy integralności, realizowane są z konieczności w aplikacjach klienckich, sprawiając, że z czasem osiągają one rozmiary krytyczne z punktu widzenia wydajności typowego komputera biurowego (rozwiązanie to nazywa się często architekturą z "grubym klientem"). Wraz ze wzrostem komplikacji i zasięgu wdrożenia systemu, jego twórcy i użytkownicy stają w obliczu nieuchronnego spadku niezawodności i efektywności. Drugim zagrożeniem, jakie rodzi redundancja reguł biznesowych w wielu aplikacjach i na wielu stanowiskach pracy, jest utrata ich spójności. Zmiana reguł może wówczas łatwo doprowadzić do ogromnych trudności z kontrolą wersji i utrzymaniem jednolitej "strategii biznesowej" całego systemu.

Stąd kolejny, naturalny krok w rozwoju architektury systemu klient/serwer - "faktoryzacja" logiki biznesowej, osiągnięta poprzez usunięcie reguł z aplikacji klienckich. Można je umieścić we współdzielonych bibliotekach DLL, zachowując bez zmian fizyczną architekturę systemu, można też osadzić je na serwerze danych, wykorzystując mechanizmy wyzwalaczy (triggerów) i procedur wbudowanych (to podejście nazywane jest czasem architekturą dwu-i-pół-warstwową). Pozwala to na ogół na realizację większych, bezpieczniejszych i bardziej niezawodnych systemów.

Tam gdzie logika biznesowa daje się w naturalny sposób wyrazić w języku programowania serwera (jest to na ogół SQL wzbogacony o instrukcje sterujące) i gdzie serwer jest umieszczony na wydajnej jednostce obliczeniowej, można też na ogół mówić o wzroście wydajności systemu. Niestety i tu pojawiają się bariery rozwoju. Język procedur wbudowanych nie najlepiej nadaje się do programowania złożonych algorytmów. Brakuje powszechnie przyjętej ich standaryzacji, co zmusza twórców systemu do silnego związania się z konkretnym dostawcą bazy danych. Wreszcie - serwery baz danych miewają ograniczenia, w mniejszym lub większym stopniu, utrudniające efektywną implementację reguł biznesowych.