Delphi, С++Builder и MIDAS: вопросы и ответы

Наталия Елманова1

После публикации в декабре 1997 года статьи «Создание серверов приложений с помощью Delphi 3» и цикла «Распределенные вычисления и технологии Inprise» в 1999 году в адрес редакции поступило много вопросов, связанных с проблемами создания распределенных систем с помощью MIDAS. Данная статья посвящена ответам на некоторые наиболее часто встречающиеся из них.

Прочитал Вашу статью «MIDAS и маленькие приложения». Это отлично, что можно выгрузить в *.cds-файл таблицу из базы данных. А как загрузить данные обратно в таблицу?

Данные обратно можно загрузить с помощью метода ApplyUpdates компонента TClientDataSet, например:

ClientDataSet1.ApplyUpdates(-1);

Как можно передать от «тонкого» клиента серверу приложений данные, которые не хранятся в базе данных (например, имя и пароль доступа к базе данных)?

Имя и пароль можно передать так: открыть библиотеку типов удаленного модуля данных и добавить метод Login c двумя строковыми параметрами (username и password). Реализация его может, например, выглядеть так:

procedure TMyRDM.Login(username, password: OleVariant);
begin
   Database1.Connected:=False;
   Database1.params.Values[‘Password’]:=password;
   Database1.params.Values[‘User Name’]:=username;
   Database1.Connected:=true;
   Table1.Open;
   Table2.Open;
end;

Соответствующий код обращения к этому методу в клиентcком приложении имеет вид:

procedure TForm1.Button1Click(Sender: TObject);
begin
   Form1.ClientDataSet1.Close;
   Form1.ClientDataSet2.Close;
   Form1.SocketConnection1.AppServer.Login(Edit1.Text,Edit2.Text);
   Form1.ClientDataSet1.ProviderName:=’Table1';
   Form1.ClientDataSet2.ProviderName:=’Table2';
   Form1.ClientDataSet1.Open;
   Form1.ClientDataSet2.Open;
end;

Каким образом при создании многозвенной системы при помощи MIDAS послать на сервер произвольный SQL-запрос?

Запрос на сервер можно отправить, например, создав дополнительный метод удаленного модуля данных и обратившись к нему из клиентского приложения. Текст запроса (или его параметры) может одновременно являться параметрами этого метода.

В Delphi 5 можно также воспользоваться свойством CommandText компонента TClientDataSet, поместив в него текст запроса и вызвав метод Execute. Если запрос содержит параметры, можно поместить их в свойство Params.

Созданный нами «тонкий» клиент в виде ActiveX не отображается в браузере. Почему?

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

1. Приложение разбито на «пакеты» (packages), которые забыли включить в комплект поставки.
2. В комплект поставки не включили библиотеку, необходимую для функционирования MIDAS-клиентов (DBCLIENT.DLL в случае Delphi 4 и C++Builder 4, MIDAS.DLL в случае Delphi 5).
3. Используется браузер, не поддерживающий отображение ActiveX, например версия Microsoft Internet Explorer ниже 3.0 (например, версия 2.0, входящая в комплект поставки Windows NT 4.0), или Netscape Communicator без модулей расширения, осуществляющих отображение ActiveX.
4. Созданный элемент ActiveX не имеет электронной подписи, и настройки уровня безопасности браузера для зоны, к которой принадлежит предоставляющий его сервер, не позволяют загрузку либо выполнение неподписанных элементов управления ActiveX.
5. Пользователь клиентского приложения не имеет права модифицировать реестр Windows (ActiveX при этом не зарегистрируется в реестре).

Прочитав с огромным интересом Вашу статью «Создание серверов приложений с помощью Delphi 3», я решил попробовать реализовать описанный подход к созданию удаленного клиента с помощью DCOM. Не могли бы Вы рассказать поподробнее, как настроить доступ к MIDAS-серверу с помощью DCOM?

Настройка доступа к MIDAS-серверу с помощью DCOM ничем не отличается от настройки доступа к произвольному серверу автоматизации.

Для конфигурации DCOM существует утилита DCOMCNFG, входящая в комплект поставки Windows NT (для Windows 95/98 поддержка DCOM устанавливается отдельно, и соответствующую утилиту для этих операционных систем можно найти на Web-сайте компании Microsoft www.microsoft.com).

Для настройки удаленного доступа с помощью DCOM нужно:

