Брокер Объектных Запросов

ID работы - 686229
программирование (дипломная работа)
количество страниц - 138
год сдачи - 2012

---

СОДЕРЖАНИЕ:

---

0. Введение. 4
0.1. Идея общей интеграции. 4
0.2. Взаимодействие на уровне процедур. 4
0.3. Распределенные объекты. 5
0.4. Почему CORBA. 6
1. Постановка задачи. 9
1.1. Классические объекты. 9
1.2. Распределенные объекты в терминах спецификации CORBA. 10
1.3. Требования, предъявляемые к ORB-у. 11
2. Спецификация CORBA. 13
2.1. Объектная модель. 13
2.2. Обзор архитектуры CORBA. 17
2.3. Пример Брокеров Объектных Запросов. 25
3. Структура системы. 27
3.1. Уточнение деталей реализации. 27
3.2. Структура ядра системы. 28
3.3. Структура библиотеки. 30
3.4. Структура подсистемы обработки запросов. 31
3.5. Входные и выходные данные. 32
4. Протокол обмена GIOP. 35
4.1. Особенности и цели протокола. 35
4.2. Обзор протокола GIOP. 36
4.3. Синтаксис Общего Представления Данных - CDR. 37
4.4. Формат сообщений протокола GIOP. 40
4.5. Транспорт для протокола GIOP. 41
4.6. Реализация взаимодействия по протоколу GIOP. 43
4.7. Поддержка протокола GIOP в рамках отображения для Object Pascal. 47
5. Разработка отображения для языка Object Pascal. 51
5.1. Множественное наследование. 51
5.2. Статические экземпляры классов. 58
6. Технология написания и отладки приложений, работающих с распределенными объектами. 64
6.1. Этапы разработки программы. 64
6.2. Технология написания сервера объекта. 65
6.3. Технология написания клиента объекта. 66
6.4. Отладочные возможности библиотеки. 66
7. Пример программы, работающей с распределенными объектами. 69
7.1. Последовательность действий при создании объекта. 69
7.2. Объект библиотека. 69
7.3. Сервер объекта. 70
7.3. Клиент объекта. 73
7.4. Окончательный результат. 74
8. Анализ конкурентоспособности программного продукта. 76
8.1. Введение. 76
8.2. Ситуация на рынке. 76
8.3. Программные продукты - конкуренты. 77
8.4. Основные понятия. 79
8.5. Параметры для оценки эффективности. 80
8.6. Расчет эффективности. 83
8.7. Цена. 84
8.8. Конкурентоспособность. 85
8.9. Выводы и прогнозы. 85
9. Вопросы эргономики и их решение для создания комфортных условий труда программистов. 87
9.1. Введение. 87
9.2. Рабочее место программиста. 88
9.3. Вредные факторы, присутствующие на рабочем месте и их классификация. 89
9.4. Вредные производственные воздействия. 89
9.5. Эргономические требования. 92
9.6. Эргономика окружающей среды. 95
9.7. Экологическая безопасность. 96
9.8. Выводы. 96
Заключение. 97
Приложение А. Подборка статей из периодической литературы. 99
А.1. Журнал PC Week RE N 40 `96 от 8.10.96 100
А.2. Журнал Computer Week N 40 `96 31.10.96-6.11.96 101
А.3. Журнал Computer Week N 41 `96 7.11.96-13.11.96 102
А.4. Журнал PC Week RE N 48 `96 от 3.12.96 103
Приложение Б. Листинг методов WriteLong и PutLong. 104
Б.1. Листинг метода WriteLong. 104
Б.2. Листинг метода PutLong. 104
Приложение В. Фрагменты исходных текстов 106
В.1. Модуль “baseio.h” - файл заголовков подсистемы обработки запросов. 106
В.2. Модуль “baseio.cpp” - реализация подсистемы обработки запросов. 110
В.3. Модуль “giop.pas” - абстрактные классы для работы по протоколу GIOP. 120
В.4. Модуль “giopimp.pas” - реализация поддержки протокола GIOP. 122
Приложение Г. Графические листы 128
Г.1. Лист 1. Структура ядра системы. 129
Г.2. Лист 2. Структура библиотеки. 130
Г.3. Лист 3. Структура подсистемы обработки запросов. 131
Г.4. Лист 4. Схемы алгоритмов кодирования сообщения, запроса, ответа. 132
Г.5. Лист 5. Схема алгоритма кодирования значения произвольного типа. 133
Г.6. Лист 6. Этапы создания приложений с распределенными объектами. 134
Г.7. Лист 7. Пример: Библиотека. Разработка сервера объекта. 135
Г.8. Лист 8. Пример: Библиотека. Разработка клиента объекта. 136
Г.9. Лист 9. Исследование конкурентоспособности программного продукта. 137
Приложение Д. Использованная литература 138

