Преподаватель который помогает студентам и школьникам в учёбе.

Технология CORBA

Содержание:

введение

Времена изменились и теперь привычные программы — это не кусок кода, как было раньше, а хорошо продуманный, управляемый сценарий. Он может приводить в действие множество различных информационных объектов, которые в свою очередь будут существовать, как апплеты, скриптлеты и сервлеты [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:

первый тип: заглушка IDL – это статический интерфейс к сервисам, объявленным в интерфейсах IDL, для клиента при этом все вызовы кажутся локальными. Он выступает при этом в качестве прокси удаленного объекта, который вызывает удалённые методы, включая в себя сериализацию, прием ответов и десериализацию. Количество заглушек может быть ограничено только количеством интерфейсов IDL. Генерация интерфейса происходит из IDL на языке программирования клиента (C, C ++, Java, Smalltalk, Ada и др) компилятором IDL.
скелет IDL – это статический представитель клиента на сервере. При этом для сервера все звонки кажутся локальными. Этот тип генерируется из IDL компилятором IDL и выполняет десериализацию вызовов клиента.

Ниже представлен пример IDL для объекта, который выполняет HELLO WORLD. В одностороннем порядке указывается, что связь является однонаправленной и, соответственно, ответ метода не ожидается:

module HelloApp {

interface Hello {

string sayHello();

oneway void shutdown();

}

Java-CORBA как мощное средство решения проблемы объединения систем на основе технологии WWW

Как уже говорилось ранее, у технологии Corba наблюдались проблемы, связанные со Всемирной паутиной. Решением данной проблемы является язык Java, который позволил связать технологию Corba и WWW. Для реализации этой связи использовались программные продукты: OrbixWeb, Visibroker.

Java-технология основана на том, что при обнаружении тега <APPLET>, броузер через сеть загружает к себе необходимые для этого апплета Java-классы и запускает его. При этом на машине пользователя запускается Java Virtual Machine (JVM), внутри которой и выполняется загруженный апплет [7, стр. 1].

Рисунок 4. Java-CORBA

Java-апплет, который является Corba-клиентом, устанавливает все необходимые соединения с другими (серверными) приложениями системы и именно через него к пользователю идет вся информация. Апплет играет роль пользовательского интерфейса для данной распределенной системы. Количество выполняемых апплетов ничем не ограничено -- вопрос лишь в достаточных вычислительных ресурсах системы [7, стр. 2].

У Java-CORBA существуют достоинства и недостатки.

Достоинства Java и Corba:

это платформенно-независимый язык, все апплеты которого выполняются одинаково на любой системе;
у этого языка существует возможность создания сложных пользовательских интерфейсов;
апплеты языка выполняют роль и клиента, и сервера;
при одновременной работе нескольких пользователей не возникает проблем;
по сравнению с CGI (от англ. Common Gateway Interface — «общий интерфейс шлюза») нет необходимости снова загружать апплет.

Недостатки Java:

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

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

У технологии Corba существуют механизмы передачи сообщений, которые называются PUSH и PULL (рисунок 5):

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

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

Рисунок 5. Описание механизмов PUSH и PULL

При использовании механизма PULL, для обработки каждого из запросов клиента сервер расходует свои системные ресурсы, что при наличии большого числа клиентов, регулярно опрашивающих его, заметно снижает его производительность. Многое также зависит и от того, сколь часто клиенты опрашивают сервер. При большом количестве клиентов-ожидателей и коротком времени между двумя запросами к серверу, производительность сервера снижается еще больше [7, стр. 2].

В модели PUSH сервер сообщений гораздо менее загружен. Сервер освобожден от необходимости регулярно реагировать на вызовы клиентов-ожидателей. Наоборот, теперь он имеет дело с клиентами-слушателями. "Вталкивание" сообщений клиенту применяется особенно в тех случаях, когда сообщения, появившиеся на сервере сообщений, должны быть немедленно обработаны клиентом (клиентами). Да и при наличии некачественной связи между узлами, механизм PUSH гораздо более рентабелен, чем PULL -- он использует информационный канал лишь один раз для каждого клиента [7, стр. 3].

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

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

Исходя из практического применения технологии Java-CORBA были сделаны выводы, что она лучше всего подходит для создания WWW Corba-клиентов, которые:

имеют пользовательский интерфейс нестандартного типа, или не HTML – подобного;
в течении какого-то времени активно взаимодействуют с различными компонентами информационной системы;
должны участвовать в роли системы или сервера в информационной системе.

Брандмауэры CORBA

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

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

Подходящими средствами обеспечения соблюдения политик безопасности на границах между доменами безопасности являются брандмауэры. Целью межсетевого экрана CORBA OMG является улучшение доступа к серверам приложений CORBA, когда существует межсетевой экран, отделяющий сервер от клиента. Это облегчает включение и управление связью клиент-брандмауэр-сервер в более широком диапазоне обстоятельств со значительно сниженной административной нагрузкой. Интероперабельная связь CORBA осуществляется через общий протокол Inter-ORB (GIOP), который в Интернете реализуется посредством IIOP (отображение GIOP на транспорт TCP). Поскольку брандмауэры управляют связью по IP-сетям, а ORB обмениваются данными через IIOP, большая часть деятельности CORBA Firewall посвящена различным операциям, связанным с обработкой трафика IIOP через брандмауэр [2, стр. 3].

CORBA (точнее, IIOP) использует соединения TCP / IP для передачи данных. Однако, если клиент находится за очень ограничительным брандмауэром или средой с прозрачным прокси-сервером, которая разрешает только внешние HTTP-соединения через порт 80, связь может оказаться невозможной, если только соответствующий прокси-сервер не разрешает метод HTTP CONNECT или соединения с сокетами. Был момент, когда было трудно заставить реализации использовать один стандартный порт, вместо этого они должны были выбрать несколько портов наугад.

Нынешние ORB не имеют этих недостатков. Из-за этих трудностей некоторые пользователи предпочли использовать веб-службы вместо CORBA. Они взаимодействуют с использованием XML / SOAP через порт 80, который обычно остается открытым или фильтруется через HTTP-прокси в организации для просмотра веб-страниц через HTTP.

Реализации CORBA поддерживают SSL и могут быть легко настроены для работы на одном порту. Большинство самых популярных ORB с открытым исходным кодом, таких как TAO и JacORB, также поддерживают двунаправленный GIOP, что дает CORBA преимущество в том, что он может использовать обратную связь вызова, а не подход опроса функция реализации веб-сервисов. В свою очередь, все больше и больше брандмауэров, которые поддерживают CORBA, без проблем продаются.

Внешние и внутренние маршрутизаторы настроены с точки зрения IP-адресов, портов и бита ACK в заголовках TCP. Более сложные маршрутизаторы могут также проверять трафик для некоторых обычно используемых протоколов приложений (например, HTTP, FTP), чтобы динамически предоставлять некоторые разрешения и отклонять трафик, если протокол приложения не соблюдается правильно.

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

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

глава 2. ОБ обзоре архитектуры и специфики corba

2.1 Архитектура распределенных объектов Corba

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

Как уже было сказано ранее, ORB (брокер объектных запросов) является основным компонентом Corba, а, следовательно, все объекты с ним совместимые должны использовать этот брокер между собой и теми, кто к ним обращается (Рисунок 2,3).

Рисунок 2. Путь вызова с точки зрения клиента

Рисунок 3. Путь вызова от клиента к удаленному объекту

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

Развитие аппаратных и программных средств привело к появлению большого количества несовместимых систем, которые в скором времени были решены при помощи системных интеграторов. В этот период консорциумом OMG, совместно с компаниями – производителями, была разработана OMA (Object ManagementArchitecture) – модель архитектуры управления объектами (рисунок 3).

Рисунок 3. Эталонная модель архитектуры управления объектами

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

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

Существующие в Corba брокеры объектных запросов играют в ОМА основную роль и реализуются одним из способов, при этом, для клиента и серванта средства реализации совершенно не имеют никакого значения:

в виде библиотек – используется клиентом;
в виде процессов-демонов – используется сервером.

Концепции Corba касаются объектных адаптеров (объектов), располагающихся между клиентом и сервером, для управления доступом к распределенному объекту. Объектным адаптером до появления Corba 3.0 являлся базовый объектный адаптер (Basic Object Adapter – BOA), который упрощал соединение клиента и сервера. С появлением Corba 3.0 был определен адаптер РОА – переносимый объектный адаптер, заменивший предыдущий ВОА, который не соответствовал основным требованиям, которые предъявляются к Интернет-приложениям.

Изначально архитектура CORBA допускала передачу при вызове удаленных методов только примитивных типов данных или удаленных ссылок. Теперь же IDL-определение включает в себя предложения Objects-by-Value («объект по значению»), благодаря чему можно передавать состояние объектов и поведение так, как это делается с помощью RMI. Активное использование этой возможности и поддержки соответствия Java-to-IDL позволяет Java-программистам разрабатывать приложения на базе CORBA, даже не изучая IDL. Разработчик может указать интерфейсы средствами Java.

Новый компилятор rmic, включенный в состав JDK 1.3, может создавать суррогаты, скелетоны и связи CORBA непосредственно из определений интерфейса в терминах Java. Кроме того, чтобы создать службы или клиенов на других языках программирования, можно генерировать IDL-определение автоматически и использовать его как входную информацию для других компиляторов [4, стр. 1].

2.2. Сервисы CORBA как основные объектные службы

Сервисы CORBA (CORBA services) – являются базовыми сервисами, которые доступны всем объектам, подключенным к коммуникационной шине данного брокера объектных запросов. Так как брокер объектных запросов — это ядро системы Corba, то его наличие может требоваться сервисам для правильного функционирования.

Всего существует шестнадцать сервисов:

сервис имен (Naming Service);
сервис управления событиями (Event Management Service);
сервис жизненных циклов (Life Cycle Service);
сервис устойчивых состояний (Persistent State Service);
сервис транзакций (Transaction Service);
сервис параллельного исполнения (Concurrency Service);
сервис взаимоотношений (Relationship Service);
сервис экспорта (Externalization Service);
сервис запросов (Query Service);
сервис лицензирования (Licensing Service);
сервис управления ресурсами (Property Service);
сервис времени (Time Service);
сервис безопасности (Security Service);
сервис уведомлений (Notification Service);
сервис трейдинга (Trader Service);
сервис коллекций (Collections Service).

Трехуровневая архитектура информационных систем, согласно спецификациям OMG, включает в себя системы управления данными, сети взаимодействующих Corba-объектов и пользовательские интерфейсы для представления данных [5, стр.25].

В книге «Основы Corba» известного американского автора Роберта Орфали в полной мере описываются все сервисы.

Благодаря сервису Жизненного Цикла (Life Cycle Service) определяются операции создания, копирования, перемещения и удаления компонентов на шине.

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

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

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

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

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

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

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

Сервис Запросов (Query Sevice) обеспечивает поддержку запросов для объектов. Он представляет собой надмножество SQL и основан на расширенных спецификациях SQL3 и языке объектных запросов (Object Query Language - OQL).

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

Сервис Свойств (Properties Service) предоставляет операции, которые позволяют вам ассоциировать именованные величины (или свойства) с любым компонентом.

Сервис Времени (Time Service) предоставляет интерфейс для синхронизации времени в среде распределенных объектов. Кроме того, предусматривает операции для определения и управления событиями, ориентированными на определенное время.

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

Сервис Коммерции (Trade Service) обеспечивает «Желтые страницы» для объектов; это дает возможность объектам оповещать о своих сервисах и выставлять заявки о себе на «рынок труда».

Сервис Контейнеров (Collection Service) предоставляет интерфейсы CORBA для создания и поддержки общедоступных контейнеров [5, стр. 27].

Известным фактом является то, что службы OMG не являются независимыми друг от друга. Часть этих служб создается на базе иных служб.

2.3. Универсальные средства CORBA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7) Средства поддержки разработки приложений, обслуживающие выбор, разработку, построение и эволюцию приложений, составляющих корпоративную информационную систему. Эти спецификации включают средства анализа, проектирования, реализации, тестирования и поддержки системы [5].

ГЛАВА 3. О ДОСТОИСТВАХ И НЕДОСТАТКАХ ТЕХНОЛОГИИ

3.1. Минусы и критика в отношении Corba

Несмотря на то, что Corba давала большое количество обещаний в отношении кодирования и сборки программного обеспечения, она в результате подвергается большому количеству критики.

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

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

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

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

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

3.2. CORBA в условиях реального времени

Мной была изучена статья из журнала «СУБД» издательства «Открытые системы», в которой говорилось, что компания "РТСофт", являющаяся эксклюзивным дистрибьютором известного производителя, встраиваемого программное обеспечение LynuxWorks на территории России и стран СНГ, сообщила, что операционная система реального времени LynxOS-178 разработки LynuxWorks теперь полностью интегрирована с программным обеспечением ORBexpress RT фирмы Objective Interface Systems.

ORBexpress RT реализует в режиме реального времени функции брокера объектных запросов (Object Request Broker, ORB) архитектуры CORBA (Common Object Request Broker Architecture) для систем оборонного и аэрокосмического применения. Комбинация ОСРВ LynxOS-178 и коммуникационного слоя ORBexpress RT обеспечит детерминированную задержку отклика при малых размерах кода прикладной программы и позволит многократно использовать этот код в различных системах. ORBexpress RT стал первой реализацией стандарта CORBA, перенесенной на ОС реального времени с сертификатом DO-178B уровня A.

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

заключение

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

На сегодняшний день технология DCOM, принадлежащая компании Microsoft потеснила CORBA с рынка Windows-ориентированных систем.

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

БИБЛИОГРАФИЯ

Henry Balen Distributed object architectures with Corba, Cambridge University Press, 2000
OMG, Joint Revised Submission, CORBA/Firewall Security+Errata, OMG Document, https://folk.uio.no/abie/fw.pdf
Журнал «СУБД», Издательство «Открытые системы»
Журнал «СУБД», статья Интеграция Java и CORBA: точка зрения программиста, Издательство «Открытые системы», 2001, № 10
Орфали Р., Харки Д., Эдвардс Д. «Основы Corba», Пер. с англ. – М., МАЛИП, Горячая Линия – Телеком, 1999. – 318 с.
Официальный сайт http://www.corba.org Дата обращения: 15.07.2019
Статья «Технологии WWW, Corba и Java в построении распределенных объектных систем» http://www.javaportal.ru/articles/www/www3.html / Дата обращения: 16.07.2019
Статья http://progbook.ru/java/1319-dunaev-tehnologii-internet-programmirovaniya.html Дата обращения: 14.07.2019
Орфали Р., Харки Д., Эдвардс Д. «Основы Corba», Пер. с англ. – М., МАЛИП, Горячая Линия – Телеком, 1999. – 318 с.
Henry Balen Distributed object architectures with Corba, Cambridge University Press, 2000
Статья http://progbook.ru/java/1319-dunaev-tehnologii-internet-programmirovaniya.html Дата обращения: 14.07.2019
Официальный сайт http://www.corba.org Дата обращения: 15.07.2019
Журнал «СУБД», статья Интеграция Java и CORBA: точка зрения программиста, Издательство «Открытые системы», 2001, № 10
Журнал «СУБД», Издательство «Открытые системы»
Статья «Технологии WWW, Corba и Java в построении распределенных объектных систем» http://www.javaportal.ru/articles/www/www3.html / Дата обращения: 16.07.2019
OMG, Joint Revised Submission, CORBA/Firewall Security+Errata, OMG Document, https://folk.uio.no/abie/fw.pdf