Файл: Распределенная технология обработки информации (Архитектурное построение систем распределенной обработки информации).pdf

Модель RPC – это одна из основных моделей, применяемых в программном обеспечении системной поддержки. Впервые она была применена в двухъярусных системах типа "клиент/сервер": клиент вызывает процедуру, работающую на сервере. Интересно, что для клиента этот вызов не отличим от вызова локальной процедуры. Модель RPC ввела сами понятия клиента (вызывающая программа) и сервера (программа, реализующая удаленно вызываемую процедуру). В модели также были представлены другие концепции, широко применяемые до сих пор: языки описания интерфейсов, службы ведения имен и каталогов, динамическое связывание, интерфейс службы.

При применении модели RPC синхронизация, установление связи, передача параметров и результата – все делается скрытно от клиента. Это первая модель, которая позволила добиться прозрачности и межъязыковой интероперабельности, отказаться от явного обмена сообщениями с помощью протоколов нижних уровней.

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

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

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

Модель RPC считается ядром большинства распределенных систем.

Часто модель RPC используется как низкоуровневый примитив для реализации более сложных форм взаимодействия.

Рис. 2.2 Разработка распределенных приложений с помощью модели RPC.

Процесс удаленного вызова выглядит следующим образом:

– процесс на машине клиента вызывает процедуру на машине сервера;

– процесс клиента приостанавливается;

– на машине сервера запускается процесс выполнения вызванной процедуры;

– результат передается на машину клиента;

– процесс клиента возобновляется.

Основное преимущество модели RPC - и клиент, и сервер не знают об удаленности вызова.

2.2 Модель RMI

Термин модель RMI расшифровывается как удаленный вызов метода. Это механизм, который позволяет объекту, находящемуся в одной системе (JVM), получать доступ / вызывать объект, запущенный в другой JVM.

RMI используется для создания распределенных приложений; он обеспечивает удаленную связь между Java-программами. Это предусмотрено в пакете java.rmi.

Как правило в приложении RMI мы пишем две программы: серверную (на сервере) и клиентскую (на клиенте). Внутри серверной программы создается удаленный объект, и ссылка на этот объект становится доступной для клиента (с использованием реестра), а клиентская программа запрашивает удаленные объекты на сервере и пытается вызвать его методы.

В следующих пунктах представлены основные аспекты работы приложения RMI:

– когда клиент выполняет вызов к удаленному объекту, он принимается заглушкой, которая в конечном итоге передает этот запрос в RRL;

– когда RRL на стороне клиента получает запрос, он вызывает метод invoke объекта remoteRef. Он передает запрос в RRL на стороне сервера;

– RRL на стороне сервера передает запрос в Skeleton (прокси-сервер на сервере), который, наконец, вызывает требуемый объект на сервере;

– результат передается обратно клиенту.

Всякий раз, когда клиент вызывает метод, который принимает параметры на удаленном объекте, они объединяются в сообщение перед отправкой по сети. Эти параметры могут быть примитивного типа или объектов. В случае примитивного типа параметры объединяются и к нему прикрепляется заголовок. Если параметры являются объектами, они сериализуются. Этот процесс известен как сортировка.

На стороне сервера упакованные параметры разделяются, а затем вызывается требуемый метод. Данный процесс известен как демаршаллинг.

Реестр RMI - это пространство имен, в котором размещены все объекты сервера. Каждый раз, когда сервер создает объект, он регистрирует этот объект в RMIregistry (используя методы bind или reBind). Они зарегистрированы с использованием уникального имени, известного как имя привязки.

Чтобы вызвать удаленный объект, клиенту нужна ссылка на этот объект. В это время клиент выбирает объект из реестра, используя его имя привязки (используя метод lookup).

В итоге, можно выделить основные цели RMI:

– минимизирование сложность приложения;

– сохранение безопасности типов;

– распределение сборки мусора;

– минимизирование разницы между работой с локальными и удаленными объектами.

2.3 Технология CORBA

CORBA (Common Object Request Broker Architecture - общая архитектура брокера объектных запросов). Один из ключевых принципов архитектуры CORBA, обеспечивающий интероперабельность приложений, заключается в независимости спецификации интерфейсов объектов от их реализации.

В начале 1990-х гг. были серьёзные проблемы с обеспечением возможности общения программ, выполняемых на разных машинах, особенно, если использовались разные аппаратные средства, операционные системы и языки программирования: либо программисты использовали сокеты и сами реализовывали весь стек протоколов, либо их программы вовсе не взаимодействовали.

Для решения этой проблемы в 1989 г. был создан консорциум OMG (Object Management Group). Его основная задача состояла в следующем - разработка и продвижение объектноориентированных технологий и стандартов. Это некоммерческое объединение, разрабатывающее стандарты для создания корпоративных платформо-независимых приложений.

Концептуальной инфраструктурой, на которой базируются все спецификации OMG, является Object Management Architecture (OMA). В состав OMA входят разнообразные стандартизованные или в настоящий момент стандартизируемые OMG службы, сервисы, программные образцы и шаблоны (CORBAservices, horizontal and vertical CORBAfacilities), язык определения интерфейсов распределенных объектов IDL (Interface Definition Language), стандартизованные или стандартизируемые отображения IDL на языки программирования, а также объектная модель CORBA.

Рис. 2.2 Основные понятия технологии CORBA

В 1997 г. консорциум OMG опубликовал спецификацию CORBA 2.0. В ней определялись стандартный протокол и отображение для языка C++, а в 1998 г. было определено отображение для Java. В результате разработчики получили инструментальное средство, позволяющее им относительно легко создавать неоднородные распределенные приложения. CORBA быстро завоевала популярность, и с использованием этой технологии был создан ряд критически важных приложений.

