Глава 15 Разработка корпоративных систем на основе библиотеки Enterprise Library

Корпоративные системы имеют очень большие базы данных: размеры хранимой информации в этих СУБД достигают 10¹⁵ байт. В хранилищах корпоративного контента хранится гетерогенная информация, это и видео-, и аудиоданные, и отсканированные документы, которые не всегда идеально распознаются и часто просто каталогизируются на основе определенных признаков: номера, даты создания и т. д. Нужно сказать, что корпоративные данные достаточно быстро увеличиваются, в среднем их объем удваивается за пятилетку, т. е. речь идет о лавинообразном росте, поскольку удвоение – это почти экспоненциальный рост. При таких изначально высоких базовых объемах этих данных управлять ими очень сложно, поскольку они обеспечивают бизнес-критичные приложения, необходимые для ведения и оперативного, и стратегического планирования развития корпорации. В связи с этим темой данной главы будут как СУБД, так и библиотеки создания корпоративных приложений, которые настроены на то, чтобы создавать из базовых блоков экономичным образом корпоративные приложения и объединять их в корпоративные информационные системы (КИС).

Библиотека классов для. NET, на основе которой производится построение такого рода приложений, называется Enterprise Library. Познакомимся с технологией построения этой библиотеки, с некоторыми из классов, которые входят в ее структуру, и, конечно, с примером создания, может быть, не корпоративного приложения, но некоторого его фрагмента на основе этой библиотеки.

Если говорить о корпоративных приложениях, о библиотеке Enterprise Library, то важно отметить, что она структурно включает в себя целый ряд блоков, каждый из которых предназначен для построения определенного рода приложений или определенной части этих приложений. Существует ядро в составе классов, которые представляют эту библиотеку, лучше сказать, эти библиотеки, и целый ряд функциональных блоков (по-английски – blocks), в названии которых указываются их специализация, т. е. функциональное назначение. Основные блоки предназначены для организации кэширования, уже достаточно много говорилось о том, что это за сервис, каким образом он обеспечивается, а также о кэш-серверах в связи с базами данных. Ряд функций обеспечивается блоком, который отвечает за безопасность, следует напомнить, что безопасность является, пожалуй, высшим стратегическим приоритетом Microsoft. После известных событий 11 сентября Microsoft разработала подход к созданию программных систем, который называется Security Development Lifecycle. Один из основных принципов разработки – Secure by Design, т. е процесс проектирования с самого начала предполагает получение на выходе безопасных приложений. Поэтому многоуровневые политики доступа к данным, методы криптографической защиты, использование шифров от различных крипто-провайдеров, возможности использования встроенных средств защиты, журналирование операций, системный аудит данных и программных компонентов корпоративных систем, средства авторизации/аутентификации различного рода, в том числе и на основе применения специальных средств аутентификации пользователей системы и биометрической аутентификации, ряд других методов и механизмов реализуют этот блок, связанный с доступом к данным. Об этом будет говориться более подробно, в том числе при рассмотрении практического примера, который будет связан с построением приложения, осуществляющего доступ к корпоративным данным. Еще один важный блок связан с проверкой корректности или валидации.

Неоднократно упоминалось о том, что корпоративные системы представляют собой конгломераты гетерогенных приложений с точки зрения как степени структурированности, так и архитектуры. Это могут быть и приложения, построенные на мейнфреймах, на файл-серверах, на клиент-серверных технологиях, на интернет-технологиях, на технологиях, связанных с сервисно-ориентированной архитектурой. И эти данные, как уже упоминалось, могут объединять как слабоструктурированную информацию, например аудио-, видеоданные, так и хорошо структурированную, которая хранится, например, в электронных СУБД в форме таблиц. В связи с этим неизбежно при развитии корпоративных систем возникают дублирования информации, противоречия и иные нарушения целостности данных, т. е. при попытке построения отчета можно столкнуться с неполнотой данных или некорректностью.

