Назначение CORBA и ее объектно-ориентированных компонентов

Ядро CORBA брокер (посредник) объектных запросов (ORB). Это что-то вроде магистрали для объектов. Основная задача ORB оказывать посреднические услуги при обмене запросами между объектами. Хотя ORB «обитает» в среде клиентсервер, объекты, с которыми он работает, выполняют функции либо клиентов, либо серверов, в зависимости от обстоятельств. Если объект принимает и обрабатывает запрос, то он играет роль сервера. Если он отправляет запрос, то выступает в роли клиента. Основная задача ORB прием и отправка запросов, а также передача результатов, в том числе перехват каждого запроса одного объекта другому; определение местонахождения объекта, который, предположительно, обработает запрос; запуск соответствующего метода принимающего объекта; при необходимости передача параметров и передача результатов объекту, инициировавшему запрос. Поскольку ORB обрабатывает запросы «прозрачно», неважно, от какого объекта локального или удаленного поступил запрос. При обработке этих запросов для ORB не имеет значения ни язык программирования, ни операционная система или платформа. Механизм, обеспечивающий «прозрачность» обработки запросов, называется языком определения интерфейса (Interface Definition Language, IDL). Этот язык применяется для объявления границ и интерфейсов объекта. Во многом подобно независимому арбитру, IDL нейтрален и не зависит от объектов и ORB, тем не менее он связывает поставщиков служб распределенных объектов с их клиентами. Всякому, кто знаком с DCOM, наверное, известно, что в модели DCOM используется IDL. Но IDL DCOM несовместим с CORBA и работает иначе, чем IDL CORBA. В CORBA предусматривается множественное наследование, а ее IDL-средствам наследование необходимо для инкапсуляции объектов. Это существенно облегчает многократное использование блоков программ. В DCOM механизм множественного наследования не реализован. Поэтому вы должны подготовить и объединить все интерфейсы, прежде чем к ним обратится клиент. Язык IDL хорош тем, что позволяет кратко описать API, сохранив при этом свободу определить методы на любом языке программирования, который обеспечивает связывание с CORBA. К таким языкам относятся Ада, Кобол, Си, Си++, Smalltalk и Java. У некоторых поставщиков имеются собственные средства согласования с CORBA для Visual Basic и Фортрана. Как известно любому человеку, имевшему дело с объектно-ориентированным программированием, для составления запроса необходимы сведения об интерфейсе принимающего объекта, а объекты должны быть разработаны так, чтобы они могли получать информацию об интерфейсах тех объектов, с которыми они будут взаимодействовать. Но, пытаясь применить этот подход для распределенной между гетерогенными объектами обработки, вы столкнетесь с множеством проблем. Для подлинной независимости IDL в CORBA используется репозиторий (хранилище) интерфейсов, предназначенный для хранения сигнатур методов, принадлежащих объектам, с тем чтобы эти сигнатуры можно было динамически извлекать и обновлять во время исполнения программы. Благодаря этому все объекты в корпоративной системе могут получить информацию об интерфейсах других объектов, методах, принадлежащих этим интерфейсам, и параметрах, необходимых для обращения к ним.

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

1. Назначение CORBA

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

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

Спецификация CORBA использует язык описания интерфейсов (OMG IDL) для определения интерфейсов взаимодействия объектов с внешним миром, она описывает правила отображения из IDL в язык, используемый разработчиком CORBA-объекта.

Стандартизованы отображения для Ада, Си, C++, Lisp, Smalltalk, Java, Кобол, ObjectPascal, ПЛ/1 и Python.

Также существуют нестандартные отображения на языки Perl, Visual Basic, Ruby и Tcl, реализованные средствами ORB, написанными для этих языков.

1.1 Объекты по значению

Помимо удалённых объектов в CORBA 3.0 определено понятие объект по значению. Код методов таких объектов по умолчанию выполняется локально. Если объект по значению был получен с удалённой стороны, то необходимый код должен либо быть заранее известен обеим сторонам, либо быть динамически загружен. Чтобы это было возможно, запись, определяющая такой объект, содержит поле Code Base — список URL, откуда может быть загружен код. У объекта по значению могут также быть и удалённые методы, поля, которые передаются вместе с самим объектом. Поля, в свою очередь также могут быть такими объектами, формируя таким образом списки, деревья или произвольные графы. Объекты по значению могут иметь иерархию классов, включая абстрактные и множественное наследование.

1.2 Компонентная модель CORBA (CCM)

Компонентная модель CORBA (CCM) — недавнее дополнение к семейству определений CORBA.

