Рис Физический и логический обмен данными по сети 21 Рис Ахитектура процессов в распределенных системах

Вид материала

Содержание

Corba, dcom, ejb.
Регистрация типов интерфейсов
Клиентская часть.
Использование предкомпилятора IDL
Результат работы предкомпилятора JavaIDL
Реализация серванта и клиентской части приложения на уровне исходных кодов
Our_System.Summator theFirstCounter = new SummatorServant()
Компиляция исходных кодов
Общий вид распределенной системы с использованием стандартных служб.
Название службы

Подобный материал:

1 2 3 4 5 6 7

Современное ППО решает эту проблему в условиях, когда:

процессы ## 1 и 2 выполняются на разных машинах, работающих под управлением разных ОС.

соотв. программные компоненты были реализованы на разных языках

Вернуться к определению (процессы, на хостах, соединенных сетью, ППО, компонентный подход к проектированию, координированная обработка данных).

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

Для этих моделей характены:

компонентный подход к проектированию и реализации (программированию) системы, в основе которого лежит объектная технология программирования и четкое разделение интерфейсов объектов (абстрактных наборов связанных методов и свойств, не зависящих от выбора конкретного языка программирования) и их реализаций;
наличие специального связующего ПО (middleware), связывающего распределенные компоненты системы в единое целое, что является обобщением классической «клиент-серверной» архитектуры;
интероперабельность, т.е. обеспечение взаимодействия компонентов, реализованных на разных языках (например, C++ и Java) и функционирующих на различных платформах (Windows, Unix, Linux и т.д.), даже, возможно, в неоднородных компьютерных сетях;
многоразовость, т.е. возможность использования готового программного компонента в разных приложениях без необходимости внесения каких-либо изменений.

CORBA

CORBA (Common Object Request Broker Architecture) является спецификацией создания распределенных программных систем, развиваемой консорциумом OMG (Object Management Group) - некоммерческой организацией, включающей в настоящее время более 800 компа-ний. Лидерами OMG являются фирмы Oracle, IBM, Sun. Цель OMG - достижение «быстрого роста технологии объектов» через развитие архитектуры управления объектами OMА (Object Management Architecture). OMА является концептуальным базисом, на котором основаны спецификации OMG.

CORBA развивается как система открытых стандартов с 1989г. Первый итоговый доку-мент OMG был опубликован в 1991г. В 1992г. вышел его переработанный вариант, а в 1994г. появилась версия CORBA 2.0. В настоящее время используется CORBA 2.3-5. Ожидается по-явление версии 3.0.

На основе CORBA развивается компонентная модель объектов CCM (CORBA Component Model). Целью этого проекта является стандаризация процессов разработки распределенных систем, специализированных по отраслевому признаку - системы управления производством, финансами и т.п.

Активно развивается до сих пор.

CORBA

CORBA (Common Object Request Broker Architecture) является спецификацией создания распределенных программных систем, развиваемой консорциумом OMG (Object Management Group) - некоммерческой организацией, включающей в настоящее время более 800 компа-ний. Лидерами OMG являются фирмы Oracle, IBM, Sun. Цель OMG - достижение «быстрого роста технологии объектов» через развитие архитектуры управления объектами OMА (Object Management Architecture). OMА является концептуальным базисом, на котором основаны спецификации OMG.

CORBA развивается как система открытых стандартов с 1989г. Первый итоговый доку-мент OMG был опубликован в 1991г. В 1992г. вышел его переработанный вариант, а в 1994г. появилась версия CORBA 2.0. В настоящее время используется CORBA 2.3-5. Ожидается по-явление версии 3.0.

На основе CORBA развивается компонентная модель объектов CCM (CORBA Component Model). Целью этого проекта является стандаризация процессов разработки распределенных систем, специализированных по отраслевому признаку - системы управления производством, финансами и т.п.

Активно развивается до сих пор.

HLA

