Przetwarzanie klient-serwer

W dziedzinie aplikacji dla przedsiębiorstw, najmodniejszy jest termin klient-serwer, określający pewną filozofię przetwarzania danych. Na swoistą ironię zakrawa fakt, że jak większość nowych i modnych terminów, wyzwolił on całą masę definicji oraz odnosi się do zastosowań, których początkowo wcale nie dotyczył.

W dziedzinie aplikacji dla przedsiębiorstw, najmodniejszy jest termin klient-serwer, określający pewną filozofię przetwarzania danych. Na swoistą ironię zakrawa fakt, że jak większość nowych i modnych terminów, wyzwolił on całą masę definicji oraz odnosi się do zastosowań, których początkowo wcale nie dotyczył.

Termin klient-serwer oznacza taką architekturę komputerową, która ma umożliwić optymalne wykorzystanie komputerów osobistych, współpracujących z serwerami aplikacji lub baz danych. Serwery wykonują w tle "czarną robotę" związaną z dostępem, wykonywaniem zapytań do baz danych, ich uaktualnianiem i przechowywaniem, zaś komputery osobiste (klienci) robią "dobrą minę", czyli zapewniają interfejs graficzny, ułatwiający pracę użytkownika. Architektura klient-serwer ma obecnie zastosowanie głównie do aplikacji w dziedzinie zarządzania bazami danych.

Na uproszczonym rysunku pokazano zasadniczą różnicę między architekturą klient-serwer a rozwiązaniem typu serwer plików, który współpracuje w sieci lokalnej ze stacjami roboczymi. W modelu klient-serwer całe przetwarzanie związane z dostępem do bazy jest wykonywane przez serwer; klient otrzymuje jedynie wyniki. W modelu serwer plików-stacje robocze, całe przetwarzanie danych odbywa się na stacji roboczej. Serwer wysyła pliki danych, które zostaną przetworzone przez system zarządzania bazami danych, działający na stacji roboczej.

W tym miejscu należy także zdefiniować terminy serwer i klient. Termin serwer używany jest zarówno na określenie komputera podającego pliki (serwer plików), jak i serwera danych z bazy danych, zmagazynowanej w jego pamięciach masowych. W architekturze klient-serwer właściwe rozumienie terminu serwer dotyczy logicznego procesu dostarczania danych z bazy. Podobnie termin klient nie powinien być rozumiany jako sprzęt (komputer), z którego serwer bazy otrzymuje zapytania. Klient może inicjować komunikację z serwerem, zażądać określonych usług, przyjąć wyniki i potwierdzić spełnienie wymagań. Serwer nigdy, z własnej inicjatywy, nie inicjuje komunikacji z klientami. Jeden serwer może obsługiwać wielu klientów.

Rozproszone aplikacje i bazy danych

Termin klient-serwer jest często błędnie używany zamiast terminu "rozproszony". Wynika to w znacznej mierze z faktu, że architektura klient-serwer jest dobrą platformą do rozproszenia aplikacji lub danych z bazy na kilka serwerów. Głównym celem każdej aplikacji typu klient-serwer jest dostęp do danych, którymi zarządza serwer. Może nim być równie dobrze lokalny komputer osobisty, jak zdalny średni lub duży komputer IBM. Każdy z nich wykonuje część pracy związanej z dostępem do danych. Dlatego często niesłusznie utożsamiane są terminy "rozproszone bazy danych" i "rozproszone przetwarzanie". Rozproszone przetwarzanie wymaga bowiem wykonywania części aplikacji na wielu serwerach, podczas gdy rozproszenie bazy danych polega na przechowywaniu jej na różnych serwerach.

Rozproszone przetwarzanie

Celem każdego systemu rozproszonego jest dostęp do danych lokalnych i zdalnych. Dostęp ten można realizować na cztery sposoby. Kolejność prezentacji odpowiada narastającemu stopniowi komplikacji systemu.

Zdalne żądanie danych: polega na przesłaniu pojedynczego żądania danych (np. zapytania SQL) do pojedynczego serwera.

Zdalna transakcja: polega na zdalnym wykonaniu przez jeden serwer całej transakcji, składającej się z wielu zapytań.

Rozproszona transakcja: polega na wykonaniu transakcji, składającej się z wielu zapytań, przez wiele serwerów (lokalnych lub zdalnych). Każde zapytanie jest przetwarzane przez oddzielny serwer, ale różne zapytania w tej samej transakcji mogą być przetwarzane przez różne serwery.

Rozproszone zapytanie: polega na wykonywaniu nawet pojedynczego zapytania przez wiele serwerów. Użytkownik nie musi wiedzieć w jaki sposób jego zapytanie jest realizowane.

Z tych czterech sposobów wykonywania przetwarzania rozproszonego, jedynie ostatni (rozproszone zapytanie) kwalifikuje się do realizacji rozproszonej bazy danych.

Rozproszone bazy danych

