Разработка распределенных приложений в Microsoft.NET Framework
Архитектура среды NET Remoting
Среда Remoting имеет достаточно сложную организацию удаленного вызова, которая позволяет разработчику при необходимости полностью контролировать и модифицировать процесс вызова клиентом Remoting метода объекта сервера. Это, с одной стороны, дает возможность после доработок применять среду Remoting практически с любыми каналами передачи информации (например, поверх MSMQ) или для некоторых специальных целей (например, для взаимодействия CLR и COM+). Открытая и изменяемая архитектура среды также делает ее достаточно привлекательной с педагогической точки зрения при изучении механизмов удаленного вызова. С другой стороны, модификация архитектуры Remoting является достаточно нетривиальной задачей, в результате решения которой могут быть получены сложные, нестандартные и недостаточно проверенные, в том числе с точки зрения безопасности, расширения промежуточной среды. Поэтому вопрос о полезности больших возможностей по расширению промежуточной среды конечным разработчиком остается, видимо, открытым.
Рис. 8.2. Выполнения удаленного вызова в .NET Remoting
Архитектура среды Remoting (рис. 8.2) включает в себя следующие основные сущности, реализуемые классами из пространства имен System.Runtime.Remoting и его подпространств.
- Посредники удаленного объекта. В среде используется два посредника, принадлежащие классам TransparentProxy и RealProxy. Первый из них является классическим посредником и реализует интерфейс удаленного объекта. Второй, "настоящий", посредник получает от "прозрачного" посредника сообщение об удаленном вызове (класс IMessage). "Настоящий" посредник может быть изменен разработчиком для реализации каких то специфических функций, и поэтому посредник удаленного объекта в среде Remoting представлен двумя сущностями.
-
Сообщение проходит по каналу (channel) среды Remoting. Канал состоит из отдельных труб (sinks) и может иметь различную структуру. Как минимум, клиентская сторона канала включает трубу форматирования, преобразующую сообщение об удаленном вызове в поток ввода- вывода, и транспортную трубу, передающую данный поток в канал передачи данных.
Серверная сторона канала, в свою очередь, состоит как минимум из транспортной трубы, трубы форматирования и трубы диспетчеризации. Трубы форматирования и транспорта присутствуют на каждой стороне не более чем в одном экземпляре. Канал может содержать и другие трубы, которые оперируют с сообщением или полученным из него потоком. В первом случае трубы располагаются до трубы форматирования (на клиенте) и реализуют интерфейс IMessageSink. Такие трубы называют трубами сообщения (message sinks). Во втором случае трубы располагаются между трубами форматирования и транспорта, и называются трубами обработки потока (channel sinks). Они реализуют интерфейс IСlientChannelSink на клиенте или IServerChannelSink на сервере. Стандартная труба форматирования реализует интерфейсы и трубы потока, и трубы сообщения, а транспортная труба относится к трубам потока. - Последняя из труб в серверной части канала должна передать сообщение заглушке удаленного вызова, называемой диспетчером (реализуется методом ChannelServices.DispatchMessage) .
Для передачи информации об объекте сервера и создания на клиенте "прозрачного" посредника используется особый класс System.Runtime.Remoting.ObjRef. При попытке сериализации и передачи по каналу маршализируемого по ссылке объекта используется рассмотренный ранее механизм сурогатных селекторов.
Благодаря этому механизму при сериализации наследников класса System.MarshalByRefObject по каналу Remoting вместо них передается маршализируемый по значению объект класса ObjRef, который после десериализации становится "прозрачным" посредником на клиенте Remoting (рис. 8.3).
Рис. 8.3. Маршализация по ссылке в среде Remoting
Таким образом, среда Remoting позволяет организовать синхронный или односторонний удаленный вызов методов объектов, наследованных от класса MarshalByRefObject. Асинхронный односторонний вызов осуществляется для методов с атрибутом OneWayAttribute 1). Такие методы не должны возвращать какие либо результаты, и вызываются по принципу "выстрелил и забыл". Выбрасываемые в ходе его выполнения исключения также не передаются клиенту. Среда Remoting поддерживает все три вида активации объектов, причем для объектов единственного вызова изменение значения свойств и общедоступных полей рассматривается как удаленный вызов, за которым следует освобождение объекта. Среда Remoting не поддерживает пул объектов.
Одной из проблем при использовании распределенных объектов является определение момента их уничтожения сервером. Для автоматического удаления из памяти локальных объектов, используемых удаленным клиентом, недостаточно отслеживания локальных ссылок на них. В среде Remoting для управлением временем жизни таких объектов используется система аренды (lease), которая при использовании активируемых клиентом объектов или объектов единственного экземпляра с некоторым интервалом просит клиента подтвердить необходимость существования объекта. Если на стороне клиента уже нет активных ссылок на удаленный объект, то подтверждения не происходит, и при отсутствии хотя бы одного подтверждения объект на сервере будет освобожден. Для объектов единственного вызова в такой системе нет нужды, поскольку объекты создаются сервером при удаленном вызове и освобождаются сервером после завершения любого удаленного вызова (включая методы set и get свойств).В силу этого с объектами, активируемыми сервером, может использоваться только конструктор по умолчанию, не имеющий параметров.
