Основы проектирования корпоративных систем Зыков Сергей

Глава 14

Разработка офисно-ориентированных систем по технологии VSTO

Перейдем к офисным приложениям, или библиотеке приложений на основе Microsoft Office System, которая поддержана Visual Studio Tools для. NET. Естественно, офисные приложения строятся на основе компонентной модели, при этом они могут включать как компоненты в форме сборок для. NET, так и сторонние объекты, например разработанные в рамках COM-модели. Но здесь над. NET как платформой появляется еще одна настройка, которую тоже можно назвать платформой, – Microsoft Office System. То есть появляется новая среда разработки и новая среда или новый уровень среды разработки и функционирования компонентов приложения. Будет обсуждено, какие преимущества имеются у Microsoft Office при использовании ее как платформы, какие средства интеграции используются для Microsoft Office System с известной и достаточно мощной средой разработки Microsoft Visual Studio.

Существует специальное средство, которое называется Microsoft Visual Tools for Microsoft Office System. Как применяется CLR, как среда CLR управляет приложениями, которые созданы на такой сложной, уже, наверное, трехступенчатой системе, где внизу находится Windows, далее – библиотека классов. NET Framework, затем, на уровень выше, – библиотека классов для офисных приложений Microsoft Office System. Более того, будет обсуждено, какие преимущества дает Visual Studio Tools for Microsoft Office, или VSTO. Будут рассмотрены элементы, которые содержатся в 2005 VSTO, в том числе по сравнению с предыдущей версией 2003, какие компоненты можно строить для расширения Office. Также будут затронуты панели действия, Smart Tag. Если написать в Microsoft Word некоторое слово, которое является, предположим, географическим названием, оно выделяется особым образом – при наведении мыши появляется буковка I, и слово подсвечивается, поясняется, что это Smart Tag и где это слово находится на карте. Каким образом осуществляется поддержка на уровне схем, что такое кэширование данных и их размещение в оперативной памяти и использование при частой потребности в них. Каким образом осуществляется связь приложений Microsoft Outlook с другими офисными приложениями. Как реализована модель безопасности, насколько тесно она интегрирована с общей моделью безопасности в среде. NET. Каким образом осуществляется модель развертывания приложений. Как работает технология ClickOnce, которая работает и для офисных приложений, не только для приложений. NET. И посмотрим на Actions Pane – модель команд, как реализовать код, который осуществляет создание меню, создание кнопок меню и обработку событий связанными с этими кнопками.

Следует сказать, что сейчас Microsoft Office System представляет собой единую среду взаимодействия большого количества офисных приложений. Это уже упомянутые нами Word, Outlook, Excel и другие приложения, в том числе в версии 2005 появилась поддержка Info Path – средств поиска. И в целом стратегия компании Microsoft сводится к тому, чтобы на основе обобщенной объектной модели, COM-модели, обеспечить взаимодействие всех продуктов Microsoft Office. И до того как рассмотреть расширения для Visual Studio for Microsoft Office System, нужно обсудить саму платформу.

Выясняется, что средства взаимодействия на основе, например, Object Linking and Embedding (OLE) существуют достаточно давно, и вообще интеграция офисных приложений ведется Microsoft уже более 10 лет. Существуют уже три модели интеграции бизнес-приложений с Microsoft Office. Это ручная интеграция, внешняя автоматизация и интеграция на уровне приложений. Кроме того, существует модель, которая поддерживает обмен данными на основе документов. Ручная интеграция представляет собой обмен информацией в режиме Cut&Paste, например, когда из одного приложения, из Excel или Access, вырезается диаграмма и вставляется в Word. Важные недостатки этой интеграции – низкая производительность, часто не вполне корректная работа, возможность внесения ручных ошибок. Поэтому предпочтительнее модель внешней автоматизации, использующая Office как сервер COM-объектов, который можно назвать внепроцессным. При этом наиболее частый сценарий для данной модели – генерация и редактирование офисных документов. К сожалению, нет возможности обеспечить 100 %-ю функциональную поддержку всех возможностей продуктов семейства Office, и в ряде случаев необходимо реализовывать собственный пользовательский интерфейс. Сервисные сценарии на основе, например ISP, не вполне реализуемы при этом подходе. Таким образом, модель внешней автоматизации также имеет ряд недостатков. Если говорить об интеграции на основе документов – это достаточно серьезное решение. Раньше такая интеграция, например между Word, Excel и Access, производилась на основе макросов, которые в основном писались на языке Visual Basic, теперь существует единая платформа – VSTO и можно создавать полноценные бизнес-приложения на различных языках платформы. NET.

Пожалуй, самый серьезный способ – это интеграция на уровне приложений. При этом создаются надстройки или расширения, которые называются AddIn для офисных приложений. Так же, как это происходит, например, с продуктами Adobe, когда документы Office можно конвертировать в файл формата PDF для Adobe Acrobat.

В VSTO используются два последних вида интеграции – интеграция на уровне документов и на уровне приложений. И в том и другом случае можно использовать достаточно большой спектр языков, которые предназначены для написания управляемого кода. В.NET, например, C# или Visual Basic. При этом VSTO дополняет VB for Applications, который пригоден для решения иных задач. В чем состоят преимущества использования Office System как платформы? Прежде всего, исчезает необходимость использования Cut&Paste, ручного переноса данных или актуализации данных. Теперь приложения могут извлекать данные, можно сказать, самостоятельно через документы, которые связаны с живыми бизнес-данными. Поэтому отпадает необходимость выполнения рутинных операций копирования данных. Кроме того, пользователям проще работать в единой среде, используя известные подходы к разработке, если это офисная среда, почти не требуется затрат на обучение пользователей. И наконец существенно снижается время разработки приложений, поскольку, если используется разработка на основе интеграции, на основе приложений, на основе AddIn, то, по сути, строятся некие надстройки над платформой Microsoft Office System, и в этом смысле трудозатраты минимизируются. Платформа VSTO (вернее, средство VSTO) возникла прежде всего потому, что появилась возможность объединить разработку приложений для. NET и для Microsoft Office. Используется полный доступ ко всем без исключения классам стандартной библиотеки классов. NET Framework, о которой говорилось ранее, в связи с компонентными приложениями.

При этом можно использовать не только классы. NET Framework, но и все объектно-ориентированные языковые конструкции, наследование, стандартные системные процедуры для обработки исключений, построение частичных классов, генерализацию или обобщение, вызов веб-сервисов. Более того, использование VSTO значительно расширяет тот спектр инструментальных возможностей и средств, которые были доступны в более ранних версиях среды. Совместное применение VSTO и Office дает возможность, как уже говорилось, объединить документы с живыми, постоянно меняющимися бизнес-данными, что особенно важно для корпораций, где данные могут обрабатываться большим количеством пользователей одновременно, часто претерпевают изменения и необходимы способы их актуализации в привычной для пользователя офисной среде.

Это реализовано на основе технологии интеллектуальных, или разумных, документов Smart Documents, которые имеют встроенные возможности соединения с данными, извлечения данных из гетерогенных источников, например на основе стандарта XML, из других документов и консолидации данных, подготовки отчетной информации. Интеллектуальные документы имеют знание о том, как связываться с данными. Как уже говорилось, одной из важных технологий создания интеллектуальных документов является XML-формат офисных документов. Можно создавать также расширенные XML-схемы и производить интеграцию интерфейсов на основе панели задач – Action Tasks Pane. Возможности технологий Smart Documents и Action Panes изображены на рис. 14.1.

