Моделирование клиентского контекста в WCF Web API с помощью MEF - PullRequest
Новая
       53

Моделирование клиентского контекста в WCF Web API с помощью MEF

1 голос
/ 11 ноября 2011

Мне нужно извлечь несколько значений заголовка в начале каждого запроса и поместить их в объект ClientContext, который может быть вставлен в код моего приложения MEF. Я использую Preview 5 веб-API WCF и не вижу способа сделать это.

В «стандартном» WCF я создал бы класс, который реализует IExtension и имел бы следующее свойство для соединения всего этого вместе: 

[Export(typeof(IClientContext)]
[PartCreationPolicy(CreationPolicy.NonShared)]
public static ClientContextExtension Current
{
    get
    {
        var operationContext = OperationContext.Current;

        if (operationContext == null)
            return null;

        var extension = operationContext.Extensions.Find<ClientContextExtension>();

        if (extension == null)
        {
            extension = new ClientContextExtension();

            operationContext.Extensions.Add(extension);
        }

        return extension;
    }
}

Пользовательский DelegatingHandler вызывает ClientContextExtension.Current и устанавливает свойства из значений заголовка. К сожалению, с веб-API WCF OperationContext.Current всегда равен нулю!

Я не могу найти способ заставить эту работу работать с Web API. Любая помощь приветствуется !!!

Ответы [ 2 ]

1 голос
/ 16 ноября 2011

Я нашел рабочее решение, но остаюсь открытым для других вариантов. Во-первых, какое-то обоснование оригинального подхода ...

Поскольку WCF использует пул потоков, все, что основано на модели для каждого потока, может (и будет) иметь время жизни, которое выходит за рамки отдельного запроса. Мне нужен был способ хранения информации контекста клиента, извлекаемой из заголовков HTTP для каждого запроса, так как каждый раз информация будет отличаться. Это означает, что я не могу сохранить контекстную информацию для каждого потока, потому что поток будет использоваться повторно.

Или я могу?

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

Мое решение состояло в том, чтобы реорганизовать свойство Current для ссылки на частное статическое поле, помеченное атрибутом [ThreadStatic ()], чтобы каждый экземпляр был специфичен для потока. Затем в моем DelegatingHandler, который выполняется для каждого запроса, я сбрасываю свойства объекта для этого запроса. Последующие вызовы Current во время этого запроса возвращают информацию, специфичную для запроса, и следующий запрос, обрабатываемый потоком, обновляется в DelegatingHandler, так что, насколько это касается моего другого кода, контекст для каждого запроса.

Не идеально, но это, по крайней мере, заставляет меня начать работать на данный момент. Как я уже сказал, я открыт для других решений.

UPDATE

При ближайшем рассмотрении это решение не работает, так как нет никакой привязки потока между DelegatingHandler и сервисным кодом, который использует объект контекста. В результате, иногда мой вызов для извлечения объекта ThreadStatic работает как положено, но в других случаях я получаю новый экземпляр, потому что код работает в потоке, отличном от обработчика.

Итак, не обращайте внимания на это решение. Вернуться к чертежной доске.

ОБНОВЛЕНИЕ ДО МОЕГО ОБНОВЛЕНИЯ

После обсуждения моей проблемы с Glenn Block выясняется, что нужно просто убедиться, что контекст установлен в том же потоке, который выполняет обработчик запросов (служба). Решение состоит в том, чтобы использовать HttpOperationHandler вместо MessageHandler.

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

Итак, я просто переместил свой код из MessageHandler в HttpOperationHandler и получил желаемые результаты.

Вы можете прочитать полное объяснение здесь: http://sonofpirate.blogspot.com/2011/11/modeling-client-context-in-wcf-web-api.html

0 голосов
/ 11 ноября 2011

Вы можете попробовать использовать 

HttpOperationHandler<HttpRequestMessage, HttpRequestMessage>

Там вы должны иметь доступ к заголовкам.

...