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

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

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

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

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

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

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

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

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

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

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

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

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

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

As Rutesh and jmservera pointed out, the distinction is a fuzzy one. Historically, they were different, but through the 90's these two previously distinct categories blended features and effectively merged. At this point is is probably best to imagine that the "App Server" product category is a strict superset of the "web server" category.

Some history. In early days of the Mosaic browser and hyperlinked content, there evolved this thing called a "web server" that served web page content and images over HTTP. Most of the content was static, and the HTTP 1.0 protocol was just a way to ship files around. Quickly the "web server" category evolved to include CGI capability - effectively launching a process on each web request to generate dynamic content. HTTP also matured and the products became more sophisticated, with caching, security, and management features. As the technology matured, we got company-specific Java-based server-side technology from Kiva and NetDynamics, which eventually all merged into JSP. Microsoft added ASP, I think in 1996, to Windows NT 4.0. The static web server had learned some new tricks, so that it was an effective "app server" for many scenarios.

In a parallel category, the app server had evolved and existed for a long time. companies delivered products for Unix like Tuxedo, TopEnd, Encina that were philosophically derived from Mainframe application management and monitoring environments like IMS and CICS. Microsoft's offering was Microsoft Transaction Server (MTS), which later evolved into COM+. Most of these products specified "closed" product-specific communications protocols to interconnect "fat" clients to servers. (For Encina, the comms protocol was DCE RPC; for MTS it was DCOM; etc.) In 1995/96, these traditional app server products began to embed basic HTTP communication capability, at first via gateways. And the lines began to blur.

Web servers got more and more mature with respect to handling higher loads, more concurrency, and better features. App servers delivered more and more HTTP-based communication capability.

At this point the line between "app server" and "web server" is a fuzzy one. But people continue to use the terms differently, as a matter of emphasis. When someone says "web server" you often think HTTP-centric, web UI, oriented apps. When someone says "App server" you may think "heavier loads, enterprise features, transactions and queuing, multi-channel communication (HTTP + more). But often it is the same product that serves both sets of workload requirements.

• WebSphere, IBM's "app server" has its own bundled web server.
• WebLogic, another traditional app server, likewise.
• Windows, which is Microsoft's App Server (in addition to being its File&Print Server, Media Server, etc.), bundles IIS.

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

• Веб-сервер : предоставляет контент в Интернет с использованием протокола http.

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

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

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

While there may be overlaps between the two (some web servers may even be used as application servers) the biggest difference IMHO is in the processing model and the session management:

In Web server processing model, the focus is on handling requests; the notion of "session" is pretty much virtual. That is to say that "session" is simulated by transferring the representation of state between client and server (hence REST) and/or serializing it to an external persistent storage (SQL Server, Memcached etc).

In Application server the session is usually more explicit and often takes form of an object living in memory of the application server for the entire duration of the "session".

There is not necessarily a clear dividing line. Nowadays, many programs combine elements of both - serving http requests (web server) and handling business logic (app server)

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

Biggest difference is a Web Server handles HTTP requests, while an Application server will execute business logic on any number of protocols.

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

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

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

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

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

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

IIS: ASP (.NET)

Tomcat: Сервлет

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

Apache: Php, CGI

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

MTS: COM +

WAS: EJB

JBoss: EJB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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