WCF Управление информацией состояния сеанса

Question

Что является самым масштабируемым способом управления состоянием в WCF.

Мне нужна только одна переменная, указывающая сеанс, и я буду управлять информацией относительно сеанса в MSSQL. Мне не нужно знать, когда закончится сеанс. Раз в день я просто убираю любые старые сеансы.

Появляется SessionID - это переменная.

Для масштаба я использую Per Call, поскольку ctor пуст. Я не думаю, что мне нужно за сеанс.

В моем простом тесте EightBall я получаю SessionID, который представляет сеанс. Но я просто тестирую одну коробку.

Что меня беспокоит, так это то, что я вижу документацию, необходимую мне для установки ReliableSessionBindingElement On и по умолчанию она выключена.

Является ли SessionID надежным индикатором сеанса в следующей конфигурации?

<system.serviceModel> 
    <services> 
     <service name="MajicEightBallServiceLib.MagicEightBallService" 
       behaviorConfiguration="EightBallServiceMEXBehavior" > 
     <endpoint address="" 
        binding="wsHttpBinding" 
        contract="MajicEightBallServiceLib.IEightBall" /> 
     <endpoint address="mex" 
        binding ="mexHttpBinding" 
        contract="IMetadataExchange" /> 
     <host> 
      <baseAddresses> 
      <add baseAddress="http://localhost:8000/MagicEightBallService"/> 
      </baseAddresses> 
     </host>    
     </service> 
    </services> 
    <behaviors> 
     <serviceBehaviors> 
     <behavior name="EightBallServiceMEXBehavior"> 
      <serviceMetadata httpGetEnabled="true"/> 
     </behavior> 
     </serviceBehaviors> 
    </behaviors> 
    </system.serviceModel> 

[ServiceBehavior (InstanceContextMode=InstanceContextMode.PerCall)] 
public class MagicEightBallService : IEightBall 
{ 
    public MagicEightBallService() 
    { 
     Console.WriteLine("Eightball awaits your question ..."); 
    } 
    public string ObtainAnswerToQuestion(string userQuestion) 
    { 
     return "maybe " + OperationContext.Current.SessionId.ToString(); 
    } 

    public sDoc GetSdoc(int sID) 
    { 
     List<sDocProp> props = new List<sDocProp>(); 
     sDocProp prop1 = new sDocProp { ID = 1, Name = "Prop1", ArrivalStatus = ArrivalStatus.OnTime }; 
     props.Add(prop1); 
     sDocPropStringSV prop2 = new sDocPropStringSV { ID = 1, Name = "Prop1", ArrivalStatus = ArrivalStatus.OnTime, Value = "StrValue1" }; 
     props.Add(prop2); 
     sDoc sDoc = new sDoc { sID = sID, sParID = 1, Props = props, SessionID = OperationContext.Current.SessionId.ToString() }; 
     return sDoc; 
    } 

Answer 1

WCF поддерживает 4 типа сеансов и надежную сессию - это только один из них. Поэтому вам не нужно включать set ReliableSessionBindingElement On для включения сеанса. Вы можете использовать другие типы сеансов.

System.ServiceModel.Channels.ReliableSessionBindingElement, который реализует спецификацию WS-ReliableMessaging, обеспечивает поддержку надежных сеансов, в которых сообщения доставляются в порядке и ровно один раз, позволяя с уверенностью, даже если сообщения проходят через несколько узлов во время разговора.

Фактически wsHttpBinding по умолчанию использует безопасный сеанс, который шифрует и подписывает цифровые сообщения.

Является ли SessionID надежным индикатором сеанса в следующей конфигурации?

Служба может проверить, не привязано ли ваше привязку к использованию сеанса с использованием атрибута ServiceContractAttribute.SessionMode.

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

[ServiceContract(SessionMode = SessionMode.Required)] 
public interface IEightBall 

http://msdn.microsoft.com/en-us/library/system.servicemodel.servicecontractattribute.sessionmode.aspx

Самый scaleble способ управления состоянием в WCF.

InstanceContextMode.PerCall - это правильный выбор, если ваш код не зависит от данных сеанса, кроме идентификатора сеанса. Идентификатор сеанса является частью сообщения WCF, поэтому нет необходимости хранить InstanceContext дольше, чем необходимо для обработки запроса.

Другой вопрос:

ли SessionID будет надежным индикатором сессии в следующие конфигурации?

Ответ ДА. Ниже представлен обратный код недвижимости System.ServiceModel.OperationContext.SessionId. Как видите, SessionId загружается с Channel.Session и не пуст SessionId Значение возвращается, только если Session не равно null.

public string SessionId 
{ 
    get 
    { 
     if (this.channel != null) 
     { 
      IChannel innerChannel = this.channel.InnerChannel; 
      if (innerChannel != null) 
      { 
       ISessionChannel<IDuplexSession> sessionChannel = innerChannel as ISessionChannel<IDuplexSession>; 
       if (sessionChannel != null && sessionChannel.Session != null) 
       { 
        return sessionChannel.Session.Id; 
       } 
       ISessionChannel<IInputSession> sessionChannel2 = innerChannel as ISessionChannel<IInputSession>; 
       if (sessionChannel2 != null && sessionChannel2.Session != null) 
       { 
        return sessionChannel2.Session.Id; 
       } 
       ISessionChannel<IOutputSession> sessionChannel3 = innerChannel as ISessionChannel<IOutputSession>; 
       if (sessionChannel3 != null && sessionChannel3.Session != null) 
       { 
        return sessionChannel3.Session.Id; 
       } 
      } 
     } 
     return null; 
    } 
}