Распределенные системы: технология Borland Midas. Часть 3. Фертиков В.В. - 11 стр.

                                    11
может быть передана обратно в клиентское приложение для дальнейшей обра-
ботки пользователем.
      Таким образом, основная логика данных сервера приложений обрабаты-
вается провайдером, который служит брокером данных между удаленным сер-
вером базы данных и набором данных клиента на клиентской машине. Обра-
ботчики событий, отвечающие за клиентские запросы, применяют бизнес-
логику данных, в то время как свойства провайдера управляют тем, какая ин-
формация включена в пакеты данных.
      Удаленный модуль данных поддерживает дуальный интерфейс сервера
автоматизации, реализующего интерфейс с именем IAppServer. Этот интерфейс
обеспечивает основу коммуникаций для многозвенных приложений: именно он
используется набором данных клиента для общения с провайдером на сервере
приложений. Наборы данных клиента получают экземпляр IAppServer от
компонента связи в клиентском приложении. По умолчанию интерфейс являет-
ся «stateless», это означает, что вызовы функции независимы и не привязаны к
предыдущему вызову. Поэтому интерфейс IAppServer не имеет свойств, ко-
торые бы хранили информацию о состоянии между вызовами. Однако есть слу-
чаи, в которых набор данных клиента полагается на сохраненную информацию
о состоянии, такую как текущая позиция курсора базы данных, когда выполня-
ется постепенно возрастающая выборка. Эта информация о состоянии сохраня-
ется только, если несколько клиентов не использует совместно сервер прило-
жений, который реализует IAppServer.
      В заключение обратим внимание на наличие в удаленном модуле еще
двух компонентов, TВatabase и TSession (см. рисунок 4). Отметим, что для
каждого «тонкого» клиента, подключенного к серверу приложений, создается
свой экземпляр удаленного модуля данных, что собственно и обеспечивает од-
новременное обслуживание сервером сразу нескольких клиентов. Таким обра-
зом, для того, чтобы избежать конфликтов между соединениями с базой дан-
ных, устанавливаемых в разных экземплярах модуля данных, следует позабо-
титься о разных именах пользовательских сессий. Эту задачу выполняет ком-
понент TSession , точнее, соответствующий его экземпляр в конкретном эк-
земпляре модуля данных. «Размножение» же экземпляров TDatabase необхо-
димо для того, чтобы иметь возможность индивидуальной регистрации на сер-
вере СУБД каждого из подключаемых клиентов, поскольку имя пользователя
СУБД и пароль являются свойствами именно этого компонента. Если сообра-
жения безопасности позволяют применить для всех подключений общее имя и
пароль, можно упростить рассматриваемую схему, вынеся компонент TData-
base за пределы модуля данных, например, поместив его на главную форму. В
этом случае нескольких его экземпляров создано не будет и необходимость в
явном использовании компонента TSession отпадет.

      Соединение клиента с сервером приложений
      Основная цель упомянутых выше компонентов связи – TDCOMConnec-
tion , TSocketConnection , TWebConnection , TOLEnterpriseConnection ,