Serwery aplikacyjne są siłą napędową Internetu. Mają wiele do zaoferowania zarówno powstającym firmom korzystającym z najnowszych technologii, jak i przedsiębiorstwom, które muszą integrować stare i nowe aplikacje.

Do niedawna prawie wszystkie aplikacje budowano pod kątem konkretnego systemu operacyjnego, działającego na określonym sprzęcie. Dla przedsiębiorstwa tworzącego lub kupującego pierwszy system informatyczny wybór aplikacji oznaczał związanie się na dobre i na złe z jednym systemem operacyjnym, czasem również z jednym rodzajem sprzętu. Sytuacja zmienia się dzięki serwerom aplikacyjnym - jednym z najważniejszych elementów infrastruktury Internetu. Programiści mogą tworzyć jedną wersję aplikacji dla jednego serwera aplikacyjnego, działającego na wielu platformach. Serwer zapewnia większość usług, dawniej realizowanych przez system operacyjny. Wystarczy więc raz nauczyć się korzystania z nich, nie trzeba ich zmieniać wraz z wymianą systemu.

Co to jest serwer?

Termin "serwer aplikacyjny" żyje własnym życiem. Każdy producent pod tą nazwą ukrywa co innego, zwłaszcza że zależy mu, aby jego wersja serwera aplikacyjnego dobrze pasowała do specyfiki innych oferowanych produktów.

Według popularnej definicji, serwer aplikacyjny to zintegrowane środowisko do opracowania i osadzania aplikacji, umożliwiające integrację w sieci takich zasobów, jak serwery Web, bazy danych i aplikacje. Inna definicja określa serwer aplikacyjny jako część pośredniej warstwy oprogramowania (middleware) w architekturze trójwarstwowej. W tej warstwie działają również serwery komunikacji asynchronicznej, serwery WWW i ich rozszerzenia (skrypty CGI, ASP). Serwery aplikacyjne mają jednak przewagę nad innymi produktami tej warstwy: komunikują się bezpośrednio z bazami danych zaplecza.

Serwer aplikacyjny służy do osadzania logiki aplikacji, zapewniając zbiór odpowiednich narzędzi i usług oraz integrację aplikacji z komponentów CORBA, EJB lub COM. Pozwala to na pominięcie wielu etapów pracy programistycznej, tworzenia na nowo tego, co inni już wcześniej zrobili, i zajęcie się ważniejszymi sprawami - wydajnością, skalowalnością i bezpieczeństwem.

Modele komponentowe

Wszystkie serwery aplikacyjne zapewniają wsparcie komponentowego modelu tworzenia logiki aplikacji. Największą popularnością cieszy się model Enterprise Java Beans, ponieważ wspierają go prawie wszystkie serwery aplikacyjne. Niektóre wspierają jednocześnie model COM+. Jedynie serwer aplikacyjny wbudowany w system operacyjny Windows 2000 zapewnia wsparcie wyłącznie dla modelu COM+.

Opracowana przez Sun specyfikacja Java 2 Enterprise Edition (J2EE) zawiera liczne usługi, pozwalające na tworzenie jednolitych, skalowalnych i dość łatwo przenośnych aplikacji Java. Rosnąca popularność tej specyfikacji spowodowała, że wielu producentów już wbudowało lub zamierza wbudować wsparcie dla J2EE w swoje serwery.

Niektóre serwery aplikacyjne mają wbudowane wsparcie dla technologii komunikacji rozproszonej CORBA za pomocą protokołu IIOP, pozwalającej na łączenie aplikacji komponentowych Java/COM+ z istniejącymi aplikacjami. Nie istnieje natomiast ostateczna specyfikacja modelu komponentowego CORBA i prawdopodobnie nigdy się nie pojawi, gdyż jej twórcy, skupieni w organizacji OMG, skłaniają się ku modelowi opartemu na EJB. Nie ma więc serwerów aplikacyjnych CORBA. Doskonałą współpracę z aplikacjami zgodnymi ze specyfikacją CORBA zapewniają serwery oparte na brokerach obiektowych ORB, gdyż powalają m.in. na korzystanie z komercyjnych implementacji usług CORBA, takich jak obsługa bezpieczeństwa czy usługi transakcyjne.

