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

Технология CORBA (Описание и архитектура CORBA)

Содержание:

ВВЕДЕНИЕ

архитектура объектный запрос база данные

Технология CORBA, разрабатываемая с 1989 года консорциумом OMG (Object Management Group), является результатом работы ведущих специалисто. Четкий процесс стандартизации, включая аспекты взаимодействия реализаций CORBA от разных поставщиков (интероперабельность), независимость от языков программирования и операционных сред, фундаментальная поддержка ООП и многие другие уникальные характеристики, сделали CORBA ведущим стандартом в области инфраструктурного middleware.

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

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

Рассмотреть архитектуру комплекса CORBA;
Охарактеризовать языки программирования, используемые при разработке на базе CORBA;
Рассмотреть практические аспекты использования построения системы технологии CORBA для решения стандартных системных задач.

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

Объектом исследования данной курсовой работы является технология CORBA.

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

1 Теоретические аспекты функционирования технологии CORBA

1.1 1Описание и архитектура CORBA

Архитектура Common Object Request Broker (CORBA) - это стандарт, разработанный Группой управления объектами (OMG) для обеспечения взаимодействия между распределенными объектами. CORBA - это ведущее в мире промежуточное программное обеспечение, позволяющее обмениваться информацией независимо от аппаратных платформ, языков программирования и операционных систем. CORBA - это, по сути, спецификация проекта для Object Request Broker (ORB), где ORB предоставляет механизм, необходимый для взаимодействия распределенных объектов друг с другом, локально или на удаленных устройствах, написанных на разных языках или в разных местах в сети [2].

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

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

Рисунок 1 - основные компоненты, видимые в реализации CORBA.

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

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

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

Рисунок 2- Отправка клиенту запроса на сервер через ORB

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

1.2 Языки программирования, используемые при разработке на базе CORBA

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

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

В настоящий момент стандартизовано отображение языка IDL на шесть языков программирования — Ada, C, C++, Cobol, Java и Smalltalk. За основу IDL взят язык C++. Следующая таблица показывает соответствие основных концепций языков JAVA и C++ с языком IDL.

Таблица 1

Соответствие основных концепций языков JAVA и C++ с языком IDL

IDL	Java	C++
Module	Package	Namespace
Method	Public Interface	Pure abstract class
Method	Method	Member function

В модуле IDL представлены предоставляемые объектам услуги, реализации которых производятся потом на любом языке, поддерживаемом CORBA. Из таблицы 1 мы видим, что что модуль, также как и package в Java и namespace и С++, определяет собственное пространство имен[ 11, с.56].

Дальнейшее изложение будет посвящено последним двум конструкциям, интерфейсам и типам-значениям. Полное описание всех конструкций языка IDL можно найти в спецификации [2] и в руководстве [11, c. 81–132].

1.3 Интерфейсы

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

Для того чтобы определить объект, достаточно определить интерфейс. Создавая таким образом CORBA-объект, одновременно создается и объектная ссылка на него.

При вызове удаленного метода объекта передается объектная ссылка, и говорят по аналогии с С++, что «объект передается по ссылке».

Другой способ взаимодействия с удаленным объектом использует «передачу по значению».

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

Эти базы данных называются репозитариями интерфейсов (Interface Repository) [6].

Созданные таким способом объекты, могут продолжать существовать после завершения создавших их процессов. При реализации этого способа на Java возможна передача не только состояния объекта, но и при необходимости байт-кода его класса (подробно о сериализации см. [5]), что и было эффективно проделано в технологии Enterprise JavaBeans Типы-значения (Valuetype) служат для представления вышеизложенного способа взаимодействия. Интерфейсы Интерфейсы определяют новое пространство имен, не могут быть вложенными, но могут быть связаны друг с другом отношениями наследования (как простого, так и множественного).

Также нет возможности на уровне IDL задать интерфейс с состоянием, т.е. создать поля для интерфейсов, хотя CORBA-объект как правило имеет состояние.

Вот пример интерфейса, реализующего большинство его возможностей:

interface MyInterface {

//Определение синонимов типов

typedef string StringArray;

typedef long ResultType;

//Определение исключительных ситуаций

exception Wrong {}

//Определение констант

const string Header = “This is Header”;

//Определение атрибутов

attribute ResultType myQuery;

//Определение методов

string myMethod (in StringArray args) raises (Wrong);

void getTotal (out double i); };

При определении методов для каждого аргумента в списке необходимо указывать его признак — является ли параметр входным (in), выходным (out) или и тем, и другим (inout).

