Введение
В любой организации связанные с бизнесом направления работы распределены между различными членами организации для более эффективной обработки каждой части. Таким же образом распределяются и объекты в киберпространстве организации для наиболее эффективного выполнения их бизнес-функций. Парадоксально, но цель системы распределенных объектов заключается в лучшей интеграции организации. Достаточно осмысленное и продуманное распределение объектов на все бизнес-процессы организации создает большую связность, дополнительную эффективность и делает систему в целом гораздо более рациональной. Однако это распределение должно быть идеально продуманно, ибо распыление объектов по ветру несомненно вредно. Чтобы предотвратить подобные ошибки, в этой статье представлены мощные технологии такие, как 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.
Следующие термины относятся к циклу жизни серванта:
- Воплощение (incarnation) - соединение серванта с объектом CORBA
- Уничтожение (еtherealization) - разрушение ассоциации между сервантом и объектом 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.