Рис. 14.1. Возможности технологий Smart Documents и Action Panes

Что касается возможностей, которые предоставляет интеграция VSTO со средой. NET, это, прежде всего, расширенное использование средств CLR. При этом на различных языках программирования, например Visual Basic или Visual C#, можно создавать сборки, которые выполняются под управлением CLR. Код при этом становится управляемым и позволяет обеспечить высокий уровень безопасности. Если приложения созданы на основе языков, например Visual Basic for Applications, или код на основе использования COM-модели, тогда представлен неуправляемый код, который можно использовать, но с ограничениями по безопасности.

Важно, что теперь появляется возможность разработки и использования кода на основе. NET Framework и под управлением среды CLR. Общеязыковая среда управляет распределением памяти и следит за безопасностью кода, в том числе за корректностью областей памяти, которые используются, за сборкой мусора и т. д. Естественно, CLR обеспечивает взаимодействие с. NET Framework и использование, например, наследования от тех базовых классов, которые имеются в соответствующих библиотеках очень серьезного объема. При помощи этих инструментов можно создать, например, систему документооборота, которая осуществляет ряд проверок, связанных с визированием документов, юридической корректностью и т. д. Или можно создать решение для прогнозирования продаж, которое в качестве интерфейса пользователя использует Excel и при изменении тенденции или прогноза цен может вносить изменения в централизованную базу данных, что очень важно для корпоративных приложений и систем, которые используются в корпорациях, поскольку, во-первых, появляется централизация управления информацией, и, во-вторых, она реализуется для пользователей в стандартном интерфейсе Microsoft Office, к которому они привыкли и который не требует дообучения.

Несмотря на то что с помощью управляемого кода можно обеспечить автоматизацию операций в Excel и Word, требуется наличие внешнего приложения как надстройки, которое взаимодействует с теми или иными приложением Office и извлекает из него данные. Это то, что можно было видеть в предыдущих версиях. Теперь же можно говорить о сборках, которые разработаны на. NET Framework и под управлением VSTO и позволяют коду взаимодействовать с офисным приложением на более тонком уровне.

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

Естественно, код, созданный с помощью VSTO, обладает всеми преимуществами приложений на платформе. NET, если говорить о VBfA коде. Конечно, макросы являются небезопасными: существует достаточно большое количество вирусов, которые распространяются вместе с этими макросами и достаточно быстро расходятся по корпорациям внутри соответствующих документов. Если говорить о сборках, то каждая сборка идентифицируется цифровой подписью, автором сборки, версией сборки и политикой безопасности, которая дает возможность ограничения тех документов, с которыми она будет использоваться, тех операций, которые она может выполнять. Это будет более подробно обсуждено дальше. Важно отметить возможность применения всех технологий, которые поддерживаются платформой. NET, и всем инструментарием, который реализован на этой платформе.

Что можно отметить нового в среде VSTO 2005 по сравнению с предыдущими версиями. По сути, речь идет о более тесном взаимодействии с. NET и более тесной интеграции офисных приложений, а также взаимодействии со сторонними приложениями на основе COM-модели. Итак, основными нововведениями можно считать: поддержку компонентов интерфейса, который создан на основе средств. NET, поддержку расширенных компонентов Office, панели действия, Action Pane и Smart Tag, возможность создания Smart Tag. Рассмотрим более подробно функции, которые появились в VSTO 2005. Очевидно, что кроме локальной работы и поддержки всех возможностей основных продуктов Microsoft Word и Excel возникает возможность создания панелей задач с использованием средств. NET, полной поддержкой веб-служб посредством. NET Framework, возможностью offline работы с документами, кэширования и использования кэш-сервера. Появилась возможность использовать все сервисные функции Visual Studio.NET, в том числе отладчик, при построении приложений на базе Office, использовать расширение Visual Studio для создания приложений на основе Office и расширить средства обеспечения безопасности с использованием стандартных политик безопасности, криптографической защиты информации, а также достаточно широкий спектр возможностей, связанных с интеграцией приложений на основе XML-технологии.

Наконец, последнее нововведение, которое следует отметить и которое будет проиллюстрировано далее более подробно, – это модель облегченного и ускоренного разворачивания приложения (в идеале – одним щелчком), которая называется ClickOnce. Такая возможность осуществима благодаря использованию погружения в среду CLR и теснейшей интеграции VSTO c библиотекой классов. NET Framework. Что касается объектов Word и Excel, объектов основных офисных приложений, то с ними взаимодействует большинство офисных пользователей и, наверное, все без исключения корпоративные, если они пользуются Microsoft Office. Расширения связаны с целым спектром компонентов, которые доступны через стандартную панель компонентов: можно наблюдать и изменять их свойства в Properties Explorer, т. е. стандартном средстве Visual Studio, можно менять свойства, исследовать и настраивать свойства офисных компонентов, прежде всего приложений Word и Excel. При этом возможны программный доступ через именованные поля, а также связь с данными, т. е. извлечение живых данных, коррекция и обновление данных, в том числе и расположенных на удаленных серверах, поддержка событийной модели.

Ранее, в главе о Windows Forms, было показано, каким образом осуществляется привязка скрипта или фрагмента кода к событию, определенному действию пользователя, например щелчку левой кнопкой мыши по полю формы. Практически таким же образом можно взаимодействовать с офисными приложениями Word и Excel стандартными средствами Visual Studio. Расширенные компоненты приложений либо представляют собой расширения функциональности, либо позволяют добавить функциональность, которая отсутствует на уровне традиционной объектной модели. Если в Excel объектная модель доступна через пространство имен, InterOp (Microsoft.Office.InterOp.Excel), то здесь поддерживается дополнительно целый ряд объектов, например стандартной объектной моделью Excel поддерживаются только события на уровне листа и книги, и в ней невозможна привязка данных таким образом, как это реализовано в Windows Forms, например, когда рассматривался навигатор, который позволяет извлекать данные. Несмотря на то что в управляемом коде некоторые объекты, например Name-ListObject недоступны напрямую, использование расширенных компонентов позволяет обратиться к этим объектам. Таким образом, в VSTO 2005 реализован ряд расширенных компонентов для Excel, таких как NameRange, XML markering, Chart, ListObject и др. Кроме того, применение расширенных компонентов в отношении текстового процессора Word открывает доступ к ранее недоступным в стандартной модели компонентам. Это связано с извлечением данных, с использованием формата XML, а также манипуляцией с закладками (bookmark). При этом поддерживаются события, которые связаны с обработкой закладок и отсутствуют в стандартной объектной модели. Компоненты XML-note и XML-notes реализуют работу с XML-документами стандартной панели задач и поддерживают реализацию целого ряда событий, включая проверку корректности документа.

