В чем разница между сервером приложений и веб-сервером?

Ответ 1

В большинстве случаев эти термины Web Server и сервер приложений используются взаимозаменяемо.

Ниже перечислены некоторые ключевые отличия в функциях веб-сервера и сервера приложений:

Веб-сервер предназначен для обслуживания содержимого HTTP. Сервер приложений также может обслуживать HTTP-контент, но не ограничивается только HTTP. Он может быть предоставлен для поддержки других протоколов, таких как RMI/RPC
Веб-сервер в основном предназначен для обслуживания статического контента, хотя большинство веб-серверов имеют плагины для поддержки языков сценариев, таких как Perl, PHP, ASP, JSP и т.д., через которые эти серверы могут генерировать динамический контент HTTP.
Большинство серверов приложений имеют в своем составе Web-сервер, что означает, что сервер приложений может делать все, на что способен веб-сервер. Кроме того, сервер приложений имеет компоненты и функции для поддержки сервисов уровня приложения, таких как пул соединений, объединение объектов, поддержка транзакций, службы обмена сообщениями и т.д.
Поскольку веб-серверы хорошо подходят для статического контента и серверов приложений для динамического контента, большинство производственных сред имеют веб-сервер, выступающий в качестве обратного прокси-сервера для сервера приложений. Это означает, что при обслуживании запроса страницы статическое содержимое (например, изображения/статический HTML) обслуживается веб-сервером, который интерпретирует запрос. Используя какой-то метод фильтрации (в основном расширение запрашиваемого ресурса), веб-сервер идентифицирует запрос динамического содержимого и прозрачно пересылает сервер приложений.

Пример такой конфигурации - сервер HTTP Apache Tomcat и сервер Oracle (ранее BEA) WebLogic. HTTP-сервер Apache Tomcat - это веб-сервер, а Oracle WebLogic - это сервер приложений.

В некоторых случаях серверы тесно интегрированы, такие как IIS и .NET Runtime. IIS - это веб-сервер. При использовании среды выполнения .NET среда IIS может предоставлять приложения.

Ответ 2

Это подробный ответ с некоторыми сценариями, чтобы четко понимать разницу, сходство и то, как оба могут работать совместно, и все

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

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

Информация, перемещаемая между сервером и его клиентом, не ограничивается простой разметкой экрана, а взаимодействием между ними.

В большинстве случаев сервер создает это взаимодействие через API-интерфейс компонента, например J2EE (платформа Java 2), EJB (Enterprise JavaBean) и другие различные модели прикладных программ.

Пример:

Лучший способ понять разницу между сценариями, в которых сервер приложений работает с веб-сервером, и сценарий, в котором нет сервера приложений, - через интернет-магазин.

Сценарий 1: веб-сервер без сервера приложений

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

Сценарий 2. Веб-сервер с сервером приложений

если запрос, который вы хотите запустить, уже был выполнен ранее, и с тех пор данные не изменились, сервер будет генерировать результаты без необходимости отправки запроса на сервер базы данных. Это позволяет запросить в реальном времени, когда второй клиент может получить доступ к одной и той же информации и получать достоверную информацию в режиме реального времени, не отправляя другой дублирующий запрос на сервер базы данных. Сервер в основном действует как промежуточный сервер базы данных и веб-сервер. Это позволяет извлекать информацию, которую можно повторно использовать, в то время как в первом сценарии, поскольку эта информация встроена в конкретную и "настроенную" HTML-страницу, это не является многоразовым процессом. Второй клиент должен будет снова запросить информацию и получить другую встроенную страницу HTML с запрошенной информацией - очень неэффективно. Не говоря уже о том, что этот тип сервера очень гибкий из-за его способности управлять своими собственными ресурсами, включая безопасность, обработку транзакций, обмен сообщениями и объединение ресурсов.

