Теле2 

Клиент серверное приложение corba. Введение в разработку VisiBroker CORBA в среде JBuilder

Источник: JBuilder

Введение

В любой организации связанные с бизнесом направления работы распределены между различными членами организации для более эффективной обработки каждой части. Таким же образом распределяются и объекты в киберпространстве организации для наиболее эффективного выполнения их бизнес-функций. Парадоксально, но цель системы распределенных объектов заключается в лучшей интеграции организации. Достаточно осмысленное и продуманное распределение объектов на все бизнес-процессы организации создает большую связность, дополнительную эффективность и делает систему в целом гораздо более рациональной. Однако это распределение должно быть идеально продуманно, ибо распыление объектов по ветру несомненно вредно. Чтобы предотвратить подобные ошибки, в этой статье представлены мощные технологии такие, как CORBA и Java, реализованные в средствах разработки Borland, - VisiBroker и JBuilder. Часто оказывается, что распределенные системы представляют большую сложность на всех стадиях жизненного цикла программ - от проекта до управления. Продукты JBuilder и VisiBroker призваны усовершенствовать этот процесс, упрощая создание и развертывание распределенных приложений CORBA. С появлением JBuilder 3.5, интеграция с CORBA становится "беcшовной" с добавлением нескольких возможностей, ориентированных на помощь разработчикам при создании объектов VisiBroker CORBA, сервлетов, серверов и клиентов на Java.

В этой статье использован практический подход к представлению VisiBroker и каждая тема проиллюстрирована реальным приложением. Вместо представления CORBA в целом, мы будем описывать концепции по мере того, как они будут нам здесь встречаться. Этот метод помогает лучше представить концепции CORBA с помощью наглядной иллюстрации теории непосредственным примером.

Что же такое CORBA?

С появлением Intranet и Internet, сетевые вычисления в конечном счете становятся доминирующим направлением разработки программного обеспечения. Но как может множество столь разнообразных систем взаимодействовать друг с другом? Чтобы справиться с этой проблемой, OMG непрерывно занимается разработкой спецификаций CORBA. Эти спецификации стандартизируют пути сетевого взаимодействия программ друг с другом. CORBA, однако, выходит за рамки простого взаимодействия; это - гибкое, настраиваемое связующее решение для многозвенных приложений - т.н. middleware, или ПО промежуточного уровня. Common Object Request Broker Architecture (Общая архитектура брокера объектных запросов) (CORBA) - совокупность спецификаций, разработанных и стандартизированных Object Management Group (OMG).

OMG, или рабочая группа по развитию стандартов объектного программирования, является консорциумом приблизительно 800 компаний компьютерной промышленности. Главным направлением деятельности OMG является определение структуры архитектуры, называемой Object Management Architecture (OMA), которая является структурой архитектуры для распределенных вычислений. OMG не является организацией, разрабатывающей стандарты. Ее целью является содействие принятию промышленностью спецификаций интерфейса для управления распределенными объектами. Еще раз отметим, что этот некоммерческий консорциум не устанавливает промышленные стандарты. Вместо этого OMG содействует принятию стандартов путем достижения согласия среди его участников. По своей природе стандарты, рассматриваемые для принятия OMG, не являются теоретическими; они были реализованы и испытаны на практике. Стандарт CORBA определяет, как объекты представляют себя, и как они взаимодействуют в распределенной среде, наряду с протоколами связи для взаимодействия между объектами.

Структура стандарта CORBA позволяет индивидуальным поставщикам программных продуктов, таким как Borland, разрабатывать программы, соответствующие рекомендациям OMG. Несколько компонентов реализации CORBA определены по стандарту OMG; однако, большинство поставщиков расширяет набор этих основных компонент для обеспечения законченного решения. Данная статья посвящена реализации CORBA VisiBroker и представляющим его компонентам.

Что такое - распределенная объектная система?

Понятие "распределенный" предполагает географически рассредоточенные объекты. Фактически распределенная объектная система - простое смешение двух технологий - сетевого и объектно-ориентированного программирования. Сети делают возможными распределенные вычисления, объекты обеспечивают инкапсуляцию, многократное использование и повышенную надежность в эксплуатации. Одной из наиболее значительных движущих сил распределенных вычислений является Web. Будучи самой большой в мире распределенной системой, она соединяет радикально отличающиеся технологии, информацию и носители. Однако не каждая распределенная система обязательно "объектно-ориентирована". Объединение сетевого и объектного подхода ведет к значительному усовершенствованию управления разработкой и сопровождением программного обеспечения, многократному использованию и масшабируемости.

Почему распределенная?

Если организация находится в одном месте (иными словами имеет единственное местоположение) и лишь несколько компьютеров, подобной организации, вероятно, нет необходимости в распределении своих объектов. Большинство организаций, однако, быстро проходят этот этап и начинают расширять свои позиции: появляется несколько местоположений, разнообразные направления бизнеса и множество компьютеров. Для этих организаций распределенные вычисления смогут повысить уровень масштабируемости решений. Кроме этого, мотивация для разработки систем в распределенном или многозвенном исполнении может иметь несколько причин. Многозвенные распределенные приложения предлагают ряд преимуществ по сравнению с традиционной разработкой клиент/серверных приложений. Для понимания преимуществ n-звенных приложений, полезно обратить внимание на недостатки других подходов; например диаметральной противоположности распределенной системы - централизованной системы, базирующейся на единственном mainframe-компьютере. Как отмечали сторонники клиент/серверной архитектуры, эта система имеет несколько недостатков. При недоступности mainframe-компьютера не может быть выполнена никакая обработка. Кроме того, все данные должны быть переданы центральному компьютеру, который, по сути, является основным архивом. Аналогично в клиент/серверной среде, клиент - это обычно более увесистая часть кода со специализированной базой данных (SQL, AS/400, и т.д.), предназначенная для обеспечения хранения данных. Проблема, связанная с этой моделью, состоит в том, что большинство систем баз данных не могут представлять и предписывать все бизнес-правила и процессы, необходимые сложной программной системе. Из-за этого несоответствия бизнес-логика часто разбивается между клиентским приложением и приложением-сервером. Такого рода практика вызывает массу проблем, связанных с надежностью в эксплуатации, многократным использованием и обновлениями, так как бизнес-логика не принадлежит отдельному звену приложения.

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

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

Почему CORBA?

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

Способность объектов CORBA обмениваться информацией в Web и в пределах Intranet с использованием IIOP - одна из основных причин, по которой CORBA была так активно принята. При выборе промежуточных приложений, CORBA предлагает ряд преимуществ по сравнению с другими подходами, подобными DCOM, включая независимость от платформ, больший контроль над процессами передачи информации между объектами и подтвержденную стабильность.

Архитектура VisiBroker

Обзор ORB

Архитектура CORBA составлена из нескольких сервисов, руководящих принципов и процессов, которые позволяют распределенным объектам связываться друг с другом. OMA, как описано ранее, логически разделен на две высокоуровневые компоненты. Это разделение позволяет проектировщикам систем создавать распределенные архитектуры, основанные на OMA, из компонентов от многочисленных поставщиков.

Системно-ориентированный компонент: брокер объектных запросов (Object Request Broker )
Компонент, ориентированный на приложение: объекты приложения CORBAfacilities.

