Wzrost złożoności programów i udostępnianie danych przez Internet wymuszają tworzenie aplikacji wielowarstwowych. Nie zawsze jest to niezbędne, aby poprawić ich wydajność i niezawodność.

Wcześniej sprawa była prosta. Komputery były urządzeniami samowystarczalnymi, a programy miały dostęp do wszystkich ich zasobów. Sieci skomplikowały sytuację, gdyż trzeba tworzyć programy, których działanie zależy od innych programów na komputerach zdalnych. Tak powstało przetwarzanie rozproszone.

Co to jest warstwa?

Aplikacja rozproszona składa się z programów, działających na wielu komputerach-gospodarzach (host). Natomiast architektura aplikacji rozproszonej to struktura pokazująca, na których komputerach działają te programy, jakie są ich zadania i zakres przetwarzania oraz protokoły, określające sposoby komunikowania się różnych części aplikacji.

Koncepcja warstwy aplikacji (tier) pozwala zgrupować różne rozwiązania architektoniczne. W zasadzie, jeśli aplikacja działa na jednym komputerze, ma architekturę jednowarstwową. Jeżeli działa na dwóch komputerach, np. przy korzystaniu z przeglądarki Web współpracującej z serwerem Web, ma architekturę dwuwarstwową, złożoną z wielu programów klienckich i jednego programu serwerowego. Serwer odpowiada na żądania wielu klientów.

Trzecia warstwa aplikacji to zwykle system zarządzania bazami danych, służący do zapamiętywania danych. Aplikacja trójwarstwowa stanowi ulepszenie systemu dwuwarstwowego. Obieg informacji jest w zasadzie liniowy: klient żąda informacji, serwer (warstwa pośrednia) przekazuje przetworzone żądanie do bazy danych, a wynik zapytania wędruje w przeciwnym kierunku tą samą drogą.

Architektura wielowarstwowa pozwala na współpracę nieograniczonej liczby programów, komunikujących się między sobą za pomocą różnych protokołów, przesyłając informacje, dane, komunikaty, żądania itp. Pozwala to na tworzenie aplikacji znacznie potężniejszych, zapewniając różne rodzaje usług wielorakim klientom.

Niestety, architektura wielowarstwowa to jednocześnie puszka Pandory z wieloma problemami przy projektowaniu, realizowaniu i uzyskiwaniu odpowiedniej wydajności aplikacji. Przemysł informatyczny stworzył wiele technologii, mających ułatwiać rozwiązywanie problemów złożoności takich aplikacji: CORBA, DCOM, EJB i RMI oraz wiele produktów na nich opartych. Przejście na wyższy stopień złożoności aplikacji (więcej warstw) zawsze powoduje problemy, niezależnie od opinii ich zwolenników, podkreślających zalety, a pomijających wady.

Architektury jednowarstwowe

Aplikacja jednowarstwowa to program, który nie potrzebuje dostępu do sieci. Wiele programów na biurko (edytory tekstowe, kompilatory) należy do tej kategorii.

Sieć Web komplikuje sytuację. Rozważmy przykład apletu Java, ładowanego z serwera, działającego na przeglądarce. Jeżeli podczas działania nie korzysta on z sieci (np. wykonując złożony algorytm obliczeniowy), to można uznać go za program jednowarstwowy, gdyż pracuje w całości na jednym komputerze. Podobnie można zakwalifikować samodzielny program w VBScript lub JavaScript, zawarty w stronicy HTML.

Prostota to ogromna zaleta architektury jednowarstwowej. Kod jest prosty, bo nie ma potrzeby obsługiwania protokołów sieciowych. Nie ma również potrzeby synchronizacji z danymi na komputerach zdalnych ani obsługi sytuacji wyjątkowych: awarii sieci, niewłaściwej wersji programów zdalnych lub protokołów. Aplikacje takie są również bardzo wydajne, gdyż żądania użytkownika nie muszą wędrować w sieci, korzystać z usług serwera i wracać z wynikami.

Architektury dwuwarstwowe

Architektura dwuwarstwowa składa się zwykle z trzech części: serwerowej, klienckiej i protokółu. Ten ostatni łączy serwer z licznymi klientami. Architektura dwuwarstwowa to rozwiązanie bardzo skuteczne dla programów sieciowych i graficznych, w których można oddzielić warstwę prezentacji od warstwy logiki działania. Pozwala na szybkie dokonywanie pewnych operacji na stacji klienta (np. sprawdzanie poprawności wprowadzanych danych) oraz wykonywanie operacji biznesowych na serwerze w sposób ujednolicony dla wszystkich klientów (jedna kopia tej części programu).

Typowa aplikacja dwuwarstwowa składa się z części klienckiej napisanej w C++, Visual Basicu lub Javie oraz części serwerowej, napisanej często w innym języku. Część kliencka nie zajmuje się problemami zapamiętywania danych ani problemami obsługi wielu żądań klientów; część serwerowa nie zajmuje się interfejsem użytkowym ani obsługą klawiatury.

Znowu sytuację komplikuje pojawienie się WWW. Często bowiem ze strony HTML są wywoływane funkcje wykonywane w całości na serwerze. Czy jest to architektura dwuwarstwowa? Trochę naciągana, ponieważ programista musi tylko napisać kod funkcji wykonywanej przez serwer. Stronę HTML też ktoś musiał przygotować, zapewne więc jest to jednak architektura dwuwarstwowa.

