Stosowanie technologii klient/serwer wymaga określenia wielu szczegółów dotyczących takich rozwiązań. Czy dwuwarstwowy model C/S jest wystarczająco dobry w praktyce?

Menedżer kupujący konfigurację klient/serwer z pewnością postawi oferentowi pytanie czy dana konfiguracja do tej klasy rozwiązań należy. Zapytana firma z pewnością również udzieli odpowiedzi twierdzącej. I w zasadzie będzie miała rację. Istnieją bowiem różne typy konfiguracji C/S, a przy tym nie jest całkiem jasne co należy rozumieć pod tym pojęciem. Praktyka informatyczna ma jednak to do siebie, że nie lubi czekać na wyniki nie kończących się sporów terminologiczno-definicyjnych, ale po prostu wdraża. No bo przecież "wiadomo o co chodzi". Warto wszakże zastanowić się: "o co".

W typowym pakiecie software'owym da się wyróżnić trzy główne warstwy:

- warstwa dostępu do danych (data access)

- warstwa logiki oprogramowania (application logic)

- warstwa prezentacji (presentation).

Schemat taki może być punktem wyjścia do porównań architektur C/S, choć nie należy go traktować jako uproszczenia znanego 7-warstwowego modelu sieci komputerowych ISO/OSI. Dla tradycyjnej już dzisiaj konfiguracji "głupich" terminali połączonych z dużym komputerem centralnym (mainframe) wszystkie trzy warstwy znajdują się w obrębie jednej maszyny. Przykładem może tu być program w COBOL-u korzystający z bazy danych w standardzie CODASYL-u - trzy elementy aplikacji stanowią jedną całość.

Jest to tzw. monolityczny typ architektury komputerowej, ale mówienie w tym kontekście o "monolitycznej architekturze klient/serwer" często prowadzi do nieporozumień. Równie dobrze można by udowadniać, że łopata to powiedzmy: prosty typ koparki przedsiębiernej i zasięrzutnej o napędzie mięśniowym. Praktyczna informatyka nie jest wszakże teorią łopatologii stosowanej i koparki w obszarze klient/serwer zaczynają się od fizycznego podziału aplikacji między klientem i serwerem.

Precyzyjnie ujmuje to Gartner Group definiując C/S jako: "podział aplikacji na zadania (tasks) realizowane na odrębnych komputerach". Oczywiście klient/serwer to przede wszystkim typ architektury software'owej a nie hardwarowej. Same pojęcia "klient" i "serwer" oznaczają głównie odpowiednie części aplikacji, a dopiero w drugiej kolejności mogą być utożsamiane z komputerami, na których działają.

Tak więc łączenie PC-tów w sieć komputerową nie tworzy automatycznie konfiguracji C/S, niezależnie od tego czy posługujemy się prostą siecią Novella, czy najnowszą wersją Pathworks/DEC. Istotą sieciowych systemów operacyjnych jest bowiem podział wirtualnych dysków (partycji), z którymi poszczególne komputery mogą pracować podobnie jak z własnym, lokalnym dyskiem. Koncepcję taką określa się mianem file/server (F/S). Różnice takiego rozwiązania w stosunku do konfiguracji monolitycznej są wyraźne:

- łatwa wymiana danych

- elastyczny podział pamięci dyskowej

- lepszy rozkład obciążenia między składnikami konfiguracji

- centralne mechanizmy ochrony danych, back-up.

Dla pewnej klasy oprogramowania taka oferta jest nawet wystarczająca. Dotyczy to np. indywidualnego oprogramowania PC: Pisanie tekstu WordPerfectem czy tworzenie tabeli Lotusem może odbywać się lokalnie. To jednak za mało, aby informatyka mogła skutecznie wspomagać strategiczne obszary działania przedsiębiorstwa. Obszary te wymagają wspólnego dostępu do danych przez konkurujące ze sobą aplikacje różnych użytkowników. Podstawowe technologie umożliwiające spełnienie tego wymagania znane były już wcześniej: podział czasu, podział zasobów, przetwarzanie rozproszone.

Podział czasu (time sharing) umożliwia funkcjonowanie konfiguracji z rys. 1. Każdy z użytkowników korzysta z centralnego komputera tak jakby należał on wyłącznie do niego, podczas gdy w rzeczywistości ma do dyspozycji maszynę zaledwie przez część jej podstawowego cyklu pracy. Z kolei podział zasobów (resource sharing) wynika bezpośrednio z mechanizmów działania sieci komputerowych.

Przetwarzanie rozproszone (distributed processing) można zilustrować następującym przykładem. Przypuśćmy, że mieszkaniec stolicy zamierza spędzić urlop w Zakopanem (hotel) i chce tam dojechać pociągiem. W tym celu udaje się do biura turystycznego, aby dokonać stosownych rezerwacji. Załóżmy dalej, że zarówno system rezerwacji PKP jak i biuro turystyczne oraz zakopiański hotel są skomputeryzowane i mają ze sobą łączność teleinformatyczną. Mamy tu do czynienia z przetwarzaniem rozproszonym, gdyż poza aplikacją w biurze turystycznym program PKP musi sprawdzić czy w żądanym terminie są wolne określone miejsca, a program w Zakopanem dokonuje podobnej weryfikacji w hotelu.

Poza aplikacją w biurze turystycznym mamy do czynienia z dwoma transakcjami, przy czym każda z nich przebiega wg schematu dwufazowego zatwierdzania (two phase commit). Oznacza to, że w pierwszej fazie rezerwacje dokonywane są tymczasowo, a dopiero w drugiej fazie, kiedy odpowiedzi na wszystkie zapytania są pozytywne, następuje rezerwacja ostateczna - również rozproszona między wieloma komputerami (aplikacjami).

