Enterprise Logging System. Part 3. Service.

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

У сервиса 2 обязанности:

• централизовать хранение настроек;
• помещать сообщения в сконфигурированное хранилище.

соответственно выглядит его контракт:

Сообщения несут разные наборы информации, и, чтобы не перегружать базовый класс сообщения неиспользуемыми свойствами, я ввел в data contract иерархию.

Для того, чтобы сервис мог десериализовать сообщения классов-наследников базовый класс необходимо пометить атрибутами [KnownType(typeof(...))], где ... - имена классов наследников.

Metadata.

Первая задача предельно проста. Необходимо сохранять и извлекать настройки клиентов из БД. Если настроек для конкретного клиента нет, то возвращаются дефолтные настройки, общие для всех клиентов.

Метаданные хранятся в БД и извлекаются при помощи Linq2Sql классов.

Вот классы, являющиеся метаданными системы:

Клиент идентифицируется по запросу, из полей которого составляется уникальный хеш. По нему то и ведется поиск в базе.

Logs
Сохранение сообщений делегируется адаптеру системы логирования, который подключается к сервису в файле конфигурации хоста сервиса. Я писал об этом здесь: http://bobbbloggg.blogspot.com/2008/04/loosely-coupled-wcf-service.html. В системе поумолчанию используется адаптер Enterprise Library Logging AB. Так как логи должны сохраняться в надежном хранилище с возможностью репликации со всеми данными системы на основной сервер, то конечно же в роли этого хранилища выступает БД. Дабы не тащить за собой Data Access AB из Enterprise Library, т.к. мне совсем не нравится его реализация, я написал свой легковесный custom DBTraceListener, сохраняющий логи в БД при помощи класов Linq2Sql. Этот TraceListener подключается к Logging AB в файле конфигурации и легко может быть заменен на любой другой.

Вот структура таблиц логов в БД.

Linq2Sql поддерживает паттерн отображения наследования с одной таблицой (см. Фаулер). Поэтому в таблицу введено специальное поле дискриминатор (DiscKey) и linq2sql классы образуют повторяющую LogMessage иерархию.

Все сообщения разделены на категории по уровню (LogLevel). Также в системе по умолчанию настроена одна дополнительная "специальная" категория сообщений - CriticalErrors, к которой подключен EmailTraceListener, который при деплойменте может быть настроен на почтовый ящик администратора системы и в случае получения сообщений о критических ошибках он будет получать письмо по почте, с тем чтобы привлечь его внимание к проблеме. Распределением сообщений по категориям занимается LoggingSystemAdapter.

В следующий раз я опишу фасад системы.

Удачи.

Enterprise Logging system. Part2 Context.

Перед тем как писать о сервисе коротко опишу контекст, передаваемый ему (сервису) вместе с сообщением. Контекст входит в data contract сообщения LogBook, т.е. я не использую появившийся в .Net 3.5 xxxContextBinding по той простой причине, что однажды установив его уже нельзя будет изменить. Да и передавать контекст в заголовке сообщения также не вижу особого смысла, поэтому он уютно располагается в теле сообщения.

Контекст в LogBook передается в виде словаря Dictionary<string, object>.
Чтобы облегчить себе жизнь я написал класс LogContext. LogContext имеет implicit operator конвертирующий его в Dictionary, поэтому не надо делать явных приведений типов.
У него есть свойство Current, которое возвращает текущий контекст (собирает небольшой набор данных об окружении) и несколько методов, с помощью которых его можно расширить.
Эти методы написаны в семантике “fluent interface”, каждый из которых возвращает копию исходного контекста с добавленными свойствами.

public LogContext AddAttributes(IDictionary attributes)
public LogContext AddAttribute(string name, object value)

и создание нового расширенного контекста будет выглядеть следующим образом:

var context = LogContext.Current.AddAttribute("1", 1)
.AddAttribute("datacontract", new Class1 { MyProperty = 1})
.AddAttribute("serializable", new Class2 { MyProperty = 2}); - очень удобно!

для того, чтобы передавать в контексте свои «кастомные» объекты, необходимо проделать следующее:
1. Пометить эти классы одним из атрибутов : Serializable или DataContract;
2. Сконфигурировать DataContractSerializer на клиенте и на сервере, добавив в конфигурационный файл приложения следующий блок:

<system.runtime.serialization>
<dataContractSerializer>
<declaredTypes>
<add type="System.Collections.Generic.Dictionary`2,mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<knownType type="ContextSendingTest.Class1, ContextSendingTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
<knownType type="ContextSendingTest.Class2, ContextSendingTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</add>
</declaredTypes>
</dataContractSerializer>
</system.runtime.serialization>

Далее при добавлении атрибута контекст проверит, помечен ли класс одним из упомянутых атрибутов и сконфигурирован ли DataContractSerializer.

Контекст реализует интерфейс IEquatable, сравнивая коллекции аттрибутов с использованием дефолтных EqualityComparer, поэтому «кастомные» классы должны перегружать метод Equals для того чтобы изменить логику их сравнения и сравнения контекстов в целом.

