веб сервер и сервер приложений отличие
Разница между веб-сервером и сервером приложений
Сервер — это центральное хранилище, где информация и компьютерные программы хранятся и доступны программисту в сети. Веб-сервер и сервер приложений — это разновидности серверов, которые используются для доставки сайтов, и, следовательно, последний имеет дело с операциями приложений, выполняемыми между пользователями и внутренними бизнес-приложениями организации.
Веб-сервер: это компьютерная программа, которая принимает запрос данных и отправляет указанные документы. Веб-сервером может быть компьютер, на котором хранится онлайн-контент. По сути, для размещения сайтов используется интернет-сервер, однако существуют разные веб-серверы, такие как отдых, хранение, FTP, электронная почта и т.д.
Сервер приложений: он включает в себя веб-контейнер, а также контейнер EJB. Серверы приложений организуют среду выполнения корпоративных приложений. Сервер приложений может быть разумным сервером, который означает, как поставить операционную систему, разместить приложения и сервисы для пользователей, ИТ-сервисов и организаций. При этом используется пользовательский интерфейс, аналогичный протоколу и протоколам RPC / RMI.
Примеры сервера приложений:
Разница между веб-сервером и сервером приложений:
Разница между веб-сервером, сервером приложений и сервером баз данных
Я задал этот вопрос, потому что я помню, когда я вел сайт, все что у меня было https войдите в Панель управления веб-сайта, в которую я помещаю все свои файлы в htdocs папка. Не было трех отдельных вещей, таких как веб-сервер, сервер приложений и сервер баз данных.
3 ответов
сервер, на котором размещен ваш сайт. На этом сервере будут установлены веб-серверы, такие как IIS, apache и т. д.
сервер, на котором созданы приложения, использующие вашу базу данных, веб-службу и т. д. На этом сервере приложений будет размещен бизнес-уровень (обернутый веб-службами), запланированные задания, службы windows и т. д.
на сервере баз данных будет размещена одна или несколько баз данных, таких как Oracle, Sql Server, MySql и т. д.
Если вы имеете в виду htdocs тогда это веб-сервер. Базы данных, которую вы используете должна быть установлена на другом сервере, который является сервер базы данных. Сервер приложений также может быть установлен на том же компьютере веб-сервера.
Это часто сбивает с толку.
программное обеспечение Web, application и database server может работать на одном физическом сервере или распространяться на нескольких физических компьютерах. Большинство крупных веб-сайтов имеют несколько компьютеров; большинство» потребительских » хостинговых пакетов работают на одном ящике.
логическое разделение выглядит следующим образом.
в Веб-сервер обрабатывает запросы HTTP(S) и передает эти запросы «обработчикам». Они имеют встроенные обработчики для запросов файлов-HTML-страниц, изображений, CSS, JavaScript и т. д. Можно добавить дополнительные обработчики запросов, которыми они не могут управлять, например динамические страницы, доставляемые сервером приложений. Веб-серверы реализуют спецификацию HTTP и знают, как управлять заголовками запросов и ответов.
программное обеспечение сервера баз данных, где приложение хранит свою структурированную информацию. Как правило, это означает пользовательское программное обеспечение, которое позволяет сервер приложений, чтобы задать такие вопросы, как «сколько элементов пользователь x имеет в своей корзине?», используя язык программирования. Примерами являются MySQL, SQL Server, Oracle (все «реляционные базы данных») и MongoDB, Redis и CouchDB (решения»NoSQL»).
программное обеспечение базы данных может работать на той же физической машине, что и веб-сервер, но обычно это первое, что размещается на отдельном физическом оборудовании, когда сайт должен масштабироваться.
веб-сервер: сервер, на котором обрабатываются все ваши HTTP-запросы, известен как веб-сервер где как Сервер приложений: включая службы веб-сервера i.e отвечая на HTTP-запросы, он также отвечает на бизнес-логику, таким образом, не ограничиваясь протоколом HTTP Например. игровые сервера, чаты и т. д.
В чем разница между сервером приложений и веб-сервером?
Я хотел бы предложить, чтобы было три дисциплинированных использования макросов:
Насколько я понимаю, Lispers использует макросы по другим причинам. «семантические» нерегулярности на целевом языке.
Я призываю людей решить все три вопроса, когда говорят, что язык X может делать то, что могут сделать макросы.
Felleisen является одним из mos т влиятельных макро исследователей в этой области. (Я не знаю, согласен ли он с этим сообщением.)
14 ответов
Веб-сервер запускает протокол HTTP для обслуживания веб-страниц. Сервер приложений может (но не всегда) запускаться на веб-сервере для выполнения логики программы, результаты которой затем могут быть доставлены веб-сервером. Это один из примеров сценария веб-сервер / сервер приложений.
В мире Java есть аналогичный сценарий, например, с Apache и Tomcat.
В большинстве случаев эти термины «веб-сервер» и «сервер приложений» используются как взаимозаменяемые.
Ниже приведены некоторые ключевые различия в функциях веб-сервера и сервера приложений:
Сервер приложений обычно проектируется и развертывается для облегчения более длительных процессов, которые также будут более ресурсоемкими.
Веб-сервер используется для коротких пакетов, которые, как правило, не потребляют много ресурсов. В основном это делается для облегчения обслуживания веб-трафика.
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.
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.
Оба термина являются очень общими, один содержит другой, и в некоторых случаях наоборот.
Веб-сервер : предоставляет контент в Интернет с использованием протокола 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».
Это зависит от конкретной архитектуры. Некоторые серверы приложений могут изначально использовать веб-протоколы (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.
Сервер приложений, таким образом, предлагает гораздо больше услуг, чем веб-сервер, которые обычно включают:
AFAIK, ATG Dynamo был одним из самых первых серверов приложений в конце 90-х (согласно определению выше). В начале 2000 года это были некоторые проприетарные серверы приложений, такие как ColdFusion (CFML AS), BroadVision (серверная JavaScript AS) и т. Д. Но ни один из них не выжил после Java-приложения. серверная эпоха.
Сервер приложений WebLogic: EJB
Другие возможности, такие как балансировка нагрузки, кластеризация, переключение сеансов при сбое, объединение соединений и т. д., которые раньше были в области серверов приложений, являются становятся доступными на веб-серверах напрямую или через некоторые сторонние продукты.
Наконец, стоит отметить, что картина еще больше искажается из-за «легких контейнеров», таких как Spring Framework, которые часто дополняют назначение серверов приложений более простыми способом и без инфраструктуры сервера приложений. А поскольку аспект распределения в приложениях переходит от распределенного компонента к парадигме обслуживания и архитектуре SOA, для традиционных серверов приложений остается все меньше и меньше места.
Другие возможности, такие как балансировка нагрузки, кластеризация, переключение сеансов при отказе, объединение пулов соединений и т. Д., Которые раньше были в сфере серверов приложений, становятся доступными на веб-серверах, а также напрямую или через некоторые сторонние продукты.
Наконец, стоит отметить, что картина еще больше искажается из-за «легких контейнеров», таких как Spring Framework, которые часто дополняют назначение серверов приложений более простым способом и без инфраструктуры сервера приложений. А поскольку аспект распределения в приложениях смещается от распределенного компонента к парадигме обслуживания и архитектуре SOA, для традиционных серверов приложений остается все меньше и меньше места.
Другие возможности, такие как балансировка нагрузки, кластеризация, переключение сеансов при отказе, объединение пулов соединений и т. Д., Которые раньше были в сфере серверов приложений, становятся доступными на веб-серверах, а также напрямую или через некоторые сторонние продукты.
Наконец, стоит отметить, что картина еще больше искажается из-за «легких контейнеров», таких как Spring Framework, которые часто дополняют назначение серверов приложений более простым способом и без инфраструктуры сервера приложений. А поскольку аспект распределения в приложениях переходит от распределенного компонента к парадигме обслуживания и архитектуре SOA, для традиционных серверов приложений остается все меньше и меньше места.
которые раньше находились в сфере серверов приложений, теперь становятся доступными на веб-серверах напрямую или через некоторые сторонние продукты.
которые раньше находились в сфере серверов приложений, теперь становятся доступными на веб-серверах напрямую или через некоторые сторонние продукты.
которые часто дополняют назначение серверов приложений более простым способом и без инфраструктуры сервера приложений. А поскольку аспект распределения в приложениях переходит от распределенного компонента к парадигме обслуживания и архитектуре SOA, для традиционных серверов приложений остается все меньше и меньше места.
которые часто дополняют назначение серверов приложений более простым способом и без инфраструктуры сервера приложений. А поскольку аспект распределения в приложениях смещается от распределенного компонента к парадигме обслуживания и архитектуре SOA, для традиционных серверов приложений остается все меньше и меньше места.
Сервер приложений и веб-сервер
Сервер приложений (Application Sever) – это сервер промежуточного программного обеспечения (ПО, middleware). Это системное ПО, которое располагается между операционной системой (ОС) с одной стороны, внешними ресурсами, например, системой управления базами данных СУБД (DBMS, Database Management System) или Интернет-сервисами, с другой стороны, и приложениями пользователя.
Сервер приложений действует как хост для бизнес-логики пользователя, он также обеспечивает доступ к бизнес-приложениям и задаёт их параметры для пользователя. Сервер приложений должен устойчиво работать независимо от изменений трафика клиентских запросов, отказов оборудования и ПО, распределённого характера масштабных приложений, а также возможной разнородности форматов данных и ресурсов их обработки.
Внешние ресурсы, например, СУБД и Интернет-сервисы, предоставляют веб-серверы (Web Server). Они отвечает на запросы пользователя по доставке контента.
Серверы приложений иногда путают с веб-серверами. У них есть общие функции, но есть и много различий. Понимание этих различий поможет правильно сконфигурировать программное обеспечение и инфраструктуру оборудования для нужд предприятия.
Различия между серверами приложений и веб-серверами
Параметр сравнения
Веб-сервер
Сервер приложений
Основная цель
Хостинг сайтов и ответы на простые веб-запросы
Хостинг приложений и обеспечение сложных взаимосвязей бизнес-логики
Тип контента
Доставка только статического контента HTML
Доставка как статического, так и динамического контента
Протоколы
HTTP/HTTPS и другие протоколы
Соединение с приложениями
Подключения к базами данных
К статическим базам данных
К базам данных приложений
Типичные клиенты
Веб- и мобильные приложения, а также веб-браузеры
Многопотоковая обработка
Поддерживается параллельная обработка многих запросов
Потребление ресурсов
Трафик не потребляет много ресурсов
Процессы с интенсивным потреблением ресурсов
Контейнеры
Веб-контейнеры (сервлеты, JSP, JSF, веб-сервисы), контейнеры клиентских приложений (DI, безопасность)
Ёмкость
Результат запроса
Гипертекстовый документ, отображающий информацию в браузере
Файлы, содержащие данные, по требованию клиента
Что такое веб-сервер?
Веб-сервер – это компьютерная система, которая хранит, обрабатывает и доставляет веб-страницы для клиента. Клиентом в этом случае является веб-браузер на компьютере пользователя или мобильное приложение на его смартфоне или планшете. В зависимости от настроек, веб-сервер может хранить один или множество веб-сайтов. Веб-серверы доставляют клиенту только статический HTML-контент, такой как документы, изображения, видео, шрифты и пр.
Обычно веб-серверы не обрабатывают динамический контент и не позволяют программировать свои программы. Веб-серверы работают по протоколу передачи гипертекста HTTP (Hypertext Transfer Protocol) или HTTPS (Hypertext Transfer Protocol Secure). Однако, опционально, некоторые веб-серверы позволяют добавлять компоненты, позволяющие работать с динамическим контентом.
Что такое сервер приложений?
Сервер приложений (Application Server, App-Server) – это программный комплекс, предназначенный для доставки контента и средств его представления для клиентских приложений. Клиентами могут быть веб-приложения, браузеры или мобильные приложения.
Серверы приложений предоставляют для клиентов бизнес-логику, то есть, преобразуют данные в динамический контент и обеспечивают функционал приложений. Примеры такого контента:
Сервер приложений – это связующее звено между клиентом и программным кодом физического сервера. Типичные задачи сервера приложений:
Серверы приложений также обрабатывают такие процессы, как кластеризация, исправление отказов и балансировка нагрузки.
Рис. 2. Сервер приложений.
Что общего у веб-сервера и сервера приложений
Если в качестве основного приложения клиента выступает веб-браузер, то различия между двумя типами серверов размываются. Большинство веб-серверов имеют плагины на основе скриптов (ASP, JSP, JSF, PHP, Perl, и пр.), которые позволяют генерировать динамический контент.
Поскольку в сценариях применения у веб-серверов и серверов приложений много общего, то наиболее популярные серверы являются гибридами этих двух типов. Гибридное решение, совмещающее свойства обеих серверов, обеспечивает максимальную скорость и функциональность системы.
Для хостинга веб-сайта со статическим контентом лучше всего подходят объектные СХД.
Наиболее популярные веб-серверы
Nginx – веб-сервер с открытым кодом, который может работать как обратный прокси-сервер (reverse proxy). Обратный прокси-сервер работает не в сторону клиента, фильтруя контент и обеспечивая безопасность, а в сторону веб-сервера. Nginx имеет архитектуру, управляемую событиями EDA (event-driven architecture), позволяющую создавать и определять события, реагировать на события, измерять потребление ресурсов реакции на событие. Кроме того, он может выполнять функции прокси-сервера электронной почты и балансировщика нагрузки и может выполнять одновременно множество запросов.
HTTP-сервер Apache – популярный веб-сервер на ОС Linux, который входит с стек LAMP (Linux, Apache, MySQL, PHP). На этом веб-сервере работает около 40% Интернет-сайтов. Apache имеет богатый выбор функций, включая htaccess, FTP, HTTP/2, ограничение полосы пропускания для определённых клиентов (throttling), балансировку нагрузки и пр.
Microsoft IIS (Internet Information Services) – свободно распространяемый пакет серверного ПО, представляющий собой проприетарный набор служб от компании Microsoft. IIS распространяется с пакетом Windows NT. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP.
Jetty – проект свободного ПО, который может обеспечивать функции НТТР-сервера, НТТР-клиента и контейнера javax.servlet. Хотя Jetty разрабатывался как веб-сервер, он также может служить платформой для межмашинных коммуникаций (М2М).
LiteSpeed имеет хорошую производительность и масштабируемость, широкий диапазон функций и простую в использовании консоль администратора. Это четвёртый по популярности веб-сервер, который, по состоянию на декабрь 2020 года, использовался для 8.1% веб-сайтов.
Наиболее популярные серверы приложений
Apache Tomcat – контейнер сервлетов с открытым исходным кодом на языке Java. Tomcat позволяет запускать веб-приложения и содержит ряд программ для автоматического конфигурирования и часто используется вместе с конфигурационным файлом Apache HTTPD (Apache Hypertext Transfer Protocol Server daemon). Tomcat может исполнять Java-сервлеты, доставлять клиентам страницы в кодах Java Server Page, и может обслуживать приложения Java EE (Java Enterprise Edition).
Сервер Oracle WebLogic – сервер для распределённых приложений с использованием стандартов Java EE. Он полностью интегрирован с продуктами и облачными сервисами Oracle.
Glassfish – сервер приложений с открытым кодом на Java EE, который поддерживает Java-сервлеты, а также спецификацию написания и поддержки серверных компонентов с бизнес-логикой EJB (Enterprise JavaBeans).
JBoss – сервер приложений с открытым кодом для создания, развёртывания и хостинга приложений на языке Java. JBoss может работать на разных платформах и в любой операционной системе с поддержкой Java.
Какой сервер приложений будет наиболее подходящим?
Знание различий между сервером приложений и веб-сервером помогает выбрать сервер для того или иного использования.
Другим подходом может быть добавление функционала в веб-сервер при помощи плагинов. В этом случает, веб-сервер может использовать технологию программирования на стороне сервера (server-side), такую как скрипты CGI, JSP, сервлеты, ASP (Active Server Pages) или JavaScript на стороне сервера.
Использование обоих типов сервера в одной системе
Часто и веб-сервер, и сервер приложений, развёртывают в одной системе. Это даёт возможность предоставлять клиентам как статический, так и динамический контент. В этом случае, веб-сервер становится подсистемой сервера приложений и все их сервисы работают на одной и той же программно-аппаратной платформе.
Преимуществом такого подхода является более высокая производительность системы. В каждом типе сервера максимально используются их преимущества. Простые веб-запросы будут сразу же обрабатываться веб-сервером и при этом не будет снижаться производительность сервера приложений.
Например, на сайте Интернет-магазина должна предоставляться информация о ценах в реальном времени. Обычно на сайте также есть форма для приобретения товара. Когда пользователь посылает запрос, веб-страница магазина ищет актуальную цену и выдаёт результат в виде HTML-страницы. Эту функциональность можно обеспечить как при помощи сервера приложений, так и при помощи веб-сервера с соответствующими плагинами. Возможно несколько сценариев.
Сценарий 1. Использование только веб-сервера с плагинами
Веб-сервер предоставляет функционал Интернет-магазина:
Сценарий 2. Использование как веб-сервера, так и сервера приложений
Сервер приложений хранит бизнес-логику для поиска цены. Веб-сервер делегирует ему генерацию ответа, скрипт вызывает сервис поиска в сервере приложений, и затем формулирует ответ HTML.
Размещение логики поиска цены в сервере приложений позволяет использовать её различными частями приложения. В первом сценарии сервис поиска цены не может повторно использоваться, поскольку данные встроены в HTML-страницу.
Рис. 3. Использование как веб-сервера, так и сервера приложений.
Заключение
Пересечение функций веб-сервера и сервера приложений означает, что каждый сценарий применения может иметь несколько решений. Можно применять веб-серверы и серверы приложений отдельно, а можно использовать их комбинацию.
Однако, не каждая конфигурация будет равноценной по параметрам работы и потреблению ресурсов, хотя и будет выполнять возложенные на неё функции. Знание различий между двумя типами серверов поможет сэкономить средства, облегчить масштабирование системы и повысить производительность.
В чем разница между сервером приложений и веб-сервером?
В чем разница между сервером приложений и веб-сервером?
В большинстве случаев эти термины веб-сервер и сервер приложений используются взаимозаменяемо.
Ниже приведены некоторые ключевые различия в возможностях веб-сервера и сервера приложений:
Это подробный ответ с некоторыми сценариями, чтобы четко понять разницу, сходство и то, как оба могут работать вместе и все
Информация, передаваемая назад и вперед между сервером и его клиентом, не ограничивается простой разметкой дисплея, а взаимодействует между ними.
Пример:
Сценарий 1. Веб-сервер без сервера приложений.
у вас есть интернет-магазин только с веб-сервером и без сервера приложений. На сайте будет отображаться, где вы можете выбрать продукт. Когда вы отправляете запрос, сайт выполняет поиск и возвращает результат HTML своему клиенту. Веб-сервер отправляет ваш запрос непосредственно на сервер базы данных (наберитесь терпения, я объясню этот в нашем следующем слепке) и ждем ответа. После получения веб-сервер формулирует ответ в HTML-файл и отправляет его в веб-браузер. Эта двусторонняя связь между сервером и сервером базы данных происходит каждый раз, когда выполняется запрос.
Сценарий 2: веб-сервер с сервером приложений
если запрос, который вы хотите выполнить, уже был выполнен ранее, и с тех пор данные не изменились, сервер сгенерирует результаты, не отправляя запрос на сервер базы данных. Это позволяет выполнять запрос в режиме реального времени, когда второй клиент может получить доступ к той же информации и получать надежную информацию в режиме реального времени, не отправляя еще один повторяющийся запрос на сервер базы данных. Сервер в основном действует как промежуточное звено между сервером базы данных и веб-сервером. Это позволяет извлекать информацию для повторного использования в первом сценарии, поскольку эта информация встроена в определенную и «настроенную» HTML-страницу, это не процесс повторного использования. Второй клиент должен будет снова запросить информацию и получить другую HTML-страницу с запрошенной информацией, что крайне неэффективно.
Для поддержки такого множества сложных задач этот сервер должен иметь встроенную избыточность, большую вычислительную мощность и большой объем оперативной памяти для обработки всех данных, которые он извлекает в режиме реального времени.
Надеюсь это поможет.
Оба термина очень общие, один содержит другой, и в некоторых случаях наоборот.
Веб-сервер : передает контент в Интернет по протоколу http.
Сервер приложений : размещает и предоставляет бизнес-логику и процессы.
Я думаю, что главное в том, что веб-сервер предоставляет все через протокол http, в то время как сервер приложений не ограничен этим.
Тем не менее, во многих сценариях вы обнаружите, что веб-сервер используется для создания внешнего интерфейса сервера приложений, то есть он предоставляет набор веб-страниц, которые позволяют пользователю взаимодействовать с бизнес-правилами, найденными в сервер приложений.
веб сервер
Сервер приложений
Скажем, у нас есть крошечное приложение, как показано ниже (фрагмент из Flask ).
О какой бизнес-логике говорят все остальные? Итак, поскольку URL-адрес отображается где-то конкретно в нашей кодовой базе, мы гипотетически показываем некоторую логику о том, как работает наша программа.
резюмируя
Обратите внимание, что вы можете создать веб-сервер с кодом сервера приложений. Это делается в некоторых случаях во время разработки, когда вы не хотите, чтобы на вашем компьютере работало несколько миллиардов различных серверов.
Как указали Рутеш и Дж.М.Сервера, различие нечеткое. Исторически они были разными, но на протяжении 90-х годов эти две ранее разные категории смешивали и эффективно объединяли. На данный момент, вероятно, лучше всего представить, что категория продукта «Сервер приложений» является строгим расширенным набором категории «веб-сервер».
В параллельной категории сервер приложений развивался и существовал долгое время. Компании поставляли продукты для Unix, такие как Tuxedo, TopEnd, Encina, которые были философски получены из сред управления и мониторинга приложений мэйнфреймов, таких как IMS и CICS. Microsoft предложила Microsoft Transaction Server (MTS), который впоследствии превратился в COM +. В большинстве этих продуктов указаны «закрытые» протоколы связи для конкретных продуктов, позволяющие подключать «жирных» клиентов к серверам. (Для Encina протокол связи был DCE RPC; для MTS это был DCOM и т. Д.) В 1995/96 году эти традиционные продукты для серверов приложений начали внедрять базовые возможности HTTP-связи, сначала через шлюзы. И линии начали стираться.
Веб-серверы становились все более и более зрелыми в отношении обработки более высоких нагрузок, большего количества параллелизма и улучшения функций. Серверы приложений предоставляют все больше возможностей связи на основе HTTP.
На данный момент грань между «сервером приложений» и «веб-сервером» нечеткая. Но люди продолжают использовать термины по-разному, в качестве акцента. Когда кто-то говорит «веб-сервер», вы часто думаете о HTTP-ориентированных веб-интерфейсах и приложениях. Когда кто-то говорит «Сервер приложений», вы можете подумать, что «большие нагрузки, корпоративные функции, транзакции и очереди, многоканальная связь (HTTP + больше)». Но зачастую это один и тот же продукт, который удовлетворяет обоим наборам требований к рабочей нагрузке.