Брокер объектных запросов (Object Requests Broker, ORB) - основной компонент OMA. ORB определяет и обеспечивает средства для обмена информацией между объектами. ORB, или Брокер объектных запросов, является связующим средством, которое обеспечивает набор сервисов, позволяющих двум объектам связываться по сети. Приведем примеры некоторых сервисов, реализованных в ORB. Это - активизация объекта, местоположение и связь. Эти сервисы документированы в архитектуре CORBA. Существует много поставщиков ORB. Некоторые поставщики ORB подобно Borland также реализуют другие сервисы CORBA, такие как сервис именования, сервис событий, сервис транзакций и сервис баз данных. Эти дополнительные услуги обеспечивают базовую структуру для создания масштабируемых, распределенных программных систем.

CORBAfacilities являются коллекциями объектов, определенных на языке IDL, которые могут непосредственно использоваться приложениями. Они состоят из горизонтальных и вертикальных компонентов, которые описывают правила взаимодействий между объектами. Они родственны Java Bean из мира Java.

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

Брокер объектных запросов (ORB) - связующее средство, которое обеспечивает набор сервисов для нахождения и использования реализаций различных объектов. Брокер объектных запросов (ORB) является основой OMA. Он определяет инфраструктуру, позволяющую компонентам CORBA связываться друг с другом. Запомните, ORB - это то, что обычно упоминается как CORBA. Польза от использования ORB-ов заключается в том, что они скрывают запутанность метода обращения, посылаемого объекту. Когда клиентский объект вызывает метод на объекте сервера, независимо от его местоположения, ORB перехватывает запрос и находит соответствующий сервер. Удобным является то, что поставщики ORB теперь записывают весь коммуникационный код, когда-либо написанный разработчиками. ORB -ы могут сообщать друг другу об использовании стандартных протоколов связи. Это позволяет объектам клиента и сервера CORBA быть реализованным на различных языках программирования и в различных операционных средах. После того, как серверный ORB принимает клиентский запрос, вызывается метод объекта сервера с передачей соответствующих параметров. Как только объект сервера закончил обработку, серверный ORB возвращает результаты клиентскому объекту через клиентский ORB. Клиенты могут получить набор параметров результатов от единственного запроса метода объекта сервера. Входные (in) параметры IDL и сквозные (in/out) параметры реализованы только для этой цели. Таким образом, ORB освобождает программистов от значительного объема рутинной работы. Объекты могут обмениваться информацией независимо от их местоположения, операционной системы и языка программирования.

Основная реализация CORBA обычно включает Брокер объектных запросов (ORB), компилятор для IDL (Язык определений интерфейсов CORBA), и Общие объектные сервисы (COS), которые помогают объектам в процессе взаимодействия. Если объект локальный, ORB делает локальный запрос метода, если объект находится на другой связанной машине, ORB связывается с использованием GIOP (наиболее часто встречается использование IIOP поверх TCP/IP). Следовательно, клиенту не обязательно "знать" что-либо относительно местоположения объекта, операционной системы хоста, или языка, на котором он был реализован для получения ссылки на него.

Объектные адаптеры, BOA и POA

Адаптер объекта CORBA необходим для подбора соответствия концепции реализации объектов на языке программирования к концепции объектов CORBA. Это - воссоединение принципа проектирования адаптера. Далее приводится то, за что ответственны объектные адаптеры:

Порождение и интерпретация объектных ссылок

  • Вызов метода
  • Активация и дезактивация объекта и реализации
  • Отображение ссылок объекта на соответствующую реализацию объекта
  • Регистрация реализации

Стандартные объектные адаптеры CORBA:

  • Основной объектный адаптер (BOA) - первый стандартный объектный адаптер CORBA
  • Портативный объектный адаптер (POA) - представлен в стандарте CORBA 2.1, заменяет BOA

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

Portable Object Adapter устраняет некоторые из недостатков BOA. Спецификации POA предназначены для предоставления разработчикам возможности написания мобильных и масштабируемых серверных приложений. При этом POA поддерживает широкий спектр возможностей, обеспечивающий тонкий контроль над ресурсами, требующимися для реализации объектов CORBA и направления к ним запросов. Это обеспечивает интерфейсы для управления жизненным циклом реализации объекта и его готовностью принять запросы, POA может быть пригоден для использования даже для серверов с экзотическими требованиями.

Терминология POA

POA содержит собственный набор концепций, которые расширяют и уточняют модель объекта CORBA. У нас есть объект CORBA, который является "виртуальным", абстрактным объектом, с возможностью обращения по его объектной ссылке и способностью к приему запросов. Кроме того, имеется сервант (servant), который является объектом языка программирования, существующим в пределах контекста процесса сервера и реализующим объект CORBA. Сервант придает физическую форму соответствующему объекту CORBA. Кроме того, POA поддерживает Объектный ID (идентификатор) - системный или определенный пользователем идентификатор, используемый для идентификации объекта в пределах его POA. И, наконец, скелет (skeleton)- объект языка программирования, который подключает сервант к POA, позволяя POA посылать запросы серванту.

Объект CORBA и жизненный цикл серванта

POA обеспечивает сильное разделение между сроками службы объектов CORBA и сроками службы серванта. Следующие термины относятся к циклу жизни объекта CORBA:

  • Активация (activation) - запуск существующего объекта CORBA, чтобы позволить ему принимать запросы.
  • Дезактивация (deactivation) - завершение работы активного объекта CORBA.

Следующие термины относятся к циклу жизни серванта:

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

Иерархия POA

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

Менеджеры POA Каждый POA имеет ассоциированного с ним менеджера POA, и менеджер POA управляет потоком запросов к его POA.

Менеджер POA может буферизовать запросы или отказываться от них. POA предоставляет очень богатый набор возможностей, обеспечивающих максимальную гибкость для разработки серверных приложений. Спецификации стандартизируют разработку сервера, позволяющую программистам создавать приложения, переносимые среди различных ORB-ов. Реализация Visibroker CORBA поддерживает все особенности POA.

Обзор IDL

Одной из ключевых спецификаций, которые обеспечивает CORBA, является Interface Definition Language (Язык определений интерфейсов) (IDL). IDL описывает объекты независимым от языка способом, так что к объектам непосредственно можно обращаться с помощью любого поддерживаемого языка, операционной системы или сети. Java и C++ - это языки программирования, которые позволяют разработчику осуществлять решения бизнес-проблем. Что касается IDL, то он является независимым от других языков, и позволяет программисту лишь определять интерфейсы объектам, но не реализацию этих объектов.

CORBA обеспечивает технологию распределенных объектов, которая дает возможность пользователям формировать интерактивные, масштабируемые приложения. Технические требования IDL CORBA отделяют интерфейс от его реализации, позволяя реализовать интерфейс на языке программирования, наиболее подходящем для специфических задач. Отображения IDL были созданы для C, C++, Ады, и Java, также как и для других языков. CORBA обеспечивает инфраструктуру, позволяющую различным реализациям объектов связываться друг с другом. Запросы объектов упаковываются в общий формат, который может быть распознан разными языками и операционными системами.

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

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

IDL не содержит никакой информации относительно того, как реализован объект. IDL только описывает интерфейс. Реализация объекта сервера может быть представлена на любом языке программирования, который поддерживает CORBA. Хочется отметить, что IDL прост в изучении. Он поддерживает синтаксическое подмножество C++ без процедурных конструкций типа циклов for и while. Поскольку IDL только описывает интерфейс к объекту (например: метод вызова и параметры), это лишний раз демонстрирует, что он является простым языком для изучения. Тех, кому не нравится идея изучения еще одного языка, можно обрадовать - VisiBroker предлагает законченное решение Java, где интерфейс определен в интерфейсе Java, и компилятор реконструирует IDL и необходимые файлы, исходя из файла интерфейса Java. Эта функция также дает возможность структурам классов Java, таким как Vector, использоваться в качестве параметров вызова.

