114 Глава 2. Связь

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

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

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

Сохранные и нерезидентные объекты

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

2.3.2. Привязка клиента к объекту

Интересная разница между традиционными системами RPC и системами, под­держивающими распределенные объекты, состоит в том, что последние обычно

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

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

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

При неявной привязке (implicit binding) клиенту предоставляется простой ме­ханизм, позволяющий напрямую запрашивать методы, используя только ссылку на объект. Так, например, в C++ можно переопределить унарный оператор выбо­ра (->) для класса так, чтобы он позволял обращаться со ссылками на объекты как с простыми указателями (листинг 2.1). В случае неявной привязки клиент прозрачно связывается с объектом в момент разрешения ссылки и получения этого объекта в действительности. С другой стороны, в случае явной привязке (explicit binding) клиент должен до обращения к методам вызвать специальную функцию для привязки к объекту. При явной привязке обычно возвращается ука­затель на локально доступный заместитель, как показано в листинге 2.2.

Листинг 2.2. Пример явной привязки с использованием как глобальных, так и локальных переменных

Листинг 2.1. Пример неявной привязки с использованием только глобальных переменных