- •Государственный комитет рф по высшему образованию
- •0. Введение.
- •0.1. Идея общей интеграции.
- •0.2. Взаимодействие на уровне процедур.
- •0.3. Распределенные объекты.
- •0.4. Почему corba.
- •1. Поддержка на различных платформах.
- •2. Устойчивость стандарта.
- •3. Сложность освоения.
- •4. Поддержка повторного использования кода.
- •1. Постановка задачи.
- •1.1. Классические объекты.
- •1.2. Распределенные объекты в терминах спецификации corba.
- •1.3. Требования, предъявляемые к orb-у.
- •2. СпецификацияCorba.
- •2.1. Объектная модель.
- •2.2. Обзор архитектурыCorba.
- •2.3. Пример Брокеров Объектных Запросов.
- •3. Структура системы.
- •3.1. Уточнение деталей реализации.
- •3.2. Структура ядра системы.
- •3.3. Структура библиотеки.
- •3.4.Структура подсистемы обработки запросов.
- •3.5. Входные и выходные данные.
- •4. Протокол обменаGiop.
- •4.1. Особенности и цели протокола.
- •4.2. Обзор протоколаGiop.
- •4.3. Синтаксис Общего Представления Данных -cdr.
- •4.4. Формат сообщений протокола giop.
- •4.5. Транспорт для протоколаGiop.
- •4.6. Реализация взаимодействия по протоколуGiop.
- •4.7. Поддержка протоколаGiop в рамках отображения дляObject Pascal.
- •5. Разработка отображения для языкаObject Pascal.
- •5.1. Множественное наследование.
- •5.2. Статические экземпляры классов.
- •Initialization
- •Initialization
- •6. Технология написания и отладки приложений, работающих с распределенными объектами.
- •6.1. Этапы разработки программы.
- •6.2. Технология написания сервера объекта.
- •6.3. Технология написания клиента объекта.
- •6.4. Отладочные возможности библиотеки.
- •7. Пример программы, работающей с распределенными объектами.
- •7.1. Последовательность действий при создании объекта.
- •7.2. Объект библиотека.
- •7.3. Сервер объекта.
- •7.3. Клиент объекта.
- •7.4. Окончательный результат.
- •8. Анализ конкурентоспособности программного продукта.
- •8.1. Введение.
- •8.2. Ситуация на рынке.
- •8.3. Программные продукты - конкуренты.
- •8.4. Основные понятия.
- •8.5. Параметры для оценки эффективности.
- •8.6. Расчет эффективности.
- •8.7. Цена.
- •8.8. Конкурентоспособность.
- •8.9. Выводы и прогнозы.
- •9. Вопросы эргономики и их решение для создания комфортных условий труда программистов.
- •9.1. Введение.
- •9.2. Рабочее место программиста.
- •9.3. Вредные факторы, присутствующие на рабочем месте и их классификация.
- •9.4. Вредные производственные воздействия.
- •9.5. Эргономические требования.
- •9.6. Эргономика окружающей среды.
- •9.7. Экологическая безопасность.
- •9.8. Выводы.
0. Введение.
0.1. Идея общей интеграции.
В течение всего времени развития отдельных программных средств постоянно делались попытки унификации отдельных программных продуктов с целью обеспечения необходимой степени взаимодействия. Причем предлагаемые средства эволюционировали вместе с развитием методов и приемов программирования. В хронологическом порядке были предложены следующие подходы к написанию отдельных программ:
алгоритмический,
процедурный,
объектно-ориентированный,
то можно аналогично проследить следующие степени интеграции:
сетевые и прочие коммуникационные протоколы, совместимость на уровне исходного кода,
библиотеки подпрограмм и технология клиент/сервер,
распределенные объектные системы.
Поддержка коммуникационных протоколов предполагает реализацию одинакового алгоритма в приложениях, нуждающихся во взаимодействии между собой. При этом реализация алгоритмов может быть абсолютно произвольной. Совместимость на уровне исходного кода гарантирует работоспособность приложения на любой платформе, где имеются средства, необходимые для реализации стандарта на набор системных функций, типов данных, аппаратных средств.
0.2. Взаимодействие на уровне процедур.
Очевидно, что реализовывать одни и те же алгоритмы в каждом программном продукте нерационально и ведет в огромным затратам на поддержку работы этих продуктов (обновление в соответствии с выходом новой спецификации протокола, внедрение поддержки новых протоколов и т.д.). Поэтому базовые алгоритмы были реализованы в виде библиотек. Библиотека предполагает многократное использование кода, находящейся в ней различными программными продуктами, что существенно облегчает обновление версий и перекладывает задачу обеспечения взаимодействия с плеч разработчика конкретной программы на плечи разработчика данной библиотеки. В данном случае прослеживается ярко выраженный случай специализации. Реализация библиотек может быть совершенно разной - статические библиотеки, которые связываются с программой на этапе компиляции; динамически связываемые (DynamicLinked) в случае Windows или разделяемые (Shared) в случае UNIX библиотеки и т.д. Такой подход оказался очень удобным и библиотеки процедур стали неотъемлемой частью операционных систем. В современной операционной системе отводится большая роль поддержке всевозможных протоколов коммуникации. Появились специализированные библиотеки - драйверы (drivers) и сервисные приложения (services, daemons), которые обеспечивали взаимодействие прикладных программ по коммуникационных каналам. При этом конкретная программа использовала четко определенное множество функций, процедур, системных вызовов и зачастую не имела точного представления о протоколе, по которому происходило взаимодействие.
Сравнительно недавно появилась технология клиент/сервер, которая на данный момент имеет очень большую популярность. Эта технология позволяет строить распределенные приложения, в которых часть действий выполняется на сервере, а часть на клиенте. Недостатком такой технологии является все тот же процедурный подход и наличие массы стандартов на такое взаимодействие, затрудняющее взаимодействие между приложениями, написанными в соответствии с различными стандартами.