Чим відрізняється сервер додатків від веб-сервера?

Чим відрізняється сервер додатків від веб-сервера?

Більшість випадків ці терміни Веб-сервер та сервер додатків використовуються взаємозамінно.

Нижче наведено деякі ключові відмінності в особливостях веб-сервера та сервера додатків:

• Веб-сервер призначений для обслуговування вмісту HTTP. Сервер додатків також може обслуговувати вміст HTTP, але не обмежується лише HTTP. Може надаватися інша підтримка протоколу, наприклад, RMI / RPC
• Веб-сервер в основному призначений для обслуговування статичного контенту, хоча більшість веб-серверів мають плагіни для підтримки мов скриптів, таких як Perl, PHP, ASP, JSP тощо. За допомогою цих серверів можна генерувати динамічний контент HTTP.
• Більшість серверів прикладних програм є веб-сервером як невід'ємною частиною їх, це означає, що сервер додатків може робити все, на що здатний веб-сервер. Крім того, у App Server є компоненти та функції для підтримки службових служб на рівні додатків, таких як Пул підключення, Об'єднання об'єднань, Підтримка транзакцій, Послуги обміну повідомленнями тощо.
• Оскільки веб-сервери добре підходять для статичного контенту, а сервери додатків для динамічного контенту, більшість виробничих середовищ мають веб-сервер, що діє як зворотний проксі для сервера додатків. Це означає, що під час обслуговування запиту на сторінку статичний вміст (наприклад, зображення / статичний HTML) обслуговується веб-сервером, який інтерпретує запит. Використовуючи якусь техніку фільтрації (в основному розширення запитуваного ресурсу) веб-сервер ідентифікує динамічний запит на вміст і прозоро пересилає на сервер додатків

Прикладом такої конфігурації є HTTP-сервер Apache Tomcat та Oracle (раніше BEA) WebLogic Server. Apache Tomcat HTTP Server - це веб-сервер, а Oracle WebLogic - сервер додатків.

У деяких випадках сервери тісно інтегровані, такі як IIS та .NET Runtime. IIS - веб-сервер. Оснащуючись середовищем виконання .NET, IIS здатний надавати послуги додатків.

Це детальна відповідь з деякими сценаріями, щоб чітко зрозуміти різницю, схожість і те, як обидва можуть працювати спільно і все

Сервер додатків - термін, який іноді змішується з веб-сервером . Хоча веб-сервер обробляє в основному протоколи HTTP , сервер додатків працює з декількома різними протоколами, включаючи, але не обмежуючись, HTTP .

Основне завдання веб-сервера - відображення вмісту сайту, а сервер додатків відповідає за логіку , взаємодію між користувачем та відображеним вмістом. Сервер додатків працює спільно з веб-сервером, де один відображає, а інший взаємодіє.

Інформація, що переміщається туди-назад між сервером та його клієнтом, не обмежується простою розміткою дисплея, а взаємодією між ними.

У більшості випадків сервер створює цю взаємодію за допомогою компонентів API , таких як J2EE (платформа Java 2) , EJB (Enterprise JavaBean) та інших різних моделей прикладного програмного забезпечення.

Приклад:

Найкращий спосіб зрозуміти різницю між сценаріями, коли сервер додатків працює з веб-сервером, порівняно зі сценарієм, коли немає сервера додатків, через Інтернет-магазин.

Сценарій 1: Веб-сервер без сервера додатків

у вас є інтернет-магазин із лише веб-сервером та відсутнім сервером додатків. На сайті буде розміщено дисплей, де ви можете вибрати товар. Коли ви надсилаєте запит, сайт здійснює пошук і повертає результат HTML назад своєму клієнту. Веб-сервер надсилає ваш запит безпосередньо на сервер бази даних (будьте терплячі, я поясню це в наступному наггеті) і чекає відповіді. Після отримання веб-сервер формулює відповідь у HTML-файл і надсилає його у ваш веб-браузер. Ця комунікація між сервером та сервером баз даних відбувається щоразу, коли виконується запит.

Сценарій 2: Веб-сервер із сервером додатків

якщо запит, який ви хочете запустити, вже був виконаний раніше і дані з того часу не змінювалися, сервер генерує результати, не надсилаючи запит на сервер бази даних. Це дозволяє здійснювати запит у режимі реального часу, коли другий клієнт може отримати доступ до тієї ж інформації та отримувати надійну інформацію в режимі реального часу, не надсилаючи ще один дублікат запиту на сервер бази даних. Сервер в основному виступає в якості проміжного між сервером бази даних та веб-сервером. Це дозволяє повторно використати інформацію, витягнуту під час першого сценарію, оскільки ця інформація вбудована в певну та "підганяну" сторінку HTML, це не є процесом багаторазового використання. Другий клієнт повинен буде запросити інформацію ще раз і отримати іншу вбудовану HTML-сторінку з запитуваною інформацією - дуже неефективно.

Для підтримки таких різноманітних складних завдань цей сервер повинен мати вбудованість, велику обробну потужність і високий об'єм оперативної пам’яті для обробки всіх даних, які він витягує в режимі реального часу.

Сподіваюсь, це допомагає.

Обидва терміни дуже загальні, один містить інший, а в деяких випадках навпаки.

• Веб-сервер : подає вміст у Інтернет за допомогою протоколу http.

• Сервер додатків : розміщує та виставляє бізнес-логіку та процеси.

Я думаю, що головний момент полягає в тому, що веб-сервер виставляє все через протокол http, тоді як сервер додатків не обмежується.

Однак, у багатьох сценаріях ви побачите, що веб-сервер використовується для створення переднього сервера додатків, тобто він відкриває набір веб-сторінок, які дозволяють користувачеві взаємодіяти з діловими правилами, знайденими в сервер додатків.

Веб-сервер

Запустіть python -m 'SimpleHTTPServer'і перейдіть до http: // localhost: 8080 . Що ви бачите, це веб-сервер, який працює. Сервер просто обслуговує файли через HTTP, що зберігаються на вашому комп'ютері. Ключовим моментом є те, що все це робиться поверх протоколу HTTP. Наприклад, існують FTP-сервери, які роблять точно те саме (подання збережених файлів), але поверх іншого протоколу.

Сервер додатків

Скажімо, у нас є крихітний додаток, як показано нижче (фрагмент від колби ).

@app.route('/')
def homepage():
    return '<html>My homepage</html>'

@app.route('/about')
def about():
    return '<html>My name is John</html>'

Невеликий приклад програми відображає URL /до функції homepage()та /aboutдо функції about().

Для запуску цього коду нам потрібен сервер додатків (наприклад, Gunicorn) - програма або модуль, який може слухати запити клієнта і, використовуючи наш код, повертати щось динамічно. У прикладі ми просто повертаємо дуже поганий HTML.

Про яку логіку бізнесу говорять усі інші? Отже, оскільки URL-адреса відображається десь конкретно в нашій кодовій базі, ми гіпотетично показуємо певну логіку щодо того, як працює наша програма.

Резюме

веб-сервер - подає файли, що зберігаються десь (найчастіше .css, .html, .js). Поширені веб-сервери - Apache, Nginx або навіть Python's SimpleHTTPServer.

сервер додатків - обслуговує файли, що генеруються на льоту. По суті, більшість веб-серверів мають якісь плагіни або навіть мають вбудований функціонал для цього. Існують також жорсткі сервери додатків, такі як Gunicorn (Python), Unicorn (Ruby), uWSGI (Python) тощо.

Зауважте, що ви можете фактично створити веб-сервер з кодом сервера додатків. Це робиться в деяких випадках під час розробки, коли ви не хочете мати на своєму комп’ютері газильйон різних серверів.

Як вказували Рутеш і jmservera, відмінність нечітка. Історично вони були різними, але протягом 90-х ці дві раніше розрізнені категорії змішали риси та ефективно злилися. На даний момент, мабуть, найкраще уявити, що категорія продуктів "Сервер додатків" є суворим набором категорії "веб-сервер".

