Компоненты архитектуры

Брокер Объектных Заявок. Брокер Объектных Заявок обеспечивает механизмы, позволяющие объектам посылать или принимать заявки, отвечать на них и получать результаты, не заботясь о положении в распределенной среде и способе реализации взаимодействующих с ними объектов. ORB отвечает за поиск реализации объекта, участвующего в заявке, подготовку объектной реализации к приему заявки и передачу данных, являющихся результатом заявки. Интерфейс клиента полностью независим от расположения вызываемого объекта, языка программирования, на котором он реализован, и любых других аспектов, не отраженных в интерфейсе вызываемого объекта. На основании совместных предложений ряда ведущих компаний OMG был разработан стандарт Общей Архитектуры Брокера Объектных Заявок (Common Object Request Broker Architecture (CORBA)) [7]. CORBA определяет среду для различных реализаций ORB, поддерживающих общие сервисы и интерфейсы. Это обеспечивает переносимость клиентов и реализаций объектов между различными ORB. В настоящее время существует ряд промышленных реализаций ORB, соответствующих стандарту CORBA [7]. CORBA непрерывно совершенствуется OMG. Текущий уровень стандарта -- CORBA 2.0. Объектные Службы. Объектные Службы представляют собой набор услуг (интерфейсов и объектов), которые обеспечивают базовые функции, необходимые для реализации других объектов. Операции, предоставляемые Объектными Службами, выступают в качестве базовых "строительных" блоков для Общих Средств и прикладных объектов. В настоящее время OMG приняты, или наxодятся в процессе формирования спецификации следующиx служб:

• Служба Уведомления Объектов о Событии (Event Notification Service).

• Служба Жизненного Цикла Объектов (Object Lifecycle Service).

• Служба Именования Объектов (Name Service).

• Служба Долговременного Хранения Объектов (Persistent Object Service).

• Служба Управления Конкурентым Доступом (Concurrency Control Service).

• Служба Внешнего Представления Объектов (Externalization Service).

• Служба Объектных Связей (Relationships Service).

• Служба Транзакций (Transaction Service).

• Служба Изменения Объектов (Change Management Service).

• Служба Лицензирования (Licensing Service)/

• Служба Объектных Свойств (Properties Service).

• Служба Объектных Запросов (Object Query Service).

• Служба Безопасности Объектов (Object Security Service).

• Служба Объектного Времени (Time Service).

Функции СУБД в информационной арxитектуре. Следуя принципам модульности и ортогональности компонентов информационной архитектуры, OMG представляет функции управления базами данных рядом таких служб, как долговременное хранение объектов, управление конкурентным доступом к объектам, служба транзакций, службы объектных связей, объектных запросов, изменений объектов и т.п. Эти и другие службы, взятые вместе, реализуют функции как объектных так и реляционных СУБД. Спецификация служб формируется на основе опыта промышленных корпораций, входящих в состав OMG. Существенное влияние на архитектурные решения оказывают также исследования и разработки, воплощенные в согласованном стандарте интерфейсов объектных СУБД [7,13], опубликованном в конце 1993 г. группой ODMG (Object Database Management Group). Эта группа включает представителей основных компаний - производителей объектных СУБД. Общие Средства. Общие Средства заполняют концептуальное пространство между ORB и объектными службами с одной стороны, и прикладными объектами с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Объектные Службы -- фундаментальные объектные интерфейсы, а задача Общих Средств -- поддержка интерфейсов сервисов высокого уровня. Общие Средства подразделяются на две категории: "горизонтальные" и "вертикальные" наборы средств. "Горизонтальный" набор средств определяет операции, используемые во многих системах, и не зависящие от конкретных прикладных систем. "Вертикальный" набор средств представляет технологию поддержки конкретной прикладной системы (вертикального сегмента рынка), такого, как здравоохранение, производство, управление финансовой деятельностью, САПР и т.д. Ниже кратко рассматривается состав первоначальных компонентов спецификации архитектуры Общих Средств OMG [16,17]. Средства поддержки пользовательского интерфейса (User Interface Common Facilities) Средства управления информацией (Information Management Common Facilities) Средства управления системой (System Management Common Facilities) Средства управления задачами (Task Management Common Facilities) Вертикальные общие средства (Vertical Common Facilities) Вертикальные общие средства предназначены для использования в качестве стандартных для обеспечения интероперабельности в специфических прикладных областях. Поддержка интероперабельности брокеров в стандарте CORBA 2.0 Интероперабельность брокеров поддерживается Универсальным Межброкерным Протоколом (General Inter-ORB Protocol, сокращенно GIOP). GIOP [9] является универсальным, поскольку он не зависит от конкретной сетевой транспортной среды и может быть отображен в любой транспортный протокол, поддерживающий виртуальные соединения. Одно из таких отображений - отображение GIOP в протокол TCP/IP - определено CORBA 2.0 в качестве Межброкерного Протокола Internet (Internet Inter-ORB Protocol, сокращенно IIOP). Назначение протокола GIOP/IIOP заключается в том, чтобы поддержать сети брокеров в рамках Internet и за ее пределами. Согласно GIOP, внутренняя архитектура брокеров предполагается неизвестной. Подход, который может быть выбран конкретным брокером для поддержки GIOP/IIOP, не определяется. Все, что требуется для согласованного включения брокера в компьютерную сеть, - это существование связанных с ним компонентов, способных посылать и принимать сообщения IIOP. Спецификация GIOP включает:

• Определение Общего представления данных (Common Data Representation - CDR), являющегося, по существу, коммуникационным синтаксисом, отображающим значения типов данных OMG IDL в формат передачи данных между брокерами и межброкерными мостами (агентами);

• Форматы передаваемых между агентами сообщений GIOP, которые введены для поддержки объектных заявок, установления местоположения реализаций объектов и управления транспортными соединениями.

• Определение ограничений на допустимый сетевой транспорт GIOP.

Протокол IIOP, который можно считать специализацией GIOP, определяет дополнительно, как агенты открывают соединения TCP/IP и используют их для передачи сообщений GIOP.