Предисловие редакторов русского издания

Вид материала

Документы

Содержание Компоненты CORBA: от системных овъектов к визнес-объектам ОМА - Архитектура Управления Объектами от OMG (Object Management Architecture) Брокер ОБъектиых запросов - Object Request Broker (ORB) Самоописываемая система. Встроенная безопасность ч транзакции. Полиморфные сообщения. Сосуществование с существующими системами.

Подобный материал:

• От редакторов русского издания, 12579.28kb.
• Предисловие переводчика и редактора русского издания, 173.31kb.
• Предисловие от редакторов, 3279.6kb.
• Крайон книга третья. Алхимия человеческого духа руководство по переходу человечества, 3416.54kb.
• Электронная библиотека студента Православного Гуманитарного Университета, 3857.93kb.
• Предисловие, 5158.35kb.
• Автор файла (январь 2009г.): Мухамеджан Мухамеджанов, 250.83kb.
• Предисловие ко второму изданию, 1366.96kb.
• Аллан Кардек спиритизм в самом простом его выражении содержание, 4227.55kb.
• Философия русского религиозного искусства XVI-XX вв. Антология, 6335.43kb.

Компоненты CORBA: от системных овъектов к визнес-объектам

Обратите внимание, что мы использовали термины «компоненты» и «распределенные объекты» как взаимозаменяемые. Распределенные объекты CORBA по определению являются компонентами из-за спосо­ба их упаковки. В распределенных объектных системах единицей работы и распределенности является компонент. Инфраструктура распределен­ных объектов CORBA предоставляет простые механизмы, чтобы ком­поненты стали более автономными, самоуправляемыми и взаимодей­ствующими. Такая заявка намного смелее, любых попыток конкуриру­ющих форм промежуточного программного обеспечения Технология распределенных объектов CORBA позволяет нам собирать в единое це­лое сложные информационные клиент/серверные системы, просто свя­зывая и расширяя их компоненты. Вы можете модифицировать объек­ты, не влияя на другие компоненты или на то, как они взаимодейству­ют. Клиент-серверные приложения превращаются в наборы взаимодей­ствующих компонентов

Последняя «нирвана» в области индустрии компонентов клиент/сер­вер - суперинтеллектуальные компоненты, которые не просто взаимо­действуют, — они сотрудничают на семантическом (смысловом) уров­не, чтобы выполнить необходимую работу. Программисты могут легко добиться необходимого взаимодействия компонентов, , создавая про­граммный код независимо для каждого компонента . Хитрость, однако, состоит в том, чтобы создать компоненты, которые a priori ничего не знают друг о друге, но сделают именно то, что нужно. Чтобы этого до­биться, необходимы стандарты, устанавливающие правила стыковки на разных уровнях взаимодействия компонентов.

ОМА - Архитектура Управления Объектами от OMG (Object Management Architecture)

Осенью 1990 года OMG впервые опубликовала Руководство по Ар­хитектуре Управления Объектами (Object Management Architecture Guide -ОМА Guide). Его обновление было сделано в 1992 году. Подробности, касающиеся Общих Средств (Common Facilities) были добавлены в янва­ре 1995. На рис.12 показаны четыре основных элемента данной архитек­туры: 1) Брокер Объектных Запросов (Object Request Broker - ORB) опре­деляет объектную шину CORBA; 2) Сервисы CORBA (CORBAservices) определяют системный уровень объектной структуры, которая расши­ряет шину; 3) Общие Средства CORBA (CORBAfacilities) определяют го­ризонтальные и вертикальные структуры, которые непосредственно используются бизнес-объектами; 4) Application Objects представляют прикладные объекты и приложения, то есть конечных потребителей инфраструктуры CORBA. Данный раздел описывает общий взгляд на четыре приведенных элемента инфраструктуры CORBA.

Брокер ОБъектиых запросов - Object Request Broker (ORB)

Брокер объектных запросов - это объектная шина. Она позволяет объектам прозрачно генерировать запросы и получать ответные отклики от других объектов - локальных или удаленных. Клиент ничего не знает о механизмах, используемых для коммуникации, активизации или хране­ния серверных объектов. Спецификации CORBA 1.1 (выпущенные в 1991) определяют только IDL, языковое связывание и API для обращения к ORB. Таким образом, вы могли бы написать переносимые программы, способные работать на дюжине CORBA-совместимых ORB, представ­ленных на рынке (особенно со стороны клиента). CORBA 2.0 определяет взаимодействие (interoperability) ORB разных производителей.



Рис 1.2 Архитектура Управления Объектами ОМС

