it-roy-ru.com

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

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

636
TwiggedToday

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

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

  • Веб-сервер предназначен для обслуживания содержимого 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 может предоставлять сервисы приложений.

544
Rutesh Makhijani

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

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

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

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

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

enter image description here

Пример:

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

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

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

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

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

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

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

129
Durai Amuthan.H

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

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

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

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

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

124
jmservera

Как указали Рутеш и Джмсервера, это различие нечеткое. Исторически они были разными, но на протяжении 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.
58
Cheeso

Веб-сервер

Запустите python -m 'SimpleHTTPServer' и перейдите на http: // localhost: 808 . То, что вы видите, это веб-сервер в его работе. Сервер просто обслуживает файлы по 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 или даже SimpleHTTPServer Python.

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

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

46
Pithikos

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

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

IIS: ASP (.NET)

Tomcat: сервлет

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

Apache: Php, CGI

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

МТС: COM +

БЫЛО: EJB

JBoss: EJB

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

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

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

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

36
Dan

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

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

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

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

Сервер приложений может (но не всегда) работать на веб-сервере для выполнения программной логики, результаты которой затем могут быть переданы веб-сервером. Это один пример сценария веб-сервера/сервера приложений. Хорошим примером в мире 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+
18
Parv

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

16
C. Ross

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

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

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

Application Server

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

16
Arun Raaj

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

8
BalusC

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

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

8
Joseph

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

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

В мире Java, например, есть похожие сценарии с Apache и Tomcat.

8
Robert S.

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

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

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

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

7
Pascal Thivent

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

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

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

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

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

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

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

7
Dilruk

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

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

5
Charles Bretana

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

4
Gerrit Brink

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

3
Amila

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

3
MarkPowell

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

2
Bablu Ahmed

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

2
Peter Recore

От 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).

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

2
Manohar Reddy Poreddy

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

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

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

1
zvolkov

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

0
Cade Roux

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

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

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

0
stdout

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

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

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

Клиент:> который потребляет услугу.

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

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

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 для искусственного интеллекта.

Мы можем принять их как уровни/иерархии в 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)

0
chandra rv