IPS Application Server
PS Application Server — сервер приложений IPS представляет собой набор библиотек и исполняемых файлов, которые обеспечивают базовую функциональность серверной части системы, а именно:
- загрузка и взаимодействие серверных модулей расширения;
- работа с базой данных и управление транзакциями;
- проверка прав доступа, аудит событий, контроль целостности данных, кэширование информации;
- публикация базовых классов для работы с метаданными и информационными объектами и т.д.
Сервер приложений может работать как консольное приложение или как служба Windows.
IPS позволяет устанавливать в сети произвольное количество серверов приложений — это дает возможность масштабировать систему для обеспечения одновременной работы сотен и тысяч пользователей. Специальная служба Брокер подключений обеспечивает автоматическую балансировку нагрузки на сервера приложений, а также автоматическое переподключение клиентов IPS к другим серверам приложений в случае выхода из строя одного из серверов.
Мастерская технологий и инструментов
- Технология и программное решение для нормативного обеспечения проектирования. Программный модуль (плагин) Autodesk Vault для автоматизации нормоконтроля.
- Автоматизированный поиск упоминаний нормативных документов в контексте файлов Ms Word, Excel, AutoCAD, зарегистрированных в Autodesk Vault;
- Запись ссылок на нормативные документы, примененные при разработке чертежа, тома, комплекта, раздела проекта и проекта в целом в специальную таблицу, доступную через интерфейс Autodesk Vault;
- Анализ актуальности примененных нормативов:
- Действует ли норматив;
- Какие были изменения;
- На что заменен;
- Автоматизация создания структуры проектов в среде Autodesk Vault;
- Автоматизация записи файлов в структуру документов и данных;
- Автоматизация преобразования параметров документов, читаемых средой Autodesk Vault и запись этих параметров (атрибутов) в среду Autodesk Vault.
IPS Application Server обеспечивает базовую функциональность серверной части системы и дает возможность ее масштабирования для обеспечения одновременной работы сотен и тысяч пользователей.
Загрузка и выполнение серверных модулей
Сервер приложений IPS предназначен для загрузки и выполнения серверных модулей расширения системы и предоставления им следующих базовых функций и классов:
- работа с базами данных и управление транзакциями;
- классы для проверки прав доступа и аудита событий, происходящих в системе;
- классы и службы для работы с метаданными, информационными объектами и связями между ними;
- средства для управления версиями и итерациями объектов;
- службы кэширования метаданных и информационных объектов;
- службы индексирования файловых, текстовых и строковых атрибутов;
- служба для работы с задачами, выполняемыми по расписанию;
- служба для получения рекурсивного состава и применяемости объектов;
- службы для работы с портфелем, веб-порталом, файловыми шкафами, выборками, классификаторами и пр.
Масштабирование системы
Допускается работа нескольких IPS Application Server с одной базой данных IPS. Таким образом, можно масштабировать систему при увеличении количества одновременно работающих пользователей. Также допускается работа нескольких консольных серверов приложений IPS на одном физическом сервере для работы с несколькими базами данных IPS.
Интеграция
Все модули расширения, разрабатываемые для IPS Application Server, получают доступ ко всем общим службам, классам и интерфейсам как самого сервера приложений, так и других модулей расширения, загруженных на сервере. Также большая часть служб и интерфейсов доступна внешним приложениям посредством технологии .NET Remoting.
Большинство модулей расширения IPS имеют свои серверные части, работающие под управлением IPS Application Server. Лицензии на эти серверные модули предоставляются бесплатно в случае наличия лицензии на сам сервер приложений IPS.
Системные требования
Сервер приложений IPS
Минимальные аппаратные требования:
- 1 ядро процессора типа Xeon класса Silver или выше на 5-15 пользователей системы.
- 1 Gb оперативной памяти на 5-15 пользователей системы (+объем памяти, рекомендуемый для используемой ОС).
- Диски SATA 7200rpm общим объёмом от 1 Tb.
Операционная система:
- Windows Server 2008 R2 или выше.
Сервер СУБД
Минимальные аппаратные требования:
- 1 ядро процессора типа Xeon класса Silver или выше на 10-20 пользователей системы.
- 1 Gb оперативной памяти на 10-20 пользователей системы (+объем памяти, рекомендуемый для используемой ОС).
- Для системной базы данных IPS рекомендуется использовать SSD-диски корпоративного класса суммарным объемом 1 Tb и выше. Для баз данных с файловыми шкафами рекомендуется использовать диски SAS или SATA 10000 rpm. суммарным объемом не менее 2 Tb.
Операционная система и СУБД:
- Windows Server 2008 R2 или выше.
- MS SQL Server 2008 R2 или выше, Oracle 11.2 или выше, PostgreSQL 9.5 или выше.
Сервер документов
Минимальные аппаратные требования:
- 1 ядро процессора типа Xeon класса Silver или выше на 50-100 пользователей системы.
- 1 Gb оперативной памяти на 50-100 пользователей системы.
- Диски SAS или SATA 7200 rpm. суммарным объемом не менее 2 Tb.
- В целях масштабирования системы допускается использование произвольного количества серверов документов в сети предприятия.
Операционная система:
- Windows Server 2008 R2 или выше.
Сервер лицензий
Минимальные аппаратные требования:
- 1 ядро процессора типа Xeon класса Bronze или выше на 100 пользователей системы.
- 100 Mb оперативной памяти на 500 пользователей системы.
- Специальных требований к дисковой подсистеме нет.
Прайс-листы на программное обеспечение
Что такое сервер приложения
Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:
- Написать код приложения
- Собрать проект
- Поднять его на сервере приложения
Сегодня я расскажу про третий этап: что вообще такое сервер приложения и зачем он нужен.
Что это такое и зачем он нужен
Жила была Анечка. Она пекла вкусные кексики и тортики на заказ. Чтобы удобнее было делать заказ, решила Анечка сделать свой интернет-магазин. И обратилась за помощью к брату, разработчику Ване.
Ваня говорит:
— Да не вопрос!Он как раз занимается фриланс-заказами с простыми системами типа интернет-магазинчиков. Поэтому он быстренько написал код на php. Но код — это просто набор файликов с расширением .php.
А как сделать так, чтобы у нас в интернете появилась страничка? Для этого нужен сервер приложения. Ваня для магазинчика выбирает apache (Apache HTTP Server), как наиболее популярный.
Мои тестовые системы:
— Users
— ShopТоже подняты на Apache. И написаны на php, то есть не требуют сборки))
Сервер обеспечивает возможность обращаться с приложением по HTTP-протоколу. Вы, конечно, можете и сами написать такой код, но зачем? Когда для этого уже есть готовая система. Причем бесплатная и open-source.
Положили код PHP в сервер. Запустили — вуаля, оно работает! Теперь у Анечки есть свой интернет-магазин, доступный извне, с любого устройства.
Если бы код был не на PHP, а на Java, у нас добавился бы шаг «собрать проект» — из набора текстовых файликов получить приложение. Обычно это архив, например, test.war. И уже его мы подкладываем в сервер. Ну а PHP — интерпретируемый язык. Ему не нужен сборщик.
Конечно, пока сайт доступен только по его IP. Чтобы это исправить, Анечке нужно выбрать доменное имя и купить домен. И тогда уже будет красивое название:
Вот теперь точно все готово!
Использование сервера приложений помогло Ване сконцентрироваться именно на бизнес-логике программы, не отвлекаясь на детали обеспечения транспортного пути. Ведь сервер приложения — это подобранный набор согласованных по версиям инфраструктурных библиотек. Например, http-сервер, который умеет принимать запросы.
Преимущества серверов приложений
Готовый HTTP-сервер
Пожалуй, самая важная и популярная функция сервера приложений — поддержка HTTP-сервисов и текущих HTTP-стандартов. Зайдите на любой сайт в интернете — фактически вы отправляете HTTP-запрос в приложение:
- Открой мне страницу гугла
- Покажи еще больше видео с котиками
- .
Да, можно написать обработку запросов самостоятельно. И следить за стандартами, постоянно обновлять код. Но зачем, когда есть готовый сервер?
Для небольших проектов хватает HTTP-сервера, без дополнительных функций и плюшек. На текущий момент самый популярный сервер — Apache HTTP Server. Есть и более сложные сервера, например, Wildfly. Они имеют больше функций и используются в энтерпрайз системах.
Систему Users мне делал фриланс разработчик. Она написана на PHP и поднята на сервере Apache.
А на работе у меня на одном из проектов был enterprise продукт.. Написан на Java, поднимается на сервере Wildfly.
Поддержка горячего резерва
Если упал сервер, то есть испортилось 1 звено в клиент-серверной архитектуре — всё, все в ступоре, все отдыхают. Сотни, тысячи, да хоть миллионы клиентов если есть — никто не может работать. Открываешь сайт в интернете и грустно смотришь на окно «Простите, что-то пошло не так»
Именно поэтому в бизнес-критичном ПО архитектуру усложняют и даже дублируют. Банк с тысячами операционистов не может позволить себе простой. Поэтому они используют кластер серверов — один упал, остальные работают.
Сервера в кластере называются нодами. На каждой ноде (железке) стоит свой wildfly (или аналог). Когда приходит запрос на одну ноду, она оповещает об этом вторую, третью, четвертую, или сколько их там будет.
Каждая нода может обработать запрос независимо. Если приложение имеет какое-либо состояние, то оно может быть сохранено в общую БД. А также ноды могут оповещать другие ноды об изменении состояния через очереди/топики.
Такая схема называется горячим резервом — когда у нас есть несколько работающих в параллели серверов. Может быть и схема холодного резерва, когда второй сервер у нас «на всякий случай», а не для постоянного использования.
Но какой бы ни был резерв, фишка в том, что синхронизацией занимается сервер приложения, а не разработчик. У разработчика не болит голова о том, как бы данные на разных серверах не разъехались. Он может сосредоточиться на бизнес-логике системы.
Централизованная настройка и управление
В сервере приложений обычно есть админка. Заходишь по специальному URL — и у тебя есть доступ к настройкам приложения. Вот так выглядит приветственная страница админки wildfly:
Если у вас несколько серверов приложения, то изменение настроек может быть опасным занятием. Одну ноду (сервер) обновили, вторую забыли, а потом ловим баг.
Но так как сервер поддерживает работу в кластере, то все упрощается:
- Мы меняем настройки в админке.
- Они сами расползаются по всем нодам.
Безопасность
В больших бюрократических компаниях разделяют разных админов:
- админ физического сервера (железка, на которой установлено ПО)
- админ сервера приложений (например, wildfly)
Так вот, админу приложения дают доступ только в админку wildfly. Физически на сервер он зайти не может, или может, но на птичьих правах, логи почитать. А если нужно параметры системы изменить — извольте заводить заявку для админа железяки.
Так безопаснее, когда у тебя нет лишних прав. Иначе неопытный админ системы может наворотить дел, разгребай потом за ним. Поэтому чем больше контора, тем важнее иметь возможность разделить права. Сервер приложения позволяет это сделать: OS отдельно, приложение отдельно.
Поддержка транзакций
Сервер поддерживает поддержку XA транзакций — когда несколько транзакционных источников поддерживают распределенную спецификацию, и сервер ее координирует.
Например, что-то записали в БД и послали сообщение по JMS, всё в одной транзакции, вот сервер приложений предоставляет в том числе менеджера распределенных транзакций.
Фишка всё та же — пока сервер приложений выполняет массу инфраструктурного кода, разработчики могут сфокусироваться на бизнес-логике.
И наверняка есть что-то еще
Я честно пыталась выведать у знакомых разработчиков, зачем вообще сервер приложения нужен.
Оказалось, что он, в общем-то, и не особо нужен. Ну разве что как HTTP-сервер, хотя и для этого уже есть готовые библиотеки, можно в коде это все делать и запускать условный Main.java, без всякого дополнительного сервера.
На работе в одном из проектов мы использовали wildfly. Он дает кучу возможностей, но по факту мы использовали:
• HTTP-сервер — а куда же без него?
• Datasource — файл, где прописывается соединение с БД
• MQ-очереди — для горячего резерва, синхронизация нод между собой. Один сервер уведомляет другой об изменениях. Если другой сервер пока занят, то это сообщение встает в очередь.Вот и всё!
Иногда сервер приложений используется просто потому, что так принято. Например, все старые приложения поднимались на Jboss, ну и новые тоже требуют делать на нем же. Потому что админы умеют работать именно с ним.
Или безопасники требуют разграничить доступ. Или по другим причинам используется именно этот сервер приложения, а не какой-то другой.
При этом я уверена, что в каких-то компаниях используют сервер приложения на полную катушку. И что в разных серверах есть еще куча разного полезного функционала, который вы могли бы написать сами в коде, но. Зачем? Когда вот оно, готовое.
Можно обойтись и без сервера. Да. Но с ним удобнее =)
Другие определения сервера
Когда вы разговариваете с коллегами, очень важно, чтобы вы говорили на одном языке!
Поэтому учтите, что под сервером приложений могут понимать разные вещи:
- Сервер приложения как ПО — Apache, Wildfly, и другие. Та программа, которая запускает ваше приложение.
- Физический сервер — компьютер, на котором установлен wildfly
Сервер приложений — это сервисная программа, которая обеспечивает доступ клиентов к прикладным программам, выполняющимся на сервере. Сервер приложений обычно выделяется как среднее звено в трехуровневой клиент-серверной архитектуре (3-tier)
Тут сервером называется именно программа. А вот другое определение:
Сервер приложений это набор физического и программного обеспечения, которое способно обеспечить доступ клиентов к программам, выполняющихся непосредственно на серверном оборудовании.
Тут уже сервером называют не только программное обеспечение, но и физический сервер.
Так что если сомневаетесь, что вы с собеседником говорите об одном и том же, лучше уточнить, что он имеет в виду!
Дополнительные материалы
Итого
Сервер приложения — это ПО, которое запускает ваше приложение. Сначала разработчик пишет код, потом собирает билд сборщиком. Но это просто некий архив с кодом. А вот чтобы это стало доступной в интернете ссылочкой, и нужен сервер приложения.
Сервер берет на себя скучную инфраструктурную работу. Например, организацию HTTP-уровня OSI. Он принимает запросы и обрабатывает их по всем стандартам. А разработчик может сконцентрироваться на бизнес-логике, не отвлекаясь на детали обеспечения транспортного пути.
В чем разница между веб-сервером и сервером приложений?
В чем разница между веб-сервером и сервером приложений?
Веб-серверы и серверы приложений – это технологии, которые позволяют обмениваться данными и услугами через Интернет. Архитектура клиент-сервер является базовым механизмом Интернета. Когда вы посещаете веб-сайт или приложение, ваш браузер (как клиент) запрашивает данные с удаленного сервера и отображает ответ. Веб-сервер – это программный компонент, который предоставляет статические данные, такие как изображения, файлы и текст, в ответ на запросы клиентов. Сервер приложений добавляет бизнес-логику для вычисления ответа веб-сервера. Оба термина используются как синонимы, и наиболее популярными серверными программными решениями сегодня являются гибридные серверы веб-приложений.
Как они работают: веб-сервер или сервер приложений
Веб-серверы и серверы приложений имеют разные независимые процессы. Однако они невидимы для конечного пользователя.
Как работает веб-сервер
Веб-сервер – это технология, на которой размещаются код и данные веб-сайта. Когда вы вводите URL-адрес в браузере, этот URL-адрес фактически является идентификатором адреса веб-сервера.
Ваш браузер и веб-сервер взаимодействуют указанным ниже образом.
- Браузер использует URL-адрес для поиска IP-адреса сервера
- Браузер отправляет HTTP-запрос на получение информации
- Веб-сервер связывается с сервером баз данных для поиска соответствующих данных
- Веб-сервер возвращает браузеру статический контент, такой как HTML-страницы, изображения, видео или файлы, в HTTP-ответе
- Затем браузер отображает вам информацию
Веб-сайт, на котором размещен статический контент, такой как блоги, изображения заголовков или статьи, может работать на веб-сервере. Однако большинство веб-сайтов и веб-приложений гораздо более интерактивны и требуют сервера приложений.
Как работает сервер приложений
Сервер приложений расширяет возможности веб-сервера, поддерживая динамическую генерацию контента, логику приложений и интеграцию с различными ресурсами. Он предоставляет среду выполнения, в которой можно запускать код приложения и взаимодействовать с другими программными компонентами, такими как системы обмена сообщениями и базы данных. Он использует бизнес-логику для более эффективного преобразования данных, чем веб-сервер.
Когда вы пытаетесь получить доступ к интерактивному контенту на веб-сайте, процесс происходит указанным ниже образом.
- Браузер использует URL-адрес для поиска IP-адреса сервера
- Браузер отправляет HTTP-запрос на получение информации
- Веб-сервер передает запрос на сервер приложений
- Сервер приложений применяет бизнес-логику и взаимодействует с другими серверами и сторонними системами для выполнения запроса
- Сервер приложений отображает новую HTML-страницу и возвращает ее в ответ веб-серверу
- Веб-сервер возвращает ответ браузеру
- Браузер отображает информацию для вас
На примере веб-сайта электронной коммерции, когда вы добавляете товары в корзину или оформляете заказ, вы взаимодействуете с сервером приложений.
Ключевые отличия: веб-сервер и сервер приложений
У веб-серверов и серверов приложений есть несколько ключевых отличий.
Охваченные задачи
Веб-сервер размещает веб-сайты и предоставляет ответы на простые запросы. Веб-серверы также регистрируют активность сервера и позволяют создавать сценарии на стороне сервера.
С другой стороны, серверы приложений имеют более сложный набор задач. Серверы приложений используют бизнес-логику для создания динамического контента путем подключения к корпоративным системам, сервисам и базам данных.
Используемые протоколы
Основным протоколом, который используют веб-серверы, является протокол HTTP. Однако различные веб-серверы также поддерживают FTP и простой протокол передачи почты (SMTP). Эти два протокола облегчают хранение и передачу файлов, а также электронную почту.
Помимо протоколов, используемых веб-серверами, серверы приложений используют дополнительные протоколы для связи с другими программными компонентами. Например, они могут использовать удаленный вызов метода (RMI) и удаленный вызов процедур (RPC).
Типы контента
Веб-серверы в основном предоставляют статический контент. Статический контент – это контент, который серверу не нужно изменять или обрабатывать перед отправкой. Например, файлы изображений (например, PNG, GIF и JPEG), загружаемые документы (PDF-файлы), видео и HTML-файлы представляют собой статический контент.
Серверы приложений в основном предоставляют динамический контент. Динамический контент – это контент, который меняется в зависимости от того, как пользователь взаимодействует с ним. Например, динамически создаваемые отчеты, настраиваемые представления данных, персонализированные пользовательские интерфейсы, результаты базы данных и обработанный HTML-код – все это динамический контент.
Многопоточность
Потоки на сервере – это отдельные пути работы, обеспечивающие параллельную обработку задач. В многопоточном режиме сервер создает и запускает несколько потоков одновременно, и каждый из них обрабатывает отдельную задачу или часть задачи. Поддержка многопоточности помогает быстрее доставлять веб-контент при одновременном управлении большим веб-трафиком.
Большинство веб-серверов не поддерживают многопоточность. Веб-серверы помещают каждый новый запрос на подключение в очередь и используют цикл событий для отслеживания новых записей и выходов из очереди. Для повышения эффективности сервер обрабатывает запросы с помощью неблокирующих операций ввода-вывода и обратных вызовов. Неблокирующие операции и архитектура, управляемая событиями, позволяют веб-серверам обрабатывать параллельные соединения.
Серверы приложений используют многопоточность для обеспечения высокой масштабируемости и эффективности. Если для запроса требуются внешние ресурсы, сервер приложений использует отдельные потоки для покрытия этих взаимодействий. Он может обрабатывать несколько потоков одновременно, параллельно обслуживая множество взаимодействий с клиентами.
Как взаимодействуют серверы приложений и веб-серверы?
Серверы приложений и веб-серверы совместно обрабатывают запросы клиентов и доставляют пользователю нужное содержимое. Веб-сервер всегда получает новый запрос первым. Если он может сам генерировать информацию, он делает это и отправляет ответ HTTP. Также проверяется, нет ли в кэше данных, которые запросил пользователь.
Если веб-сервер не может получить доступ к нужному пользователю содержимому, он перенаправляет запрос на сервер приложений. Сервер приложений обрабатывает данные и использует бизнес-логику для предоставления правильной информации. Затем запрос передается обратно на веб-сервер, который передает его пользователю. В некоторых архитектурах можно также настроить серверы приложений для самостоятельной обработки HTTP-запросов.
Краткое описание различий: веб-сервер и сервер приложений
Веб-сервер
Сервер приложений
Веб-серверы предоставляют ответы на простые запросы.
Сервер приложений предоставляет более сложное содержимое из баз данных, сервисов и корпоративных систем.
Веб-серверы в основном используют HTTP. Они также поддерживают FTP и SMTP.
Серверы приложений поддерживают множество протоколов.
Веб-серверы предоставляют статический контент, такой как HTML-страницы, изображения, видео и файлы.
Серверы приложений предоставляют динамический контент, например обновления в реальном времени, персонализированную информацию и поддержку клиентов.
Как правило, многопоточность не используется.
Используется многопоточность для одновременной обработки запросов.
Как AWS может удовлетворить требования к веб-серверу и серверу приложений?
Amazon Web Services (AWS) предлагает несколько решений облачного веб-хостинга, обеспечивающих недорогой способ доставки веб-приложений и веб-сайтов. Дополнительные сведения см. в статье о веб-хостинге на AWS. Вот два решения AWS для веб-хостинга:
- Amazon Lightsail – простейший способ запустить веб-сервер на AWS и управлять им. Lightsail включает все необходимое для запуска веб-сайта: виртуальную машину, хранилище на базе SSD, механизмы передачи данных, управление DNS и статический IP – и все это по низкой, предсказуемой цене.
- Эластичное вычислительное облако Amazon (Amazon EC2) предоставляет масштабируемые вычислительные мощности для серверов приложений в облаке. Оно помогает разработчикам, упрощая проведение вычислений в облаке в масштабе всего Интернета. Оно также обеспечивает максимальную масштабируемость и доступность веб-сайтов и веб-приложений. Amazon EC2 меняет экономику вычислений, и вы платите только за фактически используемые ресурсы.
Кроме того, AWS предлагает технологии, которые можно использовать для запуска кода, управления данными и интеграции приложений без управления серверами. Бессерверные решения AWS обеспечивают высокую доступность, оплату за использование и автоматическое масштабирование для вашего бизнеса. Дополнительные сведения см. в разделе о бессерверных решениях на AWS.
Ниже приведены способы использования бессерверных сервисов AWS.
- Храните данные с помощью Простого сервиса хранения данных Amazon (Amazon S3), Эластичной файловой системы Amazon (Amazon EFS) и Amazon DynamoDB.
- Вычисляйте с помощью AWS Fargate и AWS Lambda.
- Интегрируйте приложения с AWS AppSync, Amazon EventBridge и Простым сервисом очередей Amazon (Amazon SQS).
Начните работу с веб-серверами и серверами приложений на AWS, создав аккаунт уже сегодня.
Application Server
An application server in an n-tier architecture is a server that hosts an application programming interface (API) to expose business logic and business processes for use by applications.
Related terms:
- Web Application
- Authentication
- Internet Protocol
- Scalability
- Operating Systems
- Application Service
- Database Server
- Enterprise Application
- Structured Query Language
- Data Center
Add to Mendeley
About this page
Server Classifications
III.C. Application Servers
Application servers are network computers that store and run an application for client computers. Application servers, whatever their function, occupy a large chunk of computing territory between database servers and the end user. Most broadly, this is called “middleware” which tells us something about what application servers do. First and foremost, application servers connect database information (usually coming from a database server) and the end-user or client program (often running in a Web browser). There are many reasons for having an intermediate player in this connection, including a desire to decrease the size and complexity of client programs, the need to cache and control the data flow for better performance, and a requirement to provide security for both data and user traffic.
In the early days of application servers, it was realized that applications themselves, the programs people were using to get work done, were becoming bigger and more complex, both to write and maintain. At the same time, pressure was increasing for applications to share more of their data and sometimes functionality. More applications were either located on a network or used networks extensively. It seemed logical to have some kind of program residing on the network that would help share application capabilities in an organized and efficient way, and make it easier to write, manage, and maintain the applications.
These designated application servers first appeared in client/server computing and on LANs. At first, they were often associated with “tiered” applications, when people described the functionality of applications as two-tiered (database and client program), three-tiered (database, client program, and application service), or n-tiered (all of the above plus whatever). This was (and still is) a complex model of application development, and it resisted wide-scale implementation. Then along came the Internet application. The Internet application is automatically three-tiered (usually consisting of a database, client program, and Web servers). Managing data along with application functionality suddenly became not only an esoteric exercise in better program design, but also a downright necessity. This vaulted the application server from obscurity to the top of a pedestal, and literally scores of companies jumped in to develop products. Not surprisingly, people do not consider or think of the role of the application server in the same way, so application servers have different roles and functionalities as different companies build from their requirements and understanding. Scalability is a good example. Some companies might want an application server that simply helps them organize their applications for the Web, give them better control over the business logic they contain, and make it easier to monitor and secure the data. They do not need thousands of servers. Other companies, especially big ones, do need to manage thousands of servers. For them, the scalability of an application server is crucial. So some application servers feature scalability, others feature other things, and some try to do everything. Also, application server products belong to a variety of programming domains: some are Java based, while others are written by C++; one might support CORBA, and another could be implemented through Microsoft DCOM. It is relatively important to consider these servers in light of an organization’s programming preferences.
URL: https://www.sciencedirect.com/science/article/pii/B012227240400157X
MCSE 70-293: Planning Server Roles and Server Security
Martin Grasdal , . Dr. Thomas W. Shinder Technical Editor , in MCSE (Exam 70-293) Study Guide , 2003
Application Servers
Application servers provide access to a wide variety of data on the network, and they need to be hardened using the methods discussed earlier. The tasks users perform on a network often rely on their ability to use specific software and to be assured that all data is secure. To achieve these goals, hard disks storing these applications and the files they generate should be formatted with NTFS.
There is also a need for in-house applications, which are developed by programmers working for the company, to use the latest development tools. Older application development tools may have vulnerabilities that can be exploited. For example, a program developed using an older version of Visual Basic could be decompiled, allowing a hacker to view the code used to create the program. Code generated for in-house applications often contains sensitive information such as server names and authentication information. In addition, older development software is often not able to take advantage of the latest advances in security.
Application servers need to use the general security methods discussed for other servers. They may need to connect to other servers to acquire information or provide services. For example, an application hosted on an application server may use a database server to acquire and process data before returning it to end users. Because the two work in conjunction, the database server must also be secured. Even though the application server might be exceptionally secure, if there are security issues on the database server, the data might be compromised, which can potentially affect the ability of the application to do its job.
Servers configured in the application server role also have IIS 6.0 installed by default. IIS lets the application server provide Web-based applications to users of the network. Because the application server may have a Web server installed on it, steps need to be taken to ensure the Web server is also secure, as discussed earlier in this chapter.