CCM была введена начиная с CORBA 3.0 и описывает стандартный каркас приложения для компонент CORBA. CCM построено под сильным влиянием Enterprise Java Beans (EJB) и фактически является его независимым от языка расширением. CCM предоставляет абстракцию сущностей, которые могут предоставлять и получать сервисы через чётко определённые именованные интерфейсы, порты. Модель CCM предоставляет контейнер компонентов, в котором могут поставляться программные компоненты. Контейнер предоставляет набор служб, которые может использовать компонент. Эти службы включают (но не ограничены) службу уведомления, авторизации, персистентности и управления транзакциями. Это наиболее часто используемые распределённым приложением службы. Перенося реализацию этих сервисов от необходимости реализации самим приложением в функциональность контейнера приложения, можно значительно снизить сложность реализации собственно компонентов.

1.3 Общий протокол межброкерного взаимодействия (GIOP)

GIOP (GeneralInter-ORB Protocol) — абстрактный протокол в стандарте CORBA, обеспечивающий интероперабельность брокеров. Стандарты, связанные с протоколом выпускает Object Management Group (OMG). Архитектура GIOP включает несколько конкретных протоколов:

Internet Inter ORBP protocol (IIOP) (Межброкерный протокол для Интернет) — протокол для организации взаимодействия между различными брокерами, опубликованный консорциумом OMG. IIOP используется GIOP в среде интернет, и обеспечивает отображение сообщений между GIOP и слоем TCP/IP.

SSL InterORBProtocol (SSLIOP) — IIOP поверх SSL, поддерживаются шифрование и аутентификация.

Hyper Text Inter ORB Protocol (HTIOP) — IIOP поверх HTTP.

Corba Loc (англ. Corba Location) — является строковой ссылкой на объект технологии CORBA, подобной URL. Borland Enterprise Server, Visi Broker Ed. — CORBA 2.6-совместимый коммерческий ORB от Borland, поддерживает Java и C++.

· MICO — свободный (LGPL) ORB с поддержкой C++.

· omni ORB — свободный (LGPL) ORB для C++ и Python.

· ORBit2 — свободный (LGPL) ORB для C, C++ и Python.

· Jac ORB — свободный (LGPL) ORB, написан на Java.

· TAO — The ACE ORB, открытый ORB для C++.

· Orbacus — коммерческий ORB для C++, Java от IONA Technologies.

CORBA (CommonObjectRequestBrokerArchitecture) — Общая Архитектура Брокера Объектных Запросов — это стандарт, набор спецификаций для промежуточного программного обеспечения (ППО, middleware) объектного типа. Задача ППО, как известно, заключается в связывании программных приложений для обмена данными.

CORBA программирование распределенных систем Уильям Р. Станек Подготовка прикладных программ, объекты которых составлены на разных языках и взаимодействуют между собой на самых разных ОС и платформах.

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

Назовем технологии, позволяющие осуществлять распределенную обработку в гетерогенных системах: это архитектура брокера общих объектных запросов (CommonObjectRequestBrokerArchitecture, CORBA) и протокол InternetInter-ORB Protocol (IIOP). CORBA полностью определяет архитектуру, необходимую для обмена информацией между распределенными объектами. К числу ее спецификаций относятся IIOP и множество других технологий. IIOP самый важный компонент CORBA, потому что его основная функция организация взаимодействия распределенных объектов в гетерогенной среде. Вместе CORBA и IIOP характеризуют многообразие средств промежуточного уровня, которые станут стимулом для пересмотра подходов к созданию прикладных программ в сетевых средах разработчиками всего мира.

CORBA не исключительный варианты решения, обеспечивающего распределенную обработку. Существует и конкурирующая архитектура, разработанная корпорацией Microsoft, объектная модель распределенной обработки (DistributedComputingObjectModel, DCOM), в основном представленная брокером объектных запросов (ObjectRequestBroker, ORB), который входит в состав Windows NT 4.0 и будет включен в следующую редакцию Windows[10].

