Сервер приложений выполняет такие функции как. Серверы приложений. Кто будет заинтересован в этой роли

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

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

Модель "сервер приложений"

1. Первый уровень, интерфейсный, как правило, графический (GUI).
2. Средний уровень, исполнимый программный код, размещенный обычно на выделенном сервере.
3. Третий уровень, фоновый - базы данных. Сюда же относятся, унаследованные средства доступа к данным и управления транзакциями.

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

Бизнес-логика может быть реализована на стороне сервера как целиком (удаленный код), так и частично (распределенный код). В первом случае к серверу могут обращаться терминалы и «тонкие» клиенты и такое взаимодействие соответствует модели «сервер терминалов». «Толстые» и rich-клиенты могут получать компоненты серверного приложения и выполнять их на своей стороне (например javascript, апплеты, flash).

Мобильный софт

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

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

Клиенты могут взаимодействовать с приложениями через API сервера (Java-клиент <-> контейнер сервлетов <-> сервлет). Большую гибкость и универсальность представляет взаимодействие через сторонние сервисы, в первую очередь - через веб-сервер.

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

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

Поэтому, чтобы ответить на вопрос, является ли (и в какой степени) некое сервисное ПО сервером приложений, стоит сравнить его заявленные функции со списком атрибутов, присущих этой категории:

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

Реализации

По приведенным признакам в рассматриваемую категорию попадают, например, традиционные терминал-серверные системы, технология CGI, контейнеры Java-сервлетов и др.

Унаследованные решения

Серверы терминалов представляют среду для удаленного выполнения программ, в качестве которой выступает сама операционная система. Доступ к ним осуществляется по протоколам удаленного управления (telnet, ssh, RDP, VNC и т. п.) из клиентского ПО (эмулятор терминала, средства управления удаленным рабочим столом и т.п.). Управление запущенной программой выполняется через эмулируемый на клиенте пользовательский интерфейс (текстовый или графический) операционной системы. На серверной стороне взаимодействие программ с ОС реализуется через системные вызовы. Управление также осуществляется средствами операционной системы. Разработка может вестись на любом языке, доступном в конкретной ОС.

Общий шлюзовый интерфейс (CGI) - технология доступа к приложениям через веб-сервер. Отличия от сервера терминалов здесь в том, что пользовательский интерфейс предоставляется в виде веб-страниц. Запросы веб-клиентов, обращенные к программам, размещенным в выделенном каталоге (как правило cgi или cgi-bin) перенаправляются на их вход через стандартный поток ввода (stdin). Результаты выполнения в виде гипертекста приложение возвращает веб-серверу через stdout.

Серверы Java-приложений

Платформа Java является индустриальным стандартом, позволяющим создавать из унифицированных компонентов интероперабельные программные решения для самых разных систем, в которых может быть запущена виртуальная машина Java (JVM).

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

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

Примером реализации контейнера сервлетов является Apache TomCat, который используется в таких серверах приложений как Apache Geronimo, JBoss, GlassFish, IBM WebSphere Application Server (WAS).

Другие решения

Компания Microsoft представляет собственные решения для поддержки бизнес-логики и сервисной инфрастуктуры на основе ОС Windows Server и технологии.NET Framework. Основным средством разработки является язык C#.

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

Для сценариев на языке PHP, широко используемом для создания веб-сайтов, компания Zend Technologies (разработчик самого языка PHP) создала сервер приложений Zend Server.

Серверы приложений: плюсы и минусы

Преимущества

Целостность кода и данных

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

Централизованное управление

Изменения в конфигурации прикладных программ, такие как, например, смена сервера баз данных, выполняются централизованно.

Безопасность

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

Производительность

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

Общая стоимость владения

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

Недостатки

Централизация

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

Защита информации

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

Постоянный адрес этой страницы:

27 ответов

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

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

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

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

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

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

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

Сервер приложений : хосты и раскрывают бизнес-логику и процессы.

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

