|
Интерфейс доступа к серверу приложений
В соответствии с этим разделением в любой информационной системе можно выделить следующие логические компоненты:
Реализация доступа к объектам сервера приложений В такой трехзвенной архитектуре функциональность системы реализуется предоставлением клиенту (то есть компоненту представления) возможности обращения к абстрактным интерфейсам прикладных объектов. Интерфейс определяет набор методов, которые реализуют функции, присущие данному классу объектов. Интерфейс дает клиенту возможность только вызывать тот или иной метод, скрывая от него все детали его реализации. Клиент получает доступ к объекту только путем вызова метода, который должен быть определен в интерфейсе объекта. Это означает, что реальные действия выполняются в адресном пространстве объекта, которое, возможно, является удаленным по отношению к процессу клиента. Такое сокрытие деталей реализации позволяет в конечном итоге добиться слаженного взаимодействия компонентов в независимости от того, где и на какой платформе они реализованы и какой язык программирования для этого использовался. Объектные модели COM/DCOM и CORBA Прикладные компоненты, которые являются самостоятельными блоками программного кода и реализуют определенную бизнес-логику, могут быть распределены по сети и служить в качестве строительных блоков для создания распределенных информационных систем. При создании такой сложной объектной иерархии необходима объектная модель. Это набор правил, которые предписывают, каким образом объекты определяются и документируются. Таких моделей индустриального уровня на сегодняшний день, фактически, две: компонентная объектная модель Component Object Model (COM), разработанная Microsoft, и общая архитектура брокеров объектных запросов Common Object Request Broker Architecture (CORBA), которую развивает консорциум OMG. Функции COM и CORBA в данном случае – это функции промежуточного программного обеспечения объектной среды. Они необходимы для обеспечения взаимодействия объектов и их интеграции в цельную систему. Расширенный вариант COM, который поддерживает удаленное взаимодействие, называется DCOM (Distributed Component Object Model) и базируется на объектном расширении спецификации DCE RPC. DCOM появилась в 1996 году вмести с OC Windows NT. Исходная же модель COM была создана в 1993 году как интеграционная схема для поддержки OLE, технологии построения составных документов. В отличие от СОМ, архитектура CORBA [1,2] с самого начала создавалась для распределенных объектных систем. Ее создатель –консорциум OMG – стремился объединить объектную технологию и принципы построения клиент-серверных распределенных систем для того, чтобы предложить архитектуру, способную эффективно поддерживать взаимодействие приложений в сложной гетерогенной корпоративной среде. Чтобы не быть привязанной к конкретной платформе, OMG пошел по пути разработки единых спецификаций, на основе которых компании имели возможность создавать собственные реализации. Взаимодействие объектов Рассмотрим подробнее некоторые вопросы удаленного взаимодействия объектов. Параметры вызова методов объектов могут формироваться в отличной от серверной языковой и операционной среде, поэтому для доступа к серверным объектам на интерфейсы доступа возлагаются функции преобразования аргументов и результатов в универсальное представление, которое не зависит от конкретной языковой и операционной среды. Таким образом, в реализации каждой из объектных моделей должен присутствовать компонент, который реализует протокол удаленного доступа к серверу приложений.
Протокол должен обеспечивать:
 Со стороны сервера функция-посредник (stub) получает от “Заместителя” вызов метода, распаковывает параметры и вызывает соответствующий метод реального сервера. Сервер, выполнив клиентский запрос, может возвратить некоторый результат. “Посредник” перехватывает результат, упаковывает любые возвращаемые значения и направляет эту информацию соответствующему “Заместителю”. “Заместитель” получает возвращаемые значения, распаковывает их и передает клиенту. Рассмотрим подробнее работу “Заместителя” и “Посредника”. “Заместитель” - это задача, которая обеспечивает разбор клиентских запросов и запуск требуемых процедур на сервере приложений. Представляет из себя приложение, обеспечивающее интерфейс для авторизации на сервере, реализацию процедурных вызовов, объектных вызовов и информационных запросов для наблюдения за ходом исполнения запросов. Обеспечивает вызов call-back’ов, установленных в клиентской части. Запросы клиентского приложения передает по транспортному протоколу на сервер приложений, а ответы принимает и передает клиентскому ПО. “Посредник” в принципе аналогичен
