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. Równie dobrze może to być protokół sieci lokalnej LAN czy sieci rozległej WAN lub mechanizmy systemu operacyjnego: potoki etykietowane, przekazywanie komunikatów, 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.

Komunikacja między serwerem a klientem może odbywać się przez różne media i następować za pośrednictwem różnych protokółów. Równie dobrze może to być protokół sieci lokalnej LAN czy sieci rozległej WAN lub mechanizmy systemu operacyjnego: potoki etykietowane, przekazywanie komunikatów, 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 znacząco wpływać 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 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 protokoł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)

Opracowano na 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ś rozszerzono na inne platformy sprzętowe i systemy operacyjne.

RPC umożliwia wywołanie przez aplikację usług serwera, w taki sam sposób jak wywołuje się procedury lokalne, chociaż procedura obsługi 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)

Opracowano 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 oraz 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 razie 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 na ukrycie istniejących od dawna danych 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 licząca 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 kolejkowanie 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.

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

TOP 200