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

Информация о готовой работе

Тип: Дипломная работа  | Возможен только новый заказ  | Страниц: 137  | Формат: doc  | Год: 2000  |  

Содержание

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

Введение

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

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

Список литературы

Примечания:

срок доставки 2-4 дня