Вот, вкратце так.

Удачи!

Enterprise Logging system. Part1 Architecture.

Имею желание поделиться с вами своим взглядом на дизайн системы логирования масштаба предприятия.

"О чем этот сумасшедший?"

Я о той части SOA инфраструктуры, которая отвечает за логирование событий в enterprise. С началом разработки данной системы мы начинаем лавировать в сторону настоящей SOA инфраструктуры, малыми галсами приближаясь к нашему видению такой модной нынче SOA концепции как ESB.

"Точно двинутый, ничего не понятно же".

Да блин, все просто - нужна система, в которую централизовано будут сваливать свои логи все приложения, работающие в сети одной компании.

Итак задачи, ограничения и требования к данной системе:

• должна быть предельно проста в применении разработчиками;
• должна функционировать в распределенной системе - конечная точка сервис;
• возможность работать в отключенном режиме;
• нельзя расчитывать на то, что на клиенте будет установлен SQL сервер, поэтому должна быть возможность подключать различные стратегии кеширования;
• возможность подключения различных библиотек логирования;
• возможность настройки уровня, категорий и пр. данных сообщений, которые будут отправляться с клиента;
• сохранение логов в БД сервера, с тем чтобы реплицировать их с остальными данными на основной сервер;
• возможность настройки альтернативного хранилища/цели сообщений логов (e-mail, event log…) (при помощи сторонних библиотек логирования);
• возможность передать некий контекст;
• управление исходящим траффиком
• ...

Теперь обратимся к литературе. На codeproject я нашел несколько статей, в которых описано решение подобных задач:

• http://www.codeproject.com/KB/WPF/WpfLogging.aspx
• http://www.codeproject.com/KB/silverlight/SilverlightLogging.aspx

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

В качестве стронней библиотеки логирования я рассматривал следующие проекты:

• NLog http://www.nlog-project.org/;
• log4net http://www.nlog-project.org/;
• Enterprise Library Logging Application Block http://msdn2.microsoft.com/en-us/library/cc309506.aspx;

Функциональность и модель программирования во всех этих проектах примерно одинаковая и включает в себя возможность логировать в такие хранилища как Event log, база данных, E-mail, и т.д. и т.п. В конечном итоге выбор я остановился на Enterprise library, во-первых потому что я уже имею опыт работы с Enterprise Library и использовал Validation Application Block в слое бизнес объектов в проектах (писал об этом здесь), а во-вторых чтобы сохранить единую базу, на которой строятся все проекты.

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

Характерными особенностями ее являются:

• логирование всегда ведется на сервере, поэтому сервис логирования является основной компонентой системы;
• сервис слабо связан с непосредственным кодом логирования и библиотекой, берущей на себя эти функции при помощи уже описанного мною приема http://bobbbloggg.blogspot.com/2008/04/loosely-coupled-wcf-service.html; Это оставляет за мной возможность безболезненно сменить библиотеку логирования, в случае, если звезды изменят свое расположение и я передумаю использовать Logging AB;
• клиент работает с библотекой через фасад, а всю работу по конфигурированию, кешированию и работе с сервисом система берет на себя прозрачно для клиента, при этом по возможности не блокируя его;
• сервис логирования - WCF singleton-сервис; Его функция централизовывать хранение настроек и делегировать сохранение сообщений адаптеру библиотеки логирования;
• сохранение логов в базу данных производится через подключаемый к Logging AB Custom TraceListener.

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

• Trace;
• Info;
• Warn;
• Error;
• Status;

Настройки клиентов, уникально себя идентифицирующих, хранятся в БД. При первом обращении к фасаду системы, клиент обращается к сервису с просьбой передать настройки, если сервис недоступен - пытается "поднять" их из локального конфига.

Локальные стратегии кеширования подключаются к клиентской части системы при помощи модели провайдеров ASP.NET. Так же система расширяется за счет подключаемых фильтров, которые контролируют исходящий траффик. По умолчанию в систему включены провайдер локальных стратегий, стратегия кеширования в оперативной памяти (для тестирования), стратегия для кеширования в IsolatedStorage, фильтр траффика по уровню сообщения.

В серверной части система расширяется при помощи модели расширений WCF, подключая к сервису адаптер, которому делегируется работа с библиотекой логирования. В систему встроен адаптер для работы с EnterpriseLibrary.

Всю работу по отправке сообщений в сервис берет на себя компонента системы Disconnected Service Agent (DSA). В Smart Client Software Library есть Application Block, реализующий данную функциональность, но по упомянутым выше причинам я предпочел не использовать готовую функциональность, а написал свой небольшой блок, опять же почерпнув из MS-ской реализации светлые идеи. Основными частями данного блока являются:

