Содержание:

ВВЕДЕНИЕ

CORBA (Common Object Request Broker Architecture) – это Общая Архитектура Брокера Объектных Запросов - это такой стандарт, набор спецификаций для промежуточного программного обеспечения (ППО, middleware) объектного типа. Ядро CORBA брокер (посредник) объектных запросов (ORB). Это подобие магистрали для объектов. Задача ППО, как нам известно, заключается в связывании программных приложений для обмена данными. Преобразования ППО - это путь от программ передачи информации между конкретными приложениями, через средства импорта- экспорта данных и организацию мостов между некоторыми приложениями, через SQL, RPC (Remote Procedure Call), TP мониторы (Transaction Proceesing) обработки транзакций, Groupware - управление различными неструктурированными данными (тексты, факсы, письма электронной почты, календари и т.д.) и, в конце концов, MOM - Message-Oriented Middleware (асинхронный обмен сообщениями между сервером и клиентом), к созданию распределенных компьютерных систем. Элементы этих систем могут как взаимодействовать друг с другом на одной локальной машине, так и по сети. CORBA разрешает организовать единую информационную среду, элементы которой могут общаться друг с другом, не завися от их конкретной реализации, "прописки" в распределенной системе, платформы и языка их реализации [3]. CORBA, как бы образует нижний слой архитектуры промежуточного слоя, обеспечивающий технологическую платформу интероперабельности. Отношения между знаками объектов на этом уровне не принимается во внимание [8]. Основная задача 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 и ее объектно-ориентированных компонентов.

Для достижения поставленной цели, были выделены следующие задачи:

– рассмотреть теоретические аспекты технологии CORBA;

– изучить технология CORBA.

Объект исследования - CORBA.

Предмет исследования - технология CORBA.

Структура работы состоит из введения, основной части, заключения и списка литературы.

ГЛАВА 1 ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ ТЕХНОЛОГИИ CORBA

1.1 Назначение CORBA

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

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

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

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

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

Кроме удаленных объектов в 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 Брокер Объектных Заявок

Брокер Объектных Заявок (Object Request Broker - ORB) - это промежуточное ПО, с помощью которого устанавливаются клиент-серверные отношения между объектами в распределенной компьютерной среде (см. рис. 1). ORB обеспечивает механизмы, которые позволяют объектам посылать или принимать заявки, отвечать на них и получать результаты, не заботясь при этом о положении других объектов в распределенной среде и способе их реализации. ORB также отвечает за поиск реализации объекта-сервера для выполнения заявки, подготовку реализации этого объекта к приему заявки и за передачу данных, являющихся результатом выполнения заявки. Брокер исполняет роль такого механизма, который позволяет объектам выдавать заявки и получать ответы прозрачным образом. И благодаря этому обеспечивается интероперабельность между приложениями на различных аппаратных платформах в неоднородных распределенных средах. Необходимо также подчеркнуть, что речь идет здесь о технической интероперабельности в том смысле, как это понятие интерпретируется в [3].

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

Интероперабельность брокеров трактуется OMG как способность объекта-клиента, управляемого брокером-1, вызывать определенные IDL-спецификациями операции объекта-сервера, управляемого брокером-2, при условии, что брокер-1 и брокер-2 были разработаны независимо друг от друга. Иначе говоря, такие вызовы должны быть независимы от того, одним и тем же или разными (возможно, разнотипными) брокерами поддерживаются взаимодействующие объекты.

CORBA определяет среду для различных реализаций ORB, которые поддерживают общие сервисы и интерфейсы (см. рис.1). Это обеспечивает мобильность клиентов и реализаций объектов по отношению к различным реализациям ORB. Также ORB обеспечивает интероперабельность компонентов глобального объектного пространства. Определения интерфейсов объектов могут быть помещены в Репозитарий Интерфейсов (Interface Repository) двумя способами: - это статически - в результате спецификации на IDL, или это динамически. Репозитарий представляет компоненты интерфейса как объекты и обеспечивает доступ к ним в период выполнения.

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

Клиент может прямо взаимодействовать с ORB. В таком случае ORB ищет соответствующий код реализации объекта, пересылает ему параметры заявки и передает управление. Реализация объекта принимает параметры заявки через сгенерированный компилятором IDL скелетон (Skeleton) и при этом может обращаться к Объектному Адаптеру (Object Adaptor) и ORB [8]. Основная функция объектного адаптера, используемого для реализации CORBA-объекта, - это обеспечение доступа к сервисам брокера объектных запросов. Объектный адаптер предоставляет все низкоуровневые средства для связи объекта с его клиентами. В число данных средств входят:

1. генерация ссылок на удаленные объекты;
2. вызов методов, определенных в IDL;
3. обеспечение безопасности взаимодействия;
4. активация и деактивация объектов;
5. установление соответствия между ссылками на удаленные объекты и реальными экземплярами объектов;
6. регистрация объектов.

Спецификация OMG CORBA определяет базовый объектный адаптер, который должен быть выполнен во всех брокерах запросов. Basic Object Adapter (BOA) - это такой набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активизации приложений. Базовый объектный адаптер является решением первоочередной задачи обеспечения связи между реализацией объекта и брокером запросов. Для организации взаимодействия между ORB и, например, системой управления базами данных должен быть разработан свой объектный адаптер [10].

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

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

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

Для определенного языкового отражения обеспечивается программный интерфейс к стабу для каждого типа интерфейса. Стабы выполняют обращения к ORB, используя скрытые и, возможно, оптимизированные для определенного ядра ORB интерфейсы. Для определенного языкового отображения и, возможно, в зависимости от используемого Объектного Адаптера будет обеспечиваться доступ к методам, реализующим каждый объектный тип. Вызов этих методов осуществляется через скелетон. Присутствие скелетона не подразумевает существование соответствующего стаба клиента. Возможно, и обратное. Можно написать Объектный Адаптер, который не использует скелетоны для вызова методов реализации объектов [10].

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

ORB, включаемый в клиентское и серверное приложение.

Если имеется подходящий механизм коммуникаций, то возможна реализация, ORB-а в виде набора подпрограмм как со стороны клиента, так же и со стороны реализации объекта. Вызовы методов могут транслироваться в работу со средствами взаимодействия процессов (Inter Process Communication - IPC).

ORB, выполненный в виде сервера.

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

ORB как часть системы.

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

ORB, основанный на библиотеках.

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

ГЛАВА 2. ТЕХНОЛОГИЯ CORBA

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

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

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

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

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

Есть 16 объектных служб, это такие как:

Collection Properties

Сoncurrency Сontrol

Query Eventnoti fication

Nships Externalization Security

Licensing Startup

Lifecycle Time

Naming Trader

Persistence Transactions

Реальные объекты, образующие ядро совместимой с 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

Универсальные средства предоставляют поддержку интерфейсов высокого уровня и разделяются на два типа: горизонтальные и вертикальные.

Горизонтальные универсальные средства определяют интерфейсы, которые не зависят от предметной области. В наше время существует предварительная спецификация горизонтальных универсальных средств, которая состоит из следующих разделов:

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

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

а) информационное моделирование, т.е. определяет правила, по которым осуществляется структуризация и доступ к информации,

б) хранение и выборка информации, т.е. определяет использование баз данных и систем каталогов,

в) информационный обмен,

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

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

Средств управления задачами. Предполагается, что данный набор будет представлен четырьмя спецификациями: службы управления потоками работ (workflow facility), службы программных агентов (agent facility), службы управления правилами (rule management facility), службы автоматизации (automation facility).

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

Разрабатываются спецификации следующих средств:

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

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

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

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

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

Средств финансовых коммуникаций (accounting facility). Включают все формы коммерческих транзакций: обмен валюты, управление платежами, продажами и т.п.

Средств поддержки разработки приложений. Обслуживают выбор, разработку, построение и эволюцию приложений, которые составляют корпоративную информационную систему. Данные спецификации включают средства анализа, проектирования, реализации, тестирования и поддержки системы [10].

ЗАКЛЮЧЕНИЕ

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

Элементарно видно, что архитектура CORBA намеренно ориентирована на достижение целей - насущных потребностей разработки прикладных систем, сформулированных в начале статьи:

1. обеспечение функционирования систем в условиях информационной и реализационной неоднородности, распределённости и автономности информационных ресурсов;
2. интеграция систем;
3. реинженерия систем;
4. миграция унаследованных систем;
5. повторное использование неоднородных информационных ресурсов;
6. продление жизненного цикла систем.

Объектный подход развивается около 25 лет. И за это время он прошел путь от академических исследований до промышленных, стандартизованных решений, которые позволяют создавать по-настоящему большие, распределенные корпоративные системы, способные эволюционировать экономически эффективным образом. Отсюда видно, что консолидация современных сетевых, реляционных и объектно-ориентированных технологий позволит выйти на еще более высокий уровень интеграции и качества информационных систем. Анализируемая архитектура веско показывает, что время объектных технологий, технологий конца 20 - начала 21 века, пришло.

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. К.В. Ахтырченко, В.В.Леонтьев, Распределенные объектные технологии в информационных системах // СУБД 2017.
2. ЭккерсонВ.В поисках лучшей архитектуры клиент-сервер // Сети. 2015.
3. Аншина М. Симфония CORBA. “Открытые системы” № 3 2016г.
4. Коржов В. Многоуровневые системы клиент-сервер. “Сети ” 2017г.
5. Роберт Дж. Оберг Технология COM+. Основыипрограммирование = Understanding and Programming COM+: A Practical Guide to Windows 2015 First Edition. -- М.: «Вильямс», 2000. -- С. 480. -- ISBN 0-13-023114-2
6. Соммервилл И. Инженерия программного обеспечения.
7. Драница А. Java против .NET. - "Компьютерра", 516.
8. Калиниченко Л.А., Когаловский М.Р. Стандарты OMG: Язык определения интерфейсов IDL в архитектуре CORBA. «СУБД» №2 1996 г.
9. Аниканов А.А. Визуализация векторных полей с использованием текстурной анимации // Изв. вузов. Сев.-Кав. регион. Естеств. науки. 2001. №4. С. 5-9.
10. Jobard B., Lefer W. The Motion Map: efficient computation of steady flow animation // IEEE Visualization '97. Phoenix, Arizona, USA. 1997. P. 323-328.

Приложения

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