Для поддержки такого множества сложных задач этот сервер должен иметь встроенную избыточность, большую вычислительную мощность и большое количество ОЗУ для обработки всех данных, которые он вытягивает в реальном времени.

Надеюсь, что это поможет.

Ответ 3

Оба термина являются очень общими, один из них содержит другой, и наоборот в некоторых случаях.

Веб-сервер: служит для контента в Интернете с использованием протокола http.
Сервер приложений: хосты и раскрывают бизнес-логику и процессы.

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

Тем не менее, во многих сценариях вы обнаружите, что веб-сервер используется для создания интерфейсного сервера приложений, то есть он предоставляет набор веб-страниц, которые позволяют пользователю взаимодействовать с бизнес-правилами найденных на сервере приложений.

Ответ 4

Как указывал Rutesh и jmservera, различие является нечетким. Исторически сложилось, что они были разными, но через 90 эти две ранее отличающиеся категории смешивали черты и эффективно сливались. На данный момент лучше всего предположить, что категория продуктов "Сервер приложений" является строгим надмножеством категории "веб-сервер" .

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

В параллельной категории сервер приложений развился и существовал в течение длительного времени. компании поставляли продукты для Unix, такие как Tuxedo, TopEnd, Encina, которые были философски получены из приложений управления и мониторинга приложений для мэйнфреймов, таких как IMS и CICS. Microsoft предлагала Microsoft Transaction Server (MTS), который позже превратился в COM+. Большинство из этих продуктов указали "закрытые" протоколы коммуникаций, специфичные для продукта, для соединения "толстых" клиентов с серверами. (Для Encina протокол comms был DCE RPC, для MTS - DCOM и т.д.). В 1995/96 годах эти традиционные серверные продукты приложений начали внедрять базовые возможности HTTP-связи, сначала через шлюзы. И линии начали размываться.

Веб-серверы стали все более зрелыми в отношении обработки более высоких нагрузок, более concurrency и лучших функций. Серверы приложений поставляли все больше и больше возможностей связи на основе HTTP.

В этот момент линия между "сервером приложений" и "веб-сервером" является нечеткой. Но люди продолжают использовать термины по-разному, в качестве акцента. Когда кто-то говорит "веб-сервер" , вы часто думаете, что HTTP-ориентированный, веб-интерфейс, ориентированные приложения. Когда кто-то говорит "Сервер приложений", вы можете подумать "более тяжелые нагрузки, функции предприятия, транзакции и очередность, многоканальная связь (HTTP + больше). Но часто это тот же продукт, который обслуживает оба набора требований к рабочей нагрузке.

WebSphere, сервер приложений IBM имеет собственный веб-сервер.
WebLogic, другой традиционный сервер приложений, также.
Windows, которая является Microsoft App Server (помимо своего сервера печати и печати, Media Server и т.д.), объединяет IIS.

Ответ 5

Веб-сервер

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

Сервер приложений

Скажем, у нас есть крошечное приложение, как показано ниже (фрагмент из Flask).

@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 SimpleHTTPServer.

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

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

Ответ 6

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

Веб-сервер → среда программирования

IIS: ASP (.NET)

Tomcat: Servlet

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

Apache: Php, CGI

Серверы приложений → среда программирования

МТС: COM +

WAS: EJB

JBoss: EJB

Сервер приложений WebLogic: EJB

Важнейшим отличием является то, что серверы приложений поддерживают технологию распределенного компонента, предоставляя такие функции, как удаленный вызов и распределенные транзакции, такие как EJB в мире Java или COM +/strong > на платформе Microsoft. Http-сервер часто поддерживает некоторые более простые среды программирования, часто скрипты, такие как ASP (.NET) в случае Microsoft или Servlet, включая JSP и многие другие в случае Java или PHP и CGI в случае Apache.

Другие возможности, такие как балансировка нагрузки, кластеризация, сеансовый переход, объединение пулов и т.д., которые раньше были в области серверов приложений, становятся доступными на веб-серверах, а также напрямую или через некоторые сторонние продукты.

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

