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

Общая схема работы сервера приложений

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

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

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

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

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

Enterprise Application Server

Компания Sybase выпустила на рынок продукт Enterprise Application Server (EAS), предназначенный для установки и использования сервера приложений в рамках предприятия, и интеграции в него специфичных бизнес-модулей. Ядром EAS является сам сервер приложений Jaguar CTS (Component Transaction Server), который представляет собой среду запуска и выполнения бизнес-модулей предприятия с поддержкой их отказоустойчивой работы и контролем за выполнением операций с базами данных. Сервер приложений также отвечает за организацию связи между клиентским ПО и сервером Jaguar, во время которой клиентские запросы управляют проведением бизнес-операций на сервере.

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

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

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

Создание компонентов

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

Невизуальные объекты PowerBuilder. Практически любой объект, созданный в среде PowerBuilder способен играть роль компонента Jaguar сервера, если он не осуществляет визуального взаимодействия с пользователем и не требует использования глобального контекста приложения. Встроенные утилиты позволяют автоматически выбрать и загрузить на сервер приложений выбранные объекты в качестве компонентов. При этом будет загружен не только сам объект, но и все необходимые для его работы библиотеки приложения. При порождении нескольких компонентов из различных объектов одного приложения будут созданы различные компоненты, независимо запускаемые в рамках отдельных процессов (необходимо использование компилированного в среде PowerBuilder интероперабильного Р-кода в виде модулей PBD). Инструментальная среда поддерживает также прозрачную отладку компонента на самом сервере приложений.

Java-классы и компоненты Enterprise Java Beans. Jaguar сервер поддерживает работу в качестве компонентов с модулями на языке Java. Это может быть обычный Java-класс, или же серверный компонент, соответствующий стандарту Enterprise Java Beans. В обоих случаях гарантируется машинная независимость созданных компонентов и масштабируемость информационных систем. Создание компонентов на языке Java может производиться в любой среде разработки, однако использование PowerJ и поставляемых с ней утилит позволяет автоматизировать процедуры создания и загрузки на сервер разрабатываемых компонентов, сокращая время разработки.

Компоненты ActiveX. Версия сервера приложений Jaguar для Windows NT поддерживает технологию СОМ, а для создания подключаемых к серверу COM-объектов можно использовать любую совместимую с технологией Microsoft инструментальную среду.

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

Набор хранимых процедур баз данных, функции Cobol и объекты SAP. В комплект продукта EAS входит специальная программа Application Integrator, позволяющая использовать в виде компонентов хранимые процедуры баз данных, существующие у пользователей наработки на языке Cobol. Отдельно поставляется версия работы с бизнес-объектами SAP R/3.

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

Клиентские приложения

Доступ со стороны клиента к установленным на сервере Jaguar компонентам осуществляется с использованием CORBA-совместимого протокола IIOP. Это означает, что при наличии стандартного ORB-клиента приложение сразу оказывается готово к работе с сервером Jaguar. В комплекте EAS поставляется набор собственных реализаций ORB-клиентов, предназначенный для встраивания доступа к Jaguar серверу в создаваемые клиентские приложения. В комплект входят библиотеки классов для языка Java, а также двоичные библиотеки для подключения на этапе линковки со стандартными компилируемыми приложениями. Среда разработки Java-приложений PowerJ включает набор утилит для автоматического создания кода вызова сервера Jaguar. ORB-брокер встроен и в среду разработки PowerBuilder.

Помимо протокола IIOP, сервер Jaguar поддерживает вызов компонентов по протоколу TDS, использующегося для работы с корпоративными серверами баз данных. Это позволяет вызывать методы компонента из любого приложения, способного обратиться к хранимой процедуре, но в этом случае в качестве такого «псевдосервера баз данных» будет выступать сервер Jaguar. Протокол IIOP, базирующийся на TCP/IP, предназначен для работы в сетях, однако, современная структура Internet допускает доступ клиента к серверу через прокси-серверы и межсетевые экраны, которые могут запрещать работу с любым протоколом, выходящим за рамки стандартного Web-соединения. Поэтому реализация ORB-клиента в продуктах Sybase поддерживает также туннелирование IIOP через стандартный протокол HTTP.

Концепция тонкого клиента

Самая большая задача, стоящая перед сервером приложений, — обеспечение работы с Internet-клиентами. Можно, конечно же, использовать Сеть только как коммуникационную инфраструктуру, но чаще всего к этому добавляется и реализация клиентских приложений в виде HTML-страниц для просмотра посредством Web-браузера. Такие страницы могут содержать код, написанный на клиентских скриптах, или Java-апплет. При этом сам апплет (или даже объект ActiveX) может динамически загружаться по сети, при попытке пользователя просмотреть HTML-страницу. Такое тонкое клиентское приложение обычно перекладывает выполнение всей бизнес-логики на сервер, формирующий Web-документы. Поэтому в таких системах использование сервера приложений становится насущной необходимостью.