IDL представляет собой по существу самостоятельный язык, хотя его конструкции похожи на C++ и Java. Несколько ресурсов доступно на web-сайте OMG (www.omg.org), который предоставляет информацию относительно начала работы с IDL.

CORBA обеспечивает прозрачность местоположения. Клиентам нет необходимости знать местоположение реализации объекта. Таким образом, обеспечивается гибкость для совмещения объектов на той же самой машине, дистанционно, или возможность непрерывного перемещения для объекта, находящегося в динамической среде. Клиент может использовать Службу именования CORBA (CORBA Naming Service), чтобы найти объекты сервера. Фактическое местоположение объекта сервера прозрачно для клиента. Кроме того, VisiBroker имеет удобный "out-of-the box" Smart Agent, который работает как Directory Service (Служба каталогов) при быстром поиске и определении местоположения объектов.

CORBA IIOP

Протокол Internet CORBA Inter-ORB (IIOP) обеспечивает ORB - ам независимость от поставщиков. ORB-ы могут взаимодействовать по спецификациям IIOP. То есть IIOP гарантирует, что объекты CORBA, реализованные с использованием ORB-ов одного продавца, будут способны общаться с объектами CORBA, реализованными на любых других ORB-ах.

Архитектура управления объектами (OMA) описывает основной набор спецификаций, называемых CORBAservices, которые могут быть включены в сложные программные системы. Эти сервисы позволяют объектам приложения связываться стандартными способами. Поставщики реализовали "CORBAservices", что облегчает разработку больших распределенных систем.

С другой стороны - если разработчик планирует писать приложения, используя Enterprise Java Beans, преимущества IIOP из-за поддержки для RMI/IIOP декларирует способность к взаимодействию среди множественных языков и среди контейнеров от множественных поставщиков. Контейнер EJB Inprise основан на CORBA. Inprise Application Server предполагает CORBA-совместимость как с RMI-поверх-IIOP, так и отображение Java-на-IDL.

Создание сервера CORBA с помощью JBuilder

Определение объекта

Учитывая эти два компонента, определение объекта как IDL и ORB как канала связи между этими объектами, мы можем начать исследование разработки приложения CORBA с помощью JBuilder. Подобно любому программному проекту, первоначальными задачами, стоящими перед реализацией нашего приложения, будут оценка и дизайн. Так как CORBA - это объектно-ориентированный стандарт, мы должны разбить наш бизнес-процесс на логические объекты, их свойства и на операции, которые мы будем должны выполнить на этих объектах и с этими объектами. Для осуществления этих задач, мы будем использовать простой сервер Attendees, который сможет извлечь предполагаемую посещаемость конференции Borland/Inprise.

Для начала мы сохраним функциональные возможности простыми, путем определения только одного интерфейса, который мы назовем Attendees. IDL. Интерфейс описывает, какие функциональные возможности наш объект предлагает клиентам. Ранее уже упоминалось, что мы могли бы использовать Caffeine для определения наших интерфейсов на Java, но мы хотим продемонстрировать это на IDL.

CORBA-разработка в JBuilder

В вычислительном мире Java быстро утвердился в качестве стандартной платформы для создания Internet и Intranet апплетов и приложений. Одна из основных причин успеха Java - близкая к совершенству мобильность платформы. Программы, написанные на Java, могут работать в разнообразных операционных системах и аппаратных конфигурациях. Объедините эти характеристики с простотой использования Java, поддержкой обработки исключений, поддержкой потоков и сборкой мусора, и вы получите язык, который является идеальной средой для разработки сетевых вычислений, особенно программирования для Internet.

  • Java - объектно-ориентированный
  • Java - дружественный
  • Java предлагает исключения, поддержку потоков и сборку мусора
  • Java прекрасно отображается на IDL

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

В настоящее время проектировщики систем на CORBA способны поставить распределенные программные системы, описанные на IDL и реализованные на Java, с использованием современных браузеров и Web-технологии.

До появления Java и CORBA удаленным пользователям явно не хватало свободного доступа к информации мэйнфрейма. Связь с мэйнфреймом является трудным делом. Приходится беспокоиться относительно новых изданий платформ, коммуникационных протоколов и языков.

Для развертывания тонкого клиента вы могли использовать стандарт HTML на клиенте и сервлеты Java (которые вдвое больше клиентов CORBA) на web-сервере. В трехзвенной архитектуре, прикладная программа разбита между клиентом, сервером и средним звеном. Среднее звено позволяет упростить как клиента, так и сервер, и делает более простым развертывание по сравнению с двухзвенной системой, в которой клиент и сервер связаны непосредственно.

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

Теперь, когда мы определили, что такое CORBA и как она реализована, перейдем к фактическому написанию приложения. Самые современные языки программирования поддерживают разработку CORBA, включая C++, Java и Object Pascal Delphi. В результате, основные инструментальные средства RAD поддерживают в различной степени стандарт OMG. JBuilder был одним из первых инструментальных средств, предназначенный для тесной интеграции в IDE средств разработки CORBA, а JBuilder3.5 добавил несколько новых возможностей для создания серверов VisiBroker, клиентов и других сервисов CORBA. Мы будем изучать разработку, используя Java с JBuilder.

Разработка приложений архитектуры CORBA в среде Jbuilder

Первоначально наш сервер Attendees будет состоять из единственного объекта, ConferenceManager, который будет информировать о запросах вероятной посещаемости конференции. Мы хотим иметь возможность запрашивать AttendeesManager об ожидаемом числе посетителей в этом году.

В IDL мы определяем это следующим образом: // Attendees.idl module bicon2000 { interface Attendees { long number(in long lastYear); }; };

Мы определили модуль, называемый bicon2000 (сокращение от Borland/Inprise Conference 2000). Модуль отображается на пакет Java, и является просто пространством имен, в котором расположен интерфейс. В пределах модуля bicon2000 мы определяем единственный интерфейс по имени Attendees. Подобно интерфейсам Java, этот интерфейс, по сути, является контрактом между клиентом и сервером, обозначающим, какие методы объект Attendees выставляет для использования. Мы можем здесь видеть, насколько IDL схож с C++ и Java в своем синтаксисе. Типы данных также подобны; мы возвращаем long (long integer) для числа наших посетителей, и в качестве входного параметра берем значение, что это было в прошлом году. Аргумент "last year" идентифицируется как in, так как объект сервера (определяемый в этом случае как out) не будет изменять это значение. Интерфейс Attendees выставляет только один метод "number", подразумевая под этим, что объект Java, который мы используем для реализации Attendees, должен будет только поддержать этот единственный метод. Чтобы создать этот файл IDL, выберите File, New … из Top Menu. Выберите закладку Enterprise из диалога Objects Gallery. И затем выберите Sample IDL.

Определение закончено; все, что необходимо сделать - это "скомпилировать" стандартные конструкции в определенный язык, в нашем случае, классы Java. Компиляция файла IDL производит интерфейсы Java, клиентские стабы и скелеты сервера, которые реализованы для осуществления обмена информацией друг с другом. Эти классы обрабатывают упаковку/распаковку данных, известную как маршаллинг (marshalling), из типов данных Java на клиенте в типы данных CORBA, и затем обратно в типы данных Java на сервере. Эти классы стабов и скелетов также обрабатывают передачу сообщений IIOP, которая происходит между ними.