Как указывал Rutesh и jmservera, различие является нечетким. Исторически сложилось, что они были разными, но через 90 эти две ранее отличающиеся категории смешивали черты и эффективно сливались. На данный момент лучше всего предположить, что категория продуктов "Сервер приложений" является строгим надмножеством категории "веб-сервер" .

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

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

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

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

веб сервер

Запустите python -m "SimpleHTTPServer" и перейдите по адресу http://localhost: 8080 . То, что вы видите, это веб-сервер в его работе. Сервер просто обслуживает файлы по HTTP, хранящиеся на вашем компьютере. Ключевым моментом является то, что все это делается поверх протокола HTTP. Также существуют FTP-серверы, например, которые делают то же самое (обслуживая сохраненные файлы), но поверх другого протокола.

Сервер приложений

Скажем, у нас есть крошечное приложение, как показано ниже (фрагмент из Flask).

@app.route("/") def homepage(): return "My homepage" @app.route("/about") def about(): return "My name is John"

Небольшой пример программы отображает URL / на homepage() функции homepage() а /about - на функцию about() .

Для запуска этого кода нам нужен сервер приложений (например, Gunicorn) - программа или модуль, который может прослушивать запросы от клиента и, используя наш код, возвращать что-то динамически. В примере мы просто возвращаем очень плохой HTML.

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

резюмируя

веб-сервер - обслуживает файлы, хранящиеся где-то (чаще всего.css,.html,.js). Обычными веб-серверами являются Apache, Nginx или даже Python SimpleHTTPServer.

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

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

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

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

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

Apache: Php, CGI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сервер приложений является расширенной
версией сервера в операционной системе Windows Server ® 2008. Новая версия
сервера приложений предоставляет интегрированную среду для развертывания и выполнения
пользовательских дел на сервере приложений. Эти приложения отвечают на запросы,
поступающие по сети от удаленных клиентских компьютеров или из других приложений.
Как правило, для развертывания и запуска на сервере приложений пользователь
производит одно или более из следующих действий:

• Internet Information Services (IIS) (протокол
  передачи гипертекста (HTTP) сервер, встроенный в Windows Server)
• Microsoft ®.NET Framework
  версии 3.0 и 2.0. (Если у вас есть приложения, построенные с.NET
  Framework 3.5, вы можете загрузить и установить.NET Framework 3.5 на
  операционной системы.)
• ASP.NET
• COM +
• Очереди сообщений
• Веб-службы, которые построены с Windows Communication Foundation (WCF)

Мы рекомендуем использовать роль сервера
приложений Windows Server 2008 выполняемую приложениями, которые зависят от
служб роли или компонентов, которые являются частью комплексной роли сервера
приложений и выбрать во время процесса установки. Примером может быть
определенна конфигурация Microsoft BizTalk ® Server, которая использует набор
служб роли или компонентов, которые являются частью среды сервера приложений.

Обычно роль сервера приложений необходима
при развертывании бизнес-приложения в рамках вашей организации (или
разработанного независимый поставщик программного обеспечения (ISV) для вашей
организации), и когда разработчик указал, что конкретная роль службы требуются.
К примеру ваша организация может иметь приложение обработки заказа, доступ к
записи клиентов, которые хранятся в базе данных. Приложение получает доступ к
сведения о клиенте через набор веб-служб WCF. В этом случае можно настроить
один компьютер Windows Server 2008 в качестве сервера приложений и базы данных
можно установить на том же компьютере или на другом компьютере.

Не все серверные приложения выгодны для
установки роли сервера приложений. Например роль сервера приложений не является
необходимой для поддержки сервера Microsoft Exchange Server или Microsoft SQL
Server на Windows Server 2008.

Чтобы определить, если роль сервера
приложений является полезным для вашей организации бизнес-приложений, есть
администраторы тесно связанные с разработчиками приложений для выявления
требований приложения, например, она использует ли.NET Framework 3.0 или COM +
компоненты.

