[обновление]: Вот и хорошая статья: http://blogs.msdn.com/drnick/archive/2008/10/08/working-with-session-state.aspx
Одной из концепций, которая иногда смущает разработчиков ASP.NET при переходе на WCF, является понятие состояния сеанса. В обычных службах WCF все состояние сеанса хранится в локальной энергозависимой памяти. Прикладная программа должна выбрать копирование части состояния сеанса в долговременное хранилище, чтобы это состояние сохранялось во всех запущенных экземплярах. WCF не имеет встроенной опции для включения постоянного хранения состояния сеанса или доступа к состоянию сеанса из других процессов.
Есть несколько способов сделать WCF более похожим на ASP.NET.
Один из способов сделать WCF более похожим на ASP.NET - это сделать WCF точно таким же, как ASP.NET, включив режим совместимости с ASP.NET. Приложение WCF, которое размещено в IIS и использует HTTP в качестве транспортной привязки, работает вместе с конвейером ASP.NET, но не имеет доступа ко многим функциям ASP.NET. Включение режима совместимости интегрирует приложение WCF с конвейером ASP.NET и делает доступными многие из этих функций. Очевидно, что этот подход интересен только тогда, когда ваша служба WCF уже очень похожа на приложение ASP.NET.
Другой способ сделать WCF более похожим на ASP.NET - изменить управление состоянием сеанса WCF, чтобы использовать удаленное долговременное хранилище, а не локальную энергозависимую память. Этот подход больше похож на тот, который используется сервисами рабочих процессов для создания надежных приложений. Управление экземплярами службы и контекстами экземпляра контролируется IInstanceProvider, который создает и уничтожает объекты службы, IInstanceContextProvider, который создает и уничтожает контексты экземпляра, и IInstanceContextInitializer, который устанавливает вновь полученные контексты экземпляра. Хотя долгосрочные службы имеют другую семантику, чем состояние сеанса, существуют общие строительные блоки, которые можно использовать для обоих. [/ обновление]
В дополнение к вышесказанному я могу предложить вам несколько вещей. Взгляните на этот пост для одного из них: /199117/postoyanstvo-dannyh-wcf-mezhdu-sessiyami. Далее рассмотрим использование какой-либо формы кэша. Это может быть служба стиля кэша или ферма кэша Подробнее о кешировании читайте в моем посте здесь: System.Web.Caching vs. Enterprise Library Caching Block
Это, в основном, позволит вам сохранить уникальный ключ для пользователя (похожий на идентификатор сеанса), и все так называемые объекты сеанса для этого пользователя будут иметь префикс с псевдосессионным идентификатором пользователя на уровне кэширования. Этот слой кэширования может затем вызываться веб-сайтом, который вы используете для запуска своего сайта, а также различными службами / проектами WCF.