---

ВВЕДЕНИЕ:

---

0.1. Идея общей интеграции.
В течение всего времени развития отдельных программных средств постоянно делались попытки унификации отдельных программных продуктов с целью обеспечения необходимой степени взаимодействия. Причем предлагаемые средства эволюционировали вместе с развитием методов и приемов программирования. В хронологическом порядке были предложены следующие подходы к написанию отдельных программ:
1. алгоритмический,
2. процедурный,
3. объектно-ориентированный,
то можно аналогично проследить следующие степени интеграции:
1. сетевые и прочие коммуникационные протоколы, совместимость на уровне исходного кода,
2. библиотеки подпрограмм и технология клиент/сервер,
3. распределенные объектные системы.
Поддержка коммуникационных протоколов предполагает реализацию одинакового алгоритма в приложениях, нуждающихся во взаимодействии между собой. При этом реализация алгоритмов может быть абсолютно произвольной. Совместимость на уровне исходного кода гарантирует работоспособность приложения на любой платформе, где имеются средства, необходимые для реализации стандарта на набор системных функций, типов данных, аппаратных средств.
0.2. Взаимодействие на уровне процедур.
Очевидно, что реализовывать одни и те же алгоритмы в каждом программном продукте нерационально и ведет в огромным затратам на поддержку работы этих продуктов (обновление в соответствии с выходом новой спецификации протокола, внедрение поддержки новых протоколов и т.д.). Поэтому базовые алгоритмы были реализованы в виде библиотек. Библиотека предполагает многократное использование кода, находящейся в ней различными программными продуктами, что существенно облегчает обновление версий и перекладывает задачу обеспечения взаимодействия с плеч разработчика конкретной программы на плечи разработчика данной библиотеки. В данном случае прослеживается ярко выраженный случай специализации. Реализация библиотек может быть совершенно разной - статические библиотеки, которые связываются с программой на этапе компиляции; динамически связываемые (Dynamic Linked) в случае Windows или разделяемые (Shared) в случае UNIX библиотеки и т.д. Такой подход оказался очень удобным и библиотеки процедур стали неотъемлемой частью операционных систем. В современной операционной системе отводится большая роль поддержке всевозможных протоколов коммуникации. Появились специализированные библиотеки - драйверы (drivers) и сервисные приложения (services, daemons), которые обеспечивали взаимодействие прикладных программ по коммуникационных каналам. При этом конкретная программа использовала четко определенное множество функций, процедур, системных вызовов и зачастую не имела точного представления о протоколе, по которому происходило взаимодействие.
Сравнительно недавно появилась технология клиент/сервер, которая на данный момент имеет очень большую популярность. Эта технология позволяет строить распределенные приложения, в которых часть действий выполняется на сервере, а часть на клиенте. Недостатком такой технологии является все тот же процедурный подход и наличие массы стандартов на такое взаимодействие, затрудняющее взаимодействие между приложениями, написанными в соответствии с различными стандартами.
0.3. Распределенные объекты.
Теория программирования продолжала развиваться, на смену процедурному программированию пришло объектно-ориентированное, появились объектно-ориентированные языки программирования. Естественно, возникло желание осуществлять взаимодействие между отдельными объектами, которые находятся в разных приложениях с таким же удобством, как и с объектами, которые существуют внутри одного приложения. Наибольшую популярность получили объектные модели COM (Component Object Model), реализованная Microsoft в клане операционных систем Windows и SOM (System Object Model), реализованная IBM в операционной системе OS/2. Эти две модели требуют обязательную поддержку со стороны операционной системы и первоначально существовали в локальном варианте, что означало возможность взаимодействия только приложения, выполняемых на одном вычислительном устройстве в рамках одной операционной среды. Впоследствии появились варианты обеих моделей для взаимодействия распределенных между несколькими вычислительными устройствами объектов. Соответствующие модели получили названия DCOM и DSOM соответственно (D- от Distributed).
Спецификой модели SOM/DSOM является то, что эта модель является одним из расширений спецификации CORBA (Common Object Request Broker Architecture - Обобщенная Архитектура Брокеров Объектных Запросов), которая определяет, каким образом два приложения могут взаимодействовать между собой, причем не налагается никаких ограничений ни на местоположение объектов, ни на платформы или операционные системы, под управлением которых работают эти приложения.
0.4. Почему CORBA.
На данный момент наблюдается стремительно возрастающий интерес к идее взаимодействия распределенный объектов и программным решениям, которые делают такое взаимодействие возможным, об чем свидетельствуют, например, материалы приведенные в Приложении A. Компании-лидеры в области разработки реляционных СУБД, такие как Oracle и Informix делают попытки создания объектно-ориентированных систем управления базами данных. Тема объектно-ориентированных систем управления базами данных является отдельной темой для исследований и далее не обсуждается.
Из двух основных имеющихся на данный момент и конкурирующих между собой объектных моделей - CORBA и COM - CORBA выгодно отличается от модели COM по нескольким параметрам:
1. Поддержка на различных платформах.
Сейчас существует большое количество программных продуктов разных производителей, удовлетворяющих спецификации CORBA и способных взаимодействовать между собой. Эти продукты способны работать под управлением разных операционных систем, предоставляя теоретическую возможность тотального объединения (на практике это пока еще невозможно ввиду неполной реализации требований стандарта CORBA). Реализация объектной модели COM на данный момент существует только для платформ Windows 95/NT и обеспечивается исключительно фирмой Microsoft.
2. Устойчивость стандарта.
Стандарт CORBA является достаточно устойчивым стандартом, основы которого определены и существуют в течение нескольких лет. Это является результатом сотрудничества более чем 500 (!) участников консорциума OMG (Object Management Group), который и является автором стандарта CORBA. Ожидается устойчивость и актуальность текущей спецификации в течение ближайших 8-10 лет, что дает разработчикам программных средств, использующих данную объектную модель некие гарантии актуальности их программ в ближайшем будущем. В то же время, как показывает практика, Microsoft существенно изменяет свои стандарты каждые 2-3 года, вызывая этим устаревание программных продуктов, ориентирующихся на предыдущие стандарты или версии стандартов.
3. Сложность освоения.
Очень показательными являются следующие цифры, взятые из [1]. Минимальный набор документации, необходимый для полного ознакомления и использования объектной модели COM включает в себя руководство разработчика (925 страниц), справочное руководство по API (650 страниц), руководство по OLE Automation (400 страниц). В тоже время спецификация CORBA определяется в документе, состоящем из 178 страниц. Такая картина является частично является следствием слишком ускоренного развития технологии OLE/COM с попытками охватить большое количество всевозможных дополнительных технологий. В то же время спецификация CORBA задает лишь основные, необходимые для обеспечения взаимодействия стандарты, полностью оставляя реализацию всех дополнительных сервисов на разработчика конкретной системы.
4. Поддержка повторного использования кода.
Большинство реализаций спецификации CORBA поддерживают наследование между объектами, позволяющей вызывать для производного объекта все методы, доступные в базовом. Модель COM не поддерживает прямого наследования. Вместо этого допускается делегирование, то есть реализация в объекте определенного набора функций. Тем не менее в каждом объекте эти функции должны быть заново реализованы.
Учитывая все приведенные характеристики, объектная модель, устанавливаемая спецификацией CORBA является более приемлемым кандидатом для реализации. Кроме того, реализация объектной модели COM ввиду всей ей объемности возможна только как результат работы большого коллектива разработчиков и, вероятно, изначально не способна конкурировать с реализациями, произведенными фирмой Microsoft на соответствующих платформах - фирма Microsoft склонностью к утверждению и развитию своих собственных стандартов, игнорируя при этом все остальное. Поэтому и было принято решение о разработке системы, удовлетворяющей спецификации CORBA.

---

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

---

1. Thomas J. Mowbray, Ron Zahavi, The Essential CORBA: System Integration Using Distributed Objects, (Wiley, 1995)
2. Robert Orfali, Dan Harkey, Jery Edwards, The Essential Distributed Objects/Survival Guide, (Wiley, 1996).
3. CORBA: Common Object Request Broker Architecture and Specification.
4. AP-526. Application Note. Optimizations For Intel’s 32-Bit Processors, Intel, October 1995, Order No 242816-001.
5. Журнал Монитор-Аспект 2.94 стр. 80-84.
6. Журнал Мир ПК 10.96 стр. 10-20.
7. Журнал PC Magazine/RE 12.96 стр. 25-49.
Цена: 8000.00руб.