- •Государственный комитет рф по высшему образованию
- •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. Выводы.
4.1. Особенности и цели протокола.
Протоколы GIOP иIIOP допускают взаимодействие между различнымиORB-ами независимо от платформ, на которых они выполняются, операционных систем, под управлением которых происходит взаимодействие и прочих аппаратно- и программно-зависимых аспектов. При разработке этих протоколов преследовались следующие цели:
Распространенность.ПротоколыGIOP иIIOP разрабатывались с учетом доступного широко распространенного и гибкого транспортного механизма (TCP/IP) и задает минимум дополнительных протоколов, необходимых для передачи запросов между отдельнымиORB-ами.
Простота.Помимо прочих требований, протоколGIOP сделан максимально простым. Его простота допускает возможность реализации взаимодействия по этому протоколу практически в любой системе.
Масштабируемость.ПротоколGIOP/IIOP должен поддерживаться как отдельнымиORB-ами, так иORB-ами, объединенными в сеть на уровнеInternet и, возможно, шире.
Небольшие затраты на реализацию.Реализация поддержки протоколовGIOP/IIOP должна потребовать минимальных затрат как в плане инженерного проектирования, так в плане распространения готовыхORB-ов.
Общность.В то время какIIOP изначально определен поверх протоколаTCP/IP, сообщения, которыми происходит обмен в рамках протоколаGIOP специально разработаны для реализации поверх любого протокола, который базируется на установленном между сервером и клиентом соединении.
Архитектурная независимость.СпецификацияGIOP делает минимальные предположения об архитектуре агентов, которые поддерживают обмен данными по этому протоколу. СпецификацияGIOP считаетORB некой системой с неизвестной архитектурой.
Подход конкретного ORB-а к обеспечению поддержки протоколаGIOP/IIOPне определен. Например,ORB может принятьIIOP в качестве внутреннего протокола, использовать его только для внешнего обмена, используя для обмена в рамках самогоORB-а какие-то дополнительные средства коммуникации или выбрать нечто среднее между этими двумя крайностями. Все что требуется отORB-а - это чтобы существовало нечто способное принимать и отправлять сообщения по протоколуIIOP.
4.2. Обзор протоколаGiop.
Спецификация протокола GIOP состоит из следующих элементов:
Определение Общего Представления Данных(Common Data Representation - CDR). CDR - это способ кодирования типов данных, определенных вIDL в низкоуровневое представление, пригодное для передачи их по имеющимся каналам связи междуORB-ами.
Формат сообщения протокола GIOP. Сообщения протоколаGIOP обеспечивают нахождение объекта, отработку запросов, а также простейшее управление каналом коммуникации.
Предположения о транспорте.СпецификацияGIOP описывает общие предположения, которые делаются при рассмотрении любого сетевого транспортного слоя, который может быть использован для обмена сообщениями протоколаGIOP. Также описываются общие принципы управления соединением.
Спецификация IIOP добавляет к спецификации протоколаGIOP следующий пункт:
Транспорт для сообщений протокола IIOP. СпецификацияIIOP описывает, каким образом агенты могут установить соединение по протоколуTCP/IP и использовать его для передачи сообщений протоколаGIOP.
Протокол IIOP не является самостоятельной спецификацией - это специализированное отображение протоколаGIOP поверх транспортного слояTCP/IP.СпецификацияGIOP (без элементов, специфичных дляIIOP)может рассматриваться как самостоятельный документ, являющийся базовым для обеспечения в будущем отображения на новые транспортные протоколы.