«Распределенная» революция в программировании началась в 80-е годы с проекта SIMNET (Simulation Network) агентства ARPA (Advanced Research Project Agency) американского Министерства обороны. Проект был нацелен на создание распределенных имитационных комплексов в военном деле.

Необходимость обеспечения надежных взаимодействий между удаленными компонентами таких систем привела в 90-е годы к двум основным типам архитектуры распределенных имитационных моделей – ALSP (Aggregate Level Simulation Protocol) и DIS (Distributed Inter-active Simulation).

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

В отличие от него DIS (ставший впоследствии стандартом IEEE 1278) ориентировался на имитацию взаимодействий отдельных единиц боевой техники (Vehicle level) в реальном времени.

В 1996 году Министерство обороны США инициировало разработку новой высокоуровневой архитектуры распределенного моделирования - HLA (High Level Architecture), обеспечившей интероперабельность имитационных моделей всех уровней между собой и с системами C4I (Command, Control, Communications, Computers, Intelligеnce), равно как поддержку многоразового использования компонент этих моделей.

Высокоуровневая архитектура HLA (High Level Architecture) для распределенного моделирования была разработана в интересах и при финансовой поддержке Министерства обороны США в целях обеспечения интероперабельности всех типов моделей и поддержки их многоразового использования.

Хотя создание HLA было проинициировано Министерством обороны США, с самого начала и до сих пор эта архитектура является открытым стандартом, который развивается и поддерживается подразделением DMSO (Defense Modeling & Simulation Office) Министерства Обороны США.

HLA быстро стала стандартом «де факто» для тренажеров и симуляторов в военных приложениях, что было обусловлено жесткими требованиями совместимости с HLA тренажерами, разрабатываемыми и используемыми Министерством обороны США. В настоящее время HLA находит все большее применение и в гражданской сфере при разработке симуляторов и тренажеров для тренировки персонала сложных технических систем в авиации, космонавтике, транспорте и т.п., становясь промышленным стандартом и в этой области.

В сентябре 2000 года процесс создания HLA был отмечен важным событием: версия 1.3 была принята в качестве стандарта IEEE 1516. Активно используется в промышленных симуляторах, MATLAB HLA Toolbox.

Процессы, иинтерфейсы, и проч потроха.

Cut&Paste как пример различных реализаций стандартизованного интерфейса ! Буфер обмена, как аналог «ППО».

Рисунок «круг» (OS, ППО) как среда общения фрагментов одного процесса или нескольких процессов.

Java. Драматическая борьба того «как надо делать программные системы» с «как бы это побыстрее продать».

в 1988 году фирма Sun провозгласила: "Сеть - это компьютер". имелась в виду сеть, на которой работала система Билла Джоя Network File System (NFS), включавшая в себя TCP/IP.

А 6 лет назад, в 1990 году, Билл Джой был известен, как один из величайших умов в программировании, но постоянно проигрывающий Microsoft. На конференции PC Forum Эстер Дайсон в 1990 году он говорил, атакуя Microsoft: "Мы добавляем все больше возможностей к старым системам и сложность растет экспоненциально. У меня десять различных пакетов, и они взаимодействуют 10 х 10 различными способами. Выскакивают всевозможные сюрпризы, а поскольку все эти пакеты не работают совместно, мои возможности возрастают всего лишь аддитивно. У меня есть такая возможность и есть этакая, а в комбинации они не работают. А я хочу видеть систему, где сложность возрастает линейно, а мощность - экспоненциально". Гейтс набирал высоту, Билл Джой, похоже, уходил в тень и утрачивал влияние. В 1990 году Джой удалился в лесистые высоты Аспена в Колорадо, выполняя перспективные исследования для Sun. Его разговоры о небольших программах и управляемых бытовых устройствах не имели, казалось, отношения к работе компании.

Основная проблема в том, что массового (типичного) потребителя не интересуют проблемы массового разработчика. Да и потребителей в тысячи раз больше. Поэтому «неправильно сделанный» (плохо расширяемый, не переносимый, и т.д.) продукт, функциональность которого покрывает 90% потребностей 90% пользователей будет иметь успех. (Правило 80/20, 80% MS Office, используют 20% возможностей).

