Opis architektury klient serwer

advertisement
WDRAŻANIE SYSTEMÓW
WIELOWARSTWOWYCH
1
SPIS TREŚCI
Strona
1. WSTĘP.........................................................................................
3
2. ZANIM POWSTAŁA ARCHITEKTURA WIELOWARSTWOWA...
3
3. ARCHITEKTURA ANSI/SPARC………………………………………
4
4. ARCHITEKTURY WIELOWARSTWOWE………………………….
5
4.1 ARCHITEKTURA DWUWARSTWOWA (klient/serwer) ……….
5
4.2 ARCHITEKTURA DWUIPÓŁWARSTWOWA……………………...
8
2
4.3 ARCHITEKTURA TRÓJWARSTWOWA……………………………
9
LITERATURA .............................................................................
16
3
WSTĘP
Sztuka projektowania architektury systemowej dąży do bardzo praktycznego celu:
udostępniania informacji klientom danego systemu. Za początki baz danych niektórzy
uważają czasy, w których cywilizacja sumaryjska i egipska zaczęły korzystać z pisma
klinowego. Komputery pozwoliły jednak na przechowywanie i manipulowanie zawartymi w
bazie danymi w sposób bardzo wyrafinowany.
Architektura systemu to pierwszy wymiar procesu projektowania bazy danych, forma
abstrakcyjna wykorzystywana podczas całego procesu tworzenia systemu. Architektura
systemów bazodanowych przebyła długą drogę od czasu swoich narodzin w latach 60-tych.
Wczesne bazy oparte na modelu hierarchicznym stopniowo ewoluowały w sieciowe zestawy
wskaźników, następnie w zbiory relacji i w końcu w grupy obiektów.
Poszczególnymi modelami architektur systemów bazodanowych były kolejno:
- CODASYL DBTG (lata 60 –70)
- Model ANSI/SPARC (American National Standard Institute/Standard Planning and
Requirements Committee) –lata 70
- Modele wielowarstwowe, obiektowe, rozproszone – lata 80. i 90.
ZANIM POWSTAŁA ARCHITEKTURA WIELOWARSTWOWA
Z historycznego punktu widzenia w początkach informatyki w firmach usługowych
czy też handlowych sama baza danych często ograniczała się do jednego komputera, na
początku często był to zwykły PC, który służył do wszystkiego: wystawiania faktur, pisania
dokumentów, czy też służył do przechowywania adresów klientów, aby móc prowadzić z
nimi korespondencję. Generalnie początki informatyzacji firm czy przedsiębiorstw polegały
na pewnej automatyzacji prac biurowych i próbach gromadzenia w jednym miejscu
wybranych informacji.
Stopniowy rozwój spowodował, że system oparty o jeden komputer lub pojedyncze
komputery przestał być wystarczający. Nie wystarczał zarówno pod względem pojemności,
jak i możliwości automatyzacji prac poza typowymi czynnościami biurowymi. Początkowo
rozwiązywano ten problem poprzez zwiększanie ilości komputerów i powielanie
oprogramowania. Bardzo szybko pojawił się jednak problem o wiele poważniejszy, a
mianowicie problem spójności danych. Problem polegał na tym, w jaki sposób spowodować,
aby zmiany wprowadzone w jednym komputerze były natychmiast widoczne na pozostałych
komputerach korzystających z tych samych danych. Wiązało się to z konieczności bieżącego
śledzenia stanu organizacji, stanu finansowania czy też płynnej obsługi klientów. Równolegle
z tym problemem traktowanym jako problem techniczny pojawiły się zagrożenia związane ze
stanem organizacyjnym przedsiębiorstw. Oczywiste jest, że rozwiązanie takiego problemu
musi pociągnąć za sobą dość poważne zmiany organizacyjne.
Pierwszym krokiem było łączenie komputerów w sieci tak, aby mogły one wymieniać
między sobą informacje, czy też mogły po prostu komunikować się ze sobą. Spowodowało to
między innymi ewolucję systemów baz danych, które musiały dostosować się do pracy w
sieci. Zmiany rozwinęły się w dwóch kierunkach. Z jednej strony zaczęto produkować coraz
większe i szybsze komputery umożliwiające jednoczesną obsługę wielu klientów. Powstała
architektura typu host/terminal składająca się z dużego komputera często klasy mainframe, do
którego podłączonych było wiele terminali. Terminal taki stanowiła prosta końcówka
umożliwiająca jedynie w sposób znakowy wyświetlanie informacji i wprowadzanie danych.
Wszystkie obliczenia natomiast, zapewnianie współbieżności, przechowywanie informacji
odbywało się na tym jednym dużym komputerze.
Drugi kierunek to rozwinięcie koncepcji wspólnego dostępu tylko do pewnych
zespołów. Powstawały sieci słabszych (w porównaniu z komputerami klasy mainframe)
4
komputerów, gdzie jeden z nich był odpowiedzialny za przechowywanie danych.
Przechowywanie to ograniczało się zazwyczaj do przechowywania pewnej grupy plików, do
których dostęp współbieżny miały wszystkie komputery. Na takim komputerze były
zaimplementowane mechanizmy umożliwiające spójne nanoszenie poprawek i uaktualnianie
danych. Polegało to na wprowadzeniu takiego mechanizmu, który uniemożliwia dostęp do
danych, gdy są one w trakcie obróbki przez któregokolwiek z użytkowników.
Mechanizm taki był realizowany na różne sposoby. Jednym z nich np. było zainstalowanie w
systemie baz danych specjalnego programu zapewniającego arbitralnie dostęp do danych.
Innym zainstalowanie w systemie operacyjnym mechanizmu nadawania atrybutów plikom
pozwalającego na nadzorowanie jego udostępniania i dokonywania zmian zawartości.
Wszystkie te rozwiązania miały zazwyczaj jedną zasadniczą wadę - były mało elastyczne.
ARCHITEKTURA ANSI/SPARC – podstawa projektowania systemu opartego na
bazach danych
Najważniejszą ze wczesnych prób standaryzacji architektury systemowej była
trójschematowa architektura ANSI/SPARC. Dzieli ona system bazodanowy na trzy modele:
wewnętrzny, koncepcyjny i zewnętrzny. Celem przewodnim twórców tej architektury jest
ustanowienie wszystkich jej warstw niezależnymi od siebie. Podejście to umożliwia
uodpornienie systemu na zmiany w strukturach fizycznych czy koncepcyjnych. Po zmianie
lub dodaniu nowej struktury magazynowej nie trzeba przebudowywać całego systemu. Ta
koncepcja niezależności danych była głównym punktem wczesnej analizy metod
projektowania i zarządzania bazami danych i nie straciła swojej ważności aż po dzień
dzisiejszy. Jest ona fundamentem, na którym bazują nowoczesne metody projektowania.
Model koncepcyjny – reprezentuje informacje zawarte w bazie danych. Struktury schematu
koncepcyjnego mogą zawierać struktury, operacje i ograniczenia dotyczące modelu danych.
W bazie relacyjnej np. w skład modelu koncepcyjnego wejdą tabele, reguły integralności oraz
język SQL. W bazie obiektowo relacyjnej schemat koncepcyjny obejmie wszystkie struktury
relacyjne oraz definicje typów danych i klas, a także metody reprezentujące zachowania
obiektów. Model koncepcyjny bazy zorientowanej obiektowo to definicje klas, ich atrybuty
oraz metody.
Model wewnętrzny – to rzeczywista, fizyczna struktura bazy danych. Zawiera indeksy,
uporządkowania pól, zestawy znaków itp. Schemat wewnętrzny stanowi uzupełnienie
schematu koncepcyjnego. Jest implementacją niskopoziomową wyposażoną w metody
efektywnego dostępu do danych za pomocą metod takich jak np. indeksowanie kolumn.
Odwzorowanie schematu koncepcyjnego na fizyczny zabezpiecza przed skutkami zmian
dokonywanych w metodach fizycznego zapisu bazy. Nowe indeksy, zmienione struktury
magazynowe czy zmiany w kolejności zapisywania pól nie wpływają na modele wyższego
poziomu. Tak właśnie realizuje się niezależność danych.
Model zewnętrzny – stanowi kolekcję perspektyw wykorzystywanych przez aplikacje
korzystające z zasobów bazy. Dane prezentowane użytkownikowi odwzorowywane są z
zapisu fizycznego na postać ujętą w schemacie koncepcyjnym. Pojedynczy użytkownik
systemu może mieć dostęp do całości lub najczęściej tylko wydzielonej części danych
systemu.
Architektura trójschematowa miała i nadal ma ogromny wpływ na projektowanie
systemów bazodanowych. Rozdzielenie schematów koncepcyjnego i wewnętrznego
odseparowuje problemy związane z wykorzystywanymi rozwiązaniami sprzętowymi i
oprogramowaniem do abstrakcyjnego modelu danych. Konstruując modele logiczne nie
5
trzeba martwić się o parametry fizyczne, ścieżki dostępu, struktury pliku, optymalizację
systemu.
ARCHITEKTURY WIELOWARSTWOWE
Charakterystyka
Lata 80. Stały pod znakiem rozszerzającej się dostępności komputerów osobistych,
coraz większej miniaturyzacji maszyn i łączeniu ich w sieci lokalne. Postęp techniczny
umożliwił rozproszenie obliczeń na szereg komputerów, zamiast wykonywania ich na
pojedynczym systemie klasy mainframe. Na początku podejście to przerodziło się w
architekturę klient/serwer, której rozwinięciem stała się później rozproszona architektura
klient/serwer, umożliwiająca wprowadzenie większej ilości serwerów obsługujących bazę
danych.
Z początkiem lat 90, pojawiło się tzw. partycjonowanie aplikacji.
Jest to następny poważny krok w rozwoju architektury klient/serwer. Możliwe stało się
bowiem uruchamianie części aplikacji na komputerze-kliencie a części na serwerze, do
którego dostęp mieli pozostali klienci. Jedną z popularnych metod zastosowania tej
technologii jest przetwarzanie transakcji(Transaction Processing Monitoring), w której
obsługą transakcji zajmuje się wydzielony serwer middleware, a cała architektura zyskała
miano trójwarstwowej.
Parę lat później w związku z szeroką dostępnością Internetu, architektura trójwarstwowa
przeszła jeszcze jedną transformację. Modyfikowano mianowicie oprogramowanie
middleware, dla rozproszonych aplikacji obiektowych, co zaowocowało możliwością
przeniesienia większej części obliczeń z klientów na serwery. Możliwe stało się również
rozpraszanie obiektów na różne komputery, co dało początek rozproszonej wielowarstwowej
architekturze obiektowej.
ARCHITEKTURA DWUWARSTWOWA (klient/serwer)
Dynamicznie rozwinęła się w końcu lat 80-tych. W myśl tej koncepcji systemy oparte
na tej architekturze podzielono na dwie części. Z jednej strony została wydzielona pewna
część systemu odpowiedzialna za przechowywanie danych i zachowanie ich pełnej spójności.
Z drugiej strony wydzielono pewne aplikacje czy procesy, które pobierają dane od
użytkownika wyświetlają je i przetwarzają, a następnie albo przesyłają je do serwera w celu
zapamiętania, albo generują pewne zapytania w celu uzyskania konkretnych informacji z
komputera-serwera. W ten sposób cały proces przetwarzania danych mamy podzielony na
dwie części. Z jednej strony mamy serwer, który przechowuje dane, ale potrafi także je
wyszukiwać z przechowywanej bazy na podstawie zapytań poszczególnych komputerów
(klientów), a z drugiej strony mamy aplikacje klienta, które tak naprawdę nic nie muszą
wiedzieć o fizycznej strukturze danych przechowywanych na serwerze o sposobie ich
zarządzania o liczbie użytkowników, a muszą jedynie umieć wysłać zapytanie do bazy,
wyświetlić informacje na ekranie lub wysłać do serwera polecenie aktualizujące dane.
Głównym zadaniem architektury klient/serwer jest ograniczenie ilości danych przesyłanych
przez sieć. Tradycyjny serwer plików, w momencie otrzymania prośby o udostępnienie
pewnego pliku, prześle całą jego zawartość do odpowiedniego klienta. Omawiana tu
architektura pozwala na uściślenie zarówno zapytania jak i odpowiedzi, tak aby klient
otrzymał dokładnie te dane na których mu zależy.
Oczywiście system o architekturze klient/serwer można umieścić na jednym komputerze.
Praca odbywa się wtedy dzięki możliwość przełączania procesów. Przykładem takiego
6
systemy może być system X-Window czyli graficzne środowisko pracy systemów unixowych
i pochodnych.
Jest to jednak rozwiązanie nietypowe.
Typowym rozwiązaniem jest oczywiście kilka komputerów pracujących w sieci. W takiej
konfiguracji mamy komputer (często jest to maszyna unixowa) wyposażony w serwer bazy
danych, czyli pewne oprogramowanie umożliwiające przechowywanie i zarządzanie danymi.
Z drugiej strony mamy aplikacje klienta, opartą najczęściej na środowisku graficznym typu
Windows, realizującą komunikację z użytkownikiem tzn. prezentującą dane, pozwalającą
wprowadzać i uaktualniać informację zadawać nietypowe zapytania dotyczące
pogrupowanych informacji przechowywanych na serwerze. Zastosowanie środowiska
graficznego znacznie wzbogaciło możliwości prezentacyjne, a jednocześnie pozwoliło na
bardziej naturalną komunikację z użytkownikiem z wykorzystaniem wykresów, map
cyfrowych, a także z wykorzystaniem rozwiązań multimedialnych, co pozwala na
przechowywanie w bazie danych obrazów i dźwięków.
zalety i wady
Tworząc system klient/serwer musimy zastanowić się nad tym co zyskujemy, a co
tracimy wybierając taką właśnie architekturę.
Zyskujemy przede wszystkim dużą elastyczność całego systemu, gdyż możemy pracować z
różnymi środowiskami graficznymi równocześnie, możemy operować danymi w sposób
spójny a jednocześnie niezależny od ich bieżącej struktury. Zarządzając z kolei samym
serwerem danych jesteśmy uniezależnieni od konkretnych użytkowników, od problemów
związanych ze wspólnym dostępem, a co za tym idzie możemy skoncentrować się na samej
strukturze informacji, na strukturach biznesowych, na współbieżności i efektywności.
Ponadto, gdy firma pracująca z takim systemem rozwija się i ilość informacji przechowywana
na serwerze powoduje, że staje się on mniej wydajny, możemy wymienić jednostkę serwera
na wydajniejszą maszynę, możemy zmienić rodzaj oprogramowania serwera, nie powodując
żadnych zmian interfejsu użytkownika. Nadal pracują oni w znany sobie sposób. Zyskiem jest
także fakt, że w przypadku zmiany interfejsu użytkownika istniałaby konieczność ponownego
przeszkolenia personelu, co oczywiście pociąga za sobą wzrost kosztów. W przypadku
dużych organizacji, np., wielooddziałowego banku, koszty te są znaczne. Kolejnym
wygodnym elementem jest możliwość wyboru różnego dostępu do danych w zależności od
kategorii użytkowników mających z nimi kontakt. Ta sama baza danych może obsługiwać
zarówno pracowników kas dużego supermarketu, którzy podliczają sumy na podstawie
odczytanych kodów paskowych towarów, a z drugiej strony może obsługiwać magazyn, gdzie
pracownik musi mieć możliwość wystawienia faktury, zaznaczenia (wpisania) nowej
dostawy, czy właściwego rozmieszczania towarów na półkach. Jednocześnie menedżer
chciałby znać aktualne wpływy finansowe, sprawdzić, jakie kategorie produktów przynoszą
największe zyski, czyli mieć dostęp do bardziej przekrojowych informacji.
Każdy zatem z tych pracowników wymaga innego interfejsu, a tak naprawdę nieco innego
oprogramowania Pracownikowi kasy wystarczy prosty czytnik kodów paskowych i
uproszczony terminal, na którym wyświetlany będzie jedynie wykaz sprzedanych towarów i
ich podsumowanie. W przypadku magazynu pracownik musi mieć dostęp do informacje dużo
bardziej rozbudowanej, często potrzebuje informacji z bazy danych klientów i dostawców,
musi mieć możliwość zarządzania stanem magazynu, umieć określić czego brakuje, co należy
zamówić, a czego jest w nadmiarze i należy obniżyć cenę ze względu na możliwość
przeterminowania itd. Z kolei zarządzanie firmą na wysokim poziomie wymaga bardzo
przekrojowych danych, związanych z zarządzaniem a nie szczegółowym stanem
poszczególnych stanowisk kasowych .
7
Tak więc mając wspólną bazę danych możemy tworzyć szereg różnych aplikacji klienckich,
które mając dostęp do wspólnych danych operują na nich w zupełnie inny sposób. Pomimo
bardzo istotnych i wymiernych korzyści wybór tej technologii nie odbywa się nigdy bez strat.
Po pierwsze stopień komplikacji jest dużo większy niż pojedynczy pakiet programów
przystosowany do pracy na komputerach pracujących w jakiejkolwiek sieci. Musimy przy
pisaniu programów zapewniać mechanizmy kontroli spójności, wielodostępu, co przy
rozległych systemach nie jest sprawą trywialną. Po drugie pisząc aplikacje klienckie musimy
zapewnić ich właściwe komunikowanie się z serwerem bazy danych. Aplikacja kliencka nie
ma bezpośredniego dostępu do danych elementarnych, a jedynie za pomocą specjalnego
języka (najczęściej jest to SQL) komunikuje się z serwerem zadając pytania, nanosząc pewne
poprawki. Przy architekturze klient/serwer musimy także pamiętać o odpowiednich
połączeniach sieciowych - o pewnych standardach, czyli zapewnieniu prawidłowego
porozumiewania się komputerów z różnymi systemami. W architekturze klient/serwer
zakłada się, że poszczególne komponenty środowiska mogą pochodzić od różnych
dostawców. Wynika, to ze specjalizacji firm produkujących poszczególne komponenty
systemów informatycznych. Stąd celowym jest dobieranie najlepszych w swojej klasie
produktów, aby tworzyć wydajne systemy. Samo wybieranie komponentów jest poważnym
problemem, gdyż musimy ze sobą uzgodnić pewien standard wymiany informacji. Na
poziomie serwera bazy danych najczęściej takim standardem jest język SQL, chociaż pomimo
przyjętych pewnych norm każdy z serwerów operuje pewnymi rozszerzeniami. Nie
korzystanie z tych rozszerzeń powoduje, że tracimy pewną możliwość, która jest
zaimplementowana bardzo wydajnie i decyduje o wyższości danego serwera nad innym.
Korzystanie z tych rozszerzeń powoduje często mniejszą skalowalność i przenośność
aplikacji niż w przypadku standardowego SQL.
Rozwarstwienie
Środowisko klient/serwer z jednej strony elastyczne i wydajne ma swoje ograniczenia.
Okazuje się, że tworzenie bardzo dużych systemów, gdzie aplikacja kliencka musi realizować
bardzo dużo funkcji, w których mamy do czynienia nie z jednym, ale z wieloma serwerami
danych rozproszonymi między oddziałami danej organizacji zaczyna nastręczać pewne
trudności. Wiąże się to z tym, że musimy zapewnić zarówno wydajność wykonywania
pewnych operacji, jak i spójność danych. Z kolei rozbudowywanie aplikacji klienckiej
powoduje ich ogromną czasami złożoność i wysoki stopień komplikacji, przez co zwiększają
się jej wymagania sprzętowe.
W związku z tym pojawiła się tendencja do wydzielania pewnych płaszczyzn przetwarzania.
Jeżeli przyjrzymy się strukturze informacji w organizacji czy firmie, to okaże się, że możemy
tę informację podzielić na pewne warstwy. Z jednej strony mamy samą strukturę informacji,
czyli fizycznie rzecz ujmując strukturę bazy danych - strukturę tablic, strukturę rekordów,
listę pól, typy wartości, jakie mogą przyjmować dane. Na tą strukturę nakłada się warstwa
tzw. reguł biznesowych. Są to pewni zależności pomiędzy danymi właściwe dla konkretnej
organizacji lub właściwe w danym okresie istnienia organizacji. Taką regułą może być np.
algorytm naliczania oprocentowania dla kredytów, sposób udzielania zniżek na bilety lotnicze
itd. Są to więc pewne algorytmy postępowania nie związane w sposób bezpośredni z danymi,
ale ich sprecyzowanie jest konieczne dla prawidłowego funkcjonowania firmy. Trzecia
warstwa to tzw. warstwa prezentacyjna określająca sposób wprowadzania i wyświetlania
danych. Określa ona np. czy pewne dane przedstawiamy w postaci listy, czy pól do
wprowadzania, czy data ma mieć strukturę dzień-miesiąc-rok, czy też rok-miesiąc-dzień
(choć jest to niezależne od sposobu przechowywania danych w bazie), czy gdy użytkownik
8
kliknie myszą na nazwisku klienta to wyświetlą się informacje o operacjach
przeprowadzonych na jego koncie itp.
Widać z tego, że sama struktura informacji narzuca nam podejście wielowarstwowe do
tworzenia systemu informatycznego. Wyraźnie wyłoniła się pewna warstwa, która nie
dotyczy ani samej struktury informacji ani sposobu jej prezentacji, natomiast dotyczy reguł
zarządzania tą informacją. Powstała wobec tego idea, która zakłada umieszczenie tychże reguł
biznesowych w odpowiednim miejscu, czy też na odpowiedniej płaszczyźnie architektury
klient/serwer.
W przypadku typowej architektury klient/serwer mamy do czynienia z architekturą
dwuwarstwową (warstwa klienta i warstwa serwem); reguły biznesowe najczęściej są
umieszczane w aplikacji klienckiej. Zmiana tych reguł powoduje konieczność dokonania
wymiany wszystkich aplikacji klienckich bez możliwości równoległego funkcjonowania
starej i nowej wersji, a w najlepszym razie odpowiedniego ich skonfigurowania.
ARCHITEKTURA DWU I PÓŁ WARSTWOWA
Problemy powyższe przyczyniły się do powstania nowego trendu wśród producentów baz
danych. Trendu mającego na celu wbudowanie mechanizmów obsługi reguł biznesowych i
szerszą obróbkę danych już na poziomie SZBD.
Powstała idea przeniesienia pewnej warstwy funkcjonalnej, czyli sposobów zarządzania i
przetwarzania informacjami na stronę serwera tak, aby aplikacje klienckie dostały jedynie
pewną listę funkcji, operacji, żądań, jakie mogą realizować, a nie miały bezpośredniego
dostępu do danych. Takie umieszczenie po stronie serwery było możliwe dzięki temu, że
wiele serwerów baz danych wyposażono w mechanizm zwany procedurami wbudowanymi i
trigerami, czyli pewnymi procedurami, które uruchamiają się automatycznie przy
zachodzeniu pewnych zjawisk. Trigery powodują np, że przy zmianie pewnych danych inne
się uaktualniają; gdy usuwamy z naszej bazy informacje o kliencie, to chcemy usunąć
wszystkie zamówienia jakie on złożył itd. Procedury te powinny uruchamiać się
automatycznie, bez ingerencji użytkownika.
W takiej architekturze mamy zatem do czynienia z aplikacją kliencką, która nie odwołuje się
bezpośrednio do bazy danych, ale jedynie wywołuje pewne operacje w serwerze danych,
który bądź udostępnia pewne dane bądź realizuje wywołane procedury bazodanowe. Drugim
elementem są zaimplementowane w bazie danych reguły biznesowe wspólne dla wszystkich
aplikacji klienckich. Wymiana takiej reguły powoduje, że sposób funkcjonowania aplikacji
klienta zmieni się dla każdego klienta jednocześnie. Taką aplikację z warstwą kliencką i
warstwą serwery bazy danych, który nie ogranicza się tylko do przechowywania danych, ale
również realizuje funkcje biznesowe nazywamy często architekturą dwu i pół warstwową.
Wady
Jednak istnieją pewne wady tej architektury. Język procedur wbudowanych i trigerów jest
dość skomplikowany, a najczęściej jest to "dialekt" języka SQL z pewnymi rozszerzeniami
dotyczącymi przetwarzania instrukcji strukturalnych. Niestety każdy producent serwerów baz
danych lansuje nieco odmienny format tego języka i trudno znaleźć dwie identyczne pod tym
względem bazy danych. Stąd też istnieje groźba przepisywania od nowa procedur w
przypadku zmiany serwera bazy danych. Nie jest to szczególnie skomplikowane, gdyż
większość procedur ma podobne mechanizmy, ale różnią się składnią. Ponadto często reguły
biznesowe są bardziej skomplikowane niż te podane jako przykłady i do ich realizacji nie
zawsze najodpowiedniejszy jest język procedur wbudowanych serwera. Wygodniejsze
9
okazują się języki trzeciej generacji.Stąd istnieje potrzeba wprowadzania kodu poza strukturą
serwera bazy danych.
Działanie aplikacji w architekturze klient / serwer wymaga sprawnej komunikacji
pomiędzy stacją roboczą, a serwerem. Informacja nie jest przekazywana ciągłym strumieniem
lecz w pakietach. Wysłany pakiet dociera do odbiorcy w różnym czasie:
 w sieci lokalnej (LAN) jest to czas rzędu milisekund
 w sieci rozległej (WAN) czas ten dochodzi do kilkuset milisekund
