9.3.2. Связь

В отличие от CORBA и DCOM Globe не предоставляет никаких других методов связи кроме синхронных обращений к методам. Когда обращение завершается, то есть когда происходит возвращение результата обращения (обращение при этом выглядит как вызов метода через локальный интерфейс), всякая деятельность внутри распределенного разделяемого объекта прекращается, не считая деятель­ности, связанной с другими вызовами. В этом смысле объекты Globe считаются пассивными (passive).

Чтобы понять, что такое пассивный объект, рассмотрим распределенный объ­ект, совместно используемый тремя процессами (рис. 9.26). Процессы В и С име­ют реплики своего состояния, представленные в виде заштрихованных подобъ-ектов семантики (Sem). Процесс Л не имеет не только состояния, он не имеет даже подобъекта семантики. Локальный объект в адресном пространстве процес­са А соответствует традиционной клиентской заглушке, или заместителю.

Предположим, процесс Л обращается к объекту. В соответствие с простым сценарием репликации этот запрос будет передан соответственно процессам В и С, на что указывает траектория в виде сплошной линии. Когда запрос достиг­нет подобъекта связи (Comm), скажем, процесса Д будет активизирован поток выполнения для обработки запроса. В конце своей работы этот поток выполне­ния обратится к подобъекту семантики и вернет процессу Л результат в отдель­ном сообщении. Аналогичная деятельность происходит и в процессе С.

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

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

9.3.3. Процессы

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

Клиент Globe

Клиент Globe — это процесс, который относится к распределенному разделяемо­му объекту и обращается к этому объекту, вызывая доступные методы через ин­терфейс подобъекта управления (Ctrl), как показано на рис. 9.26. Процесс А в данном случае представляет собой типичный пример клиента Globe, не имею­щего состояния, но соединенного с репликами, у которых состояние имеется.

Во многих случаях клиент Globe относительно прост, в том смысле, что он даже не имеет подобъекта семантики. Все его обращения после маршалинга не­медленно передаются репликам, выступающим в качестве серверов. Эта модель очень похожа на заместители в CORBA и также может быть использована в ка­честве основы для интеграции распределенных разделяемых объектов в систе­мах, подобных CORBA [214]. Однако в Globe возможна также настройка клиен­тов в соответствии с подходом DCOM и RMI языка Java. Такая настройка может потребоваться, например, для того, чтобы позволить клиенту кэшировать резуль­таты обращений.

Стандартный способ придания клиентам CORBA новых свойств — использо­вание перехватчиков. В DCOM подобная настройка, которая производится пу­тем реализации на клиенте выделенного заместителя, возможна благодаря под­держке пользовательского маршалинга. В Globe распределенный разделяемый объект обычно предоставляет несколько реализаций локальных объектов. Эти реализации содержатся в хранилищах классов. Клиент сам решает, какую реали­зацию ему использовать.

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

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

Сервер Globe

В противоположность клиенту сервер системы Globe — это процесс, который способен только обрабатывать запросы с обращениями, приходящие к нему по сети. Другими словами (см. рис. 9.26), он не в состоянии вызывать методы через интерфейс, предоставляемый подобъектом управления (Ctrl); процессы В и С — это примеры серверов Globe.

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

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

Привязка сервера к объекту является идемпотентной операцией; если привязка уже выполнена, не происходит ничего. Если предполагается загрузка сервером другого локального объекта, относящегося к распределенному разде­ляемому объекту, привязка к которому уже выполнена, вызывается метод AddBinding.

Сервер объектов Globe также содержит базовые средства создания распреде­ленных разделяемых объектов путем создания локальных объектов. Создание производится вызовом метода CreateLR с указанием той реализации (то есть объ­екта класса), которую может загрузить сервер. Когда объект класса загружен, сервер создает по объекту класса новый локальный объект и инициализирует его. Обычно инициализация также предполагает, что контактный адрес нового объекта становится доступным службе локализации Globe. Таким образом, с этого момента к объекту можно выполнять привязку других процессов.

Метод RemoveLR просто удаляет определенный локальный объект с сервера объектов. Обычно эта операция не вызывается никогда. Вместо этого сервер, как правило, получает указание разорвать привязку к распределенному разделяемому объекту методом Unbi ndDSO. В результате разрыва привязки все локальные объек­ты данного объекта удаляются с сервера, таким образом, объект сам очищает за­нимаемое им место.

Отметим, что разрыв привязки вовсе не обязательно означает ликвидацию объекта. Во многих случаях к нему могут быть привязаны другие процессы, и пока объект не уничтожен явным образом, он продолжает существовать. По­добно CORBA, но в противоположность DCOM, Globe поддерживает как нере­зидентные, так и сохранные объекты.

И, наконец, существует несколько операций для просмотра привязок серве­ров объектов и состояния каждого из локальных объектов.

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

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