Скажем, в связи с учетом персонала и его управлением возникают вопросы о том, что происходит с отделом, когда из него удаляется последний сотрудник; ликвидируется он или сохраняется в измененном виде, или происходит что-то еще? На самом деле разные СУБД на уровне контроля ограничения целостности подходят по-разному к решению этой проблемы. А зависимости, которые позволяют определить степень нормализации базы данных и степень сложности обеспечения целостности, такие как зависимости между хранимыми атрибутами, между сущностями корпоративных систем, могут быть поддержаны на уровне системных библиотек, в частности библиотеки Enterprise Library. Блок, связанный с проверкой корректности, поддерживает отслеживание зависимостей, связей, взаимосвязей между элементами данных, элементами информации корпоративных систем и проверку и обработку специализированных исключительных случаев, связанных с корректировкой, обновлением, удалением и добавлением информации в корпоративные системы.

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

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

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

Поскольку речь идет о шаблонах, которые реализуют не только прикладные, но и системные задачи, логично разбить это решение на ряд блоков для того, чтобы разработчик мог выбрать необходимые ему блоки и уже в рамках этих блоков отобрать компоненты, а если понадобится, то конкретные классы и методы классов, которые необходимы ему для реализации конкретных корпоративных приложений. Блоки отвечают за конфигурацию. Конфигурация – по сути, управление метаданными, т. е. данными о данных, данными о той информации, которая хранится в системе: количество и размерность объектов, типы, взаимосвязи и ресурсы, связанные с этими объектами. Сейчас говорится об объектах, так как в идеологии. NET всякая сущность есть объект и, по сути, программирование или разработка программных систем, в том числе и корпоративных, ведутся в терминах объектов. Не случайно другим функциональным направлением, которое обеспечивают блоки Enterprise Library, является управление объектами и создание объектов для тех или иных функциональных блоков. Для этого существует средство, которое называется ObjectBuilder, далее будем говориться о нем несколько подробнее.

Важно отметить, что библиотека Enterprise Library не является абсолютно независимой, а, напротив, строится на фундаменте. NET и таким образом вбирает в себя все механизмы, которые присутствуют в системе базовых классов. NET в Microsoft.NET Framework, основной библиотеке классов. Начиная со второй версии, Enterprise Library полностью базируется на. NET Framework. Естественно, существуют специализированные инструменты, в том числе консольного типа, которые обеспечивают достаточно быстрое и легкое манипулирование свойствами корпоративных приложений, заложенными в базовых блоках. Прежде всего, это Configuration Console и Security Data-Based Console, т. е. средства манипулирования критически важными метаданными, связанными как с общей конфигурацией системы, так и с конфигурацией, связанной с настройками безопасности.

Если говорить о конфигурационной консоли, можно менять конфигурацию каждого приложения, добавляя к нему соответствующие блоки, можно менять конфигурацию каждого блока нашей библиотеки. Консоль, которая связана с безопасностью и обеспечивает управление безопасностью внутренней системной базы данных этих библиотек, позволяет создавать роли, профили и правила авторизации, которые поддерживает блок, связанный с безопасностью. Блоки, как правило, имеют названия, которые заканчиваются словами Application Block, в частности блок, связанный с безопасностью, называется Security Application Block. Далее будет показано, как происходит именование блоков, и основные функции, в чем состоят основные цели библиотеки Enterprise Library и какие возможности она предоставляет, какие задачи перед собой ставит.