Operacje wykonywane na stacji roboczej wymagają wielokrotnej komunikacji z serwerem.
Na przykład proste dopisanie rekordu wymaga czterokrotnego przesłania pakietu
informacyjnego (lub grupy pakietów). Kolejny pakiet może zostać wysłany dopiero wtedy,
gdy poprzedni dotrze na miejsce. W sieci rozległej dokonanie tej operacji może więc zostać
wydłużone o niemal sekundę z samej tylko konieczności czterokrotnego oczekiwania na
pakiet informacji.
Przyczyna opóźnienia tkwi w konieczności wielokrotnej czasochłonnej komunikacji
pomiędzy stacją roboczą, a serwerem. Opóźnienie to jest więc niezależne od mocy
obliczeniowej serwera, mocy obliczeniowej stacji roboczej lub też przepustowości łącza.
Rozwiązanie problemu wymaga zmniejszenia częstotliwości przesyłania informacji pomiędzy
stacją roboczą, a serwerem. W praktyce jest to realizowane poprzez zastosowanie serwera
aplikacji.
ARCHITEKTURA TRÓJWARSTWOWA
Rodzi się, więc pojęcie trzeciej warstwy, warstwy, która byłaby niezależna zarówno od
serwera jak też od aplikacji klienckiej, a która odpowiadałaby za przetwarzanie funkcjonalne
samej informacji. W ten sposób aplikacja kliencka nie komunikuje się bezpośrednio z bazą
danych, a nawet nie musi wiedzieć o jej istnieniu, a komunikuje się jedynie z pewnym
komputerem, na którym zainstalowany jest tzw. serwer aplikacji. Wykonuje on procedury na
żądanie aplikacji klienckiej, a one odwołują się do bazy danych. Serwer aplikacji może także
samodzielnie realizować pewne operacje. Może on dokonywać pewnych obliczeń
numerycznych lub inicjować realizowanie pewnych operacji bazodanowych.
Dobrym przykładem architektury trójwarstwowej są przeglądarki WWW, czerpiące
informacje z internetowych serwerów bazodanowych, jednak niełączące się z nimi
bezpośrednio, ale za pomocą tzw. serwerów WWW.
Serwer WWW zachowuje się w tym wypadku jak klient serwera bazy danych. Oba te serwery
mogą choć nie muszą znajdować się na jednej maszynie. Użytkownik komunikuje się z
serwerem WWW poprzez interakcję z przeglądarką w dowolnym obsługiwanym przez niego
języku np.(CGI,PHP,JAVA. itp.). Serwer WWW łączy się z bazą danych i za pomocą SQL-a
lub np. zdalnych wywołań procedur (RPC) uzyskuje potrzebne dane, które następnie przesyła
do przeglądarki klienta. Takiego rozdziału dokonuje się w sytuacji, gdy możliwe jest
wyodrębnienie fazy obróbki danych wymagającej intensywnej interakcji z bazą danych i
przeniesienia reszty tej obróbki poza serwer bazy. Podejście to znacznie ogranicza ilość
danych przesyłanych siecią, ma istotny wpływ na bezpieczeństwo danych ze względu na
zgromadzenie w jednym miejscu procedur pracujących na danych oraz daje łatwiejszą
obsługę interface’u użytkownika. Prezentowane tu rozwiązania ewoluują w kierunku
wspomnianej wcześniej architektury monitorującej przetwarzanie transakcji, w której monitor
TP (Transaction Proccessing) pośredniczy pomiędzy klientem a bazą danych. Wspomniane
już wcześniej partycjonowanie aplikacji jest więc procesem polegającym na podziale aplikacji
na serwery i moduły działające na różnych klientach i serwerach.
10
Serwer aplikacji łączy w sobie różne technologie, aby ułatwić rozwijanie, wdrażanie i
zarządzanie wielowarstowowymi, rozproszonymi aplikacjami. Obecnie na rynku znajduje się
całe mnóstwo technologii "serwerów aplikacji". Technologie te można podzielić na dwie
podstawowe kategorie:
 Serwery aplikacji Webowych
 Firmowe (ang.legacy) serwery aplikacji