Щелкните правой клавишей по значку Attendees.idl и выберите Make из появляющегося всплывающего меню, которое сгенерирует необходимые классы.

Чтобы генерировать сервер CORBA, который осуществит метод "number", выберите File, New… в меню панели инструментов. Выберите закладку Enterprise на Objects Gallery, и затем выберите CORBA Server Application. При использовании только что созданного файла IDL, будут созданы оставшиеся файлы сервера. Кроме того, будет создан GUI, который может хостировать сервер.

Созданные файлы:

Attendees .java: Просто интерфейс Java, который соответствует нашему интерфейсу IDL. Объект Java, который обеспечивает реализацию для нашего объекта Attendees, реализует этот интерфейс.

AttendeesHelper.java: абстрактный класс, используемый клиентом для привязки к объекту Server и обеспечивающий множество сервисных методов для получения ID Attendees, получения (narrowing) CORBAServices, извлеченных из ЛЮБЫХ типов, и т.д. AttendeesHolder.java: Использованный Helper-ом, этот класс является классом поддержки, который обеспечивает способность передачи объекта Attendees как параметра CORBA.

AttendeesOperations.java: класс интерфейса, используемый в качестве альтернативы для привязки скелета через делегатов. Также помогает преодолеть ограничение классов Java, которое выражается в неспособности наследования от множественных интерфейсов.

AttendeesPOA.java: Класс POA Java, от которого будет реализован фактический Object.

AttendeesPOATie.java: Это - делегированная реализация для интерфейса. Каждый экземпляр класса tie должен быть инициализирован экземпляром класса реализации, который реализует класс Operation, к которому он делегируется при каждой операции.

AttendeesStub.java: Используется Helper-ом для делегирования вызовов метода для удаленного объекта, это - код стаба для использования на стороне клиента.

На стороне сервера:

Bicon2000ServerApp.java: Серверное приложение, которое загрузит ServerFrame и выполнит AttendeesImpl (реализацию).

AttendeesImpl .java: Фактическая реализация. Это - класс Java, который мы изменим на реализацию результата обращения к методу "number". В этом методе мы возвращаем (int) (1.2 * lastYear).

ServerFrame .java: Класс Frame (GUI).

ServerMonitor.java: Поддерживает лог-файл сервера и является контейнером для всех страниц Server Monitor.

ServerMonitorPage.java: Реализует страницу Server Monitor для отображения счетчиков интерфейса.

ServerResources.java: Содержит строки серверного приложения для локализации.

Чтобы сгенерировать клиента, который может вызывать метод number, выберите File, New … из меню Top. Выберите закладку Enterprise из Objects Gallery. При использовании IDL, это приведет к генерации класса ClientImpl. Чтобы быстро проверить клиента, создайте метод main в этом классе.

public static void main (String args) throws Exception { System.out.println(new AttendeesClientImpl().number(10000)); }

Выполнение приложения(-ний)

Для выполнения приложения(-ний), сначала запустите SmartAgent. Выберите Tools из меню Toolbar и выберите VisiBroker Smart Agent. Если меню проверено, вы уже имеете запущенный Smart Agent. Щелкните правой клавишей мыши по bicon2000ServerApp.java и выберите Run из всплывающего меню. Чтобы запустить клиента, выберите AttendeesClientImpl и выберите Run из всплывающего меню. В качестве результата должно возвратиться 12000.

У вас теперь есть настоящее действующее приложение CORBA. JBuilder не только сокращает монотонную работу разработки приложения в командной строке EMACS, он также позволяет генерировать быстрые прототипы и подтверждения работоспособности концепции вашей программы фактически в пределах нескольких минут.

Smart Agent

Для полного понимания кода, сгенерированного Jbuilder, мы должны изучить некоторые новые детали реализации VisiBroker CORBA. Первый новый пункт для обсуждения - это Smart Agent, иногда называемый по имени выполняемого файла OSAGENT. Smart Agent - платформо-зависимый запускаемый процесс, который предоставляет сервисы каталогов для клиентов и реализаций CORBA. Иногда он сравнивается с информационным оператором, с клиентскими запросами, сравниваемыми с телефонным звонком в информационную службу, где клиент запрашивает другого человека по имени, и оператор соединяет эти две стороны. Когда клиент пытается соединиться с конкретным объектом, Smart Agent определяет расположение экземпляра этого объекта и возвращает ссылку клиенту. С другой стороны этой модели, когда реализации объекта станут доступными, они регистрируют себя с помощью Smart Agent, так что клиенты могут находить их. Аналогично, когда реализация завершает работу, она разрегистрирует себя с помощью Smart Agent. Если по какой-либо причине реализация объекта завершается без разрегистрации посредством Smart Agent, агент, в конечном счете, обнаружит это посредством ping"а и разрегистрирует реализацию самостоятельно. Smart Agent - один из ключевых процессов в модели VisiBroker CORBA в абстрагировании местоположения объекта, он просто отыскивает объект, когда приходит запрос. Клиенту нет необходимости знать, находится ли объект в пределах того же самого компьютера, или в глобальном масштабе, и запущен ли он в другой операционной системе.

Server Side Object Implementation public class AttendeesImpl extends bicon2000.bicon2000.AttendeesPOA { String name = "Attendees"; … … public int number(int lastYear) { ServerMonitor.log("(" + name + ") AttendeesImpl.java number()"); return (int)(1.2 * lastYear); } } Server Side Code // SmartAgent слушает порт UDP 14000. //Это часто называется биением сердца smartagent-а. System.getProperties().put("ORBagentPort", "14000"); // Инициализация ORB org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init (args, System.getProperties()); // Получение RootPOA; вместо инициализации BOA, //мы получаем ссылку на //корневой POA POA poaRoot = POAHelper.narrow (orb.resolve_initial_references("RootPOA")); // Установка строковой константы, которая будет регистрировать этот // объект name = "Attendees"; // Установка политики (цикла жизни - lifespan) в Persistent org.omg.CORBA.Policy AttendeesPolicies = { poaRoot.create_lifespan_policy(LifespanPolicyValue.PERSISTENT) }; // В BOA, объект становится персистентным (хранимым), если получает //имя. Некоторые BOA могут поддерживать как кратковременные, так и //хранимые объекты. Однако одиночный POA может поддерживать лишь либо //хранимые, либо кратковременные объекты. Корневой poa, полученный //нами выше, поддерживает лишь кратковременные объекты. Однако нам //необходим именно хранимый объект. Следовательно, мы создадим другой //POA с политикой жизненного цикла "persistence" (хранимый). POA poaAttendees = poaRoot.create_POA(name + "_poa", poaRoot.the_POAManager(), AttendeesPolicies); // В BOA, сервант является объектом CORBA. Но в POA, сервант и объект // CORBA различаются. Вместо создания объекта CORBA и установки // obj_is_ready для активации этого объекта, мы теперь создадим //сервант и активируем его в POA с помощью ID. Оператор new //AttendeesImpl()) является реализацией серванта и активизирует //этот сервант с помощью ID в myPOA poaAttendees.activate_object_with_id (name.getBytes(), new AttendeesImpl()); // Активируем менеджера POA poaRoot.the_POAManager().activate(); // Подождем до прибытия запросов orb.run(); Client Side Code public class AttendeesClientImpl { boolean bInitialized = false; bicon2000.bicon2000.Attendees _attendees; com.borland.cx.OrbConnect orbConnect1; String name = "Attendees"; public AttendeesClientImpl() { try { jbInit();} catch (Exception ex) { ex.printStackTrace(); } } private void jbInit() throws Exception { } public boolean init() { if (!bInitialized) { try { org.omg.CORBA.ORB orb = null; if (orbConnect1 != null) { orb = orbConnect1.initOrb(); } if (orb == null) { // Initialize the ORB orb = org.omg.CORBA.ORB.init((String)null, System.getProperties()); } // Get the Server Object _attendees = bicon2000.bicon2000.AttendeesHelper.bind(orb, "/" + name + "_poa", name.getBytes()); bInitialized = true; } catch (Exception ex) { ex.printStackTrace(); } } return bInitialized; } public int number(int lastYear) { init(); return _attendees.number(lastYear); } public static void main (String args) throws Exception { System.out.println(new AttendeesClientImpl().number(10000)); } }