Основных целей, судя по подходу Microsoft, четыре: последовательность (Consistency), расширяемость (Extensibility), простота использования (Ease-of-Use), можно понимать ее и как эргономику (Usability), и интеграция (Integration). Поскольку речь идет о корпоративных приложениях, здесь необходимо обеспечить как относительно дешевое и в то же время эффективное сопровождение развития, расширения, так и взаимодействие с уже существующими компонентами и теми новыми, которые будут реализованы. На чем основывается понятие Consistency? Естественно, это использование образцов, или шаблонов, паттернов проектирования совершенно определенного класса с определенным составом и взаимосвязями, которые позволяют обеспечить последовательный, прагматичный подход к реализации и внедрению программных систем, включающих блоки, связанные с корпоративными подсистемами. Расширяемость заключается в том, что все блоки включают явно определенные точки расширения, которые дают возможность разработчикам настраивать поведение этих блоков при добавлении в них своего собственного кода. Простота использования, по сути, связана с эргономикой, и здесь целый ряд усовершенствований в удобстве использования уже встроен в саму систему Enterprise Library. В частности, графические средства конфигурации, упрощенная процедура инсталляции, большое количество примеров использования и хорошая, тщательно подогнанная и собранная документация, которая описывает достаточно полно все возможности и пути применения классов и компонентов этих библиотек. Что касается интеграции, то она обеспечивается тщательным предварительным тестированием всех Application Block и грамотным и аккуратным проектированием этих блоков таким образом, чтобы они корректно взаимодействовали друг с другом и обеспечивали каркас для решения задач, связанных с разработкой корпоративных приложений. Тем не менее каждый из блоков может быть использован отдельно, вне связи с остальными, если этого требуют цели разработки.

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

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

Как уже было сказано, необязательно включать в код весь комплект компонентов, которые включаются в Enterprise Library, для того чтобы построить корпоративное приложение. Можно взять всего один Application Block, можно взять несколько, они достаточно хорошо интегрированы между собой и позволяют обеспечить взаимодействие практически вне зависимости от того набора блоков, который выбирают разработчики. Таким образом, в приложения можно включить прежде всего блоки, действительно необходимые для реализации тех программных решений, которые поставлены как техническое задание разработчикам.

С другой стороны, важной возможностью повторного использования является возможность включать исходный код библиотек, уже разработанный специалистами Microsoft, в те новые системные библиотеки, которые будут создаваться в рамках корпоративных приложений, естественно, соблюдая соглашение об авторских правах. Поскольку библиотека поставляется как корпоративное решение, та корпорация, которая его получила, имеет определенного рода лицензионное соглашение, и в рамках этого соглашения можно использовать ту функциональность, буквально копируя и вставляя нужные фрагменты исходного кода в приложения, которые будут развивать Enterprise Library и на этой основе расширять информационную инфраструктуру корпорации. Очень важно отметить, что ноу-хау, принципы и подходы к проектированию корпоративных приложений, которые имеются у корпорации Microsoft, воплощены в коде этих библиотек. Поэтому исходный текст библиотек и, естественно, средств взаимодействия между ними является важной основой для изучения тех принципов архитектурного, технологического построения и проектирования корпоративных приложений, которые имеются у Microsoft. Достаточно интересно эти принципы изучать и в дальнейшем применять практически, поскольку Microsoft, используя MSF, достаточно сложную методологию, разработала большое количество кода корпоративного качества и на основе изучения этого кода можно изучать и степень применимости, и технологию применения, например подхода Microsoft Solution Framework, при проектировании и реализации корпоративных приложений. Это достаточно важное замечание, которое нужно учесть при разработке и работе с этим кодом, с этими библиотеками.

Функциональные блоки, входящие в состав библиотеки Enterprise Library, называются Application Block и имеют некий префикс, который определяет их функциональное назначение. Это блок кэширования, блок криптографии, блок доступа к данным, блок обработки исключений, блок ведения системных журналов, блок, связанный с политикой безопасности, блок, связанный с обеспечением безопасности в целом, и важный блок, который отвечает за контроль целостности и проверку корректности элементов этой системной библиотеки.

Можно более подробно описать некоторые из этих блоков. По сути, блоки реализованы инвариантно по отношению к архитектуре конкретных приложений. Например, блок, который отвечает за ведение системных журналов, может быть использован как в веб-приложениях, так и в приложениях, ориентированных на сервисы и интеллектуальные клиенты, технология Smart Clients, которая уже обсуждалась. Блок кэширования позволяет разработчикам реализовать средства кэширования в приложениях, при этом можно использовать и плагины для сторонних провайдеров методов кэширования. Блок, связанный с криптографией, включает симметричные алгоритмы шифрования и технологии хеширования. Естественно, эти методы, как и все реализованные в составе Application Block, созданы как открытые компоненты, в том смысле, что их код и их интерфейсы открыты для разработчика. То есть разработчик может просто пользоваться теми методами, теми классами, которые реализованы в этих компонентах, создавая свои решения.

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

О блоке, который связан с ведением системных журналов, более подробно будем говорить далее. Понятно, что его функциональность – это ведение системного аудита и логирование, запись в журналы тех системных событий, которые происходят с компонентами корпоративных приложений. Блок, который называется Policy Injection, связан с реализацией таких важных и часто встречающихся возможностей ПО, как кэширование, ведение журнала системной информации, обработка исключений и поверка корректности системы во всей системе. То есть они распространяют эти правила на всю систему и дают возможность сквозным образом вести контроль над корпоративной системой, включающей, возможно, несколько приложений, построенных на основе технологии Enterprise Library.

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

Взаимодействие основных функциональных блоков в библиотеке Enterprise Library представлено на рис. 15.1.

Рис. 15.1. Структурная схема библиотеки Enterprise Library

В центре находится ядро, включающее в том числе средство ObjectBuilder, средства настройки конфигурации и общих компонентов, которые поддерживают проектирование, а также взаимодействие с инструментальными средствами разработки. На периферии в прямоугольниках с закругленными углами расположены блоки, которые были перечислены. Основные потоки взаимодействия между блоками обозначены сплошными стрелками, а дополнительные возможности, которые могут обеспечиваться на уровне взаимодействия между блоками, – пунктирными. Далее рассмотрим более подробно ядро библиотеки корпоративных приложений Enterprise Library.

Нет ничего удивительного в том, что интерфейс погружается в среду. NET, в среду Visual Studio. На рис. 15.2 показаны метаданные, конфигурация того или иного приложения, которое в данный момент создается или настраивается.

Рис. 15.2. Директории в среде. NET

Из рисунка видно, что на диске C, в директории pub и т. д., существует некий конфигурационный файл, который описывает метаданные приложения, создаваемого на основе библиотеки, и все стандартные средства, которые поддерживаются. NET Framework, доступны. Можно сказать, что все функциональные блоки, которые рассматривались ранее, в том числе на рисунке, описывающем структуру Enterprise Library, поддерживают общие механизмы настройки, которые как раз и дают возможность осуществить интеграцию этих блоков и приложений на их основе, а на базе тех приложений, которые строятся, осуществить взаимодействие между компонентами этих блоков. Кроме того, на основе этого общего репозитория метаданных можно задавать механизмы расширения блоков, используя точки расширения, о которых уже говорилось.

Существуют механизмы конфигурации (см. рис. 15.2) в форме конфигурационного файла, который представляет собой описание метаданных, в том числе в формате XML, и показывает, каким образом может происходить визуализированное управление элементами этих метаданных. Механизмы конфигурации используют стандартное пространство имен System Configuration из библиотеки. NET Framework, т. е. библиотека Enterprise Library погружена в системную библиотеку. NET Framework.

Если говорить о специфике каждого функционального блока, то для него на базе стандартных классов. NET созданы вспомогательные классы, которые поддерживают на уровне конфигурации все необходимые изменения. В частности, некоторые из конфигурационных файлов называются abp.config, web.config. В них как раз и хранятся данные о данных, хранятся те метаданные, та метаинформация, которая дает возможность настраивать приложения и управлять их работой и взаимодействием. При этом поддерживаются все стандартные возможности классов в пространстве имен System Configuration из библиотеки классов. NET, включая, например, средства шифрования и использование внешних файлов.

