Учитывая использование WCF для службы журналов ... Пожалуйста, сообщите - PullRequest
4 голосов
/ 13 апреля 2011

Я рассматриваю архитектуру для службы регистрации предприятия.Его работа будет заключаться в том, чтобы получать и хранить сообщения журнала, а затем разрешать пользователям доступ к этим сообщениям журнала.Вместо того, чтобы встраивать функциональность регистрации в нашу существующую службу Windows, которая будет использовать ее сейчас, нам нужно разделить ее, чтобы другие службы могли использовать ее в ближайшем будущем.Мне нравится тот факт, что наши различные сервисы могут регистрировать свои сообщения через net.tcp, а затем я могу создать интерфейс RESTful для доставки определенных сообщений журнала в браузеры или что-либо еще.

Может ли кто-нибудь говорить о мудрости или отсутствииследующие варианты:

  1. Использовать WCF для службы журналов
  2. Использовать net.tcp для транспорта
  3. Размещать службу в проекте службы Windows (используя ServiceHost)

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

Единственный сервис, который у нас сейчас есть, который будет использовать этот сервис журналирования, довольно многословен и будет отправлять журнал.сообщения очень часто (~ 40-100k / день).Я еще не создал прототип и не проводил никаких сравнительных тестов, и я знаю, что я не даю вам достаточно подробностей, чтобы принять окончательное решение, но я просто ищу некоторые направления и соображения на данный момент.Спасибо.

Ответы [ 3 ]

5 голосов
/ 13 апреля 2011

Существуют и другие альтернативы созданию еще одного сервиса только для регистрации.Вы можете построить протоколирование в качестве аспекта и прикрепить / отсоединить этот аспект (он же инжектировать), как и когда это требуется любым ServiceContract или OperationContract.Таким образом, вы отделяете протоколирование, но это позволяет избежать дополнительных затрат на вызов еще одной службы при каждом вызове.После того как вы создадите эти аспекты, скомпилируйте их в отдельный двоичный файл и используйте их по мере необходимости во всех ваших будущих службах. Включение и отключение определенных сценариев ведения журналов более приемлемо для IMO по сравнению с выделенной службой только для ведения журналов.

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

Важная документация MSDN, которую вы хотели бы просмотреть.

Редактировать - Пример кода

С приведенным ниже кодом вы добавляете [OperationLogging] над любым вашим договором на эксплуатацию, и вы можете перехватывать вызовы к этому договору на операции в LoggingInspector.BeforeCall.

Использование [ServiceLogging] в любом договоре на обслуживаниеа такжевсе операции, определенные в этих вызовах службы, могут быть перехвачены и зарегистрированы.

Установите для your_app_config_key значение, отличное от TRUE, эти дополнительные действия не добавляются в ваш конвейер службы.Это очень круто, поскольку ни один из этого кода не выполняется на основе этого ключа в конфигурации.

public class LoggingInspector : IParameterInspector
{
    private string service;
    public LoggingInspector(string serviceName){ service = serviceName;}
    public void AfterCall(string operationName, object[] outputs, object returnValue, object correlationState){}
    public object BeforeCall(string operationName, object[] inputs)
    {
      // your logging logic
    }
}

 //Operation Logging attribute - applied to operationcontracts.
 [AttributeUsage(AttributeTargets.Method)]
 public class OperationLoggingAttribute : Attribute, IOperationBehavior
 {
    public void AddBindingParameters(OperationDescription operationDescription, BindingParameterCollection bindingParameters){}
    public void ApplyClientBehavior(OperationDescription operationDescription, ClientOperation clientOperation){}
    public void ApplyDispatchBehavior(OperationDescription operationDescription, DispatchOperation dispatchOperation)
    {
        if (ConfigurationManager.AppSettings["your_app_config_key"] == "TRUE")
            dispatchOperation.ParameterInspectors.Add(new LoggingInspector(dispatchOperation.Parent.Type.Name));
    }
    public void Validate(OperationDescription operationDescription){}
 }

 //Service Loggign attribute - applied to Service contract
[AttributeUsage(AttributeTargets.Class)]
public class ServiceLoggingAttribute : Attribute, IServiceBehavior
{
    public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters){}
    public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
        if (ConfigurationManager.AppSettings["your_app_config_key"] == "TRUE")
            foreach (ServiceEndpoint endpoint in serviceDescription.Endpoints)
                foreach (OperationDescription operation in endpoint.Contract.Operations)
                    operation.Behaviors.Add(new OperationLoggingAttribute());

    }
    public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase){}
}
1 голос
/ 13 апреля 2011

В принципе, я думаю, что отдельная служба аудита имеет смысл, если она попадает в ограниченный контекст ваших приложений. У IDesign есть пример реализации журнала ES здесь (см. «Журнал служб предприятия»). Вы можете провести некоторое первоначальное тестирование, чтобы увидеть, сможет ли оно справиться с ожидаемыми нагрузками. Если вы беспокоитесь о производительности, я бы рассмотрел очереди сообщений через tcp (пример приложения регистрации также поддерживает это). Что касается хостинга, служба должна быть всегда запущена, поэтому Windows Service имеет смысл. Если вы хотите использовать IIS, я бы предложил использовать Windows Server AppFabric и включить функцию автозапуска приложения.

НТН.

0 голосов
/ 13 апреля 2011

Читая вопрос, я хочу поделиться своими мыслями.Само ведение журнала не очень сложная деятельность, и было бы неплохо использовать WCF для создания корпоративной среды ведения журналов.Но данные, зарегистрированные только для регистрации, бесполезны.Эти данные затем должны быть использованы каким-либо процессом \ приложением и, следовательно, обеспечивают некоторую добавленную стоимость.Поэтому более важным аспектом ведения журнала являются

  • Какие данные регистрируются.
  • Как данные регистрируются, используются \ используются

Так что мой совет будетуделять больше времени размышлениям о том, что нужно регистрировать и какую ценность добавляют эти данные.

...