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

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

Когда вы открываете любой сайт — например, 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. Он принимает запросы и обрабатывает их по всем стандартам. А разработчик может сконцентрироваться на бизнес-логике, не отвлекаясь на детали обеспечения транспортного пути.

Application Server

An application server is a modern form of platform middleware. It is system software that resides between the operating system (OS) on one side, the external resources (such as a database management system [DBMS], communications, and Internet services) on another side, and the users’ applications on the third side. It helps to execute and produces users and application access while utilizing business and function logic of application that is installed on the application server. Primary features are needed of application server enable load balancing, data/application protection, centralized management interface, data redundancy, and high availability. Application server can be connected with remotely network and enterprise systems for accessing via internet.

Terminology

Web Server: Apps server also provide several functionalities to make and serve dynamic websites.

Web client: Endpoint attempting to access web or application resourcesç

HTTPS: Communication protocol between a web server and web clients.

API: API helps to make communication in between application server and clients without getting any deep knowledge of both.

Integration: Application server acts as middle layer in between database and highly backend system. For instance; application server is used for banking website that helps to establish connection with its database and services for their account data, transactions, and market data.

High Availability: In few scenario, application servers offers load balancing, failover, and clustering. So Several servers can be deployed to manage heavy load and get high availability.

Cloud Deployment: Today, it is getting more popularity to implement application server to cloud system, and cloud load balancer can be used as opposed to higher availability features of Apps server product themselves.

Microservices: It is advance technique that enables splitting business logic into independently deployed services. Microservices are mostly implemented to application servers on the cloud system, and it helps to offer more scalable and resilient applications.

Main purpose of using of application server :

• To decrease the size and its complexity of all client programs
• To get best performance, it requires cache and handles the entire data flow.
• It implements protection for data and end-user traffic.

How to work?

Bir web sunucusundan bir sunucu uygulaması isteği aldığında, uygulama sunucusu isteği işler ve sunucu uygulaması yanıtı yoluyla web sunucusuna yanıt verir . Uygulama sunucuları öncelikle iş mantığı istekleriyle çalıştığından, web sunucusu sunucu uygulaması yanıtını çevirir ve kullanıcının erişebileceği bir HTTP yanıtını iletir.

Why use an application server?

Application servers are best put to use when there is the need to integrate with databases and servers, for example, web servers, which have already been set up and are part of an organisation’s existing IT infrastructure.

One of the predominant reasons for this is that an application server can serve as a means to provide integrity to code and data by having an integrated and centralised approach to keeping applications upgraded and updated. Not having one can lead to different versions of the same app across your business, which in turn could bring with it software compatibility problems.

While an application server and a web server might initially seem similar at face value they are, in fact, quite different. The former stands apart from the latter in that is deals with serving business logic to apps through a suite of protocols. A web server, on the other hand, works with HTTP requests, responding and handling them in order to carry out website functions, as well as hosting said website, storing its static content, such as images, JavaScript, CSS, and HTML pages.

Among the popular application server platforms are J2EE, WebLogic, Glassfish, JBoss Enterprise Application Platform, Apache Tomcat, and Apache Geronimo, to name but a few.

Сервер приложений и веб-сервер

Сервер приложений (Application Sever) – это сервер промежуточного программного обеспечения (ПО, middleware). Это системное ПО, которое располагается между операционной системой (ОС) с одной стороны, внешними ресурсами, например, системой управления базами данных СУБД (DBMS, Database Management System) или Интернет-сервисами, с другой стороны, и приложениями пользователя.

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

Внешние ресурсы, например, СУБД и Интернет-сервисы, предоставляют веб-серверы (Web Server). Они отвечает на запросы пользователя по доставке контента.

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

Различия между серверами приложений и веб-серверами

Параметр сравнения

Веб-сервер

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

Основная цель

Хостинг сайтов и ответы на простые веб-запросы

Хостинг приложений и обеспечение сложных взаимосвязей бизнес-логики

Тип контента

Доставка только статического контента HTML

Доставка как статического, так и динамического контента

Протоколы

HTTP/HTTPS и другие протоколы

Соединение с приложениями

Подключения к базами данных

К статическим базам данных

К базам данных приложений

Типичные клиенты

Веб- и мобильные приложения, а также веб-браузеры

Многопотоковая обработка

Поддерживается параллельная обработка многих запросов

Потребление ресурсов

Трафик не потребляет много ресурсов

Процессы с интенсивным потреблением ресурсов

Контейнеры

Веб-контейнеры (сервлеты, JSP, JSF, веб-сервисы), контейнеры клиентских приложений (DI, безопасность)

Ёмкость

Результат запроса

Гипертекстовый документ, отображающий информацию в браузере

Файлы, содержащие данные, по требованию клиента

Что такое веб-сервер?

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

Обычно веб-серверы не обрабатывают динамический контент и не позволяют программировать свои программы. Веб-серверы работают по протоколу передачи гипертекста HTTP (Hypertext Transfer Protocol) или HTTPS (Hypertext Transfer Protocol Secure). Однако, опционально, некоторые веб-серверы позволяют добавлять компоненты, позволяющие работать с динамическим контентом.

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

Сервер приложений (Application Server, App-Server) – это программный комплекс, предназначенный для доставки контента и средств его представления для клиентских приложений. Клиентами могут быть веб-приложения, браузеры или мобильные приложения.

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

• Результаты транзакций;
• Поддержка принятия решений;
• Аналитика в реальном времени, и др.

Сервер приложений – это связующее звено между клиентом и программным кодом физического сервера. Типичные задачи сервера приложений:

• Управление транзакциями;
• Безопасность;
• Внедрение зависимости DI (Dependency injection);
• Одновременность исполнения процессов (Concurrency).

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

Рис. 2. Сервер приложений.

Что общего у веб-сервера и сервера приложений

Если в качестве основного приложения клиента выступает веб-браузер, то различия между двумя типами серверов размываются. Большинство веб-серверов имеют плагины на основе скриптов (ASP, JSP, JSF, PHP, Perl, и пр.), которые позволяют генерировать динамический контент.

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

Для хостинга веб-сайта со статическим контентом лучше всего подходят объектные СХД.

Наиболее популярные веб-серверы

• Nginx

Nginx – веб-сервер с открытым кодом, который может работать как обратный прокси-сервер (reverse proxy). Обратный прокси-сервер работает не в сторону клиента, фильтруя контент и обеспечивая безопасность, а в сторону веб-сервера. Nginx имеет архитектуру, управляемую событиями EDA (event-driven architecture), позволяющую создавать и определять события, реагировать на события, измерять потребление ресурсов реакции на событие. Кроме того, он может выполнять функции прокси-сервера электронной почты и балансировщика нагрузки и может выполнять одновременно множество запросов.

• Apache HTTP

HTTP-сервер Apache – популярный веб-сервер на ОС Linux, который входит с стек LAMP (Linux, Apache, MySQL, PHP). На этом веб-сервере работает около 40% Интернет-сайтов. Apache имеет богатый выбор функций, включая htaccess, FTP, HTTP/2, ограничение полосы пропускания для определённых клиентов (throttling), балансировку нагрузки и пр.

• Microsoft IIS

Microsoft IIS (Internet Information Services) – свободно распространяемый пакет серверного ПО, представляющий собой проприетарный набор служб от компании Microsoft. IIS распространяется с пакетом Windows NT. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP.

• Jetty

Jetty – проект свободного ПО, который может обеспечивать функции НТТР-сервера, НТТР-клиента и контейнера javax.servlet. Хотя Jetty разрабатывался как веб-сервер, он также может служить платформой для межмашинных коммуникаций (М2М).

• LiteSpeed

LiteSpeed имеет хорошую производительность и масштабируемость, широкий диапазон функций и простую в использовании консоль администратора. Это четвёртый по популярности веб-сервер, который, по состоянию на декабрь 2020 года, использовался для 8.1% веб-сайтов.

Наиболее популярные серверы приложений

• Apache Tomcat

Apache Tomcat – контейнер сервлетов с открытым исходным кодом на языке Java. Tomcat позволяет запускать веб-приложения и содержит ряд программ для автоматического конфигурирования и часто используется вместе с конфигурационным файлом Apache HTTPD (Apache Hypertext Transfer Protocol Server daemon). Tomcat может исполнять Java-сервлеты, доставлять клиентам страницы в кодах Java Server Page, и может обслуживать приложения Java EE (Java Enterprise Edition).

• Oracle WebLogic

Сервер Oracle WebLogic – сервер для распределённых приложений с использованием стандартов Java EE. Он полностью интегрирован с продуктами и облачными сервисами Oracle.

• Glassfish

Glassfish – сервер приложений с открытым кодом на Java EE, который поддерживает Java-сервлеты, а также спецификацию написания и поддержки серверных компонентов с бизнес-логикой EJB (Enterprise JavaBeans).

• JBoss

JBoss – сервер приложений с открытым кодом для создания, развёртывания и хостинга приложений на языке Java. JBoss может работать на разных платформах и в любой операционной системе с поддержкой Java.

Какой сервер приложений будет наиболее подходящим?

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

• Если нужно обслуживать только веб-страницы со статическим контентом, то лучше использовать веб-сервер;
• Если приложения требуют наличия JSP (JavaServer Pages) и сервлетов, лучше использовать простой сервер приложений, типа Jetty или Apache Tomcat;
• Если приложения содержат много сложных функций, таких как распределённые транзакции и мессенджеры, то лучше использовать полнофункциональные серверы приложений, такие как JBoss или Oracle WebLogic.

Другим подходом может быть добавление функционала в веб-сервер при помощи плагинов. В этом случает, веб-сервер может использовать технологию программирования на стороне сервера (server-side), такую как скрипты CGI, JSP, сервлеты, ASP (Active Server Pages) или JavaScript на стороне сервера.

Использование обоих типов сервера в одной системе

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

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

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

Сценарий 1. Использование только веб-сервера с плагинами

Веб-сервер предоставляет функционал Интернет-магазина:

• Сервер получает запрос и передаёт его в соответствующую программу на стороне сервера;
• Эта программа ищет актуальные цены в базе данных или в обычном файле;
• Программа формулирует ответ в форме HTML;
• Веб-сервер посылает запрос обратно в веб-браузер клиента.

Сценарий 2. Использование как веб-сервера, так и сервера приложений

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

Размещение логики поиска цены в сервере приложений позволяет использовать её различными частями приложения. В первом сценарии сервис поиска цены не может повторно использоваться, поскольку данные встроены в HTML-страницу.

Рис. 3. Использование как веб-сервера, так и сервера приложений.

Заключение

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

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

Часть 5

Мы продолжаем наше знакомство с новой серверной операционной системой компании Microsoft — Windows Server 2008. Предыдущие части данного обзора были посвящены следующим темам:

• основные понятия, связанные с серверной операционной системой, роли, которые может выполнять Windows Server 2008, а также система управления сервером Server Manager (см. КомпьютерПресс № 4’2007);
• вариант установки Windows Server 2008 с минимальным набором функциональности — Server Core, транзакционная файловая система (TxF) и транзакционный реестр (см. КомпьютерПресс № 5’2007);
• расширения, появившиеся на уровне ядра операционной системы, процессы и потоки, изменения в сетевом стеке, а также вопросы, связанные с порядком загрузки операционной системы (см. КомпьютерПресс № 6’2007);
• технологии управления инфраструктурой и приложениями, выполняющимися на ее основе, — Windows Eventing 6.0, Windows Installer 4.0, Windows PowerShell, Microsoft Management Console 3.0 и Windows Task Scheduler 2.0 (см. КомпьютерПресс № 8’2007).

