Application server что это за роль

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

Сервер приложений (англ. 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

См. также

Тонкий клиент
Трёхзвенная архитектура
Веб-приложение

Ссылки

Simple explanation of application servers (англ.)

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

Java Enterprise Edition
Архитектура программного обеспечения
Серверы приложений

Роли сервера в ОС Windows

При установке Windows большая часть второстепенных подсистем не активируется или не устанавливается. Это сделано по причинам безопасности. Поскольку система по умолчанию защищена, системные администраторы могут сосредоточиться на проектировании системы, которая будет выполнять исключительно возложенные на нее функции и ничего лишнего. Для помощи при включении нужных функций, Windows предлагает выбрать роль сервера (Server Role).

Роли

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

Службы ролей

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

Компоненты — это программы, которые не являются непосредственно частями ролей, но поддерживают или расширяют функции одной или нескольких ролей либо целого сервера независимо от того, какие роли установлены. Например, компонент «Средство отказоустойчивости кластеров» расширяет функции других ролей, таких как Файловые службы и DHCP-сервер, позволяя им присоединяться к серверным кластерам, что обеспечивает повышенную избыточность и производительность. Другой компонент — «Клиент Telnet» — обеспечивает удаленную связь с сервером Telnet через сетевое подключение. Эта функция расширяет возможности связи для сервера.

Когда Windows Server работает в режиме основных серверных компонентов, поддерживаются следующие роли сервера:

службы сертификатов Active Directory;
доменные службы Active Directory;
DHCP-сервер;
DNS-сервер;
файловые службы (в том числе диспетчер ресурсов файлового сервера);
службы Active Directory облегченного доступа к каталогам;
Hyper-V;
службы печати и документов;
службы потокового мультимедиа;
веб-сервер (в том числе подмножество ASP.NET);
сервер обновления Windows Server;
сервер управления правами Active Directory;
сервер маршрутизации и удаленного доступа и следующие подчиненные роли:
- посредник подключений служб удаленных рабочих столов;
- лицензирование;
- виртуализация.
Когда Windows Server работает в режиме основных серверных компонентов, поддерживаются следующие компоненты сервера:
- Microsoft .NET Framework 3.5;
- Microsoft .NET Framework 4.5;
- Windows PowerShell;
- фоновая интеллектуальная служба передачи (BITS);
- шифрование диска BitLocker;
- сетевая разблокировка BitLocker;
- BranchCache
- мост для центра обработки данных;
- Enhanced Storage;
- отказоустойчивая кластеризация;
- Multipath I/O;
- балансировка сетевой нагрузки;
- протокол PNRP;
- qWave;
- удаленное разностное сжатие;
- простые службы TCP/IP;
- RPC через HTTP-прокси;
- сервер SMTP;
- служба SNMP;
- клиент Telnet;
- сервер Telnet;
- клиент TFTP;
- внутренняя база данных Windows;
- Windows PowerShell Web Access;
- служба активации Windows;
- стандартизированное управление хранилищами Windows;
- расширение IIS WinRM;
- WINS-сервер;
- поддержка WoW64.
Установка ролей сервера с помощью Server Manager

Для добавления открываем Server Manager, и в меню Manage жмем Add Roles and features:

Откроется мастер добавления ролей и компонентов. Жмем Next

Installation Type, выбираем Role-based or feature-based installation. Next:

Server Selection — выбираем наш сервер. Жмем Next Server Roles — Выберите роли, если необходимо, выберите службы ролей и нажмите кнопку Next, чтобы выбрать компоненты. В ходе этой процедуры Мастер добавления ролей и компонентов автоматически информирует о возникших конфликтах на конечном сервере, которые могут помешать установке или нормальной работе выбранных ролей или компонентов. Также появляется запрос на добавление ролей, служб ролей и компонентов, необходимых для выбранных ролей или компонентов.

Установка ролей с помощью PowerShell

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

Введите Get-Help Install-WindowsFeature для просмотра синтаксиса и допустимых параметров командлета Install-WindowsFeature (MAN).

Вводим следующую команду (-Restart перезагрузит сервер, если при установке роли требуется перезагрузка).
```
Install-WindowsFeature –Name -Restart
```
Описание ролей и служб ролей

Ниже описаны все роли и службы ролей. Расширенную настройку посмотрим для самых часто встречающихся в нашей практике Web Server Role и Remote Desktop Services

Подробное описание IIS
- Common HTTP Features — Основные HTTP компоненты
  - Default Document — позволяет устанавливать индексную страницу у сайта.
  - Directory Browsing — позволяет пользователям видеть содержимое каталога на веб-сервере. Используйте Directory Browsing для того, чтобы автоматически сгенерировать список всех каталогов и файлов, имеющихся в каталоге, когда пользователи не указывают файл в URL-адресе и индексная страница отключена или не настроена
  - HTTP Errors — позволяет настроить сообщения об ошибках, возвращаемых клиентам в браузере.
  - Static Content — позволяет размещать статический контент, например, картинки или html-файлы.
  - HTTP Redirection — обеспечивает поддержку перенаправления запросов пользователей.
  - WebDAV Publishing позволяет публиковать файлы с веб-сервера с помощью протокола HTTP.
  - HTTP Logging обеспечивает ведение журнала активности веб-сайта для данного сервера.
  - Custom Logging обеспечивает поддержку создания кастомных логов, которые отличаются от “традиционных” журналов.
  - Logging Tools обеспечивает инфраструктуру для управления журналами веб-сервера и автоматизации общих задач ведения журнала.
  - ODBC Logging обеспечивает инфраструктуру, которая поддерживает ведение журнала активности веб-сервера в ODBC-совместимой базе данных.
  - Request Monitor предоставляет инфраструктуру для мониторинга состояния веб-приложений путем сбора информации о HTTP-запросах в рабочем процессе IIS.
  - Tracing предоставляет инфраструктуру для диагностики и устранения неполадок веб-приложений. При использовании трассировки неудачных запросов, вы можете отследить трудно-фиксируемые события, такие как плохая производительность или сбои аутентификации.
  - Static Content Compression предоставляет инфраструктуру для настройки HTTP-сжатия статического содержимого
  - Dynamic Content Compression предоставляет инфраструктуру для настройки HTTP-сжатия динамического содержимого.
  - Request Filtering позволяет фиксировать все входящие запросы и фильтровать их на основании правил, установленных администратором.
  - Basic Authentication позволяет установить дополнительную авторизацию
  - Centralized SSL Certificate Support это функция, которая позволяет хранить сертификаты в централизованном месте, как общий файловый ресурс.
  - Client Certificate Mapping Authentication использует клиентские сертификаты для аутентификации пользователей.
  - Digest Authentication работает путем отправки хэша пароля в контроллер домена Windows, для аутентификации пользователей. Если вам необходимо более высокий уровень безопасности по сравнению с обычной проверкой подлинности, рассмотрите вопрос об использовании проверки подлинности Digest
  - IIS Client Certificate Mapping Authentication использует клиентские сертификаты для аутентификации пользователей. Сертификат клиента представляет собой цифровой ID, полученный из надежного источника.
  - IP and Domain Restrictions позволяет разрешать/запрещать доступ на основе запрашиваемого Ip-адреса или доменного имени.
  - URL Authorization позволяет создавать правила, ограничивающие доступ к веб-контенту.
  - Windows Authentication Эта схема аутентификации позволяет администраторам домена Windows пользоваться преимуществами доменной инфраструктуры для аутентификации пользователей.
  - FTP Service Включает FTP публикации на веб-сервере.
  - FTP Extensibility Включает поддержку FTP функций, расширяющих возможности
  - IIS Management Console устанавливает диспетчер IIS, который позволяет управлять Веб-сервером через графический интерфейс
  - IIS 6.0 Management Compatibility обеспечивает прямую совместимость для приложений и сценариев, которые используют Admin Base Object (ABO) и интерфейса службы каталогов (ADSI) API Active Directory. Это позволяет использовать существующие сценарии IIS 6.0 веб-сервером IIS 8.0
  - IIS Management Scripts and Tools предоставляют инфраструктуру для управления веб-сервером IIS программно, с помощью команд в окне командной строки или с помощью запуска сценариев.
  - Management Service предоставляет инфраструктуру для настройки интерфейса пользователя, диспетчера IIS.
  Подробное описание RDS
  - Remote Desktop Connection Broker — Обеспечивает повторное подключение клиентского устройства к программам, на основе сеансов настольных компьютеров и виртуальных рабочих столов.
  - Remote Desktop Gateway — Позволяет авторизованным пользователям подключаться к виртуальным рабочим столам, программам RemoteApp и основанных на сессиях рабочим столам в корпоративной сети или через Интернет.
  - Remote Desktop Licensing — Средство управления лицензиями RDP
  - Remote Desktop Session Host — Включает сервер для размещения программ RemoteApp или сеанса на основе рабочих столов.
  - Remote Desktop Virtualization Host — позволяет настраивать RDP на виртуальных машинах
  - Remote Desktop WebAccess — Позволяет пользователям подключаться к ресурсам рабочего стола с помощью меню Пуск или веб-браузера.
  Рассмотрим установку и настройку сервера терминальных лицензий. Выше рассказано как устанавливать роли, установка RDS не отличается от установки других ролей, в Role Services нам потребуется выбрать Remote Desktop Licensing и Remote Desktop Session Host. После установки в Server Manager-Tools появится пункт Terminal Services. В Terminal Services есть два пункта RD Licensing Diagnoser, это средство диагностики работы лицензирования удаленных рабочих столов, и Remote Desktop Licensing Manager, это средство управления лицензиями.
  
  Запустим RD Licensing Diagnoser
  
  Здесь мы видим, что доступных лицензий пока нет, т. к. не задан режим лицензирования для сервера узла сеансов удаленных рабочих столов. Сервер лицензирования указывается в локальных групповых политиках. Для запуска редактора выполним команду gpedit.msc. Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:
  - «Конфигурация компьютера» (Computer Configuration)
  - «Административные шаблоны» (Administrative Templates)
  - «Компоненты Windows» (Windows Components)
  - «Службы удаленных рабочих столов» (Remote Desktop Services)
  - «Узел сеансов удаленных рабочих столов» (Remote Desktop Session Host)
  - «Лицензирование» (Licensing)
  Откроем параметры Use the specified Remote Desktop license servers
  
  В окне редактирования параметров политики включаем сервер лицензирования (Enabled) . Затем необходимо определить сервер лицензирования для службы удаленных рабочих столов. В моем примере сервер лицензирования находится на этом же физическом сервере. Указываем сетевое имя или IP-адрес сервера лицензий и нажимаем OK. Если в дальнейшем будет изменяться имя сервера, сервер лицензий, то потребуется изменить в этом же разделе.
  
  После этого в RD Licensing Diagnoser можно увидеть, что сервер терминальных лицензий настроен, но не включен. Для включения запускаем Remote Desktop Licensing Manager
  
  Выбираем сервер лицензирования, со статусом Not Activated . Для активации кликаем по нему правой кнопкой мыши и выбираем Activate Server. Запустится Мастер активации сервера. На вкладке Connection Method выбираем Automatic Connection. Далее заполняем информация об организации, после этого сервер лицензий активирован.
  
  Active Directory Certificate Services
  
  Службы AD CS предоставляют настраиваемые услуги по выдаче цифровых сертификатов, которые используются в системах безопасности ПО, применяющих технологии открытых ключей, и по управлению этими сертификатами. Цифровые сертификаты, предоставляемые AD CS, можно использовать для шифрования и цифрового подписывания электронных документов и сообщений.Эти цифровые сертификаты можно использовать для проверки в сети подлинности учетных записей компьютеров, пользователей и устройств.Цифровые сертификаты используются для обеспечения:
  - конфиденциальности с помощью шифрования;
  - целостности с помощью цифровых подписей;
  - проверки подлинности с помощью привязывания ключей сертификата к учетным записям компьютеров, пользователей и устройств в сети.
  AD CS можно использовать для повышения безопасности путем привязки удостоверения пользователя, устройства или службы к соответствующему закрытому ключу. В число применений, поддерживаемых AD CS, входят безопасные многоцелевые расширения стандарта почты Интернета (S/MIME), защищенные беспроводные сети, виртуальные частные сети (VPN), протокол IPsec, шифрованная файловая система (EFS), вход с помощью смарт-карт, протокол безопасности передачи данных и протокол безопасности транспортного уровня (SSL/TLS) и цифровые подписи.
  
  Active Directory Domain Services
  
  Используя роль сервера доменных служб Active Directory (AD DS), можно создать масштабируемую, безопасную и управляемую инфраструктуру для управления пользователями и ресурсами; кроме того, можно обеспечить работу приложений, поддерживающих каталоги, например Microsoft Exchange Server. Доменные службы Active Directory предоставляют распределенную базу данных, в которой хранятся сведения о сетевых ресурсах и данные приложений с поддержкой каталогов, а также осуществляется управление этой информацией. Сервер, на котором выполняются AD DS, называется контроллером домена. Администраторы могут использовать AD DS для упорядочения в иерархическую вложенную структуру таких элементов сети, как пользователи, компьютеры и другие устройства. Иерархическая вложенная структура включает лес Active Directory, домены в лесу и организационные подразделения в каждом домене. Средства безопасности интегрированы в AD DS в виде проверки подлинности и контроля доступа к ресурсам в каталоге. С помощью единого входа в сеть администраторы могут управлять по сети данными каталога и организацией. Авторизованные пользователи сети также могут использовать единый вход в сеть для доступа к ресурсам, расположенным в любом месте сети. Доменные службы Active Directory предоставляют следующие дополнительные возможности.
  - Набор правил — схема, определяющая классы объектов и атрибуты, которые содержатся в каталоге, ограничения и пределы для экземпляров этих объектов, а также формат их имен.
  - Глобальный каталог, содержащий сведения о каждом объекте в каталоге. Пользователи и администраторы могут использовать глобальный каталог для поиска данных каталога независимо от того, какой домен в каталоге действительно содержит искомые данные.
  - Механизм запросов и индексирования, благодаря которому объекты и их свойства могут публиковаться и находиться сетевыми пользователями и приложениями.
  - Служба репликации, которая распределяет данные каталога по сети. Все контроллеры домена, доступные для записи в домене, участвуют в репликации и содержат полную копию всех данных каталога для своего домена. Любые изменения данных каталога реплицируются в домене на все контроллеры домена.
  - Роли хозяев операций (известные также как гибкие операции с единым хозяином, или FSMO). Контроллеры доменов, исполняющие роли хозяев операций, предназначены для выполнения специальных задач по обеспечению согласованности данных и исключению конфликтующих записей в каталоге.
  Active Directory Federation Services
  
  AD FS предоставляют конечным пользователям, которым требуется доступ к приложениям на защищенном с помощью AD FS предприятии, в партнерских организациях федерации или в облаке, возможности упрощенной и безопасной федерации удостоверений и веб-службы единого входа (SSO) В Windows Server AD FS включают службу роли службы федерации, действующую в качестве поставщика удостоверений (выполняет проверку подлинности пользователей для предоставления маркеров безопасности для приложений, доверяющих AD FS) или в качестве поставщика федерации (применяет маркеры от других поставщиков удостоверений и затем предоставляет маркеры безопасности для приложений, доверяющих AD FS).
  
  Active Directory Lightweight Directory Services
  
  Службы Active Directory облегченного доступа к каталогам (AD LDS) — это протокол LDAP, который обеспечивает гибкую поддержку приложений, работающих с каталогами, без зависимостей и связанных с доменами ограничений доменных служб Active Directory. AD LDS можно запускать на рядовых или изолированных серверах. На одном сервере можно запустить несколько экземпляров AD LDS с независимо управляемыми схемами. С помощью роли службы AD LDS можно предоставить службы каталогов для приложений с поддержкой каталогов, не используя служебные данные доменов и лесов и не требуя единой схемы для всего леса.
  
  Active Directory Rights Management Services
  
  Службы AD RMS можно использовать, чтобы расширить стратегию безопасности в организации, обеспечив защиту документов с помощью управления правами на доступ к данным (IRM). AD RMS позволяет пользователям и администраторам назначать разрешения доступа к документам, рабочим книгам и презентациям с помощью политик IRM. Это позволяет защитить конфиденциальную информацию от печати, пересылки или копирования пользователями, не имеющими на это прав. После того как разрешения для файла ограничены с помощью IRM, ограничения доступа и использования применяются независимо от местоположения информации, так как разрешение для файла хранится в самом файле документа. С помощью AD RMS и IRM отдельные пользователи могут применять свои личные настройки, касающиеся передачи личных и конфиденциальных сведений. Они также помогут организации применять корпоративную политику для управления использованием и распространением конфиденциальных и личных сведений. Решения IRM, поддерживаемые службами AD RMS, используются для обеспечения следующих возможностей.
  - Постоянные политики использования, которые остаются с информацией независимо от ее перемещения, отправки или пересылки.
  - Дополнительный уровень конфиденциальности для защиты конфиденциальных данных — например, отчетов, спецификаций продуктов, сведений о клиентах и сообщений электронной почты — от намеренного или случайного попадания в чужие руки.
  - Предотвращение несанкционированной пересылки, копирования, изменения, печати, передачи по факсу или вставки ограничиваемого содержимого авторизованными получателями.
  - Предотвращение копирования ограничиваемого содержимого с помощью функции PRINT SCREEN в Microsoft Windows.
  - Поддержка срока действия файла, предотвращающего просмотр содержимого документов по истечении заданного периода времени.
  - Внедрение корпоративных политик, управляющих использованием и распространением содержимого в организации
  Application Server
  
  Сервер приложений предоставляет интегрированную среду для развертывания и выполнения пользовательских бизнес-приложений на базе сервера.
  
  DHCP Server
  
  DHCP — это технология «клиент-сервер», с помощью которой DHCP-серверы могут назначать или сдавать в аренду IP-адреса компьютерам и другим устройствам, являющимся DHCP-клиентами.Развертывание в сети DHCP-серверов обеспечивает автоматическое предоставление клиентским компьютерам и другим сетевым устройствам на базе IPv4 и IPv6 действительных IP-адресов и дополнительных конфигурационных параметров, необходимых данным клиентам и устройствам.Служба DHCP-сервера в Windows Server включает поддержку основанных на политике назначений и обработку отказов протокола DHCP.
  
  DNS Server
  
  Служба DNS — это иерархическая распределенная база данных, содержащая сопоставления доменных имен DNS с различными типами данных, таких как IP-адреса. Служба DNS позволяет использовать понятные имена, такие как www.microsoft.com, для облегчения нахождения компьютеров и других ресурсов в сетях, работающих на базе протокола TCP/IP. Служба DNS в Windows Server обеспечивает дополнительную улучшенную поддержку Модулей безопасности DNS (DNSSEC), включая регистрацию в сети и автоматизированное управление параметрами.
  
  FAX Server
  
  Факс-сервер отправляет и получает факсы, а также дает возможность управлять ресурсами факса, такими как задания, настройки, отчеты и факс-устройства на вашем факс-сервере.
  
  File and Storage Services
  
  Администраторы могут использовать роль «Файловые службы и службы хранилища» для настройки нескольких файловых серверов и их хранилищ, а также для управления этими серверами с помощью диспетчера серверов или Windows PowerShell. Некоторые конкретные приложения включают следующие функции.
  - Рабочие папки. Использовать, чтобы разрешить пользователям хранение рабочих файлов и доступ к ним на личных компьютерах и устройствах помимо корпоративных ПК. Пользователи получают удобное место для хранения рабочих файлов и доступа к ним из любого места. Организации контролируют корпоративные данные, храня файлы на централизованно управляемых файловых серверах и при необходимости задавая политики устройств пользователей (такие как шифрование и пароли блокировки экрана).
  - Дедупликация данных. Использовать для снижения требований к месту на диске для хранения файлов, экономя средства на хранилище.
  - Сервер цели iSCSI. Использовать для создания централизованных, программных и аппаратно-независимых дисковых подсистем iSCSI в сетях хранения данных (SAN).
  - Дисковые пространства. Использовать для развертывания хранилища с высоким уровнем доступности, отказоустойчивого и масштабируемого за счет применения экономичных стандартизованных в отрасли дисков.
  - Диспетчер серверов. Использовать для удаленного управления несколькими файловыми серверами из одного окна.
  - Windows PowerShell. Использовать для автоматизации управления большинством задач администрирования файловых серверов.
  Hyper-V
  
  Роль Hyper-V позволяет создавать виртуализованную вычислительную среду с помощью технологии виртуализации, встроенной в Windows Server, и управлять ею. При установке роли Hyper-V выполняется установка необходимых компонентов, а также необязательных средств управления. В число необходимых компонентов входят низкоуровневая оболочка Windows, служба управления виртуальными машинами Hyper-V, поставщик виртуализации WMI и компоненты виртуализации, такие как шина VMbus, поставщик службы виртуализации (VSP) и драйвер виртуальной инфраструктуры (VID).
  
  Network Policy and Access Services
  
  Службы сетевой политики и доступа предоставляют следующие решения для сетевых подключений:
  - Защита доступа к сети — это технология создания, принудительного применения и исправления политик работоспособности клиента. С помощью защиты доступа к сети системные администраторы могут устанавливать и автоматически применять политики работоспособности, которые включают в себя требования к программному обеспечению, обновлениям для системы безопасности и другие параметры. Для клиентских компьютеров, не соответствующих требованиям политики работоспособности, можно ограничить доступ к сети до тех пор, пока их конфигурация не будет обновлена в соответствии с требованиями политики.
  - Если развернуты точки беспроводного доступа с поддержкой 802.1X, вы можете использовать сервер политики сети (NPS) для развертывания методов аутентификации на основе сертификатов, которые более безопасны, чем аутентификация на основе паролей. Развертывание оборудования с поддержкой 802.1X с сервером NPS позволяет обеспечить аутентификацию пользователей интрасети до того, как они смогут подключиться к сети или получить IP-адрес от DHCP-сервера.
  - Вместо того чтобы настраивать политику доступа к сети на каждом сервере доступа к сети, можно централизованно создать все политики, в которых будут определены все аспекты запросов на сетевое подключение (кто может подключаться, когда разрешено подключение, уровень безопасности, который необходимо использовать для подключения к сети).
  Print and Document Services
  
  Службы печати и документов позволяют централизовать задачи сервера печати и сетевого принтера. Эта роль также позволяет получать отсканированные документы с сетевых сканеров и передавать документы в общие сетевые ресурсы — на сайт Windows SharePoint Services или по электронной почте.
  
  Remote Access
  
  Роль сервера удаленного доступа представляет собой логическую группу следующих технологий сетевого доступа.
  - DirectAccess
  - Маршрутизация и удаленный доступ
  - Прокси-сервер веб-приложения
  Эти технологии являются службами ролей роли сервера удаленного доступа. При установке роли сервера удаленного доступа можно установить одну или несколько служб ролей, запустив мастер добавления ролей и компонентов.
  
  В Windows Server роль сервера удаленного доступа обеспечивает возможность централизованного администрирования, настройки и наблюдения за службами удаленного доступа DirectAccess и VPN со службой маршрутизации и удаленного доступа (RRAS). DirectAccess и RRAS можно развернуть на одном пограничном сервере и управлять ими с помощью команд Windows PowerShell и консоли управления (MMC) удаленного доступа.
  
  Remote Desktop Services
  
  Службы удаленных рабочих столов ускоряют и расширяют развертывание рабочих столов и приложений на любом устройстве, повышая эффективность удаленного работника, одновременно обеспечивая безопасность критически важной интеллектуальной собственности и упрощая соответствие нормативным требованиям. Службы удаленных рабочих столов включают инфраструктуру виртуальных рабочих столов (VDI), рабочие столы на основе сеансов и приложения, предоставляя пользователям возможность работать в любом месте.
  
  Volume Activation Services
  
  Службы активации корпоративных лицензий — это роль сервера в Windows Server начиная с Windows Server 2012, которая позволяет автоматизировать и упростить выдачу корпоративных лицензий на программное обеспечение Microsoft, а также управление такими лицензиями в различных сценариях и средах. Вместе со службами активации корпоративных лицензий можно установить и настроить службу управления ключами (KMS) и активацию с помощью Active Directory.
  
  Web Server (IIS)
  
  Роль веб-сервера (IIS) в Windows Server обеспечивает платформу для размещения веб-узлов, служб и приложений. Использование веб-сервера обеспечивает доступ к информации пользователям в Интернете, интрасети и экстрасети. Администраторы могут использовать роль веб-сервера (IIS) для настройки и управления несколькими веб-сайтами, веб-приложениями и FTP-сайтами. В число специальных возможностей входят следующие.
  - Использование диспетчера служб IIS для настройки компонентов IIS и администрирования веб-сайтов.
  - Использование протокола FTP для разрешения владельцам веб-сайтов отправлять и загружать файлы.
  - Использование изоляции веб-сайтов для предотвращения влияния одного веб-сайта на сервере на остальные.
  - Настройка веб-приложений, разработанных с использованием различных технологий, таких как Classic ASP, ASP.NET и PHP.
  - Использование Windows PowerShell для автоматического управления большей частью задач администрирования веб-сервера.
  - Объединение нескольких веб-серверов в ферму серверов, которой можно управлять с помощью IIS.
  Windows Deployment Services
  
  Службы развертывания Windows позволяют развертывать операционные системы Windows по сети, что означает возможность не устанавливать каждую операционную систему непосредственно с компакт-диска или DVD-диска.
  
  Windows Server Essentials Experience
  
  Данная роль позволяет решать следующие задачи:
  - защищать данные сервера и клиентов, создавая резервные копии сервера и всех клиентских компьютеров в сети;
  - управлять пользователями и группами пользователей через упрощенную панель мониторинга сервера. Кроме того, интеграция с Windows Azure Active Directory *обеспечивает пользователям простой доступ к интернет-службам Microsoft Online Services (например, Office 365, Exchange Online и SharePoint Online) с помощью их учетных данных домена;
  - хранить данные компании в централизованном месте;
  - интегрировать сервер с интернет-службами Microsoft Online Services (например, Office 365, Exchange Online, SharePoint Online и Windows Intune):
  - использовать на сервере функции повсеместного доступа (например, удаленный веб-доступ и виртуальные частные сети) для доступа к серверу, компьютерам сети и данным из удаленных расположений с высокой степенью безопасности;
  - получать доступ к данным из любого места и с любого устройства с помощью собственного веб-портала организации (посредством удаленного веб-доступа);
  - управлять мобильными устройствами, с которых осуществляется доступ к электронной почте организации с помощью Office 365 посредством протокола Active Sync, из панели мониторинга;
  - отслеживать работоспособность сети и получать настраиваемые отчеты о работоспособности; отчеты можно создавать по требованию, настраивать и отправлять по электронной почте определенным получателям.
  Windows Server Update Services
  
  Сервер WSUS предоставляет компоненты, которые необходимы администраторам для управления обновлениями и их распространения через консоль управления. Кроме того, сервер WSUS может быть источником обновлений для других серверов WSUS в организации. При реализации служб WSUS хотя бы один сервер служб WSUS в сети должен быть подключен к Центру обновления Майкрософт для получения информации о доступных обновлениях. В зависимости от безопасности сети и ее конфигурации администратор может определить, сколько других серверов напрямую подключено к Центру обновления Майкрософт.
  
  Сервер приложений — не пуп Земли?
  
  Итак, начнем по порядку, чтобы и не столь искушенный читатель понял, что имеется в виду. Предмет наших размышлений — это Application Server или Сервер Приложений. Ныне модно в качестве предисловия давать рекламу наоборот — перечислять то, чего в написанном нет; то ли из ложной скромности, то ли следуя завету Микеланджело: убирать все лишнее. Поэтому вы не найдете в этой статье серьезного доказательного сравнения технических реализаций Серверов Приложений, описания методов и приемов работы с этими реализациями, примеров файлов, листингов и кусков кода — приведен лишь список источников, в которых можно все это отыскать. Здесь же займемся более общими, но не менее увлекательными вопросами — что такое Сервер Приложений, зачем это нужно, как это покупать и выбирать и как с этим работать. Предвижу недовольство читателей, которые убеждены в том, что их не пускают на «кухню» и, следовательно, в приготовленном кушанье будет намешано неизвестно что. Приведу краткие соображения, почему следует читать и писать не только сугубо технические статьи. Прежде чем готовить еду, надо определить что — суп или гарнир, легкий ужин или обед для званых гостей, надо составить меню, заготовить продукты, выработать план изготовления, а уже потом приступать к поварскому ритуалу. Какой этап важнее — на этот предмет существует известная сказка, в которой плотник, портной и кукольник спорят, кому должна принадлежать сделанная ими кукла. Насколько я помню, в сказке побеждал кукольник, поскольку именно он вдохнул в куклу жизнь. В этом смысле таким волшебником несомненно является программист-разработчик. Нимало не преуменьшая его роль, я все-таки замечу, что современные программные приложения всегда плод коллективной работы. Поэтому провал или даже неудовлетворительное выполнение любого промежуточного этапа могут безнадежно загубить все дело.
  
  Но, довольно реверансов. Нас ждет Сервер Приложений, которому просто не терпится убедить вас в том, что без него не обойтись.
  
  Как ни грустно опять обращаться к знакомой всем заинтересованным лицам истории компьютерных технологий, без этого Сервер Приложений предстанет перед нами бродягой без роду и племени. Но я постараюсь быть краткой, тем более что истории то всего лет 50, правда, очень стремительных. Основные этапы этой истории приведены на рис. 1.
  
  Рис.1. Развитие прикладной архитектуры компьютерных систем
  
  Первая эра — эра эксклюзивного «монолита», когда компьютерные программы, или потом, пакеты программ, выполнялись на одном компьютере. Особого выбора у потенциальных потребителей программных продуктов тогда не было — или сам разрабатывай, или заказывай у опытных людей. Тогдашние операционные системы не баловали богатством возможностей — работает приложение на компьютере — и хорошо. Оно могло работать годами, выполняя раз навсегда закрепленные функции, и все были довольны. Это время часто называют и «эрой мэйнфреймов», хотя именно мэйнфреймы подошли вплотную к «тихой революции». От них появилась возможность приставить к одному серверу несколько «глаз» — терминалов, которые позволили плавно перейти в «клиент-серверную эру». Вот тут то и появляется служака «сервер». Сервер работает, служит, выполняя задания его величества клиента. Клиент от простенького «застенчивого» терминала вырастает до важного и значительного повелителя. Нынешний революционный момент характеризуется тем, что серверы не могут, а клиенты не хотят существовать по-старому. Первые не могут справиться с обилием поставленных перед ними требований, а вторые недовольны качеством обслуживания их запросов. Выход — в дальнейшей специализации. То, что пыхтя и отдуваясь выполняет несчастный сервер, теперь будет распределено на множество серверков — компонентов, каждый из которых успешно выполняет свою функцию. В такой компании клиенты превращаются в равноправные компоненты, чья задача — представительство функциональных сотоварищей (других компонентов) для пользователя, сидящего перед дисплеем.
  
  Раз уж мы ввели строительный термин — монолит, то приведем строительно-архитектурную параллель. Первая — монолитная эра, эра дольменов и кромлехов, отдельных решений, автоматизирующих конкретные производственные задачи заказчика. Опыта еще мало — каждое сооружение в некотором смысле произведение искусства. Вторая эра — однотипные поселения, каждое их которых характеризуется зaмком (сервером) и постройками попроще вокруг (клиентами). И если простые постройки не представляют большой архитектурной ценности, то замки — решения штучные и дорогостоящие. А переходим мы в эру массовой застройки, когда «строительство» программных приложений поставлено на поток. И сколько бы мы ни ругали такую застройку, именно этот способ позволяет обеспечить жильем — программными приложениями, всех желающих за разумную цену и в реальные сроки.
  
  Типовые современные дома обычно строятся из блоков или панелей. Так и современные программные приложения строятся или, скорее, будут строиться из компонентов. (Компонент — самостоятельный программный продукт, поддерживающий объектную парадигму, реализующий отдельную область бизнес-логики и умеющий взаимодействовать с другими компонентами с помощью открытых интерфейсов.) Такая технология позволит ответить на самые острые проблемы компьютерного мира — сокращение времени разработки программного приложения, облегчение процесса внедрения и поддержка гибкости внедренного решения. На рис. 2 изображены этапы жизненного цикла программного приложения.
  
  Рис. 2. Жизненный цикл информационных систем
  
  Нынешняя практика, когда серьезное приложение разрабатывается минимум за два года, невыгодна ни разработчикам, ни потребителям. Первые производят устаревшие до реализации, невостребованные программные продукты, а вторые не успевают насладиться плодами автоматизации, получить отдачу от вложений и затрат. Не успели дом поставить — как выясняется, что он не отвечает современным нормам, жильцы в нем жить не хотят, и он только занимает место, которое можно употребить на постройку нового современного дома.
  
  Под лозунгом «Быстрее, легче и гибче» и создаются современные бизнес-компоненты. Преимущества подобного подхода можно выразить в длинном списке: масштабируемость, стабильность, управляемость, настраиваемость, гибкость, переносимость, возможность многократного использования. Но, к сожалению, чудес в жизни не бывает и, если сложностей и неурядиц убыло в одном месте, то в другом они как раз прибавились. Для того чтобы компоненты умели взаимодействовать, необходимо развитие «клея» — промежуточного программного слоя.
  
  Итак, если со стороны бизнеса все красиво, как на затейливом персидском ковре, то зато на изнанке — уйма всяких узелков и зацепок. Последние годы мировое программное сообщество усиленно пытается внести порядок в эту изнанку, в чем, надо сказать весьма преуспело. Основная возможность здесь — стандартизация компонентов, приведение их к единой природе. Блоки здания должны быть сопрягаемы. Нити ковра должны быть из близких материалов. Идея здесь достаточно проста — внешние интерфейсы компонентов должны быть описаны в едином стиле — на одном и том же языке. Поэтому два известных на сегодняшний день стандарта, CORBA и COM+ создали свои варианты IDL — Языка Описания Интерфейсов. CORBA, COM+ и технология Java, которая, естественно, использует для описания интерфейсов язык Java, предлагают близкие подходы к методу взаимодействия компонентов. На основе описания внешних интерфейсов создаются прокси (заместители) для клиента и сервера, которые позволяют им связываться друг с другом в реальном времени. Прокси для клиента принято называть стабом, а прокси для сервера — скелетоном. (Мы договорились — я не претендую на изложение технологий, а только даю краткий взгляд на них. Поэтому, в частности, не касаюсь возможностей динамического взаимодействия компонентов в технологии CORBA, когда внешние интерфейсы не определены на момент компиляции системы и появляются дополнительные динамические элементы.)
  
  После стандартизации интерфейсов, мировое компьютерное сообщество перешло на следующий уровень стандартизации — самих компонентов. Из рис. 3 понятно, что я имею в виду под следующим уровнем стандартизации — все дальше от «железа», все ближе — к пользователю. В технологии CORBA это:
  
  Рис. 3. Стандарты в программных приложениях
  - ССМ (CORBA Component Model)- компонентная объектная модель, компонентное развитие модели бизнеса ВОМ — Business Object Model;
  - BOCA (Business Object Component Architecture) — принципы архитектуры компонентных систем, развитие OMA (Object Management Architecture) на вышележащий уровень стандартизации;
  - CDL (Component Definition Language)- язык определения компонентов, развитие IDL.
  Разработка этих стандартов продвигается, правда, не так быстро, как хотелось бы всем заинтересованным сторонам. Но признанным героем на поле стандартизации компонентов стала технология компании Sun — Enterprise Java Beans (EJB). Возможно причина ее успеха в том, что в «семейном кругу» одного языка программирования намного проще решить вопросы взаимодействия. Тем более языка молодого и резвого, который многие проблемы, такие как вызов удаленных методов (RMI — Remote Method Invocation), умеет решать сам. Не иcключено, что универсальные цели консорциума OMG, развивающего технологию CORBA, — объединить компоненты, написанные на разных языках программирования, функционирующие на разных системах и разных компьютерах в разных точках земного шара, являются в данном случае некоторым тормозом. В дальнейшем мы увидим как две технологии, сомкнувшись, отбросив амбиции, дают замечательный результат на радость всем заинтересованным сторонам.
  
  Что же такое этот «бин» (beаn — боб) и почему, стремительно выскочив как джин из бутылки в компьютерный мир, он уже завоевал такую популярность? Если перевести определение Sun как можно ближе к оригиналу — то «это модель для создания и развертывания серверных компонентов многократного использования, написанных на языке Java.» Продолжим вместе с Sun расплетать косу этого определения, — «компоненты — это заранее разработанные куски программного кода, которые могут быть установлены в работающие прикладные системы». Если классы Java образуют компонентную модель для проектирования приложений в технологии Java, то Java Beans логически развивает эту модель на следующем уровне интеграции создания автоматизированных систем и абстрагирования от процесса программирования — стадии внедрения. По сути, это переход от разработки приложения под заказ из готовых программных компонентов к сборке из готовых ЕJB действующих компонентов. Если раньше дома складывали из кирпичей, то теперь — из комнат-секций. Cлово Enterprise в названии Enterprise Java Beans означает новую ступень технических задач, стоящих перед программными приложениями. Такие задачи привычны для приложений уровня Предприятия: поддержка распределенности, службы именования, транзакций, безопасности, уведомлений-сообщений, долговременного хранения, и т.д. Неудивительно, что этот список напоминает список Служб технологии CORBA.
  
  С точки зрения разработки, EJB представляют собой Java-классы специального типа вместе с описателем-паспортом бина и параметрами среды функционирования, которые бин умеет обрабатывать. Описатель бина (Deployment Descriptor) в свою очередь представляет собой XML-файл, в котором содержатся правила, связанные с управлением бином, например, права доступа пользователей к бину. Несколько бинов могут объединяться, образуя приложения, Java-апплеты и новые бины.
  
  Рис. 4. Контейнер Enterprise Java Beans
  
  По технологии EJB бобы-бины размещаются в стручке — контейнере (рис. 4) На контейнер возложены обязанности по защите бинов и поддержке их взаимоотношений с внешним миром: регистрация-прописка объектов, обеспечение для них внешних интерфейсов, создание и разрушение реализаций этих объектов, охрана безопасности, управление их состояниями и координация транзакций. В технологии не определено, как конкретно должен быть реализован контейнер. Это могут быть как многопоточные процессы на отдельном сервере, в которых выполняются бины, так и законченные программные приложения, которые можно переносить или распределять между серверами и/или процессами. Клиентские бины обрабатываются внутри виртуальных контейнеров, таких как Web-страницы, формы, составные документы, и т.д.
  
  В технологии определены два основных типа бинов. Session Beans — сеансы клиент-серверного взаимодействия отрабатывают действия клиента, например, запись в базу данных, выполнение вычислений, и т.д. Это окна клиента в мир программных приложений. Они, в свою очередь, также бывают двух типов:
  - Stateless session — не умеют сохранять свое состояние и существуют только на протяжении текущего сеанса. В случае сбоя сеанс не может быть восстановлен;
  - Stateful session — сохраняют свое состояние; сеанс может быть восстановлен.
  Entity Bean — компоненты объектного представления данных, размещаемых в хранилище. Entity Bean транзакционны и восстанавливаемы. Каждая их реализация имеет уникальную метку, называемую «первичным ключом» (Primary Key) по аналогии с таблицами баз данных. В свою очередь эти бины делятся на две группы по способу определения где, в каком хранилище и как хранятся данные:
  - Bean-Managed Persistence — самостоятельные бины, управление хранением осуществляется на уровне бинов;
  - Container-Managed Persistence — «опекаемые» бины, чьим хранением заправляет контейнер.
  Кроме класса, реализующего функциональность бина, в него входят два обязательных класса, реализующие два типа интерфейсов:
  - Home Interface — доступ к «домашним» службам бина, таким как начало или отбой для Session Bean или поиск Entity Bean. Этот интерфейс реализует все службы жизненного цикла компонента и позволяет контейнеру управлять и руководить его поведением;
  - Remote Interface — доступ к бизнес-службам бина.
  Клиентские приложения общаются с бинами через контейнер, который открывает наружу оба интерфейса бина: Home и Remote. С помощью первого открывается сеанс или находится нужный бин, а с помощью второго — осуществляется отработка действий клиента в Session или транзакционная механика обработки Entity.
  
  Итак, повторим идею технологии с прикладной точки зрения. Прикладная бизнес-логика приложения делится на изолированные бизнес-объекты, каждый из которых реализуется в виде EJB. Они устанавливаются на Сервере Приложений или EJB Сервере и реализуют запрашиваемую логику для клиента (локального или удаленного). Давайте прямо сейчас, при первом появлении понятия Сервер Приложений в технологии Java, развеем непонимание, о котором уже говорилось в начале статьи. Написав оба слова, составляющие понятие, с заглавных букв, мы магическим образом преобразовали сервер приложений, реальную машину из корпуса, начинки и кабелей, в программное приложение.
  
  Обратимся вновь к интерпретации Sun. Под Сервером Приложений в технологии Java понимается программное приложение, обеспечивающее оптимальную среду для выполнения EJB. Сервер Приложений занимается «коммунальным хозяйством» дома — программной системы. На его руках надзор за системными ресурсами, такими как процессы, потоки, память, связь с базами данных, сетевые отношения, выравнивание загрузки распределенных узлов. Кроме этого важнейшая обязанность Сервера Приложений заключается в предоставлении cle;, компонентам.
  
  Еще раз хочу подчеркнуть, что технология EJB, впрочем, как и технология CORBA не предоставляет готовые программные решения — контейнеры, Сервера Приложений, а только стандарты на такой тип программного обеспечения.
  
  Стандарты — единственная возможность обеспечить некоторый порядок в бурно развивающемся компьютерном мире. Стандарты необходимы всем трем заинтересованным сторонам в области информационных технологий: разработчикам, потребителям-заказчикам и промежуточному звену — консультантам, интеграторам, продавцам. Первым — для поcтавки на рынок конкурентоспособных, жизнестойких решений, вторым — как средство борьбы с «зоопарком» программных систем, третьим — как возможность строить гибкие, интегрированные программные среды для своих заказчиков.
  
  Стандарты продолжают захватывать все новые области информационных технологий. Но, если в сетевых технологиях стандарты полностью прижились, то в области программных приложений они еще только набирают силу. Понятны опасения специалистов использовать в собственных решениях «неправильный» стандарт, который зачастую, невзирая на грамотные технические решения, заложенные в его основу, не идет дальше прекрасных инициатив и не получает развития. Выбирая дорогу, всегда есть опасность оказаться в тупике. Именно поэтому стоит внимательно читать указатели (в смысле дорожные знаки) и прислушиваться к мнению мирового сообщества. Серверы Приложений уже сейчас имеют реализации от большинства крупных производителей программных систем (компании Inprise, Oracle, Sybase, Sun, BEA, Iona, IBM). Кроме того, в данной области архитектуры программных приложений пока не появилось ни одного достойного конкурента. Так что стиль пока единственный — Сервер Приложений.
  
  Если посмотреть на Серверы Приложений глазами конечного пользователя, то они представляют собой основные несущие конструкции сооружения под названием многозвенная распределенная компонентная программная система. Именно Серверы Приложений поставляют бизнес-компоненты и обеспечивают необходимый уровень системных служб для этих компонентов, т.е. всю коммунальную систему жизнеобеспечения. Приложения, которые наш Сервер предоставляет клиентам, могут располагаться где угодно, причем эти приложения могут даже не знать, где хранятся данные, с которыми они работают — на каком сервере и в какой базе данных. Для клиентов Сервер Приложений открывает и закрывает сеансы. Для приложений — позволяет настраивать системные службы, из которых важнейшими являются служба долговременного хранения, политика хранения компонентоа Entity Beans, служба транзакций и служба безопасности.
  
  «А надо ли городить огород?, — спросит недоверчивый читатель. — Зачем мне такое дополнительное ПО для моего сугубо конкретного программного приложения?»
  
  Огород, может быть, городить и не надо, а обеспечить газом, электричеством и горячей водой наш блочный дом, программное приложение — необходимо. Да и надежный кодовый замок на входной двери не помешает. Конечно, можно предоставить решать эти проблемы самим жильцам. Пусть каждый в одиночку кипятит воду и укрепляет входную дверь. Тогда уж лучше просто влезть на дерево (я никоим образом не имею в виду службу каталогов NDS) и кушать бананы (не путайте с Baan).
  
  Чтобы постройка программного приложения не напоминала возведение Вавилонской башни, в технологии EJB расписано, кто именно должен принимать участие в проекте. Комплексная бригада строителей здания состоит, по представлению компании Sun, из следующих профессионалов.
  
  Архитектор
  
  Поставщик серверной платформы (EJB Server Provider) — специалист в области распределенной платформы и служб. Он предоставляет инфраструктуру разработки и среду выполнения для программных приложений.
  
  Конструктор
  
  Поставщик контейнеров (EJB Container Provider) — эксперт в области распределенных систем, системной безопасности и поддержки транзакций. Он обеспечивает системный уровень контейнеров, то есть системную оболочку для одного или более компонентов — Enterprise Bean.
  
  Снабженец
  
  Поставщик бизнес-компонентов (Enterprise Bean Provider) — аналитик в функциональной области, который реализует бизнес-компоненты как разработчик или подбирает готовые.
  
  Монтажник
  
  Компоновщик Приложений (Application Assembler) — также эксперт-функционал, собирающий программное приложение из строительных блоков — бизнес-компонентов. Его взгляд на соответствующий бизнес должен быть более общим и универсальным, чем у Снабженца — Поставщика бизнес-компонентов.
  
  Прораб
  
  Внедренец (Deployer) — специализируется в установке приложений. Он настраивает приложение на реальную среду.
  
  Управдом
  
  Администратор системы (System Administrator) — обеспечивает работоспособность системы на этапе эксплуатации.
  
  Конечно, то, что компания Sun описала именно такие роли, не означает, что любой проект, связанный с Enterprise Java Beans обязательно требует одного и только одного указанного специалиста и именно такой состав комплексной бригады. Да и найти, скажем, готового поставщика контейнеров не так-то просто. Что совершенно необходимо — так это не упустить специфические для компонентного проекта моменты: выбор архитектуры и способы реализации системных служб, определение структуры и поведения контейнеров и проработка вопросов внедрения (развертывания).
  
  Завершив экскурс в EJB, можно привести определение Сервера Приложений «с большой буквы». Сервером Приложений называется программный продукт, поставляющий среду выполнения для прикладных компонентов, расположенный между клиентом — с одной стороны и данными и прикладными программами — с другой, который может обеспечить интеграцию различных источников данных и прикладных ресурсов и предоставить компонентам необходимые для них сервисы.
  
  Разочарованный читатель возмутится: «Зачем же нам объясняли про EJB, если в определении про них нет ни слова!» Попробую пояснить. Я намеренно привела универсальное определение Сервера Приложений, которое относится ко всем типам компонентов (CORBA, EJB, COM+). Серверы Приложений, зародившись внутри технологии EJB, оказались столь удобны, что достаточно уверенно продвигаются как единое решение для всех компонентных технологий. Реализации Серверов Приложений уже умеют работать с разными компонентами. В качестве примера приведу Application Server компании Inprise, который можно успешно использовать в среде компонентов EJB и CORBA. Другой наблюдаемый процесс — смыкание технологий Java и CORBA. С небольшой долей натяжки можно считать, что EJB могут иметь двойное гражданство, а именно представлять собой еще и CORBA-объекты. С моей точки зрения, поддержка CORBA является необходимым условием для конкурентности реализации Сервера Приложений. Ведь из всех перечисленных технологий только эта поддерживает Унаследованные Системы — функционально пригодные, но технически устаревшие. Если считать парк автоматизации современного предприятия или компании некоторым поселением — деревушкой или городком, создаваемая интеллектуальная компьютерная среда должна включать уже существующие постройки. Одинаково неправильно требовать сноса существующих зданий или не обращать на них внимания.
  
  Другой аспект выбора реализации Серверов Приложений заключается в функциональности, которая наиболее приоритетна. Попробуем разделить Серверы приложений на группы.
  
  1. Интеграционный Сервер Приложений. (Application -integration-centric application server)
  
  Основная задача такого Сервера — интеграция Бизнес-приложений в единую интеллектуальную среду. Такие Серверы особенно актуальны для организации приложений, связанных с задачами типа Supply Chain (Цепочки Поставщиков) и электронной коммерции. К таким серверам относятся реализации крупнейших поставщиков брокеров объектных запросов — компаний Inprise и Iona.
  
  2. Информационный Сервер Приложений (Data-centric application server)
  
  Деятельность такого сервера сконцентрирована на манипулировании данными. В качестве хранилищ могут выступать произвольные приложения, которые, в частности, не обязательно представляют собой реляционные базы данных и, уж тем, более объектные. Такие серверы берут на себя организацию представления распределенных данных, хранящихся в различных источниках, в объектной парадигме. Естественно, Oracle поставляет серверы именно такого типа.
  
  3. Обрабатывающий Сервер Приложений (Processing-centric application server)
  
  Центральной заботой таких серверов является обеспечение специфической бизнес-логики. Например, сервер, реализующий распределенные вычисления, или сервер ERP-системы. К таким реализациям относится IBM Websphere.
  
  4. Управляющий Сервер Приложений (Rules-based application server)
  
  Такие серверы являются подмножеством Обрабатывающих Серверов Приложений, но в отличие от них сконцентрированы на выполнении определенных бизнес-правил. Они ориентированы прежде всего на область электронной коммерции. Примером таких серверов является реализация от компании Vision Software.
  
  5. Сервер XML (XML Server)
  
  Этот сервер представляет собой подмножество Информационного сервера, с той лишь разницей, что в качестве хранилищ данных выступают XML — документы. С другой стороны, такой сервер может представлять собой подмножество Интеграционного сервера, в котором в качестве механизма интеграции выбран XML. Известна реализация такого сервера от компании Bluestone Software.
  
  Не следует думать, что разделение Серверов Приложений по группам такое четкое. Наиболее интересные экземпляры Серверов Приложений гармонично сочетают в себе достоинства различных групп. Кроме того компании-разработчики активно развивают свои продукты. А каждая новая версия, естественно, богаче предыдущей.
  
  Предвижу следующий вопрос читателей: — « А это уже где-нибудь работает?» Ответ — «Да!». Особенно востребованы Сервера Приложений во всем, что касается использования Internet. И за счет поддержки распределенности, возможностей выравнивания загрузки, отслеживания распределенных неоднородных транзакций, управления безопасностью и многих других своих возможностей. Именно эти интеллектуальные приложения находят в Серверах Приложений могучую опору.
  
  Рис. 5. Java 2 Enterprise Edition
  
  Вскользь упомяну о следующих усилиях по созданию технологии компонентного программного обеспечения, снова связанных с Java. Это J2EE (Java 2 Enterprise Edition) — стандарт для многозвенных систем уровня предприятия, прикладная платформа, обеспечивающая взаимодействие Enterprise Java Beans, Java Server Pages, апплетов и сервлетов. рис. 5 в точности иллюстрирует то, как это выглядит у компании Sun.
  
  Средства взаимодействия компонентов располагаются в нижней части рисунка. J2EE впервые стандартизовала выполнение родного для Java протокола удаленных вызовов методов через Internet — IIOP (Internet InterOrb Protocol). Таким образом, к сотрудничеству между CORBA и Java добавился еще один пункт. Серверные компоненты заключены в контейнеры, взаимодействующие с помощью специальных коннекторов. На уровне контейнеров задаются системные сервисы: Транзакций, Сообщений и Почты. На верхнем уровне находится API-интерфейс и Средства управления. Сказать об этой технологии в контексте Серверов Приложений меня вынудило не только то, что этот стандарт является логическим развитием технологии EJB, в которой впервые определился наш герой, но и то, что уже появляются Серверы Приложений, удовлетворяющие новому стандарту. Я имею в виду уже упоминавшийся Application Server (Inprise).
  
  Но, стоп, боюсь, что Вы уже устали от обилия технологий и нагромождения стандартов? Если да — то тогда обратитесь к рис. 6, где я попыталась свести все воедино.
  
  Рис. 6. Стандарты распределенных программных систем
  
  В защиту всего этого хозяйства хочу отметить, что, говорят, наши предки -обезьяны прекрасно жили на деревьях и, если и сплетали себе нечто вроде гнезд, но ни один из нас не согласился бы там жить постоянно, разве что для того, чтобы испытать захватывающее приключение. Так и программные приложения постепенно слезли с деревьев и начали строить себе дома. А если говорить о стандартах в строительстве, то их все равно намного больше, чем на сегодняшний день существует в информационных технологиях. В утешение хочу добавить, что наши стандарты неплохо уживаются друг с другом. По крайней мере, учатся это делать. Как пример, хочу обратить ваше внимание на неоднократное упоминание лакомого современного стандарта XML в этой статье, которая вроде бы написана совсем о других стандартах.
  
  Легче ли создавать программные системы с помощью Сервера Приложений? Я бы покривила душой, если бы однозначно ответила — «да», хотя мне и очень хочется это сделать. Как всяким инструментом, к тому же непростым, им надо научиться пользоваться. Его нужно применять только в определенных условиях, как по инфраструктуре, так и по программному обеспечению. Отдельный вопрос — какую именно реализацию Сервера Приложений следует использовать. Сервер Приложений — верный друг, но только для заботливого и грамотного хозяина.
  
  Об авторе
  
  Марина Аншина — сотрудник отдела системной интеграции компании «ТопС, Системный Интегратор». С ней можно связаться по электронной почте по адресу: marinaa@tops-msk.com
  
  Моральный кодекс молодого строителя программного обеспечения — Сервера Приложений
  
  Сервер Приложений обязан
  1. Создавать сеансы взаимодействия клиента и сервера и управлять ими.
  2. Защищать корпоративные данные от несанкционированного доступа.
  3. Обеспечивать транзакционную целостность информации.
  4. Распределять нагрузку между серверными приложениями.
  5. Поддерживать требуемый уровень качества предоставляемых клиенту сервисов.
  6. Отыскивать для клиента сервер требуемой функциональности.End Sub
  IBM WebSphere Application Server (WAS)
  
  IBM WebSphere Application Accelerator — обеспечивает глобальный охват пользователей клиента критически важными корпоративными приложениями, используя Интернет для ускорения доставки приложений пользователям в любое время и место, а также предоставляет сервис по оптимизации приложений «на границе сети».
  
  IBM Websphere Application Server 8
  
  Сервер приложений WebSphere Application Server (WAS) версии 8 – программное обеспечение, предназначенное для ускорения разработки приложений и сервисов. Новая версия WAS улучшает безопасность клиентов и возможности контроля, а также предоставляет расширенные возможности автоматизации для установки, обслуживания, тестирования и решения проблем бизнес-приложений.
  
  Кроме того, эти усовершенствования дополняются новыми функциями, которые распространяют возможности WAS в поддержке широкого спектра приложений (охватывающего платформы от настольных ПК до мобильных устройств) на популярные смартфоны и планшетные компьютеры, включая iPad, iPhone, Droid, BlackBerry и многие другие. Поддержка этих устройств имеет важнейшее значение для бизнеса, поскольку мобильные приложения являются сегодня одним из наиболее крупных быстрорастущих направлений. Согласно прогнозу, приведенному в одном из недавно опубликованных отчетов о рыночных исследованиях, мировой рынок мобильных приложений может вырасти с 6,8 млрд. долларов в 2010 году до 25 млрд. долларов к 2015 году.
  
  WebSphere является основным продуктом категории программного обеспечения IBM, называемого связующим или промежуточным ПО (middleware), которое позволяет Web-приложениям и операционным системам взаимодействовать друг с другом. Первоначально разработанное в 1997 году, ПО WebSphere стало одним из важнейших ускорителей развития бизнеса IBM за пределы сферы аппаратных средств, в область прикладного программного обеспечения и сервисов. В рамках празднования своего столетнего юбилея, IBM определила WebSphere в качестве одного из ключевых катализаторов развития технологий, который дал Интернету возможность стать платформой для применения информационных и коммуникационных технологий в бизнесе.
  
  В настоящее время в мире насчитывается свыше 100000 клиентов WebSphere. Один из них – гигант тяжелой промышленности Caterpillar – уже начал тестировать то, как новое программное обеспечение может расширить сферы применения его корпоративных приложений для достижения новых клиентов.
  
  IBM Websphere Application Server 8.5 Liberty
  
  Компания IBM анонсировала в апреле 2012 года новую версию сервера приложений IBM Websphere Application Server 8.5 под названием Liberty, которая является более быстрым и динамичным промежуточным инструментом создания промышленных приложений для разных клиентов. Полностью работоспособный сервер приложений Websphere App Server 8.5 занимает всего 50 Мб, что позволяет размещать его даже в таких системах, как Raspberry Pi.
  
  Новая платформа позволяет устанавливать обновления и исправления к приложениям «на лету» – перезагрузка сервера приложений не требуется. При установке официальной среды исполнения Java SE версий 7 или 8 необходима серьезная работа по настройке, а потребление ресурсов выходит за все допустимые рамки. Именно поэтому современные Java-приложения для облачных и мобильных систем все чаще используют альтернативные среды исполнения вроде Apache Tomcat. Как и Tomcat, новая версия IBM Websphere Application Server предлагает малое потребление ресурсов, быстрый старт и удобное добавление новых приложений без перезапуска.
  
  Особое внимание на платформу следует обратить предприятиям, которые вынуждены полностью обновлять свои базовые приложения три раза в год – с появлением платформы Liberty этот процесс становится легче и быстрее. Кроме того, все новые функции Liberty имеют обратную совместимость, так что уже существующие Websphere-приложения могут получить все преимущества новой платформы без переписывания кода.
  Похожие публикации: