ST>В этом случае меня очень сильно смущает ConcurrencyMode.Single

ST>The service instance is single-threaded and does not accept reentrant calls. If the InstanceContextMode property is Single, and additional messages arrive while the instance services a call, these messages must wait until the service is available or until the messages time out.

С этим я разобрался. InstanceContextMode однозначно Single. Иначе что же я буду опрашивать если при каждом опросе будет создаваться новый экземпляр опрашиваемого класса.
ConcurrencyMode в случае Single в тестовом приложении запросы накапливаются пока процессор занят, потом быстренько друг за дружкой выполняются. В случает Multiple тоже ждут процессора, потом выполняются параллельно.
Смущает, что они сразу не выполняются.

ST>Потом, я очень надеюсь, что IThread — это всего лишь пример, а не реальный код, поскольку текущий пример никак не вяжется с моим видением дизайна вообще и SOA, в частности. Так, меня смущают имена (они ничего не говорят о том, что они делают), меня смущают типы (почему Status возвращает массив байт?, почему StatusSimple — это int)? Если это все в качестве тестов, то ОК, если из этого "прототипа" что-то переедет в продакшн, то это не хорошо.

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

ST>К тому же, сюда очень классно ложится идея реактивного программирования

Автор: Тепляков Сергей Владимирович
Дата: 06.02.11

вообще, и упомянутых callback интерфейсов в частности.

Rx, конечно, хорошо. Читал это, вещь классная. Но как выйти с этим за пределы .NET я пока не представляю

ST>В результате, я бы дизайнил сервис таким образом: есть метод сервиса:

ST>[c#]
ST>[ServiceContract(CallbackContract = typeof(ICustomServiceCallback)]
ST>public interface ICustomService
ST>{
ST> // Метод должен называться так, чтобы было понятно, что он делает.
ST> // вообще говоря, taskCount и actionsCount — это деталь реализации сервиса и должна
ST> // управляться именно им. Ведь именно при деплоя сервиса будет известно, какое
ST> // количество одновременных задач является максимально эффективным с точки зрения эффективности
ST> // Метод возвращает некий session id, который мы потом будет передавать в callback-и,
ST> // чтобы клиент понял, для какого запроса приходят данные
ST> string StartProcessing();
ST>}

ST>public interface ICustomServiceCallback
ST>{
ST> // Через этот метод мы будем уведомлять клиента о том, что операция исполняется
ST> // и мы уже получили некоторые результаты
ST> void Progress(string correlationId, CustomType[] processedData);
ST>}
ST>[c#]

Спасибо за подсказку!
Осталось мне в принципе получить представление о реализации push-модуля в веб. Подписываться на события изменения состояний сервера, конечно, правильнее чем постоянные его опросы. Но хочется что бы это было реализуемо без требований открытия дополнительных портов или поддержки каких то протоколов, менее распространённых чем HTTP.

ST>В общем, мне кажется, что вы смешиваете проблему параллелизма с WCF-ом, при этом каждая из этих проблем довольно сложная. WCF сервисы не должны выполнять такую бизнес-логику, как многопоточный процессинг изображений и уж точно клиент не должне задвать, во сколько рук мы будем получать результаты. Ведь параллелизм определяется количеством физических процессоров (или ядер) на сервисе и неправильное количество рабочих потоков просто убъет всю производительность!

Может с изображением погорячился, но измерил процессинг изображения 2000x2000 выполняется 200мс. У меня изображение в случае 5 потоков в 20 раз меньше, думаю достаточно быстро. Готов пример переделать на возврат коллекций данных, что быстрее. Не мне кажется загвозтка не в этом.
А о количестве потоков заботится Task.Factory

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

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