Что такое сервер приложений?

Сервер приложений предоставляет следующее:

• Среда выполнения поддерживает эффективное
  развертывание и управление высокопроизводительных серверных
  бизнес-приложений. Эти приложения способны обслуживать запросы от
  удаленных клиентских систем, включая веб-браузеры, соединения из Интернета
  или из корпоративной сети или интрасети и систем удаленного компьютера,
  которые может отправлять запросы в виде сообщений.
• .NET Framework 3.0, который предоставляет
  разработчикам упрощенную модель программирования для подключенных
  серверных приложений. Разработчики могут использовать встроенный.NET
  Framework библиотеки для многих функций приложения, включая ввода/вывода
  (I/O), числовые и обработка текста, доступ к базе данных, XML обработку,
  управление транзакциями, рабочий процесс и веб-служб. Для системных
  администраторов.NET Framework обеспечивает безопасную и высокую
  производительность выполнения средой выполнения для серверных приложений,
  а также упрощенные приложения настройки и развертывания среды.
• Установка Windows Server 2008 в новый, удобный для
  пользователя мастера добавления ролей, помогает вам выбрать службы ролей и
  функции, которые необходимы для запуска приложений. Мастер добавления
  ролей автоматически устанавливает все компоненты, необходимые для данной
  роли службы и делает его более легким для вас, для создания и
  предоставления компьютер в качестве сервера приложений для
  бизнес-приложений.

Кто будет заинтересован в этой роли?

Эта информация о роли сервера приложений
является главным образом для информационных технологий (ИТ) специалистов, ответственных
за развертывание и обслуживание Организации линии бизнес-приложений (LOB).
Бизнес-приложения обычно разрабатываются в вашей организации или для вашей
организации.

Среда сервера приложений состоит из одного
или нескольких серверов под управлением Windows Server 2008, настроенных с роли сервера приложений. Это включает серверы,
выполните следующие действия:

• Приложения, построенные с.NET Framework 3.0
• Приложения, построенные для использования COM +,
  очереди сообщений, веб-службы и распределенные транзакции
• Подключение к интрасети или Интернету для обмена
  информацией
• Приложения, которые предоставляют или
  использовать веб-службы
• Приложения, которые предоставляют веб-страниц
• Взаимодействовать с другими удаленными системами,
  работающие на разных платформах и операционных системах

Расширенный среды сервера приложений может
также включать следующее:

• Домен клиентские компьютеры и их пользователей
• Компьютеры, которые используются главным образом
  для управления серверами приложений
• Серверы инфраструктуры, которые работают ресурсы,
  такие как доменных служб Active Directory (AD DS) или другие репозитории
  протокола LDAP (Lightweight Directory Access Protocol), службы
  сертификации, шлюзы безопасности, процесс серверы, интеграции серверов,
  приложений или шлюзы данных или базы данных

Какие новые возможности предоставляет эта роль?

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

Ядро сервера приложений

Ядро сервера приложений – это группа
технологий, устанавливаемых по умолчанию при установке роли сервера приложений.
По существу, это ядро сервера приложений.NET Framework 3.0. (Если у вас есть
приложения, построенные с.NET Framework 3.5, вы можете загрузить и
установить.NET Framework 3.5 на операционной системы.)

Windows Server 2008 включает.NET Framework
2.0, независимо от любой роли сервера, которая устанавливается. .NET Framework
2.0 содержит Common Language Runtime (CLR), которая обеспечивает среды
выполнения кода, которая обеспечивает безопасное выполнение кода, его
упрощенное развертывание, и поддержку совместного использования нескольких
языков, а также обширные библиотеки для создания приложений.