Другие возможности предоставляются, например, на основе библиотеки классов. NET Framework 2.0, пространство имен System Configuration из библиотеки классов. NET 2.0 позволяет вести считывание и запись сложных конфигураций. Поскольку здесь говорится о корпоративных приложениях, конфигурации таких приложений имеют достаточно сложную иерархию. Иерархическое представление возможно преобразовывать в последовательное и обратно посредством механизмов сериализации и десериализации на основе стандарта XML. При этом используется класс Configuration Section.

Еще одним важным элементом ядра Enterprise Library является подсистема ObjectBuilder. ObjectBuilder имеет собственное пространство имен Microsoft.Practices (см. рис. 15.1) и позволяет осуществлять управление созданием и в целом жизненным циклом экземпляров классов, т. е. объектов. Это является критически важным для Microsoft.NET, поскольку постулируется принцип: «Каждая сущность есть объект».

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

Другие функциональные блоки могут использовать существующие в ядре счетчики производительности, протоколы событий и средства Instrumentation. На рис. 15.1 были представлены три составляющие, которые включают ObjectBuilder, средства, связанные с настройкой конфигураций и проектированием компонентов, и средства, которые называются Instrumentation или Windows Management Instrumentation, средства управления механизмами Windows из корпоративных приложений. При этом можно использовать различные механизмы, которые описывают конфигурации и стиль управления информационной системой, возможностями информационной системы.

После обсуждения ядра будем последовательно двигаться по блокам, описывая специфическую функциональность, связанную с этими блоками. Конечно, если говорить о разработке корпоративных приложений, то это распределенные приложения достаточно сложной структуры, большого объема. Встречается много серьезных проблем как у разработчиков, так и у системных архитекторов. На решение этих проблем во многом и направлен блок, который связан с кэшированием. Кэширование дает возможность обеспечить оптимизацию производительности, масштабируемости и доступности. Если говорить о производительности, то кэширование позволяет увеличить производительность приложений посредством сохранения наиболее часто используемых, востребованных данных, как можно ближе к потребителю этих данных. Это дает возможность устранить последовательные, часто повторяющиеся создания/обработку/передачу данных. Что касается масштабируемости, то хранение информации в кэш-памяти обеспечивает экономию ресурсов и увеличивает масштабируемость по мере роста частоты и запросов пользователей приложений. Если говорить о доступности, то хранение данных в локальной кэш-памяти позволяет приложениям оказаться жизнеспособными в таких случаях, как временное пропадание или неустойчивая работа сети, сложности с работой веб-сервисов и сбои аппаратного обеспечения. Это наиболее сложная проблема, которая может приводить к потере данных. Блок кэширования, который служит для реализации локального кэша, может поддерживать кэш как в памяти, так и в удаленном хранилище данных, которое может поддерживаться посредством блока доступа к данным, Data Access Application Block, или изолированного хранилища, Isolated Storage. При этом обеспечивается извлечение/добавление/удаление данных из кэша. Время хранения может меняться в зависимости от тех настроек конфигурационных файлов, которые описывают метаданные для этого блока. Локальный кэш поддерживается для единственного домена приложения, поэтому Cashing Application Block не обеспечивает реализацию разделяемого между доменами кэша.

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

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

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