1. Экспортировать список пользователей сети с первичного контроллера домена. Дело в том, что использование DCOM базируется на предоставлении прав на удаленный запуск конкретного приложения тем или иным пользователям или группам пользователей. Поэтому в сети обязательно должен быть первичный контроллер домена, а компьютер, содержащий сервер, который планируется запускать удаленно, обязательно должен иметь в своем реестре описание прав доступа к данному серверу различных пользователей или их групп. Для этого требуется, в свою очередь, экспорт сведений о пользователях сети с первичного контроллера домена, что возможно только в случае выбора на таком компьютере установки User Level Access Control раздела Network панели управления Windows. При этом пользователь компьютера, на котором предполагается использовать сервер, должен иметь право импортировать список пользователей домена.

   При таком способе доступа к серверу необходимо, чтобы все клиенты и сам сервер располагались внутри одного домена.

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

   Далее следует указать, где будет запускаться сервер (для этого нужно щелкнуть мышью по закладке Location). В данном случае необходимо выбрать опцию Run application on this computer (рис. 1).

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

3. Зарегистрировать сервер в реестре рабочей станции, где будет запускаться клиентское приложение. Для этого сервер автоматизации нужно хотя бы один раз запустить на компьютере, содержащем приложение-клиент. Альтернативой является внесение записей о сервере в реестр каким-либо иным способом, например, путем написания процедуры регистрации сервера на клиентской рабочей станции или импорта *.reg-файлов.
4. Указать, где находится сервер. Это можно сделать двумя способами. Первый способ — запустить утилиту конфигурации DCOM и на странице Location выбрать опцию Run application on the following computer. Второй способ — в клиентское приложение поместить компонент TDCOMConnection и в его свойстве ComputerName выбрать компьютер, содержащий сервер (рис. 2).

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

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

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

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

Для решения этой проблемы необходимо в утилите конфигурации DCOM щелкнуть на закладке Identity и выбрать опцию This user, в которой из списка пользователей домена следует выбрать пользователя, имеющего право модифицировать реестр.

При создании с помощью Delphi 4 «тонкого» клиента на том же компьютере, что и сервер, клиент корректно получает данные с сервера только при использовании компонента TDCOMConnection, а при использовании TSocketConnection, TOLEnterpriseConnection и TCORBAConnection отказывается работать. Почему? Нужно ли запускать для этого какие-либо приложения или сервисы?

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

В целом доступ к серверам в распределенных вычислениях (безотносительно к платформам и средствам разработки) базируется на следующих основных идеях:

1. Наличие служб, разрешающих и запрещающих доступ к серверам в соответствии с какими-либо правилами. Приложения подобного рода нужны главным образом для обеспечения безопасности удаленного запуска серверов — было бы неестественно, если бы кто угодно мог у кого угодно из соседей по сети (тем более у всех владельцев Интернет-адресов) запускать любые COM/CORBA-серверы. Такие службы, как правило, в том или ином виде присутствуют во всех распределенных системах.
2. Наличие промежуточных сервисов, осуществляющих передачу данных от клиента к серверу и обратно (они применяются не всегда, например, при использовании DCOM их нет).
3. Наличие сервисов, осуществляющих поиск сервера для клиента (так называемые Directory Services — сервисы именований). В некоторых технологиях распределенных вычислений их применение обязательно, в некоторых — нет. Простейший сервис подобного назначения можно создать и самостоятельно, например с помощью компонента TSimpleObjectBroker.
4. Наличие баз данных, содержащих сведения о серверах (имя исполняемого файла или библиотеки, его местоположение). Такие базы данных нужны в том случае, когда требуется, чтобы операционная система запускала сервер автоматически, если к нему обращается имеющий на это право клиент. В случае COM такой базой данных является реестр Windows, и в этом случае его использование обязательно. В случае CORBA в качестве такой базы данных выступает репозитарий реализаций (Implementation Repository). Его использовать не обязательно, если автоматический запуск сервера не требуется.

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

1. Доступ к MIDAS-серверам с помощью сокетов

   В каталоге Delphi 4\Bin есть два исполняемых файла Scktsrvr.exe и Scktsrvc.exe (Borland Socket Server). Для осуществления доступа с помощью протокола TCP/IP нужно запустить Scktsrvr.exe либо установить его как сервис с помощью команды ScktSrvc.exe /install. В Delphi 5 имеется одно-единственное приложение Scktsrvr.exe, которое можно и запустить, и установить как сервис. Это приложение разрешает всем, кто «видит» данный компьютер с помощью протокола TCP/IP, запускать любой из COM-серверов, а заодно является промежуточным сервисом, oсуществляющим передачу данных. Компонент TSocketConnection взаимодействует именно с этим приложением, а не с MIDAS-сервером непосредственно.

   Соответственно, клиент может взаимодействовать с сервером доступа к данным, если на компьютере, его содержащем, запущен Socket Server, независимо от того, на одном или на разных компьютерах находятся клиент и сервер. Локальный запуск с точки зрения протокола TCP/IP есть всего лишь частный случай удаленного запуска на сервере с адресом 127.0.0.1 (так называемый TCP Loopback address).

   Собственно запуск сервера по запросу клиента осуществляется средствами COM.

   Отметим, что в случае создания сервера с помощью Delphi 5 и использования Borland Socket Server из комплекта поставки этой же версии Delphi можно запретить запуск конкретного сервера с помощью TCP/IP, переписав метод UpdateRegistry удаленного модуля данных и запустив Socket Server в режиме Registered Servers Only.

