Недопустимый или маркер контекста защиты с истекшим сроком в веб-сервисе WCF

Question

Недопустимый или маркер контекста защиты с истекшим сроком в веб-сервисе WCF

Я использую этого помощника:

public static class ObjectToDictionaryHelper
{
    public static IDictionary<string, object> ToDictionary(this object source)
    {
        return source.ToDictionary<object>();
    }

    public static IDictionary<string, T> ToDictionary<T>(this object source)
    {
        if (source == null)
            ThrowExceptionWhenSourceArgumentIsNull();

        var dictionary = new Dictionary<string, T>();
        foreach (PropertyDescriptor property in TypeDescriptor.GetProperties(source))
            AddPropertyToDictionary<T>(property, source, dictionary);
        return dictionary;
    }

    private static void AddPropertyToDictionary<T>(PropertyDescriptor property, object source, Dictionary<string, T> dictionary)
    {
        object value = property.GetValue(source);
        if (IsOfType<T>(value))
            dictionary.Add(property.Name, (T)value);
    }

    private static bool IsOfType<T>(object value)
    {
        return value is T;
    }

    private static void ThrowExceptionWhenSourceArgumentIsNull()
    {
        throw new ArgumentNullException("source", "Unable to convert object to a dictionary. The source object is null.");
    }
}

используется только для вызова .ToDictionary() объекта

Надеюсь, это поможет.

6

c# wcf iis active-directory wcf-security

задан 26 May 2009 в 20:29

3 ответа

Другие вопросы по тегам:

c# wcf iis active-directory wcf-security

Похожие вопросы:

score 1 · Answer 1

Я считаю, что здесь происходит тайм-аут вашего канала (как вы подозреваете).

Если я правильно понимаю, это не вызовы службы A , которые истекают, а скорее для обслуживания B , до того, как вы вызовете свою операцию.

Я предполагаю, что вы создаете свой канал до вы позвоните в службу A , а не как раз вовремя (то есть до вызова службы B ). Вы должны создать канал (прокси, сервисный клиент) непосредственно перед его использованием, например:

AResponse aResp = null;
BResponse bResp = null;
using (ServiceAProxy proxyA = new ServiceAProxy())
{
   aResp = proxyA.DoServiceAWork();
   using (ServiceBProxy proxyB = new ServiceBProxy())
   {
      bResp = proxyB.DoOtherork(aResp);
   }
}
return bResp;

Однако я считаю, что как только вы преодолеете эту проблему (время ожидания службы B), вы поймете, что прокси-сервер приложения sharepoint (который вызвал службу A ) истечет. Чтобы решить эту проблему, вы можете захотеть изменить свою модель обслуживания с запроса-ответа на модель публикации-подписки.

Для длительно работающих служб вам нужно, чтобы ваше приложение sharepoint подписывалось на службу A и имело службу A публикует свои результаты, когда они будут готовы к этому - независимо от того, сколько времени это займет.

Программирование служб WCF (O'Reilly) Джувалом Лоуи имеет отличное объяснение, а IDesign (компания Джувала) опубликовал a отличный набор стандартов кодирования для WCF , а также код для отличной Publish-Subscribe Framework .

Надеюсь, это поможет, Ассаф.

score 5 · Answer 2

10 минут - время ожидания приема по умолчанию. Если прокси-сервер простаивает более 10 минут, сеанс безопасности этого прокси прерывается сервером. Включите ведение журнала, и вы увидите это в журнале диагностики сервера. Сообщение об ошибке, о котором вы сообщили, подходит для этого поведения. Найдите в файле диагностики вашей системы "SessionIdleManager". Если вы его обнаружите, то проблема заключается в приведенном выше.

Дайте ему пофиг и установите installSecurityContext = "false" для клиента и сервера.

score 3 · Answer 3

Не вызывайте операцию службы в операторе using. Вместо этого используйте такой шаблон, как ...

client = new ServiceClient("Ws<binding>")
try
{
    client.Operation(x,y);
    client.Close();
}
catch ()
{
    client.Abort();
}

Я не понимаю, почему это работает, но я предполагаю, что когда прокси выходит за пределы области действия в операторе using, Close не вызывается. Затем служба ожидает, пока не истечет значение receiveTimeout (для привязки), а затем прерывает соединение, вызывая сбой последующих вызовов.