Добавляетядро сервера приложений.NET Framework 3.0
возможности базовой линии.NET Framework 2.0 возможности. Для получения
дополнительных сведений.NET Framework 3.0, см.Центр разработчиков NET Framework
(http://go.microsoft.com/fwlink/?LinkId = 81263).

Почему важна эта функциональная
возможность?

Ключевые компоненты ядра сервера
приложений установлены как набор библиотек кода и.ЧИСТЫЕ сборки. Ниже приведены
ключевые компоненты ядра сервера приложений:

• Windows Communication Foundation (WCF)
• Windows Workflow Foundation (WF)
• Windows Presentation Foundation (WPF)

Из этих трех, WCF и WF часто используются
в серверных приложений, а также-приложениях клиента. WPF используется
преимущественно в клиентских приложениях, и это не обсуждается далее здесь.
Дополнительные сведения о WPF, см. в Windows Presentation Foundation (http://go.microsoft.com/fwlink/?LinkId = 78407).

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

WCF позволяет разработчикам создавать или
комбинировать различные технологии, которые сегодня доступны для создания
распределенных приложений (COM + и.Услуги NET Enterprise, очереди сообщений.NET
Remoting, ASP.Чистый веб-служб и расширения веб-служб (WSE)) таким образом,
чтобы иметь смысл для бизнеса и вычислительной среды вашей организации. Для
получения дополнительных сведений о WCF видеть Windows Communication
Foundation? (http://go.microsoft.com/fwlink/?LinkId = 81260).

WF – это модель и ядро программирования
для создания приложений, поддерживающих бизнес-процессы, быстро на Windows
Server 2008. Рабочий процесс - это набор мероприятий, которые описывают процесс
реального мира, такие, как процесс заказа покупки. Рабочий процесс обычно
описывается и рассматривать графически - то, как блок-схемы. Описание рабочего
процесса часто называют «модели». Рабочие элементы проходят через модель
рабочего процесса от начала до конца.

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

WF поддерживает рабочий процесс системы и
документооборота в различных сценариях, включая следующие:

• Рабочий процесс в бизнес-приложений
• Последовательный поток экранов, страниц и
  диалоговые окна, представленные в ответ на взаимодействие пользователя с
  пользовательским интерфейсом (UI) для данного пользователя
• Документ центре рабочий процесс, например,
  обработка заказа на покупку или медицинские записи
• Взаимодействие документооборота, таких, как
  отправка электронной почты для бизнес-клиентов и получение электронной
  почты от клиента
• Составной рабочий процесс для SOA
• Бизнес правил-управляемые делом рабочий процесс,
  например: «В понедельник в 17: 00, отправить запрос на обновление каталога
  для деловых партнеров».
• Рабочий процесс для управления системами

Что работает по-другому?

Хотя есть роль сервера приложений в
Windows Server 2003, Новая, расширенная роль сервера приложений, доступных в ОС
Windows Server 2008 не просто обновление от средства настройки сервера
приложений, который включен в Windows Server 2003 или более ранних версий
операционной системы. Так как роль функциональность является совершенно новой,
администраторы должны осознавать, что не существует миграции пути для средства
настройки сервера приложений с Windows Server 2003 или более ранних
операционных систем.

Как решить эти проблемы?

Если обновления сервера до Windows Server
2008 с Windows Server 2003 или более ранних версий операционной системы, и вы
хотите использовать возможности роли сервера приложений, необходимо
переустановить роль сервера приложений с помощью мастера добавления ролей в
диспетчере сервера. Как настроить Windows Server 2008 с правильным применением
служб с помощью мастера добавления ролей в диспетчере сервера, можно легко
переместить ваши приложения с Windows Server 2003 до Windows Server 2008.

Когда следует использовать роль сервера
приложений?

Если на сервере бизнес-приложений, которые
необходимо развертывать и управлять требуется одно или несколько из следующих
технологий: Microsoft.NET Framework 3.0, очередь сообщений, COM + или распределенные
транзакции, следует настроить ваш сервер в роли сервера приложений.

Как подготовиться к установке?

Как часть вашей подготовки для установки
роли сервера приложений создаете перечень приложений, которые будут выполняться
на этом сервере. Если вы являетесь администратором, работа с разработчиками или
ISV, который разработал приложения для определения поддержки технологий и
конфигурации, которые должны присутствовать на сервере для запуска приложений.
Затем сопоставьте эти технологии служб ролей, которые описаны в следующих
разделах, так что вы можете выбрать и должным образом настроить службы во время
установки роли сервера. Обычно разработчик или ISV список из технологий,
которые должны быть установлены для этого приложения, например,.NET Framework
3.0.

Веб-сервер

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

Службы IIS предоставляют следующие
основные преимущества:

• IIS делает возможным для сервера приложений
  провести внутренние или внешние веб-сайты или услуги со статическим или
  динамическим содержимым.
• 
  ASP.NET приложения, которые доступны в веб-обозревателе.
• Службы IIS обеспечивают поддержку для запуска
  веб-служб, которые построены с Microsoft WCF или ASP.NET.

Доступ К сети COM +

Этот параметр добавляет COM + доступ К
сети для удаленного вызова приложений, которые построены и размещенных в COM +
и корпоративных служб компонентов. Такие приложения называют также компонентами
корпоративных служб.

Доступ К сети COM + является одной из
возможностей удаленного вызова, поддерживается в Windows Server начиная с
Windows 2000 Server, и он по-прежнему поддерживаться в Windows Server 2008.
Более новые приложения обычно использовать WCF для поддержки удаленного вызова,
потому что WCF обеспечивает взаимодействие на нескольких платформах.

Служба активации процессов Windows

Этот параметр добавляет службы активации
процессов Windows (WAS). Можно запустить и останавливать приложения,
динамически, основываясь на сообщениях, получаемых по сети через HTTP, очереди
сообщений, TCP и именованные каналы протоколов. Динамические запуск и остановка
приложений означает, что более эффективное использование ресурсов сервера. БЫЛО
это новая услуга в Windows Server 2008.

Общий доступ К портам Net.TCP

Этот параметр добавляет портам Net.TCP.
Эта служба роли позволяет нескольким приложениям использовать один TCP-порт для
входящих сообщений. Например SOA, который построен с WCF могут совместно
использовать тот же порт. Совместное использование портов требуется часто когда
настройки брандмауэра или сетевые ограничения позволяют лишь ограниченное число
открытых портов или когда несколько отдельных экземпляров приложения WCF должна
быть запущена и в то же время.

Таким образом, чтобы несколько WCF
приложения могут совместно использовать порты (мультиплексирование), портам
Net.TCP выполняет мультиплексирование. Портам Net.TCP принимает входящие
запросы на подключение, используя протокол TCP. Затем автоматически перенаправляет
входящие запросы различным службам WCF, основанный на целевых адресов запросов.
Общий доступ к портам работает только тогда, когда приложения WCF используют
протокол net.tcp для входящих соединений. Общий доступ к портам Net.TCP – это
новая услуга в Windows Server 2008.

Распределенные транзакции

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

Поддержка распределенных транзакций в
Windows Server 2008 предоставляет способ для приложений для этого требования
выполнены. Поддержка распределенных транзакций в Windows Server с Microsoft
Windows NT ® Server 4.0, и эта поддержка продолжается в Windows Server 2008.

Доступна ли эта роль во всех выпусках Windows Server 2008?

Сервер приложений доступен в следующих
выпусках Windows Server 2008:

• Windows Server 2008 стандарт
• Windows Server 2008 Enterprise
• Windows Server 2008 Datacenter
• Windows Server 2008 для систем на базе Itanium

Роль сервера приложений не доступны в
следующем выпуске Windows Server 2008:

• Windows Web Server 2008

Он ведет себя по-разному в некоторых
изданиях?

Сервера приложений, поведение не меняется
основаны на выпуске Windows Server 2008.

Доступен в 32-разрядных и 64-разрядных
версиях?

Сервер приложений доступен в 32-разрядных
и 64-разрядных версиях Windows Server 2008.