Технология CORBA (Использование технологии CORBA)

Содержание:

ВВЕДЕНИЕ

CORBA (Common Object Request Broker Architecture - общая архитектура брокера объектных запросов) – это технология разработки распределенных приложений, ориентированная на интеграцию распределенных изолированных систем. В начале 1990-х гг. ночным кошмаром были проблемы обеспечения возможности общения программ, выполняемых на разных машинах, особенно, если использовались разные аппаратные средства, операционные системы и языки программирования: либо программисты использовали сокеты и сами реализовывали весь стек протоколов, либо их программы вовсе не взаимодействовали. (Другие ранние средства промежуточного программного обеспечения были ограничены средой C и Unix и не подходили для использования в неоднородных средах.) Для решения данной проблемы в 1989 г. был создан консорциум OMG (Object Management Group), основной задачей которого стала разработка и продвижение объектно-ориентированных технологий и стандартов. Это некоммерческое объединение, разрабатывающее стандарты для создания корпоративных платформо-независимых приложений.

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

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

Под "стандартом" применительно к CORBA понимается то, что официально утверждено консорциумом OMG. Надо сказать, что это очень высокий уровень "легитимности", так как авторитет OMG в компьютерном мире чрезвычайно высок. OMG представляет собой некоммерческую организацию, являющуюся содружеством разработчиков программного обеспечения и его потребителей, объединивших свои усилия для создания спецификаций этой технологии. В настоящий момент в OMG состоит более 800 членов, включая всех сколько-нибудь серьезных производителей программного обеспечения (и даже c недавнего времени Microsoft).

Объекты CORBA можно рассматривать как экземпляры (instances) некоторого метатипа, причем и метатип, и сами объекты существуют вне связи с конкретной программой на конкретном языке. Этот метатип в CORBA называется «интерфейсом».

Цель работы рассмотреть технологию CORBA

Предмет работы интерфейс компьютера.

Объект работы технология CORBA

Задачи работы:

Рассмотрим общие понятие о технологии CORBA;

Изучим особенности проектирования технологии CORBA.

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

ГЛАВА 1. ТЕОРЕТИКО-МЕТОДОЛОГИЧЕСКИЕ ОСНОВЫ CORBA

1.1. История CORBA

История CORBA начинается в октябре 1991 года, когда был представлен первый стандарт CORBA 1.0 консорциумом OMG. Object Management Group это открытая независимая организация международного масштаба, которую основали в 1981 г. одиннадцать компаний с целью создания общей среды для разработки объектно-­ориентированных приложений через разработку рекомендаций и детали­зированных спецификаций для объектно-ориентированного управления процессами.

Первые версии стандарта COREA (Component Object Request Enterprise Architecture) включали в себя базовые определения объектной модели CORBA, языка IDL, API, для динамического управления вызова объектов и репозитория интерфейсов, а также концепцию базового адап­тера объектов (BOA, Basic Object Adapter) посредником между объек­том и ORB. Единственным языком официально поддерживаемым пер­выми версиями стандарта стал язык программирования C. В 19972001 гг. были добавлены поддержки языков Cobol, Ada, Java. Кроме того бы­ли включены поддержка взаимодействия с DCOM, служба сообщений, минимальный стандарт CORBA, система CORBA реального времени и ряд других служб.[6]

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

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

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

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

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

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

Взаимодействие различных приложений возможно несколькими способами; обычно это называется межпрограммным интерфейсом [2].

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

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

Одним из таких шагов развития стало появление межпрограммных интерфейсов контейнерного типа (механизм DDE). Параллельно с этим появилась технология «клиент – сервер», которая позволила обслуживать большое количество прикладных программ (клиенты) одной программой (сервер). [12]

Также шло развитие межпрограммного интерфейса контейнерного типа, что позволило внедрять файлы из одной программы в другую. Возможные варианты видов взаимодействия приложений Конвертирование данных. Конвертирование файлов – это процесс изменения формата или свойств компьютерного файла. Для этого нужны специальные программы – конверторы – как правило, входящие в состав приложения. OLE-технология. OLE (Object Linking and Embedding) – технология, разработанная корпорацией «Майкрософт», служит для связывания и внедрения объектов в другие объекты или документы. OLE позволяет создавать объекты в одном приложении, а после открывать эти объекты в других приложениях. Отличие между связанными и внедренными объектами заключается в месте их хранения, а также способе обновления данных при их помещении в конечный файл.