Ответ 7

Веб-сервер исключительно обрабатывает запросы HTTP/HTTPS. Он служит для содержания в Интернете с использованием протокола HTTP/HTTPS.

Сервер приложений обслуживает бизнес-логику для прикладных программ через любое количество протоколов, возможно, включая HTTP. Прикладная программа может использовать эту логику так же, как вызовет метод для объекта. В большинстве случаев сервер предоставляет эту бизнес-логику через компонентный API, такой как компонентная модель EJB (Enterprise JavaBean), найденная на серверах приложений Java EE (Java Platform, Enterprise Edition). Главное, что веб-сервер предоставляет все через HTTP-протокол, в то время как сервер приложений не ограничен этим. Таким образом, сервер приложений предлагает гораздо больше услуг, чем веб-сервер, который обычно включает в себя:

API (собственный или нет) API
Балансировка нагрузки, сбой...
Управление жизненным циклом объекта
Управление состоянием (сеанс)
Управление ресурсами (например, пулы подключений к базе данных)

На большинстве серверов приложений Web-сервер является их неотъемлемой частью, что означает, что сервер приложений может делать все, на что способен веб-сервер. Кроме того, сервер приложений имеет компоненты и функции для поддержки сервисов уровня приложения, таких как объединение пулов, объединение объектов, поддержка транзакций, службы обмена сообщениями и т.д.

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

Поскольку веб-серверы хорошо подходят для статического контента и серверов приложений для динамического контента, большинство производственных сред имеют веб-сервер, выступающий в качестве обратного прокси-сервера для сервера приложений. Это означает, что при обслуживании запроса страницы статическое содержимое, такое как images/Static html, обслуживается веб-сервером, который интерпретирует запрос. Используя какой-то метод фильтрации (в основном расширение запрашиваемого ресурса), веб-сервер идентифицирует запрос динамического содержимого и прозрачно пересылает сервер приложений.

