Корпоративные информационные системы

5.                 Trading, сервис коммерции, альтернатива сервису наименований. Вместо ссылки на нужный объект по имени дает возможность объекту-отправителю выбрать группу объектов заказанного типа.

6.                 Life Cycle, сервис функциональности разрешает создавать, копировать, перемещать и уничтожать компоненты по ORB.

7.                 Externalization, сервис импорта / экспорта - с его помощью внутренние (internal) параметры объекта сохраняются в текстовом файле, из которого затем можно скопировать или восстановить объект с теми же параметрами.

8.                 Licensing, сервис лицензирования, защищает от несанкционированного использования программных компонентов в распределенной среде.

9.                 Time, сервис времени - набор интерфейсов для установки текущего времени и операций с временными интервалами. Дает возможность оперировать с событиями во времени.

10.             Property, сервис свойств, используется для приписывания свойств объектам. Это нужно в тех случаях, когда само приложение не может приписать объекту распределенной среды необходимые свойства через механизм атрибутов и операций, не затрагивая IDL определения.

11.             Relationships, сервис отношений, с его помощью можно связать два типа объектов через IDL определения.

12.             Concurrency Control, сервис согласования, предохраняет систему от разрушения в случаях совместного использования одних и тех же данных. В такой ситуации сервис определяет способы блокировки данных.

13.             Persistent Objects, сервис надежного хранения - для особо важных данных, которые надо хранить в защищенных структурах, таких как БД или специальные файловые системы. Интерфейсы сервиса могут выполняться, например, над реляционной базой данных, включенной в распределенную систему.

14.             Query, сервис запросов, определяет тип простого набора данных и способы выполнения запросов (query) к объектам такого набора. Поддерживает большинство query языков и прежде всего SQL. Соответствует SQL3 спецификациям.

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

11.5 Common Facilities - общие средства

Между объектными сервисами и общими средствами CORBA нет четкой границы. Так, лицензирование вполне могло бы относиться к общим  средствам. Чтобы пояснить, что такое  общие средства, проще всего перечислить те из них, которые уже включены в стандарт.

USER Interface - представление  объектов и сложных документов. Сюда входят средства работы  с подсказками, проверка правописания  и грамматики, управление рабочим  полем (desktop). Система OpenDoc (совместная разработка группы компаний, среди которых и IBM) может служить хорошим примером использования USER Interface.

Information management - моделирование  информации, ее сохранение и восстановление, кодирование и перевод, поддержка  времени и календаря. System management - управление ORB и CORBA приложениями. Для этой спецификации OMG использовала стандарт X/Open. Task management - контроль выполнения, отслеживание агентов.

Все перечисленные  интерфейсы представляют собой горизонтальные средства, общие для всех доменов. Домен в лексике CORBA - отрасль промышленности. Это одно из ключевых понятий, ведь основная задача OMG - объединение именно промышленных приложений. Нетрудно заметить, что промышленные приложения сильно зависят от предмета, который призваны автоматизировать. Поэтому кроме общих горизонтальных средств выделились вертикальные общие средства по доменам. Сейчас они определены по следующим направлениям: телекоммуникация, финансы, производство, медицина, транспорт, электронная коммерция, бизнес-объекты. Этот список постоянно пополняется: выпускаются новые RFP, по ним разрабатываются новые стандарты, которые относятся к Object Services или Common Facilities, к Application или Domain Interfaces.

11.6 Достоинства CORBA

1.     Язык IDL поддерживает разнообразные программные языки, операционные системы, сети и объектные системы. IDL позволяет отделить описание интерфейса от его реализации. Таким образом, можно менять объекты, не затрагивая интерфейсы. Приложение, даже если оно написано не на объектно-ориентированным языке, с помощью IDL можно инкапсулировать в объектную структуру.

2.     CORBA - сетевая архитектура по определению, эта идея лежит в основе его развития. Объектно-ориентированные интерфейсы CORBA легко определять, создавать и использовать.

3.     Каждый сервер может содержать много объектов. Связь между отправителем и адресатом осуществляется напрямую. Объекты могут быть разных размеров.

4.     CORBA хорошо сочетается с разнообразным промежуточным ПО, включая OLE языки (например, для реализации интерфейса можно использовать VisualBatch).

5.     В рамках CORBA можно обеспечить необходимый уровень безопасности системы.

6.     Интеграция с другими распространенными технологиями: базами данных, системами обработки сообщений, системами обработки пользовательского интерфейса и другими. Специализация по отраслям промышленности открывает дополнительные возможности для приближения объектов к реальным структурам.

7.     Существует протокол IIOP, который позволяет взаимодействовать различным ORB по TCP/IP. CORBA сервисы обеспечивают ряд дополнительных возможностей: транзакции, события, query и т. д. Одновременная поддержка статических и динамических интерфейсов. Возможность включения в распределенную среду Web-клиентов и серверов, в частности, через Java-реализации CORBA.

8.     CORBA - широко используемый стандарт, со множеством реализаций, но создается и поддерживается он централизованно, OMG.

9.     Так как CORBA - только стандарт, между его реализациями естественное возникает соревнование. Тем самым повышается качество продуктов, а их совместимость заложена в стандарте.

