Далее следует рассмотреть вопрос явной активизации объектов на сервере. Момент создания объекта в этом случае определяется сервером. При этом речь идет уже о передаче не экземпляра объекта, а его типа. То есть имя присваивается не экземпляру, а типу. И для обработки каждого вызова удаленного метода может создаваться собственно новый экземпляр объекта. При этом используется метод 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.