Borland MIDAS

Borland MIDAS - средство надежной и эффективной эксплуатации многозвенных информационных систем

Наталия Елманова, Центр Инфомационных Технологий
MIDAS (Multi-tier Distributed Application Services Suite) новый продукт компании Borland International, предназначенный для эксплуатации серверов приложений, расширяющий возможности, предоставляемые технологией Microsoft DCOM (Distributed Component Object Model). Этот продукт позволяет использовать при построении информационных систем трехзвенную архитектуру с "тонким" клиентом и, что более важно, обеспечить высокую производительность, надежность и защиту от сбоев при эксплуатации подобных систем.
Архитектура трехзвенной информационной системы, построенной с использованием MIDAS, представлена на рис.1.

Рис.1. Архитектура трехзвенной информационной системы с использованием MIDAS.
Рассмотрим, что представляют собой технологии, используемые в MIDAS.
Remote Data Broker позволяет создавать распределенные трехзвенные информационные системы, состоящие из серверной СУБД, среднего звена и "тонкого" клиента, при этом среднее звено может в общем случае состоять из нескольких серверов приложений и функционировать на нескольких компьютерах. Заметим, что "тонкий" клиент представляет собой приложение, не содержащее бизнес-правил, а лишь предоставляющее интерфейс пользователя, и по этой причине не требующее почти никаких дополнительных библиотек (кроме dbclient.dll размером 140 K), используемых обычными "толстыми" клиентами для доступа к данным (таких, как Borland Database Engine и клиентская часть серверных СУБД) и, соответственно, практически не нуждающееся в соответствующей настройке. Типичным примером такого клиентского приложения является исполняемая в Web-броузере форма ActiveX (созданная с помощью Delphi 3), содержащая интерфейсные элементы для отображения и редактирования данных, вся процедура инсталляции и настройки которого заключается в загрузке соответствующей Web-страницы из Internet или локальной сети.
Источником данных для "тонкого" клиента является сервер приложений, получающий от клиента запросы на выборку или изменение данных.
При получении такого запроса сервер приложений обращается к серверу баз данных, клиентом которого он является, со своим собственным запросом. Получив от сервера результат выполнения собственного запроса, сервер приложений передает данные клиенту.

Как только клиент получает набор данных от сервера приложений, этот набор может быть использован компонентом TClientDataset, который, наряду с компонентами TRemoteServer или TMidasConnection (появившимся в Delphi 3.01 и обладающим по сравнению TRemoteServer большей функциональностью, в частности, возможностью выбора способа доступа к серверу), а также поддерживающей их функционирование библиотекой dbclient.dll, составляет клиентскую часть Remote DataBroker.

Компонент TClientDataSet предназначен для хранения данных, полученных от сервера приложений, в кэше клиента, и, будучи потомком компонента TDataSet, обладает, подобно компонентам TTable и TQuery, как навигационными методами, так и методами, осуществляющими редактирование данных. Кроме того, этот компонент обладает методами SaveToFile и LoadFromFile, позволяющими сохранять данные из кэша в файле и восстанавливать их оттуда, реализуя так называемую "briefcase model" - модель обработки данных, основанную на том, что "тонкий" клиент осуществляет редактирование данных по большей части при отсутствии соединения с сервером, используя лишь кэш или локальные внешние устройства, и лишь иногда соединяется с сервером приложений для передачи ему измененных данных с целью дальнейшей обработки.

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


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

Отметим также, что удаленные модули данных (объекты Remote Data Module), входящие в состав серверной части Remote DataBroker и содержащие компоненты TDBDataSet, позволяют предоставить DCOM-интерфейс для соответствующих объектов, делая их управляемыми извне и превращая, таким образом, сервер приложений в DCOM-сервер. Осуществляется такая публикация объектов путем выбора опции экспорта из удаленного модуля данных из контекстного меню соответствующего компонента при разработке сервера приложений.

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


Использование Business ObjectBroker и OLEnterprise ( составной части MIDAS) позволяет решить подобную проблему (при этом несущественно, какое средство разработки использовалось для создания сервера приложений, лишь бы это был сервер OLE Automation).



Рис. 2. Состав OLEnterprise.

Business ObjectBroker осуществляет для "тонкого" клиента поиск нужного сервера приложений среди опубликованных (то есть доступных извне) частей реестров компьютеров сети (совокупность опубликованных частей реестров иногда называется глобальным реестром - global registry).

Приложение Object Factory, используемое сервером, является клиентом OLE Automation. Оно действует на сервере от имени удаленного клиента, "представляя" его путем воспроизведения его запросов. Со стороны клиента имеется соответствующий "представитель" удаленного сервера приложений - Object Agent, являющийся сервером OLE Automation. Получив запрос к удаленному серверу, Object Agent направляет его к Object Factory, используя механизм вызова удаленных процедур (RPC - Remote Procedure Call).



Рис.3. Object Explorer

Утилита Object Explorer (рис.3), входящая в состав OLEnterprise, позволяет просматривать локальный и глобальный реестры, а также осуществлять экспорт (публикацию) сведений об объектах из локального реестра в глобальный и импорт этих сведений из глобального реестра в локальный, осуществляя, таким образом, межреестровый обмен сведениями об удаленных серверах приложений в сети. Если в сети имеется несколько компьютеров, на которых установлен и зарегистрирован один и тот же сервер приложений, при запросе "тонкого" клиента Object Agent обратится к Business ObjectBroker за сведениями о местоположении сервера, а тот, в свою очередь, найдет для него в глобальном реестре один из этих компьютеров. После этого Object Agent обратится к Object Factory выбранного компьютера, инициируя создание экземпляра удаленного модуля данных на сервере приложений.

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


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

Отметим также, что в глобальный реестр можно включать сведения об RPC-серверах, функционирующих не только в операционных системах Windows 95 и Windows NT, но и в других операционных системах.

Еще одной важной составляющей частью MIDAS является ConstraintBroker, предоставляющий возможность использовать бизнес-правила сервера баз данных "тонким" клиентом. Обычно при проектировании баз данных бизнес-правила и правила ссылочной целостности реализуются в виде объектов базы данных, таких как индексы, триггеры, хранимые процедуры. Такой подход к проектированию данных позволяет использовать эти объекты различными клиентскими приложениями без написания дополнительного кода.

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

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


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