Это служит для явного задания того, кто — клиент или сервер — отвечает за выделение памяти под объекты. Входной параметр (in) передается от клиента серверу, за выделение и освобождение памяти для объекта отвечает клиент.

Выходной параметр (out) передается от сервера клиенту. Инициализаторы (initializers) являются аналогами конструкторов С++ или Java, в них они и отображаются компилятором. Все их аргументы должны иметь входной тип (in). CORBA не обеспечивает в отличие от С++ конструктора по умолчанию. Это означает, что при отсутствии явных инициализаторов (конструкторов, фабрик) невозможно создать экземпляр такого типа-значения при выполнении приложения. Типы-значения такого вида, т.е. те, которые имеют состояние, называются объектами с состоянием (stateful).

Есть абстрактные типы-значения (abstract), которые не содержат ни полей состояния, ни инициализаторов.

Интерфейс в CORBA – это логически сгруппированное сочетание методов и атрибутов. Каждому интерфейсу дается имя, уникальное в пределах одной распределенной системы. В отличие от СОМ в CORBA нет бинарного стандарта интерфейсов, а есть стандартный язык описаний IDL. Так сложилось, что языки с названием IDL есть в трех разных технологиях – OSF/DCE, Microsoft/COM и OMG/CORBA. Данные языки достаточно схожи, т.к. цель их создания эквивалентна, но OMG/IDL немного отличается от своих «однофамильцев».

Функциональность CORBA-объекта недоступна для клиента до того момента, пока в программе не появится объект, дающий возможность получить доступ к методам, обозначенным в IDL-интерфейсе. Данный объект (реализованный на C++, Java, C, Cobol, Ada, Smalltalk или пр.) именуется «сервантом» [1, c.24].

Исходя из применяемого языка программирования, серванты реализуются различным образом. Для объектно-ориентированных языков сервант является экземпляром (instance) определенного класса, методы которого обеспечивают необходимую функциональность. Подобный класс нередко именуется «классом реализации».

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

По своей сути сервант является «инкарнацией» CORBA-объекта. Связь между сервантами и CORBA-объектами является хотя и строго формализованной, но очень гибкой. Сервант может быть образован раньше или позже CORBA-объекта; один сервант способен «обслуживать» как один, так и несколько CORBA-объектов. Явное разделение циклов жизни CORBA-объектов и их сервантов (а именно серванты потребляют реальные ресурсы) – один из столпов, на которых основана высокая масштабируемость CORBA-приложений [1, c.45].

Помимо всего прочего, интерес в технологии CORBA представляет объектная ссылка.

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

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

Концептуально переменная типа «объектная ссылка» является указателем на «proxy-объект», присутствующий на стороне клиента и реализующий осуществление удаленных вызовов. Сам proxy-объект недоступен для программиста; это связано с тем, что его создание – задача не клиентского приложения, а самого ORB. Логически с каждым proxy-объектом сопоставлена отдельная объектная ссылка, и под копированием объектной ссылки понимается образование как нового proxy-объекта, так и настроенного на него нового «указателя». Естественно, в реальных реализациях физического копирования proxy-объекта не осуществляется в такой ситуации применяется механизм счетчика ссылок [1, c.26].

Необходимо помнить, что копирование (или уничтожение) объектных ссылок на стороне клиента воздействует только на клиентское приложение. Ошибочное ведение счетчика ссылок ведет к продолжению физического существования в клиентском приложении лишнего proxy-объекта. Никакого отношения к серверному объекту данные действия не имеют. И создание, и уничтожение сервантов или серверных CORBA-объектов – задача серверного приложения. Философия CORBA заключается в том, чтобы клиент посылал сообщения «установить связь с существующим объектом» и «разорвать с ним связь», а не «создать серверный объект» и «уничтожить его». Вместе с тем клиент способен инициировать создание Corba-объектов, вызвав у удаленного объекта специально предусмотренный для этого программистом (автором объекта) метод [3, c.44].

2 Практические аспекты использования построения системы технологии CORBA для решения стандартных системных задач

2.1 Основные этапы разработки

Основные этапы разработки CORBA включают в себя:

Создание IDL для определения интерфейсов приложения.

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

Преобразование IDL Переводчик IDL.

Обычно генерирует две совместные части для реализации клиента и сервера, код заглушки и код скелета. Код заглушки, сгенерированный для классов интерфейса, связан с клиентским приложением и предоставляет пользователю четко определенный интерфейс прикладного программирования (API). В этом примере IDL переведен на C ++.