Например, при помощи ОLE можно вставить таблицы Excel в документы Word, и наоборот. Приложения, поддерживающие технологию OLE, позволяют пользователю вызывать одно приложение из другого, не выходя из контекста интерфейса исходной программы. Используются принципиальные понятия «OLE-объект» и «OLE-контейнер». Вставка данных. При обычной вставке данных другого приложения через буфер обмена или специальным образом в приложение добавляются «мертвые» данные, которые не связаны ни с каким приложением. DDE-технология. Dynamic Data Exchange (DDE) – механизм взаимодействия приложений. Эта технология предоставляет доступ к данным через динамически действующие каналы, устанавливающие связь между приложением, принимающим данные (клиентом), и источником данных (сервером). Например, таблицы Excel могут быть источником данных для приложения Word, принимающего данные по каналу связи DDE [4].

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

Это самый низкий из уровней, представляющий базовое программное обеспечение; такое обеспечение отвечает за взаимодействие с базовыми аппаратными средствами. Программные средства такого типа, как правило, входят в состав базового оборудования и хранятся в постоянно запоминающих устройствах (далее ПЗУ). Все данные записываются на ПЗУ на этапе производства, и в процессе эксплуатации их нельзя изменить. Системный уровень программного обеспечения. Этот уровень программного обеспечения называют переходным.

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

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

1.2. Базовые понятия об объекте

Абстракции являются полезным средством уменьшения сложности. По мере усложнения программного обеспечения большую важность приобретает работа с использованием абстракций. Одной из таких интересных и полезных абстракций, исследованных в семидесятых годах, является Абстрактный Тип Данных (Abstract Data Type — ADT). ADT представляет собой инкапсуляцию структуры данных вместе с процедурами (операциями), которые этими данными манипулируют. Инкапсулированными называются данные, доступ к которым осуществляется через определенные процедуры. Среди языков, использующих ADT, можно назвать Modula-2 и Ada.

Сегодня ADT используются во многих языках, называемых объектно-ориентированными. Эти языки представляют ADT в виде объектов. Чтобы представить ADT как объект, необходимо нечто, динамически создающее новые копии, имеющие атрибуты (статусы) и поведение (действия). Объекты должны группироваться и делиться на категории по общим атрибутам и признакам поведения. Такая группировка необходима для администрирования всей совокупности членов в целом. Более того, необходимы критерии, по которым они могли бы обобщаться или подразделяться на категории. Такая потребность в обобщении или делении на категории возникает в группе, члены которой являются разнотипными.

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

Видимая часть Объекта называется его интерфейсом. Интерфейс объекта представляет собой протокол сообщений, используемых для запроса функциональности. Совокупность интерфейсов определяет поведение объекта. Интерфейс объекта состоит из имени объекта и набора методов. Методы состоят из двух частей: описания (signature) и реализация (implementation). описание состоит из имени метода, имен и типов параметров (в том числе возвращаемое значение) и исключения (exceptions). Реализация метода - это код, выполняемый для осуществления нужной операции.

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

Поведение объекта - это контракт, который предлагается потребителю. Именно контракт объекта гарантирует то, что вызов одного из его методов в соответствии с описанием приводит к определенному результату или исключению. Контракт состоит из описания и необходимых предусловий (Pre-conditions), инвариантов (invariants) и постусловий (post-conditions). Инварианты - это условия, которые всегда остаются истинными. предусловия - условия, правильность которых должна быть обеспечена перед вызовом метода. Постусловия - условия, правильность которых проверяется после вызова метода, и подтверждают правильность выполнения контракта.

Провайдером (поставщиком) контракта является сервер. Потребителем контракта является клиент. Клиент запрашивает сервис у сервера. Клиент вызывает метод у провайдера. Иногда это называют посылкой сообщения от клиента к серверу