• Connection Monitor - агент, который следит за состоянием подключения к сервису;
• Request Manager - диспетчер запросов. Ставит запросы в очередь (локальную стратегию кеширования), пытается асинхронно отправить их, дабы не блокировать клиента;
• Local Store Strategy - локальная стратегия кеширования, которая подключается в процессе конфигурирования.

На этом сегодня все в следующий раз подробнее о сервисе.

Удачи.

ConfigurationElement serializing unrecognized attributes

Этот пост будет коротким и будет посвящен простенькой проблеме: сохранение в конфигурационном элементе неопознанных атрибутов.

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

С такой ситуацией я столкнулся разрабатывая инфраструктуру для моего нового проекта. Проблема была решена быстро - достаточно было лишь взглянуть с помощью Reflector на код системы провайдеров ASP.Net, точнее на код класса ProviderSettings. У этого класса есть свойство Parameters типа NameValueCollection, которое магическим образом сериализуется в набор строковых атрибутов элемента. А делается это следующим очень просто (далее код мой). Заполняется коллекция в методе OnDeserializeUnrecognizedAttribute конфигурационного элемента, а сохраняется при помощи создания для каждого вхождения коллекции параметров ConfigurationProperty:

плюс в этом конфигурационном элементе необходимо будет перегрузить свойство Properties.

Делается это не только для того, чтобы добавить свои элементы, но и для оптимизации, т.к. код базового класса составляет коллекцию при помощи Reflection, что довольно медленно в больших классах.

Очень много информации по пространству имен System.Configuration вы можете почерпнуть в следующих статьях:

http://www.codeproject.com/KB/dotnet/mysteriesofconfiguration.aspx

http://www.codeproject.com/KB/dotnet/mysteriesofconfiguration2.aspx

http://www.codeproject.com/KB/dotnet/mysteriesofconfiguration3.aspx

Удачи!

Enterprise Library 4

Вышел CTP Enterprise Library.
линк для скачивания: http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=entlib&ReleaseId=12142

Удачи.

Loosely-coupled WCF service

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

Замечу сразу, что реализация основана на статьях Roman Kiss'а на codeproject, в которых он при помощи WCF сервисов реализует различные WS-* протоколы. Вот эти статьи:

• http://www.codeproject.com/KB/WCF/WSTransfer.aspx
• http://www.codeproject.com/KB/WCF/WSEventing.aspx

Идея подхода следующая - отделить код сервиса от непосредственной работы с ресурсами при помощи адаптера сервиса (ServiceAdaptor). Реализация основана на модели расширения WCF, которая отлично описана в статье Aaron Skonnard'а Extending WCF with custom behaviors (к сожалению статья на русском - не знаю как заставить MSDN выдавать статьи на том языке, который мне нужен, а не на том который у меня на компе).

Основа решения состоит из следующих элементов:

• базовый класс сервиса, для доступа к адаптеру;
• поведение, применяемое к сервису, для создания адаптера;
• конфигурационной элемент, для настройки поведения в конфиге;

Далее, для каждой конкретной реализации необходимы:

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

Вот и все теперь по частям:

ServiceAdapterBase

Базовый класс, инкапсулирующий логику получения объекта адаптера из инфрастуктуры WCF.

Здесь мое главное усовершенствование. Адаптер впервые создается при первом обращении к нему из методов контракта. Такое решение позволяет добиться следующих преимуществ:

• сервис сам управляет временем жизни адаптера (экземпляр адаптера существует в каждом экземпляре сервиса, соответственно их времена жизни равны);
• при установке ServiceBehavior.InstanceContextMode = Single становится невозможным создать адаптер, при поведении применяемом в конфигурационном файлеб ниоткуда кроме текущей операции, т.к. при создании объекта singlton-сервиса инфраструктура wcf еще не инициаллизирована и поведение применяемое в конфиге позволяет расширить wcf только на уровне сервиса или endpoint.
  

AdapterAttribute - service behavior

Класс, реализующий интерфейс IServiceBehavior, с помощью которого наше поведение подключается к инфраструктуре WCF. Ничего не делает, просто предоставляет данные, необходимые для создания сервиса. Т.к. наше поведение реализовано в классе атрибута, то оно может применяться и декларативно - в коде.

ServiceAdapterBehaviorElement

Класс, необходимый для подключения поведения в файле настроек.

Конкретная реализация

ITestAdapter, TestAdapter

IService, Service

Обратите внимание на параметр типа ServiceAdapter в ServiceAdapterBase - здесь вы можете жестко в коде прошить класс адаптера (удобно для разработчика - можно быстро менять реализацию сервиса). Для того чтобы дать понять классу ServiceAdapterBase, что конкретный тип адаптера будет задан в конфиге ему подставляется затычка - ConfigurableAdapter (пустой класс даже картинку не буду вешать).

И теперь последняя деталь - файл конфигурации:

P.S. С выходом .Net framework 3.5 та же функциональность слегкостью может быть достигнута при помощи модели WorkflowServices и loose-xoml. Почитайте у Roman'а http://www.codeproject.com/KB/WF/VirtualServiceForESB.aspx

Удачи!