Jaka jest różnica między serwerem aplikacji a serwerem WWW?
Odpowiedzi:
W większości przypadków te terminy Serwer WWW i Serwer aplikacji są używane zamiennie.
Oto niektóre z kluczowych różnic w funkcjach serwera WWW i serwera aplikacji:
Przykładem takiej konfiguracji jest serwer HTTP Apache Tomcat i serwer WebLogic Oracle (wcześniej BEA). Serwer HTTP Apache Tomcat to serwer WWW, a Oracle WebLogic to serwer aplikacji.
W niektórych przypadkach serwery są ściśle zintegrowane, takie jak IIS i .NET Runtime. IIS to serwer WWW. Po wyposażeniu w środowisko uruchomieniowe .NET usługi IIS mogą świadczyć usługi aplikacji.
Jest to szczegółowa odpowiedź z niektórymi scenariuszami, aby jasno zrozumieć różnicę, podobieństwo oraz sposób, w jaki oba mogą działać łącznie
Serwer aplikacji to termin, który czasami miesza się z serwerem WWW . Podczas gdy serwer WWW obsługuje głównie protokoły HTTP , serwer aplikacji obsługuje kilka różnych protokołów, w tym między innymi HTTP .
Głównym zadaniem serwera WWW jest wyświetlanie zawartości witryny, a serwer aplikacji odpowiada za logikę , interakcję między użytkownikiem a wyświetlaną treścią. Serwer aplikacji działa w połączeniu z serwerem WWW, na którym jeden jest wyświetlany, a drugi wchodzi w interakcje.
Informacje przesyłane tam iz powrotem między serwerem a jego klientem nie są ograniczone do prostego znacznika wyświetlania, ale do interakcji między nimi.
W większości przypadków serwer tworzy tę interakcję za pomocą komponentowego interfejsu API , takiego jak J2EE (Java 2 Platform) , EJB (Enterprise JavaBean) i inne modele modeli aplikacji.
Przykład:
Najlepszym sposobem na zrozumienie różnicy między scenariuszami, w których serwer aplikacji współpracuje z serwerem WWW, a scenariuszem, w którym nie ma serwera aplikacji, jest sklep internetowy.
Scenariusz 1: serwer WWW bez serwera aplikacji
masz sklep internetowy z tylko serwerem internetowym i bez serwera aplikacji. Witryna wyświetli ekran, z którego możesz wybrać produkt. Po przesłaniu zapytania witryna przeprowadza wyszukiwanie i zwraca wynik HTML z powrotem do swojego klienta. Serwer WWW wysyła zapytanie bezpośrednio do serwera bazy danych (bądź cierpliwy, wyjaśnię to w naszym następnym modelu użytkowym) i czeka na odpowiedź. Po otrzymaniu serwer WWW formułuje odpowiedź w pliku HTML i wysyła ją do przeglądarki internetowej. Ta komunikacja do przodu i do tyłu między serwerem a serwerem bazy danych zachodzi za każdym razem, gdy uruchamiane jest zapytanie.
Scenariusz 2: Serwer WWW z serwerem aplikacji
jeśli zapytanie, które chcesz uruchomić, zostało już wykonane i od tego czasu żadne dane nie uległy zmianie, serwer wygeneruje wyniki bez konieczności wysyłania żądania do serwera bazy danych. Umożliwia to zapytanie w czasie rzeczywistym, w którym drugi klient może uzyskać dostęp do tych samych informacji i otrzymywać wiarygodne informacje w czasie rzeczywistym bez wysyłania kolejnego duplikatu zapytania do serwera bazy danych. Serwer zasadniczo działa jako pośrednik między serwerem bazy danych a serwerem WWW. Dzięki temu ściągnięte informacje mogą być ponownie użyte w pierwszym scenariuszu, ponieważ informacje te są osadzone na określonej i „dostosowanej” stronie HTML, nie jest to proces wielokrotnego użytku. Drugi klient będzie musiał ponownie zażądać informacji i otrzymać kolejną stronę osadzoną w HTML z żądanymi informacjami - wysoce nieefektywna.
Aby obsługiwać tak różnorodne złożone zadania, serwer musi mieć wbudowaną redundancję, doskonałą moc przetwarzania i dużą ilość pamięci RAM, aby obsłużyć wszystkie dane, które pobiera w czasie rzeczywistym.
Mam nadzieję że to pomoże.
the application server deals with several different protocols, including, but not limited, to HTTP<- to znaczy, że zdecydowanie obsługuje żądania HTTP - to nie jest dokładne.
Oba terminy są bardzo ogólne, jeden zawiera drugi i na odwrót w niektórych przypadkach.
Serwer WWW : udostępnia treści w Internecie za pomocą protokołu HTTP.
Serwer aplikacji : hostuje i udostępnia logikę biznesową i procesy.
Myślę, że główną kwestią jest to, że serwer WWW udostępnia wszystko za pośrednictwem protokołu http, podczas gdy serwer aplikacji nie jest do niego ograniczony.
To powiedziawszy, w wielu scenariuszach okaże się, że serwer WWW jest używany do tworzenia frontonu serwera aplikacji, to znaczy udostępnia zestaw stron internetowych, które pozwalają użytkownikowi na interakcję z regułami biznesowymi znalezionymi w Serwer aplikacji.
serwer internetowy
Uruchom python -m 'SimpleHTTPServer'i przejdź do http: // localhost: 8080 . To, co widzisz, to działający serwer WWW. Serwer po prostu obsługuje pliki przez HTTP przechowywane na twoim komputerze. Kluczową kwestią jest to, że wszystko to odbywa się na szczycie protokołu HTTP. Istnieją również na przykład serwery FTP, które robią dokładnie to samo (serwowanie przechowywanych plików), ale na innym protokole.
Serwer aplikacji
Powiedzmy, że mamy małą aplikację, taką jak poniżej (fragment z Flask ).
@app.route('/')
def homepage():
return '<html>My homepage</html>'
@app.route('/about')
def about():
return '<html>My name is John</html>'
Mały przykładowy program mapuje adres URL /na funkcję homepage()i /aboutna funkcję about().
Aby uruchomić ten kod, potrzebujemy serwera aplikacji (np. Gunicorn) - programu lub modułu, który może nasłuchiwać żądań od klienta i za pomocą naszego kodu zwracać coś dynamicznie. W tym przykładzie po prostu zwracamy bardzo zły kod HTML.
O jakiej logice biznesowej rozmawiają wszyscy inni ludzie? Cóż, skoro adres URL odwzorowuje się gdzieś konkretnie w naszej bazie kodu, hipotetycznie pokazujemy logikę na temat działania naszego programu.
Podsumowanie
serwer WWW - obsługuje pliki gdzieś przechowywane (najczęściej .css, .html, .js). Typowymi serwerami WWW są Apache, Nginx, a nawet SimpleHTTPServer Pythona.
serwer aplikacji - obsługuje pliki generowane w locie. Zasadniczo większość serwerów WWW ma jakieś wtyczki, a nawet posiada wbudowane funkcje, aby to zrobić. Istnieją również ścisłe serwery aplikacji, takie jak Gunicorn (Python), Unicorn (Ruby), uWSGI (Python) itp.
Zauważ, że faktycznie możesz zbudować serwer WWW za pomocą kodu serwera aplikacji. Odbywa się to w niektórych przypadkach podczas programowania, gdy nie chcesz, aby na Twoim komputerze działało mnóstwo różnych serwerów.
Jak zauważyli Rutesh i jmservera, rozróżnienie jest niewyraźne. Historycznie były różne, ale w latach 90. te dwie odrębne kategorie łączyły cechy i skutecznie się łączyły. W tym momencie prawdopodobnie najlepiej jest sobie wyobrazić, że kategoria produktów „App Server” jest ścisłym nadzorem kategorii „serwer WWW”.
Trochę historii. Na początku przeglądarki Mosaic i zawartości hiperłącza rozwinęła się rzecz zwana „serwerem internetowym”, który obsługiwał zawartość strony i obrazy przez HTTP. Większość treści była statyczna, a protokół HTTP 1.0 był tylko sposobem przesyłania plików. Szybko kategoria „serwer WWW” ewoluowała, włączając funkcję CGI - skutecznie uruchamiając proces przy każdym żądaniu sieci w celu wygenerowania dynamicznej zawartości. Dojrzał również HTTP, a produkty stały się bardziej wyrafinowane, z funkcjami buforowania, bezpieczeństwa i zarządzania. W miarę dojrzewania technologii otrzymaliśmy specyficzną dla firmy technologię Java po stronie serwera od Kiva i NetDynamics, które ostatecznie połączyły się w JSP. Microsoft dodał ASP, myślę, że w 1996 roku, do Windows NT 4.0. Statyczny serwer internetowy nauczył się kilku nowych sztuczek, dzięki czemu był skutecznym „
W kategorii równoległej serwer aplikacji ewoluował i istniał przez długi czas. firmy dostarczały produkty dla Uniksa, takie jak Tuxedo, TopEnd, Encina, które filozoficznie wywodzą się ze środowisk zarządzania aplikacjami i monitorowania Mainframe, takich jak IMS i CICS. Ofertą Microsoftu był Microsoft Transaction Server (MTS), który później przekształcił się w COM +. Większość z tych produktów określała „zamknięte” protokoły komunikacyjne specyficzne dla produktu w celu połączenia „grubych” klientów z serwerami. (W przypadku Encina protokołem komunikacyjnym był DCE RPC; w przypadku MTS był to DCOM; itp.) W latach 1995/96 te tradycyjne produkty serwerów aplikacji zaczęły zawierać podstawowe funkcje komunikacji HTTP, początkowo za pośrednictwem bram. I linie zaczęły się zacierać.
Serwery WWW stają się coraz bardziej dojrzałe pod względem obsługi większych obciążeń, większej współbieżności i lepszych funkcji. Serwery aplikacji zapewniają coraz więcej możliwości komunikacji opartej na protokole HTTP.
W tym momencie granica między „serwerem aplikacji” a „serwerem WWW” jest rozmyta. Ale ludzie nadal używają tych terminów inaczej, co wymaga podkreślenia. Kiedy ktoś mówi „serwer WWW”, często myślisz o aplikacjach zorientowanych na HTTP, web UI. Kiedy ktoś mówi „serwer aplikacji”, możesz pomyśleć „większe obciążenia, funkcje korporacyjne, transakcje i kolejkowanie, komunikacja wielokanałowa (HTTP + więcej). Ale często jest to ten sam produkt, który obsługuje oba zestawy wymagań dotyczących obciążenia.
Jak już powiedziano wcześniej, serwery WWW obsługują petycje HTTP, podczas gdy serwery aplikacji obsługują petycje dla komponentów rozproszonych. Być może najłatwiejszym sposobem na zrozumienie różnicy jest porównanie dwóch produktów pod względem oferowanego środowiska programistycznego.
IIS: ASP (.NET)
Tomcat: Servlet
Jetty: Servlet
Apache: Php, CGI
MTS: COM +
WAS: EJB
JBoss: EJB
Serwer aplikacji WebLogic: EJB
Zasadnicza różnica polega na tym, że serwery aplikacji obsługują niektóre technologie komponentów rozproszonych , zapewniając takie funkcje, jak zdalne wywoływanie i transakcje rozproszone, takie jak EJB w świecie Java lub COM + na platformie Microsoft. Serwer HTTP często obsługuje prostsze środowiska programowania, często skrypty, takie jak ASP (.NET) w przypadku Microsoft lub Servlet, w tym JSP i wiele innych w przypadku Java lub PHP i CGI w przypadku Apache.
Inne możliwości, takie jak równoważenie obciążenia, klastrowanie, przełączanie awaryjne sesji, pule połączeń itp., Które kiedyś znajdowały się w dziedzinie serwerów aplikacji, stają się dostępne na serwerach internetowych, a także bezpośrednio lub za pośrednictwem produktów innych firm.
Na koniec warto zauważyć, że obraz jest dodatkowo zniekształcony przez „lekkie kontenery”, takie jak Spring Framework, które często uzupełniają przeznaczenie serwerów aplikacji w prostszy sposób i bez infrastruktury serwerów aplikacji. A ponieważ aspekt dystrybucji w aplikacjach zmienia się z komponentu rozproszonego na paradygmat usług i architekturę SOA, jest coraz mniej miejsca dla tradycyjnych serwerów aplikacji.
Główną różnicą między serwerem WWW a serwerem aplikacji jest to, że serwer WWW ma obsługiwać strony statyczne, np. HTML i CSS, podczas gdy serwer aplikacji jest odpowiedzialny za generowanie dynamicznej zawartości przez wykonanie kodu po stronie serwera, np. JSP, Servlet lub EJB.
Którego powinienem użyć?
Gdy poznasz różnicę między serwerem internetowym a serwerem aplikacji i kontenerami internetowymi, łatwo będzie dowiedzieć się, kiedy z nich korzystać. Potrzebujesz web serverpodobnego do Apache HTTPD, jeśli udostępniasz statyczne strony internetowe. Jeśli masz aplikację Java z JSP i serwletem do generowania dynamicznej zawartości, potrzebujesz web containersTomcat lub Jetty. Chociaż jeśli masz aplikację Java EE korzystającą z EJB, transakcje rozproszone, wiadomości i inne fantazyjne funkcje, niż potrzebujesz pełnoprawnych, application servertakich jak JBoss, WebSphere lub Oracle WebLogic.
Kontener WWW jest częścią serwera WWW, a serwer WWW jest częścią serwera aplikacji.
Serwer WWW składa się z kontenera WWW, podczas gdy serwer aplikacji składa się z kontenera WWW oraz kontenera EJB.
W skrócie, serwer sieciowy to serwer, który udostępnia użytkownikom strony internetowe za pośrednictwem protokołu http. Serwer aplikacji jest serwerem, który obsługuje logikę biznesową dla systemu. Często hostuje zarówno długo działające / procesy wsadowe i / lub usługi międzyoperacyjne nieprzeznaczone do spożycia przez ludzi (usługi REST / JSON, SOAP, RPC itp.).
Serwer WWW obsługuje wyłącznie żądania HTTP / HTTPS. Służy do treści w Internecie przy użyciu protokołu HTTP / HTTPS.
Serwer aplikacji obsługuje logikę biznesową programów aplikacyjnych za pośrednictwem dowolnej liczby protokołów, w tym ewentualnie HTTP. Program aplikacyjny może korzystać z tej logiki, tak jak wywołuje metodę na obiekcie. W większości przypadków serwer udostępnia tę logikę biznesową za pomocą interfejsu API komponentu, takiego jak model komponentu EJB (Enterprise JavaBean) znaleziony na serwerach aplikacji Java EE (Java Platform, Enterprise Edition). Najważniejsze jest to, że serwer WWW ujawnia wszystko poprzez protokół http, podczas gdy serwer aplikacji nie jest do niego ograniczony. Serwer aplikacji oferuje zatem znacznie więcej usług niż serwer WWW, które zazwyczaj obejmują:
Większość serwerów aplikacji ma wbudowany serwer WWW, co oznacza, że App Server może robić wszystko, co jest w stanie zrobić. Dodatkowo serwer aplikacji ma komponenty i funkcje do obsługi usług na poziomie aplikacji, takich jak pula połączeń, pule obiektów, obsługa transakcji, usługi przesyłania wiadomości itp.
Serwer aplikacji może (ale nie zawsze) działać na serwerze WWW w celu wykonania logiki programu, której wyniki mogą być następnie dostarczone przez serwer WWW. To jeden przykład scenariusza serwera WWW / serwera aplikacji. Dobrym przykładem w świecie Microsoft jest relacja Internet Information Server / SharePoint Server. IIS to serwer sieciowy; SharePoint to serwer aplikacji. SharePoint znajduje się „na szczycie” IIS, wykonuje określoną logikę i obsługuje wyniki za pośrednictwem IIS. W świecie Java istnieje podobny scenariusz, na przykład z Apache i Tomcat.
Ponieważ serwery sieciowe dobrze nadają się do treści statycznych, a serwery aplikacji do treści dynamicznych, większość środowisk produkcyjnych ma serwer WWW działający jako odwrotne proxy do serwera aplikacji. Oznacza to, że podczas obsługi żądania strony treść statyczna, taka jak obrazy / statyczny HTML, jest obsługiwana przez serwer WWW, który interpretuje żądanie. Przy użyciu pewnego rodzaju techniki filtrowania (głównie rozszerzenia żądanego zasobu) serwer sieciowy identyfikuje dynamiczne żądanie treści i w sposób transparentny przekazuje je do serwera aplikacji.
Przykładem takiej konfiguracji jest serwer HTTP Apache i serwer BEA WebLogic. Serwer HTTP Apache to serwer WWW, a BEA WebLogic to serwer aplikacji. W niektórych przypadkach serwery są ściśle zintegrowane, takie jak IIS i .NET Runtime. IIS to serwer WWW. gdy jest wyposażony w środowisko uruchomieniowe .NET, IIS może świadczyć usługi aplikacji
Web Server Programming Environment
Apache PHP, CGI
IIS (Internet Information Server) ASP (.NET)
Tomcat Servlet
Jetty Servlet
Application Server Programming Environment
WAS (IBM's WebSphere Application Server) EJB
WebLogic Application Server (Oracle's) EJB
JBoss AS EJB
MTS COM+
Serwer aplikacji jest zwykle projektowany i wdrażany w celu ułatwienia dłuższych procesów, które również będą wymagały więcej zasobów.
Serwer sieciowy jest używany do krótkich serii, które generalnie nie wymagają dużych zasobów. Ma to na celu głównie ułatwienie obsługi ruchu sieciowego.
Granica między nimi staje się coraz cieńsza.
Serwery aplikacji udostępniają klientom logikę biznesową. Oznacza to, że serwery aplikacji składają się z zestawu metod (choć nie tylko, może to być nawet komputer sieciowy umożliwiający wielu użytkownikom uruchamianie na nim oprogramowania) do wykonywania logiki biznesowej. Więc po prostu wyświetli pożądane wyniki, a nie treść HTML. (podobny do wywołania metody). Więc nie jest ściśle oparty na HTTP.
Ale serwery WWW przekazują treść HTML do przeglądarek internetowych (ściśle oparte na HTTP). Serwery WWW były w stanie obsłużyć tylko statyczne zasoby internetowe, ale pojawienie się skryptów po stronie serwera pozwoliło również serwerom na obsługę dynamicznej zawartości. Tam, gdzie serwer internetowy przyjmuje żądanie i kieruje je do odpowiednich skryptów (PHP, JSP, skrypty CGI itp.) W celu UTWORZENIA zawartości HTML, która zostanie wysłana do klienta. Po otrzymaniu treści serwer WWW wyśle stronę HTML do klienta.
Jednak obecnie oba te serwery są używane razem. Gdzie serwer WWW przyjmuje żądanie, a następnie wywołuje skrypt w celu utworzenia treści HTML. Następnie skrypt ponownie wywoła serwer aplikacji LOGIC (np. Pobierz szczegóły transakcji), aby wypełnić treść HTML.
Oba serwery są efektywnie wykorzystywane.
Dlatego .... Możemy śmiało powiedzieć, że obecnie w większości przypadków serwery sieciowe są używane jako podzbiór serwerów aplikacji. ALE teatralnie tak nie jest.
Przeczytałem wiele artykułów na ten temat i uznałem ten artykuł za bardzo przydatny.
W języku Java jest jeszcze jeden: kontener WWW (a ściślej kontener serwletu). Powiedzmy, że pomiędzy serwerem WWW a serwerem aplikacji.
Kontener WWW w języku Java jest serwerem aplikacji, który zasadniczo implementuje tylko część JSP / Servlet Java EE i brakuje kilku podstawowych części Java EE, takich jak obsługa EJB. Przykładem jest Apache Tomcat.
Serwer aplikacji jest maszyną (w rzeczywistości wykonywalnym procesem działającym na niektórych komputerach), która „nasłuchuje” (na dowolnym kanale, przy użyciu dowolnego protokołu), od żądań klientów dotyczących dowolnej usługi, którą świadczy, a następnie robi coś na podstawie tych żądań. (może, ale nie musi, wiązać się z respektem dla klienta)
Serwer sieciowy działa na komputerze, który „nasłuchuje” konkretnie na kanale TCP / IP za pomocą jednego z protokołów „internetowych” (http, https, ftp itp.) I robi wszystko, co robi na podstawie tych przychodzących żądań. .. Ogólnie (zgodnie z pierwotną definicją) pobrał / wygenerował i zwrócił klientowi stronę internetową HTML, albo pobrany ze statycznego pliku HTML na serwerze, albo zbudowany dynamicznie na podstawie parametrów w przychodzącym żądaniu klienta.
Serwer WWW obsługuje protokół HTTP do obsługi stron internetowych. Serwer aplikacji może (ale nie zawsze) działać na serwerze WWW w celu wykonania logiki programu, której wyniki mogą być następnie dostarczone przez serwer WWW. To jeden przykład scenariusza serwera WWW / serwera aplikacji.
Dobrym przykładem w świecie Microsoft jest relacja Internet Information Server / SharePoint Server. IIS to serwer sieciowy; SharePoint to serwer aplikacji. SharePoint znajduje się „na szczycie” IIS, wykonuje określoną logikę i obsługuje wyniki za pośrednictwem IIS.
W świecie Java istnieje podobny scenariusz, na przykład z Apache i Tomcat.
Z jednej strony serwer WWW obsługuje treści internetowe (HTML i statyczne) za pośrednictwem protokołu HTTP. Z drugiej strony serwer aplikacji jest kontenerem, na którym można budować i udostępniać logikę biznesową i procesy aplikacjom klienckim za pomocą różnych protokołów, w tym HTTP w architekturze wielowarstwowej.
Serwer aplikacji oferuje zatem znacznie więcej usług niż serwer WWW, które zazwyczaj obejmują:
AFAIK, ATG Dynamo był jednym z pierwszych serwerów aplikacji pod koniec lat 90-tych (zgodnie z powyższą definicją). Na początku 2000 roku było to panowanie niektórych zastrzeżonych serwerów aplikacji, takich jak ColdFusion (CFML AS), BroadVision (JavaScript po stronie serwera AS) itp. Ale tak naprawdę żaden nie przetrwał ery serwerów aplikacji Java.
Podstawowa znajomość :
W architekturze serwera klienta
Serwer:> Który obsługuje żądania.
Klient:> Który korzysta z usługi.
Serwer WWW i serwer aplikacji to aplikacje, które działają jak serwery dla swoich klientów.
Nazwiska otrzymywali na podstawie miejsca użytkowania.
Web server :> serve web content
:> Like Html components
:> Like Javascript components
:> Other web components like images,resource files
:> Supports mainly web protocols like http,https.
:> Supports web Request & Response formats.
Stosowanie --
we require low processing rates, regular processing practices involves.Np .: Wszystkie płaskie serwery są ogólnie dostępne gotowe, które obsługują tylko treści internetowe.
Application server :> Serve application content/component data(Business data).
:> These are special kind which are custom written
designed/engineered for specific
purpose.some times fully unique in
their way and stands out of the crowd.
:> As these serves different types of data/response contents
:> So we can utilize these services for mobile client,web
clients,intranet clients.
:> Usually application servers are services offered on different
protocols.
:> Supports different Request& Response formats.
Stosowanie --
we require multi point processing, specialized processing techniques involves like for AI.Np .: serwery map Google, serwery wyszukiwania Google, serwery dokumentów Google, serwery Microsoft 365, serwery Microsoft Computer Vision dla AI.
Możemy je przyjąć jako poziomy / hierarchie w architekturze 4-poziomowej / n-poziomowej.
So they can provide
load balancing,
multiple security levels,
multiple active points,
even they can provide different request processing environments.
Kliknij ten link, aby uzyskać standardowe analogie architektury:
https://docs.microsoft.com/en-us/previous-versions/msp-np/ee658120(v%3dpandp.10)
Największą różnicą jest to, że serwer WWW obsługuje żądania HTTP, podczas gdy serwer aplikacji wykonuje logikę biznesową na dowolnej liczbie protokołów.
W rzeczywistości Apache to serwer WWW, a Tomcat to serwer aplikacji. Kiedy jako żądanie HTTP przychodzi do serwera WWW. Następnie statyczna zawartość odsyła z powrotem do przeglądarki przez serwer WWW. Czy istnieje logika do zrobienia, a następnie żądanie to zostanie wysłane do serwera aplikacji. po przetworzeniu logiki odpowiedź następnie wyślij na serwer WWW i wyślij do klienta.
Wszystko to po prostu komplikuje coś bardzo prostego. Serwer aplikacji zawiera serwer WWW, serwer aplikacji ma tylko kilka dodatkowych dodatków / rozszerzeń niż standardowe serwery WWW. Jeśli spojrzysz na TomEE jako przykład:
CDI - Apache OpenWebBeans
EJB - Apache OpenEJB
JPA - Apache OpenJPA
JSF - Apache MyFaces
JSP - Apache Tomcat
JSTL - Apache Tomcat
JTA - Apache Geronimo Transaction
Servlet - Apache Tomcat
Javamail - Apache Geronimo JavaMail
Bean Validation - Apache BVal
Zobaczysz, że Tomcat (kontener / serwer internetowy) to po prostu kolejne narzędzie w arsenale serwerów aplikacji. Możesz pobrać JPA i inne technologie na serwer WWW, jeśli chcesz, ale serwery aplikacji po prostu pakują wszystkie te rzeczy dla Twojej wygody. Aby zostać w pełni sklasyfikowanym jako serwer aplikacji, musisz zasadniczo przestrzegać listy narzędzi określonych przez jakiś standard.
Nie musi istnieć wyraźna linia podziału. Obecnie wiele programów łączy elementy zarówno - obsługi zapytań HTTP (serwer WWW) i obsługi logiki biznesowej (serwer aplikacji)
Od https://en.wikipedia.org/wiki/Web_server
Serwer WWW to system komputerowy, który przetwarza żądania za pośrednictwem protokołu HTTP, podstawowy protokół sieciowy używany do dystrybucji informacji w sieci World Wide Web. Termin ten może odnosić się do całego systemu, a konkretnie do oprogramowania, które akceptuje i nadzoruje żądania HTTP .
From https://en.wikipedia.org/wiki/Application_server#Application_Server_definition
Serwer aplikacji działa za serwerem WWW (np. Apache lub Microsoft Internet Information Services (IIS)) i (prawie zawsze) przed bazą danych SQL (np. PostgreSQL, MySQL lub Oracle).
Aplikacje internetowe to kody komputerowe działające na serwerach aplikacji i napisane w języku (językach) obsługiwanym przez serwer aplikacji i wywołujące biblioteki wykonawcze oraz komponenty oferowane przez serwer aplikacji .
Serwer aplikacji i serwer WWW są używane do hostowania aplikacji WWW. Z drugiej strony Web Server zajmuje się kontenerem internetowym Application Server zajmuje się kontenerem internetowym, a także kontenerem EJB (Enterprise JavaBean) lub kontenerem COM + dla Microsoft dot Net.
Serwer WWW został zaprojektowany do obsługi statycznych treści HTTP, takich jak HTML, obrazy itp., A dla treści dynamicznych są dostępne wtyczki do obsługi języków skryptowych takich jak Perl, PHP, ASP, JSP itp. Ogranicza się to do protokołu HTTP. Poniższe serwery mogą generować dynamiczną zawartość HTTP.
Środowisko programistyczne serwera WWW:
IIS: ASP (.NET)
Apache Tomcat: Servlet
Jetty: Servlet
Apache: Php, CGI
Serwer aplikacji może robić wszystko, co serwer sieciowy potrafi i nasłuchuje przy użyciu dowolnego protokołu, a serwer aplikacji ma komponenty i funkcje do obsługi usług na poziomie aplikacji, takich jak pula połączeń, pula obiektów, obsługa transakcji, usługi przesyłania wiadomości itp.
Środowisko programowania serwera aplikacji:
MTS: COM +
WAS: EJB
JBoss: EJB
Serwer aplikacji WebLogic: EJB
Chociaż mogą się nakładać na siebie (niektóre serwery WWW mogą być nawet używane jako serwery aplikacji), największą różnicą IMHO jest model przetwarzania i zarządzanie sesją:
W modelu przetwarzania serwera WWW nacisk kładziony jest na obsługę żądań; pojęcie „sesji” jest prawie wirtualne. To znaczy, że „sesja” jest symulowana przez przeniesienie reprezentacji stanu między klientem a serwerem (stąd REST) i / lub serializację jej do zewnętrznego trwałego magazynu (SQL Server, Memcached itp.).
Na serwerze aplikacji sesja jest zwykle bardziej wyraźna i często przyjmuje postać obiektu żyjącego w pamięci serwera aplikacji przez cały czas trwania „sesji”.
To zależy od konkretnej architektury. Niektóre serwery aplikacji mogą natywnie używać protokołów internetowych (XML / RPC / SOAP przez HTTP), więc różnica techniczna jest niewielka. Zazwyczaj serwer WWW jest skierowany do użytkownika, obsługujący różnorodne treści przez HTTP / HTTPS, podczas gdy serwer aplikacji nie jest przeznaczony do obsługi przez użytkownika i może używać niestandardowych lub nierutowalnych protokołów. Oczywiście w przypadku RIA / AJAX różnicę można jeszcze bardziej zaciemnić, obsługując tylko treści inne niż HTML (JSON / XML) dla klientów pompujących określone usługi zdalnego dostępu.
IMO, przede wszystkim chodzi o rozdzielenie obaw.
Z czysto technicznego punktu widzenia możesz zrobić wszystko (zawartość sieci + logika biznesowa) na jednym serwerze WWW. Jeśli to zrobisz, informacja zostanie osadzona w treści żądania HTML. Jaki byłby wpływ?
Na przykład wyobraź sobie, że masz 2 różne aplikacje, które renderują zupełnie inną treść HTML w przeglądarce. Jeśli podzielisz logikę biznesową na serwer aplikacji, możesz udostępnić różne serwery sieciowe wyszukujące te same dane na serwerze aplikacji za pomocą skryptów. Jeśli jednak nie rozdzielisz logiki i nie zatrzymasz jej na serwerze internetowym, za każdym razem, gdy zmienisz swój model biznesowy, skończysz na zmianie na każdym serwerze internetowym, który posiadasz, co zajmie więcej czasu, będzie mniej niezawodne i podatne na błędy.