Поговорим подробнее о панели задач. Собственно все дальнейшее обсуждение будет посвящено настройке панели задач, ее управлению программным путем. В итоге будет рассмотрена программа или фрагмент программы на C#, который осуществляет настройку этой панели задач, дополнение туда новых командных кнопок и средств обработки событий. Сначала рассмотрим, что такое Action Pane, или панель задач, чем панель задач в VSTO 2003 отличается от более поздней версии 2005 и какого рода возможности поддерживаются. По сути, речь идет о настройке функционирования документов и гибкого конфигурирования возможностей работы с ними. Впервые это было реализовано в продуктах Microsoft Word и Excel 2003 в версии Professional и с точки зрения VSTO было добавлено в версию 2005. Речь идет о программных объектах Word и Excel и возможности настройки их атрибутов и действий с ними посредством механизмов Visual Studio. Если говорить об Excel, то существует класс Exсel.Workbook – рабочая книга Excel, который доступен из VSTO 2005. Точно так же можно настраивать свойства документа Word (Word.Document). При этом та программная модель, которая поддерживается панелью задач, во многом похожа на модель Windows Forms, рассмотренную ранее. То есть можно создавать объекты стандартных классов, настраивать их свойства и устанавливать реакцию на определенные события, которые инициируются пользователем или системой. При этом, так же как и в Windows Forms, программная модель является достаточно простой, и не требуется реализация сложных интерфейсов для инициализации или создания панели задач, например такого интерфейса, как Smart Document, который описывает интеллектуальные документы.

Необходимо отметить, что и предыдущая технология, которая базировалась на интеллектуальных документах Smart Documents, обладала многими возможностями для настройки свойств документов Word и Excel, и практически программирование панели задач в том же объеме было возможно на основе этой технологии. Однако предыдущая модель Smart Documents была доступна посредством Smart Doc SDK – средства разработки приложений, и в основе этого SDK, как и в основе многих открытых средств, лежала COM-модель, а не. NET Framework. Поэтому данная технология имела целый ряд ограничений с точки зрения и управляемости, и безопасности. В частности, если в подходе Smart Documents требовалась явная реализация интерфейса Smart Document, то здесь она не требуется, VSTO 2005 автоматически поддерживает все необходимые свойства и настройка происходит в автоматизированном режиме. Если для работы с SDK на основе Smart Documents требовалась установка так называемого XML Expansion Pack – средства расширения для работы с документами формата XML, то здесь этого делать не нужно, это средство фактически встроено в VSTO. Документы Word, которые построены на основе XML, были необходимы для работы с технологией Smart Documents. В случае работы с панелью задач, с новой технологией, которая поддерживается в VSTO 2005, это также не нужно. По крайней мере необязательно. Это является опцией, при этом можно создавать приложения, которые не основаны на XML-стандарте. И наконец, компонентный подход с точки зрения Smart Doc SDK был основан на COM-модели и на ActiveX компонентах. Здесь, если говорить об Action Pane, речь идет о возможности поддержки компонентов Windows Forms, которые являются стандартным расширением технологии. NET Framework и классы которых, как известно, имеются в пространстве имен System, т. е. явным образом задаются в стандартных классах расширений для платформы. NET. Таким образом, ограничения, которые существовали в предыдущем подходе для работы с интеллектуальными документами, для интеллектуальной обработки документов в среде Microsoft Office на новой платформе в рамках VSTO 2005 были преодолены.

Еще один важный аспект технологии VSTO – это Smart Tag. Smart Tag (или интеллектуальные ярлыки) – это способ разметки документа, который на основе специализированной технологии связывает некие фрагменты документа, особым образом помеченные и распознанные, с тем или иным набором действий, т. е. с некоторым скриптом, с некоторым кодом, например на языке C#, который позволяет по возникновении тех или иных событий реагировать на них соответственно. По сути, документ Microsoft Office представляет собой некоторый набор специальных областей, к которым привязаны, как, например, к элементам управления Windows Forms, определенные действия, определенные фрагменты программного кода. При этом, естественно, открывается возможность реализации контекстно-зависимых действий на уровне документов. То есть в зависимости от контекста, от вида документа, можно предпринимать те или иные действия. В VSTO 2005 существует специальный класс для создания Smart Tag, применение которого дает возможность доступа к ряду коллекций классов, связанных со стандартными терминами и выражениями, а также ассоциативную связь с коллекцией Actions, т. е. с коллекцией стандартных действий.

Кроме того, для реализации событийной модели открывается возможность использования делегатов. NET. Делегаты – это специальный класс, аналог указателей на функции, которые стандартно существуют в. NET и применяются для обработки событий. Этот механизм возник в языке C# и поддерживается на всей платформе. NET как стандартное средство реализации событийной модели. Важно, что Smart Tag являются динамически настраиваемыми и интерактивными элементами. Они могут динамически распознавать и обрабатывать те или иные данные, которые находятся в документах, в специализированных их фрагментах на основании типа их содержимого. Таким образом, Smart Tag можно называть настраиваемыми.

И целый ряд приложений Office 2003 поддерживает эту технологию, технологию динамически настраиваемых Smart Tag. Это Word, Excel, PowerPoint, Outlook, Access и другие приложения семейства Office. При этом можно осуществлять ассоциативное связывание выбранных Smart Tag с выбранными элементами приложений Excel и Access, ячейками таблиц или полями баз данных. При таком подходе существуют также расширенные возможности Smart Tag, которые включают связывание с XML-элементами и автоматизированное выполнение действий при распознавании того или иного класса Smart Tag. То есть можно осуществлять динамическое взаимодействие пользователя, во многом автоматизированное, с определенными классами фрагментов офисных приложений в достаточно широком диапазоне. Это и текстовые редакторы, и электронные таблицы, и базы данных, и средства взаимодействия между пользователями, и почтовые клиенты, и т. д.

При осуществлении этих двух усовершенствований, динамического распознавания и обработки данных на основании типа их содержимого, и динамического связывания с определенными фрагментами, ячейками Excel или полями баз данных Access, существенно повышается эффективность технологии или концепции Smart Clients – умных клиентов в интегрированных корпоративных приложениях Microsoft Office. Например, при связывании действий Smart Tag с элементами XML или при автоматическом запуске тех или иных действий при распознавании определенных классов Smart Tag умные клиенты могут автоматически получать метаданные по мере их ввода или обновлять данные определенной части приложения или связанных приложений в реальном масштабе времени в зависимости от характера и типа информации, которая вводится в другую часть, т. е. с другой стороны, в другой элемент этих офисных приложений.

По сути, речь может идти о многофункциональных распределенных системах, которые содержат в качестве компонентов интегрированные документы, таблицы, базы данных, средства взаимодействия, в том числе по электронной почте, и в зависимости от тех или иных действий пользователя или вводимых данных автоматически обновляют содержимое в распределенных хранилищах данных. То есть осуществляют централизованное управление и коррекцию состояния этих хранилищ. Это достаточно важная возможность. При таком подходе открывается перспектива построения гетерогенных хранилищ данных с возможностью автоматического обновления. В частности, такого рода технологии могут быть основаны на применении стандарта XML и поддержке программирования на уровне схем данных. При этом разработчики имеют прямой программный доступ к XML-узлам каждого документа, для каждого элемента схемы создаются экземпляры полей и появляется возможность доступа к данным по отдельным полям, а не по элементам интерфейса. При этом XML-схемы поддерживают взаимодействие и связь с данными на основе механизма управления событиями, в том числе событиями, связанными со вставкой, редактированием, контекстным вводом или изменением контекста. На рис. 14.2 представлен шаблон дополнений к клиенту Microsoft Office Outlook 2003 с использованием средства VSTO 2005.

Рис. 14.2..Шаблон для дополнений к MS Office, Outlook 2003 в VSTO 2005

Фактически речь идет о внедрении большого количества разнообразных фрагментов офисных приложений в общий документ, в том числе таблицы Excel, и возможно оперативное онлайновое реагирование в реальном масштабе времени на действия пользователя, например коррекция или выбор той или иной ячейки в таблице. Например в ячейке с названием Seattle Home1 появляется полное описание полей извлеченных из базы данных, связанных с ипотечным кредитом для этого строения, справа – фотография этого строения, ссылки, связанные с возможностью заключения договора на ипотечный кредит, с данными о собственниках этого строения, о размере первоначального взноса, кредитной ставке и, естественно, с указанием текущей даты, финансового года и т. д. Таким образом открывается возможность построения гетерогенных приложений, интегрирующих данные из различных источников и объединяющих их на общей и привычной всем пользователям платформе Microsoft Office System. Более подробно об интеграции различного рода данных из гетерогенных источников, в том числе с разной степенью структурированности, преимущественно на основе XML-технологий, будет говориться в следующей главе, которая во многом будет посвящена СУБД, в том числе Microsoft SQL Server.

Важным условием, важной возможностью, которая обеспечивается VSTO 2005, является кэширование данных, оно необходимо для обработки данных пользователями, в данном случае речь идет о редактировании документов Word и таблиц Excel в режиме offline, в отсоединенном и автономном режимах. При этом данные из кэша, из временного хранилища данных на локальной машине пользователя, могут быть связаны с документами и отображаться в режиме выполнения приложений. Кроме того, в кэш-области памяти могут также храниться данные, не связанные непосредственно с элементами интерфейса. Данные из кэша доступны на сервере, и если говорить о модели взаимодействия, об архитектурной модели приложения, в VSTO 2005 используется так называемая асимметричная модель. Для указания полей, данные из которых должны извлекаться и храниться в кэше, разработчиками могут использоваться атрибуты кэша (cash attribute). Достаточно указать список полей, которым нужно установить этот атрибут, и кэширование полей, т. е. сохранение их содержания, будет происходить автоматически. Для доступа к кэшу из других приложений, проектов Visual Studio используется объект ServerDocument, который позволяет открывать документы, не создавая экземпляров приложения Word и Excel, т. е., по сути, на сервере не требуется наличия Office приложения.

Важными особенностями являются возможность извлечения и связи данных из кэша с документами и отображение их в режиме выполнения приложений. Что касается приложений, которые создаются на основе Outlook, на рис. 14.2 было показано такое приложение, где в платформе VSTO 2005 поддерживается клиент Microsoft Outlook 2003. При этом существует полная интеграция с объектной моделью продукта и с кодом на языках C# и Visual Basic. Фактически реализован AddIn – дополнение для VSTO 2005, т. е. появился новый шаблон проекта, наряду со стандартными шаблонами, которые существуют в Visual Studio, например для создания проекта на C#, с помощью которого можно создавать расширения для Microsoft Outlook. Интерфейс VSTO 2005 предоставляет всю необходимую инфраструктуру для создания и использования подобного рода приложений. В том числе специализированный компонент, который называется AddIn Loader, реализован в виде динамически присоединяемой библиотеки dll, т. е. фактически тоже в виде компонента, в виде сборки, и используется для загрузки расширений к Microsoft Outlook. Поддержка MS Office Outlооk в VSTO 2005 позволяет осуществлять стандартное обращение к объектной модели продукта и к модели кода с использованием основных языков платформы. NET: C# и Visual Basic, а также выполнять ряд стандартных операций, некоторые из них будут рассмотрены далее. Это создание расширенных меню, экспорт заданий и совместное использование MS Outlook и XML Expansion Pack. Последнее дает возможность интеграции с основными видами офисных приложений, документами Word и таблицами Excel и самими этими приложениями. При этом существует достаточно большое количество AddIn и удачных примеров их использования для MS Outlook.

Что касается модели безопасности, реализованной в VSTO 2005, то, поскольку речь идет о практически полном погружении новой среды и семейства офисных приложений в платформу. NET, используются все основные механизмы обеспечения безопасности, которые обсуждались ранее. И это дает возможность наиболее полной интеграции продуктов, которые разрабатываются, в платформу, в том числе с использованием механизма сборок. В связи с этим можно говорить о полной поддержке механизмов безопасности. NET Code Access Security. При этом модель безопасности не только распространяется на сборки, которые содержат код, позволяющий расширить стандартные функции традиционных документов Office, но и защищает сами эти документы. Например, перед загрузкой любого управляемого кода, допустим написанного на языке C# или Visual Basic, средства VSTO проверяют политику безопасности, в том числе локальную, чтобы установить статус доверия сборки, на которую ссылается связанный с ней документ. Необходимо при этом убедиться в том, что обеспечивается полное доверие сборке, т. е. установлен статус Full Trust для той сборки, на которую ссылается документ.

Естественно, для разработчиков, которые приняли решение интегрировать свои компоненты, свои надстройки над Office в стандартную среду Office System 2003, эта новая модель, в том числе и с точки зрения обеспечения безопасности, является весьма удобной. До выполнения кода необходимо убедиться в том, что код признан полностью доверенным. При этом на локальном компьютере каждого пользователя корпоративной системы содержится набор правил, который определяет, какого рода операции разрешены для данного кода и какого рода код может быть исполнен. При загрузке кода языковая среда CLR собирает сведения об этом коде. Основное количество сведений относится к сборке – это версия и автор сборки, цифровая подпись, в том числе зашифрованная, алгоритм шифрования, степень доверия и политика безопасности и т. д. Кроме того, необходимо собрать сведения, относящиеся к хосту, т. е. к источнику кода. После этого сведения по сборке и по источнику соотносятся с той или иной политикой безопасности.

При этом существует четыре уровня этой политики, или четыре различных среза для политики безопасности, – Machine, User, Enterprise и Host. То есть на уровне локальной машины, на уровне пользователя, на уровне предприятия в целом и на уровне источника, например того сервера, с которого эта сборка получена по Интернет каналу. Каждая из этих четырех политик может содержать несколько групп кода – от нуля до некоторого их ограниченного количества. При этом каждая группа кода на основе сведений устанавливает тот уникальный набор прав, который включает то или иное количество разрешений, т. е. операции, допустимые в данном случае, например чтение файла с диска, запись на диск, открытие файла, коррекция и т. д. В результате, используя все собранные сведения о хосте, сборке и политике, среда выполнения соотносит сборку с кодовой группой, которая соотносит ее с матрицей прав для всех политик, для каждой из четырех политик безопасности. При этом удается достаточно четко и в то же время гибко определить, во-первых, разрешается ли выполнять этот код и, во-вторых, если разрешается, то какие именно операции допустимы для этого кода и с какими объектами. Естественно, сборки, которые используются документами Word или таблицами Excel, требуют статуса «полное доверие» – Full Trust, независимо от выбранной модели развертывания. Как правило, право на исполнение выдается определенным локациям для сборок, и после этого выбранным сборкам или наборам сборок на основе строгого, т. е. полного, имени присваивается статус доверия.

Наконец, последнее – это модель развертывания, которая реализует технологию, близкую к ClickOnce, т. е. является достаточно экономичной. По сути, в основе модели, которая применяется в VSTO 2005, лежит структурное разделение на документ, на код и на сборку. Код является частью проекта Visual Studio, а сборка – единственное, что поставляется вместе с документом. При этом сборка связана с документом, а реализация привязки осуществляется различным образом: в VSTO 2003 это делалось на основе свойств документа, в более поздней версии – 2005 – используются специализированные средства, доступные при выполнении приложений. Основных моделей развертывания – три: локальная– локальная, локальная – сетевая и сетевая – сетевая (рис. 14.3).

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

Рис. 14.3. Модель развертывания

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

Для того чтобы проиллюстрировать возможности работы с данными и элементами офисных приложений в рамках технологии VSTO 2005, попробуем рассмотреть пример фрагментов программы на C#, которая осуществляет настройку меню в приложении MS Excel. Нашей задачей является создание новой строки в меню и добавление в эту строку новых элементов, а затем определение конкретных действий, которые будет осуществлять система при возникновении тех или иных событий со стороны пользователя. Желательно осуществить привязку управляемого кода, т. е. кода на C#, при нажатии пользователем кнопки на панели инструментов. В MS Office панели инструментов называются панелями команд и представляют собой общее средство для всех приложений. В данном случае наблюдается пример, связанный с MS Excel. Иногда, например при построении AddIn, возможно, имеет смысл создать собственную панель команд с дополнительными кнопками. В других случаях можно просто добавить элементы управления к уже существующей панели команд или меню. При использовании инструментария VSTO 2005 можно сделать и то и другое. То есть можно как расширить существующее меню, так и создать новое.

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

Итак, в данном примере предлагается добавить новую строчку меню в Excel. Делается это посредством нескольких шагов, при этом каждый из них является достаточно простым. Во-первых, надо взять пространство имен, которое называется Microsoft.Office.Core, и задать ему более простой псевдоним. Для этого используется оператор Using, по сути, слово Office, которое здесь пишется, является Alias – псевдонимом более длинного Microsoft.Office.Core, и впоследствии можно писать не Microsoft.Office.Core, а просто Office, как здесь и делается. После этого в разделе объявлений класса Office.Core.Behind указываются соответствующие элементы, по сути – элементы управления в новом пространстве имен. Office. CommanBar – это, собственно, панель команд. Создаем панель меню, создаем элементы панели меню, это MainMenuBar в главном меню, MenuBarItem – элемент панели меню, MenuItem – элемент меню. Таким образом, используются три переменные уровня модуля. Одна из них, первая, дает ссылку на главную строку меню Excel, другая – на элемент строки меню MenuBarItem, и еще одна – MenuItem – нужна для того пункта меню, для которого и будет обрабатываться событие щелчка по этому пункту. Далее, как только описаны все три уровня, остается написать две функции: первая создает пункт строки меню, вторая – пункт меню, т. е. MenuBarItem и MenuItem. Рассмотрим пример: код первой процедуры, которая называется InitMenuBarItems (рис. 14.4).

Далее создаем новый пункт меню. При этом можно использовать специализированный, заранее определенный обработчик событий ThisWorkBookOpen, т. е., как только открывается книга Excel, автоматически выполняется это событие и фактически в нашем классе Office.Core.Behind создается код, который будет выполняться по этому действию (рис. 14.5).

Здесь командная кнопка создается посредством метода Cre-ateButton, и дальше используется стандартный интерфейс реализации исключений. Наконец можно привязать к скрипту события ThisWorkBookOpen – открытие текущей книги, создание тех элементов управления, о которых было сказано. Создается строка меню, пункт меню и обрабатывается событие – клик по объекту This.MenuItem, снова стандартным образом. При этом используются стандартные процедуры обработки событий, которые существуют в MS Office, точнее в MS Excel. И нужно добавить код, который создает отчет при нажатии кнопки OK или ничего не выполняет при нажатии кнопки Cancel в том окне, которое появляется при выборе пользователем созданного ранее пункта меню. Это происходит при помощи элемента WindowsForm, т. е. создается меню диалога, и можно пользоваться стандартными методами, стандартными результатами DialogResult.OK, DialogResult.Cancel. При этом происходит работа со стандартной формой, которую имеет тип FRMReport и называется FRM, и со стандартным методом ShowDialog, который как раз и генерирует стандартный диалог, стандартное окно с кнопками OK и Cancel.

Рис. 14.4. Создание строки меню

Рис. 14.5. Создание пункта меню и командной кнопки

Завершая разговор о компонентных и офисных приложениях в среде MS.NET, следует сказать о том, что в целом они наследуют важные особенности компонентной модели COM. Но являются более специфичными и позволяют осуществлять построение гибких, настраиваемых, интероперабельных приложений, в том числе с компонентами на разных языках. Что очень важно, осуществляется возможность создания сопровождаемых гибко настраиваемых повторно и многократно используемых приложений на основе различных компонентов, которые могут быть изменены по запросу пользователя и приводить к тиражируемым, коробочным решениям и к решениям, которые не требуют существенных изменений.

Реализация принципа компонентно-ориентированного программирования осуществлена Microsoft и расширена с платформы. NET на надплатформу, которая называется MS Office System, тоже является своего рода платформой и позволяет строить на компонентой основе надстройки – AddIns для приложений уже офисного класса, которые используются в корпорациях для совместной обработки гетерогенных данных. Важно, что все механизмы. NET Framework и CLR внедрены в семейство приложений MS Office, таких как Word – текстовый процессор, Excel – электронные таблицы, Access – базы данных и Outlook – клиент электронной почты. Нужно сказать, что при этом обеспечивается повышенный уровень безопасности за счет интеграции с внутренними политиками безопасности. NET и Windows, реализации механизма сборок, электронной подписи, идентификации автора и версии сборки, за счет манифеста и т. д.

И последнее, что хотелось бы отметить. Сборка, которая для. NET является синонимом компонента, находится структурно посередине между понятием класса языка программирования и понятием модуля корпоративной системы, например модуля учета, планирования и управления основных средств в корпоративной системе Oracle Applications или Oracle Business Suit. Такой подход позволяет создавать интероперабельные, надеждные, масштабируемые и легко изменяемые приложения, и в отличие от конкурирующих подходов, таких как, например, Enterprise Java Beans, обеспечивает языковую интероперабельность, т. е. очень важную возможность реализации компонентов приложения на наиболее подходящих языках программирования.

Глава 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, для реализации стандартных процедур, возникающих у разработчиков при работе с рядом стандартных задач для проектирования и реализации корпоративных приложений.

Глава 16

Разработка корпоративных систем, ориентированных на базы данных (Microsoft SQL Server)

Продолжим тему о системах управления данными, речь о которых уже шла в предыдущей главе, на примере СУБД Microsoft SQL Server 2008.

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

