Статическое и динамическое обращение к методам

После того, как клиент свяжется с объектом, он может через заместителя обратиться к методам объекта. Основное различие между моделями RMI и RPC состоит в том, что RMI в основном поддерживает внутрисистемные ссылки на объекты. Стандартный для RMI способ поддержки – описание интерфейсов объектов на языке определения интерфейсов (как в RPC). Такой подход называется статическим обращением. Статическое обращение требует, чтобы интерфейсы объекта при разработке клиентского приложения были известны. Одновременно предполагается, что при изменении интерфейса клиентское приложение перед использованием будет заново откомпилировано. Иногда удобнее собирать параметры перед обращением к методу во время исполнения программы. Этот процесс называется динамическим обращением. Отличие от статического способа в том, что приложение выбирает, какой метод удаленного объекта вызвать во время выполнения, передавая процедуре динамического вызова идентификатор этого метода.

Передача параметров в модели RMI

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

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

Копирование ссылки при передаче объекта в качестве параметра происходит только тогда, когда она относится к удаленному объекту. Если же ссылка относится к локальному объекту, то есть к объекту в адресном пространстве клиента, то клиенту передается сам объект.

Брокеры объектов

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

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

Архитектура CORBA

Система, подчиняющаяся спецификации CORBA, состоит из трех основных частей:

· брокер запросов объектов, содержащий базовые функции взаимодействия объектов.

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

· средства CORBA – это набор средств и инструментов верхнего уровня, необходимых не индивидуальным объектам, а приложениям.

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

Работа CORBA

Чтобы к объекту можно было обратиться через брокер объектов, этот объект должен сначала объявить свой интерфейс, из чего клиенты узнают о методах, которые он предоставляет. Интерфейсы описываются на IDL.

В дополнение к описанию методов, в отличие от систем на базе RPC, язык IDL спецификации CORBA поддерживает множество объектно-ориентированных концепций, например, наследование и полиморфизм. Как и в случае RPC, спецификации, написанные на IDL, могут быть переданы компилятору с этого языка, который формирует заместителя объекта и скелетон. Заместитель объекта – это переходник, ответственный за сокрытие распределенности, его задача – представить вызовы не удаленными, а локальными. Программа заместителя содержит в себе описание методов, предоставляемых реализацией объекта. Для получения готового клиентского приложения, она должна быть загружена вместе с программой клиента. С другой стороны скелетон защищает от проблем распределенности сервер, поэтому сервер может разрабатываться так, как если бы вызовы к нему поступали из локального окружения. Как заместитель, так и скелетон могут быть написаны на любом из тех языков, которые поддерживаются компилятором с языка IDL (например, спецификация CORBA 3 поддерживает трансляцию с IDL на Си, Си++, Java, Smalltalk, Аду, Кобол, Лисп, PL/1, Python и IDLScript).

Современные версии спецификации CORBA допускают и обратные отображения: например, в стандарте CORBA 3 предусмотрено проведение отображения записи интерфейсов на языке Java в записи интерфейсов на IDL. Обратное отображение позволяет программистам на языке Java создавать объекты, доступные из других приложений, написанных (возможно) на других языках программирования. Обработка программы на языке Java обратным компилятором позволяет получить эквивалентный интерфейс, написанный на IDL, имея который, можно построить (на языке Java или другом языке программирования) программу клиента CORBA, имеющую доступ к нужному объекту.