W praktyce istnieje kilka sposobów rozproszenia danych z bazy na kilka serwerów. Niektóre z nich realizowane są automatycznie przez system zarządania bazami danych, inne wykonywane są na żądanie administratora systemu lub użytkownika.

Wyciąg danych z bazy: użytkownik żąda przekopiowania niektórych tabel z bazy do konkretnego serwera. Aby dokonać tej operacji należy wykonać zdalną transakcję lub zdalne zapytanie.

Obraz bazy: system zarządzania bazą danych wykonuje wyciąg danych z bazy i kopiuje go do innego serwera. Może to być realizowane co określony czas, np. raz na dzień. Sposób ten jest stosowany jedynie dla odczytu danych z bazy.

Replikacja: system zarządzania bazą danych aktualizuje kilka kopii określonych tabel z bazy na różnych serwerach. Aplikacja korzystająca z tych danych na ogół nie wie, gdzie dane faktycznie rezydują. Aktualizowanie kopii odbywa się synchronicznie lub asynchronicznie z procesem wykonywania transakcji na tych danych.

Fragmentacja: tabele dzieli się w pionie (wybranie podzbioru pól) lub w poziomie (wybranie niektórych rekordów) i części przechowuje na różnych serwerach. Sposób podziału powinien być tak dobrany, aby dane rezydowały możliwie blisko miejsca, w którym są używane.

Komunikacja klient-serwer

Komunikacja między serwerem a klientem może odbywać się przez różne media i następować za pośrednictwem różnych protokółów. Może to być równie dobrze protokół sieci lokalnej LAN, czy sieci rozległej WAN lub mechanizmy systemu operacyjnego: potoki etykietowane, przekazywanie komunikatów (message passing), skrzynki pocztowe, dzielona pamięć, itd. Jednakże architektura aplikacji klient-serwer nie powinna być zależna od użytych metod komunikacji i rodzaju fizycznego medium, łączącego klienta i serwer.

Również zmiana sposobu połączenia nie powinna w żaden sposób wpłynąć na działanie systemu. Służą do tego mechanizmy pozwalające na budowanie aplikacji typu klient-serwer, bez potrzeby poznawania specyfiki konkretnych sieci komputerowych, bądź mechanizmów systemowych. Polegają one na wprowadzeniu pewnej warstwy oprogramowania, ukrywającej przed programistą skomplikowane mechanizmy sieciowe i komunikacyjne, a prezentującej mu jedynie standardowe funkcje API (Applications Programming Interface), niezależne od używanego protokółu sieciowego. Ta warstwa oprogramowania nosi zwykle nazwę middleware, jako że znajduje się między aplikacją a siecią.

Programy z grupy middleware stosują różne metody dostępu do serwera danych. Istnieją trzy podstawowe sposoby, o zbliżonych właściwościach i możliwościach, chociaż o różnym pochodzeniu.

Zdalne wywoływanie procedur (Remote Procedure Call). Zostało opracowane w początku lat 80. i jest używane do tej pory w produktach firm Sun, Hewlett-Packard i in. Początkowo służyło do łączenia aplikacji działających na platformach unixowych, potem zaś zostało rozszerzone na inne platformy sprzętowe i systemy operacyjne.

RPC polega na wywołaniu przez aplikację procedury, w taki sam sposób, jak wywołuje się procedury lokalne. Jednakże procedura jest w rzeczywistości wykonywana na serwerze zdalnym. RPC jest aktywnie wspierane przez konsorcjum producentów oprogramowania Open Software Foundation (OSF). W ramach jednolitego środowiska Distributed Computing Environment (DCE) zaleca ono stosowanie RPC jako uniwersalnej metody komunikacji między różnymi platformami obliczeniowymi. Główną wadą RPC jest założenie, że sieć jest zawsze dostępna, co powoduje jego wrażliwość na uszkodzenia i zablokowanie sieci.

Kolejkowanie komunikatów (Message Queuing). Zostało opracowane z myślą o tych firmach, które pracują w luźno powiązanych strukturach sieciowych, złożonych z wysp niejednorodnych komputerów. Kolejkowanie komunikatów jest oparte na funkcjach API wysokiego poziomu i wykorzystuje bufory do zapamiętania i ustawienia w kolejkę komunikatów, przesyłanych między aplikacjami. Może korzystać z różnych rodzajów komunikacji między aplikacjami: synchronicznej, asynchronicznej i konwersacyjnej. Kolejki gwarantują dostarczenie komunikatu, nawet w przypadku awarii sieci: komunikaty są po prostu zapamiętane aż do chwili, gdy połączenie jest sprawne.

Metoda kolejkowania komunikatów, mimo że została opracowana przez stosunkowo niewielkie firmy, zdobyła uznanie największych producentów oprogramowania, w tym IBM, DEC, PeerLogic i in. Uzyskała też nową nazwę ţ Message Oriented Middleware (MOM).