Co robi serwer?

Wszystkie serwery aplikacyjne mają zestaw podstawowych cech. Zapewniają: obsługę bezpieczeństwa, tworzenie i obsługę puli połączeń z klientami, zarządzanie stanem sesji połączeniowej, obsługę logiki aplikacji i dostęp do bazy danych.

Obsługa bezpieczeństwa. Aby uzyskać informacje z bazy danych, klient musi potwierdzić swoją tożsamość za pośrednictwem serwera aplikacyjnego. Niektóre z serwerów mają wbudowane usługi bezpieczeństwa, większość jednak korzysta z dostępnych usług systemu operacyjnego, bazy danych lub serwera logowania. Bardziej zaawansowaną obsługę bezpieczeństwa zapewnia stosowanie certyfikatów cyfrowych (np. X.509) i komercyjnych systemów szyfrowania danych.

Zarządzanie stanem sesji połączeniowej. Serwer musi zapewniać informacje o stanie połączenia z klientem przez cały czas trwania sesji. W prostych aplikacjach Web, korzystających ze skryptów CGI, utrzymywanie stanu polega na używaniu specjalnych plików (cookies) lub zmiennych ukrytych w adresie URL. Te sposoby nie nadają się jednak do aplikacji biznesowych - co będzie, gdy nieświadomy klient odmówi przyjęcia pliku cookie?

Serwery aplikacyjne utrzymują informacje o stanie połączenia za pomocą obiektów sesyjnych działających w serwerze. Obiekty stanowe (np. stanowe beany sesji w modelu EJB) działają na rzecz jednego klienta, cały czas utrzymują otwartą sesję i pozwalają na przesyłanie informacji od klienta i z powrotem. Ich wadą jest mała skalowalność. Zużywając dużo zasobów serwera, limitują liczbę obsługiwanych klientów. Programiści wolą więc posługiwać się bezstanowymi obiektami sesji (np. bezstanowe beany sesji w modelu EJB). Po uzyskaniu połączenia z klientem, pobraniu i sprawdzeniu informacji, rozłączają się i mogą być użyte na rzecz innego klienta. Informacje o stanie sesji klienta przechowuje się w bazie danych.

Równoważenie i przejmowanie obciążenia. W razie awarii wszystkie serwery aplikacyjne zapewniają pewną formę równoważenia obciążenia i mechanizmy przejmowania zadań przez działający serwer.

Równoważenie obciążenia oznacza, że grupa serwerów aplikacyjnych działa na klastrze lub w tzw. farmie komputerów. Żądania przychodzące od klientów są kierowane przez sprzętowy lub programowy przełącznik do serwera najmniej obciążonego. Równoważenie obciążenia zapewnia skalowalność aplikacji. W miarę wzrostu obciążenia do farmy można dodać większą liczbę serwerów.

Przejmowanie obciążenia przez działający serwer zapewnia odporność na błędy. Jeżeli jedna maszyna w klastrze ulegnie awarii, żądania klientów są kierowane do innych serwerów. Proste przejmowanie obciążenia nie rozwiązuje wszystkich problemów. Jeżeli użytkownik kolejno wysyła pięć formatek ekranowych i awaria nastąpi podczas przesyłania trzeciej formatki, skierowanie jej do innego serwera nie zapewni odtworzenia stanu sesji i przesłanych danych. Z tego powodu niektóre serwery realizują automatyczne powielanie stanu sesji lub przesyłanie jej do serwera lustrzanego, zapewniając precyzyjne przejmowanie obciążenia na poziomie sesji.