В этой части мы начнем рассмотрение Windows Server 2008 в роли сервера приложений — Application Server, — который представляет собой интегрированную среду для развертывания и выполнения серверных бизнес-приложений. Чаще всего такие приложения разрабатываются либо внутри организации для решения специфических бизнес-задач, либо приобретаются у независимых разработчиков программного обеспечения (Independent Software Vendor, ISV). Обычно подобные приложения используют одну или более следующих технологий, сервисов и компонентов: Internet Information Services (IIS), Microsoft .NET Framework, ASP .NET, COM+, Message Queuing, web-сервисы на основе Windows Communication Foundation (WCF).

История сервера приложений

История сервера приложений от Microsoft началась более 10 лет назад, в 1986 году, когда в рамках NT 4.0 Option Pack был выпущен продукт Microsoft Transaction Server 1.0 (кодовое название Viper). Он позволял развертывать COM-компоненты в контейнеры и задавать их различные транзакционные уровни. За время, прошедшее с момента выпуска Windows NT 4.0, сменилось несколько поколений подходов к созданию приложений — от архитектуры «клиент-сервер» до многозвенной архитектуры и федеративных систем (Federated Systems). Технологии, обеспечивавшие поддержку каждой такой архитектуры, тоже изменились — на смену объектно-ориентированному подходу (инкапсуляция, наследование и полиморфизм), популярному в 80-х годах, пришел компонентоориентированный, широко применявшийся в 90-х (независимость от местоположения, тесное связывание, метаданные в режиме выполнения), а в наше время появился сервис-ориентированный подход (использование сообщений, схемы, контракты, политики, межплатформенность). Соответствующим образом пополнялись компоненты сервера приложений — от Microsoft Transaction Server до COM+ и Enterprise Services, на смену которым пришли .NET Framework и Windows Communication Foundation.

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

Сервер приложений в Windows Server 2008

Основные изменения и улучшения сервера приложений Windows Server 2008 заключаются в упрощении установки и конфигурации роли (что, впрочем, относится ко всем ролям, поддерживаемым в Windows Server 2008). Новый мастер Add Roles Wizard, реализованный в Server Manager, позволяет выбрать сервисы и дополнительные функции, необходимые для обеспечения работоспособности бизнес-приложений; установка Application Server Foundation, сервера приложений с настройками по умолчанию, включает .NET Framework 3.0. Также для роли «сервер приложений» устанавливается web-сервер — Internet Information Services (IIS) 7.0 и доступны следующие сервисы: Windows Process Activation Service (WAS), позволяющий активировать сервисы Windows Communication Foundation (WCF) по протоколу HTTP, через TCP, Named Pipes и Message Queue, и Net.TCP Port Sharing, который дает возможность нескольким WCF-приложениям использовать один TCP-порт для получения сообщений. Помимо этого доступны такие сервисы, как COM+ Network Access для удаленного вызова приложений COM+, Distributed Transactions и MSMQ.

Application Server Foundation

Application Server Foundation — это группа технологий, устанавливаемых по умолчанию при выборе роли «сервер приложений». В основе Application Server Foundation лежит библиотека классов .NET Framework 3.0. В составе Windows Server 2008 поставляется библиотека классов .NET Framework 2.0 — она доступна для всех ролей. В .NET Framework 2.0 входит Common Language Runtime (CLR) — ядро выполнения кода, написанного на «управляемых» языках — C#, VB .NET и ряде других, которое обеспечивает безопасное выполнение кода, упрощенное развертывание и межъязыковое взаимодействие, — и обширная библиотека классов. Application Server Foundation добавляет к базовым функциям .NET Framework 2.0 ряд расширений, реализованных в .NET Framework 3.0. К таким расширениям относятся Windows Communication Foundation (WCF), Windows Workflow Foundation (WF) и Windows Presentation Foundation (WPF). Из этих трех ключевых компонентов .NET Framework 3.0 WCF и WF часто применяется как для серверных, так и для клиентских приложений, тогда как WPF в основном используется только на клиенте (в данном обзоре он не обсуждается — более подробно о Windows Presentation Foundation см. соответствующий раздел сайта MSDN по адресу: http://msdn2.microsoft.com/en-us/netframework/aa663326.aspx и раздел сайта netfx3 по адресу: http://wpf.netfx3.com/).

