MIDAS и создание серверов приложений (стр. 1 из 3)

Наталия Елманова, Центр Инфомационных Технологий

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

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

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

Создание сервера приложений и "тонкого" клиента с доступом по TCP/IP в Delphi 3.01/3.02 и в С++Builder 3.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.