Объекты времени компиляции против объектов времени выполнения

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

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

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

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

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

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

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