В чем разница между сервером приложений и веб-сервером?
Ответы:
В большинстве случаев эти термины веб-сервер и сервер приложений используются взаимозаменяемо.
Ниже приведены некоторые ключевые различия в возможностях веб-сервера и сервера приложений:
Примером такой конфигурации являются Apache Tomcat HTTP Server и Oracle (ранее BEA) WebLogic Server. HTTP-сервер Apache Tomcat - это веб-сервер, а Oracle WebLogic - это сервер приложений.
В некоторых случаях серверы тесно интегрированы, такие как IIS и .NET Runtime. IIS - это веб-сервер. При наличии среды выполнения .NET IIS может предоставлять сервисы приложений.
Это подробный ответ с некоторыми сценариями, чтобы четко понять разницу, сходство и то, как оба могут работать вместе и все
Сервер приложений - это термин, который иногда смешивается с веб-сервером . Хотя веб-сервер обрабатывает в основном протоколы HTTP , сервер приложений работает с несколькими различными протоколами, включая, но не ограничиваясь, HTTP .
Основная задача веб-сервера заключается в отображении контента сайта, а сервер приложений отвечает за логику , взаимодействие между пользователем и отображаемым контентом. Сервер приложений работает совместно с веб-сервером, где один отображает, а другой взаимодействует.
Информация, передаваемая назад и вперед между сервером и его клиентом, не ограничивается простой разметкой дисплея, а взаимодействует между ними.
В большинстве случаев сервер создает это взаимодействие через компонентный API , такой как J2EE (платформа Java 2) , EJB (Enterprise JavaBean) и другие различные модели прикладного программного обеспечения.
Пример:
Лучший способ понять разницу между сценариями, в которых сервер приложений работает с веб-сервером, и сценарием, в котором нет сервера приложений, - через онлайн-магазин.
Сценарий 1. Веб-сервер без сервера приложений.
у вас есть интернет-магазин только с веб-сервером и без сервера приложений. На сайте будет отображаться, где вы можете выбрать продукт. Когда вы отправляете запрос, сайт выполняет поиск и возвращает результат HTML своему клиенту. Веб-сервер отправляет ваш запрос непосредственно на сервер базы данных (наберитесь терпения, я объясню этот в нашем следующем слепке) и ждем ответа. После получения веб-сервер формулирует ответ в HTML-файл и отправляет его в веб-браузер. Эта двусторонняя связь между сервером и сервером базы данных происходит каждый раз, когда выполняется запрос.
Сценарий 2: веб-сервер с сервером приложений
если запрос, который вы хотите выполнить, уже был выполнен ранее, и с тех пор данные не изменились, сервер сгенерирует результаты, не отправляя запрос на сервер базы данных. Это позволяет выполнять запрос в режиме реального времени, когда второй клиент может получить доступ к той же информации и получать надежную информацию в режиме реального времени, не отправляя еще один повторяющийся запрос на сервер базы данных. Сервер в основном действует как промежуточное звено между сервером базы данных и веб-сервером. Это позволяет извлекать информацию для повторного использования в первом сценарии, поскольку эта информация встроена в определенную и «настроенную» HTML-страницу, это не процесс повторного использования. Второй клиент должен будет снова запросить информацию и получить другую HTML-страницу с запрошенной информацией, что крайне неэффективно.
Для поддержки такого множества сложных задач этот сервер должен иметь встроенную избыточность, большую вычислительную мощность и большой объем оперативной памяти для обработки всех данных, которые он извлекает в режиме реального времени.
Надеюсь это поможет.
the application server deals with several different protocols, including, but not limited, to HTTP<- это говорит о том, что он определенно обрабатывает http-запросы - это не точно.
Оба термина очень общие, один содержит другой, и в некоторых случаях наоборот.
Веб-сервер : передает контент в Интернет по протоколу http.
Сервер приложений : размещает и предоставляет бизнес-логику и процессы.
Я думаю, что главное в том, что веб-сервер предоставляет все через протокол http, в то время как сервер приложений не ограничен этим.
Тем не менее, во многих сценариях вы обнаружите, что веб-сервер используется для создания внешнего интерфейса сервера приложений, то есть он предоставляет набор веб-страниц, которые позволяют пользователю взаимодействовать с бизнес-правилами, найденными в сервер приложений.
веб сервер
Запустите 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 или даже SimpleHTTPServer Python.
Сервер приложений - обслуживает файлы, созданные на лету. По сути, большинство веб-серверов имеют какие-то плагины или даже поставляются со встроенными функциями для этого. Существуют также строгие серверы приложений, такие как Gunicorn (Python), Unicorn (Ruby), uWSGI (Python) и т. Д.
Обратите внимание, что вы можете создать веб-сервер с кодом сервера приложений. Это делается в некоторых случаях во время разработки, когда вы не хотите, чтобы на вашем компьютере работало несколько миллиардов различных серверов.
Как указали Рутеш и Дж.М.Сервера, различие нечеткое. Исторически они были разными, но на протяжении 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 + больше)». Но зачастую это один и тот же продукт, который удовлетворяет обоим наборам требований к рабочей нагрузке.
Как уже говорили многие, веб-серверы обрабатывают петиции 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, для традиционных серверов приложений остается все меньше и меньше места.
Основное различие между веб-сервером и сервером приложений заключается в том, что веб-сервер предназначен для обслуживания статических страниц, например HTML и CSS, тогда как сервер приложений отвечает за генерацию динамического содержимого путем выполнения кода на стороне сервера, например, JSP, сервлета или EJB.
Какой из них я должен использовать?
Как только вы узнаете разницу между веб-сервером и сервером приложений и веб-контейнерами, легко определить, когда их использовать. Вам нужен web serverподобный Apache HTTPD, если вы обслуживаете статические веб-страницы. Если у вас есть Java-приложение с JSP и сервлетом для генерации динамического контента, вам понадобится web containersTomcat или Jetty. Хотя, если у вас есть приложение Java EE, использующее EJB, распределенные транзакции, обмен сообщениями и другие интересные функции, вам не нужно полноценное приложение, application serverтакое как JBoss, WebSphere или Oracle WebLogic.
Веб-контейнер является частью веб-сервера, а веб-сервер является частью сервера приложений.
Веб-сервер состоит из веб-контейнера, в то время как сервер приложений состоит из веб-контейнера и EJB-контейнера.
Короче говоря, веб-сервер - это сервер, который предоставляет веб-страницы пользователям через http. Сервер приложений - это сервер, на котором размещена бизнес-логика системы. Он часто содержит как долго выполняющиеся / пакетные процессы, так и / или сервисы взаимодействия, не предназначенные для потребления человеком (сервисы REST / JSON, SOAP, RPC и т. Д.).
Веб-сервер обрабатывает исключительно HTTP / HTTPS-запросы. Он передает контент в Интернет по протоколу HTTP / HTTPS.
Сервер приложений передает бизнес-логику прикладным программам через любое количество протоколов, включая HTTP. Прикладная программа может использовать эту логику так же, как при вызове метода для объекта. В большинстве случаев сервер предоставляет эту бизнес-логику через API-компонент, такой как компонентная модель EJB (Enterprise JavaBean), обнаруженная на серверах приложений Java EE (Java Platform, Enterprise Edition). Суть в том, что веб-сервер предоставляет доступ ко всему через протокол http, а сервер приложений не ограничен этим. Таким образом, сервер приложений предлагает гораздо больше услуг, чем веб-сервер, который обычно включает в себя:
Большинство серверов приложений имеют веб-сервер как неотъемлемую часть, это означает, что сервер приложений может делать все, на что способен веб-сервер. Кроме того, в 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+
Граница между этими двумя становится все более тонкой.
Серверы приложений предоставляют бизнес-логику клиентам. Это означает, что серверы приложений состоят из набора методов (хотя не только, они могут быть даже сетевым компьютером, позволяющим многим запускать на нем программное обеспечение) для выполнения бизнес-логики. Таким образом, он будет просто выводить желаемые результаты, а не содержимое HTML. (похоже на вызов метода). Так что это не строго HTTP.
Но веб-серверы передают контент HTML в веб-браузеры (строго на основе HTTP). Веб-серверы были способны обрабатывать только статические веб-ресурсы, но появление серверных сценариев позволило веб-серверам обрабатывать и динамическое содержимое. Когда веб-сервер принимает запрос и направляет его в соответствующие сценарии (PHP, JSP, CGI-сценарии и т. Д.), Чтобы СОЗДАТЬ HTML-контент для отправки клиенту. После получения контента веб-сервер отправит HTML-страницу клиенту.
Однако в настоящее время оба эти сервера используются вместе. Где веб-сервер принимает запрос, а затем вызывает скрипт для создания содержимого HTML. Затем скрипт снова вызовет ЛОГИКУ сервера приложений (например, «Извлечь детали транзакции»), чтобы заполнить содержимое HTML.
Таким образом, оба сервера используются эффективно.
Поэтому .... Мы можем с уверенностью сказать, что в настоящее время в большинстве случаев веб-серверы используются в качестве подмножества серверов приложений. НО театрально это НЕ тот случай.
Я прочитал много статей на эту тему и нашел эту статью довольно удобной.
В терминах Java есть еще один: веб-контейнер (или, точнее, контейнер сервлетов). Это, скажем, между веб-сервером и сервером приложений.
Веб-контейнер в терминах Java - это сервер приложений, который в основном реализует только часть JSP / Servlet Java EE и не имеет нескольких основных частей Java EE, таких как поддержка EJB. Примером является Apache Tomcat.
Сервер приложений - это машина (фактически исполняемый процесс, запущенный на некоторой машине), который «слушает» (на любом канале, используя любой протокол) запросы клиентов на любую предоставляемую им услугу, а затем что-то делает на основе этих запросов. (может включать или не включать переуступку клиенту)
Веб-сервер - это процесс, работающий на машине, которая «слушает» конкретно по каналу TCP / IP, используя один из «интернет» протоколов (http, https, ftp и т. Д.), И делает все, что делает на основе этих входящих запросов. .. Как правило, (как определено первоначально), он извлекал / генерировал и возвращал веб-страницу html клиенту, либо извлекал из статического html-файла на сервере, либо создавал динамически на основе параметров во входящем клиентском запросе.
Веб-сервер запускает протокол HTTP для обслуживания веб-страниц. Сервер приложений может (но не всегда) работать на веб-сервере для выполнения программной логики, результаты которой затем могут быть переданы веб-сервером. Это один пример сценария веб-сервера / сервера приложений.
Хорошим примером в мире Microsoft являются отношения Internet Information Server / SharePoint Server. IIS - это веб-сервер; SharePoint является сервером приложений. SharePoint находится «на вершине» IIS, выполняет определенную логику и предоставляет результаты через IIS.
В мире Java есть похожий сценарий, например, с Apache и Tomcat.
С одной стороны, веб-сервер обслуживает веб-контент (HTML и статический контент) по протоколу HTTP. С другой стороны, сервер приложений - это контейнер, на котором вы можете создавать и предоставлять бизнес-логику и процессы клиентским приложениям через различные протоколы, включая HTTP, в многоуровневой архитектуре.
Таким образом, сервер приложений предлагает гораздо больше услуг, чем веб-сервер, который обычно включает в себя:
AFAIK, ATG Dynamo был одним из самых первых серверов приложений в конце 90-х (согласно определению выше). В начале 2000 года это было правление некоторых проприетарных серверов приложений, таких как ColdFusion (CFML AS), BroadVision (серверная JavaScript AS) и т. Д. Но ни один из них не пережил эпоху серверов приложений Java.
Основное понимание:
В архитектуре клиент-сервер
Сервер:> который обслуживает запросы.
Клиент:> который потребляет услугу.
Веб-сервер и сервер приложений являются программными приложениями, которые выполняют роль серверов для своих клиентов.
Они получили свои имена в зависимости от места их использования.
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-np/ee658120(v%3dpandp.10)
Самым большим отличием является то, что веб-сервер обрабатывает HTTP-запросы, а сервер приложений будет выполнять бизнес-логику на любом количестве протоколов.
На самом деле Apache - это веб-сервер, а Tomcat - сервер приложений. Когда в качестве HTTP-запроса приходит на веб-сервер. Затем статическое содержимое отправляется обратно в браузер через веб-сервер. Есть ли и логика, чтобы сделать, то этот запрос отправить на сервер приложений. после обработки логики ответ отправляется на веб-сервер и отправляется клиенту.
Все вышеперечисленное просто усложняет что-то очень простое. Сервер приложений содержит веб-сервер, сервер приложений просто имеет на пару больше дополнений / расширений, чем стандартные веб-серверы. Если вы посмотрите на TomEE в качестве примера:
CDI - Apache OpenWebBeans
EJB - Apache OpenEJB
JPA - Apache OpenJPA
JSF - Apache MyFaces
JSP - Apache Tomcat
JSTL - Apache Tomcat
JTA - Apache Geronimo Transaction
Servlet - Apache Tomcat
Javamail - Apache Geronimo JavaMail
Bean Validation - Apache BVal
Вы увидите, что Tomcat (веб-контейнер / сервер) - это просто еще один инструмент в арсенале серверов приложений. Вы также можете получить JPA и другие технологии на веб-сервере, если хотите, но серверы приложений просто упаковывают все эти вещи для вашего удобства. Чтобы быть полностью классифицированным как сервер приложений, вам необходимо соблюдать список инструментов, установленных каким-либо стандартом.
Там не обязательно четкая разделительная линия. В настоящее время многие программы сочетают в себе элементы как обслуживания http-запросов (веб-сервер), так и обработки бизнес-логики (сервер приложений).
От https://en.wikipedia.org/wiki/Web_server
Веб - сервер представляет собой компьютерную систему , которая обрабатывает запросы через HTTP, основной сетевой протокол используется для распространения информации о World Wide Web. Этот термин может относиться ко всей системе или конкретно к программному обеспечению, которое принимает и контролирует запросы HTTP .
С https://en.wikipedia.org/wiki/Application_server#Application_Server_definition
Сервер приложений работает за веб-сервером (например, Apache или Microsoft Internet Information Services (IIS)) и (почти всегда) перед базой данных SQL (например, PostgreSQL, MySQL или Oracle).
Веб-приложения - это компьютерный код, который выполняется на серверах приложений и написан на языке (ах), который поддерживает сервер приложений, и вызывает библиотеки времени выполнения и компоненты, которые предлагает сервер приложений .
Сервер приложений и веб-сервер используются для размещения веб-приложений. Веб-сервер - это веб-контейнер, с другой стороны, Сервер приложений - это веб-контейнер, а также контейнер EJB (Enterprise JavaBean) или контейнер COM + для Microsoft dot Net.
Веб-сервер предназначен для обслуживания статического HTTP-контента, такого как HTML, изображения и т. Д., А для динамического контента есть плагины для поддержки языков сценариев, таких как Perl, PHP, ASP, JSP и т. Д., И он ограничен протоколом HTTP. Ниже серверы могут генерировать динамический HTTP-контент.
Среда программирования веб-сервера:
IIS: ASP (.NET)
Apache Tomcat: сервлет
Причал: Сервлет
Apache: Php, CGI
Сервер приложений может делать все, что способен веб-сервер, и прослушивает с использованием любого протокола, а также у сервера приложений есть компоненты и функции для поддержки служб уровня приложений, таких как пул соединений, пул объектов, поддержка транзакций, службы обмена сообщениями и т. Д.
Среда программирования сервера приложений:
МТС: COM +
БЫЛО: EJB
JBoss: EJB
Сервер приложений WebLogic: EJB
Несмотря на то, что между ними могут быть совпадения (некоторые веб-серверы могут даже использоваться в качестве серверов приложений), самое большое отличие IMHO заключается в модели обработки и управлении сеансами:
В модели обработки веб-сервера основное внимание уделяется обработке запросов; понятие "сессия" в значительной степени виртуально. То есть, что «сессия» моделируется путем передачи представления состояния между клиентом и сервером (следовательно, REST) и / или сериализации его во внешнее постоянное хранилище (SQL Server, Memcached и т. Д.).
На сервере приложений сеанс обычно является более явным и часто принимает форму объекта, живущего в памяти сервера приложений на протяжении всей «сессии».
Это зависит от конкретной архитектуры. Некоторые серверы приложений могут использовать веб-протоколы изначально (XML / RPC / SOAP через HTTP), поэтому технических различий мало. Обычно веб-сервер ориентирован на пользователя и обслуживает разнообразный контент по HTTP / HTTPS, тогда как сервер приложений не ориентирован на пользователя и может использовать нестандартные или не маршрутизируемые протоколы. Разумеется, в случае RIA / AJAX это различие может быть еще более затуманено, поскольку клиентам, использующим определенные службы удаленного доступа, предоставляется только контент, отличный от HTML (JSON / XML).
ИМО, в основном это разделение проблем.
С чисто технической точки зрения вы можете делать все (веб-контент + бизнес-логика) на одном веб-сервере. Если вы сделаете это, то информация будет встроена в запрашиваемый контент HTML. Какое будет влияние?
Например, представьте, что у вас есть 2 разных приложения, которые отображают совершенно другой HTML-контент в браузере. Если бы вы разделили бизнес-логику на сервер приложений, вы могли бы предоставить другим веб-серверам поиск одинаковых данных на сервере приложений с помощью сценариев. Однако, если вы не отделите логику и не сохраните ее на веб-сервере, всякий раз, когда вы меняете свою бизнес-модель, вы в конечном итоге меняете ее на каждом имеющемся у вас веб-сервере, что займет больше времени, будет менее надежным и подверженные ошибки.
Почти каждая страница, которую вы посещаете, использует оба. Статический контент (например, изображения, видео) обслуживается веб-сервером, а остальное (части, которые различаются между вами и другими пользователями), генерируется сервером приложений.