Компиляция файлов интерфейса[ 11, с.185].

После перевода IDL на соответствующий язык, в данном примере C ++, эти файлы интерфейса компилируются и подготавливаются для реализации объекта.

Завершение реализации.

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

Скомпилируйте реализацию

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

Связывание приложения.

После того, как весь код объекта из шагов три и пять был скомпилирован, классы реализации объекта должны быть связаны с компоновщиком C ++. После соединения с библиотекой ORB, в этом примере, ORB express , создаются две исполняемые операции, одна для клиента и одна для сервера[ 9].

Запустите клиент и сервер.

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

В простейшем виде сервер должен выполнить следующее:

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

Определения программирования CORBA

В процессе разработки CORBA существует ряд уникальных терминов, специфичных для реализации CORBA[ 11, с.187].

Первая версия CORBA предоставила IDL и стандартные сопоставления только нескольким языкам, а по мере развития стандарта CORBA в CORBA 2.0 были добавлены дополнительные языковые привязки (в частности, C ++ и Java), а также общий протокол между ORB (GIOP). Когда клиент вызывает операцию CORBA, клиентский ORB отправляет сообщение GIOP на сервер.

Сервер ORB преобразует этот запрос в вызов объекта сервера, а затем возвращает результаты в ответе GIOP. Этот стандартный синтаксис передачи, определенный Группой управления объектами, обеспечивает совместимость взаимодействия ORB-ORB и предназначен для работы над любым транспортным протоколом, удовлетворяющим минимальному набору допущений[ 10, с.74].

Когда GIOP передается по TCP / IP, он называется Internet Inter ORB Protocol (IIOP). IIOP разработан, чтобы позволить различным поставщикам ORB взаимодействовать друг с другом. Примером такой функциональной совместимости является ситуация, когда существует связь между разработанным на предприятии ORB и небольшим приложением реального времени, использующим ORB реального времени.

2.2 Контрольный пример

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

Первый шаг состоит в написании IDL-описания разрабатываемого сервиса сервера myServer. IDL файл передается программисту клиентской стороны и становится мостом между языками.

module my {

interface myInterface {

string getInfo();

};

Это декларация интерфейса myInterface внутри пространства имен my. Интерфейс состоит из единственного метода, который возвращает информацию в формате string.

Второй шаг состоит в компиляции IDL для создания кода стабов и скелетов Java, который будет использоваться для реализации клиента и сервера. Инструмент от Sun, поставляемый с JavaIDL, называется idltojava: idltojava my.idl Idltojava создаст директорию my с несколькими Java файлами. _myInterfaceImplBase.java — это скелет, который мы будем использовать для реализации объекта сервера, а _myInterfaceStub.java будет использован для клиента[ 11, с.187]..

Существует Java представление IDL интерфейса в my.java и набор других файлов поддержки, например, для облегчения доступа к операции сервиса указания имен. Классы клиента и сервера будут находиться в пакете «my» [ 11, с.187]..

Реализация серверного объекта выполнена в классе myServer, который создает объект сервера, регистрирует его с помощью ORB, дает имя ссылке на объект, а затем ожидает клиентского запроса.

import remotetime.*;

import org.omg.CosNaming.*;

import org.omg.CORBA.*;

import java.util.*; import java.text.*;

// Реализация серверного объекта

class myServer extends _myInterfaceImplBase {

public String getInfo() {

return Date

Format.getTimeInstance(DateFormat.FULL). format(new Date(System.currentTimeMillis())); } }

Сервер реализует единственный метод интерфейса, getInfo(). Он возвращает точное время на сервере.

// Реализация удаленного приложения

public class myRemoteServer {

public static void main(String[] args) throws Exception {

// Создание и реализация ORB ORB orb =

ORB.init(args, null);

// Создание серверного объекта и регистрция myServer ServerObjRef = new myServer();

orb.connect(ServerObjRef);

// Получение корневого контекста имен

org.omg.CORBA.Object

objRef = orb.resolve_initial_references("NameService");

NamingContext ncRef = NamingContextHelper.narrow(objRef);

// Присвоение строкового имени ссылки на объект NameComponent nc = new NameComponent("myInterface", "");

NameComponent[] path = {

nc }; ncRef.rebind(path, ServerObjRef);

// Ожидание запроса клиента:

java.lang.Object sync = new java.lang.Object(); synchronized(sync) {

sync.wait(); } } }

После запуска сервера процесс входит в состояние ожидания.

Из-за того что это временное обслуживание, время жизнио граничено серверным процессом.

Код клиента:

import remotetime.*;

import org.omg.CosNaming.*;

import org.omg.CORBA.*;

public class RemoteClient {

public static void main(String[] args) throws Exception {

// Создание и инициализация

ORB: ORB orb = ORB.init(args, null);

// Получение контекста наименования:

org.omg.CORBA.

Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef);

// Разрешение ссылки на строковый объект для

// сервера времени:

NameComponent nc = new NameComponent("myInterface",""); NameComponent[] path = {

nc };

ExactTime timeObjRef = ExactTimeHelper.narrow( ncRef.resolve(path));

// Выполнение запроса к серверу:

String exactTime = timeObjRef.getInfo();

System.out.println(exactTime); } }