CORBA ORB обеспечивает широкий спектр сервисов распределен­ного промежуточного программного обеспечения. ORB позволяет объек­там обнаруживать друг друга во время выполнения (run-time) и вызы­вать сервисы друг друга.

ORB намного более сложен, чем альтернативные формы клиент/ серверного middleware, включая традиционные вызовы удаленных про­цедур (Remote Procedure Calls - RPC), обмен сообщениями (Message-Oriented Middleware — MOM), хранимые процедуры баз данных или се­тевые службы взаимодействия "точка-точка" (peer-to-peer). Теоретичес­ки, CORBA является лучшим клиент/серверным middleware из когда-либо определенных. На практике же CORBA хороша настолько, насколько хорош реализующий эту архитектуру продукт.

Чтобы показать, почему CORBA ORB так хороши для ППО архи­тектуры клиент/сервер, мы приводим следующий «краткий» список за­мечательных свойств, присущих всем ORB:

• Статические и динамические вызовы методов. CORBA ORB позволя­ет статически определять вызовы ваших методов во время компиля­ции или находить их динамически во время выполнения. Таким об­разом, вам предоставляется выбор: строгий контроль типов на ста­дии компиляции или максимальная гибкость при отложенном (на этапе выполнения) связывании. Большинство других видов middleware поддерживают только статическое связывание.

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

Самоописываемая система. CORBA предоставляет метаданные на этапе выполнения для описания каждого серверного интерфейса, известного системе. Каждый CORBA ORB должен поддерживать Ре-позитарий Интерфейсов (Interface Repository), который содержит те­кущую (real-time) информацию, описывающую предоставляемые сервером функции и их параметры. Клиенты используют метадан­ные, чтобы определить, каким образом вызывать сервисы во время выполнения. Метаданные также помогают инструментальным сред­ствам создавать код «на- лету». Такие метаданные генерируются ав­томатически либо прекомпиляторами языка IDL, либо такими ком­пиляторами, которые знают, как генерировать IDL непосредствен­но из объектно-ориентированного языка. Например, компилятор MetaWare C++ генерирует IDL непосредственно из определения класса C++; Inprise VisiBroker/Netscape Caffeine генерирует IDL не­посредственно из байт-кода Java. Насколько нам известно, не суще­ствует других видов middleware клиент/сервер, которые бы обеспечи­вали такой тип метаданных и независимые от языка определения для всех своих сервисов. Как станет ясно из дальнейшего изложения, все бизнес-объекты и компоненты требуют позднего связывания, чтобы обеспечить наибольшую гибкость, на которую они способны. Прозрачность локальная/удаленная. ORB может выполняться в авто­номном режиме на лаптопе, или же может взаимодействовать со всеми другими ORB во вселенной, используя сервисы протокола ПОР (Internet Inter-ORB Protocol — Internet-протокола взаимодействия ORB) стандарта CORBA 2.0. ORB может выступать в качестве посред­ника для межобъектных вызовов внутри единственного процесса, нескольких процессов, выполняющихся на одном компьютере, или множества процессов, выполняющихся в разных сетях под управле­нием разных операционных систем. Такой механизм полностью про­зрачен для ваших объектов. Обратите внимание, что ORB может выступать посредником как между "мелко-зернистыми" объектами — подобными классам C++, так и для более масштабных — "круп­но-зернистых" объектов. В общем случае, CORBA-программисту нет дела до транспортных протоколов, местоположения серверов, ак­тивации объектов, порядка следования байтов через различные плат­формы или целевых операционных систем — CORBA все это сделает прозрачным.

• Встроенная безопасность ч транзакции. ORB включает в свои сообще­ния контекстную информацию для управления безопасностью и тран­закциями при переходе с машины на машину и через границы ORB.

• Полиморфные сообщения. В отличие от других форм middleware, ORB не просто вызывает удаленную функцию — он вызывает функцию целевого объекта. Это означает, что вызов одной и той же функции может дать разный эффект, в зависимости от объекта, принимаю­щего вызов. Например, вызов метода con'figure_yoiirself приведет к разным результатам в случае вызова для объекта базы данных и для объекта-принтера (см. также следующую врезку).

• Сосуществование с существующими системами. Отделение опреде­ления объекта от его реализации в архитектуре CORBA обеспечива­ет возможность инкапсуляции существующих приложений. Исполь­зуя CORBA IDL, вы можете сделать ваш существующий код, по­добным объекту на шине ORB, даже если он реализован в хранимых процедурах, CICS, IMS или КОБОЛе. Это делает CORBA эволюци­онным решением. Вы можете написать ваши новые приложения как "чистые" объекты и инкапсулировать существующие приложения в IDL-обертку.