Объектно-ориентированные технологии распределенной обработки

Сегодня наибольшее применение для разработок приложе­ний распределенной обработки находят две компонентные модели — DCOM и CORBA. Эти технологии реализуют трех­уровневую архитектуру модели «клиент—сервер». Введение спе­циального промежуточного слоя — сервера приложений, которому «делегированы полномочия» организации взаимодействия клиента и сервера, обеспечивает возможность интеграции объектов, размещенных на машинах разных платформ и под управление разнотипных операционных систем.

Обе модели распространяют принципы вызова удаленных процедур на объектные распределенные приложения и обеспечивают прозрачность реализации и физического размещения серверного объекта для клиентской части приложения; поддерживают возможность взаимодействия объектов, созданных различных объектно-ориентированных языках и скрывают от приложения детали сетевого взаимодействия.

Основу этого подхода составляет «минимальная» объектная модель, обладающая ограниченными возможностями, но имею­щая обязательные аналоги в наиболее распространенных объ­ектных системах. В архитектуре CORBA используется модель Core Object Model с соответствующим языком спецификации интерфейсов объектов (Interface Definition Language — IDL). Чтобы обеспечить возможность взаимодействия объекта, существующего в одной системе программирования, с некоторым объектом из другой системы программирования, в исходный текст первого объекта (объявления его класса) должна быть по­мещена IDL-спецификация интерфейса (имя метода, список имен и типов данных входных и выходных параметров) того объекта, метод которого должен быть вызван. Аналогичная спе­цификация должна быть помещена на стороне вызываемого объекта. Далее, спецификации, транслированные IDL-процессором в выражения языка программирования, включаются в ис­ходный текст программы на языках Си, Java.

DCOM

В DCOM-технологии, представленной на рис. 7.12, взаимо­действие между клиентом и сервером осуществляется через двух посредников. Клиент помещает параметры вызова в стек и обра­щается к методу интерфейса объекта. Это обращение перехваты­вает посредник Proxy, упаковывает параметры вызова в СОМ-пакет и адресует его в Stub, который в свою очередь распаковывает параметры в стек и инициирует выполнение метода объекта в пространстве сервера.

При этом объект должен быть предварительно зарегистрирован на локальной машине, чтобы клиент с помощью распределенной службы имен (в качестве ко­торой Microsoft предлагает Active Directory) мог его отыскать по глобальному уникальному идентификатору (GUId).

CORBA

CORBA-технология также использует интерфейс объекта, но в этом случае схема взаимодействия объектов (рис. 7.13) включа­ет промежуточное звено (Smart agent), реализующее доступ к уда­ленным объектам. Smart agent, установленный на машинах сете­вого окружения (сервере локальной сети или Internet-узле), мо­делирует сетевой каталог известных ему серверов объектов. Регистрация объектов сервера в каталоге одного или нескольких Smart agent'oB происходит автоматически при создании сервера.

Связи между брокерами осуществляются в соответствии с требованиями специального протокола General Inter ORB Protocol, определяющего низкоуровневое представление данных и множество форматов сообщений.

На машине клиента создаются два объекта-посредника: Stab (заглушка) и ORB (Object Required Broker — брокер вызываемого объекта). Так же как и в DCOM-технологии, Stub передает пере­каченный вызов брокеру, который посылает широковещательное сообщение в сеть. Smart agent, получив сообщение, отыскивает сетевой адрес сервера и передает запрос брокеру, размещенному на машине сервера. Вызов требуемого объекта производится через специальный базовый объектный адаптер (BOA). При этом данные в стек пространства вызываемого объекта помещает особый объект сервера (Skeleton — каркас), который вызывается адаптером.

CORBA имеет два механизма реализации запросов к объектам:

• статический, предполагающий использование заглушек каркасов, интерфейсы которых были сгенерированы при создании объекта;

• динамический вызов с помощью интерфейса динамического вызова (DII).

Интерфейс динамического вызова позволяет определять объекты и их интерфейсы во время выполнения, а затем формировать заглушки. Аналогично, на стороне сервера может использо­ваться динамический интерфейс каркасов (DSI), что позволяет обращаться к реализации объекта, для которого на этапе созда­ния не был сформирован каркас.

Ключевым компонентом архитектуры CORBA является язык описания интерфейсов IDL, на уровне которого поддерживают­ся «контрактные» отношения между клиентом и сервером и обеспечивается независимость от конкретного объектно-ориен­тированного языка. CORBA IDL поддерживает основные поня­тия объектно-ориентированной парадигмы (инкапсуляцию, по­лиморфизм и наследование). При этом CORBA-объекты могут быть преобразованы в объекты языков программирования (на­пример, Java, С, C++), т. е. будут сформированы файлы:

• исходного клиентского кода, содержащего интерфейсные заглушки;

• исходного серверного кода, содержащего каркасы;

• заголовков, которые включаются в клиентскую и серверную программы.

В модели DCOM также может использоваться разработан­ный Microsoft язык IDL, который, однако, играет вспомогатель­ную роль и используется в основном для удобства описания объ­ектов. Реальная интеграция объектов в DCOM происходит не на уровне абстрактных интерфейсов, а на уровне бинарных кодов, и это одно из основных различий этих двух объектных моделей.

Как DCOM, так и CORBA, в отличие от процедурного RPС., дают возможность динамического связывания удаленных объектов: клиент может обратиться к серверу-объекту во время выполнения, не имея информации об этом объекте на этапе компиляции. В CORBA для этого существует специальный интерфейс динамического вызова DII, a COM использует механизм OLE-Automation. Информацию о доступных объектах сервера на этапе выполнения клиентская часть программы получает из специального хранилища метаданных об объектах — репозитария интерфейсов Interface Repositary в случае CORBA, или библиотеки типов (Type Library) в модели DCOM. Эта возможность очень важно для больших распределенных приложений, поскольку позволяет менять и расширять функциональность серверов, не внося существенных изменений в код клиентских компонентов программы. Например, банковское приложение, основная биз­нес-логика которого поддерживается сервером в центральном офисе, а клиентские системы — в филиалах, размещенных в раз­ных городах.

Контрольные вопросы

1. Какие разновидности систем «клиент—сервер» вы знаете?

2. Что такое файловый сервер?

3. Что такое сервер баз данных?

4. Что такое сервер приложений?

5. Сформулируйте основные требования к системам управления рас­пределенными базами данных.

6. Перечислите основные условия и предпосылки появления систем управления распределенными базами данных.

7. Перечислите основные различия системы распределенной обработки данных и системы распределенных баз данных.

8. Обоснуйте целесообразность разделения «клиентских» и «сервер­ных» функций.

9. Проведите сравнительный анализ распределения функций для различ­ных базовых архитектур.

10. Определите основные принципы и примерные структурные схемы

сервера распределенной обработки.

11 Перечислите основные решения распределенной обработки на основе

межмодульного взаимодействия.