10. По мере развития CORBA процесс создания программных приложений все больше напоминает конструирование из готовых деталей.

11.7 Обзор протоколов GIOP и IIOP

Спецификация  протокола GIOP состоит из следующих элементов:

1.     Определение Общего Представления Данных (Common Data Representation - CDR). CDR - это способ кодирования типов данных, определенных в IDL в низкоуровневое представление, пригодное для передачи их по имеющимся каналам связи между ORB-ами.

2.     Формат сообщения протокола GIOP. Сообщения протокола GIOP обеспечивают нахождение объекта, отработку запросов, а также простейшее управление каналом коммуникации.

3.     Предположения о транспорте. Спецификация GIOP описывает общие предположения, которые делаются при рассмотрении любого сетевого транспортного слоя, который может быть использован для обмена сообщениями протокола GIOP. Также описываются общие принципы управления соединением.

Спецификация IIOP добавляет к спецификации протокола GIOP следующий пункт:

4.     Транспорт для сообщений протокола IIOP.

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

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

Протокол  обмена GIOP

За исключением  редкого случая прямых вызовов методов  между классами одного и того же языка программирования необходим  механизм кодирования вызова метода в некоторую последовательность байт (byte stream) у клиента и декодирования этой последовательности у сервера. Для этой цели спецификация CORBA определяет Общий Протокол обмена между Брокерами Объектных Запросов (General Inter-Orb Protocol - GIOP). Кроме того, определен протокол передачи сообщений протокола GIOP поверх транспортного протокола TCP/IP, являющегося основным видом взаимодействия в Internet, ввиду чего этот протокол получил название Протокола обмена между Брокерами Объектных в Internet (Internet Inter-Orb Protocol - IIOP). Протокол IIOP должен поддерживаться всеми Брокерами Объектных Запросов независимо от особенностей их реализации, что является главным требованием для обеспечения взаимодействия между произвольными ORB-ами двух разных и совершенно независимых производителей.

Особенности и цели протокола

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

1.     Распространенность

Протоколы GIOP и IIOP разрабатывались с учетом доступного широко распространенного и гибкого  транспортного механизма (TCP/IP) и  задает минимум дополнительных протоколов, необходимых для передачи запросов между отдельными ORB-ами.

2.     Простота

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

3.     Масштабируемость

Протокол GIOP/IIOP должен поддерживаться как отдельными ORB-ами, так и ORB-ами, объединенными  в сеть на уровне Internet и, возможно, шире.

4.     Небольшие затраты на реализацию

Реализация  поддержки протоколов GIOP/IIOP должна потребовать минимальных затрат как в плане инженерного проектирования, так в плане распространения готовых ORB-ов.

5.     Общность

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

6.     Архитектурная независимость

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

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

Формат  сообщений протокола GIOP

Перед тем, как  описывать сообщения протокола GIOP, необходимо определить понятие клиента  и сервера. Под клиентом далее  понимается агент, который открыл соединение и инициировал запрос. Сервер - это агент, который принял соединение и этот запрос получил. Протокол GIOP определяет семь сообщений, список которых приведен далее в таблице вместе с указанием того, какая сторона какие сообщения может посылать.

Значение, соответствующее  типу сообщения	Тип сообщения	Кто может посылать сообщение
		Клиент	Сервер
0	Request	Да	-
1	Reply	-	Да
2	CancelRequest	Да	-
3	LocateRequest	Да	-
4	LocateReply	-	Да
5	CloseConnection	-	Да
6	MessageError	Да	Да

Заголовок сообщения  однозначно определяет его тип. Заголовок  определен таким образом, чтобы  не зависеть от порядка байт в представлении  базовых типов данных. Элементами заголовка являются:

1.     Поле magic, которое состоит из четырех символов "GIOP", идентифицирующих все сообщения протокола GIOP.

2.     Поле GIOP_version, которое состоит из двух полей major и minor, идентифицирующих старший и младший номера версии используемого протокола. Текущая спецификация определяет версию 1.0. Приложение должно поддерживать взаимодействие в рамках протокола только если номер, содержащийся в поле major равен, а в поле minor - больше или равен номерам версии, используемой при разработке приложения.

3.     Поле byte_order. Значение 0 в этом поле определяет, что в сообщении принято кодирование данных с лидирующим наиболее значащим байтом, 1 - наименее значащим. В настоящее время подавляющее большинство процессоров, в том числе и серия Intel x86 используется представление с лидирующим наименее значащим байтом.

4.     Поле message_type содержит значение от 0 до 6, определяющее тип сообщения.

5.     Поле message_size содержит длину оставшейся части сообщения (0 если больше ничего нет).

За общим  заголовком каждого сообщения в  зависимости от его типа может  идти заголовок и тело конкретного сообщения. Структура каждого заголовка специфична для каждого типа сообщения и представляет особенного интереса для рассмотрения.

Транспорт для протокола GIOP

Протокол GIOP предназначается  для реализации поверх большого количества транспортных протоколов. При этом делаются следующие предположения об особенности протокола:

1.     Транспорт ориентируется на установление соединения с последующим обменом информации в рамках соединения. Соединение используется для определения правил нумерации запросов.

2.     Транспорт протокол должен гарантировать прохождение переданных байт в том порядке, в котором они были посланы.