Следующий блок связан с доступом к данным. Здесь поддерживаются стандартные механизмы активных объектов данных Active Data Objects, ADO.NET 2.0, и в этом смысле удается абстрагироваться от провайдеров данных, используя стандартные объекты, стандартные классы, например дебикомманд, деби-Connection для того, чтобы получать параметры получения данных и параметры подключения к этим данным, а также параметры их преобразования. В связи с этим приложение можно переносить из одного хранилища в другое без изменения кода. Просто настройкой конфигурации можно добиться взаимодействия с новым местоположением, новыми особенностями хранения данных. Вообще этот блок поддерживает функции управления соединением с данными, извлечения/создания/коррекции данных, кэширования и создания хранимых процедур и т. д. Естественно, этот блок также построен на основе стандартных классов. NET, в данном случае ADO.NET 2.0. Важно, что поддерживается работа с большим диапазоном SQL-серверов, об одном из них, Microsoft SQL Server, будет говориться далее, но поддерживаются и Oracle-сервер, и различные варианты SQL-серверов от Microsoft, в частности Compact Edition для мобильных систем. Возможно упрощенное обращение к базе данных с использованием при передаче параметра строки соединения. При этом код приложения может создавать именованный экземпляр базы данных.

Известно, что при работе с СУБД Oracle каждый раз реализуется новый экземпляр базы данных и происходит стандартная передача параметров соединения метода CreateDatabase класса DatabaseFactoring в стандартном пространстве имен. NET. Каждая база данных, которая имеет имя и создается как экземпляр, имеет информацию о соединении, и эта информация сохраняется в файле конфигурации. Корректируя эту информацию, конфигурационный файл, по сути, метаданные, которые описывают сценарий взаимодействия с базами данных, разработчики корпоративных приложений могут использовать приложения с различными конфигурациями базы данных без перекомпиляции, т. е. опять-таки можно обеспечить существенное упрощение взаимодействия с данными на основе механизмов, поддерживаемых библиотеками Enterprise Library, в частности блоком, который связан с доступом к данным. Как и в случае с другими блоками, блок Data Access Application Block уменьшает необходимость написания стандартного кода для взаимодействия с данными, а также делает последовательной политику доступа к данным внутри как каждого приложения корпоративного типа, так и корпорации в целом, которая объединяет большое количество различных приложений. За счет универсализации интерфейсов между корпоративным приложением и различными базами данных удается обеспечить прозрачную интеграцию, в ряде случаев даже без перекомпиляции, с возможностью замены конкретного вида SQL-сервера, вида конкретной базы данных, с которой ведется работа. Разработчики могут обойтись без использования гетерогенных программных моделей для различных типов баз данных.

С любой базой данных можно вести диалог на платформе. NET посредством механизмов, предусмотренных ADO.NET, и классов, заложенных в составе данного блока. Существенно уменьшается при этом количество кода, которое было бы необходимо для взаимодействия с различными SQL-серверами, с различными видами баз данных. Блок применяется для решения следующего набора задач: это использование механизмов DataReader и DataSet для извлечения нескольких записей, выполнение команд и получение параметров после выполнения этих команд, получение значений, которые выполняют команды или хранимые процедуры. В рамках одной транзакции здесь поддерживается управление многопользовательской работой с базами данных. В режиме транзакций можно выполнять несколько элементарных операций, можно получать в результате обмена с SQL-сервером данные в формате XML и можно стандартным образом обмениваться данными посредством использования DataSet.

Следующий блок связан с обработкой исключений. Он называется Exception Handling Application Block. Известно, что на стандартной платформе. NET, в. NET Framework, существует специальное пространство имен, которое называется System Exception. Внутри этого пространства существуют различные классы для обработки разных видов исключений – арифметических ошибок, ошибок, связанных с доступом к данным, и т. д. Здесь этот принцип обобщается на уровень корпоративных приложений.

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

Что очень важно, обработка исключений становится политикой, можно задавать и конфигурировать на основе этого блока политики обработки исключений. По сути, существуют классы, которые отвечают за исключения, за обработку конкретного вида исключений и за действия, связанные с обработкой того или иного рода исключений. Здесь удается определить политики обработки исключений и обеспечить связь между определенным классом исключений, которые существуют в иерархии классов System Exception или в другой иерархии классов, связанной с библиотеками Enterprise Library, и определить стандартный сценарий действий по обработке этих исключений. Таким образом, обеспечивается последовательный интерфейс обработки исключений, создание политик обработки исключений, поддерживается стратегия обработки исключений на всех архитектурных уровнях корпоративных приложений, а не только на уровне интерфейса, который обеспечивают прикладные сервисы. При этом политики обработки исключений могут поддерживаться, создаваться на разных уровнях администрирования, как для администраторов, так и для разработчиков. Эти политики задаются в форме правил.

