Файл: Технология CORBA.pdf

введение

Времена изменились и теперь привычные программы — это не кусок кода, как было раньше, а хорошо продуманный, управляемый сценарий. Он может приводить в действие множество различных информационных объектов, которые в свою очередь будут существовать, как апплеты, скриптлеты и сервлеты [8, стр. 2].

Основу архитектуры управления объектами OMA (object management architecture) составляет брокер объектных запросов ORB (object request broker), который служит посредником при передаче потока информации между объектами. Каждый объект, участвующий в сети CORBA, соединен с брокером, который на практике выступает в роли библиотеки, подходящей для языка программирования, используемого в данном проекте разработки. Взаимодействие между различными брокерами стандартизуется посредством протокола GIOP (general inter-ORB protocol). Протокол IIOP — версия этого протокола для сетей на базе TCP/IP. Данные стандарты составляют основу интероперабельности, которую обеспечивает CORBA между объектами, написанными на разных языках [6, стр. 1]

Общая Архитектура Брокеров Объектных запросов – common object request broker architecture (Cobra) является наиболее важным (и амбициозным) проектом в области промежуточного программного обеспечения, который когда-либо выдвигала компьютерная промышленность [5, стр. 10].

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

Все последние достижения в области программного обеспечения, такие как клиент-серверные технологии, объектная идеология, современные средства моделирования между собой объединенные и поспособствовали подъёму отрасли на новую ступень ее развития [5, стр. 5].

Появление ПК привело к принципиальному отходу от парадигмы монолитной архитектуры с приложениями, работающими на мэйнфреймах. В то время как этим приложениям требовался сам мэйнфрейм для обработки, приложения, основанные на архитектуре клиент-сервер, позволяли передавать часть обработки на ПК на рабочих станциях пользователей [1, стр. 89].

CORBA (Common request broker architecture) – стандарт, который определяется Object Management Group (OMG), позволяющий различным программным компонентам, написанным на нескольких языках программирования и работающим на различных компьютерах, работать совместно, тем самым упрощая разработку распределенных приложений в гетерогенных средах.

CORBA – является не простой, а кроссплатформенной спецификацией. Она определяет такие услуги как безопасность и транзакции. Corba при этом не является операционной системой, а представляет собой промежуточное программное обеспечение.

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

Исходя из цели работы можно определить ее задачи:

• изучение понятия «Брокер объектных запросов», «брандмауэр»;
• изучение тенденций развития технологии.

Для написания данной работы использовались труды ученых, а также учебники по теме работы.

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

глава 1. ОБ ОСНОВАХ стандарта corba

История возникновения стандарта Сorba

За последние десятилетия объектная модель Corba претерпела значительные изменения. Основной задачей Corba являлась возможность создания совместных приложений, основанных на распределенных взаимодействующих объектах. На рисунке 1 представлен логотип Corba.

Рисунок 1. Логотип Corba

Corba – это результат работы целого консорциума OMG (Object Management Group), включавшим в себя более семисот компаний, являвшимися в то время самыми яркими представителями индустрии компьютеров. Исключением являлась компания Microsoft, у которой существовала собственная технология объектного брокера, под названием DCOM (Distributed Component Object Model) [5, стр.11].

Осенью 1990 года OMG впервые было опубликовано руководство по архитектуре управления объектами, обновление которого было сделано в 1992 году.

История Corba начинается в октябре 1991 года с версии Corba1.0. Эта модель включала в себя язык определения интерфейса IDL и основной набор интерфейсов прикладного программирования API для динамического управления запросами и вызовами DII, а также репозиторий интерфейса) [6, стр.3].

IDL (Interface Definition Language) – пассивный язык описания интерфейсов, который определяет функциональность компонентов, т.е. внешние (контрактные) интерфейсы с потенциальными клиентами (в программном смысле). Компоненты, которые написаны на этом языке должны быть доступны независимо от программных языков, инструментальных средств, операционных систем и сетевой инфраструктуры программных компонент [5, стр.12].

Corba 1.0 обеспечивала отображение только для языка программирования C, и была не способна к взаимодействию.

В феврале 1992 была выпущена Corba 1.1, которая являлась широко опубликованной. В нее было внесено много изменений, таких как: закрыты огрехи исходной спецификации, добавлены интерфейсы для базового адаптера объекта и управления памятью, интерфейс репозитория (хранилища данных), а также уточнены неоднозначности в объектной модели.

Следующей версией являлась Corba 1.2, выпущенная в декабре 1993 года. В ней были устранены недостатки в управлении памятью и объектом сравнения ссылок [6, стр.4].

Август 1996 года являлся основополагающим для Corba. Созданная Corba 2.0 быстро получила популярность, а использование технологии позволило создать ряд критически важных приложений. Появление Corba 2.0 можно назвать «капитальным ремонтом» существующей объектной модели Corba, в процессе которого были добавлены некоторые основные возможности:

• динамический скелетный интерфейс или зеркало динамического вызова;
• расширение репозитория интерфейса;
• преобразование начальных ссылок;
• архитектура взаимодействия (GIOP, IIOP, DCE CIOP);
• поддержка многоуровневой безопасности и транзакционных сервисов;
• расширен тип данных для COBOL;
• взаимодействие с OLE2/COM [6, стр.5].