Komunikacja obiektowa. Technika o nazwie Object Request Broker - ORB (co w dość dowolnym tłumaczeniu oznacza "maklera żądań obiektowych") polega na zupełnie innym podejściu do środowiska obliczeniowego - jest ono traktowane jako zbiór obiektów. ORB zarządza przesyłaniem komunikatów między obiektami w sieci.

Obiekt zawiera zarówno dane, jak i metody ich przetwarzania. Programista może zmienić zawartość obiektu, nie wpływając na inne obiekty, ani na sposoby komunikowania się z nimi. Obiekt ukrywa swoją zawartość pod prostym interfejsem, zrozumiałym dla innych obiektów. ORB polega na żądaniu wykonania przez obiekt określonych operacji po przesłaniu do niego komunikatu. Znana z programowania obiektowego enkapsulacja obiektu pozwala ukryć istniejące od dawna dane w środowisku programowania obiektowego, przez nadanie im interfejsu obiektowego.

W metodzie ORB korzysta się z funkcji API wysokiego poziomu, pozwalających na ukrycie skomplikowanych mechanizmów komunikacji przed twórcami aplikacji. Grupa ponad 400 producentów oprogramowania Object Management Group (OMG) stworzyła ogólną specyfikację Common Object Request Broker Architecture (CORBA), zawierającą opis funkcji API, za pomocą których można korzystać z ORB.

ORB stanowi bazę nowych systemów (Distributed Object Management - DOM) zarządzania rozproszonymi aplikacjami obiektowymi. Najwięksi producenci w przemyśle komputerowym - IBM, DEC, NCR, HP i wiele mniejszych firm wspierają aplikacje typu DOM.

Obecnie obserwuje się rosnące zainteresowanie twórców oprogramowania takimi narzędziami, które będą zawierały te trzy metody komunikowania między aplikacjami. Dlatego OSF i OMG dążą do opracowania specyfikacji obejmującej kolejowanie komunikatów w DCE i CORBA. Z drugiej strony twórcy produktów opartych na kolejkowaniu komunikatów obiecują, że ich nowe produkty będą zgodne ze specyfikacją CORBA.

Zarządzanie rozproszonymi zasobami sieci

W środowisku sieciowym, zwłaszcza niejednorodnym sprzętowo, ważną rolę odgrywa skuteczne zarządzanie nie tylko sprzętowymi zasobami sieci: serwerami, stacjami roboczymi oraz aktywnymi elementami sieci (huby, bridge), ale także warstwą programową (licencje, ochrona danych). Od dobrego rozwiązania tego problemu zależy, w znacznie większej mierze niż się zwykle sądzi, sukces lub porażka rozwiązania klient-serwer.

W celu rozwiązania tych problemów konsorcjum producentów oprogramowania Open Software Foundation (OSF) opracowuje specyfikację Distributed Management Environment (DME). Celem jest uzyskanie technologii i produktów o wspólnym interfejsie i zestawie funkcji API oraz narzędzi do opracowywania systemów zarządzania sieciami. Produkty te nie będą gotowe wcześniej niż pod koniec przyszłego roku, ale już obecnie wiele firm dostarczyło narzędzia dobrze nadające się do zarządzania systemami z przetwarzaniem rozproszonym.

W skład DME wchodzą programy do zarządzania obiektowymi bazami danych w sieciach rozproszonych, pozwalające na tworzenie jednolitych struktur katalogowych, programy do zapewnienia bezpieczeństwa dostępu do danych w sieci (rejestracja wykonywanych operacji), programy do określania i kontroli liczby działających licencji, itp. W zakresie zarządzania sprzętowymi zasobami sieci korzysta się na ogół z protokółu SNMP (Simple Network Management Protocol), pozwalającego na aktywne zbieranie informacji o zasobach sieci.

Konsorcjum OSF przewiduje, że produkty opracowane w ramach DME pozwolą na zarządzanie zasobami komputerowymi w dowolnym środowisku sprzętowym i pod dowolnym systemem operacyjnym.

Jaka jest przyszłość przetwarzania klient-serwer?

Według oceny p. Esther Dyson (EDventure Holding Inc.), obserwującej rynek informatyczny w USA i Europie, nie ma innej drogi dla aplikacji w biznesie niż praca w trybie klient-serwer. Nawet ci producenci oprogramowania, którzy do tej pory nie zajmowali się tą tematyką (np. Microsoft), opracowują strategię rozwoju narzędzi i programów do przygotowania aplikacji klient-serwer.

Różnorodność i liczba problemów, które muszą rozwiązywać twórcy programów typu klient-serwer jest jednak tak duża, że nie ma obecnie żadnego dużego producenta oprogramowania, który byłby w stanie sam rozwiązywać problemy przetwarzania klient-serwer. Stąd potrzeba specjalizacji i korzystania z usług firm - integratorów systemów, rozwiązujących problemy na miejscu, u użytkownika.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200