Якась історія. У перші дні веб-переглядача Mosaic і гіперпосилання з вмістом розвивалася ця річ, яка називалася "веб-сервер", який обслуговував вміст і зображення веб-сторінок через HTTP. Більша частина вмісту була статичною, а протокол HTTP 1.0 був лише способом передачі файлів. Швидко категорія "веб-сервер" перетворилася на функцію CGI - ефективно запускаючи процес у кожному веб-запиті для створення динамічного контенту. HTTP також дозрів, і продукти стали більш досконалими, з кешуванням, безпекою та управлінням. Коли технологія дозріла, ми отримали технологію на базі сервера на базі Java, створену на базі сервера від Kiva та NetDynamics, яка з часом все об'єдналася в JSP. Microsoft додав ASP, я думаю, у 1996 році до Windows NT 4.0. Статичний веб-сервер навчився деяких нових хитрощів, щоб він був ефективним "

У паралельній категорії сервер додатків розвивався і існував тривалий час. компанії поставляли товари для Unix, такі як Tuxedo, TopEnd, Encina, які по-філософськи походять від керування додатками Mainframe та середовища моніторингу, такі як IMS та CICS. Пропозиція Microsoft - сервер транзакцій Microsoft (MTS), який згодом перетворився на COM +. Більшість із цих продуктів вказали "закриті" протоколи комунікацій, що стосуються конкретного продукту, щоб з'єднати "жирних" клієнтів із серверами. (Для Encina протокол comms був DCE RPC; для MTS це DCOM; тощо). У 1995/96 рр. Ці традиційні продукти сервера додатків почали впроваджувати основні можливості HTTP-зв’язку спочатку через шлюзи. І лінії почали розмиватися.

Веб-сервери стають все більш зрілими щодо обробки більш високих навантажень, більшої конкурентоспроможності та кращих функцій. Сервери додатків надають все більше можливостей на основі HTTP-зв'язку.

У цей момент лінія між "сервером додатків" та "веб-сервером" є нечіткою. Але люди продовжують використовувати терміни по-різному, як питання акценту. Коли хтось каже "веб-сервер", ви часто думаєте про додатки, орієнтовані на HTTP, веб-інтерфейс. Коли хтось скаже "Сервер додатків", ви можете подумати "більш важкі навантаження, функції підприємства, транзакції та черги, багатоканальний зв'язок (HTTP + більше). Але часто це той самий продукт, який обслуговує обидва набори вимог навантаження.

• WebSphere, "сервер додатків" IBM має власний пакетний веб-сервер.
• WebLogic - ще один традиційний сервер додатків.
• Windows, що є сервером додатків Microsoft (крім того, що є файлом і сервером друку, медіа-сервером тощо), вбудовує IIS.

Як багато хто говорив раніше, веб-сервери обробляють петиції HTTP, тоді як сервери додатків обробляють петиції для розподілених компонентів. Тож, можливо, найпростіший спосіб зрозуміти різницю - це порівняння двох продуктів щодо програмного середовища, яке вони пропонують.

Веб-сервер -> Середовище програмування

IIS: ASP (.NET)

Томат: Сервлет

Причал: Сервлет

Apache: Php, CGI

Сервери програм -> Середовище програмування

МТС: COM +

БУЛО: EJB

JBoss: EJB

WebLogic Application Server: EJB

Найважливішою відмінністю є те, що сервери прикладних програм підтримують деяку технологію розподілених компонентів , надаючи такі функції, як віддалений виклик та розподілені транзакції, як-от EJB у світі Java або COM + на платформі Microsoft. Сервер Http часто підтримує деякі простіші програми програмування, часто сценарії, як ASP (.NET) у випадку Microsoft або Servlet, включаючи JSP та багато інших у випадку Java або PHP та CGI у випадку Apache.

Інші можливості, такі як балансування навантаження, кластеризація, відмова від сеансу, об'єднання з'єднань тощо, які раніше були у царині серверів прикладних програм, стають доступними як на веб-серверах, так і безпосередньо або через деякі сторонні продукти.

