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

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

Answer 3

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

• Веб-сервер : подача контента в Интернет по протоколу http.

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

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

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

Answer 4

Как указали Рутеш и Дж.М.Сервера, различие нечеткое. Исторически они были разными, но на протяжении 90-х годов эти две ранее разные категории смешивали и эффективно объединяли. На данный момент, вероятно, лучше представить, что категория продукта «Сервер приложений» является строгим расширенным набором категории «веб-сервер».

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

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

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

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

• WebSphere, «сервер приложений» IBM имеет собственный встроенный веб-сервер.
• WebLogic, другой традиционный сервер приложений, аналогично.
• Windows, которая является сервером приложений Microsoft (помимо сервера файлов и печати, сервера мультимедиа и т. Д.), Включает в себя IIS.

Answer 5

Веб-сервер

Запустите 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 или даже SimpleHTTPServer Python.

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

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

Answer 6

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

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

IIS: ASP (.NET)

Tomcat: сервлет

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

Apache: Php, CGI

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

МТС: COM +

БЫЛ: EJB

JBoss: EJB

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

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

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

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

Answer 7

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

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

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

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

Сервер приложений может (но не всегда) работать на веб-сервере для выполнения логики программы, результаты которой затем могут быть переданы веб-сервером. Это один пример сценария веб-сервера / сервера приложений. Хорошим примером в мире 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's WebSphere Application Server) EJB
WebLogic Application Server (Oracle's)   EJB
JBoss AS                                 EJB
MTS                                      COM+

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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

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

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