Тем не менее, Java указывает ВЕРНОЕ направление развития, что фактически подтвердила MS, переводя весь свой зоопарк на .NET, и С#.

Немного подробнее о различных стандартах ППО.

CORBA, DCOM, EJB.

Web-сервисы. GRID-сервисы. .NET.

Жизненный цикл объектов.

Разработка

Проектирование (интерфейсов). Сравнить IDL и WSDL.

Принятие решения о выборе между статическими или динамическими режимами вызовов методов (на клиентской стороне) и обработки вызовов на серверной стороне (универсальность<>производительности, зависит от возможностей ППО).

Генерация стандартизованных стабов/скелетонов (исходных кодов на выбранных языках высокого уровня); специальные средства (предкомпиляторы).

Реализация серверных фрагментов.

Регистрация типов интерфейсов

Функционирование

Серверная часть

Запуск «серверного» процесса (с черными кружочками).

Активация удаленных объектов и, возможно, регистрация их на специальной службе.

Обработка заявок.

Остановка, возможно, с сохранением состояния.

Клиентская часть.

Обеспечение клиентской программы «адресом» нужного ей объекта (объектная ссылка); в виде файла или «имени» (идентификатора) на службе регистрации.

Вызов удаленного объекта.

Этапы разработки РВС (CORBA)

Существует большой выбор комплектов разработчика систем на базе CORBA от различных поставщиков и ориентированных на разные языки программирования. Но везде присутствуют следующие необходимые элементы:

предкомпилятор языка IDL;
набор файлов на языке IDL, содержащих описание стандартных интерфейсов и служб (согласно стандартам OMG);
набор готовых компонентов - реализация ядра ORB и некоторого подмножества стандартных служб CORBA (в минимальной конфигурации - служба наименований и репозиторий интерфейсов).

Проектирование интерфейсов на языке IDL;
Использование предкомпилятора IDL;
Реализация серванта и клиентской части приложения на уровне исходных кодов
Компиляция исходных кодов

Проектирование интерфейсов на языке IDL.

Например, если мы хотим создать сервис, играющий роль сумматора, то описание соответствующего интерфейса на языке IDL может выглядеть следующим образом:

module Our_System {

interface Summator {

attribute string name;

long getSum();

long addValue( in long increment );

};

};

Пример описания интерфейса на языке IDL.

Интерфейс на Summator имеет один текстовый атрибут name, который мы будем интерпретировать как «имя» объекта, и два метода:

getSum() - метод без параметров возвращающий текущее значение счетчика в виде целого числа;
addValue( in long increment ) - метод с одним передаваемым (на это указывает ключевой слово in ) целочисленным параметром (возможно - отрицательным), который следует прибавить к текущему значению счетчика; метод возвращает новое значение счетчика.

Следует сказать, что отличие атрибута от метода достаточно условно и, как мы увидим, на уровне реализации практически ничем не отличается.

Использование предкомпилятора IDL

Обязательным элементом любого комплекта разработчика является специальная программа, т.н. предкомпилятор с языка IDL.

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

Например, если воспользоваться JavaIDL - простейшим комплектом разработки CORBA приложений на языке Java, то следует отдать команду

idlj -fserver -fclient Sum.idl,

где Sum.idl - файл, содержащий текст, приведенный на Рис.13..

В результате будут созданы несколько файлов на языке Java, назначение которых комментируется в следующей таблице:

Имя файла (все с расширением .java)	Назначение	В каком фрагменте кода понадобится
Имя файла (все с расширением .java)	Назначение	серверный	клиентский
Summator	Базовый класс для объектов типа "сумматор".	x	x
SummatorOperations	Абстрактный класс (в Java - типа interface) содержащий отображение методов и атрибутов интерфейса на язык Java, но без реализации.	x	x
_SummatorImplBase	Фрагмент кода, содержащий скелетон интерфейса.	x
_SummatorStub	Фрагмент кода, содержащий представитель (стаб) интерфейса.		x
SummatorHelper	Специальный вспомогательный класс, содержащий набор методов, необходимых клиентской стороне (обычно - для манипуляций с объектными ссылками)		x

