Создание сервера приложений и
Созданные с помощью 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 с помощью тега <OBJECT>. Для отображения ActiveX следует использовать только MS Internet Explorer версии 3.0 и выше. Вторая причина может быть связана с настройкой уровня безопасности броузера. В случае максимального уровня безопасности (значение, принятое по умолчанию) никакой исполняемый код (в том числе и ActiveX) в броузере не выполняется, а некоторые версии Internet Explorer не только не сгружают ActiveX и тем более не выполняют его, но при этом еще и ничего не сообщают пользователю. Есть еще и третья причина - настройки операционной системы компьютера пользователя таковы, что пользователю запрещено изменять реестр, и в этом случае ActiveX в нем, естественно, не зарегистрируется.
