Различие начинается здесь. Мы должны создать локально экземпляр удаленного класса приемника

. Так как этот класс не будет конфигурироваться элементом , то его экземпляр создается локально. Затем мы получаем экземпляр класса удаленного объекта . Этот класс конфигурируется в элементе , поэтому его экземпляр создается на удаленном сервере:

Теперь можно зарегистрировать метод обработчика объекта

на удаленном объекте. является именем делегата, который был определен на сервере. Метод имеет те же самые аргументы, которые определены в .

Вызывая метод

, сервер будет делать обратный вызов в методе в начале и в конце метода:

Теперь мы более не заинтересованы в получении событий с сервера и отменяем подписку на событие. Следующий раз при вызове

никакие события не будут получены.

Конфигурационный файл для клиента —

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

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

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

В выводе клиента видно, что события достигают его по сети:

Активированные клиентом объекты могут сохранять состояние для определенного клиента. Для активированных клиентом объектов на сервере требуются ресурсы. Для активированных сервером объектов

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

Контекст вызова перемещается вместе с логическим потоком выполнения и передается с каждым вызовом метода. Логический поток выполнения запускается из вызывающего потока выполнения и перемещается через все вызовы методов, которые запускаются из вызывающего потока выполнения и передаются через различные контексты, различные домены приложений и различные процессы.

Можно присвоить данные контексту вызова с помощью метода

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