Технологический стандарт CORBA определяет язык IDL, применяемый для унифицированного описания интерфейсов распределенных объектов, и его отображения на языки Ada, C, C++, Java, Python, COBOL, Lisp, PL/1 и Smalltalk. Для преобразования описания интерфейса на языке IDL на требуемый язык программирования используется специальный компилятор. В дальнейшем построенный с его помощью программный код может быть преобразован любым стандартным компилятором в исполняемый код.

Рис. 2.3 Ядро архитектуры CORBA.

Основной и в тоже время главной особенностью CORBA является использование компонента ORB (Object Resource Broker - брокер ресурсов объектов) для создания экземпляров объектов и вызова их методов. Данный компонент формирует «мост» между приложением и инфраструктурой CORBA. ORB поддерживает удаленное взаимодействие с другими ORB, и обеспечивает управление удаленными объектами, включая учет количества ссылок и времени жизни объекта. Для обеспечения взаимодействия между ORB используется протокол GIOP (General Inter-ORB Protocol - общий протокол для коммуникации между ORB). Наиболее распространенной реализацией данного протокола считается протокол IIOP (Internet Inter-ORB Protocol - протокол взаимодействия ORB в сети интернет), обеспечивающий отображение сообщений GIOP на стек протоколов TCP/IP.

Рис. 2.4 Схема взаимодействия объектов OMA

Изначально, технология CORBA ориентирована на предоставление готовой проблемно-ориентированной инфраструктуры для создания РВС в рамках определенной проблемной области. Для этого, в состав CORBA включают набор стандартных объектных сервисов и общих средств. Спецификация CORBA предусматривает также ряд стандартизованных сервисов (CORBA Services) и горизонтальных и вертикальных Общих Средств (Common Facilities). Сервисы представляют собой обычные CORBA-объекты со стандартизованными (и написанными на IDL) интерфейсами. К таким сервисам относится, например, сервис имен NameService, сервис сообщений, позволяющий CORBA-объектам обмениваться сообщениями, сервис транзакций, позволяющий CORBA-объектам организовывать транзакции. В реальной системе не обязательно должны присутствовать все сервисы, их набор зависит от требуемой функциональности. На сегодняшний день разработано 14 объектных сервисов. Между объектными сервисами и общими средствами CORBA нет четкой границы. Последние тоже представляют собой CORBA-объекты со стандартизованными интерфейсами. Cоmmоn Fаcilities делятся на горизонтальные (общие для всех прикладных областей) и вертикальные (для конкретной прикладной области).

Процесс разработки приложения с использованием технологии CORBA состоит из следующих 4-х этапов:

1. Определение интерфейса на IDL.

2. Обработка IDL для создания кода заглушки и скелетона.

3. Создание кода реализации объекта (сервер).

4. Создание кода использования данного объекта (клиент).

Созданный на IDL код должен специальным компилятором преобразовываться в код интерфейса объекта на требуемом языке программирования. После чего, на клиенте автоматически генерируется заглушка, преобразующая вызовы методы данного интерфейса в обращения к ORB. На сервере программист на основе сгенерированного интерфейса создает собственную реализацию данного класса. Скелетон автоматизирует получение и обработку удаленного вызова методов, поступающих через ORB.

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

– использование IDL для описания интерфейсов позволяет разрабатывать программные компоненты независимо от языка программирования и базовой операционной системы;

– поддержка богатой инфраструктуры распределенных объектов;

– прозрачность вызова удаленных объектов.

Тем не менее программные решения на базе технологии CORBA редко выходят за рамки отдельных предприятий. Разработка крупномасштабных меж-организационных систем на базе технологии CORBA сопряжена со следующими трудностями:

– плохая совместимость различных реализаций технологии CORBA от различных поставщиков;

– проблемы взаимодействия узлов CORBA через Интернет;

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

На смену технологии CORBA пришли стандартизованные протоколы веб-сервисов, такие как XML, WSDL, SOAP и др. Сегодня CORBA используется для реализации узкого круга приложений и является фактически нишевой технологией.

2.5 Технология DCOM

Технология DCOM (модель объектов распределенных компонентов) - это набор концепций и программных интерфейсов Microsoft, в которых объекты клиентских программ могут запрашивать услуги у объектов серверных программ на других компьютерах в сети. DCOM основан на компонентной объектной модели (COM), которая предоставляет набор интерфейсов, позволяющих клиентам и серверам обмениваться данными на одном компьютере (под управлением Windows 95 или более поздней версии).

Например, мы можем создать страницу для веб-сайта, содержащую скрипт или программу, которую можно обработать (перед отправкой запрашивающему пользователю) не на сервере веб-сайта, а на другом, более специализированном сервере в сети. Используя интерфейсы DCOM, программа сайта веб-сервера (теперь действующая как объект клиента) может пересылать удаленный вызов процедур (RPC) на объект специализированного сервера, который обеспечивает необходимую обработку и возвращает результат сайту веб-сервера. Он передает результат в средство просмотра веб-страниц.

DCOM также может работать в сети внутри предприятия или в других сетях, помимо общедоступного Интернета. Он использует TCP / IP и протокол передачи гипертекста. DCOM входит в состав операционных систем Windows. Она также будет или скоро будет доступна на всех основных платформах UNIX и на больших серверных продуктах IBM. DCOM заменяет OLE Remote Automation.