
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 ;)