У нас есть большое, сложное приложение Silverlight, которое взаимодействует с нашей базой данных посредством асинхронных вызовов WCF. В число функций входит специальный инструмент создания отчетов, который позволяет пользователям создавать и запускать отчеты с различными настройками параметров.
Рендеринг отчетов занимает много времени (10-120 секунд) и занимает память и процессорное время на сервере, поэтому он кажется хорошим первым кандидатом для микросервисов. Наш сервер приложений / IIS будет передавать запросы на рендеринг отчетов через очередь сообщений на наш сервер рендеринга. По завершении сервер рендеринга будет использовать в очереди сообщение, готовое к отправке. Размер двоичных массивов отчета может составлять несколько мегабайт.
Разум для меня - как переключиться обратно с этой отключенной парадигмы обмена сообщениями обратно на парадигму запроса-ответа WCF?
Я в порядке с использованием async / await в методе WCF RenderReport (). Но это только углубляет проблему в код. Каким-то образом Мне нужно сделать «фазовый сдвиг» от обмена сообщениями до запроса-ответа.
Возможные ответы?
- Включить клиента Silverlight в парадигму обмена сообщениями, используя дуплексный WCF, и использовать все еще открытое соединение для передачи данных отчета при его получении? Это вносит большую сложность, чем я хотел бы взять на себя сейчас, и предпочел бы не дублировать WCF, поскольку мы смотрим на переход к REST.
- Включить Silverlight в обмен сообщениями, добавив SignalR в Silverlight, и пусть он сигнализирует клиенту, что данные отчета готовы для получения? Но SignalR может отправить только несколько килобайт, поэтому я не могу отправить сами данные отчета ... и опять же, это добавляет сложности и еще одного обхода для сбора данных.
- Откажитесь от «push» сообщений и просто проведите опрос Silverlight для получения результатов.
Я скучаю по другим альтернативам?