Если вы хотите приготовить дрожжевое тесто, а дрожжей у вас нет

… то ни хрена у вас не получится.

В общем, этот пост не про то, как надо что то делать, а про то, как у меня ничего не получилось. Кода в этот раз не будет, если кому то понадобится пример, выложу более подробную статью.

Исходная задачка была достаточно простой с точки зрения Enterprise приложения: обеспечить для WCF сервиса передачу больших данных с учетом аутентификации.

WCF использует два режима для передачи данных: Buffered и Streamed. Buffered режим соответствует первоначальной сериализации всего пакета данных в память с последующей передачей клиенту. Соответственно передача в Buffered режиме определяет несколько ограничений, как то ограничение на размер передаваемых данных. Buffered режим также не оптимален с точки зрения использования памяти (ну тут все понятно из описания).

Streamed режим предназначен для передачи данных потоком, без занесения всех их в память. Данный режим также накладывает ряд ограничений, но в общем случае это касается контракта данных. Так, тип возвращаемого параметра должен быть Stream или его наследником, тип параметра метода сервиса также должен быть потоком. Данное ограничение можно снять, если использовать контракты сообщений (MessageContracts).

Остальные ограничения Streamed режима можно понять, если учесть одно обстоятельство – ни принимающая, ни отправляющая сторона не знают размер потока. Если учесть этот факт, то понятны ограничении, означенные в статье Large Data and Streaming:

You cannot use a significant number of WCF features when streaming is enabled:

·         Digital signatures for the message body cannot be performed because they require computing a hash over the entire message contents. With streaming, the content is not fully available when the message headers are constructed and sent and, therefore, a digital signature cannot be computed.

·         Encryption depends on digital signatures to verify that the data has been reconstructed correc...