Технология клиент-сервер в корпоративных системах на базе M-технологии

Данная статья посвящена разработке корпоративных приложений на базе M-технологии. Вместо общих вопросов, связанных с выбором подходящего способа распределения компонентов модели клиент-сервер речь в ней пойдет о конкретных методах и средствах их решения на основе одного из инструментальных средств - MSM-Workstation for Windows.

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

Прежде всего, не оправдались надежды на то, что корпоративная система, построенная по технологии клиент-сервер, обойдется дешевле. Не стоит углубляться в подсчеты затрат на электроэнергию, аппаратуру и программное обеспечение, поскольку главная причина их роста - усложнение системного сопровождения и администрирования [1].

Далее, несмотря на то, что системы клиент-сервер хорошо справляются с большими базами данных, рост количества приводит к потере качества, когда БД оказываются очень велики (миллионы записей). Тиражирование данных, часто предлагаемое для решения проблемы производительности, является потенциально опасным: при наличии нескольких копий данных может наступить момент, когда они перестанут совпадать, несмотря на все принятые для синхронизации меры. А значит, "...все усилия, потраченные на синхронизацию, окажутся бесполезными, даже если эта работа делается очень быстро". Поэтому мэйнфрейм рассматривается как альтернатива решению клиент-сервер в тех случаях, когда последнее приводит к тиражированию данных (например, совместная работа нескольких крупных групп пользователей, разбросанных по городам и весям, с единой БД) [2].

Если даже смириться с ростом стоимости рабочего места (учитывая, что вместе с архитектурой клиент-сервер возник ряд принципиально новых видов услуг, например, возможность анализа выборок из центральной БД силами конечных пользователей [1]), то с недостаточной масштабируемостью можно и нужно бороться. Особенно это актуально при отсутствии положительного опыта эксплуатации систем хост-терминал, что типично для России (хотя бывают и исключения).

Заглянем поглубже...

Один из подходов к решению перечисленных проблем основан на более детальном анализе взаимодействия между клиентом и сервером [3]. Сервер характеризуется видом оказываемой услуги, центральное место в корпоративных системах занимают серверы баз данных и серверы приложений. Традиционным стал взгляд на технологию клиент-сервер как на систему трех взаимодействующих компонентов: представление (или front-end) - реализует функции ввода и отображения данных; приложение (business-logic) - объединяет чисто прикладные функции, характерные для предметной области; СУБД (resource manager) - управляет доступом к данным, контролирует целостность БД и т.д.

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

Первая модель самая простая, именно она нашла воплощение в первых реализованных проектах. Главное ее достоинство - обилие инструментальных средств разработки приложений для Windows, работающих с SQL-серверами через стандартный интерфейс ODBC. Что касается недостатков, то, пожалуй, большая часть критических замечаний, высказанных в адрес всей технологии, на самом деле относится именно к этой модели: плохой отклик из-за чрезмерной загрузки сети невозможность удовлетворительного администрирования приложений. Причина этого неприятного явления в том, что различные по своей природе функции смешиваются в одной программе. При коллективной работе над проектом, когда, каждый разработчик автоматизирует "свои" типы рабочих мест, становится в высшей степени сложно контролировать взаимную непротиворечивость алгоритмов обработки данных, встраиваемых в многочисленные компоненты front-end. Аналогичные трудности возникают и при необходимости внесения сквозных изменений в проект.

В основе второй модели лежит механизм хранимых процедур - средство программирования ядра СУБД. Сегодня этот механизм реализован во всех SQL-серверах, представленных на рынке. Прикладной компонент оформляется как набор хранимых процедур языка SQL и переносится на компьютер - сервер БД. Преимущества такого подхода очевидны: снижается трафик сети, появляется возможность централизованного администрирования функций обработки данных, а также их разделения несколькими приложениями. Недостатки же связаны с тем, что процедурное расширение SQL не является полноценным языком программирования. Отсутствие средств отладки и тестирования хранимых процедур в большинстве СУБД может превратить их в потенциально опасный механизм. Поэтому на практике в виде хранимых процедур обычно реализуются лишь простейшие функции, тесно связанные с доступом к данным, в то время как большая часть обработки данных по-прежнему осуществляется на компьютере-клиенте. Такая "смешанная" модель сегодня, пожалуй, применяется наиболее широко, однако для разработки систем масштаба предприятия она оказывается малопригодной даже в случае удовлетворительного решения проблемы комплексной отладки обеих частей распределенного приложения. Дело в том, что ядро типичной СУБД, ориентированной на SQL, не совсем подходит для организации баланса загрузки серверов, миграции процедур между серверами, выполнения приоритетных запросов и т.д.

Достаточно традиционным методом решения проблем, свойственных двухзвенным моделям, стало выделение третьего звена - сервера приложений. Программное обеспечение, используемое для создания серверов приложений, часто относят к категории "middleware". В мире реляционных СУБД это TUXEDO system, Microsoft Transaction Server, Digital ACMS и других. Мониторы транзакций являются посредниками между клиентами и СУБД, позволяя сделать прикладную систему независимой как от конкретной реализации пользовательского интерфейса, так и от СУБД. Кроме того, они обеспечивают баланс загрузки, а также возможность динамической реконфигурации системы без остановки серверов приложений.

Однако, как справедливо замечено в работе [4], высокая производительность "реляционной" трехзвенной прикладной системы если и достижима, то ценой значительных затрат на покупку дополнительного ПО и мощных компьютеров класса "сервер". Затраты на ПО связаны не столько с приобретением самих серверов приложений, сколько с необходимостью значительных инвестиций в инструментальные средства разработки. В любом случае для эффективной реализации каждого из трех компонентов приходится использовать различные подходы и языки программирования (в качестве типичной "тройки" можно назвать Visual Basic, Cи и расширенный SQL), а значит, о простоте и концептуальном единстве такой системы говорить трудно.

А нельзя ли попроще?

Является ли проблема масштабируемости архитектуры клиент-сервер труднопреодолимой в принципе, либо же сказываются издержки традиционных технологий, ориентированных на SQL? Посмотрим, как обстоит дело в случае MSM (одной из реализаций M-технологии [4, 6]).

"Изюминка" M-технологии в том, что серверы баз данных способны удовлетворять запросы к данным на более низком уровне, чем оператор SQL SELECT [6], а именно, на уровне глобальных массивов. Глобальный массив является расширением понятия массива: как индексы, так и данные могут быть строками переменной длины, причем реально хранятся только те элементы массива, которым присвоены значения. Интересно, что в М-языке поддерживается аналогичная структура для хранения информации в оперативной памяти (в этом случае говорят о локальных массивах). Наличие подобных структур вкупе с богатым набором операций над ними позволяет достичь такого уровня привязки к предметной области, что необходимость в поисковых запросах, которые "трясут" базу данных, как правило, удается свести к минимуму. Вместо этого используется так называемая навигация, когда при каждом обращении к БД извлекается заведомо релевантная запись, что исключает издержки, связанные с проверками и дополнительными операциями доступа к данным. На данной стадии изложения достаточно оценить важность отказа от запросов в пользу навигации, существенно снижающей нагрузку на все компоненты системы (в частности, на сеть), а значит, расширяющей "радиус действия" двухзвенных моделей (в особенности - первой из них). Поэтому необходимость в третьем звене у М-разработчика возникает значительно позже, чем у его SQL-коллеги.

Процедурной основой различных вариантов моделей клиент-сервер на базе MSM является использование единого языка (М) и связанной с ним технологии для реализации всех серверных компонентов - как приложения, так и управления базой данных. Интересно, что этот же язык, дополненный средствами интерфейса с Windows (MWAPI), может использоваться и для создания компонента представления. Благодаря наличию открытых интерфейсов (API) с инструментами третьих фирм выбор М для этой цели не является чем-то навязанным. Однако многие разработчики, стремясь к простоте, гибкости и максимальной производительности, выбирают М в качестве единственного языка для всех компонентов системы (кстати, из всех присутствующих на рынке М-систем такая возможность имеется только в MSM).

В основе взаимодействия MSM-компонентов лежит протокол распределенного кэширования дисковых блоков БД, носящий название RVG (Remote Volume Groups) [7, 8]. Протокол выполняется на сеансовом уровне модели ISO-OSI и может использоваться поверх наиболее распространенных транспортных протоколов (TCP/IP, UDP/IP, SPX, IPX). Главным его достоинством является предоставление доступа к актуальной копии каждого блока БД независимо от местонахождения клиента (или сервера приложений) в сети, причем обновление блока происходит лишь в месте его хранения - на сервере БД. Таким образом, появляется возможность эффективного распределения по сети компонента управления данными, что и позволяет во многих случаях обеспечить оптимальное время отклика даже в рамках первой модели клиент-сервер ("удаленные данные"). Как показали тесты, MSM-RVG в 2-5 рaз обгоняет аналогичные протоколы, реализованные в других М-системах (ISM, DTM, DSM). Однако ценность программно-технических основ MSM была бы невелика при отсутствии средств поддержки разработки. Имеющиеся средства и методы можно отнести к одной из следующих функциональных групп:

• MSM-Workstation for Windows - набор инструментальных средств для М-программирования представительских и прикладных компонентов; поддерживает различные методы интеграции с "не-М" приложениями. Позволяет строить наиболее производительные системы клиент-сервер c использованием М в двух-трех звеньях, связанных протоколом RVG.
• MSM-SQL - дополнительный пакет, обеспечивающий реляционный взгляд на базу данных произвольной структуры; в качестве front-end может использоваться какой-либо генератор отчетов общего назначения (Access, Crystal Reports, ReportSmith, The Reporter и др.) или специализированная программа, разработанная с помощью любого популярного инструмента (Power Builder, Delphi, и др.). Единственное требование к front-end - поддержка стандарта ODBC. С применением MSM-SQL связан, пожалуй, наименее трудоемкий метод интеграции с Windows традиционных приложений MSM, изначально ориентированных на текстовый пользовательский интерфейс (CHUI).
• MSM-PDQweb - средство, открывающее доступ к БД MSM через WWW. Позволяет разрабатывать корпоративные приложения на основе Internet/intranet, используя в качестве front-end обычный браузер

MSM-Workstation - инструментарий для разработки двух- и трехзвенных приложений клиент-сервер содержащий следующие компоненты:

• GUI-оболочка, поддерживающая основные функции управления системой и объединяющая остальные компоненты SDK;

• собственный конструктор GUI-приложений (Builder);

• традиционные средства программирования CHUI и фоновых задач;

• библиотека интерфейса прикладного программирования MSM-API, позволяющая разрабатывать front-end практически на любом языке (Visual Basic, C++, Delphi, Java и т.д.).

Может возникнуть вопрос о целесообразности включения в состав CDK собственного GUI-конструктора. Зачем понадобилось выпускать подобную систему для М? Не лучше ли использовать каждый продукт для выполнения наиболее подходящих для него задач, например, разработать на Delphi front-end, а на М - функциональное наполнение, связав Delphi-код с М-кодом через MSM-API?

Как следует из состава MSM-Workstation, "внешний" подход к разработке GUI фирмой поддерживается, и для знатоков той или иной визуальной среды вполне может стать быстрым стартом в освоении М-технологии. Некоторое знание М все же потребуется для написания функций обработки данных, но, как показывает опыт, львиная доля временных затрат уходит на отладку диалоговых процедур - на создание компонента front-end, а значит, затраты на М-программирование будут не так уж велики. MSM-API позволяет выполнять на сервере как низкоуровневые операции (на уровне команд языка М), так и высокоуровневые вызовы М-функций. В последнем случае возможна передача до 4Гбайт данных за одно обращение. С MSM-API можно работать не только путем прямых вызовов процедур из DLL-библиотеки, но и посредством управления OLE-объектом M.Command. Основными методами являются M.Login (зарегистрироваться на сервере), M.Do (выполнить на сервере М-функцию и получить результат) и M.Xecute (исполнить строку команд). Используя системную утилиту, администратор сервера может централизованно управлять прикладными функциями, составляя таблицы допустимых функциональных вызовов для различных категорий клиентов, что позволяет добиться высокого уровня безопасности системы.

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

