Обращение к удаленным объектам

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

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

Распределенные объекты

Ключевая особенность объекта состоит в том, что он инкапсулирует данные, называемые состоянием (state), и операции над этими данными, называемые методами (methods). Доступ к методам можно получить через интерфейс. Важно понять, что единственно правильным способом доступа или манипулирования состоянием объекта является использование методов, доступ к которым осуществляется через интерфейс этого объекта. Объект может реализовывать множество интерфейсов. Точно так же для данного описания интерфейса может существовать несколько объектов, предоставляющих его реализацию.

Это подразделение на интерфейсы и объекты, реализующие их, очень важно для распределенных систем. Четкое разделение позволяет нам помещать интерфейс на одну машину при том, что сам объект находится на другой. Структура, показанная на рис. 2.16, обычно и называется распределенным объектом (distributed object).

Когда клиент выполняет привязку к распределенному объекту, в адресное пространство клиента загружается реализация интерфейса объекта, называемая заместителем (proxy). Заместитель клиента аналогичен клиентской заглушке в системах RPC. Единственное, что он делает, — выполняет маршалинг параметров в сообщениях при обращении к методам и демаршалинг данных из ответных сообщений, содержащих результаты обращения к методам, передавая их клиенту. Сами объекты находятся на сервере и предоставляют необходимые клиентской машине интерфейсы. Входящий запрос на обращение к методу сначала попадает на серверную заглушку, часто именуемую скелетоном (skeleton). Скелетон преобразует его в правильное обращение к методу через интерфейс объекта, находящегося на сервере. Серверная заглушка также отвечает за маршалинг параметров в ответных сообщениях и их пересылку заместителю клиента.

Характерной, но немного противоречащей интуитивному представлению особенностью большинства распределенных объектов является то, что их состояние (данные) не распределяется — оно локализовано на одной машине. С других машин доступны только интерфейсы, реализованные в объекте. Такие объекты еще называют удаленными (remote object). Тем не менее, при работе с распределенными объектами, их состояние может быть физически распределено по нескольким машинам, но это распределение также скрывается от клиентов за интерфейсами объектов.

Объекты времени компиляции против объектов времени выполнения Объекты в распределенных системах существуют в различных формах. В наиболее распространенном варианте они соответствуют объектам выбранного языка программирования, например Java, C++ или другого объектно-ориентированного языка, и представляют собой объекты времени компиляции. В этих случаях объект является экземпляром класса. Класс — это описание абстрактного типа в виде модуля, содержащего элементы данных и операций над этими данными.

Использование объектов времени компиляции в распределенных системах обычно значительно упрощает создание распределенных приложений. Так, в языке Java объект может быть полностью описан в рамках своего класса и интерфейсов, которые этот класс реализует. Компиляция определения класса порождает код, позволяющий создавать экземпляры объектов языка Java. Интерфейсы можно скомпилировать в клиентские и серверные заглушки, позволяющие обращаться к объектам Java с удаленных машин. Разработчик программы на Java чаще всего может не беспокоиться по поводу распределения объектов: он занимается только текстом программы на языке Java.

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

При работе с объектами времени исполнения тот способ, которым они будут реализованы, обычно остается открытым. Так, например, разработчик может решить написать на С библиотеку, содержащую набор функций, которые смогут работать с общим файлом данных. Главный вопрос состоит в том, как превратить эту реализацию в объект, методы которого будут доступны с удаленной машины. Традиционный способ состоит в том, чтобы использовать адаптер объектов (object adapter), который послужит оболочкой (wrapper) реализации с единственной задачей — придать реализации видимость объекта. Сам термин «адаптер» взят из шаблона проектирования, который предоставляет интерфейс, преобразуемый в то, что ожидает клиент. Примером адаптера объектов может быть некая сущность, динамически привязываемая к описанной ранее библиотеке на C и открывающая файл данных, соответствующий текущему состоянию объекта.

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