W architekturze dwuwarstwowej nie zawsze trzeba opracować kompleksową część serwerową aplikacji. Jeżeli korzystamy wyłącznie z funkcji serwera Web, wystarczy użyć produktu komercyjnego, posługującego się gotowym protokołem HTTP. Istnieją również inne specjalizowane serwery, posługujące się protokołami standardowymi. Zaletą takiego rozwiązania jest szybkość tworzenia aplikacji, wadą zaś - korzystanie z uniwersalnych protokołów komunikacyjnych, dostosowanych do każdej możliwej sytuacji, a więc niezbyt szybkich, ale niezawodnych.

Jeżeli zależy nam na wydajności aplikacji dwuwarstwowej, może się okazać korzystne opracowanie własnego serwera aplikacji i użycie niskopoziomowych metod komunikacji np. gniazdek (sockets), zapewniających znacznie lepszą szybkość.

Architektury trójwarstwowe

Aplikacja zwykle przechowuje dane. Dane można zapisać w plikach, ale jeśli potrzebny jest jednoczesny dostęp wielu klientów, lepszym rozwiązaniem jest użycie serwera bazy danych w trzeciej warstwie aplikacji.

Ogólny sposób użycia baz relacyjnych do przechowywania danych polega na określeniu schematu bazy, opisującego dane, i opracowaniu zapytań, umożliwiających zapisywanie i odczytywanie danych. Wymaga to jednak nauczenia się SQL - języka programowania baz danych.

Jeżeli piszemy programy w formie obiektowej, wiele wysiłku trzeba poświęcić na odwzorowanie obiektów programu na struktury relacyjnej bazy danych, co może przedłużyć czas tworzenia projektu. W niektórych przypadkach podwaja go!

Ponadto użycie relacyjnej bazy jest na ogół związane z koniecznością zatrudnienia administratora bazy. Może więc być uzasadnione jedynie koniecznością bezpiecznego przechowywania dużych ilości danych, do których jednoczesny dostęp ma wielu użytkowników. Ogólna reguła jest taka: jeśli mamy mało danych - warto rozważyć prosty plikowy system zapamiętywania; jeśli jednak musimy dane przeszukiwać - baza danych jest bezkonkurencyjna.

Serwery baz danych zwykle pozwalają na tworzenie procedur składowanych do wstępnej obróbki danych przez serwer oraz trygerów do wykonywania zadanych operacji w razie powstania wstępnie zdefiniowanych warunków. Mają jednak poważne wady: nie są przenośne między różnymi serwerami, niekoniecznie są wydajniejsze niż dobrze opracowane procedury przetwarzania w warstwie logiki aplikacji oraz łamią - korzystny pojęciowo i implementacyjnie - rozdział architektury aplikacji na trzy części.

Architektury wielowarstwowe

Zwolennicy standardów CORBA, EJB i DCOM twierdzą, że każda nowa aplikacja powinna być pisana zgodnie z ich ulubionym standardem (oraz każda dawna aplikacja przepisana w tymże standardzie), iż dla programistów nie ma nic lepszego niż wielowarstwowe aplikacje. W tym wyimaginowanym świecie rozproszonych obiektów tworzenie nowej aplikacji polega na składaniu obiektów, które same zajmą się wzajemną komunikacją, a protokoły standardu obiektowego obsłużą tak niewdzięczne zadania, jak dopasowanie formatu parametrów, komunikacja w sieci, znajdowanie zdalnych obiektów, zarządzanie transakcjami, bezpieczeństwo itd.

Gdzie tkwi problem? Po pierwsze, opanowanie setek lub tysięcy nowych wywołań funkcji API wszystkich współdziałających usług systemowych zajmie wiele czasu. Po drugie, nigdy nie jest tak, aby wszystko działało zgodnie z założeniami - trzeba włożyć sporo pracy, aby poznać zalety i wady poszczególnych rozwiązań. Po trzecie, aplikacje wielowarstwowe wymagają stosowania w każdej warstwie serwera aplikacyjnego. To kosztuje - i to sporo, na ogół dziesiątki tysięcy dolarów.

Oprócz tych czysto materialnych trosk, istnieją problemy techniczne. Opracowanie komponentów, które można użyć powtórnie w przyszłych projektach, to na ogół mrzonka. Albo wymaga zbyt dużo wysiłku, na który nie ma czasu, albo następny projekt będzie tak różny od obecnego, że i tak komponenty nie będą przydatne.

Aplikacje wielowarstwowe wymagają również znacznie bardziej skomplikowanych, a więc znacznie droższych, systemów ochrony danych i składowania, przyznawania praw dostępu, zarządzania aplikacją i danymi, logowania itp.

Kolejny problem to wydajność. Wszystkie protokoły komunikacji rozproszonych obiektów muszą być na tyle uniwersalne, aby sprostać każdej sytuacji. Są więc niezawodne i bezpieczne, ale powolne. W efekcie również aplikacja wielowarstwowa musi być mniej wydajna niż równoważna jej aplikacja dwu-, a nawet trójwarstwowa. Zdiagnozowanie problemu wydajności złożonej aplikacji przekroczy możliwości najlepszych narzędzi i sprawi, że administrator sieci poświęci na to sporo czasu.

W przypadku skomplikowanych aplikacji, w których współdziałają z sobą setki lub tysiące obiektów i komponentów, nie ma jednak lepszych rozwiązań niż wielowarstwowa architektura oparta na standardach przemysłowych (CORBA, EJB, DCOM).