Remoting в Microsoft.NET

Ремоутинг в Microsoft.NET – это технология, позволяющая приложениям взаимодействовать друг с другом через границы процессов. Она позволяет посылать сообщения, работать с объектами, вызывая их методы и управляя их временем жизни. Вы вольны выбирать пригодный вам канал передачи данных и способы сериализации объектов. Сегодня ремоутинг позволяет использовать TCP/IP и HTTP. Потенциально же возможности ремоутинга не ограничены рамками какого-либо сетевого протокола или операционной системы. Как и в случае SOAP, можно писать свои прослойки для доступа к объектам, если стандартных возможностей недостаточно. Ремоутинг позволяет строить распределенные приложения и легко передавать данные между ними. Сила данного механизма заключается в простоте реализации и гибкости использования различных протоколов для передачи информации.

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

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

Ознакомимся с теорией, а затем посмотрим на несколько примеров.

Объекты, передаваемые по ссылке или по значению

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

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

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

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

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

Для того, чтобы создаваемый вами тип мог быть передан по значению, достаточно, чтобы он реализовывал интерфейс ISerializable или имел атрибут SerializableAttribute, например, следующий класс будет автоматически сериализоваться:

[Serializable]
 public class Toy
 {
   public String ToyName;
   public int Price;
 }

Также можно унаследовать свой класс от MarshalByValueComponent, и реализовать интерфейс ISerializable.

Передача ссылки на объект вместо копирования его состояния позволяет избежать описанных выше проблем. Работа на клиенте идет с объектной ссылкой, которая с помощью прокси-объекта отправляет запросы серверному компоненту, таким образом позволяя не переносить все данные о состоянии объекта, а также получать прямой доступ к ресурсам сервера. Стоит отметить, что при обращении к объектам, передаваемым по ссылке и находящимся в том же приложении, что и вызывающий объект, система вернет прямую ссылку. Это позволит работать без потери производительности. В .NET объекты, передаваемые по ссылке, должны наследоваться от класса MarshalByRefObject, например:

public class Toy : MarshalByRefObject 
{
  public String ToyName;
  public int ToyPrice;
}

Наследование от MarshalByRefObject позволяет переложить всю функциональность передачи объекта по ссылке на имеющуюся реализацию.

Обобщенный взгляд на ремоутинг

Передача объектов по значению – наука невеликая. Основу технологии удаленного доступа к объектам, естественно, составляет именно работа с объектами, живущими на удаленном компьютере. Сконфигурировав правильно систему ремоутинга и указав все параметры, вы можете насладиться простотой создания удаленного объекта с помощью привычного оператора new. Для соединения система ремоутинга использует уже упомянутый прокси.

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

Канал – это объект, который отвечает за упаковку и доставку данных по определенному протоколу. Канал может, как известно, быть односторонним (на посылку или на прием), либо дуплексным (чудо, которое умеет и то, и другое) – как-то HttpChannel и TcpChannel.

Активация

Активация – это создание и инициализация компонента. Активация немаловажна при работе с удаленными объектами, так как тесно связана с состоянием объекта.

При работе с удаленными объектами, вы можете активировать их как на клиенте, так и на сервере.

Создаваемые на сервере объекты делятся на Singleton-объекты, и SingleCall-объекты (объекты одного вызова). Как не сложно догадаться, Singleton-объекты в рамках работы сервера всегда только один, в то время как SingleCall-объекты создаются направо и налево при каждом вызове.

Для настройки времени жизни Singleton-объектов используется механизм сроков аренды. Предопределенные значения времени можно указать в конфигурационном файле.

При активации на стороне клиента объекты создаются на сервере по вызову new (либо Activator.GetObject) на клиенте. Клиент сам управляет временем жизни объекта, используя срок аренды (lifetime lease). Если же клиент не указывает время жизни объекта, система ремоутинга на сервере использует параметры, указанные на сервере по умолчанию. При создании объектов, активируемых на клиенте, система ремоутинга на сервере посылает клиенту новую объектную ссылку (экземпляр класса ObjRef). Именно этот магический объект позволяет создавать прокси.

Для того, чтобы создаваемый объект был client-side активируемым, приложение должно быть соответствующим образом сконфигурировано. Это может быть сделано как программно, так и декларативно, при помощи конфигурационных файлов (их синтаксис мы рассмотрим позже). Еще один способ создать активируемый на стороне клиента объект – воспользоваться соответствующим методом класса Activator, которому и передается вся необходимая информация.

В отличие от DCOM, где для определения времени жизни использовался механизм подсчета ссылок, в Microsoft .NET применяется механизм сроков аренды. Суть его заключается в том, что каждый client-activated объект хранит промежуток времени, который он будет существовать, так называемый срок аренды (lease). Если во время этого промежутка производится вызов метода, то время жизни объекта продлевается. Для управления этим механизмом используется менеджер сроков аренды (lease manager), закрепленный за приложением. Он содержит список так называемых спонсоров (sponsors), связанных со сроками аренды. По истечении срока аренды менеджер обращается к соответствующему спонсору с запросом о продлении срока. Если спонсор недоступен, менеджер будет выжидать предопределенное время, а затем, в случае неудачи, объект уничтожается. Каждый объект может сам управлять своим сроком жизни путем переопределения метода InitializeLifetimeService. Несмотря на то, что при использовании механизма сроков аренды объект может жить излишне долгое время, в условиях рвущейся связи такой механизм более жизнеспособен, чем механизм подсчета ссылок.

Особенности вызовов методов и передачи сообщений

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

Напомним, что прокси предназначен для обеспечения работы с удаленным объектом без его копирования на сторону клиента. Однако на самом деле используется не один, а два прокси объекта, которые являются экземплярами классов RealProxy и TransparentProxy. Клиент обычно работает с TransparentProxy, который только начинает процесс вызова метода, делая предварительную работу по упаковке параметров. Затем он передает управление вспомогательному объекту, Real-прокси, который и выполняет всю работу по передаче сообщений. Сообщения реализуют интерфейс IMessage и являются контейнерами для передаваемых между Application-доменами данных. В данной терминологии процесс передачи запакованных данных именуется передачей сообщений.

Классы RealProxy и ObjRef могут быть расширены и дополнены, например, для обеспечения распределения нагрузки...