Таким образом, поместив MSM "на задний план", разработчики приложений для Windows получают скоростной "мотор баз данных" с легко наращиваемой функциональностью. Однако зачем же нужна еще одна среда визуального программирования? Чтобы ответить на этот вопрос, потребуется чуть подробнее рассмотреть процесс клиент-серверного взаимодействия. Как уже говорилось, "чистое" разделение функций между компонентами представления и приложения встречается редко. Обычно создается некоторый промежуточный вариант распределенного приложения. Происходит это из-за тесной связи части прикладных функций с обработкой диалоговых воздействий пользователя, которые зачастую инициируют операции, требующие интенсивного обмена с базой данных, например, вывод динамически обновляемого списка для выбора подходящего значения реквизита. Обратите внимание, что необходимость в обращениях к прикладным функциям возникает уже в процессе заполнения экранной формы, задолго до нажатия кнопки "ОК".

Реализация такого высокоинтерактивного рабочего места (часто называемого "толстым" клиентом) возможна и в рамках описанной гибридной схемы с помощью MSM-API. Однако задача эта оказывается весьма трудоемкой в силу того, что у программиста появляется немало дополнительных забот. Начать с того, что приходится уделять внимание согласованию структур данных двух различных языков программирования (например, ни в VB, ни в Delphi вы не найдете аналога разреженного массива со строковой индексацией, "родного" для М). Далее, не удается в полной мере использовать сервис инструмента разработки front-end. В частности, такая удобная и общепризнанная возможность, как привязка объектов экранной формы к структурам данных, для внешних (по отношению к front-end) переменных М работать не будет. И наконец, из-за отсутствия MSM на клиенте отсутствует и механизм локального кэширования данных, поступающих через стык "клиент - сервер приложений", а значит, забота о минимизации обращений к серверу также ложится на плечи программиста.

Полезно заметить, что при создании "тонких" клиентов, осуществляющих лишь минимальную обработку пользовательского ввода, перечисленные трудности не являются камнем преткновения. О сетевом трафике можно особенно не беспокоиться: как правило, он оказывается не намного выше, чем при обмене с терминалом. Прикладной уровень интерфейса с сервером сводится к передаче результатов ввода и приему результатов обработки (несколько напоминая обслуживание терминала в традиционной системе типа "Query-by-form"). Однако при создании "толстых" клиентов трудоемкость программирования пользовательского интерфейса резко возрастает, и упомянутые проблемы проявляются в полной мере. Ответом фирмы Micronetics стало включение в SDK полностью интегрированной среды разработки М-приложений для Windows.

Внешний вид среды разработчика (Builder) напоминает решения в аналогичных продуктах - набор элементов управления традиционный (поле, различные виды списков, документ, кнопка, радио-кнопка, меню, таймер, и т.д.), равно как и событийно-ориентированный подход к программированию GUI.

Что еще, кроме привычной среды разработки, получает программист вместе с MSM-Workstation? Прежде всего, появляется возможность реализации двух- и трехзвенных приложений клиент-сервер, выполненных целиком на одном языке. Пропадает необходимость согласований данных на межязыковом стыке, что экономит и человеческие, и машинные ресурсы. Облегчается создание сложных сценариев диалога благодаря разнообразным механизмом привязки элементов управления к локальным и глобальным структурам данных М. Единый синтаксис обращения к данным и механизм распределенного кэширования (RVG) позволяет добиться полной прозрачности доступа к данным независимо от места их хранения - на клиенте или на сервере. Как правило, необходимость в минимизации обращений к БД отсутствует - протокол RVG достаточно эффективен, однако дальнейшая оптимизация путем размещения временных данных или данных "только для чтения" на ПК-клиенте конечно тоже возможна.

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