1.3 Использование технологии CORBA

Технология CORBA – стандарт написания распределенных приложений, принадлежащий консорциуму Open Management Group (OMG). Благодаря этой технологии решается задача связывания различных объектов (программных приложений) для обмена данными. Объекты могут взаимодействовать друг с другом не зависимо от реализации и размещения. Клиент при помощи брокера запросов направляет свой запрос на определенный сервер, зная только интерфейс этого сервера. Сервер получает запрос, обрабатывает и направляет ответ клиенту с помощью того же брокера. Преимущества технологии CORBA заключаются кроме того в том, что она делает возможным повторное использование кода без необходимости его переписывать, например, на другой язык программирования. Наследование интерфейсов делает возможным расширение существующего функционала.

Object Request Broker или ORB – брокер объектных запросов, некое промежуточное ПО между объектами. Брокер отвечает за отправку запроса и получения ответа, поиск определенной реализации сервера для выполнения того или иного запроса и подготовку найденного сервера для выполнения запроса. [5]

Таким образом не предполагается осведомленность объектов о положении друг друга в системе. Object Services в CORBA – набор системных сервисов. Они обеспечивают дополнительную функциональность брокера. Например, сервис именования хранит ссылки на объекты системы CORBA (по имени объекта можно получить этот объект). Сервис жизненного цикла определяет управление жизненным циклом компонентов на шине. Сервисы условно можно поделить на две категории: те, которые уже функционируют поверх ORB без дополнительного встраивания, и те, которые необходимо встраивать в брокер отдельно.

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

1. Сервис жизненного цикла. Основополагающий сервис, определяющий жизненный цикл компонентов на шине (создание, удаление, копирование и т.д.).

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

3. Сервис долговременного хранения. Выполняет функцию сохранения объектов в долговременной памяти.

4. Сервис событий. Основная функция – поддержка асинхронного взаимодействия.

5. Сервис отношений. Предоставляет логические связи между компонентами.

6. Сервис контроля совместного доступа. Занимается управлением разделяемыми ресурсами, доступом к ним.

7. Сервис транзакций. Определяет множество моделей транзакций. 8. Сервис внешнего представления. Копирует объект и представляет его в виде файла, элемента базы данных, т.е. в виде какого-либо внешнего представления.

9. Сервис запросов. Обеспечивает выполнения запросов к объектам.

10. Сервис свойств. Служба, позволяющая ассоциировать свойства с компонентом.

Таким образом, сам брокер объектных запросов иногда не предоставляет полной функциональности без сервисов. Есть некие стандартные сервисы, которые употребляются очень часто и расширяют функциональность брокера. Консорциум OMG стандартизовал такие сервисы. Перейдем к следующему элементу. Основная задача Common Facilities (общих средств) – поддержка интерфейсов сервисов высокого уровня. Общие средства можно поделить на две категории: горизонтальные и вертикальные.

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

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

Но, это разделение весьма условно, так как клиент может являться сервером, а сервер клиентом. Например, при выполнении запроса, сервер может отправить запрос другому компоненту, и в этом случае сервер фактически является клиентом по отношению к другому серверу. Для коммуникации, приложения должны понимать друг друга. Они должны знать, какие действия совершает то или иное приложение, и дать понят другим, какие действия могут совершать они сами. Именно для этой цели был создан язык IDL (Interface Definition Language). IDL-определенные методы могут быть выполнены на любом языке, поддерживающем отображение из языка IDL. Соответственно язык IDL используется в среде компонентов для связи. Соответственно каждому компоненту необходимо отображать этот язык в свою реализацию.

Для этой цели существуют стабы и скелетоны (серверные и клиентские заглушки). Стаб (заглушка) действует в адресном пространстве клиентского приложения. Фактически, это пустые реализации для каждого метода интерфейса. Он является неким посредником. Его основная функция – упаковать параметры запроса в специальный формат и передать запрос скелетону сервера (через ORB).

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