При использовании ConstrainBroker эта проблема решается по-другому. В этом случае RemoteDataBroker не только доставляет данные клиентскому приложению, но и обращается к словарю данных с целью получения ограничений сервера и передачи их клиенту. Соответственно при попытке передачи записи на сервер приложений анализ соответствия записи правилам сервера производится непосредственно в клиентском приложении без обращения к серверу баз данных и серверу приложений, что снижает загрузку серверов и сети. Отметим, что при изменении бизнес-правил следует внести соответствующие изменения в словарь данных, что можно сделать с помощью входящей в состав MIDAS утилиты SQL Explorer(рис.4), позволяющей вносить серверные ограничения, а также создавать и изменять таблицы, индексы, триггеры, хранимые процедуры, правила ссылочной целостности.



Рис.4. SQL Explorer

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

В заключение отметим, что разработка серверов приложений с помощью Delphi 3 может быть осуществлена с помощью trial-версии MIDAS, входящей в комплект поставки Delphi 3 Client/Server Suite и имеющей ограниченное число подключаемых клиентов и объектов, доступных Business ObjectBroker, а также ограничения на время работы ConstrainBroker. Однако эксплуатация серверов приложений требует обязательного наличия на компьютерах, содержащих серверы приложений, полной версии MIDAS (рис.5), не обладающей вышеперечисленными ограничениями.



Рис.5. Состав Borland MIDAS

Последнее обновление - 3 апреля 1998

Интеграция объектов

Некоторые мониторы транзакций могут эффективно работать с объектами. В этом отношении выделяется Microsoft Transaction Server (MTS). Продукт строго интегрирован с DCOM. По-существу, любой объект ActiveX может управляться и кэшироваться с помощью MTS. Это позволяет более просто осуществлять разделение объектов, поскольку существующие компоненты, построенные с помощью Visual Basic, или J++, могут быть легко приспособлены для управления сервером. MTS сохраняет "жизнеспособность" объектов для их повторного использования, устраняя потребность в постоянном создании объектов при запросе сервиса. По очевидным причинам MTS тесно привязан к , но надежность и низкая стоимость продукта делают его очень привлекательным. Компания Microsoft проделала отличную работу по интеграции Java и ActiveX - можно использовать все Java-объекты. Это облегчает интеграцию MTS в многоплатформенные среды.
В мире UNIX спецификация OMG Object Transaction Server (OTS) направлена на унификацию функций TP-мониторов при использовании брокеров объектных заявок. Это расширение протокола CORBA нашло отражение в спецификации Java Transaction Service компании JavaSoft. Коммерческий дебют этой спецификации состоялся в феврале с выпуском компанией Sybase продукта Jaguar Component Transaction Server.
Другим влиятельным стандартом, который необходимо учитывать при оценке TP-мониторов и серверов приложений, является Transation Architecture (XA), спецификация, разработанная компанией . XA определяет интерфейс между менеджером транзакций и используемыми им ресурсами, такими как системы баз данных и коммуникационные каналы. Большинство UNIX-ориентированных TP-мониторов и систем баз данных поддерживает этот стандарт. Поддержка на платформах Windows NT отстает, но MTS развивается в этом направлении.
Нужно также принимать во внимание коммуникационный протокол, используемый сервером приложений. Серверы, которые тесно привязаны к RPC (или DCOM в случае MTS), могут быть ограничены синхронной природой работы. Продукты, позволяющие использовать очереди сообщений, часто обладают большей гибкостью, особенно в случае ориентации на широкомасштабные сети. Например, в мониторе Encina может использоваться промежуточное программное обеспечение MQSeries компании IBM. Компания Microsoft намерена интегрировать MTS и Message Queuing Server в будущих версиях.

IPC и объекты

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