Нарешті, варто зауважити, що картинка додатково спотворюється такими "легкими контейнерами", як Spring Framework, які часто доповнюють призначення серверів додатків більш простим способом і без інфраструктури сервера додатків. А оскільки аспект розподілу в додатках рухається від розподіленого компонента до парадигми обслуговування та архітектури SOA, для традиційних серверів додатків залишається все менше місця.

Основна відмінність веб-сервера від сервера додатків полягає в тому, що веб-сервер призначений для обслуговування статичних сторінок, наприклад, HTML і CSS, тоді як сервер додатків відповідає за генерування динамічного контенту шляхом виконання коду сторони сервера, наприклад, JSP, Servlet або EJB.

Який я повинен використовувати?
Як тільки ви знаєте різницю між веб-сервером та сервером додатків та веб-контейнерами, легко зрозуміти, коли ними користуватися. Вам потрібен web serverподібний Apache HTTPD, якщо ви розміщуєте статичні веб-сторінки. Якщо у вас є Java-програма з просто JSP та Servlet для створення динамічного контенту, то вам потрібно, web containersяк Tomcat або Jetty. Хоча, якщо у вас є додаток Java EE з використанням EJB, розподілених транзакцій, обміну повідомленнями та інші фантазії особливості , ніж вам потрібно повноцінний , application serverяк JBoss, WebSphere або WebLogic Oracle.

Веб-контейнер є частиною веб-сервера, а веб-сервер - частиною сервера додатків.

Веб-сервер складається з веб-контейнера, тоді як сервер додатків складається з веб-контейнера, а також контейнера EJB.

Коротше кажучи, веб-сервер - це сервер, який обслуговує веб-сторінки користувачам через http. Сервер додатків - це сервер, на якому розміщена бізнес-логіка для системи. У ньому часто розміщуються як тривалі / пакетні процеси, так і / або послуги інтероп, не призначені для споживання людиною (послуги REST / JSON, SOAP, RPC тощо).

Веб-сервер обробляє виключно HTTP / HTTPS запити. Він обслуговує вміст в Інтернеті за допомогою протоколу HTTP / HTTPS.

Сервер додатків обслуговує бізнес-логіку прикладних програм через будь-яку кількість протоколів, можливо, включаючи HTTP. Прикладна програма може використовувати цю логіку так само, як вона називатиме метод на об'єкті. У більшості випадків сервер відкриває цю бізнес-логіку через компонентний API, такий як модель компонентів EJB (Enterprise JavaBean), знайдена на серверах прикладних програм Java EE (Java Platform, Enterprise Edition). Основний момент полягає в тому, що веб-сервер відкриває все через протокол http, тоді як сервер додатків не обмежується. Таким чином, сервер додатків пропонує набагато більше послуг, ніж веб-сервер, який, як правило, включає:

• API (власний чи ні)
• Завантажити балансування, вийти з ладу ...
• Управління життєвим циклом об'єкта
• Державне управління (сесія)
• Управління ресурсами (наприклад, пули підключення до бази даних)

Більшість серверів прикладних програм є веб-сервером як невід'ємною частиною їх, це означає, що сервер додатків може робити все, на що здатний веб-сервер. Крім того, у App Server є компоненти та функції для підтримки службових служб на рівні додатків, таких як Пул підключення, Об'єднання об'єднань, Підтримка транзакцій, Послуги обміну повідомленнями тощо.

Сервер додатків може (але не завжди) працювати на веб-сервері для виконання логіки програми, результати якої можуть бути надані веб-сервером. Це один із прикладів сценарію веб-сервера / сервера додатків. Хорошим прикладом у світі Microsoft є відносини Internet Information Server / SharePoint Server. IIS - веб-сервер; SharePoint - сервер додатків. SharePoint сидить "на вершині" IIS, виконує певну логіку та подає результати через IIS. У світі Java існує подібний сценарій, наприклад, з Apache та Tomcat.

