Opis architektury klient serwer
advertisement
WDRAŻANIE SYSTEMÓW WIELOWARSTWOWYCH 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 4.3 ARCHITEKTURA TRÓJWARSTWOWA…………………………… 9 LITERATURA ............................................................................. 16 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) 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 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 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 . 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 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 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. 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 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 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. 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 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ć 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++. 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