Отложенный синхронный тип запроса предполагает некую совокупность двух предыдущих типов запроса. Здесь отправивший запрос компонент также продолжает работу, как при одностороннем типе запроса, но позднее он может заблокироваться до получения ответа, как при синхронном типе запроса. Универсальный межброкерный протокол (GIOP – General InterORB Protocol) поддерживает интероперабельность брокеров. Этот протокол не зависит от внутренней архитектуры брокера. Для 209 согласованного включения брокера в сеть, необходимо лишь наличие связанных с брокером объектов, которые способны принимать и посылать сообщения IIOP. Данный протокол является своеобразным каркасом.

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

ГЛАВА 2. ОСОБЕННОСТИ АРХИТЕКТУРЫ И ПОСТРОЕНИЯ CORBA

2.1 Применения технологии CORBA

Технология создавалась фирмой Microsoft как средство взаимодействия приложений (в том числе составных частей операционной системы) Windows, функционирующих на одном компьютере, с последующим развитием для использования в пределах локальной сети. Главная задача на момент создания обеспечение технологии Object Linking and Embedding (OLE 1.0). Характерно, что обмен данными между приложениями (Dynamic Data Exchange, DDE) первоначально строился не по COM-технологии, а с использованием механизма сообщений (messages). Развитие технологии идет по мере добавления новых возможностей. Как универсальная технология взаимодействия приложений COM начал использоваться с OLE 2.0 (1991). Концепция технологии неразрывно связана с ее реализацией. Появление новых возможностей это просто появление новых библиотек, функций API и утилит Windows. "Общий знаменатель технологии" двоичная структура объекта, хотя в настоящий момент существует язык описания структуры объекта Interface definition Language (IDL). [6]

Технология создавалась консорциумом OMG как универсальная технология создания распределенных систем в гетерогенных средах. OMG представляет собой некоммерческую организацию, являющуюся содружеством разработчиков программного обеспечения и его потребителей, объединивших свои усилия для создания спецификаций этой технологии. В настоящий момент в OMG состоит более 800 членов, включая всех сколько-нибудь серьезных производителей программного обеспечения (и даже c недавнего времени Microsoft). Первая спецификация CORBA появилась в 1991 г. Новые возможности официально считаются добавленными в CORBA в момент утверждения соответствующей спецификации. Как правило, в разработке спецификации участвуют крупнейшие специалисты в данной области.

Технология CORBA носит существенно более общий и универсальный характер, чем COM, что заложено в ее фундаменте. Опережение разработки спецификаций (по сравнению с реализациями) позволяет добиться более связной, целостной и гармоничной системы. С другой стороны, при разработке реального проекта нужно предварительно убедиться, что высококачественная реализация того или иного сервиса CORBA уже доступна (источниками проблем могут служить, например, Persistence Service и Security Service).

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

Данные вызова преобразуются в сетевой формат, сериализируются с помощью сгенерированных для объектов заглушек (stubs) и передаются от клиентских к серверным ORB. На сервере данные вызова десериализируются с помощью Фреймворка. В этом случае для объекта, где вы­полняется вызов, генерируются специальные скелетоны для правильного отображения данных. Данные, полученные при обработке вызова, пере­даются по цепочке обратно к клиентскому коду.

Архитектура CORBA. Глобальная структура CORBA приближает­ся к модели OMG, в рамках которой выделяются 4 группы архитектур­ных объектов ORB брокер объектных запросов; сервисы CORBA; сред­ства CORBA; прикладные объекты и приложения. [3]

Каждый уровень выступает как сервер для лежащего ниже уровня.

Брокер объектных запросов. CORBA ORB разрешает объектам на­ходить и обращаться к сервисам друг друга. ORB сложнее, чем вызовы удаленных процедур, в частности:

поддерживает не только статические, но и динамические вызовы мето­дов;

отъединяет интерфейс от его реализации;

является самоописываемой системой;

создает прозрачность относительно местоположения объектов.

Все ORB реализовывают как статические, так и динамические вызовы методов.

Сервисы CORBA. В качестве базовых сервисов в рамках CORBA используется пятнадцать сервисов:

• (Naming) Механизм, используемый объектами ORB для обнару­жения других ORB объектов.

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

(Event Service) Позволяет компонентам, находящимся на шине, реагировать на события в системе.

(Persistence Service) Служба, позволяющая создавать хранилища компонентов в различных средах.

(Concurrency Control Service) Представляет собой механизм, ко­торый позволяет выполнять блокировки от имени транзакций и потоков выполнения.

(Transaction Service) Позволяет организовывать двухфазное за­вершение транзакций для компонентов, при этом имеется возможность работать не только с простыми, но и с вложенными транзакциями.

(Relationship Service) Создает динамические ассоциации между компонентами, не связанными друг с другом.

(Extemalization Service) Обеспечивает стандартный способ для передачи данных компоненту и обратно, а также для пересылки самих компонентов по сети.

(Query Service) Позволяет выполнять запросы для объектов, в ча­стности, находить объекты по свойствам.

(Licensing Service) Позволяет отслеживать использование компо­нентов с целью получения платы.

(Properties Service) Предоставляет доступ к свойствам компонен­тов, позволяет менять состав и значение свойств.

(Time Service) Предоставляет интерфейсы для синхронизации ча­сов в распределенной среде и обеспечивает возможность управлять со­бытиями, привязанными к астрономическому времени.

(Security Service) Позволяет поддерживать инфраструктуру для обеспечения безопасности системы.

(Trader Service) Позволяет опубликовывать предлагаемые серви­сы и находить их.

(Collection Service) Позволяет создавать контейнеры, в которые можно помещать компоненты и формировать из них контейнеры.

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

Горизонтальные включают средства: USER interface (Интерфейс пользо­вателя); Information management (Информационный менеджмент). Воз­действие на систему предполагает большое количество утилит, которые реализуют функции системного администрирования. Управление зада­чами состоит из средств: управления потоками работ, программных агентов, контроля правил, автоматизации.

Обеспечение безопасности CORBA. Систему, которую обеспечи­вает безопасность спроектировали так, чтобы она не могла помешать пользователю во время создания приложений. В теории, объекты, кото­рые вы создали должны контактировать с ORB (который обеспечивает безопасность) без вашего участия. ORB предусматривает все необходи­мое для объектов, которые не знают о существовании сервиса безопас­ности (Security Service) и даже не имеют соответствующих интерфейсов. Это позволяет объектам легко пересекать границы сред, использующих различные механизмы обеспечения безопасности. [8]

Совокупность особенностей CORBA Security Service гарантирует в распределенных средах безопасность уровня B2, близкого к высшему уровню защиты. Чтобы выполнить такой важный уровень при работе в сети, следует составлять идентификатор с каждым клиентом. Для всех ресурсов был создан список прав доступа, обеспечены средства аудита и невозможность передачи прав доступа другим пользователям. Спецификация CORBA позволяет производителям ПО при необходимо­сти снижать уровень безопасности системы. Также CORBA определяет несколько стандартных профилей безопасности для контактирования между различными ORB.

Под «обеспечением безопасности» в CORBA подразумевается ре­шение (или попытка решения) очень многих проблем:

идентификация пользователя;

делегирование привилегий при последовательном вызове объектами методов друг друга;

предоставление прав доступа к ресурсам;

обеспечение аудита;

обеспечение юридической достоверности истории вызовов объектами друг друга;

кодирование передаваемых данных (если необходимо) и взаимодейст­вие с промышленными стандартами кодирования;

создание и администрирование профилей безопасности.

2.2. Сервисы CORBA

Сервисы CORBA - это широкодоступные объектные сервисы, которые пригодны для использования всеми объектами CORBA.

Ранее эти сервисы были известны как Общие Объектные Сервисы, и первоначально определялись в Обобщенной Спецификации Объектных Служб (COSS - Common Object Services Specification).

Теперь эти сервисы входят в сервисы CORBA, список которых включает:

Уведомление о событии

Устойчивость

Жизненные циклы

Присваивание имен

Управление параллелизмом

Связи

Транзакции

Совокупности