Первые несколько строк делают то же, что они делали в серверном процессе: инициализируют ORB и разрешают указатель на сервис указания имен. Далее необходима ссылка на объект для обслуживающего объекта, поэтому передается ссылка на строковый объект в метод resolve(), и приводиться результат к ссылке на интерфейс myInterface методом narrow(). В конце выполняется запрос к серверу и вызывается метод удаленного объекта getInfo()[ 11, с.187].

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

ЗАКЛЮЧЕНИЕ

Распределенная система, использующая CORBA, не ориентирована на применение конкретных операционных систем, двоичных стандартов, сетевых протоколов и языков программирования. Фактически, это единственная технология, которая обеспечивает возможность использования практически любых языков программирования и функционирование программного обеспечения практически на любых аппаратно-программных платформах. Интерфейс в CORBA – это логически сгруппированное сочетание методов и атрибутов. Каждому интерфейсу дается имя, уникальное в пределах одной распределенной системы. В отличие от СОМ в CORBA нет бинарного стандарта интерфейсов, а есть стандартный язык описаний IDL. Так сложилось, что языки с названием IDL есть в трех разных технологиях – OSF/DCE, Microsoft/COM и OMG/CORBA. Данные языки достаточно схожи, т.к. цель их создания эквивалентна, но OMG/IDL немного отличается от своих «однофамильцев».

В процессе написания курсовой работы были решены следующие задачи:

Рассмотрена архитектура комплекса CORBA;
Охарактеризованы языки программирования, используемые при разработке на базе CORBA;
Рассмотрены практические аспекты использования построения системы технологии CORBA для решения стандартных системных задач;

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

Иванов И.П., Самарский Д.А. Принципы построения систем управления делопроизводством с использованием технологии CORBA // Вестник МГТУ. Приборостроение. - 2002. - №2. - С. 95 - 111.
Орфали Р. Харки Д. Эдварде Дж. Основы CORBA: Пер. с англ. М.: Малип, 1999. - 625 с.
Орфали Р. Харки Д. Java и CORBA в приложениях клиент-сервер: Пер. с англ. М.: Лори, 2000. -712 с.
Причард Дж. COM и CORBA. Просто и доступно. – Лори, 2001. – 384 с.
Ревунков Г.И., Самарский Д.А., Постников В.М. Исследование систем распределенной обработки данных, построенных с использованием компонентных технологий (СОМ- и COBRA- технологии) // Интеллектуальные технологии и системы. - 2000. - №2. - С. 40 - 47.
Ревунков Г.И., Самарский Д.А. Исследование методов построения систем распределенной обработки данных с использованием объектных технологий // Интеллектуальные технологии и системы. - 2001. - №1. - С. 69 - 84.
Сырецкий, Г.А. Информатика. Фундаментальный курс. Том II. Информационные технологии и системы / Г.А. Сырецкий. - СПб.: BHV, 2012. - 848 c.
Трайнев, В.А. Новые информационные коммуникационные технологии в образовании: Информационное общество. Информационно-образовательная среда. Электронная педагогика. Блочно-модульное построение информационных технологий / В.А. Трайнев. - М.: Дашков и К, 2013. - 320 c.
Цимбал А. Сравнительный анализ технологий. СORBA и COM [Электронный ресурс]. - Режим доступа: http://www.interface.ru/fset.asp?Url=/bor- land/corbacom.htm ( дата обращения 24.11.2019)
Цимбал А. Аншина М. Технологии создания распределенных систем СПб: Питер, 2003. - 575 с.
Цимбал А. А. Технология CORBA для профессионалов. СПб.: Питер, 2001. - 624 с.