М-программистам будет интересно узнать, что вместе с MSM-Workstation в М пришел новый уровень открытости. Теперь M-программы могут выступать не только в качестве серверов автоматизации OLE, но и в качестве контроллеров. Это означает, что М-задача, выполняющаяся под Windows, может управлять другими объектами OLE, такими как Word.Basic или Excel.Application. Кроме того, начиная с Workstation версии 2.0, появляется возможность встраивания в М-код объектов ActiveX. Поддержка OLE 2 и ActiveX позволяет существенно повысить производительность труда разработчиков за счет использования в новых программах существующих компонентов.

Заключение

Проницательный читатель, вероятно, сочтет, что возможностей протокола RVG, рассчитанного прежде всего на организацию эффективного обмена с удаленной БД, маловато для успешного взаимодействия между клиентом и сервером приложений в трехзвенной схеме, когда нужен не запрос к данным, а удаленный вызов процедуры. И будет прав. Действительно, RVG приспособлен главным образом для обслуживания стыков "сервер приложений - сервер БД" в трехзвенной модели и "клиент - сервер БД" в двухзвенной. Но, во-первых, благодаря высокой эффективности RVG диапазон использования двухзвенных моделей в М-технологии на порядок шире, чем в случае применения SQL, а во-вторых, MSM-API позволяет связывать М-сервер с М-front-end точно так же, как и при реализации последнего на каком-либо другом языке программирования. М-клиент выступает в этом случае как контроллер OLE-автоматизации, управляющим удаленным М-сервером теми же самыми методами (M.Login, M.Do и т.д.).

Несмотря на новизну MSM-Workstation, уже сегодня можно привести примеры успешно начатых проектов. В США с ее помощью разрабатывается система распределенного ведения БД членов ACM. Общественная организация со скромным бюджетом пока не может позволить себе централизованный сервер, доступный в режиме on-line, поэтому журналы обновлений БД распространяются по e-mail, хотя переход на "настоящий" клиент-сервер тоже возможен [9]. Похожая ситуация с разрабатываемой во Львове инфоpмационно-спpавочной системой по международным, европейским и национальным стандартам для предприятий Украины. В обоих случаях программное обеспечение выполнено полностью на М.

Можно привести примеры и помасштабнее. Kaiser Permanente (США), крупнейшее в мире медицинское учреждение, на сегодняшний день эксплуатирует систему на 2500 рабочих мест, опирающуюся на 22 сервера RS6000, работающих под управлением MSM-UNIX. Большинство рабочих мест представляют собой терминалы, подключенные через локальную сеть по LAT-протоколу. Благодаря удачному архитектурному решению - система сразу была выполнена по технологии клиент-сервер с выделением серверов приложений и серверов БД - переход к GUI протекает плавно, без глубокой структурной перестройки системы. В качестве инструмента разработки front-end используется Workstation/Builder, в качестве языка - М [10].

Медицинские информационные системы, построенные по технологии FileMan/Kernel, сегодня используются в 164 больницах Министерства по делам ветеранов США (VA), в 199 госпиталях Министерства обороны США (DoD), а также во многих организациях по всему миру. В России подобные системы в области здравоохранения внедрялись не слишком широко, крупнейшая установка (на 200 рабочих мест) функционирует в поликлинике Новокузнецкого АО "ЗапсибМетКомбинат". Системы на базе FileMan широко применяются в Финляндии и в Польше. Типичная инсталляция содержит от нескольких сотен до тысячи рабочих мест, обслуживаемых десятком ПК-серверов с MSM-PC/Plus (или иной М-системой). Способ реализации графического интерфейса, предложенный авторами ядра системы (VA), предполагает использование Borland Delphi для создания front-end и RPC-брокера собственной разработки для подключения основных прикладных функций.

В ближайшее время список удачных корпоративных М-решений в духе клиент-сервер будет пополняться, тем более, что начать работу можно уже сегодня, получив бесплатную исследовательскую версию с сервера http://www.escape.ru.

"СП. АРМ", Санкт-Петербург

Литература