Сергей Зыков - Основы проектирования корпоративных систем

Далее следует рассмотреть вопрос явной активизации объектов на сервере. Момент создания объекта в этом случае определяется сервером. При этом речь идет уже о передаче не экземпляра объекта, а его типа. То есть имя присваивается не экземпляру, а типу. И для обработки каждого вызова удаленного метода может создаваться собственно новый экземпляр объекта. При этом используется метод Single Call. Здесь явно указывается имя объекта srv_obj и осуществляется вызов метода Register Service Type, т. е. определенный метод реализации сервиса на основе класса Remoting Configuration. Нужно сказать, что все вызовы удаленного метода могут обрабатываться одним и тем же объектом, сервером, при этом используется метод Single в отличие от предыдущего Single Call. Клиент работает с удаленным объектом полностью аналогично предыдущему случаю. Другая форма взаимодействия между клиентом и сервером основана на активизации объектов клиента. При этом момент создания объекта определяется уже не сервером, а клиентом, и на сервере в этом случае может быть создано много объектов. В этом случае сервер объекта уникально однозначно определяется явным указанием имени компьютера. Мы видим, что осуществляется передача параметра методу Register Activated Service Type, т. е. осуществляется регистрация указанного типа сервиса с параметром того самого объекта типа «сервер», к которому реализуется обращение. При этом, по сути, мы работаем в том же пространстве имен Remoting с тем же классом Remoting Configuration, но другим образом определяем конфигурацию взаимодействия между клиентом и сервером. При активизации объектов клиентом на сервере клиент должен вначале осуществить регистрацию типа объекта с учетом его расположения на сервере, а затем создать объекты, для каждого обращения создается объект (Proxy), который осуществляет инкапсуляцию методов на сервере. Итак, мы используем метод Register Activator Client Type класса Remoting Configuration с явным указанием, что тип объекта расположен на сервере, и явным указанием этой машины. После чего для каждого вызова создается свой объект класса Server Object. По сути, это не совсем объекты, это Proxy. Но для каждого из них осуществляется свой вызов оператора New.

Последнее, что будет обсуждаться касательно Remoting, – это процедура сборки мусора. Вообще, процедура сборки мусора крайне важна для больших объектных систем. Здесь речь идет о том, что существует большое количество объектов типа «ссылки». Следует напомнить, что в. NET, в CTS – системе типизации, существуют два больших подкласса объектов – ссылки и значения. Если рассматривать корпоративные системы, то очевидно, что для реализации распределенных приложений, которые используют большое количество сложных объектов, а вместе с тем эти объекты имеют сложную структуру и динамически взаимодействуют друг с другом, целесообразно использовать типы-ссылки. В связи с этим часто возникают ситуации, когда не вполне корректно уничтожается информация о значении самого типа-ссылки при уничтожении собственно объекта этого типа. То есть не всегда разрывается связь между именем и значением объекта, на которое указывает ссылка с этого имени. Для уничтожения такого рода висячих ссылок, т. е. ссылок, указывающих на некорректную область памяти, которая уже освобождена и не содержит значения типа «ссылки», существует стандартный процесс сборки мусора.

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

Если рассматривать классический подход к распределенной сборке мусора между клиентом и сервером, ссылки через границы процессов, то нужно реализовать уничтожение объектов на сервере, на которые ссылки более не актуальны. Это происходит следующим образом: распределенный сборщик мусора подсчитывает количество ссылок на серверный объект, т. е. на тот объект, который находится на сервере, при этом, естественно, поскольку эти ссылки идут на сервер, осуществляется периодический опрос клиентов. Другой подход сводится к тому, что в. NET можно явным образом выполнить функцию сборки мусора, и программист может явно вызвать соответствующий метод, стандартно реализованный в. NET Framework.

Что касается подхода Remoting, то здесь используется механизм аренды. Существует определенный интервал времени, который определяется для каждого серверного объекта. Каждому серверному объекту ставится в соответствие объект специального вида, который имеет интерфейс лизинга. И выглядит следующим образом: существует для маршаллинга по ссылке класс, который определяется как класс Marshal by Ref Object и содержит виртуальный объект, собственно и реализующий инициализацию процедуры обслуживания сборщика мусора. При этом интерфейс лизинга внутри класса осуществляет вычисление времени аренды для каждого объекта, который поставлен в соответствие и для которого существует возможность определения и обновления срока аренды, если такая возможность предоставляется.

На этом рассмотрение реализации технологий распределенных вычислений в среде. NET завершается. Мы познакомились с общим принципом распределенных вычислений, обсудили различие между подходом с сохранением состояний и подходом без сохранения состояний, а также подходом, который связан с Loosely Coupled и Tightly Coupled моделями взаимодействия. Оценили эффективность сильно связанной и большую универсальность слабо связанной модели взаимодействия объектов. Рассмотрели эволюцию архитектур, которые связаны с объектным и дообъектным подходами обмена информацией между клиентом и сервером по технологии RPC. Общим для этих подходов является наличие Proxy и Stub как механизмов упаковки и передачи параметров между клиентом и сервером. При упаковке речь идет о маршеринге, при распаковке – об анмаршаллинге. В объектном подходе имеет место инкапсуляция объектов, т. е. изоляция технологий сред взаимодействия и конкретных языков программирования, на которых реализуются процедуры, методы или функции для клиентов и серверов.