Kontener logiki aplikacji. Większość logiki współczesnych aplikacji (kody dostępu do danych, operacje na danych, sprawdzanie poprawności i przetwarzanie) ma postać komponentów, osadzanych w kontenerze tworzonym w serwerze aplikacyjnym.

Kontener jest zestawem usług świadczonych przez serwer aplikacyjny na rzecz konkretnej aplikacji. Osadzanie komponentów wymaga określenia zasad bezpieczeństwa ich używania, udziału w transakcjach, trwałości (zapisywania stanu komponentu), wymagań odnośnie do wielowątkowości.

Dostęp klienta do komponentów. Większość serwerów aplikacyjnych ma wbudowany lub korzysta z usług samodzielnego serwera Web do komunikacji z przeglądarką klienta. W przypadku klientów o większej funkcjonalności (np. klient C/C++ lub PowerBuilder) trzeba w serwerze stworzyć oddzielne komponenty do komunikacji. Klienckie aplikacje Java mogą bezpośrednio komunikować się z komponentami EJB działającymi w serwerze.

Dostęp do bazy danych. Większość serwerów aplikacyjnych ma możliwości rodzimego (bez pośrednictwa sterowników) otwierania sesji połączeniowych z bazami danych Oracle i IBM; dostęp do innych baz najczęściej realizuje się za pomocą sterowników JDBC/ODBC. Natomiast każdy serwer realizuje własny sposób dostępu do baz nierelacyjnych lub źródeł innych danych (pliki tekstowe, obiekty multimedialne).

Otwarcie sesji połączeniowej z bazą to kosztowna operacja, zużywająca wiele zasobów komputera. Aby polepszyć skalowalność, serwery utrzymują pulę stale otwartych sesji połączeniowych z bazą, wykorzystywanych przez wszystkie obiekty aplikacji i wszystkich użytkowników.

Obsługa transakcji. Jeszcze do niedawna programista musiał zajmować się obsługą transakcji w bazie. W środowisku serwera aplikacyjnego istnieją różne metody definiowania granic transakcji dokonywanych przez obiekty logiki aplikacji (np. transakcja wymagana, obiekt rozpoczyna nową transakcję), a serwer zajmuje się ich obsługą.

W aplikacjach rozproszonych, współpracujących z wieloma bazami danych, konieczne jest korzystanie z usług transakcyjnych brokera obiektowego lub samodzielnego monitora transakcyjnego. Tylko nieliczne serwery aplikacyjne mają wbudowane usługi monitora transakcyjnego.

Środowisko do tworzenia aplikacji. Niektóre serwery aplikacyjne zawierają własne środowisko do tworzenia i osadzania aplikacji. Wynika to z istnienia specjalizowanych rozszerzeń funkcjonalnych wykraczających poza wspierany model komponentowy. Twórcy narzędzi programistycznych starają się współpracować z głównymi producentami serwerów w celu włączenia ich do narzędzia.

Rynek serwerów aplikacyjnych

Koszt serwera aplikacyjnego waha się od zera (to rzadki przypadek) do ponad 30 tys. USD za jeden procesor. Analitycy rynkowi z firmy Giga Information Group oceniają, że w tym roku rynek serwerów aplikacyjnych osiągnie wartość 1,64 mld USD, a w 2003 r. przekroczy 9 mld USD. W roku 1999 obroty na tym rynku wyniosły 585 mln USD.

Według oceny analityków IDC na rynku przodują BEA Systems z serwerami z rodziny WebLogic (w 1999 r. udział firmy wynosił ok. 32%), IBM z serwerami WebSphere (udział ok. 16%) oraz Sybase z Enterprise Application Server (udział ok. 15%). Prognozy mówią, że pod koniec 2001 r. liderami będą BEA i IBM z udziałem po 24%; na dalszych miejscach znajdą się ATG (10%), iPlanet (9%), SilverStream i Sybase (5-7%).