CORBA детище консорциума ObjectManagementGroup (OMG), в составе которого более 700 компаний из самых различных отраслей промышленности. Цель этой организации состоит в том, чтобы определять базовые структуры для разработки приложений с использованием объектно-ориентированных методов. OMG выпускает спецификации, позволяющие стандартизировать обработку распределенных объектов, а не прикладные программы, и такая ориентация на разработку идей, а не программ принесла группе большой успех. Самый удачный результат деятельности OMG впервые реализованная в 1991 г. CORBA. CORBA описывает стандартную архитектуру для обмена информацией между распределенными объектами, благодаря которой компоненты прикладных программ могут связываться друг с другом, независимо от их местоположения в вычислительной сети. Более того, поскольку CORBA определяет стандартный интерфейс между объектами, операционная система, в которой работает объект, и язык, на котором он составлен, не имеют значения. Если объект удовлетворяет требованиям CORBA, он способен обмениваться информацией с другими распределенными объектами. Появившийся в декабре 1994 г. как составная часть спецификации CORBA 2.0 протокол IIOP еще одна удача OMG. До того как был подготовлен протокол IIOP, спецификация CORBA определяла способ взаимодействия только для распределенных объектов, созданных одним производителем. При подготовке объектов приходилось рассчитывать лишь на конкретную реализацию архитектуры. Благодаря IIOP вторая спецификация CORBA стала окончательным решением для взаимодействия объектов, которое не привязано ни к какой конкретной платформе или реализации.

С применением CORBA вы создадите системы масштаба предприятия (корпоративные системы), в которых объекты распределены по вычислительной сети. В корпоративных системах основные объекты для обслуживания файлов, необходимые прикладной программе, могут храниться на сервере Windows NT. Эти объекты вы составите, например, на языке Си++. На большом компьютере можно разместить первичные функции ядра системы скажем, используя объекты, запрограммированные на языке Кобол. Любой настольный компьютер, работающий под управлением Windows 95, пригоден для хранения внешних интерфейсов, использующих объекты, созданные средствами VisualBasic. И все эти объекты могут обмениваться информацией, а посредником при передаче запросов служит CORBA[8].

Фирмы Netscape Communications Corp. и SunMicrosystems избрали CORBA и IIOP в качестве основы для следующего поколения своих программ. Sun применяет CORBA и IIOP для реализации гетерогенных вызовов удаленных процедур в языке программирования Java 1.1, причем без этих технологий в копоративных сетях не было бы платформы Java (JavaPlatform). Более того, в API EnterpriseJavaBeans будут применяться CORBA и IIOP, чтобы обеспечить возможность создания масштабируемых прикладных программ для деловой сферы (бизнес-приложения) с многократно используемыми серверными компонентами. Дляогранизации вызовов удаленных процедур в языке Java пригодна и технология DCOM. Необходимые для этого специальные программные процедуры имеются в Visual J++. Но модель DCOM рассчитана только на платформы Windows NT 4.0 и Windows 95 (с помощью расширений InternetExplorer), т. е. DCOM не годится для обмена информацией с другими операционными системами. Microsoft сообщает, что в будущем технология DCOM будет перенесена на другие платформы. По протоколу IIOP осуществляется взаимодействие открытой сетевой среды (OpenNetworkEnvironment, ONE) фирмы Netscape с корпоративными системами. Кроме того, с помощью IIOP программисты могут подключать программы, подготовленные на языках Java, JavaScript и Си или Си++, к системам масштаба предприятия.

В программе NetscapeNavigator протокол IIOP реализуется в рамках механизма LiveConnect и предназначен для обмена информацией между апплетами, внешними модулями и сценариями.

2. Технология CORBA

2.1 Объединение компонентов

Как технология, которая обеспечивает базовые структуры для взаимодействия разнородных объектов, CORBA достигла замечательных успехов, и это при том, что она представляет собой только часть еще более крупной архитектуры управления объектами (ObjectManagementArchitecture, OMA), состоящей из следующих компонентов:

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

2.2 Службы объектов CORBA

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

Имеется 16 объектных служб, в том числе:

CollectionProperties

Сoncurrency Сontrol

Query Eventnotification

NshipsExternalizationSecurity

LicensingStartup

LifecycleTime

NamingTrader

PersistenceTransactions

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

Компонент это набор бизнес-объектов, которые осуществляют обработку, инкапсулируют данные и обеспечивают необходимые интерфейсы пользователя. Для взаимодействия объектов в рамках компонента используется ORB. Кроме того, с помощью ORB объекты обмениваются информацией о себе, в результате объекты «узнают» о существовании других объектов во время исполнения программы. Таким образом, в компоненте имеется все необходимое для вывода на экран представления объекта и взаимодействия с ним. Типичный бизнес-компонент мог бы применяться, скажем, для вывода на экран распределения мест на 11-часовом рейсе до Лос-Анджелеса, а другой для регистрации сведений о бронировании мест на этот рейс. Возможности компонентов можно расширить за счет добавления служебных функций системного уровня. Функция Persistence пригодится, чтобы поддерживать состояние объектов в рамках компонента.

Поскольку эти сервисные функции встроены в CORBA, их можно применять для создания «интеллектуальных» (smart) компонентов, при этом нет необходимости программировать их с нуля. Хотя и в DCOM имеется реестр компонентов и справочная служба, там нет способа поддерживать состояние объектов DCOM в перерыве между соединениями. Из-за этого недостатка DCOM уступает CORBA. На уровне прикладной программы, где устанавливаются границы инфраструктуры компонентов, базовые структуры программ определяют способы реализации совместной деятельности независимых компонентов. Благодаря четко определенным границам все компоненты вместе функционируют как единый комплекс, так что создается впечатление единства прикладной программы. Именно такое единство позволяет прикладным программам, использующим распределенные в гетерогенных средах объекты, «прозрачно» сопрягаться друг с другом. «Прозрачная» интеграция означает, что пользователи воспринимают прикладную программу как единое целое, а не как сложный набор разобщенных модулей. Инфраструктуру компонента одной прикладной программы можно расширить до инфраструктуры компонента нескольких программ. В этом случае CORBA несет ответственность за обмен информацией между множеством различных прикладных программ в рамках корпоративной системы. Для несовместимых с CORBA программ, например доставшихся в наследство приложений, можно создать оболочки (wrappers), которые придают им подобие объектов CORBA. Оболочка выполняет роль интерфейса, необходимого для доступа к конкретным функциям старой программы. Если вы с помощью CORBA интегрировали унаследованные программы с процессами клиента и сервера, у вас есть все составляющие многоуровневой модели клиентсервер. Один уровень это визуальные объекты, например интерфейсы, размещаемые на клиентских ПК. Другой уровень объекты сервера, предусматривающие бизнес-функции. Еще один уровень составляют унаследованные прикладные программы, например СУБД на большой ЭВМ.

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

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

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

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

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

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

· Дезактивация (deactivation) — завершение работы активного объекта CORBA.

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

· Воплощение (incarnation) — соединение серванта с объектом CORBA

· Уничтожение (еtherealization) — разрушение ассоциации между сервантом и объектом CORBA

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

JavaBeans, так что программисты на Java находятся в привилегированном положении. Все остальное, что присутствует в COM, имеется и в CORBA, и даже более того — за исключением универсальной технологии доступа к БД. Опять-таки, Java-программисты имеют преимущество и здесь — за счет наличия общей для Java технологии доступа к данным JDBC. Под «стандартом» применительно к CORBA понимается то, что официально утверждено консорциумом OMG. Надо сказать, что это очень высокий уровень «легитимности», так как авторитет OMG в компьютерном мире чрезвычайно высок. В настоящий момент стандартизовано отображение языка IDL на 6 языков программирования — Ada, C, C++, Cobol, Java и Smalltalk. Существуют также отображения на Pascal (точнее, Delphi), Perl, Python и еще десяток языков. Наиболее используемыми языками в настоящий момент являются Java (вследствие прекрасного взаимодействия Java-технологий, особенно JDBC, RMI, JNDI и EJB, с CORBA), и C++ - как самый эффективный, мощный и распространенный язык компьютерной индустрии. CORBA обеспечивает даже несколько более высокий уровень за счет базировании технологии исключительно на языке описания IDL с последующим отображением таких спецификаций на конкретный язык программирования, а также некоторых возможностей, например, автоматического (т.е. прозрачного для программиста) распространения контекста транзакций. CORBA в настоящее время не имеет своей компонентной модели. Пусть это не имеет практического значения для Java-программистов, но в общем случае эта та область, где OMG (и фирмам-производителям программного обеспечения) еще предстоит серьезно поработать. CORBA имеет очень развитую сервисную часть; например, только для поиска серверных объектов по различным критериям можно использовать 4 различных сервиса CORBA. Кроме того, OMG стремится к максимальной стандартизации вспомогательных возможностей CORBA. CORBA предоставляет разработчикам существенно большие возможности, чем COM, в области сервисов и вспомогательных средств. С другой стороны, COM-программисты обычно не испытывают какого-либо дискомфорта из-за их недостатка. Вследствие ограниченности области применения COM объективно нет необходимости в создании таких же развитых и универсальных средств, как это совершенно необходимо для CORBA. Понятие «объекта» в CORBA принципиально отличается от своего COM-аналога. Объект CORBA не является переменной языка программирования и в общем случае время его существования не связано со временем работы серверных или клиентских приложений. СORBA-объект не занимает никаких ресурсов компьютера — оперативной памяти, сетевых ресурсов и т. п.

