В чем разница между сервером приложений и веб-сервером? Топологии серверов приложений WebSphere Application Server для обеспечения высокой доступности

Были рассмотрены возможности двух серверных платформ для терминальных решений. Но на рынке произошли изменения: появился новый сервер от Microsoft — "MS Windows 2000 Advanced Server", практически полностью уничтожающий различия между продуктами Microsoft и Citrix. Новый сервер обладает такими возможностями, как:

Служба кластеризации и перераспределения нагрузки
Поддержка протокола RDP5
Поддержка доступа к серверу при помощи браузера IE (компонент ACTIVE X)
Доступ к серверу печати, COM-портам и буферу обмена клиента.

Также стоит отметить появление на рынке продукта от компании Corel, который, к сожалению, в продажу на территории России не поступал и пока никакого независимого тестирования не проходил.

Основные задачи, которые выполняет сервер приложений — выполнение задач клиента и отправка изменившегося окна клиента. Здесь имеет смысл отметить два момента.

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

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

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

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

Выбор сервера приложений

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

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

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

Пример

Общее количество рабочих мест — 20. 10 пользователей используют только Microsoft Word, Excel, Outlook, IE (отдел продаж, маркетинга и PR), 3 пользователя используют только 1C (бухгалтерия), 4 пользователя используют IE, Outlook (начальники отделов), 2 пользователя очень редко используют Word и, наконец, остается системный администратор, загружающий все подряд от PhotoShop до J++.

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

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

Какие параметры вы должны получить:

Пиковая нагрузка на процессор. Частота пиковой нагрузки на процессор за день. Средняя продолжительность такой нагрузки.
Средняя загрузка процессора за день. Желательно также найти почасовую среднюю нагрузку.
Пиковое использование памяти. Частота пиковой нагрузки за день. Средняя продолжительность такой нагрузки.
Среднее использование памяти в течение дня, почасовая средняя нагрузка.

Вы должны провести такое испытание со всеми группами пользователей.

Далее вы легко можете получить так называемые "минимальные" показатели сервера приложений — помножьте средние показатели на количество пользователей в группе и сложите все группы. вы получите просто фантастические запросы к памяти — для нашего примера: около 780 Мбайт оперативной памяти и около 2 ГГц суммарной занятости процессора.

Но не стоит пугаться — метод, описанный выше неправилен:), так как терминальный сервер умеет эффективно использовать память.

К примеру, общий объем загружаемых компонентов Microsoft Word в памяти около 9 Мбайт, но 8 Мбайт из данного блока приходится на словари, графику и помощника. Когда будет запущена следующая копия Word, эти 8 Мбайт не будут загружены или продублированы — они будут доступны обеим копиям. Если какая-нибудь из них попробует изменить эту восьми мегабайтную часть, то измененная часть будет отделена и потребует немного памяти. Использование данного механизма распределения памяти позволяет экономить память. Но степень данной экономии вы сможете определить, только используя второго, подключенного к терминальному серверу клиенту. То есть вы подключаете второго клиента или запускаете записанную ранее роботом программу действий второй раз.

Итак, вы смогли определить примерные размеры приложений при повторном запуске. Далее вы должны составить примерную временную таблицу загруженности данного приложения в память. К примеру: Word — 27% времени, Excel — 10% времени, IE — 100% времени. Далее вы умножаете то количество памяти, которое действительно требуется на количество пользователей использующих данное приложение и на полученную таблицу. Получившиеся "мегабайто-сапиенс" и есть то минимальное количество памяти, которое вам потребуется (для нашего примера — около 340 Мбайт).

Процессорная мощность может быть вычислена и нормальным способом — вы можете просто сложить среднюю загруженность терминального сервера. Далее перевести эту загруженность в какие-либо масштабируемые единицы — к примеру, мегагерцы или показатели производительности какого либо теста процессора. Здесь стоит обратить внимание на то, что мегагерц — наихудший вариант, ибо 166MMX работает не 5 раз медленнее 800 МГц Athlon, но какой показатель наилучшим образом подходит для сравнения, к сожалению, сказать сложно.

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

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

вам должно быть известно количество таких моментов в течение рабочего дня и их распределение. Если таких перегрузок немного, то вы смело можете забыть про них, если же очень много то вам придется выделить дополнительные ресурсы памяти и процессора. К примеру, выяснилось, что обычная перегрузка происходит каждые 20 минут. При этом загрузка процессора возрастает на 200 МГц, плюс затрачивается в среднем около 10 Мбайт памяти. Продолжительность около 15 секунд. Практически именно данные показатели вы должны прибавить к минимальным. А вот утренняя перегрузка обладает другими качествами — предположим 20 перегрузок в течение 10 минут, длительностью около 20 секунд. вам тогда придется учитывать более сложную ситуацию — возникновение, скажем, двух перегрузок одновременно.

Итак, в итоге вы получили показатели: процессорная мощность — около 600 мегагерц процессор, 400 мегабайт оперативной памяти. Далее вы должны выделить память для самой операционной системы и ее сервисов. К примеру, если вы собираетесь инсталлировать Windows 2000 Advanced Server, смело прибавляйте 128 Мбайт памяти и около 40 МГц для внутренних задач.

Итог — 640 МГц на 512 Мбайт оперативной памяти.

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

Если вашим пользователям потребуется часто пользоваться жестким диском, рассмотрите возможность использования SCSI-контролера и SCSI-диска — это позволит разгрузить процессор, и уменьшить количество перегрузок.

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

После выбора

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

Во-первых, вы должны выбрать, будете ли вы использовать продукты компании Citrix или остановитесь на продуктах от Microsoft. Более дорогой вариант — Metaframe, обладает несколькими не очень важными с моей точки зрения возможностями:

Program Neighborhood. Применение данного компонента практически бессмысленно, если количество пользователей менее 100, в любом случае вы сможете, используя стандартные средства администрирования, добиться той же эффективности
Video Frame — данный компонент позволяет нескольким операторам или скажем только вам наблюдать за работой клиентов и если надо вмешиваться в их работу.
Поддержка передачи звука
Поддержка IPX/SPX, и некоторых другие протоколы, включая соединение по нуль модемному кабелю.

Наиболее важное отличие между данными терминальными серверами лежит в протоколе подключения клиентов. Microsoft использует для этого RDP 5.0, Citrix — ICA.

Эти протоколы имеют собственные плюсы и минусы. К примеру, ICA — платформенно-независимый протокол, клиент может работать на любой платформе, будь он веб-браузером или старым добрым Lunix. Протокол от Microsoft работает только на 2 клиентах — WIN16 и WIN32, но это дает ему возможность использовать вызовы WINAPI, что резко сокращает размер и количество передаваемых пакетов. В итоге данный протокол чаше демонстрирует возможность комфортной работы на полосе 4-8 Кбайт в секунду, когда Citrix даже при установке SPEEDSCREEN2 (утилиты для сжатия потока ICA) не демонстрирует показатели лучше 10 килобайт в секунду.

Как это может отразиться на работе вашего предприятия? Если вам придется подключать удаленное подразделение, то использование коммерческих линий часто оказывается очень дорогим удовольствием и сжатие потока будет очень важно. К примеру, для очень комфортного подключения одного клиента по RDP5.0 придется использовать два модема 33.6, а по ICA — в обязательном порядке выделенный канал.

Второй фактор при покупке данных продуктов — возможность приобрести их на территории России. Если продукты Microsoft еще присутствуют, то продукты от компании Citrix вам придется поискать. Как дополнительный плюс надо отметить русифицированость продуктов Microsoft.

Инсталляция

Windows 2000 Advanced Server

Инсталляция обычно проходит без особых проблем, единственное, что от Вас потребуется — это установить терминальные службы в качестве компонента. Далее никаких особенных настроек от Вас не понадобится, вам потребуется лишь лицензировать сервер на более чем 2 подключенных клиента и на этом настройка закончится.

Citrix Metaframe 1.8

Установка также не должна вызвать у Вас каких-либо проблем, никаких сложных настроек при установке указывать не надо.

Но если у Вас возникли какие-либо проблемы с установкой какого-либо из этих продуктов, то вы легко сможете найти инструкции по установке на нескольких российских серверах.

Настройка сервера после установки

Здесь я приведу несколько советов по улучшению состояния серверов:

Отключите сжатие потока, если ваши клиенты не обладают мощными процессорами. Это также должно снизить нагрузку на сервер.
Не используйте сервер как прокси, веб-сервер, сервер баз данных. Для этих целей выделите другую рабочую станцию.
Отключите или снизьте до 1-2 Мбайт кэширование битмэпов в случае использования бездисковых клиентов. Это разгрузит сеть и убыстрит работу.
Уменьшите до 640х480 точек и 16 цветов размер клиентского десктопа. Это резко снизит нагрузку на сеть и даст еще немного ресурсов серверу.
Отключите любые скрин-сейверы на стороне клиента, или, проще говоря, не инсталлируйте их.
Попытайтесь избавиться от любых DOS-компонентов или любых компонентов, активно использующих графику.
Отключите всевозможные видеоэффекты, заставки, фоны рабочего стола и тому подобные прелести.
Отключите шифрование, так как оно примерно на 5 процентов снижает скорость работы клиента.
Попробуйте отделить сегмент сети, в которой работает ваш сервер приложений и клиенты, это снизит нагрузку на сеть.
Увеличьте кэш битмапов до максимума, в случае использования дисковых клиентов. Это резко увеличит скорость обновления экрана.
Запретите пользователям использовать какие либо другие средства, кроме регламентированных (обязательно выключите пинбол при установке сервера, так как данное приложение готово загрузить все предлагаемые ему мощности;))

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

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

Основной вопрос в таких сетях: как отразится резкое снижение полосы пропускания на качестве работы.

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

Задержка при передаче данных была принудительно установлена в 0.25 секунды (я думаю, что большие задержки даже в России получить сложно). Все битмапы были предварительно кэшированы. Использовался RDP 5.0.

Канал 8 Кбайт в секунду

Пауза чувствуется при открытии любого окна, складывается ощущение, что при нажатии на кнопку только через секунду на экране показывается диалоговое окно. При печати текста возникает ощущение наличия в клавиатуре огромного буфера — символов этак на 30. Очень долго происходит соединение с сервером: экран авторизации появляется только через 15 секунд.

Канал 6 Кбайт в секунду

Резко возрастает время появления диалогов, даже при повторном запросе. Пауза между выводом символа в Word и нажатием кнопки около секунды. Но нормальная работа еще возможна.

Канал 4 Кбайта в секунду

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

Канал 2 Кбайта в секунду

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

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

Если вам требуется консультация по установке терминальных серверов или построении корпоративных систем управления на их основе, то пишите мне по почте.

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

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

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

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

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

Бизнес-логика может быть реализована на стороне сервера как целиком (удаленный код), так и частично (распределенный код). В первом случае к серверу могут обращаться терминалы и «тонкие» клиенты и такое взаимодействие соответствует модели «сервер терминалов». «Толстые» и 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.

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

Файл-сервер и сервер приложений очень похожи на первый взгляд. Но есть и отличия. Файл-сервер хранит данные и программы, а сервер приложений обрабатывает первые и выполняет вторые.

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

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

Предоставление сервисных услуг для программ.

Предоставление модели контейнера для приложений.

Обеспечение управления приложениями. Представление средств их разработки.

Соответствие стандартам и индустриальным спецификациям.

Обслуживание веб-страниц, поскольку в этом существует реальная востребованность.

Преимущества при работе с серверами приложений:

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

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

Безопасность. Важность пункта не обсуждается. При проверке поставщиком услуг не будет затрагиваться уровень базы данных, потенциально ненадежные клиенты отсеиваются в среднем слое.

Производительность. На сервер приложений можно возложить задачу по балансировке сетевого трафика. Результат – равномерное распределение нагрузки между физическими серверами системы.

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

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

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

Сервер приложений (англ. application server ) - это программная платформа (software framework), предназначенная для эффективного исполнения процедур (программ, механических операций, скриптов), которые поддерживают построение приложений. Сервер приложений действует как набор компонентов, доступных разработчику программного обеспечения через API (Интерфейс прикладного программирования), который определен самой платформой.

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

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

Преимущества серверов приложений

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

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

Централизованная настройка и управление

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

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

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

Поддержка транзакций

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

Примеры реализации

Под сервером приложений в случае Java EE подразумевается комплекс программ, реализующих концепцию Java EE и позволяющих запускать в себе Java EE приложения. К классу серверов приложений относятся такие продукты как Sun GlassFish, IBM WebSphere, RedHat JBoss Application Server, Apple WebObjects (англ. ) и др.
Zope, развитый сервер web-приложений.
Терминальные серверы, например поставляемые компанией Citrix

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 и связанные объекты на нем.

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