“Заместителю”, за исключением того, что запросы не передаются в сеть, а
обращение к серверному объекту производится напрямую. Он представляет из
себя объектную библиотеку для сборки с прикладным программным обеспечением
сервера приложений. Для сессии каждого клиента создается отдельный экземпляр
“Посредника”. На сервере приложений также необходима некоторая задача,
которая будет обрабатывать приходящие запросы, разбирать их и осуществлять
вызов требуемых процедур на сервере через “Посредника”. Необходимо также
обеспечить поддержку очереди запросов для каждого клиента и отвержение
запросов, если до этого был выполнен блокирующий вызов.
CallASproc – вызывает метод сервера приложений с параметрами. Тип вызова указывает, блокирующий вызов или нет. Возвращает список параметров с результатами выполнения. Для реализации метода “Посреднику” необходимо обратится к библиотеке функций сервера приложений. “Заместитель” должен упаковать имя функции и параметры и отправить запрос в сеть. Функция должна произвести разбор входных параметров – выделить из них объектные ссылки и проверить объекты, определенные ими на зарегистрированность у “Посредника”. Проверка идентичности объекта производится сравнением с именем класса и его идентификатором, который должен быть предварительно прочитан при регистрации объекта. Также необходимо выделить параметры типа ”call-back” и при наличии зарегистрировать их. CallASObjMethod – вызывает метод прикладного объекта сервера приложений. “Посредник” должен проверить объект на зарегистрированность. Процедура вызова метода объекта аналогична вышеописанной, за исключением того, что вместо обращения к библиотеке функций сервера приложений происходит вызов метода объекта сервера приложений. GetASObjProp – возвращает значение свойства объекта сервера приложений. SetASObjProp – устанавливает значение свойства у указанного объекта. Функции TieASObject и UntieASObject весьма полезны для реализации доступа к прикладным объектам сервера приложений посредством символьного имени, которое может сгенерировать клиент. Также для успешного взаимодействия сервера приложений и клиента обоим компонентам, то есть “Посреднику” и “Заместителю”, необходимо иметь следующие функции и свойства : KillProcess – аварийно завершает процесс, ранее запущенный GetProcessCondition – запрашивает текущее состояние процесса. Возможные состояния – исполняется, в очереди, ждет ответа на call-back. Synhronize – сверяет идентификаторы зарегистрированных процессов, объектов и call-back’ов на клиентской и серверной части. Для Посредника процессы и объекты, которых нет на клиенте молча разрушаются, процессы и объекты, которых нет на сервере, но есть на клиенте, разрушаются с генерацией исключения для прикладной программы. Для Заместителя процессы и объекты, которых нет на сервере создаются заново, а процессы и объекты, которых нет на клиенте, но есть на сервере молча разрушаются. Logout – связь с сервером прерывается. Все начаты процессы аварийно завершаются, все созданные объекты разрушаются. По разрушением здесь подразумевается не разрушение прикладных объектов сервера приложений, а уничтожение указателей на их интерфейсы, которых может быть несколько. Методы только Посредника: InitCallBack – инициирует вызов call-back’а на стороне клиента с параметрами. Сall-back может вызываться тремя способами : блокирующим, неблокирующим и без подтверждения. Это указывается в типе вызова call-back’а. LockListener – запрещает обрабатывать входящие запросы. На все входящие запросы интерфейс отвечает, что он заблокирован. Количество вызовов должно подсчитываться в счетчике вызовов блокировок. UnLockListener – вычитает единицу из счетчика вызовов блокировки. Вновь разрешает обрабатывать запросы, если счетчик вызовов обнулился. CheckLock – проверка заблокированности интерфейса. DownServer – завершение работы сервера. Все начаты процессы завершаются, все созданные объекты разрушаются. Одной из интересных особенностей такого протокола является механизм реализации так называемых callback–параметров. Это параметры, которые передаются процедуре или функции при ее вызове, однако они не несут в себе данных как таковых. Вместо этого в каждом параметре содержится информация о том, каким образом эти данные можно получить. Например, это может быть указатель на функцию, которая вернет необходимый результат, или, если речь идет об объекте, указатель на интерфейс объекта и на его метод. Такой механизм удобен и позволяет экономить ресурсы сервера при обработке запросов. Литература [1] Объектные технологии построения распределенных информационных систем, Юрий Пуха, СУБД №3/97 [2] Симфония CORBA, Марина Аншина, Открытые системы, №3/98 [3] COM или CORBA? Вот в чем вопрос … Наталья Дубова, Открытые системы, №3/99 Интернет-ресурсы Официальный сервер OMG http://www.omg.org Описание проектов на базе CORBA http://www.corba.org Один из разработчиков CORBA Алан Поуп имеет свою страницу http://www.qds.com/people/apope/CORBA Распределенные объектные технологии от Microsoft http://www.objectwatch.com Несколько серверов, на которых содержиться информация по распределенным объектным технологиям: http://www.adtmag.com http://www.enterprisedev.com/ http://www.intelligententerprise.com/ http://www.sdmagazine.com/ http://www.componentmag.com/ http://www.appdevadvisor.com http://www.cutter.com/ http://www.objectnews.com/ http://www.osp.ru/os/
|