Windows Communication Foundation

Windows Communication Foundation (WCF) — это унифицированная программная модель для построения приложений, использующих web-сервисы для коммуникации (connected applications). Такие приложения создаются на основе архитектуры Service Oriented Architecture (SOA) и часто называются сервис-ориентированными приложениями. Разработчики могут использовать WCF для создания надежных, безопасных транзакционных web-сервисов, которые могут общаться с другими сервисами и приложениями, реализованными на различных платформах. Таким образом, появляется возможность создавать приложения, потребляющие сервисы, «составлять» приложения из сервисов, расширять функциональность существующих приложений и реализовывать механизмы интеграции между приложениями и сервисами. WCF поддерживает все современные технологии, используемые для создания распределенных приложений, — COM+ и .NET Enterprise Services, Message Queuing, .NET Remoting, ASP .NET Web Services и Web Services Enhancements (WSE).

Более подробно о Windows Communication Foundation см. соответствующий раздел сайта MSDN по адресу: http://msdn2. microsoft.com/en-us/netframework/aa663324 и раздел сайта netfx3 по адресу: http://wcf.netfx3.com/.

Windows Workflow Foundation

Windows Workflow Foundation (WF) — это программная модель и ядро выполнения приложений, использующих так называемые потоки работ (workflow). Поток работ представляет собой набор активностей, описывающих реальные бизнес-процессы. Потоки работ обычно создаются и отрабатываются графически с помощью соответствующих инструментов. В описании потоков работ обычно применяется модель, и включенные в нее отдельные элементы потока (активности) могут выполняться как программно, так и вручную. Простые потоки работ могут быть описаны и реализованы с помощью традиционных языков программирования, например как серия шагов и условий их выполнения. Более сложные, реалистичные workflow требуют соответствующих средств дизайна, разработки и выполнения. Таким образом, включенные в Windows Workflow Foundation графические средства создания моделей, библиотеки предопределенных активностей и средства выполнения потоков работ максимально упрощают реализацию сложных, комплексных сценариев, позволяющих управлять активностями как программно, так и вручную.

Можно выделить следующие ключевые сценарии использования Windows Workflow Foundation:

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

Более подробно о Windows Workflow Foundation см. соответствующий раздел сайта MSDN по адресу: http://msdn2.microsoft.com/en-us/netframework/aa663328 и раздел сайта netfx3 по адресу: http://wf.netfx3.com/.

Более подробно о .NET Framework 3.0 — см. .NET Framework Developer Center по адресу: http://msdn2.microsoft.com/en-us/netframework/default.aspx, а также специализированный сайт http://www.netfx3.com.

Дополнительные сервисы

Помимо Application Server Foundation можно добавить к серверу приложений ряд дополнительных сервисов, к которым относятся web-сервер, удаленный доступ к сервисам COM+, Windows Process Activation Service, Net.TCP Port Sharing и поддержка распределенных транзакций.

Web-сервер

Используя данную опцию, можно установить web-сервер — Internet Information Services 7.0. Это существенно переработанная версия web-сервера, обладающая повышенной производительностью, высокой безопасностью, управляемостью, надежностью, модульностью и масштабируемостью. К основным преимуществам использования Internet Information Services можно отнести возможность хостинга в рамках сервера приложений внутренних и внешних сайтов, web-сервисов и компонентов со статическим и динамическим наполнением, возможность выполнения приложений на ASP .NET с доступом к ним из web-браузера и поддержку выполнения web-сервисов, созданных как средствами Windows Communication Foundation, так и ASP .NET.

Дополнительную информацию о Internet Information Services можно получить на сайте, посвященном IIS 7.0 и расположенном по адресу: http://www.iis.net/.

Более подробно о новом web-сервере мы поговорим в следующей части нашего обзора.

Удаленный доступ к сервисам COM+