Расширение нашего примера

Написанное нами приложение Attendees было слишком упрощенным примером того, как может выглядеть фактическая Attendance System (Система посещаемости). Чтобы далее оценить IDL и преимущество CORBA, мы снова ненадолго вернемся к нашему проекту Attendees. В нашем упражнении информация о посетителях была возвращена посредством вызова простого метода для объекта Attendees. Нам может потребоваться добавление процентных изменений, процентов за день, бронирования гостиницы и обработки исключений, отслеживающих недоступность данного метода для вызова. Наш IDL тогда выглядел бы примерно так:

/** * Attendees.idl * Пример IDL для конференции Borland/Inprise * */ module bicon2000 { /** * Интерфейс Person определяет персону */ interface Person { string getName(); }; /** * Интерфейс Attendees определяет объект конференции * Attendees. Эта конференция является трехдневной. */ interface Attendees { enum ConferenceDays { DAY1, DAY2, DAY3 }; exception RoomNotAvailable {}; long number(in long lastYear); float percentIncrease(); float percentIncreaseOnDay(in ConferenceDays whichDay); boolean bookHotelRoom(in Person attendee) raises (RoomNotAvailable); }; };

Заметим, что этот модуль имеет более одного интерфейса. Два скелета и proxy - это коды для двух объектов, которые будут генерироваться при запуске IDL2JAVA. Важно понять, что IDL является очень богатым языком, который может полностью описать дизайн нашего объекта и, при компиляции, у нас в конечном счете остается только реализация объектов Java, как и при использовании любых классов Java. Это свидетельствует о том, что дизайн приложений CORBA не налагает ограничений и не делает никаких предположений относительно возможной реализации.

Дополнительные сервисы VisiBroker

В нашем примере мы затронули многие из основных средств, предоставляемых VisiBroker в частности, и в целом архитектурой CORBA. Существует, однако, несколько дополнительных сервисов и процессов, не используемых в этом примере, которые часто необходимы в крупномасштабных разработках CORBA. Приведем некоторые из этих компонентов:

Консоль (console) - Inprise VisiBroker Console является инструментом, который позволяет вам просматривать и управлять сервисами VisiBroker ORB с использованием графического интерфейса. В частности вы можете использовать браузеры сервисов ORB, чтобы управлять объектными серверами, управлять конфигурацией гейткиперов (gatekeepers), просматривать репозитарий интерфейсов, редактировать контексты именования, искать экземпляры объектов и просматривать OAD-ы в вашей сети. Дизайн VisiBroker Console подобен графическим интерфейсам консолей в Inprise Application Server и Inprise AppCenter.

SmartAgent - Smart Agent VisiBroker (osagent) динамическая, распределенная служба каталогов, которая обеспечивает средства, используемые как клиентскими программами, так и реализациями объектов. Smart Agent должен быть запущен по крайней мере на одном хосте в пределах вашей локальной сети. Когда ваша клиентская программа вызывает bind() для объекта, Smart Agent автоматически консультирует. Smart Agent определяет местонахождение указанной реализации так, чтобы могло быть установлено соединение между клиентом и реализацией. Связь со Smart Agent полностью прозрачна для клиентской программы. Если для POA установлена политика PERSISTENT и используется activate_with_id, Smart Agent регистрирует объект или реализацию так, чтобы клиентская программа могла их использовать. Когда объект или реализация дезактивированы, Smart Agent удаляет их из списка доступных объектов. Как и в случае с клиентскими программами, связь с Smart Agent полностью прозрачна для реализации объекта.

OsFind - Если мы хотим удостовериться, что Smart Agent осведомлен об объекте, мы можем убедиться в этом, запустив платформо-зависимую утилиту VisiBroker, называемую osfind. Когда мы выполняем osfind, мы видим, что наш объект зарегистрирован Smart Agent и доступен для клиентских запросов. SmartAgent, выполняющийся в среде Windows, предоставляет консоль для просмотра зарегистрированных объектов. Кроме того, вы можете визуально просматривать лог-файл и привязки. OSFIND также сообщает информацию относительно Object Activation Demon, специального процесса VisiBroker, который может активизировать серверы в качестве поставщика объектов по мере того, как они будут затребованы клиентами.

Отладчик

RMI-over-IIOP - RMI (remote methods invocation - вызов удаленных методов) - механизм Java, который позволяет создавать и использовать объекты в распределенной среде. В этом смысле, RMI представляет собой ORB, который является языково-специфическим (Java) и не-CORBA совместимым. OMG выпустила спецификацию отображения языка Java на IDL, которая позволяет классам Java, написанным с использованием RMI, взаимодействовать с объектами CORBA путем использования кодирования IIOP. VisiBroker имеет два компилятора, которые позволяют адаптировать ваши существующие классы Java для работы с другими объектами, использующими VisiBroker ORB. Компилятор java2iiop позволяет адаптировать ваши RMI -совместимые классы для использования IIOP, генерируя соответствующий полный скелет, стаб и классы Helper-а. Компилятор java2idl генерирует IDL исходя из ваших классов Java, позволяя вам реализовывать их на языках, отличных от Java.

Репозиторий интерфейсов (Interface Repository) - необязательная служба, которая может предоставлять подробности относительно конкретного интерфейса по требованию клиентов. Таким образом, клиенты могут опрашивать репозиторий интерфейсов, чтобы изучить, какие методы предлагаются интерфейсом, и в свою очередь, вызвать их. Репозиторий интерфейсов может также использоваться для сохранения дополнительной информации относительно интерфейса, типа информации о его активации.

OAD - Ранее кратко упоминавшийся OAD или Object Activation Demon (Демон активации запросов) может использоваться для активизации серверных процессов либо по требованию, как объектов клиентских запросов внутри них, либо вызовом методов для них. OAD использует отображения, сохраненные в репозитории интерфейсов, для определения того, какие серверы обеспечивают какие интерфейсы.

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

Перехватчики/обработчики событий/триггеры (Interceptors/Event Handlers/Triggers) - Эти сервисы могут быть написаны для осуществления более полного контроля над привязкой и повторной привязкой, обработки отказов и обеспечения сервисов более низкого уровня, таких как балансирование загрузки или шифрование.

