CC BY
149
СТРУКТУРНЫЕ МОДУЛИ КОРПОРАТИВНОГО СЕРВЕРА ПРИЛОЖЕНИЙ
Олейник П. П.
Рассмотрены современные серверы приложений, технологии создания распределённых информационных систем и способы реализации бизнес-объектов (компонентов). Описаны присущие им недостатки. Сформулированы критерии оптимальности, представлен состав и структура основных модулей оптимальной системы.
Ключевые слова: распределённые приложения, трёхзвенная архитектура, сервер приложений, динамическая компиляция кода, плагинная архитектура.
Введение
Многие современные информационные системы (ИС) построены на основе трёхзвенной архитектуры, ключевым элементом которой является корпоративный сервер приложений (КСП, СП) [2-3, 16]. При этом вся бизнес-логика приложения расположена на СП, благодаря чему снижаются требования к аппаратным средствам клиентского компьютера и, как следствие, к клиентскому приложению (КП). Учитывая масштабы современных предприятий, выбор и реализация гибкой архитектуры СП является ключевой проблемой, возникающей при создании программного обеспечения.
1. Критерии оптимальности архитектуры сервера приложений
С целью разработки архитектуры КСП выдвинуты следующие критерии (критерии оптимальности, КО) [6]:
1. Поддержка возможности расширения функциональности СП без прерывания выполнения клиентских запросов. Данный критерий предполагает наличие возможности динамического расширения функциональности ИС в процессе выполнения СП. Для вступления в силу всех изменений нет необходимости перезапускать КП и прерывать выполнение поступающих от них запросов.
2. Динамическая компиляции кода. Предполагается, что в качестве модулей расширений будут использоваться файлы с исходным тестом на языке программирования (ЯП). При этом должна выполняться динамическая компиляции кода в процессе работы программы.
3. Прозрачность для клиентского приложения. КП не должно содержать информацию о реализации СП.
4. Минимизация вспомогательных библиотек, необходимых для выполнения клиентского приложения. Клиентскому приложению требуется лишь информация об интерфейсах, предоставляемых сервером приложений. Вся реализации должна находиться в отдельных файлах, доступных только с СП.
5. Наличие графического интерфейса для СП. Это необходимо для управления функциональностью в интерактивном режиме.
6. Возможность доступа к БД. Так как основной задачей, решаемой в трехзвенной архитектуре, является управление базами данных и посылка запросов к СУБД, данная функциональность неотъемлема для СП.
Наиболее важными являются первые два критерия. Возможность расширения функционала во время выполнения приложения позволяет сократить время разработки ИС. При этом нет необходимости прерывать выполнение клиентских запросов, потребуется лишь поставить их в очередь на время загрузки новых (модификации существующих) плагинов. После внесения изменений в бизнес-логику начинается обработка клиентских запросов, находящихся в очереди. Ключевой проблемой при такой организации процесса выполнения клиентских запросов и
запросов на перезагрузку плагинов является реализация алгоритма синхронизации доступа к СП. В работе [7] представлено применение шаблона проектирования read/write lock для решения данной задачи. При этом рассмотрен алгоритм, не отдающий предпочтения запросам какого-либо определённого типа. На временной диаграмме, представленной на рис. 1, изображена оптимальная последовательность обработки вызовов, поступающих как от КП на создание бизнес-объектов, так и от приложения администратора на перезагрузку плагинов.
0 Приложение алмннистратора ] Клиентское приложение №1
И ■ | Вызов метола создания объекта \
*2 '
Ц' и- ■ Вы юк метола иерезафузки плагинов 1 1 | Начало создания объекта > 1 1
ls ■
•б ‘ 1 I
t7- ■ Окончание создания объекта |
ta' - Начало перезагрузки плагинов
tg 110' -Окончание перезагрузки плагинов
tii‘
t, |Г
Вызов метола создания объекта Начало создания объекта
Окончание создания объекта Вьпов метола создания объекта
Начало создания объекта Окончание создания объекта
Рис. 1. Оптимальная последовательность обработки вызовов
Предполагается, что Ь ^ ь Под вызовом метода понимается обработка исполняющей среды метода на КП или на приложении администратора. Под началом (окончанием) метода полагается его выполнение на СП.
Как видно из рис. 1, несколько вызовов метода создания бизнес-объекта обрабатываются параллельно. В момент времени оба КП вызвали описанный метод. При этом в момент вы-
зов, поступивший из второго приложения, начал непосредственное исполнение на СП.
Вызов метода перезагрузки плагинов, поступившего в момент t3, заблокирован до тех пор, пока не закончат своё выполнение ранее вызванные методы, поступившие от клиентских приложений. В момент времени t6 происходит новый вызов метода создания объекта. Он ставится в очередь и ожидает окончания перезагрузки плагинов. В момент t9 вступают в силу все изменения, внесённые в систему, и клиентскому приложению доступна обновлённая функциональность.
Динамическая компиляция также необходима, т. к. она позволяет перенести часть операций из среды разработки в рабочую среду (на СП) и тем самым контролировать процесс загрузки плагинов, что необходимо при реализации алгоритма синхронизации доступа к СП. Предполагаем, что все модули расширений будут представлены в виде текстовых файлов, содержащих текст классов определённого ЯП. Для расширения функционала происходит загрузка текста классов, динамическая компиляция кода на СП и загрузка откомпилированных библиотек в память. После выполнения этих операций начинается обработка запросов, как находящихся в очереди, так и вновь поступающих от КП. В случае возникновения ошибки при компиляции плагинов в памяти СП остаётся старая версия библиотеки, а в приложение администратора выводится список обнаруженных ошибок.
2. Анализ существующих технологий и архитектур
2.1. РЕАЛИЗАЦИЯ ТЕХНОЛОГИИ ENTERPRISE JAVABEANS
Описанные два критерия являются ключевыми, поэтому рассмотрим существующие реализации в разрезе данных критериев. Многие современные СП, такие как Oracle Application Server, Borland AppServer (ранее Inprise Application Server), Sun Java System Application Server, реализуют различные элементы платформы J2EE, в частности, технологию Enterprise JavaBeans (EJB), поэтому рассмотрим процесс установки компонента в
Технические и программные средства управления E/B-контейнер [10, 17, 22, 24, 25, 31] (рис. 2).
Рис. 2. Процесс разработки и установки EJB-компонента
Разработка E/B-компонента начинается с написания класса, унаследованного от системного. После реализации функциональности происходит компиляция классов в байт-код, содержащийся в файлах с расширением *.class. Завершающим этапом, выполняемым в интегрированной среде разработке (ИСР, IDE), является создание E/B-компонента, физически представляющий собой файл с расширением *.jar.
Установка компонента в E/B-контейнер осуществляется непосредственно на СП. Для этого используются как утилиты командной строки, так и утилиты, имеющие графический интерфейс. После выполнения описанных действий E/B-компонент готов к обработке клиентских запросов.
Рассмотрим процесс разработки и установки E/B-компонента в Oracle Application Server (OAS) [24]. В OAS программная реализация компонента упаковывается в EAR-файл, содержащий дескриптор приложения, который в последствии устанавливается в Oracle /2ЕЕ-контейнер (OC4J). Корпорация
111
Oracle рекомендует для установки Е/В-компонента использовать либо оболочку Oracle Enterprise Manager (OEM), либо ИСР JDeveloper. Имеется также возможность установки с помощью утилиты Java admin.jar. Чаще всего установку выполняют с помощью OEM в котором есть соответствующий мастер (Wizard), после запуска которого требуется указать путь к файлу с компонентом. После выставления всех необходимых параметров мастер выполняет установку компонента в контейнер.
В представленном продукте имеется, с нашей точки зрения, недостаток: компонент может выполнять запросы клиентов только после установки его в EJB-контейнер. То есть если в установленном компоненте найдена ошибка, то необходимо в среде разработки сделать исправления, откомпилировать код и создать EJB-компонент, а затем удалить работающий компонент с СП и загрузить новую версию. При вызове методов объекта из КП с момента удаления предыдущей версии и до окончания установки новой версии произойдёт ошибка выполнения. Если в момент удаления старой версии выполнялся метод на СП, то возникает программное исключение в КП. Следовательно, для переустановки компонента потребуется оповестить пользователей, использующих данный компонент. В рассмотренных КСП отсутствует механизм расширения функционала без прерывания клиентских запросов. Так же не предполагается динамическая компиляция исходного кода, реализующего функциональность Е/В-компонент непосредственно на СП. Таким образом, Oracle Application Server не удовлетворяет выделенным критериям.
В Borland AppServer (BAS) разработка компонента выполняется в среде разработки, при этом корпорация Borland рекомендует для данных целей использовать продукт JBuilder, т. к. в нём присутствует самый обширный набор инструментальных средств [22, 25]. Установить можно как непосредственно с ИСР, так и с помощью программы Management Console в которой имеется мастер Deployment Wizard, предназначенный для этого. Мастер предлагает указать пусть к каталогу, в котором расположен компонент, а также ряд опций, среди которых есть возможность установки компонента в отдельный раздел (partition,
отдельный контейнер), чем достигается независимость его от других компонентов, установленных на СП. Переустановка компонента предполагает удаление предыдущей версии и установка новой. При этом компиляция исходного кода на ЯП Java выполняется до установки в СП, поэтому продукту присущи недостатки, описанные ранее.
Перейдём к рассмотрению продукта Sun Java System Application Server [31]. Для установки компонента на СП могут использоваться следующие инструменты:
1. Программа asant представляет собой утилиту командной строки;
2. Программный интерфейс JSR 88, позволяющий разрабатывать собственные инструменты установки компонентов в контейнер;
3. Команда asadmin, позволяющая установить компонент в экземпляр контейнера по умолчанию;
4. Программа Admin Console имеющая графический пользовательский интерфейс.
Установка предполагает выбор файла *. ear либо с помощью графического интерфейса, либо с помощью указания параметров командной строки. После установки компонента он становится доступным для клиентского приложения. Описанные средства рассматриваемого СП не предполагают установку (переустановку) компонента в момент выполнения клиентского запроса. В фирменной документации к данному продукту отсутствует описание решения этой задачи.
2.2. ТЕХНОЛОГИЯ COM+
Рассмотрим технологии корпорации Microsoft в разрезе нашего обсуждения. Отличительной особенностью продуктов корпорации Microsoft является их тесная интеграция с операционной системой Windows [27]. Основной технологией, используемой в качестве СП, является технология COM+ [11, 14].
На рис. 3 представлен процесс разработки и установки COM+ объекта в оснастку.
Создание компонента начинается с описания интерфейсов на языке MIDL (Microsoft Interface Definition Language). Эти интерфейсы используются клиентскими приложениями для вызова функциональности COM объекта.
Рис. 3. Процесс разработки и установки СОМ+-компонента
Разработка бизнес-логики СОМ объекта выполняется на определённом ЯП и заключается в реализации объявленных интерфейсов. После того, как все методы и свойства интерфейса реализованы, происходит компиляция кода. При этом все СОМ+ объекты физически располагаются внутри ¿//-библиотек.
Завершающим этапом является установка СОМ объекта в оснастку СОМ+ приложения, после чего объект может обрабатывать клиентских запросов. При поступлении первого запроса происходит активация объекта, т.е. загрузка библиотеки в память (блокировка ¿//-библиотеки), создание экземпляра класса в памяти, увеличение счётчика ссылок, передача объекта в КП.
В связи с тем, что оснастка блокирует файл в момент активации объекта, отсутствует возможность заменить физически СОМ объект (¿///-библиотеку). Если с помощью оснастки удалить файл и загрузить новый, то произойдёт прерывание выпол-
нения всех клиентских запросов. То есть возникает ситуация, описанная при обсуждении особенностей серверов приложений, реализующих технологию EJB. Кроме того, технология COM+ не предполагает наличия динамической компиляции кода в момент выполнения приложений, т. к. COM объекты физически располагаются в откомпилированных ранее ^//-библиотеках.
Таким образом, реализация технологии COM+ в операционной системе Windows не отвечает выдвинутым КО1 и КО2.
2.3. ТЕХНОЛОГИЯ .NET REMOTING
С появлением платформы .Net Framework (FW) и операционной системы Windows 2003 корпорация Microsoft предоставляет средства, позволяющие создавать бизнес-объекты с развитым функционалом и использовать выше обозначенные продукты в качестве корпоративного СП [27]. В платформе .Net FW присутствует технология Remoting, организующая взаимодействие распределённых (удалённых, серверных) объектов в рамках единой ИС [3, 9, 12, 15].
Технология Remoting может быть применена в любом .Net-совместимом объектно-ориентированном ЯП (например, в C#, VB.Net, De/phi for .Net и т. д.) [3, 9]. В рассмотренных ранее технологиях использовалось специальное программное обеспечение (EJB-контейнер, оснастка COM+ приложения), с помощью которого происходит установка компонента. В Remoting процесс регистрации удалённого объекта (remote object) является более прозрачным и выполняется после создания подходящего канала (tcp или http) в программном коде сервера. То есть разработчик ИС полностью контролирует процесс регистрации серверного объекта, а также может управлять последовательностью обработки запросов, поступивших от КП. На рис. 4 представлен процесс разработки удалённого объекта и его регистрация в серверном приложении (на сервере), реализованном на платформе .Net 2.0.
Разработка объекта начинается с определения интерфейса, в котором описаны методы и свойства. Далее разрабатываются
классы, реализующие описанный интерфейс. Завершающим этапом является компиляция классов в сборки, представляющие собой ^//-библиотеки, содержащие информацию, необходимую для среды выполнения .Net.
Рис. 4. Процесс разработки удалённого объекта
Регистрация удалённого объекта выполняется в серверном приложении, при этом первоначально создаётся канал, используемый для коммуникации между клиентским и серверным приложениями.
Таким образом, программист сам вправе решать, в какой момент регистрировать объект и какой именно объект необходим в тот или иной момент времени. Для перезагрузки серверного объекта достаточно удалить его регистрацию (для чего вызывается соответствующий метод), а затем провести повторную регистрацию. Отметим, что в платформе .Net присутствуют классы, позволяющие выполнять динамическую компиляцию программного кода в момент выполнения приложения (RunTime) [20, 29]. Несмотря на наличие множества гибких средств, технология Remoting не предполагает динамического расшире-
ния функционала и перезагрузки удалённых объектов в момент обработки клиентских запросов, что связано с отсутствием встроенного механизма синхронизации доступа к серверному приложению. То есть данной технологии присущи недостатки, описанные ранее.
2.4.РЕАЛИЗАЦИЯТЕХНОЛОГИИ CORBA
Ещё одной технологией, получившей широкое распространение, является технология CORBA (Common Object Request Broker Architecture) [10-11, 14, 17-19, 23, 26]. Для описания интерфейсов, с помощью которых происходит взаимодействие клиентского и серверного приложений, используется язык IDL (Interface Definition Language). В связи с тем, что существует множество реализаций данной технологии (BEA Tuxedo, VisiBroker, Orbix), доступных на различных программно-аппаратных платформах и выполняемых в среде разнотипных операционных систем, в ней присутствуют некоторые особенности. Каждый объект, реализующий бизнес-логику предметной области, физически разделён на две части: 1) сервер - содержит реализацию методов и обслуживает клиентов; 2) клиент - представляет собой обёртку на серверный объект и необходим для представления сервера в КП. Общей частью для клиента и сервера является брокер объектных запросов ORB, который организует взаимодействие объектов.
В КП присутствует так называемая заглушка (stub), которая физически представляет собой файл, содержащий описание серверного объекта на конкретном ЯП. Заглушка содержит один или более классов, представляющих сервер CORBA на стороне клиента. Для взаимодействия с сервером клиентское приложение обращается к классам заглушки, выполняющим роль посредника для доступа к объектам сервера.
На стороне сервера находится интерфейс ORB, называемый базовым объектным адаптером BOA (Basic Object Adapter). Он отвечает за маршрутизацию сообщений между брокером ORB и интерфейсом каркаса, присутствующем на стороне сервера.
Каркас (ske/eton) — это класс, который так же, как и заглушка зависит от языка программирования, на котором создаётся CORBA объект. Он содержит один или более классов, предоставляющих серверные интерфейсы CORBA. Технология CORBA требует генерации большого количества вспомогательных файлов, что необходимо для достижения переносимости программного приложения в различные гетерогенные среды.
Рассмотрим процесс разработки как серверного, так и клиентского приложения, т. к. он существенно отличается от аналогичных действий, описанных ранее (рис. 5).
Из-за наличия большого количества реализаций технологии CORBA, процесс разработки может незначительно различаться в каждой из них. Рассмотрим продукт VisiBroker компании Bor/and, при этом для создания CORBA приложения использован язык De/phi [14, 17, 23].
Рис. 5. Процесс разработки сервера и клиента в технологии СОЯВЛ
Первым шагом в разработке является описание интерфейсов
на языке IDL. Затем, с помощью компилятора IDL2Pas генерируется текст вспомогательных файлов на языке Delphi как для серверной части, так и для клиентской. Создаются следующие файлы:
1. Файл, содержащий определения всех интерфейсов и типов;
2. Файл, содержащий все пользовательские типы, исключения и клиентские классы заглушек;
3. Файл, содержащий определение класса каркаса на стороне сервера;
4. Файл, содержащий определение общего класса для реализации на стороне сервера.
После реализации функциональности сервера необходимо откомпилировать клиентское и серверное приложение. Чтобы КП смогло воспользоваться функционалом серверного объекта, необходимо зарегистрировать удалённый объект в Службе имён.
Любое изменение интерфейса требует перегенерации ряда вспомогательных файлов, поэтому невозможно использовать динамическую компиляцию кода в момент выполнения приложения, что затрудняет процесс модификации ИС. В свою очередь, если удалить регистрацию объекта из Службы имён в момент выполнения запроса, поступившего от клиента, то возникнет ошибка в КП, что в нашём случае недопустимо.
В продукте BEA Tuxedo для реализации CORBA--приложения потребуется выполнить ряд вспомогательных шагов (кроме описанных выше) [18-19] :
1. Создать файл конфигурации, описывающий политику активации серверного объекта;
2. Зарегистрировать объект в фабрике, которая используется клиентским приложением;
3. В случае использования транзакций, необходимо создать менеджер ресурсов XA;
4. Создать конфигурационный файл, в котором прописываются свойства удалённого объекта;
5. Откомпилировать с помощью программы buildobjserver код класса, реализующего серверное приложение;
6. Использовать команду tmboot для запуска процесса, обслуживающего серверный объект.
После выполнения всех шагов CORBA-сервер может начать обработку клиентских запросов. В случае модификации серверного (а во многих случаях и клиентского) приложения потребуется выполнить основные операции по компиляции программного кода и по запуску процесса, обслуживающего объект. Реализация этих операций не предполагает обработку клиентских запросов в момент их выполнения. Поэтому продукту присущи недостатки, рассмотренные ранее.
В продукте Orbix после описания интерфейса взаимодействия приложений на языке IDL необходимо сгенерировать так называемую начальную заготовку программного кода (starting point code) [26]. Генерация выполняется с помощью утилиты idlgen, которая создаёт вспомогательные файлы как для реализации клиентского приложений, так и для реализации серверного приложения. После того, как функциональность приложения написана, необходимо выполнить следующие завершающие шаги:
1. Запустить сервис ядра Orbix, который организует маршалинг вызовов серверного объекта в клиентском приложении;
2. Задать окружение серверного приложения, в котором прописаны свойства и правила инициализации объекта;
3. Запустить серверное приложение, в котором создаётся экземпляр серверного CORBA-объекта;
4. Запустить клиентское приложение и инициировать вызов серверного объекта.
Подводя итог анализу различных популярных программных продуктов, можно утверждать, что отсутствуют реализации, полностью отвечающие двум основным критериям оптимальности. Наиболее перспективной представляется технология Remot-ing, т. к. она позволяет контролировать основные этапы обработки клиентских запросов, что необходимо при реализации СП, свободного от описанного недостатка существующих систем.
3. Проектирование архитектуры сервера приложений, соответствующей выделенным критериям
3.1. ВЫБОР ЯЗЫКА ПРОГРАММИРОВАНИЯ
Для реализации системы, удовлетворяющей заданным критериям, необходимо выбрать подходящий ЯП. Благодаря наличию ряда ключевых достоинств, в настоящее время широкую популярность получили объектно-ориентированные языки программирования (ООЯП), поддерживающие компонентную парадигму [2, 16]. Чаще всего, при разработке крупных ИС используют следующие языки:
• Java. В этом языке имеется строгая типизация, наличие множества встроенных классов, предоставляющих широкие возможности создания как клиентской, так и серверной частей приложения. Язык поддерживает создание клиентских компонентов JavaBeans и серверных компонентов Enterprise JavaBeans [10].
• C++. Наиболее широкие возможности языка проявляются в C++ Builder, в котором поддерживается возможность создания VCL компонентов. Имеется реализация VC++.Net, которая также позволяет создавать компоненты (для платформы .NetFramework) [1, 12].
• C#. Основной язык платформы .Net Framework, в которой неотъемлемой частью является возможность разработки собственных компонентов [12, 15].
• Delphi. Язык программирования (ранее Object Pascal), в котором наиболее полно реализована концепция компонентно-ориентированного программирования [14].
• VB. В этом языке впервые появилась возможность создания компонент.
• VB.Net. Этот язык является портированной версией языка VB на платформу .Net.
Несмотря на свою популярность, язык Java теряет её в связи с разработкой корпорацией Microsoft платформы .Net Framеwork. При этом основной язык данной платформы C# по
121
своим функциональным возможностям превосходит Java. В связи с этим мы не будем рассматривать Java в качестве альтернативы для реализации СП. Исключим также из рассмотрения языки VB, VB.Net и VC++.Net. Это связано с тем, что языки VB.Net, VC++ .Net являются портированными версиями старых языков программирования на новую платформу корпорации Microsoft, с целью обеспечения перевода унаследованных приложений на новую платформу. При этом язык VB в настоящее время всё реже применяется при разработки КИС.
Современные ЯП поставляются в составе интегрированной среды разработки (ИСР), поэтому необходимо рассмотреть возможности не только языка, но и ИСР. После изучения литературных источников [1, 9, 14] и сравнения функциональности были выбраны следующие языки программирования и ИСР, доминирующие в области разработки информационных систем:
1. Delphi for Win32 (Borland Developer Studio 2006). Данный язык является одним из первых, который позволяет создавать компоненты и поддерживает несколько технологий реализации распределённых приложений, таких как COM, DCOM, COM+, CORBA.
2. C++ Builder for Win32 (Borland Developer Studio 2006). Язык является наиболее функциональным по сравнению с другими языками C+ + . Так же как и Delphi, этот язык имеет множество возможностей и, в отличие от Visual C++ 6, поддерживает развитые возможности по созданию графического пользовательского интерфейса.
3. C# (Visual Studio 2005). Данный язык появился относительно недавно и разработан специально для платформы Microsoft .Net, поэтому ему доступны все нововведения, присущие данной платформе. Язык поддерживает множество технологий и библиотек, таких как ASP.Net, .Net Remoting, WinForm, COM+ и т. п.
С целью выбора подходящего ЯП и соответствующей ИСР необходимо выделить критерии сравнения языков программирования (табл. 1) [4, 8, 13].
Таблица 1. Критерии сравнения языков программирования
Критерий сравнения Необходимость введения
I. Свойства языка программирования
1. Наследование интерфейсов Требуется для реализации критерия оптимальности 4 (КО4). То есть КП будет взаимодействовать только с интерфейсами серверных объектов. В свою очередь, на СП будет находиться исходный код, реализующий все функциональные возможности, к которым имеется доступ с помощью интерфейсов.
2. Создание объектов по имени класса Требуется на СП для прозрачного создания удалённых объектов (КО3). КП необходимо лишь знать имя класса, реализующего требуемую функциональность.
3. Переносимость на различные платформы Позволит запускать сервер приложений под различными платформами (КО 4).
4. Управление модулями (dll, bpl, .Net - сборки) Необходимо для динамической загрузки файлов, содержащих вспомогательные классы и функции (КО4).
5. Динамическая компиляция кода Позволит выполнять расширение функциональных возможностей сервера без физического перезапуска (КО1, КО2).
II. Возможности управления базами данных
1. Наличие классов доступа к БД Необходимо для доступа из серверного объекта к СУБД (рис. 2) для получения информации и выполнения запросов (КО1, КО6).
2. Управление транзакциями Позволяет выполнять несколько запросов в виде атомарной операции (КО6).
3. Возможности выполнения динамического запроса Клиентскому приложению может потребоваться необходимость выполнения произвольного запроса к БД (КО6).
III. Сетевое взаимодействие / Распределённые приложения
1. Поддержка сетевых Требуется для создания распределённых
протоколов приложений, так как чаще всего компьютер клиента и СП находятся в одной локальной или глобальной сети (КО3).
2. Возможность передачи объектов по сети Весь процесс создания объекта на СП и последующая передача ссылки в клиентское приложение должны быть прозрачными для клиента (КО3).
3. Конфигурирование настроек распределённых приложений Язык программирования должен поддерживать возможность смены конфигурации системы без перекомпиляции приложений (КО3, КО4).
4. Активация сервера приложений Сервер приложений должен автоматически активироваться при поступлении первого запроса от клиентского приложения (КО3).
IV. Многопоточность
1. Наличие классов управления потоками Реальный СП является приложением, который обслуживает множество клиентов. Клиентскому приложению нет необходимости беспокоиться о синхронизации доступа к данным, хранящимся на сервере (КО3).
2. Возможности по синхронизации потоков Все запросы на создание объектов, поступающих от клиентского приложения, могут выполняться одновременно. В случае необходимости перезагрузки модулей расширений на сервер, необходимо на некоторое время заблокировать поступающие запросы. После окончания компиляции модулей потребуется продолжить выполнение поступивших запросов. При такой последовательности обработки клиентское приложение ничего не знает о внутренней реализации СП (КО3).
Для выбора оптимального ЯП использована методика, представленная в работах [8, 13], суть которой в том, что все критерии сравнения разделяются на группы. Затем создаётся матрица предпочтений в пределах каждой группы. Для опреде-124
ления веса критериев использован многокритериальный анализ, а именно метод аналитических иерархий [13]. Наиболее широким спектром возможностей в разрезе указанных критериев сравнения обладает язык программирования C# 2.0 (и ИСР Visual Studio 2005)[12, 15].
Рассмотрим преимущества этого ЯП с учётом групп критериев:
1. Свойства языка программирования. Это связано с тем, что платформа .Net Framework имеет в своём составе встроенные классы, позволяющие динамически компилировать программный код, а также поддерживает обширную метаинформацию, доступную через технологию отражения (reflection). Немаловажную роль при этом играет возможность создания отдельного домена приложений, в который загружаются сборки (dll-библиотеки). Благодаря наличию спецификации языка C# появляются реализации платформы .Net на операционных системах, отличных от Windows. При этом в остальных языках существует ограниченная поддержка возможности создания экземпляра класса по имени. Так в Delphi присутствует возможность создания указателя на тип класса (конструкция class of), но при её использовании необходимо выполнять небезопасное приведение типов, что не контролируется компилятором и может вызывать ошибку в момент выполнения приложения. Кроме того, как Delphi, так и С++ предназначены для построения приложений для ОС Windows. Программный продукт Kylix, предназначенный для разработки продуктов на ОС Linux в настоящее время не поддерживается. Управления модулями в данных продуктах основано на скудных средствах управления dll-библиотеками, имеющимися в ОС Windows. При этом в языке C# имеется возможность создания отдельных доменов приложений и, в случае возникновения ошибки в отдельном домене, избежать остановку всего СП. Динамическая компиляция кода в момент выполнения приложения в языках Delphi и C++ не предусмотрена.
2. Возможности управления базами данных. Корпорация Microsoft реализовала продуманную, хорошо спроектированную иерархию классов, позволяющую осуществлять доступ к данным, хранящимся в БД, а также управлять транзакциями как с КП, так и с СП. Нельзя не отметить качественную реализацию параметризированных динамических запросов, выполняемых с помощью библиотеки ADO.Net. В языках C++ и Delphi основная иерархия классов предназначена для работы с БД через устаревший интерфейс BDE, которые не применим при работе с большими объёмами данных. Реализация библиотеки ADO основана на вызове COM интерфейсов, разработанных фирмой Microsoft.
3. Сетевое взаимодействие/Распределённые приложения. Благодаря наличию технологии .Net Remoting язык C# значительно превосходит своих конкурентов. Эта библиотека полностью написана на C# и позволяет организовать сетевое взаимодействие между приложениями. В других языках используются протоколы и библиотеки, входящие в ОС Windows, и для передачи объектов по сети необходимо создать собственную реализацию, что не является тривиальной задачей. Кроме того в C++ и Delphi ограничена возможность контроля процесса взаимодействия различных элементов распределённого приложения.
4. Многопоточность. В языке C# имеется множество встроенных классов, позволяющих создавать и управлять отдельными потоками в пределах одного процесса. От прикладного программиста скрыта внутренняя реализация управления объектами привилегированного режима ОС Windows. Программист оперирует не отдельными функциями API Win32, как это часто бывает при разработке на языках С++ и Delphi, а объектами. Кроме отдельных классов, управляющих потоками, в платформе .Net Framework имеются полноценные реализации некоторых общеизвестных алгоритмов. Например, реализован алгоритм «читатели-писатели», который позволяет организовать многопоточный доступ при выполнении операции чтения данных и упорядочивает дос-
туп к объекту при записи [7, 28]. В С+ + и Ве1рЫ имеется основной класс ТТНгеас1 представляющий собой обёртку вызовов низкоуровневых методов ОС. В них отсутвтуют полноценные реализации даже самым распространённых алгоритмов синхронизации потоков.
Именно на языке программирования С# 2.0 была спроектирована и реализована рабочая система.
3.2. АРХИТЕКТУРА СЕРВЕРА ПРИЛОЖЕНИЙ
Перейдём к рассмотрению архитектуры СП. В литературе по проектированию ПО широкое распространение получила плагинная (модульная, plugginable) архитектура [10, 16, 21, 29]. При этом предполагается разработка унифицированной архитектуры загрузки модулей расширений, в которых расположена вся бизнес-логика приложения. Классической реализации присущ существенный недостаток, который требует реализации плагинов в виде отдельных ^11-библиотек. В подобной реализации ключевой является проблема модификации существующего программного кода, определяющего бизнес-правила приложения. После внесения изменений необходимо перекомпилировать плагин и загрузить его на СП. Это требует либо физического перезапуска сервера приложений, либо прерывания выполнения клиентских запросов. Поэтому оптимальной представляется такая архитектура, которая позволяет вносить изменения в бизнес-логику приложения без прерывания выполнения запросов, поступающих от клиентских приложений. Для этого необходимо выполнить следующие условия:
1. Предусмотреть возможность динамической компиляции классов, реализующих бизнес-логику приложения;
2. Спроектировать модуль управления доступом к плагинам. Выполнение первого требования на СП позволяет контролировать процесс загрузки плагинов и реализовать алгоритм синхронизации доступа к СП. Так как к СП одновременно может подключиться большое количество клиентов, то необходимо на период перезагрузки плагинов заблокировать поступление за-
просов. После выполнения компиляции и всех вспомогательных операции потребуется восстановить возможность обработки операций на СП. Данные функции выполняет модуль управления доступом к плагинам.
Сходные функциональные элементы были реализованы в КСП SharpArchitect Application Server [5-7] (рис. 6).
Рис. 6. Структурные модули сервера приложений
Рассмотрим ключевые модули, присутствующие в реализации:
1. МСД управляет очередями запросов на создание бизнес-объектов и запросов на перезагрузку плагинов на СП, поступающих из приложения администратора. При реализации использован класс ReadWriteLock, реализующий шаблон проектирования read/write lock [7, 28].
2. МКПК осуществляет выбор подходящего компилятора для исходных кодов плагина, компиляцию и загрузку в память откомпилированной dll-библиотеки. При реализации использован класс CsharpCodeProvider и интерфейс ICode-Compiler [20, 30].
3. МОЗ создаёт соответствующие объекты для выполнения запросов и передачи результатов на клиентское приложение. Состав и структура классов, присутствующих в данном мо-
дуле, соответствует методам, имеющимся в библиотеки ADO.Net [12, 15].
4. МР необходимы для реализации бизнес-логики приложений. Каждый плагин состоит как минимум из трёх классов:
a) Серверный преобразователь данных выполняет конвертацию результата запроса к реляционной БД из набора записей в коллекцию объектов;
b) Объект переноса данных реализует бизнес-логику приложения, инициализируется значениями из полей таблиц БД и передаётся клиенскому приложению;
c) Коллекция объектов переноса данных представляет собой список объектов и необходима для последующего отображения данных на клиенте.
В настоящее время для написания плагинов используется язык программирования C#. В случае необходимости может быть использован любой язык платформы .Net Framework. Кроме того, подобная архитектура реализуема на любом объектноориентированном языке, поддерживающем динамическую компиляцию кода в момент выполнения приложений (Run-Time), например, на Java. При этом потребуется реализовать ряд функциональных элементов, присутствующих в платформе .Net FW.
Заключение
В статье рассмотрены существующие подходы и технологии, применяемые при реализации КИС. Выявлены присущие им недостатки. На основании сформулированных критериев представлена оптимальная, с нашей точки зрения, реализация. Даны рекомендации по возможностям расширения системы.
Литература
1. АРХАНГЕЛЬСКИЙ А. Я. Программирование в C++ Builder
6. М.: Бином, 2003. - 1152 с.
2. ГРЭХЕМ И. Объектно-ориентированные методы. Принципы и практика. 3-е издание. Пер. с англ. М.: Издательский дом «Вильямс», 2004. - 880 с.
3. МАКЛИН С., НАФТЕЛ ДЖ., УИЛЬЯМС К. Microsoft .Net Remoting. Пер. с англ. М.: Издательско-торговый дом «Русская редакция», 2003. - 384 с.
4. ОЛЕИНИК П. П. Критерии выбора языка программирования для реализации корпоративного сервера приложений / Теория, методы проектирования, программно-техническая платформа корпоративных информационных систем: Материалы IV Междунар. науч.-практ. конф., г. Новочеркасск, 26 мая 2006 г. / Юж.-Рос. гос. техн. ун-т. (НПИ). - Новочеркасск: ЮРГТУ, 2006. С. 94-98.
5. ОЛЕЙНИК П. П. Многопоточный сервер приложений, поддерживающий динамическую компиляцию модулей расширений (SharpArchitect Application Server). Свидетельство об официальной регистрации программы для ЭВМ №2006613503, 9 октября 2006 г.
6. ОЛЕЙНИК П. П. Практические аспекты реализации многопоточного сервера приложений // Информационные технологии. Теоретический и прикладной научно-технический журнал. 2007. №1. С. 47-50.
7. ОЛЕЙНИК П. П. Применение шаблона проектирования read/write lock для управления доступом к функциональности сервера приложений // Информационные технологии и вычислительные системы. 2007. № 2. С. 51-54.
8. ОЛЕЙНИК П. П. Проблема выбора оптимального языка программирования для реализации программного продукта / Матеріали V Міжнародноі науково-практичноі конференції “Динаміка наукових досліджень - 2006”. Том 7. Дніпропетровськ: Наука і освіта, 2006. С.67-69.
9. ПАЧЕКО К. Язык программирования Delphi и платформа .NET. Руководство разработчика. Пер. с англ. М.: Издательский дом «Вильямс», 2005. - 960 с., - Парал. тит. англ.
10. ПЕРРОУН П. ДЖ., ВЕНКАТА С. Р., ЧАГАНТИ «КРИШНА» Р. Создание корпоративных систем на основе Java 2
Enterprise Edition. Руководство разработчика. Пер. с англ. М.: Издательский дом «Вильямс», 2001. - 1184 с.: ил. - Па-рал. тит. англ.
11. ПРИЧАРД ДЖ. COM и CORBA. Просто и доступно. М.: Лори, 2001. - 384 с.
12. РИХТЕР ДЖ. CLR via C#. Программирование на платформе Microsoft .NET Framework 2.0 на языке С#. Мастер-класс. / Пер. с англ. М.: Издательство «Русская Редакция»; СПб.: Питер, 2007. - 656 с.
13. СИНЕЛЬНИКОВ В. И., ОЛЕЙНИК П. П. Методика выбора языка программирования для реализации программного продукта // Автоматизация и современные технологии. Ежемесячный межотраслевой научно-технический журнал. 2007. №7. С. 27-34.
14. ТЕЙКСЕЙРА С., ПАЧЕКО К. Borland Delphi 6. Руководство разработчика. Пер. с англ. М.: Издательский дом «Вильямс», 2002. - 1120 с. - Парал. тит. англ.
15. ТРОЕЛСЕН Э. Язык программирования C# 2005 и платформа .Net 2.0. 3-е издание. Пер. с англ. М.: ООО "И. Д. Вильямс", 2007. - 1168 с. - Парал. тит. англ.
16. ФАУЛЕР М. Архитектура корпоративных программных приложений. Пер. с англ. М.: Издательский дом «Вильямс», 2004. - 544 с. - Парал. тит. англ.
17. ЦИМБАЛ А. А. Технология CORBA для профессионалов. СПб.: Питер, 2001. - 624 стр.
18. BEA SYSTEMS. BEA Tuxedo. Creating CORBA Client Applications, http://edocs.bea.com/tuxedo/tux80/pdf/clients.pdf
19. BEA SYSTEMS. BEA Tuxedo. Creating CORBA Server Applications, http://edocs.bea.com/tuxedo/tux80/pdf/servers.pdf
20. BLAKE C. Run Time Compiler, http://www.csharpcorner.com/ UploadFile/ChrisBlake/RunTimeCompiler12052005045037AM/ RunTimeCompiler.aspx
21. BOLAND D. Pluggable Remote Object Hosting, http://www.codeproject.com/csharp/dbremoteplugins.asp
22. BORLAND CORP. Borland AppServer б.б. Developers Guide, http://techpubs.borland.com/am/appserver/vбб/ja/
as devguide.pdf
23. BORLAND CORP. VisiBroker 7.0. VisiBroker for C++. Developers Guide, http://techpubs.borland.com/am/visibroker/ v70/en/vb cppdg-R1.pdf
24. GARMANY J., BURLESON D. K. Oracle Application Server 1Qg Administration Handbook, ORACLE Press Series, Osborne, 2004, 400 p.
25. INPRISE CORPORATION. Inprise Application Server. Руководство программиста Enterprise JavaBeans, 187 c., http://www.javaportal.ru/java/tutorial/ EJBProgrammersGuide.pdf
26. IONA TECHNOLOGIES. Orbix. CORBA Tutorial Java, httpV/www.iona.com/support/docs/orbix^J/tutorials/java/ tutorial java.pdf
27. MICROSOFT CORP. Application Server: Frequently Asked Questions, http://www.microsoft.com/windowsserver2003/ techinfo/overview/appservfaq.mspx
28. MICROSOFT CORP. ReaderWriterLock- класс, http://msdn.microsoft.com/librarv/rus/default.asp?url=/librarv/ RUS/cpref/html/frlrfSvstemThreadingReaderWriterLockClassT opic.asp
29. OSHEROVE R. Creating a Plug-In Framework, http://msdn.microsoft.com/librarv/default.asp?url=/librarv/ en-us/dnaspp/html/pluginframework.asp
30. POORE E. C# Script for .NET 2.Q, http://codeproject.com/csharp/CSharpScript.asp
31. SUN MICROSYSTEMS INC. MIGRATING TO SUN JAVA™ SYSTEM APPLICATION SERVER S, http://www.sun.com/software/products/appsrvr/wp as8.pdf
Статья представлена к публикации членом редакционной коллегии М.В. Губко