Serwer aplikacji Wekowych
Serwer aplikacji Webowych zapewnia środowisko do rozwijania aplikacji opartych na
HTML. Umożliwia pisanie aplikacji klient/serwer. W architekturze tej serwer aplikacji
Webowych znajduje się na serwerze Weba i obsługuje napływające żądania klientów.
Połączenia z bazami danych są realizowane przy pomocy ODBC i JDBC.
Ten
typ serwera aplikacji jest łatwy w eksploatacji i zorientowany na Javę ze wsparciem dla
technologii Enterprise JavaBeans do tworzenia komponentów do pracy po stronie serwera.
Jednak rozwiązania te nie spełniają wymogów aplikacji korporacyjnych o krytycznym
znaczeniu - nie zapewniają obsługi transakcji, zapewniają bezpieczeństwo jedynie na
podstawowym poziomie, nie mają dostępu do systemów firmowych i zazwyczaj
charakteryzują się wydajnością podoptymalną.
Zalety
Wady
Stworzone z myślą o aplikacjach dla Internetu Brak obsługi transakcji
Zintegrowane z serwerem Weba
Niska wydajność
Łatwość rozwijania oprogramowania
Brak zarządzania systemami
Równoważenie obciążenia dla zapewnienia
Małe wsparcie dla istniejących systemów
skalowalności
Przykładami serwerów aplikacji Webowych są rozwiązania dostarczane przez Netscape,
NetDynamics i WebLogic.
Firmowe serwery aplikacji
11
Firmowe serwery aplikacji zapewniają infrastrukturę dla aplikacji o krytycznym
znaczeniu dla biznesu z obsługą transakcji, bezpieczeństwem, wychodzeniem z awarii,
równoważeniem obciążenia służącym do integracji danych w istniejących, firmowych
systemach, takich monitory transakcji. Jednak wiele z tych rozwiązań zamyka rozproszone
obiekty w ramach architektury klient/serwer i przez to utrudnia wsparcie dla działań opartych
na Webie.
Zalety
Wady
Solidna reputacja w korporacyjnych
Niestworzone z myślą o rozproszonych,
aplikacjach o krytycznym znaczeniu
Webowych środowiskach
Obsługa transakcji w aplikacjach
Niska wydajność w transakcjach
intranetowych
Internetowych
Bezpieczeństwo w korporacyjnych
Złożone środowisko programistyczne
aplikacjach intranetowych
Brak integracji z serwerem Weba
Ograniczone wsparcie językowe
Przykładami firmowych serwerów aplikacji mogą być rozwiązania BEA M3 i IBM
Component Broker.
Rozproszona obiektowa architektura wielowarstwowa ( na przykładzie arch.
CORBA)
Wraz ze wzrostem popularności technologii OO, zaczęto zajmować się problemem
rozpraszania obiektów. Skoro partycjonowaniu można poddać aplikacje i rozmieścić jej
fragmenty na różnych serwerach to dlaczego tego samego nie zrobić z systemami
obiektowymi. Wraz z utworzeniem grupy OMG(Object Management Group) , która
nakreśliła referencyjny model obiektowy i szereg modeli standardowych dla architektury
CORBA(Common Object Request Broker Architecture) nadeszło rozwiązanie powyższego
problemu. Ze standardem CORBA rywalizuje dziś opracowana przez Microsoft architektura
DCOM(Distributed Common Object Model) jak również inne narzędzią bazodanowe:
RDO(Remote Data Objects), DAO(Data Access Objects), OLE DB(Object Linking and
12
Abbanding DataBase, ADO(Active Data Objects) oraz ODB-ActivX. Większość
wymienionych tu technologii to dzieło Microsoft’u.
Niezależnie od swoich wad i zalet technologie, wszystkie te modele pozwalają ukryć
procedury dostępu do danych w obiektach i umieścić te obiekty na serwerach zamiast w
aplikacji klienta. Klient otrzymuje dane od obiektów na drodze komunikacji sieciowej.
Rozproszona architektura obiektowa czyni z bazy danych kolejny obiekt, który komunikuje
się z klientami poprzez sieć. Przezroczystość to ma bardzo subtelny wpływ na projektowanie
baz danych. Przeważnie w procesie tym zachodzi zjawisko nadawania pewnych priorytetów
samej bazie lub obsługującej ją aplikacji. W wypadku systemu rozproszonego sytuacja taka
nie występuje. Żaden element systemu nie jest ważniejszy od drugiego. Zamiast stosować
pojedynczy SZBD i obsługiwane przez niego serwery, można łączyć ze sobą różne systemy
zarządzania. Można nawet w obrębie takiego systemu umieścić bazę relacyjną jak i bazę
zorientowaną obiektowo. Zamiast serii modeli danych aplikacji, odwzorowywanych na model
koncepcyjny mamy serię modeli obiektowych odwzorowywanych na szereg modeli
koncepcyjnych. W projektowaniu obiektowym znaczenie zaczyna odgrywać język UML,
który już został uznany za standard i w przyszłości będzie prawdopodobnie szeroko
wykorzystywany.
Nowoczesne metody projektowania nie tylko odzwierciedlają wybraną architekturę
systemową, ale także czerpią z niej swą treść. Podejmowanie decyzji związanej z architekturą
jest tak samo ważne jak projektowanie związków encji, czy pisanie procedur w SQL-u.
Ewolucja architektury systemów bazodanowych nie jest oczywiście jeszcze zakończona choć
ciężko byłoby dziś stwierdzić czym mogłyby być w przyszłości zastąpione obiekty. Na razie
wydaje się, że mają one przed sobą świetlaną przyszłość podejście obiektowe do
projektowania systemów bazodanowych zwłaszcza w skali makro będzie stopniowo wypierać
starsze metody.
W czasach kiedy rozproszone aplikacje obiektowe stają się normą, a biznes oparty na WWW
święci sukcesy, przedsiębiorstwa koncentrują na warstwie pośredniej. Umieszczając logikę
biznesu na serwerach pracujących w warstwie pośredniej, przedsiębiorstwa mogą z łatwością
uaktualniać aplikacje przeznaczone dla tysięcy klientów - bez konieczności każdorazowego
wykonywania instalacji na wszystkich klientach.
Jednakże architektury z warstwą pośrednią są o wiele trudniejsze w programowaniu niż
tradycyjne aplikacje klient/serwer i wiążą się ze sprostaniem wielu unikalnym wyzwaniom
pojawiającym się przy ich wdrażaniu i zarządzaniu. Aby przedsiębiorstwo mogło skorzystać z
zalet wielowarstwowych, rozproszonych architektur, szeregowi programiści muszą być w
stanie rozwijać wyrafinowane, rozproszone aplikacje korzystając z wizualnych środowisk.
Działy IT muszą mieć możliwość łatwego wdrażania tych aplikacji w środowisku testowym i
produkcyjnym, które jest dzielone z administratorami. Administratorzy natomiast potrzebują
możliwości zarządzania tymi zdecentralizowanymi aplikacjami z jednego miejsca
Serwery aplikacji Webowych umożliwiają łatwe rozwijanie aplikacji dla Internetu, natomiast
firmowe serwery aplikacji opierają się na takich istniejących systemach, jak monitory
transakcji (TP Monitors).
Przedsiębiorstwa skłaniają ku rozwiązaniom opartym na serwerach warstwy pośredniej, a
aplikacje rozproszone stają się normą. Rozproszone aplikacje obiektowe oferują
przedsiębiorstwu zwiększoną odporność na awarie i skalowalność, krótszy czas do wejścia na
rynek dzięki wielokrotnemu wykorzystaniu komponentów i możliwości powiązania razem
rozdzielnych, heterogenicznych środowisk dzięki sile www.
13
Dzięki podzieleniu aplikacji na komponenty i przeniesieniu logiki biznesu na serwery
warstwy pośredniej, departamenty IT mogą w bardzo dużym stopniu zmniejszyć czas
rozwijania nowych aplikacji poprzez ponowne wykorzystywanie logiki znajdującej się w
obiektach serwerów warstwy pośredniej. Inną kluczową zaletą architektur z warstwą
pośrednią jest możliwość umieszczenia logiki biznesu na serwerze, a nie na kliencie. Oznacza
to, że w razie konieczności zmiany kodu, zmiana odbywa się w jednym miejscu, a nie na
każdej z 10.000 aplikacji klienckich.
Rozproszone wielowarstwowe architektury obiektowe oferują również istotne zalety
przedsiębiorstwom, które szukają sposobów zintegrowania nowego biznesu opartego na www
z systemami istniejącymi. Biznesowe aplikacje Webowe wymagają architektur z cienkimi
klientami, aby móc stosować klientów opartych na przeglądarkach. Klienci ci wymagają
możliwości interakcji z zasobami intranetowymi, ale często charakteryzują się ograniczonymi
zasobami systemowymi, co utrudnia ściąganie apletów.
Stosując rozwiązania serwerowe, koncentrujące się na warstwie pośredniej, działy IT mogą
ulżyć klientom przenosząc zasadniczą część logiki biznesu na serwery warstwy pośredniej zostawiając klientom cienki interfejs do bogatej funkcjonalności, której domagają się
użytkownicy. Takie rozwiązania po stronie serwera mogą także łączyć ze sobą różnorodne
platformy i integrować się z systemami firmowymi, dzięki czemu możliwe jest tworzenie
aplikacji Webowych integrujących istniejące systemy przedsiębiorstwa.
Wyzwania stawiane przez wielowarstwowe rozproszone aplikacje
Pomimo, że wielowarstwowe rozproszone architektury oferują przedsiębiorstwom szereg
korzyści, jednak przejście na te nowe rozwiązania wiąże się z nowymi, swoimi własnymi
problemami:
 Rozwijanie wielowarstwowych, rozproszonych aplikacji jest złożone
 Wdrożenie setek komponentów, z których się składa rozproszona aplikacja to duże
wyzwanie
 Zarządzanie tysiącami rozproszonych komponentów jest mozolne.

Rozwijanie wielowarstwowych, rozproszonych aplikacji jest złożone
14
Wysoce wykwalifikowani, zaawansowani programiści już od pewnego czasu rozwijali
wielowarstwowe, rozproszone aplikacje. Jednak owi programiści posiedli głęboką wiedzę o
różnorodnych złożonościach na poziomie systemu, takich jak współbieżność, blokowanie,
zarządzanie transakcjami, bezpieczeństwo i skalowalność. Rozumieją również w jaki sposób
należy zarządzać dostępem do takich zasobów systemowych, jak wątki, pamięć, połączenia z
bazami danych i połączenia sieciowe.
Jednak złożoność tych zagadnień ograniczała rozprzestrzenianie się programowania
wielowarstwowego, ponieważ przeciętni programiści zazwyczaj mają więcej doświadczenia z
rozwijaniem logiki biznesu niż programowaniem systemowym.
Wdrożenie setek komponentów, z których się składa rozproszona aplikacja, to duże
wyzwanie
Większość rozproszonych aplikacji składa się z setek komponentów. Każdy komponent ma
właściwości, które muszą być odpowiednio skonfigurowane, aby określić w jaki sposób
komponent jest uruchamiany, czy zapisuje informacje na dysk itp. W wielu wypadkach
sposób ustawiania tych właściwości zależy od platformy, na której rezyduje komponent. Co
więcej środowiska testowe i produkcyjne rozproszonych aplikacji są zazwyczaj rozdzielone,
co uniemożliwia programistom wprowadzanie do aplikacji inteligentnych modyfikacji w celu
poprawienia wydajności i skalowalności w rzeczywistym środowisku wdrożeniowym. Po
zainstalowaniu aplikacji, śledzenie aktywności tysięcy zdecentralizowanych obiektów samo w
sobie stanowi duże wyzwanie.
Zarządzanie tysiącami rozproszonych komponentów jest mozolne
Po wdrożeniu rozproszonej aplikacji administratorzy potrzebują sposobów upewniania
się, że aplikacja nadal działa. Komponenty aplikacji rozproszonej mogą się znajdować w
dowolnym miejscu przedsiębiorstwa i doświadczają wszystkich możliwych awarii, takich jak
zawieszenie systemu, przerwania w ruchu sieciowym lub błędy aplikacji.
Administratorzy muszą szybko otrzymywać informacje, że komponent nie pracuje i móc
podjąć natychmiastowe kroki, aby ponownie go uruchomić, albo uruchomić replikę
komponentu i przekierować ruch kliencki.
Jednak zarządzanie sieciami i systemami odbywa się zawsze z poziomu hosta. Hosty
wykonują określone funkcje, wykonuje się na nich oprogramowanie. Rozproszona aplikacja
nie wykonuje się na hoście - wykonuje się na połączonej sieci hostów. Patrząc się na jeden
host nie można stwierdzić czy aplikacja działa, czy nie.
Administrowanie rozproszoną aplikacją oznacza administrowanie całą siecią - może to być
szalenie mozolnym zadaniem jeżeli się nie posiada odpowiednich narzędzi.
Wymagania wobec wielowarstwowych, rozproszonych aplikacji
Aby wielowarstwowe, rozproszone architektury odgrywały poważną rolę w
przedsiębiorstwie, spełnione muszą być następujące warunki:
 Łatwość programowania przez szeregowych programistów. Wielowarstwowe,
rozproszone architektury wymagały zbyt dużo wiedzy systemowej dotyczącej
rozmaitych technologii (takich jak bazy danych, monitory transakcji, bezpieczeństwo i
CORBA), aby zwykły programista chciał się nimi zajmować. Aby takie architektury
mogły być dla przedsiębiorstw praktyczne, zwykli programiści muszą być w stanie
szybko i łatwo budować wyrafinowane, wielowarstwowe rozwiązania bez
konieczności rozumienia leżących w głębi złożoności systemowych. Muszą móc
rozwijać aplikacje - obsługujące transakcje i bezpieczeństwo - korzystając ze
Zintegrowanego Środowiska Programistycznego (IDE). Zapewniona powinna być
15






również obsługa technologii Enterprise JavaBeans (EJB) dla łatwego rozwijania
komponentów Javy do pracy po stronie serwera.
Uproszczone wdrażanie aplikacji w zintegrowanych środowiskach testowych i
produkcyjnych. Działy IT muszą mieć możliwość łatwego testowania rozproszonych
rozwiązań, wprowadzania modyfikacji poprawiających wydajność, a następnie
współpracowania z administratorami w tym samym produkcyjnym środowisku. Dla
uproszczenia wdrażania aplikacji, IT potrzebuje rozwiązania udostępniającego
zcentralizowane spojrzenie na wszystkie komponenty znajdujące się na hostach w
sieci i łatwego sposobu ustawiania właściwości komponentów rozproszonej aplikacji.
Zcentralizowane zarządzanie. IT musi mieć możliwość łatwego zarządzania setkami
rozproszonych aplikacji, których wiele może posiadać tysiące komponentów
rozproszonych po całym przedsiębiorstwie.
Sprawne ramy do tworzenia krytycznych, korporacyjnych aplikacji. Aby
wielowarstwowe, rozproszone aplikacje były dla przedsiębiorstwa użyteczne, muszą
się opierać na ramach zapewniających obsługę transakcji, bezpieczeństwo,
wychodzenie z awarii, równoważenie obciążenia, skalowalność i wysoką wydajność.
Otwartość i oparcie na standardach. Przedsiębiorstwa potrzebują rozwiązań, które są
otwarte i opierają się na standardach, aby możliwa była współpraca z innym
oprogramowaniem zbudowanym w oparciu o standardy. Na przykład, rozproszone
aplikacje muszą się móc integrować z takimi systemami aplikacyjnymi jak SAP.
Integracja z bazami danych i systemami firmowymi. Rozproszone aplikacje muszą
mieć dostęp do korporacyjnych danych znajdujących się w popularnych bazach
danych (takich jak Oracle i Sybase), albo udostępnianych poprzez monitory transakcji,
takie jak CICS i Tuxedo).
Wsparcie różnorodnych środowisk. Przedsiębiorstwa posiadają różnorodne
środowiska, które muszą być obsługiwane, aby możliwe było stosowanie
wielowarstwowych, rozproszonych aplikacji. Po stronie serwera komponenty
serwerowe muszą być dostosowane do takich platform jak Windows NT i UNIX.
Dostęp do tych serwerów musi być możliwych z różnorodnych klientów, takich jak
HTML, aplety Javy, aplikacje Javy, dynamiczny HTML i aplikacje C++.
16
LITERATURA
1. Robert J. Muller "Bazy danych - jezyk UML w modelowaniu danych" Mikom
Warszawa 2000
2. C.J. Date "Wprowadzenie do systemow baz danych" WNT Warszawa 2000
3. C.J. Date i Hugh Darwen "SQL -omowienie standardu jezyka"
WNT Warszawa 2000
4. Marek Rzewuski „W poszukiwaniu najlepszej architektury” PC Kurier 9/2001
5. Radosław Roszczyk „Rozproszone warstwy” PC Kurier 13/2000
6. „Zintegrowane rozwiązanie do tworzenia, wdrażania i zarządzania wielowarstwowymi
rozproszonymi aplikacjami I” – Artykuły techniczne firmy Borland Polska –
www.borland.pl
17
Download