Столкнулся с интересной ситуацией при работе с потоками в WCF. И как всегда спешу поделиться J.
Для некоторых ошибок WCF, например, ошибке MessageSecurityException реконмендуется пересоздавать клиентский проксик. При этом, существует несколько реализаций надежных прокси-классов, которые пересоздают и открывают заново коммуникационный канал. Ситуация вроде бы очевидная и имеет простое решение:
1. Обернуть прокси-класс с помощью еще одного проксика или другой обертки (я использую Spring.NET для этого), которая будет управлять временем жизни и состоянием клиентского проксика (есть еще вариант с работой непосредственно с каналом без использования автогенерируемого прокси-класса).
2. Соответственно при выполнении метода отлавливать нужные типы ошибок, пересоздавать реальный класс проксика и вызывать метод повторно с теми же аргументами.
Если пункт 1 в принципе понятен, то в пункте 2 могут быть проблемы связанные с аргументами метода.
В момент второго обращения аргументы могут стать невалидными. Пример таких аргументов – потоки. При первой отправке сообщения поток читается для сериализации. Так как поток сериализуется, начиная с текущей позиции, то при втором запросе уйдет пустой поток. Если конечно перед этим не сбросить его Position в 0.
Однако тут придется привязаться к DataContract, поскольку потоки могут не быть непосредственным контрактом данных, а содержаться как поле одного из контрактов. Как еще один вариант решения проблемы – прикручивать свой сериализатор, который сам будет уметь сбрасывать потоки в ноль, а потом отдавать стандартному DataContractSerializer.
Комментариев нет:
Отправить комментарий