Результат работы предкомпилятора JavaIDL

Чтобы понять каким образом произошло "языковое связывание" в данном случае, приведем содержание файла

SummatorOperations.java:

SummatorOperations.java:

package Our_System;

public interface SummatorOperations

{

String name ();

void name (String newName);

int getSum ();

int addValue (int increment);

}

Пример отображения интерфейса IDL на язык Java.

Таким образом (см. Рис.13.):

имя модуля превратилось в название пакета Java;
наличие атрибута name привело к появлению двух методов - для чтения текущего значения атрибута (String name()) и для задания нового значения (void name (String newName));
методы getSum и addValue превратились в "обычные" методы, причем IDL тип данных long преобразовался в тип int.

Предкомпилятор позаботился о том, чтобы установить правильные взаимосвязи между всеми вышеперечисленными файлами, а также "подключил" стандартные классы, реализующие ядро JavaIDL ORB и соответстветствующий Object Adapter. Достаточно привести определения этих классов, присутствующие в каждом файле:

класс (интерфейс) CORBA объекта Summator в файле Summator.java:

public interface Summator extends SummatorOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity

класс _SummatorImplBase скелетона в файле _SummatorImplBase.java:

public abstract class _SummatorImplBase extends org.omg.CORBA.portable.ObjectImpl implements Our_System.Summator, org.omg.CORBA.portable.InvokeHandler

класс _SummatorStub стаба в файле _SummatorStub.java:

public class _SummatorStub extends org.omg.CORBA.portable.ObjectImpl implements Our_System.Summator

Реализация серванта и клиентской части приложения на уровне исходных кодов

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

Для реализации серванта можно создать класс SummatorServant, наследуя готовый класс _SummatorImplBase:

public class SummatorServant extends _SummatorImplBase,

в котором придется определить поведение всех функций, объявленных в интерфейсе SummatorOperations (см. Рис. 2.).

Для создания экземпляра CORBA объекта типа Summator, (а фактически - для создания реализации CORBA объекта) достаточно объявить переменную этого класса (в языке Java это будет объектная ссылка) и воспользоваться оператором new для создания экземпляра объекта заданного типа (стандартная схема создания экземпляров объектов в Java):

Our_System.Summator theFirstCounter = new SummatorServant();

При необходимости можно создать несколько экземпляров таких объектов.

Мы пропустили несколько технических деталей: подключение к ядру ORB; активация и подключение к Объектному Адаптеру; регистрация на нем созданного объекта; "опубликование" его объектной ссылки, чтобы сделать объект доступным для клиентских частей системы.

В клиентской программе, необходимо предусмотреть механизм получения объектной ссылки на нужный экземпляр CORBA объекта. Для этого удобнее всего воспользоваться CORBA службой Именований (Naming Service), о которой мы поговорим позднее.

Когда объектная ссылка получена (в Java она является ссылкой на объект класса org.omg.CORBA.Object), ее необходимо преобразовать к типу Summator. Для этого и нужен класс SummatorHelper (см. Рис. 1.). Соответствующие фрагменты кода имеют вид:

org.omg.CORBA.Object ior; //ссылка на нетипизированный объект

// присваивание нужного значения ссылке ior

...

//Объявление переменной типа Summator и приведение ior

//к нужному типу при помощи специального метода narrow

//класса Helper

Our_System.Summator theProxyForTheFirstCounter = Our_System.SummatorHelper.narrow (ior)

Простейший пример фрагмента клиентского кода

Теперь можно использовать объект theProxyForTheFirstCounter для вызова методов объекта theFirstCounter из серверной части кода.

Компиляция исходных кодов

На этом заключительном этапе необходимо откомпилировать исходные тексты всех частей распределенного приложения, с использованием результатов работы предкомпилятора (см. 1.1.1).

Результат компиляции естественно зависит от используемого языка. Например, в при использовании Java, распределенное приложение будет представлять собой набор файлов *.class (возможно - упакованных в архивы *.jar). И для их запуска нужно использовать среду исполнения Java. Если часть распределенного приложения представляет собой Java апплет, то для запуска понадобится браузер.

В случае использования языка C (C++) результатом работы этого этапа будут либо исполняемые файлы *.exe, либо библиотеки динамической компиляции *.dll (на платформе Microsoft) или *.so (на платформе Unix, Linux).

Общий вид распределенной системы с использованием стандартных служб.

Стандартные службы CORBA

Название службы	Краткая характеристика
Naming Service (Служба именования)	Наиболее распространенная служба, позволяющая давать имена CORBA объектам и создавать иерархическое доменное пространство имен. Она предназначена для поиска объектов (получения объектной ссылки) по их именам.
Trading Object Service (Объектный трейдер)	Одна из самых первых служб. Позволяет объектам "опубликовать" сервисы, которые они предоставляют и зарегестрировать их в репозиторях этой службы. Предназначена для поиска объектов (получения объектной ссылки), основываясь на опубликованных ими сервисах.
Query Service (Сервис запросов)	Результат инициативы Sybase, IBM, SunSoft и Taligent - основных разработчиков систем управления объектными базами данных. Позволяет находить объекты, удовлетворяющие определенным критериям. Использует специальный язык запросов типа SQL.
Collections Service (Сервис контейнеров объектов)	Позволяет управлять группами объектов, объединяя их в контейнеры: очереди, списки, массивы, деревья и т.д.
Relationship Service (Сервис сообщений)	Позволяет устанавливать и управлять отношениями между объектами. Например, владения, содержания (включения), ссылки.
Life Cycle Service (Сервис жизненного цикла объекта)	Помогает управлять созданием, копированием, перемещением и удалением объектов. В случае связанных между собой объектов использует интерфейсы Relationship Service.
Time Service (Сервис времени)	Помогает синхронизировать время в распределенных системах. Необходим в задачах "реального времени". Использует стандарт UTC (Universal Time Coordinated) и совместим с существующим системами, например, X/Open DCE Time Service
Event Service (Сервис событий)	Представляет собой пример MOM (Message Oriented Middleware) Позволяет организовать взаимодействие компонентов распределенной системы посредством асинхронного обмена сообщениями.
Notification Service (Расширенный сервис событий)	Расширяет Event Service, добавляя новые возможности. Например, поддержку "типизированных" событий, имеющих внутреннюю структуру; фильтрацию рассылаемых сообщений и возможность управлять этими фильтрами.
Object Transaction Service (OTS) (Сервис объектных транзакций)	Позволяет множеству распределенных объектов взаимодействовать в рамках "неделимых транзакций", даже при наличии серьезных аппаратных или программных сбоев. Чрезвычайно полезен для работы с базами данных. Поддерживает "вложенные" транзакции.
Concurrency Service (Сервис контроля совместного доступа)	Позволяет объектам координировать обращения к совместно используемым ресурсам посредством механизма блокировок.
Persistent Object Service (Сервис долговременного хранения)	Предназначена для сохранения и восстановления состояния объекта, в ситуации временного отключения серверного процесса. Появился по инициативе IBM и SunSoft. Существующие реализации тесно связаны с реляционными базами данных.
Externalization Service (Сервис внешнего представления)	Принцип работы напоминает механизм сериализации (serialization) объектов в языке Java, когда текущее состояние "бинарное" объекта записывается в потоковый файл или, наоборот, восстанавливается из файла.

Кроме этого, крупные фирмы-разработчики постоянно предлагают свои специализированные службы, например Telecom Log Service.

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

Blog

Рис Физический и логический обмен данными по сети 21 Рис Ахитектура процессов в распределенных системах

Содержание