Гейткипер (Gatekeeper) - Гейткипер позволяет клиентам VisiBroker связаться с серверами, находящимися в разных сетях, при одновременном согласовании ограничений защиты, наложенных web-броузерами и защитными фильтрами (firewalls). Gatekeeper выполняет функции шлюза между клиентами и сервером, когда ограничения защиты, наложенные Java sandbox security или сетевыми фильтрами, не допускают для клиентов непосредственной связи с серверами. Gatekeeper - это GIOP прокси-сервер, полностью совместимый со спецификациями OMG CORBA Firewall. Кроме того, Gatekeeper обеспечивает следующие функциональные возможности: начальная загрузка, прозрачность местоположения, предоставление возможности обратного вызова, туннелирование HTTP, функционирование в качестве простого web -сервера для загрузки классов, настраиваемых средствах управления доступом, основанных на IP, балансирование загрузки, отказоустойчивость.

Интерфейс динамических вызовов (Dynamic Invocation Interface) - Этот интерфейс позволяет клиентам CORBA вызывать методы выполнения по имени и обнаруживать эти методы во время выполнения посредством обращения в репозитарий интерфейсов. DII позволяет формировать клиентов без использования файлов стабов, сформированных из кода IDL.

Интерфейс динамических скелетов (Dynamic Skeleton Interface) - Подобно DII, DSI позволяет реализации объектов быть сформированной без расширения скелетных классов. Может оказаться полезным предоставить возможность объекту реализовывать несколько интерфейсов.

Привязка связывания (Tie Binding) - Обеспечивает создание реализаций объектов CORBA, исходя из классов, которые не наследуются от org.omg.CORBA.Object. Делегирование объекта, известное как объект привязки, позволяет серверу использовать прямые вызовы истинной реализации объекта. Это особенно полезно при создании объектов CORBA, исходя из существующих классов, так как Java не поддерживает множественное наследование.

Smart Stubs - Стабы, которые вмешиваются во все вызовы метода, предоставляя хорошие обработчики прерываний для добавления кода, предназначенного для защиты, кэширования и балансирования загрузки.

Заключение

Мы обсудили главные концепции VisiBroker CORBA и реализовали простой пример его использования. Хотя с уверенностью можно сказать, что реальные приложения значительно сложнее, этот пример представляет многие из всеобъемлющих концепций архитектуры CORBA. Ясно, что CORBA является согласительным стандартом для промышленности, которая значительно изменила представление о том, как может быть выполнена разработка информационных систем посредством осуществления систем распределенных объектов и перехода от наследуемых систем на уровень современных архитектур. Прочитав эту статью, разработчики и архитекторы смогут четко уяснить основную архитектуру CORBA и мотивации ее использования, а также приобрести практические знания относительно того, как максимально использовать преимущества VisiBroker в будущих приложениях, разработанных в среде JBuilder.

Технология CORBA (Common Object Request Broker Architecture)

Технология CORBA (разработка консорциума OMG - Object Management Group) предназначена для разработки и эксплуатации распределенных приложений и поддерживается большинством известных аппаратных и операционных платформ. В консорциум входит более 800 компаний, поэтому в совместной разработке нет ярко выраженного предпочтения одной какой-либо операционной или аппаратной платформе. Главной идеей технологии CORBA является разработка стандартизованных спецификаций, на основе которых каждая фирма, входящая в консорциум, развивает свои собственные реализации. После инсталляции клиентской и серверной частей программного обеспечения CORBA клиенты могут взаимодействовать с сервером с помощью специальных компонентов CORBA. Объект CORBA взаимодействует с другим объектом (или объектами) CORBA через интерфейсы. Для организации взаимодействия между объектами CORBA используется брокер запросов ORB (Object Request Broker) и сетевой агент (Smart Agent). За счет использования этих механизмов также обеспечивается взаимодействие приложений клиентов, работающих под разными операционными платформами.

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

В клиентской части приложения размещаются следующие объекты:

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

Объект CORBA

Объект CORBA, в отличие от объекта СОМ, имеет единственный интерфейс. Но этот интерфейс имеет возможность наследовать методы от многочисленных предков (множественное наследование). Такая реализация объекта CORBA вызвана тем, что многочисленные фирмы, составляющие консорциум OMG, имеют возможность создавать уникальные объекты CORBA, ориентированные на работу в конкретной аппаратной и программной средах, но строго соблюдая общие спецификации (стандарты).

Интерфейс объекта CORBA создается на языке описания интерфейсов Interface Definition Language (версия IDL CORBA).

В технологии CORBA внедрен базовый объект Object. Так как каждый объект CORBA имеет единственный интерфейс, то и тип объекта определяется типом интерфейса. Поэтому объект CORBA поддерживает свой собственный интерфейс и все наследуемые интерфейсы.

Службы CORBA и их взаимодействие

Экземпляр брокера запросов ORB должен быть установлен в каждом клиентском приложении. Клиентское приложение обращается к экземпляру объекта CORBA через соответствующие механизмы брокера запросов (рис. 2.5). Получив запрос, брокер запросов просматривает сетевое окружение и находит свободный работающий сетевой агент (Smart Agent). Затем устанавливается сеанс связи с найденным сетевым агентом. Сетевая служба, которой принадлежит Smart Agent , организует сеанс связи с базой данных (служба Implementation Repository) и среди зарегистрированных серверов CORBA находит свободный. Сетевой агент передает запрос пользователя найденному серверу CORBA через соответствующий брокер. После исполнения запроса полученный ответ (в обратном направлении) передается пользователю.

Различные брокеры взаимодействуют между собой по протоколу General Inter ORB Protocol (GIOP).

Рис. 2.5. Взаимодействие сервера CORBA с клиентами

Основные службы CORBA:

  • events - событий;
  • naming - именования;
  • query - запросов;
  • transactions - транзакций;
  • property - свойств;
  • relationsips - отношений;
  • security - защиты;
  • life cycle - жизненного цикла;
  • time - времени;
  • object collections - сбора объектов.

Вывод. Для обеспечения взаимодействия технологии CORBA со средой Delphi в последней имеется специальная библиотека orbpas50.dll Среда Delphi имеет специальную вкладку CORBA , на которой размещены различные компоненты CORBA. В зависимости от установленной на персональный компьютер реализации (отрасли) вкладка CORBA будет содержать как компоненты конкретной отрасли, так и общие (стандартизованные) компоненты.

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

  • 1. Расскажите об истории создания технологии СОЛ1.
  • 2. Что такое объект СОМ?
  • 3. Что такое интерфейс объекта СОМ?
  • 4. Назовите типы интерфейсов СОМ.
  • 5. Объясните процедуру создания объекта СОМ.
  • 6. Расскажите о работе пользователя с объектом СОМ.
  • 7. Объясните назначение библиотеки СОМ.
  • 8. Что такое фабрика класса?
  • 9. Укажите основные характеристики технологии MTS.
  • 10. Расскажите о технологии ADO.
  • 11. Расскажите о назначении и принципиальных отличиях технологии MIDAS.
  • 12. Расскажите об истории создания технологии CORBA.
  • 13. Что такое объект CORBA1
  • 14. Расскажите о приемах работы в технологии CORBA.
  • 15. Расскажите о службах технологии CORBA.

CORBA (Common Object Request Broker Architecture) - объектно-ориентированная технология создания распределенных приложений. Технология основана на использовании брокера объектных запросов (Object Request Broker, ORB) для прозрачной отправки и получения объектами запросов в распределенном окружении. Технология позволяет строить приложения из распределенных объектов, реализованных на различных языках программирования. Стандарт CORBA разработан Object Management Group (OMG) .

Архитектура CORBA