Эти ресурсы занимает только так называемый «сервант» (servant), который является «инкарнацией» одного или нескольких CORBA-объектов. Именно сервант является переменной языка программирования. Пока не существует сервант, сопоставленный с конкретным объектом CORBA, этот объект не может обслуживать вызовы клиентов, но, тем не менее, он существует. Результатом создания объекта (при этом совершенно не обязательно при этом создается и сопоставляется с этим объектом соответствующий сервант!) является так называемая «объектная ссылка» CORBA. Объектная ссылка сопоставлена с этим, и только с этим объектом, и это сопоставление остается корректным в течение всего срока существования CORBA-объекта (может быть, в течение нескольких лет). Объектная ссылка CORBA правильно интерпретируется ORB’ами от любого производителя программного обеспечения. После уничтожения CORBA-объекта все объектные ссылки на него навсегда теряют смысл. С помощью объектной ссылки клиент вызывает методы объекта, при этом инкарнациями этого объекта могут быть различные серванты (не более одного одновременно), которые физически могут находиться даже на различных компьютерах. CORBA является существенно более открытой, универсальной и гибкой системой, чем COM. И COM, и CORBA способны тесно и эффективно взаимодействовать со стандартными средствами обеспечения безопасности.

Несмотря на внешнюю похожесть, что вызвано общностью решаемых задач, между COM и CORBA, пожалуй, больше различий, чем сходства. В большинстве случаев либо нецелесообразно использовать CORBA (для небольших и простых проектов под Windows просто по причине относительно высоких затрат на приобретение программного обеспечения, лицензий и пр.), либо практически невозможно использовать COM (для сложных, масштабируемых, высоконадежных проектов или просто при работе в гетерогенных средах, а не только в Windows). Windows-приложения, ориентированные на взаимодействие с MicrosoftOffice, всегда будут использовать COM; проекты с использованием Java и любых Java-технологий (кроме Microsoft J++), как говорится, «сам бог велел» строить на основе CORBA. Во многих случаях выбор технологии диктует выбор той или иной части проекта: если вы планируете работать, например, с ORACLE 8i, то, безусловно, гораздо лучше ориентироваться на CORBA. Область, где эти технологии реально конкурируют, на мой взгляд, очень невелика. Как нетрудно заметить, автор настоящего обзора является сторонником CORBA, чего и желает всем своим читателям.

жизненный цикл межброкерный информационный

Заключение

Учитывая, что в стоящий за этой спецификацией консорциум входит более 700 компаний, CORBA нечто большее, чем повальное увлечение, охватившее рынок. CORBA превосходит традиционную трехуровневую модель клиент сервер благодаря тому, что это полностью масштабируемая и исключительно гибкая архитектура. Используя CORBA, вы с легкостью расширите сеть, состоящую из трех компьютеров до сети масштабов Интернета. CORBA обеспечивает базовую структуру, позволяющую соединять объекты, запрограммированные на разных языках, причем не имеет значения, для какой платформы или операционной системы эти объекты были созданы, если есть средства согласования с CORBA. Поскольку CORBA предназначена для гетерогенных платформ, в настоящее время у нее есть преимущества перед DCOM. Однако принимая во внимание мощь Microsoft, DCOM, несомненно, в ближайшем будущем станет силой, с которой придется считаться.

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

1. К. В. Ахтырченко, В. В. Леонтьев, Распределенные объектные технологии в информационных системах // СУБД 1997.

2. ЭккерсонВ. В поисках лучше й архитектуры клиент-сервер // Сети. 1995.

3. Аншина М. Симфония CORBA. «Открытые системы» № 3 1998г.

4. Коржов В. Многоуровневые системы клиент-сервер. «Сети «1997 г.

5. Роберт Дж. Оберг Технология COM+. Основыипрограммирование = Understanding and Programming COM+: A Practical Guide to Windows 2000 First Edition. — М.:"Вильямс", 2000. — С. 480. — ISBN 0−13−23 114−2

6. Соммервилл И. Инженерия программного обеспечения.

7. Драница А. Java против .NET. — «Компьютерра», #516.

8. Аниканов А. А. Визуализация векторных полей с использованием текстурной анимации // Изв. вузов. Сев.-Кав. регион. Естеств. науки. 2001. № 4. С. 5−9.

9. Jobard B., Lefer W. The Motion Map: efficient computation of steady flow animation // IEEE Visualization '97. Phoenix, Arizona, USA. 1997. P. 323−328.

Приложения Архитектура CORBA

Сравнение CORBA и DCOM

.ur