Współczesne duże aplikacje klient/serwer przypominają aplikacje działające na mainframe'ach.

Początek lat 90. w informatyce to era "downsizingu" i "rightsizingu" - cechująca się przechodzeniem z aplikacjami ma mniejsze komputery i ze środowisk, pracujących w trybie z podziałem czasu (duże komputery typu mainframe i minikomputery), na instalacje klient/serwer.

Próbowano podobnie uczynić z dużymi aplikacjami do obsługi transakcji, typowymi w działalności handlowej, finansowej i ubezpieczeniowej. Jedynie w niewielu przypadkach ten proces powiódł się, a to głównie z powodu trudności w zarządzaniu setkami lub tysiącami niezależnych aplikacji klienckich, działających na komputerach PC, zlokalizowanych w różnych miejscach.

Rozwiązanie klient/serwer dla dużej liczby użytkowników ma tylko wtedy sens, gdy aplikacjami dla klientów i ich komputerami można dobrze i tanio zarządzać z centralnego stanowiska, a także łatwo je dystrybuować i aktualizować.

W potocznym rozumieniu termin "klient/serwer" oznacza, że aplikacja kliencka działa na PC, korzystając przez sieć z baz danych zlokalizowanych na serwerze. Standardowy język SQL dostępu do bazy pozwala na rozdzielenie procesu opracowywania i utrzymywania aplikacji klienckiej od opracowywania i utrzymywania aplikacji dla serwera bazy danych. Na PC działają wydajne narzędzia do opracowania aplikacji i jej graficznego interfejsu użytkowego. To dobre rozwiązanie dla niewielkich zespołów użytkowników, pracujących na ograniczonej przestrzeni. Aplikacje powinny być proste i nie ingerować w swoje działanie.

To samo rozwiązanie architektoniczne ma jednak sporo wad w przypadku dużych aplikacji, krytycznych dla działania przedsiębiorstwa: planowania zaopatrzenia materiałowego (MRP), obsługi dużej liczby klientów w banku czy przetwarzania danych ubezpieczeniowych. Jedynie duży komputer zapewnia sprawne działanie aplikacji przez 24 godziny na dobę, 7 dni w tygodniu. Utrzymywanie aplikacji i danych wymaga pracy zespołu profesjonalnych informatyków, posługujących się sprawdzonymi (i dobrze wspomaganymi) metodami wprowadzania zmian do aplikacji, kontroli wersji kodu źródłowego, bezpieczeństwa, składowania danych.

Serwer bazy danych i serwer aplikacji

Czy duże aplikacje (zwłaszcza transakcyjne) powinny pracować tylko na mainframe? Niekoniecznie, choć mogą. Logicznym rozszerzeniem modelu scentralizowanego zarządzania aplikacjami i danymi jest rozwiązanie z oddzielnym serwerem bazy danych i samodzielnym serwerem aplikacji.

Model ten ogranicza pojęcie klient/serwer w jednej sprawie. Obecnie aplikacja kliencka sprowadza się do interfejsu graficznego, działającego na komputerze lub terminalu użytkownika końcowego. Natomiast właściwa aplikacja biznesowa pracuje na serwerze aplikacji, pobiera i zapisuje dane w bazie (lub bazach) danych i dostarcza je do stacji klienta. Jeden serwer aplikacji może obsługiwać wielu użytkowników, a do utrzymywania aplikacji można zastosować metody wypróbowane przez wiele lat na mainframe'ach.

Podejście to nieco zmienia sens terminu "system otwarty", ale nie wnosi żadnych ograniczeń co do wyboru sprzętu i systemu operacyjnego serwerów, bazy danych i aplikacji. Natomiast wymaga stosowania ustalonego, jednego interfejsu między stacjami klienta a serwerem aplikacji i ustalonego interfejsu do baz danych. Stosując SQL ograniczony do pewnego zakresu, np. poziom podstawowy SQL-92, można dowolnie wymieniać bazę danych, nie zmieniając linii kodu w aplikacji.

Jako stacje klienta można stosować terminale XWindows, posługujące się protokołem komunikacyjnym X11, lub komputery sieciowe NC z wbudowanym protokołem TCP/IP. Pozwala to kupować sprzęt od dowolnego producenta, bez obawy, że wybrany dostawca zniknie z rynku.

Systemy otwarte i Poltax

W Polsce było zbyt mało mainframe'ów i minikomputerów, aby wpłynęły one znacząco na rozwój informatyki. Nie pojawiły się również tendencje przechodzenia z mainframe'a na systemy otwarte. Natomiast idea systemów otwartych i aplikacji klient/serwer wyraźnie uwidoczniła się w nieudanym projekcie Poltaxu. Zapewne niewielu pamięta, że początkowo ścierały się dwie wizje skomputeryzowania polskiego systemu podatkowego. Jedną prezentowali ludzie ówczesnego ośrodka informatyki Ministerstwa Finansów, dobrze wyposażonego w wydajne, duże komputery IBM, którzy uważali, że tylko rozwiązanie oparte na mainframe ma szansę na sukces. Ponadto nadal wierzyli, że "nie można stracić pracy, kupując od IBM-a". W ich przypadku to się nie sprawdziło. Głównymi rzecznikami drugiej wizji - związanej z ideą systemów otwartych, modelem klient/serwer i innymi modnymi sloganami o informatyce opartej na systemach unixowych - byli młodzi ludzie, wykształceni w Stanach Zjednoczonych. Ich pomysł został przyjęty i wszyscy wiemy, jak to się skończyło. Obecnie w Poltaxie podejmowane są próby wprowadzenia modelu wielowarstwowego z serwerami baz danych, serwerem aplikacji i komputerami sieciowymi, działającymi jako stacje klienckie. Miejmy nadzieję, że pomysł ten zostanie zrealizowany i doczekamy się nowoczesnego systemu podatkowego.