Оскільки веб-сервери добре підходять для статичного контенту, а сервери додатків для динамічного контенту, більшість виробничих середовищ мають веб-сервер, що діє як зворотний проксі для сервера додатків. Це означає, що під час обслуговування запиту на сторінку, статичний вміст, такий як зображення / статичний html, обслуговується веб-сервером, який інтерпретує запит. Використовуючи якусь техніку фільтрації (в основному розширення запитуваного ресурсу) веб-сервер ідентифікує динамічний запит на вміст і прозоро направляє на сервер додатків.

Прикладом такої конфігурації є Apache HTTP Server та BEA WebLogic Server. Apache HTTP Server - це веб-сервер, а BEA WebLogic - сервер додатків. У деяких випадках сервери тісно інтегровані, такі як IIS та .NET Runtime. IIS - веб-сервер. Оснащений середовищем виконання .NET IIS здатний надавати послуги додатків

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+

Сервер додатків, як правило, розробляється та розгортається для полегшення триваліших процесів, які також будуть більш ресурсомісткими.

Веб-сервер використовується для коротких записів, які, як правило, не потребують ресурсів. Це здебільшого сприяє обслуговуванню веб-трафіку.

Межа між цими двома стає все тоншою.

Сервери додатків піддають бізнес-логіку клієнтам. Це означає, що сервери додатків складаються з набору методів (не виключно, хоча вони можуть бути навіть мережевим комп'ютером, що дозволяє багатьом запускати програмне забезпечення на ньому) для виконання бізнес-логіки. Так він буде просто виводити бажані результати, а не вміст HTML. (подібно до виклику методу). Отже, це не строго на основі HTTP.

Але веб-сервери передають вміст HTML у веб-браузери (строго на основі HTTP). Веб-сервери вміли обробляти лише статичні веб-ресурси, але поява сценаріїв на стороні сервера дозволила веб-серверам також обробляти динамічний вміст. Якщо веб-сервер приймає запит і направляє його на відповідні сценарії (PHP, JSP, CGI-скрипти тощо), щоб СТВОРИТИ вміст HTML для надсилання клієнту. Після отримання вмісту веб-сервер відправить клієнту сторінку HTML.

Однак сьогодні обидва ці сервери використовуються разом. Де веб-сервер приймає запит, а потім викликає скрипт для створення вмісту HTML. Потім сценарій знову зателефонує на сервер додатків LOGIC (наприклад, Отримати дані транзакцій) для заповнення вмісту HTML.

Тому обидва сервери ефективно використовуються.

Тому .... Ми можемо з упевненістю сказати, що нині у більшості випадків веб-сервери використовуються як підмножина серверів прикладних програм. Але театрально НЕ так.

Я прочитав багато статей на цю тему і вважав цю статтю досить зручною.

З точки зору Java, є ще один: веб-контейнер (або, більш строго, контейнер сервлетів). Це, скажімо, між веб-сервером та сервером додатків.

Веб - контейнер Java термінів є сервером додатків , які в основному тільки реалізує JSP / Servlet частина Java EE і не вистачає кілька основних частин Java EE, таких як підтримка EJB. Приклад - Apache Tomcat.

Сервер додатків - це машина (фактично виконуваний процес, який працює на якійсь машині), яка "слухає" (на будь-якому каналі, використовуючи будь-який протокол), для запитів клієнтів для будь-якої послуги, яку він надає, а потім робить щось на основі цих запитів. (може або не може залучати відповідь до клієнта)

Веб-сервер - це процес, який працює на машині, яка спеціально "слухає" на каналі TCP / IP, використовуючи один з протоколів "Інтернет" (http, https, ftp тощо) і робить все, що робиться на основі цих вхідних запитів. .. Як правило, (як визначено оригінально), він діставав / генерував та повертав веб-сторінку html клієнтові, або витягувались із статичного HTML-файлу на сервері, або будувались динамічно на основі параметрів у вхідному запиті клієнта.

Веб-сервер запускає протокол HTTP для обслуговування веб-сторінок. Сервер додатків може (але не завжди) працювати на веб-сервері для виконання логіки програми, результати якої можуть бути надані веб-сервером. Це один із прикладів сценарію веб-сервера / сервера додатків.

Хорошим прикладом у світі Microsoft є відносини Internet Information Server / SharePoint Server. IIS - веб-сервер; SharePoint - сервер додатків. SharePoint сидить "на вершині" IIS, виконує певну логіку та подає результати через IIS.

У світі Java існує подібний сценарій, наприклад, з Apache та Tomcat.

З першого боку, веб-сервер обслуговує веб-контент (HTML та статичний вміст) через протокол HTTP. З іншого боку, сервер додатків - це контейнер, на якому ви можете будувати та виставляти бізнес-логіку та процеси для клієнтських додатків за допомогою різних протоколів, включаючи HTTP в n-ярусної архітектурі.

Таким чином, сервер додатків пропонує набагато більше послуг, ніж веб-сервер, який, як правило, включає:

• API (власний чи ні)
• Управління життєвим циклом об'єкта,
• Державне управління (сесія),
• Управління ресурсами (наприклад, пули підключення до бази даних),
• Завантажити балансування, вийти з ладу ...

AFAIK, ATG Dynamo був одним із перших серверів додатків наприкінці 90-х (згідно з визначенням вище). На початку 2000 року це було правління деяких власних серверів прикладних програм, таких як ColdFusion (CFML AS), BroadVision (JavaScript на стороні сервера JavaScript) тощо.

Основне розуміння:

В архітектурі сервера клієнтів

Сервер:> Що обслуговує запити.

Клієнт:> Що споживає послугу.

Веб-сервер та сервер додатків - це програмні програми, які виступають серверами для своїх клієнтів.

Вони отримали свої назви за місцем їх використання.

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.

Використання -

      we require low processing rates,

      regular processing practices involves.

Напр .: усі плоскі сервери, як правило, готові, які обслуговують лише веб-контент.

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.

Використання -

      we require multi point processing,

      specialized processing techniques involves like for AI.

Наприклад: сервери карт Google, сервери пошуку Google, сервери документів Google, сервери Microsoft 365, сервери комп'ютерного зору Microsoft для AI.

Ми можемо вважати їх як яруси / Ієрархії в 4-ярусної / n-ярусної архітектурі.

 So they can provide 
                    load balancing,
                    multiple security levels,
                    multiple active points,
                    even they can provide different request processing environments.

Перейдіть за цим посиланням для стандартних аналогій архітектури:

https://docs.microsoft.com/en-us/previous-versions/msp-np/ee658120(v%3dpandp.10)

Найбільша різниця полягає в тому, що веб-сервер обробляє HTTP-запити, тоді як сервер додатків виконує бізнес-логіку на будь-якій кількості протоколів.

Насправді Apache - це веб-сервер, а Tomcat - сервер додатків. Коли запит HTTP надходить на веб-сервер. Потім статичний вміст відправляється назад у браузер веб-сервером. Чи робиться логіка, і цей запит відправляється на сервер додатків. після обробки логіки відповідь відправте на веб-сервер і відправте клієнту.

Все вищесказане є лише надмірним ускладненням чогось дуже простого. Сервер додатків містить веб-сервер, сервер додатків просто має ще пару додатків / розширень до нього, ніж звичайні веб-сервери. Якщо ви подивитесь на TomEE як приклад:

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

Ви побачите, що Tomcat (веб-контейнер / сервер) - це ще один інструмент арсеналу серверів додатків. Ви можете отримати JPA та інші технології на веб-сервері, якщо хочете, але сервери додатків просто пакують усі ці речі для вашої зручності. Щоб бути повністю класифікованим як сервер додатків, вам по суті потрібно відповідати переліку інструментів, викладеним певним стандартом.

Не обов'язково є чітка лінія розмежування. На сьогоднішній день багато програм поєднують в собі елементи обох - обслуговування http-запитів (веб-сервер) та обробки бізнес-логіки (сервер додатків)

З https://en.wikipedia.org/wiki/Web_server

Веб - сервер являє собою комп'ютерну систему , яка обробляє запити через HTTP, основний мережевий протокол використовується для розповсюдження інформації про World Wide Web. Термін може стосуватися всієї системи або конкретно до програмного забезпечення, яке приймає та контролює HTTP-запити .

З https://en.wikipedia.org/wiki/Application_server#Application_Server_definition

Сервер додатків працює за веб-сервером (наприклад, Apache або Microsoft Internet Information Services (IIS)) і (майже завжди) перед базою даних SQL (наприклад, PostgreSQL, MySQL або Oracle).

Веб-додатки - це комп'ютерний код, який працює на серверах додатків і написаний мовою (мовами), яку підтримує сервер додатків і викликає бібліотеки виконання та компоненти, які пропонує сервер додатків .

Сервер додатків і веб-сервер використовуються для розміщення веб-додатків. Веб-сервер має справу з веб-контейнером, з іншого боку Сервер додатків має справу з веб-контейнером, а також контейнером EJB (Enterprise JavaBean) або контейнером COM + для Microsoft dot Net.

Веб-сервер призначений для обслуговування статичного контенту HTTP, такого як HTML, зображення тощо, а для динамічного вмісту є плагіни для підтримки мов скриптів, таких як Perl, PHP, ASP, JSP тощо, і він обмежений протоколом HTTP. Нижче сервери можуть генерувати динамічний контент HTTP.

Програмне середовище веб-сервера:

IIS: ASP (.NET)

Apache Tomcat: Сервлет

Причал: Сервлет

Apache: Php, CGI

Сервер прикладних програм може робити все, що спроможний веб-сервер, і слухає, використовуючи будь-який протокол, а також у App Server є компоненти та функції для підтримки служб рівня додатків, таких як Об'єднання Об'єднання, Об'єднання Об'єднання, Підтримка транзакцій, Послуги обміну повідомленнями тощо.

Середовище програмування сервера додатків:

МТС: COM +

БУЛО: EJB

JBoss: EJB

WebLogic Application Server: EJB

Незважаючи на те, що між цими двома можуть бути перекриття (деякі веб-сервери можуть навіть використовуватися як сервери додатків), найбільша різниця IMHO полягає в моделі обробки та керуванні сеансом:

У моделі обробки веб-серверів основна увага приділяється обробці запитів; Поняття "сеанс" є майже віртуальним. Тобто, "сеанс" моделюється перенесенням представлення стану між клієнтом і сервером (отже, REST) ​​та / або серіалізацією його на зовнішнє стійке сховище (SQL Server, Memcached тощо).

На сервері прикладних програм сеанс зазвичай є більш явним і часто формується об'єктом, що живе в пам'яті сервера додатків протягом усієї тривалості "сеансу".

Це залежить від конкретної архітектури. Деякі сервери прикладних програм можуть використовувати веб-протоколи (XML / RPC / SOAP через HTTP), тому технічна різниця є незначною. Як правило, веб-сервер орієнтований на користувачів, який обслуговує різноманітний вміст через HTTP / HTTPS, тоді як сервер додатків не орієнтований на користувачів і може використовувати нестандартні або не маршрутизовані протоколи. Звичайно, з RIA / AJAX, різницю можна ще більше помутніти, надаючи лише вміст без HTML (JSON / XML) клієнтам, що перекачують певні послуги віддаленого доступу.

ІМО, здебільшого йдеться про розділення проблем.

З чисто технічної точки зору, ви можете робити все (веб-контент + бізнес-логіка) на одному веб-сервері. Якщо ви зробите це, то інформація буде вставлена ​​всередину запитуваного вмісту HTML. Який був би вплив?

Наприклад, уявіть, що у вас є 2 різних програми, які відображають зовсім інший вміст HTML у браузері. Якщо ви розділите бізнес-логіку на додаток-сервер, ви могли б надавати різним веб-серверам, які шукають однакові дані на сервері додатків за допомогою скриптів. Однак, якщо ви не розділяєте логіку і зберігаєте її на веб-сервері, щоразу, коли ви змінюєте свою бізнес-модель, ви в кінцевому підсумку змінюєте її на кожному вашому веб-сервері, який би зайняв більше часу, був би менш надійним і схильний помилятися.