Как уже упоминалось, в качестве клиента могут выступать Java-приложения и, в частности, Java-апплеты. Каким образом должен доставляться этот апплет для запуска на клиентской машине? Для этого можно использовать любой Web-сервер, но есть решение проще. Сам Jaguar содержит полнофункциональный Web-сервер, готовый к хранению и загрузке на сторону клиента как статических HTML-страниц, так и Java-апплетов. Используя PowerJ (или любое другое средство для создания Java-апплетов) можно создать модуль для присоединения к серверу приложений и управления со стороны клиента выполнением бизнес-логики.

Однако поддержкой загрузки статических документов возможности Jaguar как Web-сервера не ограничиваются. Поддерживаются средства динамического создания HTML-страниц с помощью технологии сервлетов (стандарт для создания Java-приложений, занимающихся динамическим формированием ответа на запрос документа по протоколу HTTP). В более простом случае, когда необходимо динамически создать HTML-страницу, достаточно воспользоваться технологией Dynamo, представляющей собой реализацию серверного языка сценариев JavaScript (стандарт ECMAScript). Оба подхода к созданию динамических HTML страниц позволяют осуществлять вызов компонентов сервера приложений.

Компоненты Jaguar сервера

Начиная с версии 3.6 сервер Jaguar полностью поддерживает Java-технологии J2EE для построения компонент и Java Server Pages (JSP) для использования HTML шаблонов со встроенными вставками кода на языке Java.

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

Оптимизация работы сервера приложений

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

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

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

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

Транзакции и базы данных

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

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

Две другие модели предлагают реальное обеспечение единой транзакции в рамках нескольких баз данных в рамках работы со средами Windows или Unix. Одна модель обеспечивает работу с MS DTC (distributed transaction coordinator), другая представляет собой предложенную Sybase реализацию распределенных транзакций по протоколу OTS/XA. Выполнение общей транзакции может управляться компонентами сервера как с использованием предоставляемого API-интерфейса, так и с использованием стандартных средств, специфичных для конкретной среды разработки. Так в случае применения компонентов JavaBeans поддерживается управление транзакциями в соответствии с моделью JavaBeans.

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

Обеспечение отказоустойчивости

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

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

Организация безопасности сервера

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

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

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

Архитектура серверного приложения

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

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

Передачу информации между независимо запущенными компонентами можно организовать и на уровне вызовов специального API-интерфейса сервера Jaguar. В целом, набор установленных на сервер компонентов образует целое приложение, запуск которого начинается с обращения клиентского ПО к серверу, что порождает целую цепочку взаимно работающих компонентов. Такая структура позволяет использовать при проектировании ПО объектно-ориентированный подход, но уже без ограничений на используемые инструментальные средства и оперируя масштабами всей корпоративной системы, а не нескольких компьютеров. Учитывая, что большинство аспектов взаимосвязи компонентов и клиентского ПО реализуется самим сервером Jaguar, а не на уровне разработчика, процесс проектирования всей системы отделяется от конкретного кодирования программных модулей и ассоциируется уже не с конкретным кодом, а с администрированием сервера приложений. Отлаженное и работающее приложение, состоящее из нескольких компонентов, можно затем устанавливать на «боевой» сервер целым контейнером вместе с административными настройками.

Заключение

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

Владислав Дмитриев — технический консультант Sybase CIS. С ним можно связаться по электронной почте по адресу: dmitriev@sybase.ru


Требования к серверу приложений

Сокращение времени разработки информационных систем. Типовой коммерческий информационный проект должен реализовываться максимум за 2-3 месяца. Отсюда вытекает необходимость повторного использования имеющихся в компании наработок, а также требование универсальности и совместимости сервера приложений с используемыми программными модулями. Необходима поддержка инструментов для быстрой разработки (RAD — rapid application development), а также сокращение процесса запуска созданного бизнес-модуля в составе работающего сервера приложений.

Уменьшение стоимости сопровождения и масштабирования функциональности. Зачастую стоимость сопровождения и поддержки уже созданных систем значительно превышает первоначальную стоимость. Поддержка современных стандартов как на этапе разработки модулей сервера приложений (например, технологии Java), так и на этапе их функционирования в рамках работающей информационной системы (стандарт CORBA и др.) позволяет использовать готовые наработки третьих фирм, а также сократить затраты на поддержку и развитие системы. Использование объектно-ориентированного подхода уже на уровне организации бизнес-процессов облегчает документирование системы и ее дальнейшее развитие.

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

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

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