Сохранные и нерезидентные объекты Помимо деления на объекты, зависящие от языка программирования, и объекты времени выполнения существует также деление на сохранные и нерезидентные объекты. Сохранный объект (persistent object) — это объект, который продолжает существовать, даже не находясь постоянно в адресном пространстве серверного процесса. Другими словами, сохранный объект не зависит от своего текущего сервера. На практике это означает, что сервер, обычно управляющий таким объектом, может сохранить состояние объекта во вспомогательном запоминающем устройстве и завершить свою работу. Позже вновь запущенный сервер может считать состояние объекта из запоминающего устройства в свое адресное пространство и обработать запрос на обращение к объекту. В противоположность ему, нерезидентный объект (transient object) — это объект, который существует, только пока сервер управляет им. Когда сервер завершает работу, этот объект прекращает существовать. Использовать сохранные объекты или нет — это спорный вопрос. Некоторые полагают, что нерезидентных объектов вполне достаточно.

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

После того как клиент свяжется с объектом, он может через заместителя обратиться к методам объекта. Подобное удаленное обращение к методам (Remote Method Invocation, RMI) в части маршалинга и передачи параметров очень напоминает RPC. Основное различие между RMI и RPC состоит в том, что RMI, как говорилось ранее, в основном поддерживает внутрисистемные ссылки на объекты. Кроме того, отпадает необходимость в клиентских и серверных заглушках общего назначения. Вместо них мы можем использовать значительно более удобные в работе и специфические для объектов заглушки, которые мы также обсуждали.

Стандартный способ поддержки RMI — описать интерфейсы объектов на языке определения интерфейсов, так же как в RPC. Однако с тем же успехом мы можем использовать объектный язык, например Java, который обеспечивает автоматическую генерацию заглушек. Такой подход к применению предопределенных определений интерфейсов часто называют статическим обращением (static invocation). Статическое обращение требует, чтобы интерфейсы объекта при разработке клиентского приложения были известны. Также оно предполагает, что при изменении интерфейса клиентское приложение перед использованием новых интерфейсов будет перекомпилировано.

В качестве альтернативы обращение к методам может осуществляться более динамичным образом. В частности, иногда удобнее собрать параметры обращения к методу во время исполнения. Этот процесс известен под названием динамического обращения (dynamic invocation). Основное его отличие от статического обращения состоит в том, что во время выполнения приложение выбирает, какой метод удаленного объекта будет вызван. Динамическое обращение обычно выглядит следующим образом:

Здесь object идентифицирует распределенный объект; method — параметр, точно задающий вызываемый метод; input_parameters — структура данных, в которой содержатся значения входных параметров метода; output_parameters — структура данных, в которой хранятся возвращаемые значения.

В качестве примера рассмотрим добавление целого числа int к объекту fobject файла. Для этого действия объект предоставляет метод append. В этом случае статическое обращение будет иметь вид:

Здесь операция id (append) возвращает идентификатор метода append. Для иллюстрации динамического обращения рассмотрим браузер объектов, используемый для просмотра наборов объектов. Предположим, что этот браузер поддерживает удаленное обращение к объектам. Это будет означать, что браузер в состоянии выполнить привязку к распределенному объекту и предоставить пользователю интерфейс с объектом. Пользователю после этого может быть предложено выбрать метод и ввести значения его параметров, после чего браузер сможет произвести действительное обращение. Обычно подобные браузеры объектов разрабатываются так, чтобы они поддерживали любые возможные интерфейсы. Такой подход требует исследования интерфейсов во время выполнения и динамического создания обращений к методам.

Другая область применения динамических обращений — службы пакетной обработки, для которых запросы на обращение могут обрабатываться в течение всего того времени, пока обращение ожидает выполнения. Служба может быть реализована в виде очереди запросов на обращение, упорядоченных по времени поступления. Основной цикл службы просто ожидает назначения очередного запроса, удаляет его из очереди и, как это было показано ранее, вызывает процедуру invoke.