При этом нет необходимости править код приложения для того, чтобы политика начала работать и применилась к этому коду. Кроме того, политика обработки исключений подразумевает возникновение исключений и обработку исключений также последовательным образом. Обработчики исключений могут использоваться в разных местах приложения, а также отслеживать взаимосвязи между объектами различных приложений. Можно привести несколько примеров обработки исключений. Сценарий обработки исключения выглядит так: информация об исключениях заносится в протокол, исключения могут перехватываться/преобразовываться/повторно использоваться, может происходить замена исключений в зависимости от их типов.

Следующий блок связан с ведением системных журналов, протоколов. Он называется Login Application Block. Важно отметить, что существует стандартный журнал – Event Log, в который записываются все системные события ОС Windows, связанные как с предупреждениями, так и ошибками. Этот механизм позволяет осуществлять запись прямо на уровне системного журнала, а также передавать сведения о системных событиях, ошибках по электронной почте, записывать данные в базу данных, в очередь сообщений, в текстовый файл, создавать события, используя механизм из ядра, который называется Instrumentation, а также использовать точки расширения этого функционального блока, которые имеются у него, как у прочих функциональных блоков Enterprise Library.

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

Еще один важный блок связан с выполнением стандартных операций внутри приложения, он называется Policy Injection Application Block. Здесь можно задавать правила, предусловия, постусловия для каждой из стандартных операций. Это регистрация данных, кэширование, обработка ошибок, коррекция или проверка достоверности информации внутри приложения. При этом работа ведется на уровне объектов, и для каждого конкретного объекта приложения можно указать как предусловия, так и постусловия, характерные особенности, в том числе имя сборки, к которой принадлежит объект, имя пространства имен, имя, тип и атрибуты объекта. При этом взаимодействие между объектами приложений обеспечивается посредством традиционных клиент-серверных приложений с использованием клиента и прокси, о которых говорилось в предыдущих главах. Этот блок создает для каждого вновь сконфигурированного класса прокси, который инкапсулирует правила, применяемые к явно назначенным и используемым атрибутам. Существует возможность присоединения средств обмена данными и обработчиков таких средств каждому методу для каждого прокси. И для каждого экземпляра целевого объекта приложения можно создать соответствующие методы и свойства и управлять этими методами и свойствами. То есть политики регламентирования правил, управления пред– и постусловиями, выполнения операций для этих объектов могут осуществляться на разных уровнях, как на уровне приложения, так и на уровне корпорации в целом.

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

Таким образом, осуществляется возможность интеграции и гибкого применения правил, регламентирующих выполнение различных операций на уровне всей библиотеки Enterprise Library. Существуют достаточно обширные предустановленные обработчики событий для каждого из этих блоков, которые существенно ускоряют разработку приложений на основе библиотеки Enterprise Library и позволяют успешно бороться с проблемами реализации различных приложений на основе большого количества взаимодействующих блоков. Естественно, разработчики могут создавать собственные обработчики событий и политики обработки событий и выполнения операций, которые осуществляют практически произвольные правила для взаимодействия между методами и свойствами каждого из объектов корпоративных приложений. Важно отметить, что реализация каждой прикладной системы создает автоматически прокси и средство обмена данными со своим обработчиком, которое следует аспектно-ориентированному подходу. При этом реализация методов, связанных с объектно-ориентированным подходом, не реализована на уровне блока Policy Injection по ряду причин, которые связаны со сложностью коррекции кода внутри методов отдельных приложений, а также взаимодействием конструкторов классов для различных блоков корпоративного приложения.