Экспорт

Время

Защищенность

Служба запросов

Лицензирование

Trading

Изменение управления

Свойства

Реальной альтернативой использования CORBA на текущий момент является DCOM фирмы Microsoft. Этой технологии мы посвятили уже немало статей, что может создать впечатление нашей глубокой приверженности именно DCOM. Однако это не так, и в дальнейшем мы планируем опубликовать материалы, посвященные CORBA, опираясь на ваши пожелания. Кстати, мы будем рады узнать ваше мнение о публикуемых материалах.

В последние 2-3 года резко возрос интерес к так называемым распределенным системам. Под распределенными системами обычно понимают программные комплексы, составные части которых функционируют на разных компьютерах в сети. Эти части взаимодействуют друг с другом, используя ту или иную технологию различного уровня от непосредственного использования сокетов TCP/IP до технологий с высоким уровнем абстракции, таких, как RMI или

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

Обеспечение масштабируемости систем, т.е. способности эффективно обслуживать как малое, так и очень большое количество клиентов одновременно.

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

Возможность непрерывной работы в течение длительного времени (так называемый режим 24x7, т.е. режим круглосуточной работы в течение недель и месяцев). [4]

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

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

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

Заметим, что далеко не для всех приложений вышеперечисленные требования являются существенными. Легко представить распределенную систему, которая функционирует на небольшом (до 100) количестве компьютеров, работающих в локальной сети, где нет проблем с перезапуском одного или двух-трех серверов в случае необходимости, а главными задачами, для решения которых используются распределенные технологии, являются задачи использования функциональности нескольких стандартных серверов приложений (например, текстовых процессоров, броузеров и электронных таблиц) в интересах клиентских задач. Необходимо иметь в виду, что термин "распределенные системы" относится к огромному числу задач самого разного класса.

Данный обзор содержит сравнительный анализ двух наиболее популярных и комплексных систем создания распределенных приложений, а именно, CORBA консорциума OMG и COM (DCOM, COM+) фирмы Microsoft. Этот обзор предназначен главным образом для менеджеров проектов, руководителей информационных служб и др., т.е. для тех, кому приходится принимать ответственные, "стратегические" решения. Вследствие этого, в нем будут отсутствовать чисто технические аспекты обоих технологий, которые интересны только для разработчиков.

Кроме того, при написании обзора не ставилась задача сделать окончательный вывод типа "... таким образом, CORBA (COM), бесспорно, лучше, чем COM (CORBA)". Связано это не с модной в наше время "политкорректностью" или отсутствием у автора своей точки зрения по этому вопросу. Дело даже не в том, что существуют определенные трудности с формализацией такого сравнения я мог бы представить результаты сравнительных анализов, в которых используются численные оценки (баллы), выставленные экспертами, весовые коэффициенты и прочее, что придает отчету серьезный и весомый вид. Дело в том, что COM и CORBA можно сравнивать только с учетом определенных допущений. Отказ от таких допущений легко позволяет получить какой угодно результат. Вот эти допущения:

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

Реализации же этой концепции могут сильно отличаться друг от друга по различным критериям, наиболее важным в том или другом случае. Inprise/Corel VisiBroker и Application Server, BEA WebLogic, Iona Orbix, Oracle Application Server и "картриджи" Oracle, IBM BOSS все эти продукты используют те или иные возможности CORBA. Технология Sun Enterpise JavaBeans создана поверх CORBA и использует такие ее возможности, как удаленный вызов объектов, службу имен, управление транзакциями. Реализация EJB фирмы Inprise связано с CORBA еще более тесным образом. Мы будем сравнивать COM и CORBA именно как концепции создания распределенных систем, а не как ту или иную их реализацию. [1]

При работе с реальным проектом необходимо учитывать область применения той или иной технологии. COM (как цельное и комплексное решение) способен функционировать только под Windows NT/Windows2000. Рассуждения о переносе COM на другие операционные системы в настоящий момент носят скорее рекламный характер. Ни компонентная модель COM (т.е. ActiveX), ни монитор транзакций (Microsoft Transaction Server, MTS) не способны работать нигде, кроме Windows, и сама Microsoft не проявляет никакой активности в этом напрвлении (вопросами переноса тех или иных элементов COM на другие платформы занимается консорциум Open Group). CORBA является многоплатформенным решением просто по определению.

Помимо чисто технологических аспектов, при принятии решения необходимо оценить затраты на закупку необходимого программного обеспечения, его сопровождения и обучение персонала. COM (в отличие от CORBA) официально является бесплатной технологией. Вы получаете все необходимое, просто приобретя, например, Windows NT Server. (Кстати, сам факт конкуренции дорогостоящей технологии с "аналогичной", но бесплатной, многое говорит об их технических возможностях).

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

Таким образом, главной задачей настоящего обзора является попытка помочь руководителю того или иного уровня принять квалифицированное решение в каждом конкретном случае. Поскольку и CORBA, и COM позиционируются соответственно OMG и Microsoft как универсальные технологии создания распределенных систем, мы будем оценивать и сравнивать их именно с этой точки зрения. Предполагается, что для проекта используется платформа Windows (в противном случае нечего рассматривать COM) и имеется достаточно средств для закупки основных стандартных частей той или иной реализации (иначе обсуждение CORBA теряет смысл).

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

обеспечение систем функционалом, находящихся в условиях ин­формационной и реализационной неоднородности, а также распределен­ности и автономности информационных ресурсов;

интеграция;

реинженерия;

миграция унаследованных;

повторное использование неоднородных информационных ресур­сов;

увеличение жизненного цикла систем.

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Абросимова, М.А. Информационные технологии в государственном и муниципальном управлении: Учебное пособие / М.А. Абросимова. - М.: КноРус, 2013. - 248 c.
2. Акперов, И.Г. Информационные технологии в менеджменте: Учебник / И.Г. Акперов, А.В. Сметанин, И.А. Коноплева. - М.: НИЦ ИНФРА-М, 2013. - 400 c
3. Вдовин, В.М. Информационные технологии в финансово-банковской сфере.Учебное пособие / В.М. Вдовин, Л.Е. Суркова. - М.: Дашков и К, 2012. - 304 c.
4. Венделева, М.А. Информационные технологии в управлении: Учебное пособие для бакалавров / М.А. Венделева, Ю.В. Вертакова. - М.: Юрайт, 2013. - 462 c.
5. Дарков, А.В. Информационные технологии: теоретические основы: Учебное пособие / А.В. Дарков, Н.Н. Шапошников. - СПб.: Лань, 2016. - 448 c.
6. Информационные системы и технологии: Научное издание. / Под ред. Ю.Ф. Тельнова. - М.: ЮНИТИ, 2016. - 303 c.
7. Информационные ресурсы и технологии в финансовом менеджменте: Учебник / Под ред.Г.А. Титоренко, И.Я. Лукасевича. - М.: ЮНИТИ, 2012. - 271 c.
8. Корнеев, И.К. Информационные технологии в работе с документами: Учебник / И.К. Корнеев. - М.: Проспект, 2016. - 304 c.
9. Купер А., Рейманн Р. М. Интерфейс. Основы проектирования взаимодействия. – М. : Питер, 2014. – 720 с
10. Машнин Т.С. Технология Web-сервисов платформы Java. БХВ-Петербург, 2012. – 455С.
11. Магда Ю. С. Программирование последовательных интерфейсов. – СПб. : БХВ-Петербург, 2015. – 292 с.
12. Платонов Ю.Г. Методы обеспечения интеграции распределенных слабосвязанных информационных систем: диссертация кандидата технических наук: 05.13.11. Новосибирск, 2014. 107 с.
13. Румянцева, Е.Л. Информационные технологии: Учебное пособие / Е.Л. Румянцева, В.В. Слюсарь; Под ред. Л.Г. Гагарина. - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013. - 256 c.
14. Светлов, Н.М. Информационные технологии управления проектами: Учебное пособие / Н.М. Светлов, Г.Н. Светлова. - М.: НИЦ ИНФРА-М, 2012. - 232 c.