COM+ Network Access — это сервис, обеспечивающий удаленный вызов приложений, созданных с применением технологии COM+ и компонентов Enterprise Services. Такие приложения часто называют компонентами Enterprise Services. Данный сервис впервые появился в Windows 2000 Server и продолжает поддерживаться в Windows Server 2008. Приложения, создаваемые с применением новейших технологий, обычно используют WCF для поддержки удаленных вызовов, так как WCF обеспечивает межплатформенное взаимодействие.

Windows Process Activation Service

Данная опция добавляет сервис Windows Process Activation Service (WAS). С помощью WAS можно динамически запускать и останавливать приложения, которые применяют сообщения, получаемые из сети по HTTP, Message Queuing, TCP и Named Pipes. Динамический запуск и остановка приложений обеспечивают более эффективное использование ресурсов сервера. WAS — новинка, появившаяся в Windows Server 2008.

Net.TCP Port Sharing

Данная опция добавляет сервис, известный под названием Net.TCP Port Sharing Service, который является новым сервисом в Windows Server 2008. Он позволяет нескольким приложениям применять один TCP-порт для получения входящих сообщений по соответствующему протоколу. Данный сервис принимает запросы и автоматически перенаправляет их соответствующим сервисам в зависимости от адреса получателя. Например, сервис-ориентированные приложения, построенные на основе WCF, могут использовать один порт. Разделение портов между несколькими приложениями является частым требованием при применении межсетевых экранов (firewall), или при ограничениях на число одновременно открытых портов, или когда требуется одновременная работа нескольких экземпляров WCF-приложения. Совместное использование порта (мультиплексирование) работает только в том случае, когда WCF-приложения применяют протокол net.tcp для входящих коммуникаций.

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

Приложения, выполняющие обновления в различных базах данных или в других транзакционных ресурсах, должны поддерживать транзакции — все обновления либо успешно выполнены, либо отменены. Поддержка распределенных транзакций в Windows Server 2008 обеспечивает выполнение этого требования. Отметим, что распределенные транзакции впервые стали поддерживаться в Microsoft Windows NT Server 4.0

Microsoft Message Queue 4.0

В состав Windows Server 2008 также входит новая версия коммуникационной технологии на основе обмена сообщениями, распространяемыми через очереди, — Microsoft Message Queue 4.0. Среди новинок в данной версии отметим появление подочередей, возможность обработки «отравленных» сообщений (Poison Messages), а также удаленное получение сообщений в рамках транзакций.

Использование подочередей позволяет создавать логические разделы для физических очередей. С помощью подочередей возможна реализация следующих сценариев: группировка отдельных сообщений для их более эффективной обработки и возможность вынесения сообщений, которые не могут быть обработаны, в специально созданную для таких случаев подочередь. Более подробно о подочередях см. на сайте MSDN по адресу: http://msdn2.microsoft.com/en-us/library/ms711414.aspx.

Так называемые отравленные сообщения — это сообщения, число попыток обработки которых превысило заданный максимум. В MSMQ 4.0 появилась возможность переноса приложений из основной очереди в очередь, называемую retry queue. Это позволяет приложениям продолжить обработку сообщений из основной очереди и позднее вернуться к обработке «отравленного» сообщения. Более подробно о работе с «отравленными» сообщениями см. на сайте MSDN по адресу: http://msdn2.microsoft.com/en-us/library/ms703179.aspx.

Удаленное получение сообщений в рамках транзакций представляет собой транзакционное получение сообщения из удаленной очереди. В предыдущих версиях Message Queuing (MSMQ) такая возможность не поддерживалась, и Microsoft рекомендовала не использовать доступ к удаленным очередям вне транзакции. Более подробно о работе с удаленными очередями см. на сайте MSDN по адресу: http://msdn2.microsoft.com/en-us/library/ms700128.aspx.

Версии Windows Server 2008

Роль Application Server поддерживается во всех изданиях Windows Server 2008 — Windows Server 2008 Standard, Windows Server 2008 Enterprise, Windows Server 2008 Datacenter, Windows Server 2008 for Itanium-Based Systems, но недоступна в издании Windows Web Server 2008.