Что касается блока, который отвечает за безопасность корпоративных приложений, здесь реализуются механизмы авторизации, безопасного кэширования данных для авторизации и аутентификации пользователя. Важно отметить, что, как и для других блоков библиотеки Enterprise Library, основные функции получаются как надстройка над стандартной библиотекой классов. NET Framework. Основные требования к механизмам обеспечения безопасности при этом сводятся к следующим: требуется аутентификация пользователей, здесь можно использовать одну или несколько систем, механизмов безопасности. То же самое для авторизации пользователей. Если требуется определение тех ролей, в которых может выступать пользователь, тоже можно использовать одну или несколько систем обеспечения безопасности. Можно использовать различные механизмы обеспечения безопасности и для хранения/извлечения информации из профилей пользователей. В рамках одной системы можно использовать кэширование информации, которая описывает аутентификацию и авторизацию пользователя. Все политики безопасности делятся на пять базовых областей – это аутентификация, авторизация, поддержка безопасности на уровне ролей, на уровне профилей пользователей, а также кэширование информации, связанной с аутентификацией и авторизацией пользователей.

Наконец, блок, который называется Unity Application Block, представляет собой контейнер для добавления зависимостей, конструкторов, полей и методов. Этот блок отслеживает ограничения целостности и управляет зависимостями. Он основан на использовании технологии ASP.NET и во многом опирается на эти технологии.

Еще один блок, который связан с обеспечением корректности приложений, ассоциирован с ASP.NET, а также с рассмотренными нами ранее технологиями создания пользовательских интерфейсов Windows Forms и технологией взаимодействия распределенных приложений Windows Communication Foundation. Он позволяет встраивать в приложения на уровне как отдельных элементов корпоративных информационных систем, так и этих систем в целом стандартные и пользовательские механизмы, которые обеспечивают проверку достоверности данных. Например, проверяется корректность ввода на основе тех правил, которые будут указаны. То есть при обработке заказа необходимо проверить, что номер телефона заказчика содержит правильное количество цифр или что дата заказа попадает в тот или иной характерный диапазон. При этом при появлении ошибки, при сопоставлении с правилом проверки корректности возможна отправка стандартного или пользовательского сообщения, указывающего на некорректность операции и комментирующего эту некорректность.

Завершая разговор о библиотеке корпоративных систем, кратко проиллюстрируем примером использования блока Data Access. Используется стандартная сборка Microsoft.Practices.EnterpriseLibrary.Data, которую необходимо добавить в наш стандартный. NET проект и еще одну сборку, которая отвечает за конфигурацию, Microsoft.Practices.EnterpriseLibrary.Configuration. Для этого надо щелкнуть правой кнопкой мыши по свойству References, выбрать пункт меню Add Reference и выбрать место хранения этих сборок, добавить соответствующие файлы, сборки хранятся в формате DLL, и после этого директивой Import добавить классы из этих библиотек, которые понадобятся. По сути, речь идет об импорте классов из компонентов. Необходимо сделать две директивы: Import Microsoft.Practices. EnterpriseLibrary.Data и Import Microsoft.Practices. EnterpriseLibrary.Data.SQL. И далее стандартным образом использовать обработку событий, конкретно нужно взять функцию обработки событий PageLoad и добавить код, в данном случае на языке Visual Basic:

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

Таким образом, были обсуждены основные возможности работы по созданию корпоративных приложений на основе библиотеки Enterprise Library, рассмотрено устройство и работа этой библиотеки. Она основана на стандартном наборе классов. NET Framework, является надстройкой над ним, включает ядро и механизмы, которые называются Application Block и представляют собой наборы сборок, наборы компонентов. NET, для реализации стандартных процедур, возникающих у разработчиков при работе с рядом стандартных задач для проектирования и реализации корпоративных приложений.