3. Dwa plus jeden

Uważne przyjrzenie się barierom rozwoju systemów klient/serwer architektura każdego dużego i rozwijającego się systemu rozproszonego (wielu użytkowników, dużo transakcji i różnych aplikacji) nieuchronnie zmierza do podziału wielowarstwowego. Najprostszy wariant to architektura trójwarstwowa, złożona z warstwy prezentacji (front-end), warstwy serwerów aplikacji, nazywanej czasem warstwą strategii (co jednak, jak zobaczymy, zawęża jej potencjalne funkcje) oraz warstwy serwerów danych. Rola pierwszej i ostatniej z nich jest intuicyjnie oczywista i dobrze znana. Warstwa prezentacji odpowiada za komunikację z użytkownikiem. Warstwa serwerów danych ma za zadanie zapewnienie dostępu do danych przechowywanych w (być może rozproszonych) bazach danych, zagwarantowanie ich spójności i bezpieczeństwa. Jej funkcje realizowane są przez obsługę transakcji i zapytań. Pozostaje sprecyzować, jakie są zadania środkowej warstwy i wyjaśnić podaną wyżej jej nazwę.

4. Rola środkowej warstwy

Pierwsze zadanie warstwy serwerów aplikacji już znamy. Właśnie tam mogą być umieszczone reguły biznesowe, opisujące strategię działania organizacji. Warstwa ta odpowiada za implementację logiki zarządzania i podejmowania decyzji. Potencjalne korzyści, wynikające z tej modyfikacji, wydają się oczywiste. Po pierwsze - aplikacje klienckie (moduły front-end) mogą być dzięki temu mniejsze, prostsze, bardziej efektywne i bardziej elastyczne. Istnienie wielu aplikacji, dobrze dopasowanych do zróżnicowanych potrzeb wielu grup użytkowników, nie będzie niczym groźnym, jeśli logika przetwarzania i operacji biznesowych znajdzie się w dodatkowej warstwie. Podobnie, zmiany strategii zarządzania nie będą wpływać na serwery baz danych, które będą pracować bardziej niezawodne i efektywne.

Warstwa środkowa może więc służyć wyodrębnieniu serwerów odpowiedzialnych za strategię, ale na tym jej rola się nie kończy. W istocie, możemy w niej umieścić wszystko, co nie należy do zadań obu pozostałych warstw, a musi być wykonywane w systemie. Podstawą do wyodrębnienia serwerów w systemie może być obiektowy projekt aplikacji - obiekt stanowiący agregat danych i usług staje się tu podstawowym środkiem do modelowania funkcjonalności systemu. Z drugiej jednak strony, usługi obiektów współdzielą wiele operacji na danych, zaś te wymagają w systemach transakcyjnych pośrednictwa monitorów transakcyjnych, zapewniających integralność i równomierne obciążanie serwera zapytaniami. Środkowa warstwa traci w ten sposób swoją monolityczną strukturę, stając się swoistą federacją procesów-obiektów, świadczących wzajemnie wszelkie niezbędne usługi.

Taki model systemów rozproszonych - świat rozproszonych, komunikujących się obiektów proponuje dziś Gartner Group w zamian za dotychczasowy - klasyczny model architektury klient/serwer.

Analizując specyfikę usług - ich "apetyt" na moc obliczeniową, konieczność dostępu do źródeł danych, rozmieszczenie atrybutów obiektów w tablicach relacyjnych baz danych czy konieczność wykorzystania specyficznych urządzeń wejścia/wyjścia - możemy stworzyć fizyczną strukturę rozproszenia, niezależną od logicznego podziału na obiekty.

Podział logiczny systemu to jedno, a fizyczna jego realizacja, to drugie. Dlatego istotnym elementem każdego projektu klient/serwer są standardy przypisania logicznych komponentów aplikacji na komponenty fizyczne architektury. Dobrze zaprojektowany podział pozwala na skonstruowanie sensownej liczby serwerów aplikacji, o właściwie dobranych repertuarach usług i strukturze wywołań.

Warto tu zaznaczyć, że to wszystko nie jest dzisiaj jakąś wizją technologii przyszłości czy tylko tematem prac naukowo-badawczych. Wiele organizacji - zwłaszcza na najbardziej dojrzałym rynku amerykańskim - dawno wyszło z aplikacji pilotażowych, "zaliczyło" architekturę dwuwarstwową i stanęło w obliczu opisanych powyżej ograniczeń rozwoju systemów. Tam gdzie trzy lata temu czasopisma, takie jak CW czy Datamation, publikowały liczne artykuły popularyzujące ideę rozproszonych systemów biznesowych, dzisiaj możemy przeczytać materiały opisujące udane projekty wykorzystujące możliwości architektury trójwarstwowej "w przemyśle". Jest to dzisiaj możliwe dzięki coraz większej standaryzacji rozwiązań technicznych (standardy, takie jak CORBA, RPC, DCE, OpenDoc) oraz dostępności coraz dojrzalszych narzędzi konstrukcyjnych (Entera firmy OEC, pakiet ORBIX firmy Sun, RPC Painter czy EncinaBuilder dla PowerBuildera itp).