Вызовы удаленных процедур (RPC - Remote Procedure Call) и соответствующий Java-эквивалент, вызовы удаленных методов (RMI - Remote Method Invocation. Эти протоколы позволяют приложению вызывать функции и передавать параметры, минуя границы процессов и машин. Более распространены синхронные механизмы, т.е. каждая операция должны закончиться до начала следующей. Такие сервисы обеспечиваются операционной системой или языковой средой разработки. Обычно RPC базируются на инфрастуктуре распределенной вычислительной среды (DCE - Distributed Computing Environment).

Системы передачи сообщений. В отличие от RPC такие системы, как правило, бывают асинхронными. Запросы сервисов ставятся в очередь и обрабатываются в соответствии с приоритетами и доступностью ресурсов. Возвращаемые ответы содержат информацию об успешном или неуспешном выполнении операции. Средства этой категории часто используются в приложениях, связанных с организацией потоков работ (workflow) и управлением процессами, а также в сильно распределенных приложениях с медленными и ненадежными соединениями.

Распределенные объектные системы. Объектные системы обеспечивают средства размещения и взаимодействия объектов в распределенной среде. Объекты идентифицируются именами или сервисами, а также поддерживаемыми ими интерфейсами. Реализация объекта и платформа, на которой он выполняется, прозрачны для клиента.
В последней из перечисленных областей бушует война. При поверхостном взгляде видно сражение технологий Distributed COM и ActiveX компании Microsoft с технологиями CORBA и IIOP (Internet InterORB Protocol) консорциума и JavaBeans. При более глубоком рассмотрении эта битва отражает борьбу между открытостью, зрелостью и масштабируемостью и возрастающей силой . Итеропетабельность между этими стандартами достигается медленно.
Объекты - это реальная основа современных многозвенных приложений. Во всех обсуждаемых ниже продуктах более высокого уровня основным является управление объектами. Планирование стратегии предприятия в терминах объектов и компонентов позволит наилучшим образом применить эту быстро развивающуюся технологию.

MIDAS и создание серверов приложений: вопросы и ответы

Наталия Елманова, Центр Инфомационных Технологий
После выхода статьи от читателей и слушателей проводимых в Учебно-консалтинговом центре Interface Ltd. курсов, посвященных Delphi 3 и MIDAS, поступило большое количество вопросов, касающихся технических и организационных аспектов разработки и эксплуатации трехзвенных информационных систем с "тонким" клиентом. Данная статья посвящена особенностям и наиболее предпочтительным архитектурам построения подобных информационных систем в случае различных схем организации функционирования обслуживаемых ими предприятий, новым возможностям создания "тонких" клиентов, предоставляемым Delphi 3.01/3.02 и С++Builder 3.0, ответам на наиболее часто встречающиеся вопросы, а также наиболее распространенным ошибкам при создании серверов приложений и "тонких" клиентов.

Мониторы управления транзакциями

Интенсивное совместное использование ресурсов приводит к возникновению узкого места, затрудняющего выполнение работ. Многие ранние попытки использования архитектуры "клиент-сервер" в масштабах предприятия провалились в результате неадекватного управления ресурсом баз данных. Ранние эксперименты по использованию РСУБД для управления динамическим содержимым Web-страниц постигла та же судьба и по тем же причинам. Во многих случаях проблема не была связана с реальной обработкой операторов SQL. Неприятности возникали по причине отсутствия должного управления соединениями с базами данных и применения неэффективных методов хэширования.
Начиная с CICS (Customer Information Control System) компании , созданной в начале 1970-х, был разработан ряд систем для управления ресурсом баз данных и транзакциями. Успех этих продуктов демонстрируется тем, что лучшие 20 результатов, полученных на тестовом наборе (измеренных в числе транзакций в минуту 2 февраля 1998 г.), получены с примением технологии промежуточного программного обеспечения баз данных. При отборе на основе параметра цена/производительность в 18 из лучших 20 результатов использовались .
TP-мониторы получили развитие по следующим причинам:

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

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

Установление соединения с базой данных часто происходит медленно. Если много пользователей часто подключается и отключается, производительность системы серьезно деградирует.
Эти проблемы решаются в TP-мониторах следующим образом:

Обеспечивается одновременная связь с набором различных систем баз данных.

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

Пользовательские запросы обрабатываются с использованием легковесных нитей (threads) операционной системы, а не полновесных процессов.
Это позволяет TP-мониторам использовать возможности SMP-систем (SMP - Symmetric MultiProcessor), таких как Sun Enterprise, Digital Alpha и Compaq Proliant.

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

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

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

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

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

Для координации операций разделенных и распределенных приложений поддерживается одноранговая связь с другими мониторами обработки транзакций.

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


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

На арене открытых систем в категории TP-мониторов лидирует Tuxedo компании . Вышедший из компании Novell в феврале 1996 г., этот надежный и зрелый продукт использовался примерно в 80% упоминавшихся выше результатах TPC-C. В 1997 г. продукт стал победителем конкурса журнала DBMS Readers' Choice на лучший монитор транзакций. Среди других продуктов этой категории следующие:

Encina компании (победитель конкурса DBMS 1996 г.)

Продукты семейства Transaction Server компании IBM (включая CICS и Encina)

ACMSxp компании

Top End компании (распространяемый компаний )

Trnasaction Server компании Microsoft.

Некоторые другие вопросы

Посмотрел Вашу статью: . Очень понравилось. Не могли бы Вы уточнить, как вручную отредактировать реестр (какие ключи добавить или отредактировать), чтобы OLE-объект воспринимался не как локальный, а как удаленный? К сожалению, из статьи я этого не смог понять.
С уважением Алексей Гудков,

ОАО ИК "РИФ"
В принципе это делается с помощью утилиты DCOMCNFG (в Windows NT 4 она есть, а для Windows 95 можно найти и эту утилиту, и сам клиент DCOM на Web-сервере Microsoft). Но если осуществлять соединение клиента и сервера с помощью DCOM, сервер при этом не сможет работать под управлением Windows 95. Кроме того, требуется на странице Access Control раздела Network в Control Panel выбрать опцию User Level Access Control, что отличается от установок, принятых по умолчанию, а также экспортировать с первичного контроллера домена сведения о пользователях, а затем описать, кому из них Вы разрешаете этот сервер запускать. Естественно, в сети при этом обязательно должен быть первичный контроллер домена.
С помощью OLEnterprise (в частности, Object Explorer) все это сделать проще, так как в этом случае наличие первичного контроллера домена не обязательно, экспорт имен тоже не требуется, и сервер может работать под управлением Windows 95. Чтобы сервер воспринимался как удаленный, в раздел компьютера-сервера HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{} добавляется подраздел OLEnterpriseExport, а в раздел компьютера-клиента HKEY_CLASSES_ROOT\CLSID\{ } добавляется раздел Dap\DCEClient\<имя выполняемого файла>.<имя OLE-сервера> c набором параметров, представленных на рис. 6.

Рис.6 Раздел Dap\DCEClient\ реестра клиента при импорте объекта
Уважаемая Наталия Елманова!
Прочитав Вашу статью, я попробовал создать приложение-сервер, и у меня возник вопрос - как установить связь master-detail в удаленном модуле данных без компонентов DataSource?
Буду очень вам признателен за ответ.
С уважением Денис Бокатый

Можно создать модифицируемый SQL-запрос к обеим таблицам, содержащий предложение WHERE, и поместить его в удаленный модуль данных вместо компонентов TTable. Кроме того, можно поместить компонент TDataSource, используемый для связи таблиц, в обычный модуль данных или на форму. Иногда также можно связь master/detail установить не на сервере приложений, а в клиенте (при небольших объемах таблиц это может быть даже выгоднее с точки зрения производительности). Отметим, что наиболее общепринятый способ установки такой связи подразумевает описание ее в словаре данных сервера приложений с помощью SQL Explorer (ConstraintBroker Manager), входящего в состав MIDAS, с целью передачи сведений о ней клиентскому приложению.

Здравствуйте, Наталия!

Большое спасибо Вам за внимание, которое Вы нам уделили. Ваши советы нам помогли.


...

Думаю, что было бы хорошо "обозреть" имеющиеся у пользователей Delphi средства для создания приложений для Internet, работающих с базами данных. По моему разумению, можно выделить три группы средств:

"Родные" средства Delphi с палитры компонентов Internet - позволяют работать с любым www-сервером под управлением Windows NT или Windows 95, но требуют знания HTML и неудобны при отладке приложений (может быт, ь в этом я и не прав, так как сам этот способ не реализовывал).

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

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


С уважением, Михаил Шунин

начальник отдела программирования КИВЦ ОАО "Аэрофлот"

,

Разработка web-приложений, связанных с динамической генерацией HTML-страниц - это действительно интересная и важная тема, которой, по-видимому, будет посвящена одна из ближайших статей, посвященных продуктам Borland.

Что касается сервера Baikonur от Epsylon Technologies - это действительно интересный продукт, наглядно демонстрирующий, какие возможности предоставляют разработчикам технологии Borland, использованные при его создании. Нельзя не отметить, что этот продукт является, по существу, сервером приложений, предоставляющим возможность их визуально создавать. Своей технологической направленностью этот продукт заметно выделяется среди отечественных программных продуктов, ориентированных в основном на национальную российскую специфику (не секрет, что это главным образом бухгалтерские, финансовые и офисные приложения, юридические базы данных, игры, мультимедиа-энциклопедии, OCR, различные программы лингвистического назначения - достаточно посетить очередной SofTool, чтобы в этом убедиться). Остается только пожелать удачи компании Epsylon Technologies, разработавшей этот интересный продукт и надеяться на то, что авторы Baikonur смогут написать о нем и использованных при его создании технологиях более подробно.

Что касается использования ActiveForm и многозвенных приложений - я надеюсь, что настоящая статья в определенной степени выполняет это пожелание.

Несколько слов для пользователей C++Builder.

Все изложенное в данной статье (и в других статьях, посвященных серверам приложений и MIDAS) в равной степени (с точностью до написания кода, которого, по существу, не так уж и много) относится и к С++Builder 3.0. В новую версию C++Builder включена поддержка MIDAS на уровне компонентов (имеются компоненты TClientDataSet, TRemoteServer, TMidasConnection, TProvider), эксперты для создания удаленных модулей данных и ActiveX, и имеется MIDAS Development Kit для создания серверов приложений. Отличие от Delphi заключается в том, что для создания ActiveX используется библиотека Active Template Library (ATL), тогда как Delphi использует собственные средства создания ActiveX. Одновременная разработка сервера приложений и клиента в C++Builder осуществляется даже более просто, чем в Delphi, благодаря новым средствам управления проектами, позволяющим загрузить в среду разработки несколько проектов одновременно. Отметим также, что с помощью C++Builder Enterprise возможна разработка "тонких" клиентов для Borland Entera. Таким образом, C++Builder, наряду с Delphi 3, теперь является инструментом, позволяющим создавать серверы приложений и "тонкие" клиентские приложения, в том числе в виде выполняемых в web-броузере элементов ActiveX.
В заключение хотелось бы поблагодарить авторов многочисленных (как процитированных, так и многих других) писем, пришедших после публикации статьи о серверах приложений, свидетельствующих о том, что данная тема представляет определенный интерес для читателей.

Об удаленном клиенте с использованием DCOM

Об удаленном клиенте с использованием DCOM
В принципе можно использовать не OLEnterprise, а непосредственно технологию DCOM (Distributed Component Object Model) корпорации Microsoft. Не вдаваясь в теоретические подробности использования DCOM, отметим, что использование этой технологии для запуска серверов приложений возможно лишь при условии наличия первичного контроллера домена в сети и выбранной на рабочих станциях установки User Level Access Control на странице Access Control раздела Network панели управления Windows (это необходимо для переноса с контроллера домена списка пользователей для разрешения им доступа к серверу приложений). Помимо этого, сервер приложений может быть доступен для клиентских приложений, если только он выполняется под управлением Windows NT, но не Windows 95. Отметим также, что сведения о сервере приложений должны быть в реестре клиента (этого можно добиться, например, путем запуска сервера приложений непосредственно на рабочей станции с ключом /regserver, если, конечно, ресурсы рабочей станции позволяют это сделать). После этого следует внести изменения в реестр так, чтобы зарегистрированный таким образом OLE-объект воспринимался не как локальный, а как удаленный объект. Это можно сделать как отредактировав реестр вручную, так и с помощью утилиты конфигурации DCOM, указав явно, на каком компьютере запускается сервер приложений (запустив эту утилиту на рабочей станции, содержащей клиентское приложение), и кто из пользователей имеет право его запускать (на компьютере, содержащем сервер приложений). Примеры сервера и клиента, описанные в начале статьи, были выполнены и с использованием DCOM (без OLEnterprise). Характеристики использованных ПК для этого примера представлены в табл.2. Таблица 2. Технические характеристики использованных ПК и ПО при соединении клиента и сервера приложений с помощью DCOM

Компоненты распределенной системыПОПК

Сервер БД	Windows NT Server 4.0 + Oracle Workgroup Server 7.2 (Trial 90-day version) for Windows NT	Pentium-133/32 MB RAM
Сервер приложений	Windows Nt Server 4.0	Pentium-133/32 MB RAM (это тот же самый ПК, на котором запущен сервер БД)
Клиенты 1,2,3	Windows 95	Pentium-120/16 MB RAM

| |

Подготовка данных для сервера приложений

Подготовка данных для сервера приложений
Для создания сервера приложений нам потребуются какая-либо серверная СУБД, клиентом которой будет данный сервер приложений, и тестовые таблицы, которые будут перенесены на сервер баз данных. В рассмотренных в настоящей работе примерах используются Personal Oracle for Windows 95 и Oracle Workgroup Server 7.2 for Windows NT (90-дневные trial-версии), но не возбраняется использовать в качестве источника данных любую серверную СУБД (и, вообще говоря, даже набор таблиц dBase или Paradox). Создадим нового пользователя Oracle с правами CONNECT и RESOURCE и от его имени перенесем c помощью утилиты Data Migration Wizard таблицы CLIENTS.DBF и HOLDINGS.DBF из базы данных DBDEMOS, входящей в комплект поставки Delphi 3, в базу данных Personal Oracle for Windows 95 или Oracle Workgroup Server 7.2 for Windows NT. После этого можно приступить к созданию простейшего сервера приложений, являющегося, с одной стороны, клиентом серверной СУБД, и, с другой стороны, сервером конечного пользовательского приложения, которое становится при этом так называемым "тонким" клиентом. | |

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

Если с поставкой "тонких" клиентов все более или менее ясно, то поставка серверов приложений и связанные с ней проблемы вызвали самый большой наплыв вопросов.
Нередко разработчики, создавшие сервер приложений и успешно протестировавшие его на компьютере, на котором производилась разработка, сталкиваются с трудностями при переносе этого сервера приложений на другой компьютер - он отказывается там выполняться либо работает некорректно. Вопросы по этому поводу обычно содержат описание проблемы и формулируются примерно следующим образом: "Что должно быть установлено на компьютере, на котором эксплуатируется сервер приложений?". Например, Георгий Буриков и Михаил Шунин из ВЦ ОАО "Аэрофлот-Российские Международные авиалинии" спрашивают в своем письме:
Мы пытаемся установить удаленное соединение с базой данных, используя компонент TMidasConnection. На серверной части (WindowsNT) работает серверное приложение - TProvider, TQuery и TDataBase в RemoteDataModule и главная форма, показывающая счетчик клиентов (аналог примера из DEMOS\ACTIVEFM\EMPEDIT\Server.dpr из поставки Delphi 3.01).
В директории с приложением-сервером находится программа scktsrvr.exe (она запускается как приложение ) и dbclient.dll. Приложение-сервер запущено.
Клиентское приложение содержит DataModule c ClientDataSet, Query и MidasConnection и главную форму с DBGrid, настроенным на Query. Свойства MidasConnection выставлены следующим образом:
ComputerName - IP-адрес сервера,
ConnectType - stSockets
ServerGuid - {56791B61-7625-11D1-A3B8-00C0DF817EF4} - (взято из текста
приложения сервера)
ServerPort - 211
UserBroker - False
При установке свойства Connected компонента MidasConnection равным true счетчик клиентов в приложении-сервере увеличивается на 1 и при сбросе Connected в false уменьшается. Т.е. вроде бы приложение-сервер "чувствует" подключение приложения-клиента. Однако при установке ClentDataSet.Active равным true возникает ошибка - "Ошибка при загрузке библиотеки" без дополнительных пояснений.
О какой библиотеке идет речь?

С уважением, Михаил Шунин, Георгий Буриков

ВЦ ОАО "Аэрофлот-Российские Международные авиалинии"

Речь идет об одной из библиотек, которые входят в состав MIDAS и должны находиться на сервере приложений. Это библиотеки IDPROV32.DLL (она должна быть в том же каталоге, что и BDE), DBCLIENT.DLL и STDVCL32.DLL (эти библиотеки должны быть в каталоге Windows\System и должны быть зарегистрированы в реестре).

В целом же на этот и другие подобные вопросы можно ответить следующее. На компьютере, где выполняется сервер приложений, должен быть установлен MIDAS. В его состав входит BDE, SQL Explorer (ConstraintBroker Manager), вышеупомянутые библиотеки, а также OLEnterprise. В состав Delphi 3 Client/Server Suite входит только MIDAS Development Kit, включающий лицензию разработчика и ограниченную версию MIDAS, позволяющую создавать серверы приложений, тестировать их, но не позволяющую заниматься их поставкой. Для поставки и промышленной эксплуатации серверов приложений, созданных с помощью Delphi 3, требуется полная версия MIDAS, предоставляющая, наряду с необходимыми библиотеками и утилитами, право эксплуатации любого количества серверов приложений на том компьютере, где она установлена. Естественно, комплектов MIDAS нужно столько, сколько в сети имеется компьютеров с поддерживаемыми MIDAS серверами приложений. Эксплуатация серверов приложений без наличия полной версии MIDAS на компьютере, где они установлены, является нарушением лицензионного соглашения Delphi.

Поставка "тонких" клиентов

Как уже неоднократно отмечалось, поставка "тонких" клиентских приложений представляет собой намного более простой процесс, чем поставка "толстых" клиентов. Для функционирования такого клиента требуется, помимо исполняемого файла, наличие библиотеки dbclient.dll (ее можно найти в каталоге Windows\System на компьютере разработчика и скопировать либо в аналогичный каталог компьютера пользователя, либо в каталог, содержащий исполняемый файл клиентского приложения). Если речь идет о создании стандартного дистрибутива с помощью InstallShield Express или иного аналогичного средства, следует отказаться от включения BDE и SQL Links в его состав, а включить лишь файлы, необходимые для функционирования клиентского приложения, и библиотеку dbclient.dll.
Если клиентское приложение выполнено в виде иcполняемого в броузере ActiveX, следует выбрать dbclient.dll в закладке Deploy Additional Files диалоговой панели Web Deployment Options. При распространении ActiveX через Internet рекомендуется выбрать также опцию "Use CAB file compression" для уменьшения времени передачи его по сети.

Простые Web-серверы уже не так уж и просты

Первичной задачей Web-серверов была поддержка Web-сайтов. Однако теперь они играют более серьезную роль в информационных корпоративных системах. Web-технология оказывает сильное влияние на новое поколение серверов приложений. В них используются такие Web-протоколы как и , а Web-браузеры применяются для организации первичной среды клиентов.
Определение платформы Web-сервера существенно изменилось за последние 18 месяцев. Это связано с быстрым развитием Web-технологии как основы информационных и коммерческих платформ. Анализ инвестиций в intranets показывает, что удалось сэкономить многие миллионы долларов, особенно в областях продаж и поддержки заказчиков. Многие бизнесмены ожидают, что Web-коммерция позволит существенно увеличить общий объем продаж. Например, президент компании Джон Чамберс (John Chambers) утверждает, что применение Internet-коммерции и intranet-систем позволяет его компании каждый год экономить более 250 миллионов долларов. Через Web осуществляется около 40% продаж с ожидаемым объемом в 1998 г. в 3 миллиарда долларов. Компания организовала совместное предприятие с компанией с целью переноса корпоративных приложений в среду Web.
Технически развитие Web-технологии облегчается наличием стандартов, таких как , SSL и Java. Эти стандарты воплощаются в Web-сервере, который служит центральной точкой для интеграции новых инструментальных средств и технологий. В приводимая ниже таблица иллюстрирует развитие функциональных возможностей Web.

Особенности Web-платформВозможности

Common Gateway Interface (CGI)	Запросы целиком обрабатываются в отдельных процессах сервера; медленное и трудное программирование; отсутствует встроенная поддержка баз данных
Скриптовые среды первого поколения: Netscape LiveWire; Microsoft Active Server Pages (ASP); Apache with Java Servlets; GoldFusion; WebObjects	Интеграция с HTML позволяет динамически расширять Web-страницы; разработка убыстряется благодаря возможности создания скриптов высокого уровня на JavaScript, VB Script и Java; имеются некоторые проблемы с эффективностью выполнения скриптов; обеспечивается некоторая поддержка объектов и баз данных; очень ограниченная безопасность.
Прикладные среды второго поколения: LiveWire plus LiveConnect and Borland/Visigenic ORB; ASP plus ADO and MTS; Apache with CORBA and JavaBeans; SilverStream 1.0; Progress Software WebSpeed	Более развитая поддержка объектов; интеграция Java и CORBA; поддержка пулов подключений к базам данных; улучшенная производительность за счет кэширования и прекомпиляции; улучшенная безопасность за счет использования 40-битового SSL.
Корпоративные и коммерческие среды третьего поколения: Netscape with Kiva Application Server and Actra commerce servers; Microsoft Site Server 3.0 with Active User Object; MTS 2.0 and Merchant Server; Open Market LiveCommerce and Transact	Усложненное пулирование ресурсов баз данных и кэширование объектов; интеграция с серверами знаний; расширения в сторону более вертикальных прикладных областей, таких как регистрация и профилирование пользователей; развитые функции категорий пользователь-бизнес и бизнес-бизнес; интеграция с платежными системами; более развитая безопасность с использование 64-битового SSL и цифровых сертификатов

<

Прозрачность баз данных

Если приходится иметь дело с несколькими системами баз данных, то наиболее существенным является общий интерфейс доступа к данным (API - Application Programming Interface). Наличие такого API позволяет использовать стандартные инструментальные средства и существенно упрощает процесс разработки приложения. К наиболее популярным интерфейсам относятся ODBC, OLE DB и ActiveX Data Object (ADO) компании . Среди разработчиков, использующих язык Java, в качестве общего интерфейса доступа к базам данных принят JDBC. В мире Си++ многих привлекает DBTools++ компании RogueWave Software (www.roguewave.com).

Различные архитектуры построения трехзвенных информационных систем

Нередко у потенциальных пользователей MIDAS возникают вопросы о способах построения многозвенных информационных систем, наиболее удовлетворяющих нуждам именно их предприятия, в том числе вопросы о том, сколько нужно иметь серверов приложений, как конфигурировать клиентские рабочие станции, каковы возможности осуществления и изменения конфигурации рабочих станций удаленно, например, через Internet или с помощью модемной связи.
Многозвенные информационные системы можно построить разными способами, и выбор той или иной архитектуры существенно зависит от числа пользователей такой ИС, степени территориальной разбросанности предприятия, потребности в централизованном хранении и обработке данных, частоты обновления версий используемых автоматизированных рабочих мест и структуры используемой базы данных.
Первый часто встречающийся случай - крупное или среднее предприятие, расположенное компактно и имеющее общую локальную сеть. В этом случае нередко корпоративные данные хранятся в общей для всех серверной СУБД. Переход к трехзвенной архитектуре в этом случае производится главным образом с целью снижения издержек, связанных с конфигурацией рабочих станций (установка и настройка клиентской части серверной СУБД, настройка BDE, обновление версий автоматизированных рабочих мест) и поддержкой их в рабочем состоянии, и, во вторую очередь - с целью снижения сетевого трафика и повышения надежности эксплуатации системы в целом. В этом случае наиболее приемлемым представляется наличие в сети нескольких компьютеров, на которых установлены MIDAS и OLEnterprise и эксплуатируются одни и те же серверы приложений, при этом сведения о них экспортированы в глобальный реестр (например, с помощью утилиты Object Explorer). На рабочих станциях в этом случае устанавливается Run-time - версия OLEnterprise, и все описания серверов приложений импортируются в локальные реестры. При такой конфигурации рабочие станции подключаются к серверам приложений случайным образом и в случае отказа одного из серверов эти подключения окажутся равномерно распределенными по другим серверам.

В случае очень большого числа пользователей и высокой интенсивности транзакций можно рекомендовать как альтернативу "самодельным" серверам приложений серверы приложений Borland Entera, которые, в отличие от серверов, созданных с помощью Delphi, могут управляться не только помощью Windows 95 и Windows NT, но и с помощью других операционных систем (в частности, различных версий Unix). В этом случае вместо Delphi Client/Server Suite следует использовать Delphi Enterprise, что позволит создать "тонких" клиентов для использования Entera в качестве сервера приложений.

Второй случай, характерный, в частности, для многих предприятий нефтяной и газовой промышленности, крупных торговых объединений, а также различных межрайонных и межрегиональных служб, от налоговых инспекций до авиационных касс - предприятие, имеющее несколько территориально разбросанных подразделений (возможно, даже в разных городах), не связанных локальной сетью между собой. Нередко такие предприятия имеют несколько локальных информационных систем и набор связанных с этим проблем, таких, как поддержка актуальности данных во всех этих информационных системах, репликация данных, объединение данных из нескольких информационных систем для их совместного анализа и составления итоговых сводок и отчетов. Переход к трехзвенной архитектуре в случае таких предприятий осуществляется с целью устранения этих проблем и организации централизованного хранения и обработки данных (а нередко также с целью снижения тех же затрат на конфигурацию рабочих станций, что и в предыдущем случае). Обычно в этом случае наиболее приемлемым представляется установка сервера баз данных и сервера приложений в центральном офисе (не обязательно на одном и том же компьютере), при этом последний должен быть оснащен MIDAS и быть доступным через Internet. Рабочие станции филиалов должны быть оснащены Internet Explorer 3.0 и выше, при этом и разработчики, и пользователи рабочих станций удаленных филиалов должны иметь доступ не только к компьютеру, содержащему сервер приложений, но и к какому-либо web-серверу (его местоположение не играет существенной роли, так как первые лишь отправляют туда новые версии "тонких" клиентских приложений, а вторые их сгружают на свои рабочие станции).


В этом случае никаких особых требований к рабочим станциям, помимо наличия Internet Explorer 3.0, а также доступа в Internet, нет. В этом случае, естественно, также возможно использование Borland Entera и Delphi Enterprise вместо MIDAS и Delphi Client/Server Suite.

В случае невозможности доступа через Internet возможны иные варианты, такие, как использование выделенной линии, модемная связь и др. Реализация связи не так принципиальна - лишь бы при этом была возможность использования протокола TCP/IP. Естественно, при частых сбоях и разрывах соединения рекомендуется активно использовать кэширование данных на рабочих станциях, сохранять содержимое кэша в файлах и загружать их оттуда, благо у компонента TClientDataSet есть методы SaveToFile и LoadFromFile.

Возможны различные комбинации этих вариантов, например, доступ по протоколу TCP/IP и наличие нескольких однотипных серверов приложений. Дать рекомендации на все случаи жизни, естественно, невозможно, но имеющиеся благодаря средствам разработки Borland технические возможности предоставляют разработчикам и руководителям отделов автоматизации достаточно большой простор для фантазии при организации информационных систем предприятий, и достаточный выбор вариантов их построения.

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

Являясь эффективными средствами для построения масштабных приложений категории OLTP (OnLine Transaction Processing), TP-мониторы обычно не обеспечивают следующие возможности:

Хранение логики приложений и управление ею

Размещение и создание экземпляров объектов

Кэширование объектов и отслеживание их времени жизни
Разработка многозвенных приложений целиком связана с их разделением, которое состоит в делении работы между клиентом и одним или несколькими специализированными серверами. Серверы приложений облегчают разделение, допуская перенос компонентов приложения на архитектурный уровень и физическую платформу, на которых они могут работать наиболее эффективно.
Сервер приложений поддерживает определение логики приложений. Для этих целей некоторые серверы обеспечивают собственные средства разработки и языки. Другие полагаются на объектные стандарты, такие как CORBA, COM или JavaBeans. Почти во всех случаях требуется инкапсуляция логики приложения в одном или нескольких объектах. Возможности этих объектов доступны через их методы, которые могут быть вызваны напрямую из кода приложения или из других объектов.
Гибкость современных РСУБД делает соблазнительным поместить существенную часть логики приложения прямо в базу данных в виде хранимых процедур. Если не принимать во внимание ссылочные и другие ограничения целостности, это, вообще говоря, плохая идея. Для большинства приложений пропускная способность сервера баз данных является наиболее ценным ресурсом. Если сервер выполняет специфичную для приложения задачу для одного пользователя, пожирающего этот ресурс, то он не в состоянии обслуживать потребности всех других пользователей. Лучше разделить эту работу таким образом, чтобы аппаратные ресурсы могли быть сосредоточены на выполнении наиболее требуемых действий.
До последнего времени большинство серверов приложений было тесно связано с платформами разработки корпоративных приложений. Хорошим примером являются продукты компании . Линия продуктов этой компании включает средства разработки GUI (Graphical User Interface), компоненты связи с базами данных и средства распространения. Все они выстроены вокруг надежного сервера приложений. Проектировщик создает приложение так, как если бы оно должно было выполняться на одной машине, а затем использует средства разделения, чтобы поделить работу между клиентом и серверами приложений. В продуктах семейства Vision компании также используется эта модель.
До конца 1995 г. этот класс корпоративных инструментальных средств переднего края составлял достаточно хорошо понимаемую и устоявшуюся категорию. И тогда пришло время Web.

Создание локального клиентского приложения

Создание локального клиентского приложения (на том же ПК, что и сервер)
Закрыв проект созданного только что сервера, можно приступить к созданию клиентского приложения. Создадим главную форму приложения и обычный модуль данных, который должен быть видим из главной формы (этого можно достичь путем выбора опции: File/Use unit...). В модуль данных поместим один компонент TRemoteServer, два связанных с ним компонента TClientDataSet и два связанных с ними компонента TDataSource.
Рис.6. Модуль данных клиентского приложения
Попробуем установить свойство ServerName компонента RemoteServer1 (выбрав его из выпадающего списка или введя вручную). После этого, если в реестре есть соответствующая запись, автоматически будет установлено значение свойства ServerGUID. При этом сервер приложений, созданный ранее, должен автоматически запуститься, о чем будет свидетельствовать появившаяся на экране его главная форма. После этого можно установить нужные значения свойств ProviderName компонентов TClientDataSet, выбрав их из выпадающего списка (так как сервер приложений выбран, все его доступные через интерфейс свойства становятся видны в среде разработки). После этого можно установить связь master/detail между таблицами по общему полю ACCT_NBR. Далее нужно установить значения свойства Active компонентов TClientDataSet равными True и связать интерфейсные элементы главной формы приложения с соответствующими полями таблиц, доступных через запущенный сервер приложений.
Рис.7. Главная форма клиентского приложения
Теперь можно скомпилировать и запустить приложение. Отметим, что при запуске приложения из среды разработки с сервером приложений соединены два клиента - среда разработки и скомпилированное клиентское приложение. При желании можно с помощью утилиты SQL Monitor проследить, какие именно запросы созданный нами сервер приложений направляет серверу баз данных. Данный пример был выполнен на ПК Pentium-120/32 МБ c ОС Windows 95 с использованием. Personal Oracle 7.2 for Windows 95 (90-дневная trial-версия)и Delphi 3.0. При этом во время отладки приложения был постоянно загружен MicrosoftWord 7.0. | |

Создание сервера приложений и

Созданные с помощью Delphi 3.0 клиент и сервер приложений могли взаимодействовать посредством OLEnterprise либо DCOM. В версии Delphi 3.01появилась также возможность организовать связь клиента и сервера непосредственно с помощью протокола TCP/IP. Для этого в палитре компонентов последних версий Delphi (3.01 и 3.02) имеется компонент TMidasConnection, обладающий большей функциональностью по сравнению с TRemoteServer из Delphi 3.0. Этот компонент позволяет выбрать тип соединения с сервером приложений (DCOM, OLEnterprise, непосредственное использование протокола TCP/IP). При его использовании процесс создания сервера приложений и клиента заметно упрощается, так как в случае доступа по протоколу TCP/IP в общем случае нет необходимости иметь в реестре компьютера, на котором установлен "тонкий" клиент, какие-либо сведения о сервере приложений. Рассмотрим простейший пример создания такой системы.
Начнем с создания сервера приложений. Создадим главную форму приложения, основное назначение которой - служить индикатором запущенного сервера. С этой целью можно разместить ее где-нибудь в углу экрана, а свойство FormStyle установить равным fsStayOnTop, чтобы не потерять это окно среди других открытых окон. Далее следует создать удаленный модуль данных, выбрав пиктограмму Remote DataModule из репозитария объектов, поместить в него компонент TTable или TQuery, установив необходимые значения свойств DatabaseName и TableName. Свойство Active также следует установить равным True (или установить его динамически при создании модуля данных). В противном случае компонент не будет содержать никаких данных, и тем более предоставлять их клиентскому приложению (рис.1).

Рис.1. Форма и удаленный модуль данных сервера приложений
Затем нужно обязательно экспортировать этот компонент из модуля данных (либо связать его с компонентом TProvider и экспортировать последний). Если этого не сделать, клиентское приложение не будет иметь доступа к этому объекту (эта ошибка является довольно типичной).
Основное назначение удаленного модуля данных заключается именно в предоставлении содержащимся в нем компонентам доступа к данным возможности быть видимыми и управляемыми извне, то есть из других приложений (и в общем случае - с других компьютеров, в том числе доступных не только посредством локальной сети, но и посредством Internet). Проконтролировать наличие в удаленном модуле данных объектов, видимых извне, можно, просмотрев соответствующую библиотеку типов (рис.2).



Рис.2. Библиотека типов, связанная с удаленным модулем данных

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

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

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


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

Если обобщить данный случай, то, образно говоря, серверы приложений такого класса обязаны содержать либо генерировать некий набор SQL-запросов для изменений в базе данных и посылать их на сервер баз данных по команде клиентского приложения. Наш сервер приложений использует для генерации запросов библиотеку Borland Database Engine. Другие серверы приложений, такие, например, как Borland Entera, используют иные механизмы генерации запросов, обусловленные в известной степени той платформой, на которой этот сервер приложений функционирует. В любом случае именно набор SQL-запросов является самой главной составляющей функциональности такого сервера приложений. Что же касается пользовательского интерфейса сервера приложений (форма со счетчиком подключений или что-то в этом роде), он совершенно необязателен. В конце концов, сервер приложений может не иметь главной формы или не показывать ее, или может быть запущен в виде сервиса. Если же говорить опять об общем случае (когда речь идет не только о серверах приложений, созданных с помощью Delphi, но и о других подобных серверах приложений, в том числе для других платформ), то ведь не все платформы обладают графическим пользовательским интерфейсом, и, следовательно, создание такого объекта, как форма, возможно не на всех платформах. Не стоит обольщаться - самые дорогие серверы приложений нередко просто запускаются из командной строки и не обладают интерфейсом в привычном для пользователей Windows понимании.

В известном смысле сервер приложений и "тонкий" клиент представляют собой разделенное на две части классическое клиентское приложение, называемое в совокупности с клиентом серверной СУБД и библиотеками доступа к данным, такими как BDE, "толстым" клиентом.


Первая часть ( созданный нами сервер приложений) содержит компоненты доступа к данным (и требует наличия BDE и клиента серверной СУБД), а вторая (клиент) должна содержать пользовательский интерфейс (и не требовать наличия BDE и клиентской части серверной СУБД).

Прежде чем приступить к созданию "тонкого" клиента, запустим Borland MIDAS Socket Server scktsrvr.exe (его можно найти в каталоге Delphi 3.0\Bin), предоставляющий доступ извне к имеющимся на данном компьютере серверам приложений, созданных с помощью Delphi 3, по протоколу TCP/IP. Отметим, что в этом случае любой из имеющихся серверов приложений может быть запущен с любого компьютера, имеющего доступ к Вашему компьютеру с помощью данного протокола, поэтому при использовании подобных систем следует рассматривать различные вопросы, связанные с безопасностью их эксплуатации.



Рис.3. Borland MIDAS Socket Server

Теперь, наконец, можно создать клиентское приложение. Для этого создадим обычную форму (или выберем со страницы ActiveX репозитария объектов пиктограмму ActiveForm для создания клиентского компонента ActiveX). На форму поместим компонент TMidasConnection и установим его свойство ComputerName равным IP-адресу компьютера, на котором должен выполняться сервер приложений. Если этот компьютер в данный момент доступен в сети, можно выбрать его имя из списка, появляющегося при щелчке напротив имени этого свойства. Но нужно понимать, что в общем случае, особенно если клиентское приложение предназначено для доступа к серверу через Internet, указание именно IP-адреса является более предпочтительным. Далее следует установить значение свойства ServerName в следующем формате: <имя исполняемого файла>.<имя OLE-сервера>, например MyAppSrv.MyRemDataMod1. Свойство ServerGUID можно не устанавливать. Если сервер приложений не зарегистрирован на компьютере, где разрабатывается клиент, значение этого свойства должно остаться пустым, и это не помешает совместной работе сервера и клиента - ведь в общем случае при распространении клиентского приложения или ActiveX через Internet в реестре компьютера, где оно будет выполняться, нет и не может быть сведений о сервере приложений.


Свойство Connected можно установить равным True (или произвести установку этого свойства равным True на этапе выполнения в момент создания формы клиентского приложения). После этого должен запуститься сервер приложений (в том числе удаленный).

Далее следует поместить на форму компонент TClientDataSet, выбрать имя компонента TMidasConnection в качестве значения свойства RemoteServer и выбрать значение свойства Provider из выпадающего списка объектов, экспортированных из удаленного модуля данных сервера приложений. Теперь можно установить свойство Active равным true. Далее следует поместить на форму компонент TDataSource и связать его с компонентом TClientDataSet.

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



Рис. 4. Активная форма на этапе проектирования.

Далее можно запустить и протестировать клиентское приложение, а если он выполнено в виде ActiveX - осуществить его поставку на Web-сервер вместе с библиотекой dbclient.dll и протестировать, обратившись к сгенерированной HTML-странице (рис.5).



Рис.5. Тестирование "тонкого" клиентского приложения

Отметим также, что можно обратиться к созданной HTML-странице с другого компьютера локальной сети.

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


Нередко при создании таких ActiveX задаются вопросы типа: "А если приложение должно содержать несколько форм, как мне поступить?". Ответ достаточно прост: в этом случае возможна генерация дополнительных форм динамически при наступлении какого-либо события (например, нажатия на кнопку). Нужно только не забыть уничтожить созданную форму, когда она станет не нужна. Следует также помнить, что библиотека OCX, содержащая ActiveX, содержащий, в свою очередь, несколько форм, будет иметь больший размер, чем в случае ActiveX c одной формой.

Довольно часто встречаются вопросы, связанные с тем, что ActiveX не отображается в броузере. Вот одно из таких писем:

Здравствуйте, Наталия Елманова!

Прочел вашу статью на Web-сайте www.interface.ru. Пробую создать сервер приложений с использованием ActiveForm. После создания и переноса CAB-файла и Web-страницы на Web-сервер страничка открывается, но на месте предполагаемой аппликации только квадратик. Разъясните, в чем может быть проблема.

С уважением Слава.

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