Сервис это фасад к системе , не стоит в нем реализовывать логику. Лучше сделать так:при обращении к сервису создается задача (таск, заявка , заказ) ей присваивается id она кладется в очередь.Клиент пользуясь тем же сервисом видит свои задачи и их статусы. Обработка задач выполняется отдельным компонентом (пулом воркеров, каждый тащит задачи из очереди и меняет их статус после обработки, сохраняет результат). Если проект большой то стоит посмотреть в сторону CQRS (http://martinfowler.com/bliki/CQRS.html). В простом достаточно хранить задачи в базе и отдельно поднять компонент для их обработки (при этом обрабатывать может несколько инстансов и не обязательно на той же машине где крутится wcf, это увеличит масштабируемость и безопасность). Если сервисы под iis то тем более нужно разделять бизнес логику и фасадный интерфейс — iis может в любой момент выгрузить приложение из памяти и при следующем обращении оно начнет стартовать заново, что не всегда быстро. В идеале, сервис вообще не ходит в БД а общается с backend тогда можно закрыть доступ к БД из дмз , что правильнее сточки зрения безопасности.

Здравствуйте, Xenon_IPC, Вы писали:

X_I>Здравствуйте уважаемые гуру проектирования и разработки программного обеспечения.
X_I>Требуется разработать одну систему с небольшой нагрузкой (до нескольких десятков клиентов). Клиент постараюсь сделать максимально возможно тонким и бизнес-логику по максимуму вынести на сервер. Хотел бы посоветоваться с архитектурой серверной части. Общую идею попробовал изобразить на следующей картинке (клик чтобы увеличить):
X_I>
X_I>Интересуют следующие вопросы:
X_I>

X_I>1. Насколько из данного изображения понятна архитектура и основные внутренние процессы в системе
X_I>2. Насколько академически корректны данные условные обозначения (по возможности конкретизировать какие элементы изображены неверно и какое условное обозначение является для них верным)
X_I>3. Какие замечания собственно по самой архитектуре (что неверно, что можно улучшить)
X_I>

X_I>Чтобы внести ясность того насколько Ваше понимание системы после ознакомления с изображением соответствует тому что я хотел передать, постараюсь описать это словами:
X_I>на неком сервере (в intranet сети либо internet сети это собственно не важно) существует сервис который принимает соединения от удаленных клиентов. Для каждого подключенного клиента создается свой экземпляр сервиса в котором он работает (в терминологии WCF InstanceContextMode = PerSession). Вызовы с клиента являются асинхронными (для этого на изображении я попытался это обозначить с помощью дуги на стрелке), т.е. клиент при вызове метода не блокируется. Ответ от сервера является также асинхронным, по сути это callback на клиент с результатом либо некоторым извещением (например об ошибке или прогрессе операции). Другими словами обычный дуплексный режим. Далее, в сервисе существует некий синглтон-пул для работы с БД. Каждый экземпляр сервиса заносит свой запрос в этот пул, пул его обрабатывает и результат отдает обратно сервису по callback'у. У некоторых возможно возникнет вопрос, для чего понадобился пул запросов и почему к БД не обращаться непосредственно из сервера. Это вызвано одним из требованием к системе: клиент может сделать одновременно несколько запросов к серверу, которые должны выполняться параллельно. Т.е. например клиент хочет получить список заказов и пока они грузятся открывает новое окошко с каталогом продукции. В этом случае на сервер сначала идет запрос получить список заказов, этот запрос ложится в пул и сервис готов для приема следующего запроса: каталога продукции, который тоже ложится в пул и т.д. В пуле созданы 4 потока (думаю этот параметр сделать настраиваемым), которые ожидают появления новых запросов. Расположение БД не должно играть роль (будет находиться на том же компьютере либо на удаленном).
X_I>Вот, в общих чертах на словах схема работы серверной части. Прошу высказывайте свои комментарии и конструктивную критику.

X_I>С уважением, Александр