Z punktu widzenia interesanta biura turystycznego oprogramowanie rezerwacyjne jest całkowicie "przejrzyste" (transparent), nie musi on wcale wiedzieć gdzie znajdują się niezbędne dane i jak rozłożone są części aplikacji między poszczególne komputery w sieci. W typowej dla architektury C/S sytuacji, części aplikacji realizowane na różnych komputerach stanowią integralną całość - w tym kontekście mówi się o współprzetwarzaniu (cooperative processing). Od kojarzonej z takim przetwarzaniem relacji master-slave (proces nadrzędny i podległy) korzystniejszym wydaje się być porównanie do biologicznej symbiozy.

Klient/serwer tak. Ale jak? Wróćmy zatem do rysunku 1. Wychodząc z przyjętego 3-warstwowego modelu aplikacji, w nietrywialnym przypadku możemy przyporządkować klientowi tylko warstwę prezentacji lub warstwę prezentacji i logiki oprogramowania. Ponadto w dalszych trzech wariantach możemy podzielić jedną z trzech warstw między klienta i serwer (rys. 2). Mamy więc do wyboru 5 rodzajów topologii C/S. Widać wyraźnie, że topologie te decydują o obciążeniu aplikacją jednej lub drugiej strony.

Obciążenie to warunkuje wykorzystywanie zasobów systemu (głównie czasu i pojemności dysków) po stronie klienta lub serwera. W skrajnym przypadku I (rozproszona prezentacja), niemal cała aplikacja znajduje się po stronie serwera. Jest to korzystne gdy po tej stronie dysponujemy niezbędną pojemnością dysków i gdy serwer posiada odpowiednią moc (pamięć operacyjna, procesory), aby zagwarantować wymaganą przez użytkownika szybkość. W przypadku V (rozproszony dostęp do danych) aplikacja jest bardzo zależna od parametrów po stronie klienta.

W zależności od przyjętego rozkładu aplikacji między klientem a serwerem możemy modyfikować obciążenie sieci, będące często jednym z krytycznych czynników dla całej konfiguracji. Z reguły w przypadku I. możemy się liczyć z mniejszą liczbą transmisji dużych pakietów danych, natomiast w wariancie V. mamy do czynienia z większą ilością transmisji mniejszych pakietów. Przypadki II-IV są rozwiązaniami pośrednimi, aczkolwiek każdy administrator sieci wie, że jej parametryzacja (tuning) jest zadaniem złożonym i w praktyce możliwa jedynie dla konkretnej sytuacji rzeczywistej - wszelkie formuły teoretyczne należy więc traktować z ostrożnością.

Dotychczas milcząco zakładaliśmy, że nasze rozwiązanie C/S ma dwie części: z jednej strony klient ze swoimi "żądaniami" i "pytaniami" (request, query), a z drugiej obsługujący go serwer. Wariant ten nazywany jest dwuwarstwową architekturą C/S (two-tier). Jest to rozwiązanie naturalne, ale nie jedyne. Odwzorowanie 1:1 trzech warstw aplikacji z rys. 1 prowadzi do modelu trzywarstwowego (three-tier C/S architecture).

Model ten - C/S/S - powstaje w wyniku rozbicia warstwy serwera na dwie części: serwer dostępu do danych + serwer aplikacji. Narzędziem służącym do implementacji tej trzeciej warstwy jest "oprogramowanie środka" - middleware. Takie ujęcie koresponduje także z wąsko rozumianą definicją middleware, która mówi że jest to oprogramowanie oddzielające aplikację od samego systemu operacyjnego. W kontekście technologii C/S przez middleware rozumie się "międzyoprogramowanie" oddzielające stronę klienta od serwera. Oczywiście rozdział taki może przyczyniać się do większej integracji składników całej konfiguracji, co ma szczególne znaczenie dla różnorodnych i rozbudowanych aplikacji w heterogenicznym środowisku sieciowym.

Niuanse te zapewne zainteresują topologa (?!); dla menedżera wszakże istotniejsze będzie pytanie: co to oznacza w praktyce? Pytanie takie zawiera zwykle podtekst: ile to będzie kosztować? Rozważmy konkretną konfigurację C/S: z jednej strony "unixopodobny" serwer z bazą danych Oracle, z drugiej zaś wybrany pakiet CDE (Cooperative Development Environment) tej samej firmy np. Forms czy Reports. Oczywiście zapewnienie łączności między tymi stronami wymaga jeszcze dodatkowego oprogramowania, choćby SQL*Net niemniej zasadniczo kupujemy w zestawie 2 pakiety.

Decydując się na architekturę trzywarstwową obsługiwaną przez 3 różne pakiety niezależnych producentów nie możemy liczyć na bezpośrednie oszczędności. Wprawdzie w danej chwili może się okazać, że zastąpienie pakietu CDE przez produkt firmy Powersoft(Sybase) - np. PowerBuilder jest korzystniejsze cenowo, niemniej warstwę pośrednią też ktoś musi oprogramować, a to komplikuje całość implementacji.

Czy warto więc inwestować w trzecią warstwę? Z pewnością taka architektura przyczynia się do większej otwartości systemu i czyni go perspektywicznie bardziej elastycznym. Z drugiej strony praktyka pokazuje, że oparcie się o mniej wyrafinowane, ale sprawdzone rozwiązania renomowanych domów software'owych gwarantuje stabilność i efektywność ekonomiczną także w dużych przedsiębiorstwach.