Ниже расскажу о реализации проброса WCF запросов от одного сервера через несколько промежуточных, так называемый wcf tunneling, вопрос о реализации которого уже поднимался на gotdotnet.ru. Там автор предлагал использовать Castle.DynamicProxy для динамической генерации прокси-классов для создания канала. Однако комментаторы отметили, что полученный функционал дублирует лишь стандартные возможности при прямом взаимодействии точка-точка.
Актуальность приобретается, когда добавляется набор промежуточных точек. При этом на клиенте идет перехват вызова произвольной удаленной функции FuncName на вызов абстрактной функции object _DataTransfer(HeaderAuthen auth, object ServiceLink, object FuncName, object[] param); Далее обращение транслируется через серию промежуточных машин и в итоге обращение передается на ServiceLink, где обрабатывается. Также возвращается результат. Грубо говоря примитивный функционал Biztalk своими руками по передачи soap сообщений в многосвязной сети. Кроме того мы без ведома пользователя накладываем на канал защиту через HeaderAuthen auth.
Отдельно выкладываю реализацию класс DynamicServiceProxy и ServiceChannelManagerInterceptor, подменяющие вызов, а также сам вызов в ServiceChannelManager. Соответственно все закладывается в библиотеку, которая должна быть на всех точках, а на туннельных-промежуточных точках еще и реализуется Контранкт, в котором важно описать передаточную функцию _DataTransfer, все функции на конечных точках, а также все классы и типы через KnownTypeContainer. Также важно включить сериализатор XmlSerializerFormat, так как по умолчанию в WCF используется DataContractSerializer, которых не позволяет передавать object. То есть вызовы проходить будут, а данные - нет. Кроме того у XmlSerializerFormat тоже есть особенность, кто нельзя передать некоторые стандартные типы, например, DataSet как параметр, так как в них используется нетипизированный ArrayList. Вот пожалуй и все, что нужно знать.