Рассмотрим основные возможности, основные службы, которые реализует этот сервер. Это службы анализа данных; служба обеспечения сетевой готовности; службы интеграции, управляемости, обеспечения производительности и масштабируемости; службы программируемости или обеспечения генерации отчетных данных; служба, обеспечивающая безопасность; службы, обеспечивающие обработку пространственных данных, в частности географических карт. Все знают, что такое Google Maps или Google Earth, у Microsoft тоже есть похожее средство для визуализации картографической информации. Кратко перечислим основные версии Microsoft SQL Server, которые были созданы:

• 1992 г. – SQL Server 4.2;

• 1993 г. – SQL Server 4.21 под Windows N T;

• 1995 г. – SQL Server 6.0, кодовое название SQL95;

• 1996 г. – SQL Server 6.5, кодовое название Hydra;

• 1999 г. – SQL Server 7.0, кодовое название Sphinx;

• 1999 г. – SQL Server 7.0 OLAP, кодовое название Plato;

• 2000 г. – SQL Server 2000 32-bit, кодовое название Shiloh (версия 8.0);

• 2003 г. – SQL Server 2000 64-bit, кодовое название Liberty;

• 2005 г. – SQL Server 2005, кодовое название Yukon (версия 9.0);

• 2008 г. – SQL Server 2008, кодовое название Katmai (версия 10.0).

Истоки современного SQL-сервера имеют достаточно продолжительную историю. Это порядка 15 лет, даже, наверное, больше и, пожалуй, где-то на версии 7.0 (1999 г.) с кодовым названием «Сфинкс» Microsoft удалось выйти на рынок корпоративных систем. До этого решения были для малых, настольных систем, и здесь достаточно серьезно был улучшен интерфейс, возможности. В итоге Microsoft удалось создать достаточно серьезную масштабируемую систему. Можно долго рассказывать о том, кто и как называл свои SQL-серверы из основных производителей, ведь Oracle-сервер называется Enterprise Server, и Microsoft одно время использовала это название, и слова SQL Server тоже были использованы многими производителями. Пожалуй, версия 7.0 была первой версией с серьезным графическим интерфейсом для администрирования, с хорошими, удобными средствами администрирования и существенной коррекцией исходного кода, по сути, полной переработкой исходного кода, для устранения претензий со стороны Sybase.

Версия 2005 появилась в ноябре 2005 г., вместе с Visual Studio 2005. Понятно, что это платформа. NET, и обеспечивалась интеграция не только с платформой, но и со средством разработки. Пожалуй, в SQL Server 2005 было наиболее серьезное развитие интегрированной среды разработки, и был создан и разработан ряд дополнительных подсистем. В частности, это система извлечения/ преобразования/загрузки данных ETL, а также компонентов интеграции SQL Server Integration Services, далее будем называть эту технологию SSIS, OLAP-сервер аналитической обработки или онлайн-обработки многомерных моделей данных и сбора релевантной информации. Эти службы находятся в составе Microsoft Analysis Services и ряда служб сообщений (Service Broker, Notification Services). По сути, на этой платформе с небольшими, но важными изменениями, направленными на интеграцию и на еще большую специализацию корпоративных приложений, и построен SQL Server 2008.

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

Как правило, данные хранятся на серверах, которые входят в состав центра обработки данных, Data Center. В этом заключается концепция данных корпорации Microsoft. При этом SQL Server 2008 позволяет осуществлять доступ к данным практически из любого корпоративного приложения, которое основано на технологии, на платформе. NET и на инструментальном средстве Visual Studio. С другой стороны, осуществляется возможность работы в рамках сервисно-ориентированной архитектуры при поддержке Microsoft BizTalk сервера, который обеспечивает интеграцию корпоративных приложений на основе SOA, а также бизнес-процессов этой архитектуры.

Таким образом, сотрудники, которые отвечают за сбор и анализ информации, могут работать как с данными в системе Microsoft Office, так и с другими корпоративными приложениями внутри корпорации. Фактически они работают в привычной офисной среде и пользуются механизмами Visual Studio.NET, платформой. NET и SQL Server 2008. При этом поддерживаются надежность, высокая производительность и достаточно интеллектуальная обработка, извлечение, коррекция, интеграция, составление отчетов и трансформация этих отчетов в офисные форматы, которые отвечают всем основным требованиям по работе с данными, представленными и реализованными в Microsoft Office, Microsoft.NET платформе. Как видно из рис. 16.1, который описывает SQL Server, этот сервер поддерживает обработку данных на основе концепции центра данных.

Рис. 16.1. SQL Server как центр данных

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

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

Интеллектуальный анализ данных осуществляется на платформе Microsoft Business Intelligence (Microsoft BI) с возможностью реализации упреждающей аналитики, встроенной в SQL Server 2008. Здесь используются мощные средства анализа данных, которые позволяют осуществить интеграцию с произвольными офисными и корпоративными приложениями. Обеспечивается высокий уровень сетевой доступности и готовности, минимизирующей время простоя и поддерживающей должный уровень доступности приложения. Службы интеграции отличаются хорошей масштабируемостью и степенью извлечения, преобразования и загрузки данных, а также широкими возможностями интеграции гетерогенных источников данных различной степени структурированности. Система управляемости основана на принципе политик, который позволяет управлять одним или несколькими экземплярами серверов.

Кроме того, существуют средства контроля производительности тонкой настройки, поиска и устранения неполадок, которые позволяют администратору увеличить эффективность управления данными различных экземпляров SQL-серверов. Средства производительности и масштабируемости поддерживают как вертикальную масштабируемость для отдельных серверов, так и горизонтальную для больших баз данных, а также средства оптимизации производительности в форме консоли, которая достаточно удобна. Поддерживаются различные средства создания программных расширений при помощи платформы. NET Framework и Visual Studio Team System, поддерживающей командную разработку.

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

Продолжим обсуждение служб Microsoft SQL Server. Что касается служб, которые связаны с анализом данных, то прежде всего это OLAP-служба, для создания и развертывания новых систем разработчикам приходится осваивать и использовать много новых средств. При использовании служб Analysis Services можно использовать на платформе Visual Studio единую среду разработки, которая называется BIDS (Business Intelligence Development Studio). По сути, это надстройка над Visual Studio, которая также связана со средством командной разработки Team System: в связи с этим у разработчиков есть ресурсы для проектирования, разработки, совместной работы, оптимизации и тестирования. В результате появляется интегрированная среда с интуитивно ясным интерфейсом, где разработчики могут достаточно быстро и эффективно создавать приложения. Кроме того, повышается производительность труда при разработке за счет мастеров бизнес-аналитики, Business Wizards, которые дают возможность даже начинающим пользователям строить модели достаточно сложных задач бизнес-аналитики. Таким образом, разработка решений, в том числе многомерная, OLAP, использование механизмов KPI анализа ключевых показателей и других задач, связанных с OLAP-обработкой данных, становится доступной большому количеству аналитиков, а не профессионалов в области разработки.

