serwer aplikacji

Serwer WWW czy serwer aplikacji?

Dziś artykuł z cyklu „dyskusja akademicka na temat nazewnictwa”. Pod lupę bierzemy 2 terminy: serwer WWW (ang. web server) oraz serwer aplikacji (ang. application server), które dzisiaj właściwie przenikają się i w większości zastosowań oznaczają to samo. Kiedyś było inaczej. Kiedyś to były serwery WWW. Kiedy w internecie można się było raczyć niemalże wyłącznie prostym […]

Dziś artykuł z cyklu „dyskusja akademicka na temat nazewnictwa”. Pod lupę bierzemy 2 terminy: serwer WWW (ang. web server) oraz serwer aplikacji (ang. application server), które dzisiaj właściwie przenikają się i w większości zastosowań oznaczają to samo.

Kiedyś było inaczej. Kiedyś to były serwery WWW. Kiedy w internecie można się było raczyć niemalże wyłącznie prostym HTML-em, strony były w większości statyczne. I świat był prosty. I serwery webowe miały prosto. Serwowały statyczną treść, a jak były sprytne, to potrafiły ją sobie nawet scachować.

A jak się wtedy miały serwery aplikacji? Zupełnie dobrze. Aplikacje migrowały z mainframe’ów. Serwery aplikacji brylowały swoimi super zaawansowanymi serwisami, zarządzaniem transakcjami, zarządzaniem instancjami, podstawowym bezpieczeństwem, protokołem do połączeń serwera z klientem – własnym, unikalnym, który zjednywał serwerowi lojalność klientów. Bo jak aplikacja nie potrafi gadać z nikim innym, to nigdzie nie pójdzie.

Tak to było kiedyś w wielkim, przerysowanym uproszeniu ;)

Później nastąpił rok 1996

Potem granica między tymi terminami zaczęła się rozmywać. Niektórzy za punkt graniczny przyjmują rok 1996, gdy do Windows NT 4.0 dodano obsługę ASP – dynamicznego generowania stron internetowych.

Dziś każdy serwer WWW potrafi obsługiwać dynamiczną treść, działać jako proxy. Daje wsparcie dla różnych języków programowania, usługi bezpieczeństwa i inne bajery. Dziś nikt sobie nie wyobraża serwera aplikacji nieobsługującego HTTP, a każdy serwer aplikacji ma wbudowany serwer WWW. Wydaje się, że obecnie główną różnicą jest intencja, to, do czego chcemy używać danego narzędzia i w związku z tym, na jakie funkcjonalności kładziemy nacisk. Gdy chcesz środowisko dla aplikacji webowych, HTTP-centrycznych, to myślisz „serwer WWW”. Gdy na horyzoncie widnieje hasło „serwer aplikacyjny”, to od razu pojawiają się skojarzenia – duże obciążenia, kolejkowanie, transakcje, funkcjonalności klasy Enterprise (enterprise features).

Niektóre produkty poszły o krok dalej. Zauważyły, że są tak genialne, iż nazwa serwer aplikacji nie oddaje ich umiejętności, więc tytułują się platformą aplikacji – np. JBoss® Enterprise Application Platform, czy Euro Application Platform. Czy to coś zmienia? Nie bardzo. Może marketingowo brzmi lepiej. Gdy ktoś pyta: a co to jest EuroAP? To odpowiadam „serwer aplikacji”, żeby rozmówca od razu skojarzył, że nawet dla zaawansowanych aplikacji javaEE będzie jak znalazł.

Resumując, historycznie serwery webowe posługują się protokołem HTTP i serwują statyczną treść. Serwery aplikacji mają za to wbudowaną obsługę różnych protokołów i bajery ułatwiające pracę programistom np. javaEE. Obecnie kategoryczne zakwalifikowanie produktu do jednej bądź drugiej grupy jest niemożliwe, a określenia serwer WWW czy serwer aplikacji używamy po to, by podkreślić nasze zamiary i nadzieje w stosunku do danego produktu.

Jeżeli mamy tu purystów, którzy zgromią mnie za takie postawienie sprawy, to zapraszam do komentowania ;)

Autorzy

Artykuły na blogu są pisane przez osoby z zespołu EuroLinux. 80% treści zawdzięczamy naszym developerom, pozostałą część przygotowuje dział sprzedaży lub marketingu. Dokładamy starań, żeby treści były jak najlepsze merytorycznie i językowo, ale nie jesteśmy nieomylni. Jeśli zauważysz coś wartego poprawienia lub wyjaśnienia, będziemy wdzięczni za wiadomość.