Альтернатива HttpContext при использовании NInject с WCF-службой, размещенной в WAS с использованием связывания MSMQ

У меня есть односторонняя служба WCF, использующая привязку MSMQ, которая активируется с помощью службы активации Windows в IIS 7.0.

Я большой поклонник NInject, поэтому я использовал расширение NInject для WCF, которое для типичного сервиса HTTP WCF будет работать отлично.

Однако в WAS активировать службы нет HTTP-конвейера, поэтому я не могу использовать InRequestScope при привязке моих типов, потому что System.Web.HttpContext.Current имеет значение null. Я изо всех сил пытаюсь найти альтернативу при использовании WAS, который даст мне то, что я хочу. Атрибут режима AspCompatibility не работает в этом режиме.

Я думал, что InThreadScope может работать, но сервис создается в отдельном потоке, чем в том, что он выполняется.

Поэтому в основном мне нужен эквивалент HttpContext для WCF + WAS для охвата моих объектов на уровне запроса. Есть ли какой-то статический объект в этом мире, который будет работать одинаково или кто-нибудь еще имеет какие-то идеи о чем-то, что я могу взломать вместе?

Ответ 1

Я реализовал свои собственные расширения WCF для Ninject 2.0, прежде чем понял, что на github есть this. Моя реализация немного отличается, но я придумал решение для объектов с областью видимости:

using System;
using Ninject.Activation;

namespace Ninject.Contrib.Wcf {
  /// <summary>
  /// Defines Scope Callbacks for WCF Context.
  /// </summary>
  public class NinjectWcfScopeCallbacks {
    /// <summary>
    /// Defines WCF Context scope.
    /// </summary>
    public static readonly Func<IContext, object> WcfContext =
      ctx => (System.ServiceModel.OperationContext.Current != null
                ? System.ServiceModel.OperationContext.Current.
                    InstanceContext.
                    Extensions.Find<NinjectInstanceContext>()
                : null);

    /// <summary>
    /// Defines WCF Web Context scope.
    /// </summary>
    public static readonly Func<IContext, object> WcfWebContext = 
               ctx => System.ServiceModel.Web.WebOperationContext.Current;
  }
}

Для полноты я использую обратный вызов, указанный выше:

Bind<IHelloWorldService>()
        .To<HelloWorldService>()
        .InScope(NinjectWcfScopeCallbacks.WcfWebContext);

В WAS не размещены службы WCF, поэтому не уверены, что вы использовали бы описанные выше WcfWebContext или WcfContext, но вы можете попробовать их и посмотреть. Если WebOperationContext работает, тогда вы все настроены. В противном случае я обнаружил, что вещи немного сложнее. Вы заметите, что фрагмент кода выше использует класс NinjectInstanceContext, который привязан к OperationContext. Это класс, который я написал, который использует механизм "кэширования и сбора" Ninject 2.0, который позволяет детерминировать объекты. В принципе, класс реализует IExtension<InstanceContext>, который является конструкцией WCF для прикрепления почти к чему-либо к OperationContext. Этот класс также реализует интерфейс Ninject INotifyWhenDisposed, который обеспечивает поддержку для детерминированного удаления. Вот как выглядит определение класса:

  /// <summary>
  /// Defines a custom WCF InstanceContext extension that resolves service instances
  /// using Ninject.  
  /// <remarks>
  /// The custom InstanceContext extension provides support for deterministic disposal
  /// of injected dependencies and service instances themselves by being hook into 
  /// Ninject "cache and collect" mechanism (new in Ninject 2.0) for object life cycle 
  /// management.  This allows binding object instances to the lifetime of a WCF context
  /// and having them deterministically deactivated and disposed.
  /// </remarks>
  /// </summary>
  public class NinjectInstanceContext : 
                IExtension<InstanceContext>, INotifyWhenDisposed {
  }

Остальная часть моего расширения WCF для Ninject совпадает с one в github. Что в основном происходит, так это то, что создается поставщик экземпляров, который подключен к цепочке активации WCF - я не использую их специфическую терминологию, просто как я понимаю вещи. Итак, идея заключается в том, что поставщик вашего экземпляра должен предоставлять экземпляры запрашиваемого класса службы WCF. Итак, здесь, где мы используем Ninject для создания экземпляра службы. Поступая таким образом, мы также можем активировать и вводить любые зависимости. То, что поставщик экземпляра делает в моей реализации, завершает ядро Ninject в экземпляре if NinjectInstanceContext и прикрепляет его к OperationContext. Затем создание этой службы делегируется этому расширению WCF. Когда поставщику экземпляра сообщается о выпуске службы, удаляется NinjectInstanceContext, который был присоединен к OperationContext, который посредством реализации INotifyWhenDisposed вызывает детерминированное удаление службы (и, возможно, ее зависимостей).

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

Ответ 2

Я уверен, что OperationContext - это то, что вы ищете