Проверка корректности структуры данных в интерфейсе SQL Server (рис. 16.2) реализуется посредством иерархии Calendary и по отношению к измерению времени на основе оповещений. Это одно из новых дополнений, которое автоматически информирует о возможных недочетах на ранних стадиях процесса разработки, позволяет сократить потери времени, вызванные проектными ошибками, и ускорить разработку. Это просто пример оповещения. Как видно из рисунка, выделяются проблемные области, они подсвечиваются. При этом они не затрагивают функциональность системы, поскольку оповещения можно как игнорировать, так и отклонять либо по отдельности, либо глобально. Вообще же таким образом можно осуществлять контроль над относительно неэффективными решениями на ранних этапах разработки. Напомним, что методология Microsoft призвана как раз выявлять ошибки на ранних стадиях разработки и осуществлять в связи с этим оптимизацию производительности по затратам времени и средств. Кроме создания оповещений в реальном времени, возможно насквозь осуществлять сканирование проекта решения и затем выдавать текущее оповещение по проекту, как это показано на рис. 16.3, который демонстрирует набор правил для проверки корректности, в том числе на основе OLAP-анализа данных, многомерной оптимизации, анализа многомерных данных на основе куба в пространственном приложении и т. д.

Рис. 16.2. Проверка корректности структуры данных

Рис. 16.3. Набор правил для проверки корректности

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

Рис. 16.4. Проектирование связи между атрибутами

Рисунок 16.5 демонстрирует интеграцию с офисными приложениями, в том числе с Microsoft Excel.

Частично возможности подобной интеграции рассматривались при обсуждении офисных приложений. Нужно добавить, что приложение Excel 2007 является полнофункциональным клиентом служб Analysis Services, которые входят в состав SQL Server 2008. При этом возможности Excel 2007 поддерживаются в следующих областях: это доступ к данным, которые хранятся в OLAP-кубах служб Analysis Services. Excel позволяет создавать сводные таблицы с представлением многомерных данных, т. е. пользователи в рамках привычных им интерфейсов Microsoft Excel могут по-разному разбивать данные, обрабатываемые на сервере, результаты кэшируются на сервере и на клиенте и дают возможность повышения производительности вычислений. Доступ пользователей к функциям и аналитическим возможностям служб Analysis Services – это ключевой показатель эффективности KPI, вычисляемые элементы, именованные наборы данных, есть и переводы, также осуществляются централизованно.

Рис. 16.5. Интеграция с MS Excel

Надстройки над приложениями Office 2007, не только Excel, но и над другими приложениями, для извлечения и обработки данных, которые предоставляют в распоряжение конечных пользователей средства анализа и прогноза данных, реализованы в SQL Server 2008. Новой является функция автоматического анализа, например, определение исключений, в которых данные отличаются от шаблонов, которые заранее заданы или наблюдаются в других областях таблицы, а также специализированных диапазонов данных, которые можно выделить, функции предсказания будущих данных по текущим тенденциям, анализ сценариев моделирования по определенным условиям, определение изменений, необходимых для достижения какой-либо конкретной цели, также можно фиксировать и отслеживать. Создание отчетов по информации, которая предоставлена службами Analysis Services, при помощи служб отчетов Reporting Services и визуализация этих отчетов в виде таблиц Excel дают возможность обеспечить большую доступность для конечных пользователей.

Далее обсудим средства и пути анализа данных. Используются средство Data Mining Client для Excel 2007 и определенные шаблоны, которые поддерживают интеграцию Data Mining, добычу данных для Visual Studio 2007. В надстройке BIDS (Business Intelligence Development Studio) Visual Studio 2007, о которой уже говорилось, используется средство Data Mining Designer. Естественно, реализация средств анализа данных основана на концепции объектов, и используется подход Analysis Management Objects (AMO) и открытые интерфейсы API на его основе. Также возможно подключение сторонних алгоритмов для анализа данных.

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

Как и в случае с OLAP-технологиями, извлечение и обработка данных ранее было прерогативой узких специалистов высокой квалификации и было поэтому дорогостоящим. Однако сейчас за счет комплексной реализации технологии извлечения и обработки данных в службах Analysis Services и тесной интеграции с приложениями Office 2007, в частности Excel, корпорации Microsoft удалось создать достаточно эффективные экономические решения, которые позволяют практически каждому пользователю, знакомому с Office, делать задачи по извлечению и анализу данных на основе использования служб Service Analysis платформы SQL Server.

Проиллюстрируем возможности извлечения данных, Data Mining, на основе стандартного клиента для Microsoft Excel 2007. Именно это средство облегчает извлечение и анализ данных для пользователей, поскольку основано на стандартной платформе Office. Этот набор средств дает возможность эффективного анализа и визуализации различных представлений данных (рис. 16.6) средствами офисных приложений, в данном случае электронные таблицы.

Рис. 16.6. Data Mining Client для Excel 2007

Таким образом, пользователи могут повысить эффективность принимаемых ими решений, оперативно получая практические рекомендации путем выполнения нескольких простых действий, для чего существует специализированная надстройка, которая называется Table Analysis Tools для Excel 2007. Сложность извлечения и обработки данных при этом инкапсулируется набором интуитивно понятных задач, которые дают возможность пользователям относительно прозрачно переходить от исследования к построению предметно-ориентированного решения на основе тех понятий, которыми они владеют, в бизнес-терминах и производить эффективное извлечение и анализ данных, проверять их корректность и осуществлять доступ к этим данным. Также существуют шаблоны, которые называются Data Mining Templates и позволяют извлекать и обрабатывать данные на основе приложения Visio. Хотелось бы напомнить, что Visio имеет средства интеграции с Microsoft Visual Studio и является на сегодня компонентом Microsoft Office, т. е. интегрирован и с. NET, и с SQL Server 2008. При этом возможно достаточно легкими средствами генерировать большое количество стандартного рода диаграмм и таким образом формировать широкую, интуитивно понятную и способствующую коллективной работе систему, которая открывает путь к повышению эффективности совместно принимаемых бизнес-решений по всей корпорации с учетом анализа и прогноза данных.

На рис. 16.7 представлен пример применения средства Data Mining Designer, который позволяет интегрировать средства извлечения данных и бизнес-аналитики в пакет Microsoft Office 2007.

Рис. 16.7. Пример применения средства Data Mining Designer

При этом используется средство интеграции с SQL Server, которое называется BIDS. Оно имеет проектно-ориентированную структуру и содержит все средства, которые позволяют отлаживать и управлять исходными текстами, как и в Visual Studio, для того чтобы бизнес-аналитики могли не только проектировать, но и создавать и корректировать собственные решения. Естественно, такой подход возможен только для достаточно квалифицированных пользователей, которые могут создавать собственные системы, и позволяет грамотно распределять функционал между пользователями разных уровней, декомпозировать задачи и получать их решения в сжатые сроки и с наивысшим качеством.

Business Intelligence Development Studio – это фрагмент SQL Server, который представляет собой комплексную среду разработки на основе Microsoft Visual Studio, это надстройка над Visual Studio. С помощью этой среды разработчики могут создавать структуру данных для их извлечения и обработки, могут настраивать доступ к данным по столбцам, к данным таблиц, добавлять множество моделей для извлечения и обработки данных, в том числе гетерогенных, слабоструктурированных, которые предусматривают различные алгоритмы извлечения данных и размещения их в этих таблицах. По сути, речь идет о применении технологии, схожей с DataGrid, т. е. достаточно гибкой технологии по извлечению и представлению данных, их форматированию для создания корпоративных консолидированных отчетов.