В данном разделе приводится краткий обзор CORBA в том виде, как ее описание дается в спецификации OMG версии 3.0. Требования этого документа могут в различной степени удовлетворяться фактическими реализациями брокеров объектных запросов . На Рис. 2.1 изображен запрос, посылаемый клиентом реализации объекта. Клиент - это сущность, которая хочет выполнить операцию с объектом, а Реализация - это совокупность кода и данных, которые в действительности реализуют объект.

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

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

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

Информация о реализации объекта предоставляется во время инсталляции и хранится в репозитории реализации, а затем используется в процессе доставки запроса.

CORBA-cервисы, представляют собой набор служб системного уровня, упакованных вместе с интерфейсами IDL. Их можно рассматривать как расширение функциональности ORB. Они используются для создания компонент, их именования и внедрения в среду.

Сервис именования (Naming service) служит для управления ссылками на CORBA-объекты и их хранения. Его осн.зад. - универсальным образом организовать соединение объектов друг с другом. Сервис имен оперирует с хранилищем объектных ссылок. Обращение к этому сервису выполняется для получения нужной объектной ссылки, идентифицируемой по читабельному имени объекта.

Сервис событий (Event service) обеспечивает поддержку асинхронного взаимодействия приложений.

Сервис хранения объектов (Persistence service) предоставляет набор универсальных интерфейсов для сохранения экземпляров объектов в долговременной памяти. Сервис разработан таким образом, что возможна его реализация на основе объектной базы данных.

Сервис управления транзакциями (Transaction service) поддерживает множество моделей транзакций, включая вложенные транзакции. Сервис транзакций необходим для корректной работы приложений в многопользовательском режиме.

Сервис взаимодействия (Relationship service) реализует логические связи между CORBA-объектами. Сервис определяет два дополнительных типа объектов: связь и роль. Роль представляет собой CORBA-объект, отражающий характер связи, а связь характеризует зависимости объектов прикладной области.

Сервис управления разделяемыми ресурсами (Concurrency control) service позволяет клиентам координировать свои действия при исп-нии разделяемых ресурсов. Управление разделяемыми ресурсами осущ-ся с пом. блокировок. Каждая блокировка ассоциируется с единственным ресурсом и единственным клиентом. Сервис определяет также несколько режимов блокировок, которые соответствуют различным способам доступа.

Сервис внешнего представления (Externalization service) формирует копию CORBA-объекта в виде некоторого внешнего представления - файла, элемента базы данных и т.д.

В адресном пространстве клиента функционирует специальный объект, называемый заглушкой (stub). Поучив запрос от клиента, он упаковывает параметры запроса в специальный формат и передает его серверу, а точнее скелету.Скелет (skeleton) - объект, работающий в адресном пространстве сервера. Получив запрос от клиента, он распаковывает его и передает серверу. Также скелет преобразует ответы сервера и передает их клиенту (заглушке).Создание CORBA приложения на Java начинается с написания интерфейса для удаленного объекта, используя язык описания интерфейсов (Interface Definition Language, IDL). Создадим файл test.idl

module testApp {

{ long count(in string msg); };

Серверная часть приложения.

Первое что мы делаем, создаем ORB. Затем создаем экземпляр класса удаленного объекта (testServant) и регистрируем его в ORB. Дальше вызываем специальную службу имен (NameService) и регистрируем в ней имя удаленного объекта, чтобы клиент смог его найти.После того как сервер обработает запрос от клиента и выполнит метод count он снова перейдет в состояние ожидания.

ORB orb = ORB.init(args, null);

testServant testRef = new testServant();

orb.connect(testRef);

org.omg.CORBA.Object objRef =orb.resolve_initial_references("NameService");

NamingContext ncRef = NamingContextHelper.narrow(objRef);

Код клиента. Основные шаги написания клиентского приложения: Создание и инициализация ORB Получение контекста службы имен Нахождение удаленного объекта Вызов метода count.

Третий пункт. Создается объект NameComponent. Вызывается метод resolve(NameComponent path), который отыскивает по имени удаленный объект (стандартный CORBA-объект). При помощи метода narrow(org.omg.CORBA.Object obj) класса testHelper (сгенерированного idltojava компилятором) получаем объектную ссылку на интерфейс test.

NameComponent nc = new NameComponent("test", "");

NameComponent path = {nc};

org.omg.CORBA.Object obj= ncRef.resolve(path);

test testRef=testHelper.narrow(obj);Теперь можно вызывать метод count

String msg = "try to count";

int count = testRef.count(msg);

24. ORB: понятие, назначение, основные функции. Принципы организации запросов в ORB. Использование стандарта IIOP.

Брокер объектных запросов - это объектная шина. Задачей брокера явл. предоставление механизма выполнения запроса объекта-клиента: поиск объекта, к кот. относится данный запрос, передача необх. данных, подготовка объекта к обработке. Брокер объектных запросов обеспечивает прозрачное взаимодействие клиентского и серверного приложений. Для разработчика вызов методов удаленных объектов не отличается от обычных локальных вызовов. ORB управляет взаимодействием объектов в распределенной сетевой среде. IIOP

IIOP (Internet Inter-ORB Protocol) - это специальный протокол взаимодействия между ORB.

IIOP определяет обмен сообщениями через TCP/IP-соединения. В посл.время протоколу IIOP уделяется все больше внимания со стороны крупнейших производителей ПО. IIOP становится признанным стандартом для вызова удаленных объектов в Интернет.

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

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


Похожая информация.


Александр Годин

Технология CORBA - это стандарт написания распределенных приложений, предложенный консорциумом OMG (Open Management Group). Создавая CORBA-объекты, мы можем,например, существенно уменьшить время решения задач, требующих выполнения большого объема вычислений. Это возможно благодаря размещению CORBA-объектов на разных машинах. Каждый удаленный объект решает определенную подзадачу, тем самым разгружает клиент от выполнения лишней работы.

Рассмотрим взаимодействие объектов в архитектуре CORBA

Рис.1 Взаимодействие объектов в архитектуре CORBA

Основу CORBA составляет объектный брокер запросов (Object Request Broker). ORB управляет взаимодействием объектов в распределенной сетевой среде. IIOP (Internet Inter-ORB Protocol) - это специальный протокол взаимодействия между ORB.

В адресном пространстве клиента функционирует специальный объект, называемый заглушкой (stub). Поучив запрос от клиента, он упаковывает параметры запроса в специальный формат и передает его серверу, а точнее скелету.

Скелет (skeleton) - объект, работающий в адресном пространстве сервера. Получив запрос от клиента, он распаковывает его и передает серверу. Также скелет преобразует ответы сервера и передает их клиенту (заглушке).

Для того, чтобы написать любое приложение CORBA используя технологию Java, необходимо иметь две вещи - это установленный пакет JDK1.2 и компилятор idltojava . JDK предоставляет набор классов для работы с CORBA объектами, а idltojava производит отображение языка IDL в Java.

Создание CORBA приложения на Java начинается с написания интерфейса для удаленного объекта, используя язык описания интерфейсов (Interface Definition Language, IDL).

Создадим файл test.idl module testApp { interface test { long count(in string msg); }; };

Данный интерфейс описывает лишь один метод count . Причем, нам не важно, что делает этот метод, главное мы определяем, что он есть, определяем какие у него входные и выходные параметры.

Воспользуемся компилятором idltojava.

Idltojava Hello.idl Примечание. Данный компилятор по умолчанию использует препроцессор языка С++, поэтому что бы не мучится с сообщением об ошибке имя команды или файла указано неправильно (в переменной окружения CPP должен быть прописан путь к нему) отключим его использование, установив флаги. idltojava -fno-cpp Hello.idl Результат работы данной программы можно представить в виде схемы.

Рис.2 Работа idltojava компилятора
В текущей директории появилась новая папка testApp , в которой содержатся пять java - файлов. Каждый из них имеет свое назначение.

_testImplBase.java - абстрактный класс, который представляет собой не что иное, как скелет сервера (skeleton) и обеспечивает функциональность сервера;

_testStub.java - класс, реализующий заглушку (stub) клиента. Обеспечивает функциональность клиента;

test.java - класс, содержащий описание интерфейса test на языке Java;

testHelper.java и testHolder.java - классы, предоставляющие вспомогательные функции для CORBA объектов.

Теперь наша задача - написать класс, реализующий интерфейс test . Такие классы должны называться так, чтобы в их имени было слово "Servant", в нашем случае это будет testServant .

Class testServant extends _testImplBase { public int count(String msg) { return msg.length(); } }

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

Теперь перейдем непосредственно к написанию серверной части приложения.

Первое что мы делаем, создаем ORB. Затем создаем экземпляр класса удаленного объекта (testServant) и регистрируем его в ORB. Дальше вызываем специальную службу имен (NameService) и регистрируем в ней имя удаленного объекта, чтобы клиент смог его найти (есть и другой способ нахождения удаленного объекта, но о нем чуть позже).

Рассмотрим подробнее эти этапы.

