вер в значительной степени скрыт от клиента. Обычно бывают скрыты следующие элементы взаимодействия.

• Местоположение объекта: клиент не знает, где располагается целевой объект - в отдельном процессе на другой машине сети, в другом процессе той же самой машины или внутри текущего процесса.

• Реализация объекта: клиент не знает, каким образом реализован объект, какой язык программирования или язык сценариев использован для его реализации, какая операционная система или какое оборудование работает в объекте.

• Состояние объекта: при передаче запроса к целевому объекту клиент не должен знать, активизирован ли этот объект (то есть, запущен ли соответствующий процесс) и готов ли он принять запрос. В случае необходимости, перед тем как передать к объекту запрос услуги, ORB - компонент невидимо для клиента запускает процесс на объекте.

• Механизм связи с объектом: клиенту неизвестен механизм (например, протокол, разделяемая память, вызов локального метода и т. д.), с помощью которого к объекту будет доставлен запрос и от объекта будет получен ответ.

Эти особенности ORB дают возможность разработчикам приложений сконцентрировать внимание на самих приложениях и не беспокоиться о проблемах распределенного системного программирования нижнего уровня. Архитектура CORBA представлена на рисунке 5.6.9.

ХРАНИЛИЩЕ ИНТЕРФЕЙСОВ

компилятор

ЯЗЫКА IDL

ХРАНИЛИЩЕ РЕАЛИЗАЦИЙ

вх. арг.

АДАПТЕР ОБЪЕКТА

GIOP/IIOP

ЯДРО ШИНЫ ORB

(~Л СТАНД. ИНТЕРФЕЙС ИНТЕРФЕЙС ШИНЫ ORB

СТАНД. ОТОБРАЖЕНИЕ ЯЗЫКА

(~Л СТАНДАРТНЫЙ ПРОТОКОЛ

Рис. 5.6.9 Архитектура CORBA

Для передачи запроса клиент определяет целевой объект посредством ссылки, которая создается для каждого объекта CORBA в момент создания самого объекта. Используемая любым клиентом ссылка всегда соответствует именно тому объекту, для которого она была создана. Ссылка существует столь долго, сколько существует сам объект. Другими словами, ссылка всегда соответствует одному единственному объекту. Ссылки всегда постоянны и «закрыты» от клиента, так что он не может модифицировать их по своему усмотрению. «Внутренности» ссылки известны только ORB. Ссылки на объекты могут иметь стандартизованные форматы, например, в соответствии со стандартами OMG для Протокола взаимодействия между ORB-компонентами по правилам Internet (МОР - Internet inter ORB protocol) или же для Общего протокола взаимодействия между ORB-kom-понентами (GIOP - General inter ORB protocol). Могут быть использованы и другие подходящие форматы.

Перед тем как передать запрос к объекту, клиент должен знать типы операций, поддерживаемых этим объектом. Операции и типы данных, которые поддерживаются объектом, определяются с помощью интерфейса объекта. Интерфейс определяет те запросы, которые могут быть переданы к объекту и обслужены им. Интерфейсы для объекта определяются на языке IDL. Интерфейсы CORBA похожи на классы языка С++ и на интерфейсы языка Java. Так, интерфейс статических вызовов (SII - Static invocation interface) представляет собой не более, чем вызов процедуры на языке С к скомпилированному модулю. Интерфейс динамических вызовов (DM - Dinamic invocation interface) - это вызов процедуры С, но с дополнительным кодом. DM используется, когда на момент компиляции доступна не вся необходимая для вызова объекта информация.

Язык OMG IDL не является полноценным языком программирования, а представляет собой (каки GDM0/ASN.1) декларативный язык. Например, в нем отсутствуют средства построения управляющих конструкций (циклы, переходы). Он не предназначен для непосредственной реализации распределенных приложений; для этого определяются отображения языка - правила преобразования структур и типов OMG IDL в эквивалентные конструкции одного из стандартных языков программирования.

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

CORBA, вызов операций которого осуществляется по тем же правилам, что и операций других объектов CORBA. Язык IDL по своим возможностям практически не уступает языку GDM0/ASN.1 для описания информационных объектов.

5.6.3 IN и TINA

в предыдущих главах книги приведено немало доводов и примеров, подтверждающих эффективность концепции Интеллектуальной сети. Реализация платформы IN в инфраструктуре узкополосных сетей, потребовавшая от операторов сетей значительных капиталовложений, не предполагает замены такого дорогостоящего фундамента без очень серьёзных мотиваций. Однако повод для размышлений на эту тему уже просматривается. Это - все возрастающая потребность в мультимедийных услугах на базе широкополосных сетей B-ISDN, заставляющая операторов анализировать возможности усовершенствования и эволюции своих платформ IN для удовлетворения новых требований заказчиков, ради чего, собственно говоря, и была разработана TINA.

Хотя обе системы, и IN, и TINA, представляют собой архитектуры управления услугами информационных сетей произвольного типа, между функционально-ориентированной архитектурой IN и объектно-ориентированной архитектурой TINA существуют принципиальные различия, усложняющие их взаимодействие и взаимопроникновение. IN предусматриваетдекомпозициюуслуг в группы многократно используемых блоков SIB и определяет функциональные сетевые элементы для их распределенной реализации. Архитектура IN основана на идее централизации функций управления услугами в специальных сетевых узлах и управления удаленными коммутаторами через сеть ОКС-7. Согласно этому для IN определен ряд функциональных объектов, в которых размещены программы логики услуг (SCF), относящиеся куслугам данные (SDF), функции обнаружения запросов услуг в коммутаторе (SSF), атакже средстваэксплуатационного управления услугами (SMF). Связь между этими элементами осуществляется посредством информационных потоков, которые передаются по сети в операциях прикладного протокола INAP системы ОКС-7.

TINA базируется на технологии среды распределённой обработки (DPE), которая должна поддерживаться каждым сетевым узлом. Услуги в TINA моделируются путём взаимодействия между вычислительными объектами (СО), включающими в себя логику, интерфейсы и операции. Архитектурой TINA определена группа порождающих СО, которые могут использоваться при создании услуг посредством объединения разных СО из этой группы и настройки их параметров.