2. Доступ к MIDAS-серверам с помощью протокола HTTP

   Этот способ доступа поддерживается в Delphi 5. Он позволяет создавать клиентские приложения с использованием брандмауэров и SSL (Secure Sockets Layer — протокола, гарантирующего безопасную передачу данных по сети, комбинирующего криптографическую систему с открытым ключом и блочное шифрование данных). Для его использования нужна библиотека WININET.DLL, содержащая соответствующие утилиты и входящая в комплект поставки Microsoft Internet Explorer начиная с версии 3.0.

   Компонент TWebConnection, используемый при создании таких клиентов, взаимодействует со специальной библиотекой HTTPSRVR.DLL. Эта библиотека отвечает за запуск MIDAS-серверов или создание и уничтожение экземпляров удаленного модуля данных посредством COM, а также за передачу данных между клиентом и сервером. Она представляет собой ISAPI DLL и должна быть помещена в логический каталог Scripts Web-сервера Microsoft Internet Information Server 4.0, при этом последний должен быть запущен.

   Так же как и в случае использования сокетов, можно запретить или разрешить доступ к конкретному MIDAS-серверу, изменив процедуру UpdateRegistry удаленного модуля данных.

3. Доступ к MIDAS-серверам с помощью DCOM

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

4. Доступ к MIDAS-серверам с помощью OLEnterprise

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

   Для предоставления доступа клиента к серверу в этом случае используется приложение Object Factory, предоставляющее доступ к серверам, специальным образом отмеченным в реестре Windows как разрешенным для подобного доступа (в терминологии OLEnterprise они называются экспортированными в глобальный реестр). Для осуществления подобных модификаций реестра используется соответствующая утилита — OLEnterprise Object Explorer. Собственно запуск сервера по запросу клиента осуществляется средствами COM.

   OLEnterprise содержит собственный сервис именований — Business Objecn Broker, но его использование не является обязательным.

5. Доступ к MIDAS-серверам с помощью CORBA

   Чтобы CORBA-клиент мог найти уже запущенный CORBA-сервер, нужно запустить специальный сервис, позволяющий ему это сделать, — Object Agent (в случае использования Inprise VisiBroker он называется Visibroker Smart Agent). Это приложение выполняет роль сервиса именований, осуществляя поиск уже запущенного сервиса для клиента, и разрешает доступ к нему.

   Чтобы инициировать запуск CORBA-сервера по запросу клиента, в общем случае следует зарегистрировать сервер в репозитарии интерфейсов и в репозитарии реализаций (для этой цели есть соответствующие утилиты в каталоге VBroker; подробности можно найти в документации) и запустить Object Activation Daemon — сервис, ответственный за удаленный запуск серверов, зарегистрированных в репозитарии реализаций. Естественно, реестр Windows для этой цели не используется, так как CORBA-серверы существуют не только в Windows.

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

«Тонкий» клиент успешно запускает удаленный сервер приложений с помощью DCOM, но не находит его с помощью сокетов, несмотря на установленную поддержку TCP/IP и запущенный Socket Server. Почему?

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

class procedure TMyRDM1.UpdateRegistry(Register: Boolean; 
  const ClassID, ProgID: string);
begin
   if Register then
   begin
      inherited UpdateRegistry(Register, 
  ClassID, ProgID);
      EnableSocketTransport(ClassID);
      EnableWebTransport(ClassID);
   end else
   begin
      DisableSocketTransport(ClassID);
      DisableWebTransport(ClassID);
      inherited UpdateRegistry(Register, 
  ClassID, ProgID);
   end;
end;

Эта процедура добавляет в реестр разделы, с помощью которых Socket Server определяет, разрешен ли доступ к данному серверу с помощью сокетов. Если эта процедура переписана (или вызвана с параметром Register, равным False), а Socket Server запущен в режиме Registered Objects Only, доступ к данному серверу с помощью сокетов осуществляться не будет.

Другая возможная причина отсутствия доступа к MIDAS-серверу может, как ни странно, заключаться в неверном предположении о том, каков в действительности IP-адрес компьютера, содержащего сервер. Дело в том, что в некоторых сетях, обычно содержащих одновременно Windows NT-серверы и UNIX-серверы, могут возникнуть проблемы, связанные с тем, что в подобных сетях многие рабочие станции имеют по два сетевых имени и IP-адреса — один для сети Microsoft, другой для UNIX и Internet. В этом случае первое имя и адрес нужно использовать при соединении с помощью DCOM, а второе — при соединении с помощью сокетов. Чтобы узнать, каковы в данной сети адреса UNIX/Internet, следует использовать утилиты IPCONFIG и NSLOOKUP.

КомпьютерПресс 2'2000