Пример такой конфигурации - Apache HTTP Server и BEA WebLogic Server. HTTP-сервер Apache - это веб-сервер, а 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 WebSphere Application Server) EJB
WebLogic Application Server (Oracle's)   EJB
JBoss AS                                 EJB
MTS                                      COM+

Ответ 8

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

Ответ 9

Основное различие между веб-сервером и сервером приложений заключается в том, что веб-сервер предназначен для обслуживания статических страниц, например HTML и CSS, тогда как сервер приложений отвечает за генерацию динамического содержимого путем выполнения кода на стороне сервера, например, JSP, сервлета или EJB.

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

Веб-контейнер является частью веб-сервера, а веб-сервер является частью сервера приложений.

Веб-сервер состоит из веб-контейнера, в то время как сервер приложений состоит из веб-контейнера и EJB-контейнера.

Ответ 10

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

Веб-сервер используется для коротких всплесков, которые обычно не являются ресурсоемкими. Это в основном облегчает обслуживание веб-трафика.

Ответ 11

Веб-сервер выполняет HTTP-протокол для обслуживания веб-страниц. Сервер приложений может (но не всегда) запускаться на веб-сервере для выполнения программной логики, результаты которой затем могут быть доставлены веб-сервером. Этот пример сценария сервера веб-сервера/сервера приложений.

Хорошим примером в мире Microsoft является отношение Internet Information Server/SharePoint Server. IIS - это веб-сервер; SharePoint - это сервер приложений. SharePoint сидит "сверху" IIS, выполняет определенную логику и выполняет результаты через IIS.

В мире Java существует, например, аналогичный сценарий с Apache и Tomcat.

Ответ 12

В терминах Java есть еще один: веб-контейнер (или, точнее, контейнер сервлетов). Это, скажем, между веб-сервером и сервером приложений. Веб-контейнер в терминах Java - это сервер приложений, который в основном реализует только часть JSP/Servlet Java EE и не имеет нескольких основных частей Java EE, таких как поддержка EJB. Примером является Apache Tomcat.

Ответ 13

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

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

API (собственный или нет) API
Управление жизненным циклом объекта,
Управление состоянием (сеанс),
Управление ресурсами (например, пулы подключений к базе данных),
Балансировка нагрузки, сбой...

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

Ответ 14

Граница между этими двумя становится все более тонкой.

Серверы приложений предоставляют бизнес-логику клиенту. Таким образом, подобный сервер приложений включает в себя набор методов (не обязательно, хотя и может быть сетевым компьютером, позволяющим многим запускать на нем программное обеспечение) для выполнения бизнес-логики. Таким образом, он просто выводит желаемые результаты, а не HTML-контент. (аналогично вызову метода). Так что это не строго HTTP-протокол.

Но веб-серверы передают HTML-контент в веб-браузеры (строго на основе HTTP). Веб-серверы могли обрабатывать только статические веб-ресурсы, но появление сценариев на стороне сервера помогло веб-серверам также обрабатывать динамическое содержимое. Где веб-сервер принимает запрос и направляет его на script (PHP, JSP, CGI-скрипты и т.д.), Чтобы СОЗДАТЬ HTML-контент, который будет отправлен клиенту. Затем веб-сервер знает, как отправить их обратно клиенту. ПОТОМУ ЧТО, что действительно знает веб-сервер.

Сказав это, в наши дни разработчики используют оба эти метода вместе. Если веб-сервер принимает запрос и затем вызывает script для создания HTML, НО script снова вызовет ЛОГИКУ сервера приложений (например, Получить данные транзакции), чтобы заполнить содержимое HTML.

Таким образом, в этом случае оба сервера были эффективно использованы.

Поэтому.... Мы можем с уверенностью сказать, что в настоящее время в большинстве случаев веб-серверы используются в качестве подмножества серверов приложений. НО это не так.

Я прочитал много статей по этой теме и нашел эту статью довольно удобной.

Ответ 15

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

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

Ответ 16

Большая разница в том, что веб-сервер обрабатывает HTTP-запросы, а сервер приложений выполняет бизнес-логику на любом количестве протоколов.

Ответ 17

Все вышеперечисленное просто слишком усложняет что-то очень простое. Сервер приложений содержит веб-сервер, на сервере приложений есть еще несколько дополнений/расширений к нему, чем стандартные веб-серверы. Если вы посмотрите на 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 и другую технику на веб-сервере, если хотите, но серверы приложений просто упакуют все эти вещи для вашего удобства. Чтобы быть полностью классифицированным как сервер приложений, вам, по существу, необходимо выполнить список инструментов, определенных некоторым стандартом.

Ответ 18

Фактически Apache - это веб-сервер, а Tomcat - сервер приложений. Когда HTTP-запрос поступает на веб-сервер. Затем статическое содержимое отправляется обратно в браузер через веб-сервер. Есть ли логика и сделать это, а затем этот запрос отправляется на сервер приложений. после обработки логики, тогда ответ отправляется на веб-сервер и отправляется клиенту.

Ответ 19

Не обязательно четкая разделительная линия. В настоящее время многие программы объединяют элементы обслуживания HTTP-запросов (веб-сервера) и обработки бизнес-логики (сервера приложений)

Ответ 20

A Веб-сервер может быть либо компьютерной программой, либо компьютером, на котором запущена программа, которая отвечает за прием HTTP-запросов от клиентов, отсылает ответы HTTP вместе с дополнительным содержимым данных, которые обычно являются веб-страницами таких как документы HTML и связанные объекты на нем.

Сервер приложений - это вид программного обеспечения, который будет поставлять различные приложения на другое устройство. Это компьютер, найденный в офисной или университетской сети, который позволяет всем в сети запускать программное обеспечение с одной и той же машины.

Ответ 21

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

Веб-сервер - это компьютерная система, которая обрабатывает запросы через HTTP, основной сетевой протокол, используемый для распространения информации во всемирной паутине. Термин может относиться ко всей системе или конкретно к программному обеспечению, которое принимает и контролирует запросы HTTP.

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

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

Веб-приложения - это компьютерный код, который выполняется на серверах приложений и написан на языке (ах), который поддерживает сервер приложений, и вызывает библиотеки времени выполнения и компоненты, которые предлагает сервер приложений.

Ответ 22

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

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

Среда программирования веб-сервера:

IIS: ASP (.NET)

Apache Tomcat: сервлет

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

Apache: Php, CGI

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

Среда программирования сервера приложений:

МТС: COM+

БЫЛО: EJB

JBoss: EJB

Сервер приложений WebLogic: EJB

Ответ 23

Основное понимание:

В архитектуре клиент-сервер

Сервер:> который обслуживает запросы.

Client :> Which consumes service.

Веб-сервер & Оба сервера приложений - это программные приложения, которые действуют как серверы для своих клиентов.

Они получили свои имена в зависимости от места их использования.

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.

Usage --
      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.

Usage --
      we require multi point processing,

      specialized processing techniques involves like for AI.
Например: серверы карт Google, серверы поиска Google, серверы Google документов, Microsoft 365 серверы, серверы компьютерного зрения Microsoft для ИИ.

Мы можем принять их как уровни/иерархии в 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-n-p/ee658120(v%3dpandp.10)

Ответ 24

В то время как между ними могут быть перекрытия (некоторые веб-серверы могут даже использоваться как серверы приложений), наибольшая разница IMHO находится в модели обработки и управлении сеансом:

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

В сервере приложений сеанс обычно более явный и часто принимает форму объекта, живущего в памяти сервера приложений на протяжении всего сеанса.

Ответ 25

Это зависит от конкретной архитектуры. Некоторые серверы приложений могут использовать веб-протоколы изначально (XML/RPC/SOAP через HTTP), поэтому мало технических различий. Как правило, веб-сервер обращен к пользователю, обслуживая множество контента по протоколу HTTP/HTTPS, в то время как сервер приложений не обращен к пользователю и может использовать нестандартные или немаршрутизируемые протоколы. Разумеется, с RIA/AJAX разница может быть дополнительно омрачена, предоставляя клиентам только не HTML-контент (JSON/XML) клиентам, накачивающим определенные службы удаленного доступа.

Ответ 26

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

API (собственный или нет) API
Управление жизненным циклом объекта,
Управление состоянием (сеанс),
Управление ресурсами (например, пулы подключений к базе данных),
Балансировка нагрузки, сбой

Ответ 27

Сервер приложений и веб-сервер в Java используются для размещения веб-приложения Java. В Java J2EE перспектива основной разницы между веб-сервером и сервером приложений - поддержка EJB. Чтобы запустить файл приложения EJB или хост-приложения Java (.ear), вам нужен сервер приложений, такой как JBoss, WebLogic, WebSphere или Glassfish, в то время как вы все еще можете запускать свой файл сервлета и JSP или Java-приложения (.war) внутри любой сети как Tomcat или Jetty. Сервер приложений поддерживает распределенные транзакции и EJB. Хотя веб-сервер поддерживает только сервлеты и JSP. С точки зрения логической разницы между веб-сервером и сервером приложений. веб-сервер должен предоставлять услугу уровня протокола HTTP, в то время как сервер приложений обеспечивает поддержку веб-сервиса и выставляет сервис бизнес-уровня, например. EJB.

Сервер приложений более тяжелый, чем веб-сервер с точки зрения использования ресурсов.

Ответ 28

ИМО, это в основном о разделении проблем.

С чисто технической точки зрения вы можете делать все (веб-контент + бизнес-логика) на одном веб-сервере. Если вы сделаете это, то информация будет встроена в запрашиваемый контент HTML. Какое будет влияние?

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