  1. Создание и инициализация ORB. Производится вызовом статического метода init класса ORB

    ORB orb = ORB.init();

  2. Создание экземпляра класса удаленного объекта и регистрация его в ORB

    testServant testRef = new testServant();

    orb.connect(testRef);

  3. Получение контекста имен (NamingContext)

    org.omg.CORBA.Object objRef =

    orb.resolve_initial_references("NameService");

    NamingContext ncRef = NamingContextHelper.narrow(objRef);

    в первой строчке мы получаем объектую ссылку на службу имен (NameService). Но фактически это обыкновенный CORBA-объект и для того, чтобы использовать его как контекст имен (NamingContext), необходимо вызвать метод narrow класса NamingContextHelper , который как бы конкретизирует данный CORBA-объект.

  4. Регистрация имени удаленного объекта (testServant)

    Как было сказано раньше регистрация имени производится для того чтобы клиент смог найти удаленный объект. Этой цели служит функция rebind(NameComponent nc, Object obj) интерфейса NamingContext .

    NameComponent nc = new NameComponent("test", ""); //первый параметр //указывает имя объекта, //второй нам использовать не обязательно NameComponent path = {nc}; ncRef.rebind(path, testRef);

  5. Ожидание запросов от клиента. java.lang.Object sync = new java.lang.Object(); synchronized (sync) { sync.wait(); }

    После того как сервер обработает запрос от клиента и выполнит метод count он снова перейдет в состояние ожидания.

Теперь сервер готов к работе

Листинг 1. testServer.java

Import testApp.*; import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; import java.lang.*; class testServant extends _testImplBase { public int count(String msg) { return msg.length(); } } public class testServer { public static void main(String args) { try { ORB orb = ORB.init(args, null); testServant testRef = new testServant(); orb.connect(testRef); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("test", ""); NameComponent path = {nc}; ncRef.rebind(path, testRef); java.lang.Object sync = new java.lang.Object(); synchronized (sync) { sync.wait() } } catch (Exception e) { System.err.println("ERROR: " + e); e.printStackTrace(System.out); } } }

Обратите внимание на то, что все операции выполняемые над CORBA-объектами заключены в try-catch блок.

Перейдем к написанию кода для клиента.

Основные шаги написания клиентского приложения

  1. Создание и инициализация ORB
  2. Получение контекста службы имен (NamingContext )
  3. Нахождение удаленного объекта
  4. Вызов метода count .

Как видно, первые два пункта совпадают с этапами создания серверного приложения, поэтому рассматривать их не будем.

Третий пункт реализуется тоже достаточно просто. Создается объект NameComponent . Вызывается метод resolve(NameComponent path) , который отыскивает по имени удаленный объект (стандартный CORBA-объект). При помощи метода narrow(org.omg.CORBA.Object obj) класса testHelper (сгенерированного idltojava компилятором) получаем объектную ссылку на интерфейс test .

NameComponent nc = new NameComponent("test", ""); NameComponent path = {nc}; org.omg.CORBA.Object obj= ncRef.resolve(path); test testRef = testHelper.narrow(obj);

Теперь можно вызывать метод count

String msg = "try to count"; int count = testRef.count(msg);

Листинг 2. testClient.java

Import testApp.*; import org.omg.CosNaming.*; import org.omg.CORBA.*; import java.lang.*; public class testClient { public static void main(String args) { try { ORB orb = ORB.init(args, null); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("test", ""); NameComponent path = {nc}; test testRef = testHelper.narrow(ncRef.resolve(path)); String msg = "try to count"; int count = testRef.count(msg); System.out.println ("number of chars in message is:" + count); } catch (Exception e) { System.out.println("ERROR: " + e) ; e.printStackTrace(System.out); } } }

Запуск приложения

  1. Запуск сервера имен (входит в поставку с JDK1.2). Это делается, чтобы мы смогли получить ссылку на службу имен tnameserv

    по умолчанию сервер запускается по порту 900. Это значение можно изменить, указав параметр запуска -ORBInitialPort, например

    Tnameserv -ORBInitialPort 1024

  2. Запуск сервера testServer java testServer -ORBInitialPort 1024 // указывается тот порт //по которому работает сервер имен
  3. Запуск клиента testClient java testClient -ORBInitialHost javas.stu.neva.ru -ORBInitialPort 1024

    параметр -ORBInitialHost указывает хост на котором работает testServer

после выполнения этого приложения, на консоль будет выведено

Number of chars in message is:12

Соединение с сервером без использования службы имен

Основная идея этого метода состоит в том, что сервер сохраняет экземпляр класса удаленного объекта (testServant ) в виде текстового файла в любом месте, доступном клиенту. Клиент загружает из файла данные (в объект String ) и преобразует специальными методами в объектную ссылку на удаленный объект.

Все это реализуется следующим образом

Удалим некоторую часть кода - это касается и клиента (testServer.java и testClient.java )

  1. Исключим из import библиотеки org.omg.CosNaming.*; org.omg.CosNaming.NamingContextPackage.*;
  2. Удалим код соответствующий п.3-п.4
Вместо удаленного кода вставим - для сервера: //преобразуем объект в строку String ior = orb.object_to_string(testRef); String filename = System.getProperty("user.home") + System.getProperty("file.separator")+"test_file"; //создаем файл test_file FileOutputStream fos = new FileOutputStream(filename); PrintStream ps = new PrintStream(fos); //записываем в него данные ps.print(ior); ps.close();

для клиента:

String filename = System.getProperty("user.home") + System.getProperty("file.separator")+"test_file"; //открываем файл FileInputStream fis = new FileInputStream(filename); DataInputStream dis = new DataInputStream(fis); //читаем данные String ior = dis.readLine(); //преобразуем в объект CORBA org.omg.CORBA.Object obj = orb.string_to_object(ior); //получаем ссылку на удаленный объект test testRef = testHelper.narrow(obj);

Скомпилируем приложения, запустим сервер и клиент аналогично тому, как мы делали это раньше (сервер имен запускать в данном случае не надо).



Есть вопросы?

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам:

Отправить