Шаблон приложения проекта служб Analysis Services BIDS, изображенный на рис. 16.8, включает в себя средства проектирования с интуитивно понятным интерфейсом для создания и просмотра моделей извлечения и обработки данных, а также обеспечивает перекрестную проверку корректности и построения диаграмм превышения и прибыли.

Рис. 16.8. Performance Point Server

Это позволяет перед развертыванием моделей сравнить их качества, причем используя средства визуального контроля, и по результирующим статистическим метрикам погрешности и точности обеспечивает корректный выбор процедуры дальнейшего развития корпоративных систем и корпоративной стратегии. Существует стандартное средство, встроенное в Microsoft SQL Server, которое называется Performance Points Server и создано для оценки и анализа KPI (Key Performance Indicators) – основных показателей бизнес-деятельности.

На рис. 16.8 представлено решение, которое используется на значительном количестве предприятий корпоративного типа для оценки соответствия различных плановых значений, прежде всего финансовых показателей, ключевым значениям. Это одна из основных бизнес-метрик. Служба Analysis Services SQL Server 2008 обеспечивает централизованную базу данных для учета KPI в масштабах всей корпорации. При этом существует приложение Microsoft Office Performance Point Server 2007, с которым поддерживается интеграция, что дает возможность топ-менеджерам и лицам, принимающим решения, создавать специализированные панели, Dashboard или аналоги приборной панели, где они могут отслеживать ключевые показатели компании и принимать решения на основе динамики анализа этих показателей. При этом ключевые показатели традиционно имеют ретроспективный характер. Можно отслеживать, например, динамику продаж с учетом изменения запасов за последний месяц, квартал, год и т. д., а располагая знаниями прогностического анализа, организация может формулировать ключевые показатели KPI на будущие периоды и планировать свою деятельность, выявлять и разрешать потенциальные проблемы и узкие места.

На рис. 16.8 изображен один из показателей эффективности KPI, а именно число заказов, которые относятся к будущему периоду и, как ожидается, будут размещены впоследствии. Рисунок 16.9 иллюстрирует Reporting Services.

Следует напомнить, что построение консолидированных отчетов является важной целью для каждой корпорации, для анализа результатов функционирования различных компаний, подразделений и видов деятельности. Для построения такого рода отчетов существуют службы Reporting Services на платформе SQL Server 2008, которые дают возможность генерации параметрических отчетов исходя из прогнозируемой вероятности. Например, рис. 16.9 иллюстрирует результаты запроса, который анализирует список потенциальных клиентов некоторой гипотетической компании Adventure Works, занимающейся продажей велосипедов, и оценивается вероятность покупки этими клиентами велосипедов. Запрос фильтруется таким образом, чтобы в результате возвращались только те потенциальные клиенты, для которых вероятность покупки превышает 50 %. Представлен полученный отчет, на основе которого корпорация может разработать маркетинговую кампанию, нацеленную только на ту аудиторию, которая с наибольшей вероятностью осуществит такую покупку велосипеда. Подобная процедура существенно повышает эффективность работы корпорации по направлениям и дает возможность обеспечить окупаемость инвестиций.

Рис. 16.9. Reporting Services

Следующая схема иллюстрирует обеспечение сетевой готовности в рамках SQL Server 2008:

• поврежденные страницы данных можно восстановить с зеркального сервера благодаря улучшенному зеркалированию баз данных;

• улучшения в создании отказоустойчивых кластеров в ОС Windows Server 2008;

• новые узлы в одноранговую репликацию можно добавлять во время работы, не отключая репликацию;

• сжатие резервных копий позволяет сократить время, требуемое на восстановление, а также уменьшить количество занимаемого резервными копиями пространства;

• изменения в механизме блокировок улучшают одновременную работу;

• возможность горячей замены процессора снижает время простоев из-за обслуживания оборудования;

• регулятор ресурсов позволяет осуществлять упреждающий контроль приоритетности рабочей нагрузки.

Как указывалось ранее, хранение данных под управлением СУБД осуществляется в страницах памяти. Если происходит повреждение страниц данных, например в результате программного или аппаратного сбоя, то поврежденные страницы можно восстановить благодаря улучшенному зеркалированию баз данных, используя зеркальные серверы. Также реализован целый ряд механизмов по усовершенствованию отказоустойчивости кластеров на основе функционирования ОС Windows Server 2008, т. е. на уровне ОС. Новые узлы, т. е. новые машины, можно добавлять во время работы сервера, не отключая механизмы репликации, и при этом репликация продолжается. Резервные копии могут храниться в сжатом виде, что обеспечивает сокращение времени восстановления и позволяет существенно уменьшить количество пространства, которое отводится на хранение резервных копий. Изменения в механизме блокировок транзакций, улучшенная обработка блокировок транзакций (существуют взаимные блокировки транзакций и целый ряд проблем, связанных с разрешением этих блокировок) улучшают одновременную работу большого количества пользователей, что является крайне важным для корпоративных приложений. Кроме того, существует возможность горячей замены процессора сервера базы данных, что обеспечивает снижение времени простоя и, кроме того, может обеспечить динамическую приоретизацию с упреждающим контролем приоритетности нагрузки, т. е. улучшенное управление ресурсами.

Еще один важный аспект функционирования Enterprise Server 2008 связан с SSIS (SQL Server Integration Services) – службой интеграции, в данном случае он существенно улучшен по сравнению со стандартным ETL-подходом к интеграции, который лежит в основе большинства информационных хранилищ. ETL – это извлечение, преобразование и загрузка данных. Однако потребности в реализации совместного использования большого количества разнообразных источников данных, а также соседство глобальных онлайновых операций быстро меняют традиционные требования к интеграции данных. При этом для извлечения максимальной выгоды, достижения максимальной эффективности собранных и подлежащих анализу данных необходимо повышение эффективности интеграции этих данных для повышения эффективности принятия решений и обеспечения консолидированных отчетов. В связи с этим службы интеграции дают нам возможность построения достаточно гибкой и масштабируемой архитектуры, которая повышает эффективность интеграции гетерогенных данных различной степени структурированности, в различных корпоративных бизнес-средах. Для корпорации Enterprise Server является достаточно хорошим решением.

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

Рис. 16.10. Отсутствие промежуточного хранения данных

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

Рассмотрим структуру SSIS – Microsoft SQL Server Integration Services. В основе лежит разделение на потоки задач и потоки данных, без промежуточного хранения и без дублирования информации. SSIS содержат ядро поддержки потока задач, которое ориентировано на операции, а также масштабируемое быстрое ядро поддержки потока данных. Поток данных при этом существует в контексте общего потока задач. Первое ядро предоставляет ресурсы и поддержку операций для второго ядра. Такое сочетание потоков задач и потоков данных этих двух ядер обеспечивает эффективность подхода как для традиционных ETL-решений, так и для гетерогенных информационных хранилищ. При этом во многих более сложных ситуациях, например при поддержке центров обработки данных, использование подобного подхода оправданно и повышает эффективность.