лекция трпо. Лекция 16. Технология соrba. Цели ознакомить студентов с понятием технологии соrba. Ход занятия. План
 Скачать 150.22 Kb.
|
|
Лекция № 16. Технология СОRBA. Цели: ознакомить студентов с понятием технологии СОRBA. Ход занятия. План: Базовые понятия об объекте. Object Management Group. Единая архитектура CORBA. Базовые понятия об объекте. Абстракции являются полезным средством уменьшения сложности. По мере усложнения программного обеспечения большую важность приобретает работа с использованием абстракций. Одной из таких интересных и полезных абстракций, исследованных в семидесятых годах, является Абстрактный Тип Данных (Abstract Data Type — ADT). ADT представляет собой инкапсуляцию структуры данных вместе с процедурами (операциями), которые этими данными манипулируют. Инкапсулированными называются данные, доступ к которым осуществляется через определенные процедуры. Среди языков, использующих ADT, можно назвать Modula-2 и Ada. Сегодня ADT используются во многих языках, называемых объектно-ориентированными. Эти языки представляют ADT в виде объектов. Чтобы представить ADT как объект, необходимо нечто, динамически создающее новые копии, имеющие атрибуты (статусы) и поведение (действия). Объекты должны группироваться и делиться на категории по общим атрибутам и признакам поведения. Такая группировка необходима для администрирования всей совокупности членов в целом. Более того, необходимы критерии, по которым они могли бы обобщаться или подразделяться на категории. Такая потребность в обобщении или делении на категории возникает в группе, члены которой являются разнотипными. Таким образом, Объект является базовой вычислительной единицей, имеющей определенное поведение и атрибуты. Эти атрибуты определяют поведение объекта. Запросы, сделанные объекту, называются сообщениями или методами. Объекты могут поддерживать более чем один метод. Видимая часть Объекта называется его интерфейсом. Интерфейс объекта представляет собой протокол сообщений, используемых для запроса функциональности. Совокупность интерфейсов определяет поведение объекта. Интерфейс объекта состоит из имени объекта и набора методов. Методы состоят из двух частей: описания (signature) и реализация (implementation). описание состоит из имени метода, имен и типов параметров (в том числе возвращаемое значение) и исключения (exceptions). Реализация метода - это код, выполняемый для осуществления нужной операции. Интерфейс объекта описывает его поведение. Часто Интерфейс является синонимом типа интерфейса объекта. Однако, на самом деле, тип - это защищающий элемент, используемый при компиляции для проверки правильности его свойств. С типом связано понятие класса. Класс имеет внутреннюю часть, определяющую структурное качество, и внешнюю часть, содержащую группировку всех объектов класса и конструктор для каждого класса. Поведение объекта - это контракт, который предлагается потребителю. Именно контракт объекта гарантирует то, что вызов одного из его методов в соответствии с описанием приводит к определенному результату или исключению. Контракт состоит из описания и необходимых предусловий (Pre-conditions), инвариантов (invariants) и постусловий (post-conditions). Инварианты - это условия, которые всегда остаются истинными. предусловия - условия, правильность которых должна быть обеспечена перед вызовом метода. Постусловия - условия, правильность которых проверяется после вызова метода, и подтверждают правильность выполнения контракта. Провайдером (поставщиком) контракта является сервер. Потребителем контракта является клиент. Клиент запрашивает сервис у сервера. Клиент вызывает метод у провайдера. Иногда это называют посылкой сообщения от клиента к серверу. Базовые понятия Клиент-Сервер Существует четыре формы распределения вычислительных процессов, которые широко используются в распределенных вычислениях: клиент, сервер, равноправный участник и фильтр. Клиенты - обычно вычислительные сущности, потребляющие сервисные ресурсы. Серверы - обычно ресурсные сущности, реагирующие на запрос сервисов. Равноправные участники - обычно идентичны друг другу и могут сами выполнять запросы или обслуживать чужие запросы. Фильтр - процесс, расположенный в потоке между двумя процессами и выполняющий некоторую фиксированную функцию. Клиенты являются потребителями сервисов и ресурсов, провайдерами которых являются серверы. Равноправные участники могут потреблять и предоставлять сервисы и ресурсы, но в общем не специализированы. Фильтры иногда работают как клиенты или серверы, но чаще - как промежуточное звено в системах клиент-сервер. Специализация преследует цель уменьшить объем общего кода, который имеется во многих местах. Другими словами, подобная специализация имеет тенденцию к размещению кода приложения в одном месте, а не к “распылению” его по всему предприятию. Разделение задач между клиентами и серверами является сложным вопросом, поскольку в любом совместно используемом приложении распределение сервисов и их доступность должны быть целесообразным. К примеру, в традиционной системе клиент-сервер мы имеем GUI (графический интерфейс пользователя) со стороны клиента и базу данных - со стороны сервера. В этом случае обычно лучше всего передавать процесс вычисления клиенту. Это - пример типичной двухуровневой среды клиент-сервер. В случае с трехуровневой средой клиент-сервер обычно стараются перенести вычисления как можно дальше от клиента, оставляя ему ту часть приложения, которая необходима для работы GUI. Вся вспомогательная логика (бизнес-правила) и вычисления переносятся на какую-то другую платформу. Перемещение коммерческих правил на распределенный сервер приводит к их централизации, а значит, и к возможности их легкой модификации. Это уменьшает сложность работ по их обслуживанию и профилактике. Распределение может рассматриваться как фактор, зависящий от объема сообщений и частоты их передачи между сущностями. Чем выше частота передачи сообщений или их размер, тем выше потребность в как можно более “близком” размещении двух взаимодействующих сущностей. Разработка схем этого размещения выполняется с учетом результатов анализа частоты взаимодействия между двумя или более сущностями (называемого affinity analysis). Дополнительно принимаются в расчет качество сервисов и модели аварийных ситуаций. Если определенным запросам необходим быстрый ответ, другими словами - низкая латентность, то две сущности должны находиться рядом. Если часть сети между сущностями может быть серьезно повреждена, то вероятность такого повреждения следует уменьшить. Распределенные объекты Чаще всего распределенные объекты работают в конфигурации Клиент-сервер. Сами объекты являются серверами - они реагируют на запросы, предоставляют клиенту сервисы или ресурсы. Чтобы отличать такие серверы от процессов, работающих в системе клиент-сервер, будем говорить об объектах, которые работают со стороны сервера или клиента. Объекты со стороны сервера предлагают сервисы и ресурсы. Объекты же со стороны клиента их запрашивают. Они находятся во взаимодействии, так же, как и во всех объектно-ориентированных системах, где клиент и провайдер находятся на различных машинах внутри одной сети. Комбинация объектно-ориентированного подхода и идеологии клиент-сервер вбирает в себя лучшее из двух областей: абстрактность, которая уменьшает сложность системы и упрощает ее разработку; распределеннность в соответствии с параметрами аппаратного обеспечения и концентрация совместно используемых данных (и общего кода) в одном месте (удобном для их обработки). Распределение объектов по сети осуществляется после анализа эффективности взаимодействия между объектами (частота и размер сообщений). Кроме того, во внимание принимаются качество сервиса, модели аварийных ситуаций и степени детализации объектов. Степень детализации чаще всего определяется на практике. Создавать большой объект, предназначенный для совместного использования в сети, непрактично, поскольку он будет иметь очень высокое сродство по отношению ко всем клиентам. С другой стороны, к сервису, предусматривающему поиск информации (имя сервиса, директории, базы данных и т.д.), должен быть обеспечен доступ большого количества клиентов. Протокол сообщения (не спутайте с сетевым протоколом), или интерфейс, чрезвычайно важны в случае распределенных объектов. Интерфейс показывает, какие запросы может принять объект. В объектно-ориентированных системах чрезвычайно важно понятие контракта. Серверы предоставляют своим клиентам контракты, гарантирующие, предоставление (или наличие) какого-либо сервиса. Управляемые объекты Управление объектами в распределенной среде нуждается в некоторых аспектах, необходимых и для нераспределенных объектов. Перечислим их: для приема сообщений - протокол или интерфейс, описывающие принимаемые сообщения. то, с помощью чего объект может создаваться и инициализироваться - конструктор или фабрика объектов. хранилище объектов или расширенное управление жизненным циклом. Подход, используемый для реализации трех этих характеристик объектов, в общем, называется объектной моделью. Основная разница между Управляемыми Объектами и объектами вообще заключается в том, что управляемые объекты ссылаются на полномасштабное управление, в котором участвует большое количество объектов. Кроме того, как и все объекты, управляемые объекты должны поддерживать: инкапсуляцию наследование полиморфизм Каждый из трех параметров может быть достигнут различными способами (различными реализациями) и могут по-разному проявляться в различных объектных системах. Вкратце эти характеристики можно определить таким образом: Инкапсуляция — механизм абстракции, скрывающий реализацию от пользователя и предоставляющий доступ к атрибутам объекта, посредством управляющих процедур. Наследование — возможность определять новый класс на базе использования родительского класса с добавлением дополнительного поведения и (или) атрибутов. Полиморфизм — характеристика объекта, позволяющая одному и тому же сообщению инициировать различное поведение объекта в зависимости от его реального типа. Object Management Group Консорциум Object Management Group (OGM) был основан в 1989 году с целью распространения принятых стандартов управляемых распределенных объектов. Поначалу участниками консорциума являлись конечные пользователи и несколько производителей. Прежде всего, была разработана Архитектура Управления Объектами (Object Management Architecture - OMA), а затем - эталонная модель, до последней доработки называвшаяся Модель Core 92 (начиная с 1995 года - модель Core 95). Предпосылкой ее появления стало “принятие характеристик интерфейсов и протоколов”, которое позволило бы взаимодействовать приложениям, созданным на базе распределенных объектов (и с их использованием). Сегодня членами OMG, которая продолжает бурно развиваться, и в работе которой участвуют конечные пользователи и производители, являются свыше 500 компаний. OMG приобрела хорошую репутацию благодаря своей оперативности в принятии стандартов. OMG — это не обычная организация. Она не разрабатывает отраслевые стандарты, а вместо этого предлагает стандарты, уже созданные производителями, для использования в отрасли. То есть, ею предлагается принятие уже существующих стандартов. Это делается по единодушному согласию всех участников. Другой важной гранью деятельности OMG является то, что она заказывает предлагаемые стандарты, которые должны быть реализованы. OMG не склонно к принятию стандартов, которые хорошо смотрятся на бумаге, но использование которых на деле нецелесообразно. Если стандарт одобрен OMG, это значит, что кто-то где-то использовал его и определил, что он действительно работает. Архитектура Управления Объектами OMA состоит из четырех частей (рис.1): фундаментальный компонент, называемый Брокер Объектных Запросов (Object Request Broker), дополнительные сервисы, используемые разработчиками для управления распределенными объектами; общие сервисы, используемые многими различными приложениями, и распределенные приложения как таковые.  Рис. 1 ORB - аббревиатура от “Брокер Объектных Запросов”, предусматривает фундаментальные и основные действия с распределенными объектами и с управлением ими. Стандартом, который был принят для реализации этих целей, явился CORBA (Common Object Request Broker Architecture - Единая архитектура программы-брокера объектных запросов). Сервисы, используемые для разработки распределенных объектов, называются CORBA-сервисами. Поначалу они назывались общие объектные сервисы, поскольку не было уверенности, что всем распределенным объектам эти сервисы будут действительно необходимы. Эти сервисы предназначались для использования, в первую очередь, объектами распределенных приложений и назывались Общими Объектными Средствами Обслуживания (Common Object Facilities). Это связано с тем, что средства обслуживания расценивались как каркас, составленный из многих сервисов, которые, в свою очередь, представлялись еще более “гранулированными” сервисами. Сейчас они поменяли свое название на средства обслуживания CORBA. Приложения, составленные из таких “строительных блоков” являются объектными приложениями. Интерфейс и реализация Поведение объекта определяется его интерфейсом. Сервисы объекта декларируются его интерфейсом, детали реализации которых скрывает инкапсуляция. Таким образом, поведение объекта не зависит от реализации. До тех пор, пока объект обеспечивает определенное (его интерфейсом) поведение, нет необходимости знать способ его конкретной реализации. В CORBA понимание этого принципа является фундаментальным. ОМА определяет, является ли данная модель классической объектной моделью. Классической является модель, в которой все методы включены в класс. Она является контрастом по отношению к ряду других объектных моделей (таких как обобщенная объектная модель), в которой методы не указывают на классы. В CORBA все объекты определяются по интерфейсам, причем нет необходимости знать ограничения реализации, разумеется, если данные объекты обеспечивают объявленные сервисы. Чтобы это было возможным, в CORBA используется Язык Описания Интерфейсов (IDL — Interface Definition Language). В общем, IDL описывает интерфейсы объектов. Клиентам, для того, чтобы делать запросы, необходимо знать только интерфейс объекта. Серверы реагируют на запросы, сделанные их интерфейсу, в котором инкапсулированы подробности реализации (рис. 2).  Рис. 2 В CORBA интерфейс является эквивалентом класса. Запрашиваемый объект CORBA всегда передаются посредством ссылки на объект. Также, все обращения делаются через ссылку на объект или, сокращенно, Objref. Однако ОМА допускает некоторое нарушение этого по отношению к необъектным типам. Необъектные типы - это типы, не являющиеся объектами CORBA. Их аналоги встречаются и в С++, в котором тоже есть необъектные типы (примитивы С++ - short, int, long, double и т.д.). IDL не является языком программирования. Это язык для описания типов, в особенности типов интерфейсов. В нем нет операторов условного перехода, управления потоками или итераторов. Типы IDL CORBA IDL по форме очень близок к С++ — в нем поддерживаются базовые и составные типы, а объекты объявляются как интерфейсы, которые сходны с классами С++. Допуская некоторые неточности, таблица 1 представляет типы IDL и примерно сходные с ними типы. Однако, не используя грамматику IDL, можно неверно использовать приведенные выше типы. Гораздо лучше прочесть официальное описание языка (в инструкции к CORBA 1.1) или обратиться к примерам кода. Компилятор IDL Обычным примером кода на IDL является: interface Person { readonly attribute Gender sex; readonly attribute Date birthdate; attribute string name; }; interface Employee: Person { readonly attribute ssn; void addEmployer( Employer emp ); void deleteEmployer( Employer emp ); short numEmployers( ); Employer Employer( short index ) throws exOutofBounds; }; Атрибуты являются парами, к которым возможен доступ и которые могут быть изменены, если они не имеют префикса readonly (только для чтения). IDL в CORBA - это исходный код для IDL транслятора (обычно называемого компилятор). Транслятор IDL принимает на входе операторы на IDL, а затем переводит их на целевой язык. OMG позволяет в качестве целевого языка использовать следующие: С. С++ и Smalltalk. “Заглушки” и “заготовки” Целевой код, созданный компилятором IDL создается в паре - для распределения со стороны клиента и сервера. Распределение для клиента часто называется “заглушка” (stub), а для стороны сервера - “заготовка”(skeleton). Их можно статически подключить к коду клиента и сервера во время компиляции. Перед компиляцией “заготовки”, в ней необходимо описать реализацию каждого метода. “Заглушки” уже завершены (то есть, их описывать не надо). Для их использования приложению клиента просто надо вызвать из заглушки имеющийся в ней метод, что приводит к вызову сервиса объекта (рис.3).  Рис.3 Клиентское приложение обращается к “заглушке”, после чего запрос через “заготовку” передается серверу. При этом обмена самим объектами не происходит — происходит обмен ссылками. Таким образом, вместо того, чтобы перемещались объекты, происходит гораздо более целесообразный обмен ссылками. Единая архитектура CORBA На диаграмме (рис.4) приведена архитектура CORBA. “Заглушки” являются механизмом обращения к клиенту, а “заготовки” представляют собой интерфейс запросов со стороны сервера.  Рис.4 Архитектура CORBA показывает ее прозрачность по отношению к расположению объектов. Таким образом, реализация может находиться в одном и том же процессе с клиентом, в другом процессе или вообще на другой машине. CORBA организует обмен запросами (сообщениями) между клиентом и реализацией объекта. Доступность ORB-сервисов, которые могут быть запрошены любым клиентом или сервером, поддерживается ORB-интерфейсами. На вышеприведенной диаграмме показано нечто, называемое интерфейсом ВОА (Базовый объектный адаптер - Basic Object Adapter). Объектный адаптер необходим для поддержки различных стилей реализации объекта. ВОА в чем-то можно сравнить со швейцарским армейским ножом в том смысле, что он поддерживает множество сервисов при использовании минимума реализаций. Запуск ВОА В то время как интерфейс отвечает за тип реализации, объектный адаптер следит за “стилем” реализации объекта. Примером может служить критерий посылаемого запроса, по которому активизируется не работающий в данный момент объект. ВОА имеет четыре стиля активизации: По методу (per method) Распределенная активизация Нераспределенная активизация Постоянная (persistent) Активизация по методу - это стиль, когда новый сервер запускается каждый раз при обращении к методу объекта. Каждый вызов метода осуществляется на своем сервере. Серверами с распределенной активизацией являются серверы, поддерживающие множество активных объектов одновременно. Серверы с нераспределенной активизацией - серверы, поддерживающие только один активный объект. Такой сервер может обслуживать много обращений к методам в том случае, если все они принадлежат одному объекту. Постоянными называются серверы, не нуждающиеся в активизации и являющиеся активными все время. Они являются доступными до тех пор, пока работает система (или машина). Вероятнее всего, следующим объектным адаптером, который будет разработан, будет адаптер, определенный Группой управления объектными данными (ODMG - Object Data Management Group). Сейчас прилагаются усилия к стандартизации того, как OODBMS (объектно-ориентированные СУБД) будут работать с ORB в качестве системы постоянного хранения. Системы, подобные этим, имеют различную стилистику, что связано с различием в реализации основных объектов. Можно назвать: контроль и управление идентичностью объектов, работа в течение длительного времени, совпадение результатов работы, поставарийное восстановление или возврат. Дополнительные подробности можно найти в Object Database Standard: ODMG-93, Release 1.1. Вызов ORB Сделанный вызов проходит через ORB следующий путь (рис.5): Клиент вызывает метод посредством “заглушки”. ORB передает вызов ВОА, который активизирует реализацию. Реализация запрашивает у ВОА, является ли последний по-прежнему активным и доступным. ВОА передает запрос через “заготовку” реализации метода. Реализация через ORB возвращает результат (или исключение).  Рис. 5 Активизацию можно представить и другой схемой (рис.6.):  Рис. 6 Вызов слева от ORB (со стороны клиента) вызывает стек протокола. С правой стороны происходит работа со стеком протокола (далее, обслуживание вызова — “upcall”). Вызов удаленной процедуры (RPC) Вызов ORB имеет тесную связь с более ранней технологией - вызовом удаленной процедуры (Remote Procedure Call - RPC) RPCделает незаметным наличие сети, “маскируя” удаленный вызов под локальную процедуру. Компилятор RPC использовался для преобразования спецификации процедуры в пару “заглушек”: одну со стороны клиента и другую - со стороны сервера. На этом сходство оканчивается. Для компилятора RPC процедура является сущностью первого класса (в отличие от интерфейса объекта). В данном случае концепции класса, касающейся пакетирования и инкапсуляции семантически связанных вызовов, не существует. Короче говоря, процедурность обеспечена была, но не было объектной ориентации. Кроме того, схема адресации сети для обнаружения удаленной процедуры была несколько несовершенна. В случае с RPC необходим адрес машины и адрес порта, куда направлена процедура и по которому будет возвращен ответ. Этой схемы достаточно для подключения к хосту и отдельному серверу, но не для связи с объектом внутри этого сервера. Концептуально RPC происходит так, как показано на диаграмме (рис.7). Посредством распределения по портам сервер регистрирует порт. Сервер считывает содержимое порта и блокирует порт до получения ответа. Клиент запрашивает у распределителя портов хоста номер порта сервера. Распределитель портов возвращает номер порта. Клиент связывается с сервером через хост и номер порта. Сервер прекращает блокировку порта. Сервер возвращает результат или исключение.  Рис. 7 CORBA инкапсулирует сервисы в объекты и предлагает дополнительную гибкость при активизации как серверов, так и объектов. Она была спроектирована таким образом, чтобы необходимость использования RPC была исключена. Реализация ORB Одна из возможных реализаций показана на следующих диаграммах. Клиент обращается к демону (daemon - служебный процесс), являющемуся известным портом, расположенному на другой машине через TCP-сокет. Демон запускает процесс с сервера реализации. После запуска, процесс вызывает impl_is_ready() объектного адаптера. Либо, для нераспределенного сервера (определяется стратегией активизации), он вызывает obj_is_ready. После этого ВОА передает вызов метода экземпляру объекта. Объект обрабатывает запрос и возвращает результат клиенту. Заметьте, что ВОА работал с реализацией и демоном одновременно. После активизации объекта последующие вызовы в этом сеансе работы передаются напрямую реализации, минуя сервер. Доступ, прозрачный к локации  Одной из целей OMA является прозрачный доступ к объекту, независимо от его местоположения. В основном это означает, что программист может получить доступ к объекту, не зная, где именно в сети этот объект находится. CORBA скрывает все подробности местонахождения объекта при доступе к нему. Объект в текущем процессе и объект в другом процессе, выполняющемся на той же машине, будут выглядеть одинаково. Объект на второй машине тоже в целом не отличается от объекта на первой, несмотря на то, размещается ли он внутри вызывающего процесса или нет. Подробности о местонахождении объекта являются подробностями реализации и не нуждаются во включении в контракт объекта. Вследствие этого объект может находиться в любом месте сети и будет казаться локальным. Однако может случиться так, что при возникновении ошибки не всегда будет понятен статус ответа на запрос. Так, мог быть сделан запрос, затем возникла ошибка, и в результате мы не будем уверены в природе ошибки - связано ли это с получением объектом запроса или с результатом его выполнения. CORBA определяет условия выполнения как статус по завершении работы. Тогда статусом запроса может быть: “завершен”, “не завершен” или “возможно завершен”. Последний случай показывает о возможном возникновении ошибке. Функциональная совместимость ORB Поскольку CORBA не зависит от реализации, то необходим сетевой протокол для обеспечения взаимодействия различных реализаций. Общим интерфейсом, включающим описание типа и формата сообщений, необходимым для такого взаимодействия, является GIOP (General Inter-ORB Protocol - Общий Меж-ORB Протокол). Семантический уровень - IIOP (Internet Inter-ORB Protocol - Меж-ORB Протокол Интернет) используется для преобразования GIOP в TCP/IP. Такая комбинация GIOP и IIOP необходима для поддержки внешнего взаимодействия. Все поставщики ORB обеспечивают внешнюю совместимость этого протокола. Однако один протокол не может использоваться для всех целей, поэтому существует возможность преобразования GIOP в другие протоколы (такие как IPX или SNA). В случае, когда один набор интерфейсов не может обеспечить выполнение всех задач, в поле зрения попадают ESIOP (Environment Specific Inter-ORB Protocols - Inter-ORB протоколы, определяемые средой). Одним из ESIOP является протокол, базирующийся на DCE (distributed computing environment). В случае среды, когда протокол DCE может использоваться, DCE-CIOP (DCE Common Inter-ORB Protocol - Общий Inter-ORB Протокол DCE) играет роль склейки между ESIOP и TCP. Сервисы CORBA Сервисы CORBA - это широкодоступные объектные сервисы, которые пригодны для использования всеми объектами CORBA. Ранее эти сервисы были известны как Общие Объектные Сервисы, и первоначально определялись в Обобщенной Спецификации Объектных Служб (COSS - Common Object Services Specification). Теперь эти сервисы входят в сервисы CORBA, список которых включает: Уведомление о событии Устойчивость Жизненные циклы Присваивание имен Управление параллелизмом Связи Транзакции Совокупности Экспорт Время Защищенность Служба запросов Лицензирование Trading Изменение управления Свойства Реальной альтернативой использования CORBA на текущий момент является DCOM фирмы Microsoft. Этой технологии мы посвятили уже немало статей, что может создать впечатление нашей глубокой приверженности именно DCOM. Однако это не так, и в дальнейшем мы планируем опубликовать материалы, посвященные CORBA, опираясь на ваши пожелания. Кстати, мы будем рады узнать ваше мнение о публикуемых материалах. |