Сеансы, инстантирование и параллелизм

Сеанс — это корреляция всех сообщений, отправленных между двумя конечными точками. Instancing относится к управлению временем существования определяемых пользователем объектов службы и связанных InstanceContext с ними объектов. Конкуренция — это термин, который используется для управления количеством потоков, выполняющихся одновременно в InstanceContext.

В этом разделе описаны эти параметры, их использование и различные взаимодействия между ними.

Сеансы

Когда контракт службы задает ServiceContractAttribute.SessionMode свойство SessionMode.Required, этот контракт говорит, что все вызовы (т. е. базовые обмены сообщениями, поддерживающие вызовы), должны быть частью одной беседы. Если контракт указывает, что он разрешает сеансы, но не требует их, клиенты могут подключаться и устанавливать сеанс или нет. Если сеанс заканчивается и сообщение отправляется через тот же сеансовый канал, возникает исключение.

Сеансы WCF имеют следующие основные концептуальные функции:

• Они явно инициируются и завершаются приложением, которое их вызывает.

• Сообщения, доставленные во время сеанса, обрабатываются в том порядке, в котором они получаются.

• Сеансы связывают группу сообщений в разговор. Смысл этой корреляции — абстракция. Например, один канал на основе сеансов может коррелировать сообщения на основе общего сетевого подключения, а другой канал на основе сеансов может коррелировать сообщения на основе общего тега в тексте сообщения. Характеристики, которые могут быть получены из сеанса, зависят от характера корреляции.

• Общее хранилище данных не связано с сеансом WCF.

Если вы знакомы с классом System.Web.SessionState.HttpSessionState в ASP.NET приложениях и функциональных возможностях, которые он предоставляет, вы можете заметить следующие различия между этим типом сеансов и сеансов WCF:

• ASP.NET сеансы всегда инициируются сервером.

• ASP.NET сеансы неявно неупорядочены.

• ASP.NET сеансы предоставляют общий механизм хранения данных в запросах.

Клиентские приложения и приложения-службы взаимодействуют с сеансами разными способами. Клиентские приложения инициируют сеансы, а затем получают и обрабатывают сообщения, отправленные в сеансе. Приложения-службы могут использовать сеансы в качестве точки расширяемости для добавления дополнительного поведения. Это может быть достигнуто путем работы непосредственно с InstanceContext или за счет реализации пользовательского поставщика контекста экземпляра.

Инстанцирование

Поведение инстанцирования (заданное с помощью свойства ServiceBehaviorAttribute.InstanceContextMode) определяет, как InstanceContext создается в ответ на входящие сообщения. По умолчанию каждое InstanceContext связано с одним определяемым пользователем объектом службы, поэтому (в случае по умолчанию) свойство InstanceContextMode также управляет отображением определяемых пользователем объектов службы. Перечисление InstanceContextMode определяет режимы вставки.

Доступны следующие режимы инстантирования:

• PerCall: для каждого запроса клиента создается новый InstanceContext (и, следовательно, объект службы).

• PerSession: создается новый InstanceContext (и поэтому объект службы) для каждого нового клиентского сеанса и сохраняется в течение всего времени существования этого сеанса (для этого требуется привязка, поддерживающая сеансы).

• Single: один InstanceContext (и, следовательно, объект службы) обрабатывает все клиентские запросы на время существования приложения.

В следующем примере кода показано значение по умолчанию InstanceContextMode , PerSession явно заданное в классе службы.

[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerSession)]
public class CalculatorService : ICalculatorInstance
{
    ...  
}  

А если свойство ServiceBehaviorAttribute.InstanceContextMode определяет, как часто InstanceContext освобождается, то свойства OperationBehaviorAttribute.ReleaseInstanceMode и ServiceBehaviorAttribute.ReleaseServiceInstanceOnTransactionComplete отвечают за то, когда освобождается объект службы.

Well-Known одноэлементные службы

Один вариант использования объектов службы для одиночных экземпляров иногда полезен: можно создать объект службы самостоятельно и создать узел хостинга службы с помощью этого объекта. Для этого необходимо также задать свойство ServiceBehaviorAttribute.InstanceContextMode как Single, иначе при открытии узла службы будет вызвано исключение.

ServiceHost(Object, Uri[]) Используйте конструктор для создания такой службы. Он предоставляет альтернативу реализации пользовательского System.ServiceModel.Dispatcher.IInstanceContextInitializer, когда необходимо предоставить конкретный экземпляр объекта для использования одиночным сервисом. Эту перегрузку можно использовать, если тип реализации службы сложно создать (например, если он не реализует общедоступный конструктор без параметров).

Обратите внимание, что при предоставлении объекта этому конструктору некоторые функции, связанные с поведением Windows Communication Foundation (WCF), работают иначе. Например, вызов InstanceContext.ReleaseServiceInstance не действует при предоставлении экземпляра объекта-одиночки. Аналогичным образом игнорируется любой другой механизм выпуска экземпляра. ServiceHost всегда действует так, как если бы свойство OperationBehaviorAttribute.ReleaseInstanceMode было установлено на ReleaseInstanceMode.None во всех операциях.

Общий доступ к объектам InstanceContext

Вы также можете контролировать, с каким каналом сеанса или вызовом связан объект InstanceContext, выполняя эту связь самостоятельно.

Конкурентность

Конкурентность — это управление количеством потоков, активных в InstanceContext в любой момент времени. Это контролируется при помощи ServiceBehaviorAttribute.ConcurrencyMode и перечисления ConcurrencyMode.

Доступны следующие три режима параллелизма:

• Single: В каждом контексте экземпляра допускается максимум один поток для обработки сообщений одновременно. Другие потоки, желающие использовать тот же контекст экземпляра, должны блокироваться, пока исходный поток не выйдет из контекста экземпляра.

• Multiple: каждый экземпляр службы может одновременно обрабатывать несколько сообщений с помощью потоков. Реализация службы должна быть потокобезопасной для использования этого режима параллелизма.

• Reentrant: каждый экземпляр службы обрабатывает одно сообщение за раз, но принимает рекурсивные вызовы операций. Служба принимает эти вызовы только при вызове через клиентский объект WCF.

Использование параллелизма связано с режимом инстантирования. При PerCall инстантинге параллелизм не имеет значения, так как каждое сообщение обрабатывается новым InstanceContext и, следовательно, никогда не активен в одном потоке InstanceContext.

В следующем примере кода демонстрируется установка свойства ConcurrencyMode в значение Multiple.

[ServiceBehavior(ConcurrencyMode=ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.Single)]
public class CalculatorService : ICalculatorConcurrency
{
    ...  
}  

Сеансы взаимодействуют с параметрами InstanceContext

Сеансы и InstanceContext взаимодействуют в зависимости от комбинации значения перечисления SessionMode в контракте и свойства ServiceBehaviorAttribute.InstanceContextMode в реализации службы, которое управляет связью между каналами и конкретными объектами службы.

В следующей таблице показаны результаты входящего канала, либо поддерживающего сеансы, либо не поддерживающего сеансы, для комбинации значений свойства ServiceContractAttribute.SessionMode и свойства ServiceBehaviorAttribute.InstanceContextMode службы.

См. также

• Использование сеансов
• Практическое руководство. Создание службы, требующей сеансов
• Практическое руководство. Управление инстантированием службы
• Параллелизм
• Сессия