Принятие спецификации поспособствовало возможности взаимодействия объектов через объектные брокеры Corba 2.0, созданные разными производителями. В Corba 2.0 появилась возможность определения стандартного протокола и отображения для языка программирования С++. В версии Corba 2.1 (1997 года) были добавлены дополнительные функции безопасности, а в 1998 году для Corba 2.2 было отображено отображение для Java, однако при этом не осуществлялось никакого взаимодействия с на то время быстро разрастающейся Всемирной паутиной. В связи с возникшей проблемой, компаниям пришлось обратиться к другим технологиям, чтобы иметь возможность создать инфраструктуру электронной коммерции на основе языка разметки HTTP, Web-браузеров, Java и др.

Опыт использования Corba показал разработчикам, что создание Corba-приложения – это достаточно сложная задача. Большинство программных интерфейсов приложений (API – application programming interface) оказались сложными, непонятными и не согласованными, и это требовало от разработчиков более тщательно вникать в большое количество деталей. При этом, простота компонентных моделей, к примеру, EJB, в достаточной мере упрощала программирование. В этот период возникла необходимость построения компонентной модели Corba, потребовавшей большое количество времени.

Разработка CBOF (Common Business Object Facility) начавшаяся в августе 1996 года была на время приостановлена, после чего от нее отказались в пользу CORBA Component Model (ССМ). В июне 1999 года появилась версия Corba 2.3, включавшая в себя новые и пересмотренные характеристики:

• COM / CORBA часть A и B (orbos / 97-09-07), (orbos / 97-09-06, 97-09-19);
• переносимость IDL / Java;
• объекты по значению (orbos/98-01-18), (ptc / 98-07-06);
• сопоставление языка Java с языком IDL;
• сопоставление языка IDL с языком Java;
• сопоставление языков C++;
• отчеты Core и RTF (PTC/98-09-04), (ptc/98-07-05), (ptc / 99-03-01, 99-03-02).

Однако важность новой спецификации имела сомнительную важность так как:

• оказалась достаточно объемной и сложной, а большая часть специфицированных не была реализована и осталась на уровне проекта. Чтение документа показало, что ССМ является технически не готовой, а некоторые разделы спецификации, по сути, невозможно было даже реализовать, а уже реализованные не обеспечивали переносимости;
• компании – поставщики программного обеспечения Corba отказались от реализации ССМ, при этом технология EJB крепко закрепилась в индустрии, не давая другим компонентным технологиям возможности на успешное завоевание своего места.

В июле 2002 в свет вышла спецификация Corba 3.0, являвшаяся основной. Она включала в себя более плотную интеграцию с Java и другие компонентные технологии, которые облегчали программистам использование Corba.

Данная спецификация была некой попыткой противостоять компании Microsoft и ее модели распределенного объектного программирования DCOM. Кроме того, была представлена модель компонентов CCM, с помощью которой спецификация имела возможность перейти от модели распределенных объектов, ограниченной Java, к модели ориентированной на распределенные компоненты.

С 2002 по 2004 годы версии Corba (3.0.1-3.0.3) содержали только незначительные редакционные обновления.

В 2008 году произошла реорганизация спецификации Corba с появлением версии 3.1. Данная спецификация была разделена на три совершенно отдельных документа:

• первая часть – интерфейсы;
• вторая часть – интероперабельность или способность к взаимодействию (функциональная совместимость);
• третья часть – компоненты [6, стр. 2].

Corba спроектирована таким образом, чтобы дать возможность интеллектуальным компонентам находить друг друга и взаимодействовать посредством объектной шины. Кроме того, она определяет широкий набор связанных с шиной сервисов для создания и удаления объектов, для доступа к ним по именам, хранения их в долговременной памяти, предоставления информации об их состоянии и задания определенных связей между ними [5, стр. 12].

Брокер объектных запросов

Брокер объектных запросов является объектной шиной, позволяющий объектам прозрачно генерировать запросы, а в ответ получать отклики от других объектов – локальных или удаленных.

Спецификации Corba 1991 года выпуска определяли только пассивный язык написания интерфейсов, языковое связывание и API необходимое для обращения к ORB, а уже Corba 2.0 определило взаимодействие ORB разных производителей.

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

Брокер объектных запросов дает возможность облегчить связь между клиентом и сервером, при этом скрывая:

• расположение самих объектов: клиент не должен знать, где находится целевой объект, который может располагаться на своем компьютере, либо удаленном;
• реализация объектов: клиент имеет возможность игнорировать язык программирования, на котором был написан удаленный объект, его реализацию или операционную систему, в которой он находится;
• состояние выполнения объекта: при отправке запроса на удаленный объект брокера, он отвечает за инициализацию объекта, при необходимости, прежде чем отправить запрос;
• механизмы связи объектов: клиент не знает какие механизмы связи использует ORB для отправки запросов и возврата ответа.

Язык определения интерфейса IDL

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

Это становится возможным только при обеспечении правильного обмена данными между двумя разными языками, для которых IDL определяет типы данных независимым способом от языка с необходимыми соответствиями. К примеру, длинный тип в 32 бита на языке С++ может соответствовать Java. Благодаря OMG существует множество таких соответствий с популярными языками программирования, такими как: C, C ++, COBOL, Java, Smalltalk или Ada.

В Corba существует два основных типа IDL: