Технологии построения распределенных вычислительных систем (RPC, COM, CORBA).

Концепция распределенных вычислений – разделение ресурсов при выполнении к/либо задачи в сети. Мех-зм удаленного вызова процедур или RPC предназн. для создания распре-х приложений. Суть: часть программы выполняется на одном узле, часть – на другом. З-ча - сделать технологию т.о., чтобы вызов удал. проц. выглядел как локальный вызов. Примитивы службы реал-ся как семейство удал-х проц-р. Удаленное взаимод-е определяется в декларации интерфейса – это набор только определений процедур удаленной службы. Для вызова к имени нужен список парам-в и тип рез-та- это декларация инт-са. Исполнитель объявляет инф-ю об услугах, а user исп-ет эту инф-ю; в ней сод-ся декларация инт-са , имена и парам-ы услуг. Описание инт-са – с пом-ю языка IDL. Характерными чертами вызова локальных процедур являются: 1) Асимметричность, то есть одна из взаимодействующих сторон является инициатором; 2) Синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.

Проблемы: 1) разное адресное пространство вызывающей и вызываемой процедуры – проблема именования и связывания – связывание имени процедуры с адресом ее выполнения (В отличие от локального вызова удаленный вызов процедур обязательно использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах); Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. 2)разные архитектуры машин и разные поддерживаемые типы данных; 3) отказы клиента или сервера (при аварии вызывающей процедуры удаленно вызванные процедуры станут «осиротевшими», а при аварийном завершении удаленных процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожидать ответа от удаленных процедур.);

Принципы решения проблем:

1) исп-ние общих справочников имен (спец. сервис\каталог, как в RPC и CORBA или сист-й реестр как в COM); 2)единые языки межмашинного представления данных (XDR), 3) маршаллинг – преобраз-е данных к формату XDR(процесс упаковки данных и преобраз-ия их в стандартный вид перед передачей по сети так, чтобы данные могли пройти через сетевые ограничители.); 4)различ. семантики выполнения, как средство минимизации негативного эффекта отказов – введение доп-х пар-ров состояния и диагностики в вызовах процедур;

Объектный вариант RPC – технологии COM,CORBA.

Технология COM заключ-ся в том, что из одного приложения можно получить доступ к методам и интерфейсам объектов, реализованных в др. Основа технологии – интерфейсы. Интерфейс расм-ся как абстрактный класс (содержит только декларацию методов, без реализации). По умолчанию все методы виртуальные, все инт-сы – наследники базового класса IUnKnown. Технология связана с COM-объектами. Один такой объект реализует 1 и > интерфейсов; приложения, реализующие COM-объекты, это COM-серверы – они могут содержать > 1 COM-объекта. С каждым COM-объектом связан генератор класса – спец. объект создающий экземпляры СОМ-объектов. Генератор обслуживает несколько СОМ-объектов. Данные обо всех COM – объектах содержит библиотека типов (инт-сы об-тов, св-ва и методы, кол-во и тип арг-тов каждого метода). У биб-ки типов есть редактор, позволяющий автоматически управлять одним приложением из другого; основное преимущество – автоматический маршаллинг. Библ-ка в сист-м реестре находит прогу, кот реализует класс идент-ров. Технология COM могла бы быть универсальной и платформо-независимой, но закрепилась в основном на операционных системах семейства Microsoft Windows.

Основное отличие техн-и CORBA от COM в том, что это не фирменная вещь. Задача CORBA — осуществить интеграцию изолированных систем, дать возможность программам, написанным на разных языках, работающим на разных узлах сети, взаимодействовать друг с другом так же просто, как если бы они находились в адресном пространстве одного процесса. Основное место – брокер объектной реализации, выполняющий поручения процесса – клиента. Задачи брокера: 1) прием от клиента инф-и о запрашиваемом методе; 2) поиск реализации объекта в распределенной среде; 3) активизация объекта или уничтожение порожденного экземпляра объекта – при необх-ти.; 4) передача экземпляру объекта параметров запроса; 5) получение и передача параметров обратно клиенту. Суть: есть два процесса – клиент и сервер. Взаим –е осущ-ся ч.з. протокол межброкерного взаимодействия IIOP. Его функции: принять рез-т, передать запрос, оповестить клиента об исключ. ситуации. На клиенте инт-с объекта прекомпилируется и т.о. создается код заглушки. На стороне сервера заглушка – это заготовка программы. Связывание осущ-ся ч.з. заглушки; т.о. ссылка в поле клиента связ-ся с целевым объектом. На серверные заглушки возлаг. функции маршаллинга. GIOP - абстрактный протокол в стандарте CORBA, обеспечивающий интероперабельность(способность системы к взаимодействию с другими системами) брокеров.

Основные элементы архитектуры RPC: при вызове процедуры управление передается stubа она передает параметры RPC runtime(ядро), кот. упаковывает параметры, определяет куда их передать. на сервере RPC runtime заталкивает параметры в стек, stub преобразовывает параметры к общему виду и передает их на другую сторону.

Типовые компоненты информационных систем, базовые логические
архитектуры ИС.

ИС- комплекс прог, ориентированных на сбор,хранение, поиск и обработку текстовой и/или фактографической инфы.,В осн. Работающих в режиме диалога с пользователем. ИС=3логики +3 сервиса. Сервисы готовые, а логики предмет разработки. Типовые комп-ты –аппаратные сервисы, системное ПО, комп-ты прикладной среды, ПО промежуточного слоя(ср-ва тассировки транзакций), приложения предметной области и логики.

Логические компоненты ИС:

AL – логика доступа. Определяет правила, по которым данные извлекаются из хранилища – набор SQL-запросов. BL – бизнес-логика. Определяет, что делает система с полученными данными, правила, по кот данные обраб-ся. PL – логика представления. Определяет, как данные представляются пользователю. FS – файловый с. - cервис, кот предоставляетя файловой системой. DS – система хранения данных. Реализуется СУБД. PS – аппаратура, которая реализует интерфейс (монитор, принтер). «Толстый» клиент (вся логика у клиента). «+»: низкая нагрузка на сеть. «Тонкий»: м/ обраб-ть данные BL, дополнительно вводят триггеры(хранимые процедуры без пар-ров), кот м/ менять состояние БД при опред усл, или хранимые процедуры(именованная, параметризированая конструкция, опред-ая на языке SQL, или на нек его расширении, компилир-ся на стороне сервера, а выз-ся из прикл-ой проги с указанием пар-ров)- позволяют обр-ть данные на сервере. «+»: т.к. на клиенте минимум ф-ций, то в случае чего менять 1 комп, а не всю ИС.

Однозвенная архитектура«+»:легко администр-ть,дешево,легкое транспортирование. «-»:высокая нагрузка на сервер, плохая масштабируемость (много польз-лей не добавить).