Глава 7

Средства автоматизации разработки корпоративных систем

От методологической и модельной части перейдем к части, которая в большей мере касается практики.

Обсудим более подробно CASE-средства.

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

Речь пойдет о попытках классификации CASE-средств. Их существует великое множество, и их число непрерывно растет. В последнее время популярна тема DSL (Domain Specific Languages) – предметно-ориентированных языков, которые нацелены на какие-то конкретные, узкие предметные области. Для них существуют как большие CASE-средства, такие как Microsoft Visual Studio, в который можно встроить такого рода языки и поддержку диаграмм, так и специальные средства, которые появляются достаточно часто. В любом случае причина появления подобных средств понятна (они будут рассмотрены более подробно), но прежде следует подвести некоторые итоги того, что было рассмотрено в предыдущей части курса моделей и методологий, а также сделать краткие выводы, чтобы перейти к практической части более естественным образом.

По поводу моделей и методологий нужно заметить, что это наиболее абстрактная формализация всего жизненного цикла ПО. Как правило, методологии включают все этапы ЖЦ, за редким исключением. Правильный выбор модели и методологии (если речь идет о жизненном цикле, то лучше употреблять термин «модели», методологии – это просто набор практических приемов реализации этого ПО того или иного программного проекта или программного продукта). Выбор модели критическим образом сказывается в целом на успехе проекта, поскольку он определяет архитектуру проекта, архитектуру решения, из какого количества компонентов будет состоять решение, какие технологии будут использоваться, как эти компоненты будут взаимодействовать. Во многом определяется экономика проекта, поскольку существует глобальный документ – план проекта, тесно связанный с той моделью и методологией, которая принимается для разработки. И в этом плане, естественно, трудозатраты будут указываться в соответствии с выбранной моделью. Некоторые модели, скажем каскадная, поддерживают проектирование в один проход, являются документоориентированными, другие – неполный жизненный цикл, например модель Build-and-fix (модель проб и ошибок), либо итеративную или эволюционную разработку, когда на каждом этапе после завершения каждого частичного цикла появляется в общем готовый с точки зрения надежности продукт, пусть и не полнофункциональный. Здесь тоже во многом можно вести речь о раннем начале сопровождения, т. е. тоже об экономике проекта. Конечно, модель, также как и методология, должна учитывать опыт проектной команды. Естественно, если вести речь о больших системах, команда должна иметь опыт работы с той или иной моделью, с теми или иными стандартами. Конечно, серьезные модели требуют определенной дисциплины при проектировании и зрелости проектной команды, нужно соблюдать стандарты и знать в том числе CASE-средства, используемые командой для всех этапов проектирования и реализации системы. Поэтому стоит обсудить CASE-средства более подробно.

Универсальной модели не существует так же, как и универсального CASE-средства, несмотря на то, что есть линейка Rational, которая поддерживает практически все этапы жизненного цикла, Microsoft Visual Studio – достаточно серьезное средство, в том числе и для командной работы. Поэтому в ряде случаев хорошим подходом является комбинирование. Конечно, у всех моделей, также как и у всех CASE-средств, есть свои определенные преимущества и недостатки, они ранее упоминались. Так, спиральная модель требует оценки рисков, что, с одной стороны, является преимуществом, а с другой – влечет достаточно серьезные затраты, поэтому ее лучше применять для внутренних проектов, где разработчик может получить от заказчика полную информацию о рисках и сложностях, с которыми можно столкнуться в проекте с точки зрения представления предметной области. Преимущества и недостатки имеют смысл только в контексте проекта, исходя из этого следует выбирать не только модель жизненного цикла и методологию разработки, но и те технологические средства и архитектурные особенности, которые будут лежать в основе поддержки этого проекта.

По поводу проектирования и управления базами данных необходимо напомнить, что в основе корпоративных систем лежат базы данных достаточно большого объема, измеряемые тера-, а в ряде случаев – петабайтами (1015 байт). Размер, которого они могут достигать, достаточно быстро возрастает, примерно в 2 раза за пять лет. Это можно считать экспоненциальным ростом при достаточно больших базовых объемах, поэтому достаточно важно рассмотреть базы данных как элемент корпоративных систем.

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

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

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

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

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

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

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

Конечно, перспективны компонентные корпоративные приложения, как в архитектуре. NET или Java Bins, масштабируемые, мобильные, естественно, существуют и мобильные версии приложений. Компонентный подход. NET предполагает и мобильную версию. Например, мобильный смартфон на платформе Windows Mobile 5.0 также имеет. NET Framework, семейство классов. NET, и на том же самом языке C#, о котором пойдет речь, можно вести проектирование так же, как и на большой системе. Корпоративные клиенты могут получать доступ к данным с таких устройств. Как на платформе. NET, так и на платформе Java возможны подобные решения. Речь идет о клиент-серверных решениях, причем, как правило, трехзвенных, с явным выделением прикладной логики в отдельный слой. Перспективные направления развития корпоративных систем – это кроссплатформенность, т. е. возможность миграции с платформы на платформу (здесь под платформой можно понимать операционную систему и более высокий прикладной уровень), также интероперабельность и безопасность, это достаточно важные тенденции. Интероперабельность связана с компонентным проектированием, т. е. с возможностью гибкого наращивания функциональности или производительности за счет небольшой локальной доработки отдельных компонентов.

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

Как уже было отмечено, важные составляющие корпоративных систем – это база данных и СУБД. Перечислим основные стандарты, которым имеет смысл следовать, определившись со стратегией и тактикой реализации корпоративного приложения. В частности, большое значение имеют стандарты UML, Rational Unified Process и Microsoft Solution Framework. Существуют корпоративные стандарты, ряд объектных стандартов, например COM, DCOM, COM+, объектные модели Microsoft, модель Java Bins, компонентная модель Java, модель брокеров объектных запросов CORBA и целый ряд других. Здесь, может быть, нет строгой математической интерпретации, но тем не менее это некая формализация и во многом официальный стандарт, которого следует придерживаться.

В сложных системах, как правило, возникает понятие объекта, как и в современных базах данных. И соответственно проектирование и реализацию этих систем нужно вести с учетом понимания природы этих объектных моделей, и, конечно, для корпоративных систем необходимо использовать достаточно строгие методологии, такие как RUP, MSF, которые дают возможность, с одной стороны, адаптироваться к требованиям заказчика, а с другой – обеспечить достаточно полный набор проектной документации и должной детализации выхода по проекту. Следует напомнить, что выход по проекту и программный продукт – это не только программный код, но и документация, техническое задание или список требований, функциональных и других проектных ограничений, целый ряд диаграмм, описывающих сценарии использования, прецеденты, классы, которые будут проектироваться, динамику взаимодействия (диаграммы переходов состояния, диаграммы последовательностей, взаимодействия, потоков данных, клиент – объект, которые ведут нас к ответственному проектированию, и др.), документация к коду, находящаяся внутри кода к каждому модулю, построчная документация к коду модуля, документация к модульным интерфейсам и общая документация, которая включает документацию для специалистов по установке программ, настройке, конфигурированию, и пользовательская документация, в том числе краткая и полная инструкции по эксплуатации программного обеспечения.

Теперь уже предметно рассмотрим CASE-средства, которые помогают автоматизировать проектирование корпоративных приложений. Попробуем выделить несколько направлений классификации CASE-средств, принципы их упорядочивания, организации, поскольку их действительно достаточно много и многие из них реализуют целый ряд полезных идей, которые было бы целесообразно использовать при производстве корпоративных приложений. Рассмотрим классификации по масштабам применения, видам моделирования (здесь речь идет не совсем о математических моделях, хотя есть CASE-средства, которые используют раскрашенные сети Петри и другие интересные математические формализации, но их не так много) и функциональному назначению. Дадим определение CASE-средств, рассмотрим их основные функции и состав, а также достаточно большое количество примеров с описанием функций основных CASE-средств, которые популярны прежде всего в нашей стране. На Западе традиционно используется немного иной набор CASE-средств. Например, в России достаточно популярно CASE-средство Borland Delphi, а в США оно практически не используется, т. е. срез распространенности, или популярности, CASE-средств в нашей стране и за рубежом выглядит иначе.

Что такое CASE, или Computer Aided Software Engineering? Software Engineering – это программная инженерия, та самая дисциплина, которая и ведет к построению качественных, надежных, производительных, масштабируемых, больших программных систем и комплексов, в том числе в масштабах корпорации. А CASE – это инструментальные средства, которые поддерживают создание таких систем, т. е., по сути, весь жизненный цикл корпоративных приложений. Рассмотрим основные этапы жизненного цикла и задачи, которые пользователи CASE-средств или разработчики решают в ходе создания корпоративных приложений. Во-первых, это анализ и спецификация требований к функционалу и других проектных ограничений к программному обеспечению, которое будет создаваться, проектирование прикладного программного обеспечения и баз данных, т. е. речь идет о диаграммировании и архитектурном проектировании. CASE-средства позволяют в отношении баз данных строить схему базы данных по ER-модели, по ER-диаграмме. Кодогенерация в определенной мере производится также автоматически, например, по диаграмме классов можно строить сигнатуры классов автоматизированно, а также вести трассировку проектных спецификаций.

Когда речь идет о модели Microsoft, или модели синхронизации и стабилизации, следует заметить, что эта модель достаточно сложна, поскольку она требует автоматизации тестирования. Также стоит отметить, что средства тестирования, такие как Rational Robot, достаточно широко распространены в мире CASE-средств. Есть похожее средство и у Microsoft.

Рассмотрим средства документирования. Когда речь идет о большом количестве билдов, большом количестве релизов ПО, нужно поддерживать каждый релиз своей версией документации, которая также имеет версии. Вести контроль этих версий и изменений, которые были внесены, достаточно сложно, особенно если документирование ведется вручную и документация имеет большой объем, вполне сопоставимый, а иногда и превосходящий объем кода. Скажем, документация только для пользователей по одному модулю Oracle Applications – это книга объемом примерно 700 страниц с большим количеством иллюстраций, перекрестными ссылками, глоссарием и целым рядом других вещей для быстрого поиска информации. Конечно, создавать такие документы вручную и отслеживать их взаимосвязи, что очень важно в проекте, в случае корпоративных систем без CASE-средств невозможно.

Далее речь пойдет о системах обеспечения качества, в том числе тестирования и трассировки спецификации. Рассмотрим управление конфигурацией. Как было отмечено ранее, проекты сложны, в них большое количество файлов (тысячи, может быть, десятки тысяч) и каждая версия характеризуется их уникальным набором. Если некорректно учитывать состав этой версии и собирать ее, ПО будет ненадежным или вообще неработоспособным. Когда речь идет о корпоративной системе, это, конечно, недопустимо. Поэтому управление конфигурацией, полный учет модулей и проектной документации, которая их сопровождает, – это тоже важная функция CASE-средств. Еще одной важной функцией является управление проектом, организация взаимодействия на основе, скажем, программного инструментального CASE-средства Microsoft Visual Studio Team System, и целый ряд других процессов.

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

Какие компоненты входят в состав современных CASE-средств? Это прежде всего репозиторий (единое хранилище метаданных), здесь поддерживается средство хранения версий. Как уже упоминалось, существуют основные или базовые версии, к которым пристраиваются «ветви», или определенные направления, ветвления попыток совершенствования системы. В определенный момент их замораживают или закрывают на замок (lock), делают операцию замыкания и некий стабильный релиз, который полностью обособлен и может быть использован, скажем, на этапе приемки работ или этапе завершения какой-то определенной фазы жизненного цикла ПО. Очень важно при этом поддерживать синхронизацию. Например, если кто-то из разработчиков откомпилировал и сохранил новую версию файла, то нужно добиться, чтобы эта локальная версия файла переходила в глобальный билд как компонент, когда он уже готов и протестирован вместе с соседними модулями. Контроль целостности – тоже важный аспект в случае баз данных. Скажем, если удалить последнего сотрудника из отдела, что должно происходить с отделом? Кроме того, ведется контроль целостности не только на уровне структур данных, но и на уровне проектных спецификаций. Нужно убедиться в том, что они полны, непротиворечивы и те диаграммы, которые разрабатываются, в том числе с помощью CASE-средств, действительно являются адекватным отображением ранних шагов моделирования жизненного цикла ПО.

CASE-средства включают также графические средства как для анализа и проектирования, так и для последующих шагов жизненного цикла. Это возможность создания и редактирования целого ряда диаграмм, например Microsoft Visual Studio, которая поддерживает большое количество диаграмм на основе интеграции со средством Visio. Линейка Rational поддерживает практически все виды UML-диаграмм, поскольку изначально ориентирована на этот язык и стандарт моделирования. Другой стандарт – это IDEF, диаграмма потоков данных, ER-диаграммы и ряд других диаграмм относятся к этому стандарту.

Другими компонентами CASE-средств являются средства, поддерживающие разработку прикладного ПО, т. е. создание программного кода. Здесь сразу следует отметить такие интересные возможности, как IntelliSense с цветовой подсветкой синтаксиса, выделением метаинформации, например, членов данных классов при вводе имени класса и т. д., которые существуют в Microsoft Visual Studio.NET.

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

Какого рода критерии классификации можно выделить, если вести речь о CASE-средствах? Их достаточно много. Первые CASE-средства появились в 1990-х гг. В журнале «Byte» от марта 1993 г., который был полностью посвящен CASE-средствам, были описаны методологии проектирования и поддерживающие их CASE-средства. Существовала методология Буч известного автора Гради Буча, сотрудничество которого с Якобсоном и Рамбо привело к созданию языка UML с целым рядом диаграмм. Ивар Якобсон тоже работал в те времена, когда происходило становление CASE-средств. Первые CASE-средства были основаны в том числе на диаграммах потоков данных, так как объектных моделей в полной мере тогда, наверное, не было или они были в начальном состоянии. Также широко использовались ER-диаграммы.

Итак, к основным критериям можно отнести степень интегрируемости, т. е. то, какую долю этапов жизненного цикла поддерживает это CASE-средство, предназначено ли оно только для анализа и проектирования или только для тестирования или для реализации и интеграции, или для документирования, или это CASE-средство или комплекс CASE-средств, которые поддерживают целый ряд этапов жизненного цикла (например комплекс CASE-средств от Rational поддерживает практически весь жизненный цикл). Существуют локальные, частично или полностью интегрированные CASE-средства, т. е. некоторые CASE-средства предназначены исключительно для работы в настольном режиме, однопользовательском, другие – преимущественно для командной работы, разработки больших корпоративных систем. Существуют полностью интегрированные средства, имеющие общий репозиторий, в котором все метаданные проекта хранятся вместе: это и общение по проекту, и конфигурация продукта, и документация. Фактически все эти артефакты хранятся вместе в общей базе метаданных и позволяют получить общий доступ с учетом ролей к тем или иным компонентам проекта.

Естественно, хорошим критерием классификации может явиться стандарт. Скажем, поддерживают ли CASE-средства UML-диаграммирование, или IDEF-диаграммы, или XML как формат хранения и т. д. Методологии проектирования тоже очень важны. Поддерживает ли это средство MSF или Rational Unified Process и в каком объеме, в каких аспектах? Какие модели корпоративных информационных систем, в частности баз данных, поддерживаются? Поддерживаются ли ER-модели и вообще реляционные модели данных или, может быть, поддерживается сетевая иерархическая модель данных, объектная модель определенного рода?

С какого рода СУБД эти CASE-средства интегрированы – еще один критерий. Может быть, эти средства рассчитаны только на кодогенерации, ведь структуры данных могут быть снабжены также ограничением целостности и триггерами и хранимыми процедурами на определенных языках. Скажем, существует язык PL/SQL, который предназначен специально для СУБД Oracle, и какие-то CASE-средства поддерживают только базы данных Oracle или ориентированы преимущественно на Oracle, другие ориентированы преимущественно на Microsoft SQL Server. Эти базы данных и SQL-серверы более подробно будут рассмотрены в дальнейшем.

Начнем по порядку рассматривать CASE-средства и отмечать те их аспекты, которые полезны и укладываются в ту или иную классификацию. Одним из первых CASE-средств, достаточно серьезных и хорошо известных в нашей стране, является BPwin. Как правило, оно используется в комплексе с Erwin, которое генерирует ER-диаграммы и по ER-диаграммам – схемы базы данных. Автором является Computer Associates. Здесь поддерживается методология IDEF0, DFD-диаграмма потоков данных, и основным назначением является функциональное моделирование и анализ деятельности предприятия. То есть речь идет об анализе и спецификации требований. Эта часть жизненного цикла в основном и реализуется CASE-средством BPwin.

В качестве модели данных используется не объектная модель данных, а диаграмма процессов, это очень похоже на DFD и является некоторым развитием. Это более ранняя технология, структурный анализ и проектирование (Structured Analysis and Development Technology, SADT), современный подход называется объектно-ориентированным (Object Oriented Analysis and Development, OOAD). При этом учитываются этапность, стоимость, длительность и периодичность процессов, т. е. в основе лежат диаграммы процессов, и с помощью этого средства возможно проанализировать бизнес-процессы на предприятии, их формальное описание и построение определенных диаграмм, которые позволят оценить стоимость затрат на внедрение системы, узкие места технологических цепочек и затратные центры – другими словами, точки, которые потребуют наибольших затрат.

Полезна интеграция с Erwin, которая поддерживает ER-модель как направление, и генерация отчетов в достаточно распространенных форматах офисных приложений MS Word, MS Excel. Связанным с этим CASE-средством является CASE-средство Erwin той же компании изначально. Это CASE-средство для проектирования и реализации баз данных, т. е. работа идет с IDEF1X-диаграммами, с ER-диаграммами стандартного вида. Здесь достаточно полный набор возможностей: можно строить, настраивать, проектировать в графическом виде ER-диаграммы с атрибутами сущностей, связей, поддерживать индексы и ограничение целостности на основе бизнес-правил.

При этом поддерживается достаточно большое количество SQL-серверов или серверов баз данных – это и Oraсle, и Microsoft, и целый ряд других (Informix, Sybase, Progress, DB2 от IBM) СУБД корпоративного типа. И кроме того, поддерживаются достаточно легкие настольные системы, большинство из них, конечно, уже устарело, но Microsoft Access, например, достаточно современная система, Clipper до сих пор используется, также как и СУБД Paradox, в свое время созданная корпорацией Borland, и целый ряд других систем. При этом важно, что по ER-диаграммам автоматически производится генерация SQL-кода и триггеров, т. е. процедуры, которые поддерживают ограничение целостности. Возможен реинжиниринг базы данных, т. е. по SQL-коду можно восстановить структуру базы. Поддерживает кроме большого количества серверов баз данных достаточно большое количество CASE-средств, и осуществляется возможность коллективной разработки баз данных. Здесь поддерживаются форматы Oracle, Sybase, Microsoft SQL Server.

Что интересно, кроме BPwin, возможна интеграция и с другими CASE-средствами от сторонних производителей, в том числе Delphi – достаточно популярным и распространенным в России CASE-средством.

Достаточно интересно CASE-средство, которое называется CASE 4.0. Оно работает по методологии Уорда Мелора, это тоже структурный подход к анализу и проектированию, дообъектный. По сути, речь идет о расширении подходов Йордена, это одна из первых CASE-методологий, появившаяся в начале 1990-х, и Де Марка (тоже достаточно известный подход для информационных систем, которые функционируют в реальном времени). Это важно и для корпоративных приложений, поскольку очень часто нужно обеспечить быстрое построение консолидированных отчетов. Здесь функционирование в реальном времени или с достаточно быстрой обратной связью и небольшим временем реакции является важным требованием.

Поддерживаются следующие этапы жизненного цикла: системный анализ, проектирование, реализация. Естественно, системный анализ, или анализ требований, производится тоже на основе структурного подхода. В структурном подходе преимущественно учитывается какой-то один из аспектов – либо динамический, либо статический. В объектно-ориентированном подходе равное внимание уделяется и данным, и действиям, и динамике, и статике. То есть если мы посмотрим на класс, основное понятие объектно-ориентированного программирования, то увидим, что он содержит как атрибуты, так и методы, т. е. как некоторые статические числовые характеристики, так и методы, которые позволяют динамически изменять значения этих характеристик. Существует свой репозиторий, который позволяет этому CASE-средству поддерживать жизненный цикл, т. е. существует некое хранилище метаданных, ведется контроль целостности схем информационной системы и базы данных, поддерживается коллективная разработка, поэтому фактически речь идет о средстве создания корпоративных приложений. Кроме того, поддерживается целый ряд диаграмм: это устаревшие структурные карты Джексона и достаточно широко используемые ER-диаграммы, диаграммы переходов состояния (State Transition Diagram, STD) и диаграммы потоков данных (Data Flow Diagrams, DFD). В состав этого средства входят следующие компоненты: репозиторий; хранилище метаданных; визуальные редакторы диаграмм, которые позволяют вести визуальное проектирование, в том числе и командное; средства разработки диалоговых интерфейсов; средство кодирования, редактирования кода и производства документации; клиентская часть. Здесь стоит отметить общий репозиторий, который хранится на сервере, скажем, локальной сети, и серверную часть, которая является кроссплатформенной. Клиентская часть поддерживает только Windows, серверная – как Windows, так и целый ряд Unix-совместимых и других систем.

Еще одно CASE-средство, которое будет рассмотренно, – это Design/IDEF производства компании Meta Software. Здесь поддерживаются методологии, связанные с DFD и ER. То есть во многом очень похожи на предыдущие средства, но интересным является моделирование динамики бизнес-процессов на основе раскрашенных, или цветных, сетей Петри (Colored Petri Networks, CPN). Это достаточно интересная математическая модель, которая широко используется в моделировании – не только математическом, но и инженерном, в моделировании ПО. Какие этапы жизненного цикла поддерживаются? Это формализация требований, разработка и проверка проектных спецификаций, определение компонентов и связей, т. е. программных модулей и их интерфейсов, а также средство документирования. Кроме того, поддерживается имитационное моделирование бизнес-процессов корпорации. Какие функции поддерживаются? Это словари данных, т. е. фактически аналог диаграмм классов, если не подразумевать связи, по сути, речь идет о структуре данных, описании типов, которые входят в эту структуру, коллективная разработка, генерация отчетов, иерархическая декомпозиция, это производится на основе DFD. Кроме того, можно осуществлять генерацию кода на различных языках и дописывать свои языки. Подход, который позволяет дорабатывать, дописывать языки, создавая свой язык, – это подход, который близок к DSL (Domain Specific Languages), которые сейчас активно внедряются в Microsoft Visual Studio. Совместимость достаточно широка – это и MacOS, и целый ряд Unix-систем, и Windows. Существует интеграция с аналитическими пакетами, динамического анализа и анализа Cost Benefits (функционально-стоимостной анализ).

Следующим CASE-средством является комплекс из двух продуктов – Designer 2000 и Developer 2000 от Oracle. Сейчас есть Web Developer и целый ряд других средств от Oracle, которые продолжают эту линейку, но тем не менее это достаточно известное средство, связанное с автоматизацией проектирования корпоративных приложений, корпоративных систем. Oracle Designer предназначен как раз для проектирования корпоративных информационных систем, а Developer – в большей мере для реализации. При этом Oracle Developer ориентирован на корпоративную методологию Oracle CDM (Custom Development Methods). В его основе лежит каскадная модель, подход основан на структурном анализе и проектировании, т. е. достаточно жесткий дообъектный подход, возможно, не самый удачный. Поэтому эта методология существенно менее популярна, чем MSF. Плюсом MSF является наличие тренингов, книг. Рассматриваемая же технология локализована в корпорации Oracle и за ее пределы выходит достаточно редко.

Что включает в себя это средство? Репозиторий, т. е. хранилище метаинформации, поддержка коллективной, командной разработки и централизованное администрирование. Методология CDM поддерживает визуальный анализ бизнес-процессов предприятия и выявление источников их оптимизации, т. е. выявление узких мест, с одной стороны, и дублирование определенных или противоречивых бизнес-процессов, с другой. Детализация происходит на основе иерархических диаграмм. Здесь, конечно же, используется диаграмма потоков данных, которая как раз и является основой для моделирования бизнес-процессов, это классический структурный подход, дообъектный. С другой стороны, широко используются ER-диаграммы как средство проектирования структуры базы данных.

Поскольку речь идет о продукте корпорации Oracle, очевидно, что в основе лежит СУБД Oracle, и, кроме того, рядом находится сервер приложений Oracle Applications семейства прикладных систем корпоративного типа Oracle Applications. Естественно, поддерживается автоматическая генерация структуры данных на основе ER-диаграмм, по ним генерируются таблицы Oracle, поддерживаются диаграммы взаимодействия и ряд других диаграмм. При этом осуществляется поддержка распределения функционала, управляющего базой данных, на клиентскую и серверную часть. Клиентская часть содержит генерацию форм и отчетов (известный продукт Oracle Forms, Oracle Reports). Серверная часть содержит SQL-код с процедурным расширением на языке PL/SQL. Система ориентирована преимущественно на Windows и подразумевает возможность коррекции кода. Естественно, весь комплекс ориентирован на СУБД Oracle, что является существенным ограничением инструментальных средств автоматизированного проектирования ПО, Developer и Designer 2000. Oracle Developer Suite интегрируется с Oracle Designer и поддерживает кроссплатформенность – здесь операционные системы, как Windows, так и Unix, в частности Solaris и Linux, поддерживаются.

Конечно, речь идет о проектировании корпоративных приложений, т. е. поддерживается командная работа в распределенной среде и достаточно большое внимание уделяется интернет-технологиям. Oracle является одним из первых создателей ПО для проектирования корпоративных порталов, которое так и называется – Oracle Portal. В этой связи поддерживаются открытые стандарты на основе API-интерфейса, интерфейсов прикладных программных систем. Поддерживается средство быстрого прототипирования и быстрой реализации Oracle Application Development (OAD), процедурный язык запросов PL/SQL, о котором мы упоминали и который является специфическим для СУБД Oracle, в других СУБД он не используется. Используется стандарт UML для моделирования классов и бизнес-процессов. Также имеется сетевой репозиторий с возможностью контроля версий или релизов программных систем. На основе стандарта XML производится интеграция данных со сторонними CASE-средствами, и нестрого структурированные данные хранятся тоже в формате XML. Поскольку Oracle декларирует тот факт, что СУБД Oracle Enterprise Server является объектно-реляционной СУБД начиная с 8-й версии (сейчас уже существуют 11-я и 12-я версии), описание объектов и их характеристик является ключевым звеном этого продукта и здесь используется стандарт XML для этих описаний. И естественно, присутствует управление командной разработкой, в том числе централизация этого управления, администрирования, и достаточно широкая совместимость как с Unix-, так и с Windows-системами.

Еще одно достаточно известное CASE-средство – Vantage TeamBuilder использует методологии Йордена и структурных карт Константена. Того самого Лари Константена, который явился одним из пионеров CASE-средств и CASE-технологий. Поддерживается целый ряд диаграмм, но в основном опять-таки структурное проектирование, DFD, ER-диаграммы. При этом возможно двунаправленное построение диаграмм – как восходящее, так и нисходящее. Следует напомнить, что при проектировании систем на основе диаграмм потоков данных фактически производится структурная декомпозиция – разбиение относительно общих процессов на более детальные, конкретные составляющие. Здесь это возможно как снизу вверх, так и сверху вниз. Вообще при проектировании систем гибридная интеграция, гибридное проектирование как снизу вверх, так и сверху вниз является предпочтительным, поскольку позволяет достаточно хорошо протестировать проекты, обеспечить качество как модулей верхнего уровня, которые отвечают за основы бизнес-логики, так и модулей нижнего уровня, отвечающих за конкретные функциональные особенности программного кода программного продукта. Существует возможность проверки целостности моделей и диаграмм, которые используются, возможность кодогенерации, включая использование языков четвертого поколения, основанных фактически на скриптах, т. е. на некоторых небольших фрагментах кода, небольших программах, которые активизируются в зависимости от тех или иных пользовательских или системных событий и управляют системой. Естественно, проектирование ведется в визуальном интерфейсе. Поддерживается генерация схемы базы данных и SQL-запросов. То есть речь идет о проектировании как информационной системы, в том числе корпоративного типа, так и базы данных. Возможна настройка представления диаграмм в соответствии с различными стандартами, принятыми как организациями – законодателями этих стандартов, так и конкретными коллективами разработчиков. Возможно настраивать также интерфейсы, атрибуты и шаблоны кодогенерации. Платформа Microsoft поддерживается здесь в меньшей степени, поддерживаются Unix-системы и другие ОС, достаточно хорошая степень интеграции со сторонними CASE-средствами. В частности, поддерживается интеграция с языками программирования четвертого поколения, в том числе с языком C, а также с рядом СУБД – Informix, Oracle, Sybase. Видно, что платформа Microsoft здесь в меньшей степени присутствует как с точки зрения операционной системы, так и сточки зрения СУБД.

Еще одна связка CASE-средств – S-Designer и PowerBuilder производства компании Sybase, которая является также автором SQL-сервера, т. е. сервера баз данных. Эта связка нацелена на проектирование информационных систем и баз данных, в том числе корпоративного типа, клиент-серверных приложений. Основным назначением S-Designer является проектирование баз данных, и здесь используются ER-диаграммы, логические/физические модели данных и также ODBC (Object Data Base Connectivity) драйверы – средства взаимодействия с различными СУБД. Таким образом, интеграция с СУБД достаточно гибкая, большое количество поставщиков баз данных и основные производители здесь представлены: это Oracle, Informix, Sybase, Microsoft, причем как SQL Server, который предназначен для разработки корпоративных приложений с базами данных, так и настольная система Microsoft Access, и целый ряд CASE-средств. Обратим внимание, что используются CASE-средства производства как той же компании Sybase (PowerBuilder, предназначенное для реализации приложений), так и сторонних систем. Работа осуществляется под управлением операционной системы Windows. PowerBuilder работает в связке с S-Designer и также имеет язык четвертого поколения, который позволяет осуществлять написание управляющих процедур в терминах реакции на те или иные события пользователя или системы, и, естественно, существует визуальный интерфейс для реализации процедур на этом языке. Язык похож во многом на C++, это язык объектно-ориентированный.

Следующим CASE-средством, которое будет рассмотрено, является Silver Run. Оно поддерживает практически полный цикл программного обеспечения: это моделирование бизнес-процессов, архитектурное проектирование, детальное проектирование, реализация и сборка или интеграция модулей в полный программный продукт. Используется целый ряд методологий, достаточно ранних. Что интересно, могут использоваться сторонние методологии пользователей, это достаточно открытая система на основе экспертной системы с языковым интерфейсом, т. е. пользователи могут работать в привычных для них терминах той области, в которой они работают, системной аналитики, кадров, финансов, иных корпоративных ресурсов. При этом происходит автогенерация структуры реляционной СУБД. Поддерживается целый ряд систем управления базами данных – Oracle, Microsoft SQL Server, IBM DB2 и другие СУБД. В основе лежат диаграммы, которые нацелены на структурный подход (более ранний, чем объектно-ориентированный) к анализу и проектированию SIDT, т. е. ER-модель и диаграмма потоков данных, которые представляют собой средства описания и декомпозиции бизнес-процессов. Поддерживается целый ряд языков четвертого поколения, в том числе язык PowerBuilder и ряд других. Достаточно хорошая совместимость с большим количеством операционных систем программных платформ – как Windows, так и Unix-систем и MacOS.

Еще одно CASE-средство – это Visible Analyst от Visible Systems. Здесь используется коллективная разработка больших систем, и особенностью является Forward and Reverse Engineering, т. е. проектирование – как прямое, так и обратное. Интересно, что ряд CASE-средств позволяет восстановить модели данных на уровне диаграмм по коду или по схеме базы данных ER-модель. Примерно такого рода операции можно осуществить при помощи этого CASE-средства, которое поддерживает ER-диаграммы или IDEF1X, IDEF0, DFD и некоторые более старые нотации. В основном речь идет о структурном анализе, т. е. о статическом моделировании, в том числе с использованием структурных карт Константена. Поддерживается распределенное командное проектирование с общим сетевым репозиторием, применяются средства верификации – определения корректности переходов от одного этапа жизненного цикла к другому, можно осуществить трассировку требований к ПО и переход от этих требования (предположим, от сценариев использования к диаграммам). Поддерживается некоторое количество СУБД – Oracle и Informix (Microsoft SQL Server не поддерживается), а также достаточно большой спектр языков программирования четвертого поколения, включая PowerBuilder, о котором мы упоминали.

Еще одним достаточно мощным CASE-средством является ARIS производства IDS Scheer AG. Это очень большое и сложное CASE-средство, поддерживается более 80 типов диаграмм, достаточно сложная методология производства больших корпоративных систем, нацеленная на производство систем по учету планирования и управления корпоративными ресурсами (ERP-систем). Здесь можно осуществлять детальный анализ требований, поддерживается весь жизненный цикл – моделирование бизнес-процессов, функций и данных оргструктуры. Достаточно гибким является подход к детализации, написанию спецификаций. Используется целый ряд специфических аспектов, таких как функционально-стоимостной анализ, имитационное моделирование, поэтому это достаточно большое, тяжелое средство и для использования, и для обучения, и для производства больших мощных систем, одной из которых является SAP ERP. Конечно, используются и UML-диаграммы, и целый ряд специфических диаграмм, общее представление которых, если изобразить их графически, называется «домиком ARIS» и представляет собой пирамидальную структуру.

Еще одно мощное средство, которое будет рассмотрено, – это Microsoft Visual Studio.NET, которое предназначено для коллективной разработки больших систем распределенных приложений на основе компонентных интероперабельных приложений. При этом используется визуальный интерфейс. Какие основные функции можно обозначить при описании этого средства? Это построение быстрых прототипов, т. е. достаточно быстро можно осуществить визуальное проектирование, создать формы, элементы управления, командные кнопки, выпадающие меню и т. д., все это будет хорошо соответствовать современному интерфейсу Windows, оформить эти элементы управления соответствующими скриптами, скажем, на языке C#, короткими фрагментами кода, которые будут по тем или иным событиям наступать и выполняться, и таким образом осуществить быстрое прототипирование ПО. Кроме того, это разработка, тестирование, сопровождение крупных приложений корпоративного типа, прежде всего связанных с интернет-средой, потому что Visual Studio.NET основано на технологии веб-сервисов и использует ряд других технологий распределенной работы и обработки данных, включая remoting, технологии ASP.NET, Windows Forms, Web Forms и целый ряд других технологий Microsoft. Еще одна важная функция инструментальных средств – анализ и генерация структур информационных систем и баз данных. Под базой данных понимается преимущественно Microsoft SQL Server, управление бизнес-требованиями и т. д. Используется единая среда вычислений, внутри которой на основе общей виртуальной машины можно создавать гетерогенные проекты на различных языках программирования (поддерживается несколько десятков языков) и, более того, разрабатывать собственные языки программирования. При этом удается обеспечить достаточно высокий процент повторного использования компонентов, шаблонов архитектуры приложения корпоративного уровня, есть специальные библиотеки классов для корпоративных приложений (об этом речь пойдет позднее). Другое важное направление – средства создания требований к ПО, кодогенерации. В основе лежат протоколы или стандарты XML, SOA для сервисно-ориентированной архитектуры, абстрактная машина. NET, технология ADO (активных объектов данных) и целый ряд других технологий.

Еще одним важным стандартом, на который ориентируется Microsoft, является UML. Существенным недостатком (но на сегодня уже не столь значимым, поскольку Internet Explorer является достаточно распространенным браузером) является ориентация на платформу Microsoft, но основной недостаток по-прежнему остается в том, что это не только браузер, но и вся платформа, операционная система. К сожалению, интеграция с другими операционными системами и СУБД не слишком хороша, это является существенным ограничением.

В отличие от данного продукта средства, предлагаемые корпорацией IBM, линейка Rational, которая в свое время была приобретена у компании Rational, являются кроссплатформенными, т. е. поддерживают как Windows, так и Unix-диалекты, достаточно большое количество операционных систем. По сути, здесь также поддерживается весь жизненный цикл ПО, в том числе создание, анализ, коррекция, верификация архитектуры информационных систем. Все это происходит на основе открытых стандартов того же самого SOA, UML, SQL стандарта ANSI и ER-диаграмм или IDE-F1X и фактически поддерживается весь жизненный цикл ПО. Это и моделирование предметной области в терминах бизнес-процессов или инжиниринг, проектирование схемы БД, в том числе на основе визуальных технологий, разделение интерфейса и бизнес-логики, визуальный анализ и спецификация требований, поддержка различных языков программирования, в частности интеграция с C, C++, Java, Smalltalk, ADA (это язык, который поддерживает большие корпоративные системы для реального времени, язык, разработанный Пентагоном, используется во многом для военных систем) и целым рядом других языков. Поддерживается большое количество СУБД, прежде всего IBM DB2, Microsoft SQL Server, Oracle. Также существует большое количество шаблонов. Порядка 15 средств, которые отвечают за реализацию жизненного цикла ПО, используются в этом пакете: анализ и формализация требований – Requisite Pro, тестирование – Test Manager, контроль версий – Clear Case, формирование отчетов и целый ряд других процедур. Это семейство программных продуктов является интегрированным, и поддерживается сквозная унифицированная визуальная модель, в том числе для встроенных систем и мобильных устройств на основе открытой сервисно-ориентированной архитектуры SOA (Service Oriented Architecture). Преимущества таковы, что поддерживается кроссплатформенность, фактическая независимость от операционной системы и во многом от среды реализации, т. е. различные языки программирования, большой процент повторного использования, автоматическая генерация и оптимизация кода различных языков программирования. Система ориентирована на производство кроссплатформенных динамических интернет-приложений для различных устройств, как больших машин, так и мобильных устройств – смартфонов, коммуникаторов и т. д.

Обсудив основные CASE-средства (основные в том смысле, что они часто используются в нашей стране и на их основе реализован целый ряд больших и крупных корпоративных информационных систем), перейдем к классификации этих систем. Можно выделить три основные направления классификации – по масштабам применения, функциональному использованию (назначению) и видам моделирования, т. е. какого рода модели (стандарты) используются этими CASE-средствами. Естественно, все эти деления достаточно условные, это только один из вариантов возможных классификаций.

По масштабам применения CASE-средства можно разделить на локальные закрытые, средние открытые комплексные и крупные открытые комплексные.

Локальные закрытые – однопользовательские настольные системы с простыми нотациями для локальных информационных систем и небольших систем – до 100 одновременных пользователей. Это такие системы, как Design/IDEF, отечественное средство CASE-аналитик и ряд других.

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

Крупные открытые – комплексные системы, которые поддерживают комплексные графические нотации, встроенные средства прототипирования и быстрой разработки приложений (Rapid Application Development). Одним из примеров является S-Designer и PowerBuilder, т. е. речь идет о конвейерном производстве систем, о некоторых конвейерах, которые поддерживают достаточно большую долю жизненного цикла (итераций, связанных с ЖЦ программных систем). Большие системы для производства корпоративных приложений, крупные открытые комплексы поддерживают целый ряд графических нотаций, хорошо стыкуются с известными корпоративными методологиями и ориентированы на производство больших программных систем, т. е. имеют средства командной разработки, быстрого прототипирования и поддерживают весь жизненный цикл ПО. Это линейка Rational, которая была рассмотрена ранее, это конвейер Designer-Developer, который ориентирован преимущественно на Oracle, но тем не менее и на большие корпоративные СУБД и корпоративные приложения класса ERP, системы учета и планирования корпоративных ресурсов, ну и, конечно, Visual Studio.NET от Microsoft.

По функциональному назначению можно выделить следующие виды CASE-средств.

Комплексно-технологические конвейеры. О них мы уже упоминали, это Oracle Designer-Developer, Microsoft Visual Studio и линейка IBM Rational, которые представляют собой действительно большие комплексы программных средств и достаточно сложные программные средства, такие как Microsoft Visual Studio Team Suite, и предназначены для создания больших и сложных корпоративных систем с высокой степенью масштабируемости, со средствами прототипирования и поддержкой основных этапов жизненного цикла.

Проектный инструментарий для решения исследовательских задач. Рассматривалось средство, которое было связано с раскрашенными сетями Петри, есть специальные средства, такие как Protégé, основанные на использовании онтологических моделей, т. е. средства, которые предназначены преимущественно для исследовательских задач. Какие области следует здесь выделить? Это реинжиниринг бизнес-процессов (Business-Process Reengineering, BPR), когда в корпорации имеет смысл решить задачу оптимизации, перепланирования критических бизнес-процессов, расшивки узких мест и оптимизации затрат, скорости и качества обслуживания, что достаточно актуально в кризисный период.

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

По видам моделирования: моделирование бизнес-процессов, функциональное и событийно-информационное моделирование. Здесь речь идет в основном о методологиях, стандартах, которые используются, – объектно-ориентированный анализ и проектирование, структурный анализ и проектирование.

Моделирование бизнес-процессов. Бизнес-процессы формализуются IDEF0– и DFD-диаграм мами (диаграммы потоков данных) на основе методологий структурного анализа. Используются здесь такие CASE-средства, как BPwin и Design/IDEF. Важным недостатком является то, что статическая модель IDEF0 или DFD и подход на основе структурного анализа и проектирования не вполне отвечают динамическим, быстро изменяющимся требованиям внутри корпорации, которые связаны с бизнес-процессами. Здесь могут использоваться специфические модели на основе цветных, или раскрашенных, сетей Петри – это Design/CPN и Design/IDEF, которые блокируются друг с другом, используются совместно CASE-средства. Другой вариант использования специфических моделей для бизнес-процессов, в том числе тоже на основе CPN (раскрашенных сетей Петри).

Функциональное моделирование. Как правило, в России используются CASE-средства, поддерживающие те же нотации DFD (диаграмм потоков данных) и структурный анализ и проектирование, событийное моделирование расширяется управляющими потоками и процессами, т. е. расширенные диаграммы потоков данных, и, кроме того, используются такие диаграммы, как State Transition Diagram (диаграммы переходов состояния), диаграммы последовательностей, взаимодействий и другие UML-диаграммы, здесь речь идет уже о применении UML-стандарта.

Информационное моделирование. Моделирование структур данных или баз данных с использованием IDEF1X или методологии ER-диаграмм (ER-методологии).

CASE-средства Designer-Developer от Oracle как комплексный пакет и Visual Studio.NET поддерживают моделирование и бизнес-процессов, и функций данных, и событий. И линейка Rational является всеобъемлющей с этой точки зрения, поддерживаются все четыре вида моделей. Другие средства содержат меньшее количество моделей, т. е. специализируются на каких-то отдельных видах моделирования.

По сферам применения можно отметить те же CASE-средства – Rational, Microsoft Visual Studio, Oracle Designer-Developer, которые поддерживают весь жизненный цикл программных продуктов. Другие поддерживают выборочно – либо анализ и проектирование, либо реализацию и тестирование, либо проектирование баз данных. Есть еще целый ряд специфических средств, которые нацелены на анализ бизнес-процесса с выявлением узких мест или выявления оценки рисков, бизнес-планирования и оценки трудоемкости.

По моделям данных или методологиям, которые поддерживаются, здесь можно выделить также несколько основных направлений. Самыми распространенными методологиями являются IDEF1X (ER-модель) и различные UML-диаграммы, они поддерживаются достаточно большим количеством средств. Можно заметить, что существует большое количество методологий, которые на самом деле практически никакие CASE-средства не поддерживают. Самыми хорошими примерами поддержки большого количества методологий являются линейка IBM Rational, где поддерживается весь спектр UML-диаграмм и ряд других, а также Microsoft Visual Studio.NET, который тоже поддерживает широкий спектр диаграмм стандарта UML.

Завершая обсуждение CASE-средств, средств автоматизации проектирования систем, в том числе корпоративных приложений, следует сделать некоторые выводы. Итак, современные CASE-средства представляют собой комплексные конвейеры, если говорить о больших корпоративных приложениях, которые позволяют вести быстрое прототипирование и разработку приложений, т. е. существует объединение или интеграция с Oracle Application Development средствами: Oracle Designer-Developer, Microsoft Visual Studio, линейка Rational и отчасти Sybase, которая представлена S-Designer – средством проектирования и PowerBuilder – средством быстрой реализации и прототипирования. Основной стандарт визуального проектирования сегодня – это UML, достаточно большое количество диаграмм, которые позволяют моделировать и динамические, и статические процессы, происходящие при проектировании ПО. При выборе CASE-средств для проектирования и реализации корпоративных приложений следует отдавать приоритет аппаратно и, желательно, программно независимым и с высокой совместимостью, преимущественно Java, интероперабельным (т. е. системам, которые позволяют гибко конфигурировать корпоративные приложения на основе большого количества интероперабельных компонентов, это. NET и Java-технологии), распределенным (в частности, сегодня это интернет-технологии, уже не локальные сети) и компонентно-ориентированным, портируемым, поддерживающим как большое количество операционных систем, так и различные устройства доступа – от небольших смартфонов и коммуникаторов до полномасштабных офисных машин.

 

Глава 8

Программная платформа Microsoft.NET

В данной главе будет более подробно рассмотрен подход Microsoft к созданию корпоративных систем. Прежде всего речь пойдет о Visual Studio.NET и вообще о. NET подходе. Не стоит ограничивать. NET чисто технологическим аспектом, так как. NET – это платформа в достаточно широком и глубоком смысле этого слова, т. е. это идеология проектирования программного обеспечения, которая имеет в основе такие принципы, как сервисная ориентированность, интернет-распределенность, командная работа, компонентная ориентированность (интероперабельность) и, что еще интереснее, языковая интероперабельность – создание гетерогенных проектов с компонентами, написанными на разных языках и разными людьми в разных точках земного шара. По сути, речь идет об идеологии производства систем корпоративного типа, при этом платформа является достаточно общей и имеет единую среду в форме виртуальной машины, которая предназначена для создания и поддержки таких систем. На основе математических моделей, разработанных Юрием Гуревичем, моделей абстрактных машин с состояниями, построена виртуальная машина, на основе которой происходит создание приложений Microsoft Visual Studio.NET, являющихся уже технологической надстройкой, т. е. NET – это во многом еще и идеология и модель. Рассмотрим ее более подробно.

Четыре основные аспекта

Хотелось бы выделить четыре аспекта в подходе. NET как платформы для разработки корпоративных приложений:

1) концепция, т. е. общий подход;

2) вычислительная модель – в ее основе лежит достаточно формальная математическая модель. Это некая более реальная реалистичная формализация, но тем не менее тоже фактически модель вычисления на компьютере достаточно общего вида. Так же, как в Java-подходе, имеется виртуальная Java-машина, которая работает на любой платформе, так и здесь есть виртуальная машина высокого уровня, в терминах которой компилируется код на различных языках программирования, но эта платформа ограничена множеством ОС Windows;

3) технологическая платформа;

4) инструментальная средства Visual Studio.NET.

Достаточно важным является подход к реализации системы управления этой виртуальной машиной, которая называется Common Language Runtime (CLR) и подразумевает выполнение компонентов программы, написанных на различных языках. Платформа включает среду реализации, среду вычисления с точки зрения абстрактных (виртуальных) машин и. NET Framework общей надстройки, которая представляет собой семейство базовых системных классов. При этом система типов также является достаточно универсальной, т. е. общей common type system (CTS). По сути, с одной стороны, это система типов, которая принята в C#, а с другой – в эту систему типов подгружается на самом деле система типов любого языка программирования, который написан для этой среды.

Одним из достаточно ранних курсов, реализованных в Санкт-Петербургском государственном университете для. NET, является курс создания компилятора для. NET. Он был написан для студентов второго курса, которые за один семестр могли создать компилятор некоего подмножества языка C# для. NET. То есть речь идет о том, что не только на тех языках, которые реализованы для. NET, но и вообще на этой платформе возможно реализовать произвольный язык, если правильно погрузить его в термины виртуальной машины, и, конечно, типы языка, каким бы он ни был, будут оттранслированы в семейство CTS.

Еще одним важным принципом реализации концепции. NET является предоставление ПО как сервиса. На самом деле эта идеология присуща не только Microsoft, но и Java или подходу IBM SOA, но в рамках подхода. NET есть множественные реализации, которые связаны с различным образом организованными сервисами: это веб-сервисы, технология Remoting, более поздняя технология WCF и др., скажем ASP, технологии, связанные с веб-формами, и целый ряд других технологий, которые предназначены для реализации ПО как сервиса и распространении SOA по сети Интернет.

Первое, что приходит на ум при словах «распространение по Интернету», – это вирусы. В этой связи нужно сказать, что важным акцентом после известных событий 11 сентября для Microsoft является безопасность. Платформа. NET во многом ориентирована на реализацию этого принципа безопасности, и компоненты, которые создаются в рамках платформы. NET, учитывают это.

Одним из направлений реализации и принципом подхода SDL (Secure Development Lifecycle) является Seсure by Design, т. е. собственно проектирование ПО ведется таким образом, что оно является изначально безопасным. Во многом на это нацелена идеология. NET и ее компонентная ориентированность механизма сборок assembler, т. е. самодостаточных компонентов для разворачивания ПО, который является основой идеологии. NET и защищен такими средствами, как цифровая подпись, имя автора и версии сборки и целый ряд других аспектов, позволяющих обеспечивать высокую безопасность создаваемого ПО как покомпонентно, так и в целом для корпоративных приложений, строящихся на основе интероперабельности – постоянно взаимодействующих и меняющихся объектов.

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

Прежде всего речь пойдет о технологии Windows Forms и Web Forms, достаточно важных технологиях создания, в том числе и корпоративных приложений, которые обеспечивают стандартизацию пользовательских интерфейсов и взаимодействие в среде Интернет на основе этих интерфейсов. Конечно, мы посмотрим на. NET. Отчасти в сравнении с Java весь San Microsystems тоже имеет достаточно древний и апробированный подход, который называется EJB, по сути, компонентное проектирование тоже на основе виртуальной машины, и даже в различных ОС, не только Windows. Но с языковой точки зрения интероперабельность – подход немного беднее. Мы обсудим некоторые параллели, преимущества и недостатки. NET, которые выявлены и существуют, в том числе и в аспекте проектирования корпоративных приложений.

Что такое Microsoft.NET

Не совсем верно рассматривать. NET как исключительно технологическое средство, платформу. По сути, это достаточно комплексная идеология проектирования ПО, в том числе и корпоративного типа.

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

1) идеология проектирования и реализации программного обеспечения;

2) модель эффективной поддержки жизненного цикла прикладных систем;

3) унифицированная, интегрированная технологическая платформа;

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

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

Кроме того, это модель, в том числе и математическая, достаточно эффективной поддержки ЖЦ программных систем – от концептуальной постановки задачи проектирования до реализации, внедрения, разворачивания по сети Интернет одним кликом приложения и сопровождения. Это технология, обеспечивающая унифицированное проектирование с точки зрения использования открытых протоколов и средств взаимодействия SOA, HTTP, XML, UDDI, WSDL, других стандартов и, наконец, это современный, удобный в использовании и безопасный инструментарий командной разработки больших систем, который поддерживает все этапы ЖЦ – создания, разворачивания, размещения и сопровождения поддержки ПО.

Итак, рассмотрим более подробно основные аспекты. NET.

В чем состоит видение Microsoft этой идеологии?

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

Идеология и основные принципы. NET

NET как идеология (vision) – это:

1) легкость развертывания приложений в глобальной среде Интернет;

2) экономичная разработка программного обеспечения;

3) бесшовная, гибкая интеграция программных продуктов и аппаратных ресурсов;

4) предоставление программного обеспечения как сервиса;

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

1. Важным аспектом является легкость разворачивания приложения в глобальной среде Интернет. На сегодня в Microsoft реализован инструментарий ClickOnce, который позволяет осуществить разворачивание программных системы одним щелчком мыши.

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

3. Также важным идеологическим аспектом. NET является интеграция программных продуктов и аппаратных ресурсов, которую можно охарактеризовать как бесшовную, гибкую. Вообще, если рассматривать производство ПО как задачу, то можно заметить, что изначально это было искусство, т. е. фактически ручное изготовление штучного товара. Позже наступил период, когда кустарей-одиночек сменили программные проектные команды, создающие ПО с использованием более серьезного инструментария. В настоящее время существующие сборочные конвейеры, такие как Visual Studio.NET и др., позволяют во многом стандартизировать режим и на основе стандартных компонентов вести сборку очень сложных систем, включающих сотни тысяч индивидуальных программных моделей, достаточно сложно взаимодействующих друг с другом. Сегодня все, что строится в мире ПО, во многом связано с интеграцией, т. е. в идеале новое ПО не производится, принципиально новая функциональность даже при создании нового продукта составляет от силы 10–15 %, все остальное – это уже ранее использованное решение, которое просто повторно применяется, и интеграция новых функциональных моделей компонентов с уже реализованными частями, фрагментами программ продуктов.

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

5. Еще два важных аспекта идеологии. NET – новый уровень безопасности и удобства использования.

По поводу удобства: Microsoft удалось завоевать достаточно большое количество пользователей во многом потому, что ОС, которые она предоставляет, являются достаточно удобными с точки зрения удобства пользования (usability) – это хорошие средства, позволяющие достаточно быстро решать сложные или типовые задачи одним щелчком или с помощью мастеров для решения типовых задач. В Microsoft одна из самых сильных команд специалистов по usability. И многие пользователи уже привыкли к интерфейсу Microsoft.

Безопасность – это стратегический приоритет корпорации, и, конечно, NET как идеология не может не отмечать важность этого приоритета и широко его применять.

NET как вычислительная модель

1. Компонентный подход как развитие объектно-ориентированной модели.

2. Универсальная система типизации: «всякая сущность есть объект»; унификация данных и метаданных.

3. Строго иерархическая организация кода, пространств имен и классов.

4. Универсальный интерфейс. NET Framework (включая поддержку различных подходов к программированию).

5. Высокая вариативность экземпляров реализации (в частности, на основе веб-сервисов).

Рассмотрим особенности вычислительной модели работы. NET, как подхода к созданию, в том числе больших корпоративных систем.

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

Еще одним важным аспектом вычислительной модели является универсальная или обобщенная система типизации Common Type System. Здесь реализуется достаточно инновационный подход Microsoft, который сводится к декларации, что каждая сущность есть объект. То есть речь идет о чисто объектно-ориентированном подходе и попытке реализовать эту идею, а также об унификации данных и метаданных. Во всяком случае появляется достаточно хорошее средство использования метаданных. Репозиторий метаданных реализован достаточно эффективно, в частности, следует отметить средство Reflection, которое позволяет восстановить код по метаданным класса. Сборка или представление компонента включают в себя все метаданные, которые необходимы для разворачивания этого компонента как части программного продукта.

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

Обобщенный интерфейс. NET Framework базовых, системных классов является надстройкой над OC Windows и позволяет, кроме всего прочего, осуществить интеграцию различных подходов к программированию, таких как ООП, функциональный, логический и др.

Для. NET реализован целый ряд языков программирования, которые транслируются во внутреннюю среду абстрактной или виртуальной машины. NET. Это прежде всего родной язык. NET Си#; это F#, который, по сути, является развитием языка SML, т. е., с одной стороны, он во многом является функциональным языком, но с другой – реализует и некоторые аспекты ООП, поскольку функция является объектом модели и язык моделирует объектный подход; ряд языков Cobol, Fortran, которые использовались в большом количестве унаследованных проектов, и. NET, позволяет портировать проекты унаследованных приложений, в том числе корпоративных, которых очень много.

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

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

Перечислим основные особенности технологической платформы. NET.

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

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

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

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

Также важно отметить, что. NET во многом соответствует современным технологическим стандартам. Язык C# сейчас фактически стандартизован европейской ассоциацией стандартов, и во многом используются стандартные протоколы обмена и стандарты таких данных, как HTTP, XML, UML, SOAP, протоколы взаимодействия.

Как инструментальное средство, NET является достаточно универсальным, поскольку поддерживает многоязыковую среду Common Language Runtime (CLR), которая, как упоминалось ранее, поддерживает разработку компонентов на различных языках. При этом важной особенностью является возможность построения фрагментов проекта на наиболее подходящих для этого языках.

При реализации бизнес-логики и интерфейса их, конечно, необходимо разделять. Бизнес-логику лучше реализовать на Прологе как набор условий и логических альтернатив, другой подход – сделать это на функциональном языке, таком как F#, а интерфейс можно достаточно легко реализовать на C#, который включает все механизмы взаимодействия с Windows и библиотеками. NET Framework наиболее быстрым и прозрачным способом, т. е. различные компоненты достаточно быстро реализуются.

И в этом смысле у. NET практически нет альтернатив, такого большого спектра языков и разнообразия подходов больше не найти. Причем сервисные средства. NET, такие как отладка, анализ кода и т. д., поддерживаются для всех без исключения языков, реализованных в рамках Visual Studio. То есть на каком бы языке ни велась разработка, программист получает все сервисные возможности, интегрированные в среду разработки. Как было сказано ранее, можно разрабатывать собственные языки программирования, это достаточно интересно и актуально. Одним из современных направлений развития программной инженерии является создание программного обеспечения на основе DSL – предметно-ориентированных языков, т. е. языков для приложений того или иного рода, той или иной предметной области.

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

Посмотрим на архитектурную схему: сбоку, интегрируя все доступные сервисы (рис. 8.1), начиная с уровня естественного языка, с уровня исходного кода на языке программирования, находится Visual Studio.NET – как средство разработки, оно интегрирует все особенности платформы. Основой для программирования являются различные языки программирования. Работа происходит в исходном тексте, в стандартном редакторе Visual Studio.NET, при этом на любом языке. Типы этого языка, какими бы своеобразными они ни были, транслируются автоматически при трансляции кода в стандартные системные типы. NET, т. е. имеют место трансляции в типы Common Language Specification (CLS). Далее используются на уровне пользовательского интерфейса различные веб-формы, веб-сервисы, скажем, средства SP.NET Windows Forms, технологии, связанные с. NET Remoting, и т. д. На уровне взаимодействия с данными используются технологии ADO.NET и т. д., слабоструктурированные данные могут преобразовываться по средствам форматов в стандарты XML. Естественно, все взаимодействие со средой выполнения строится на основе базовых классов. NET Framework, которые едины для любого языка программирования, строятся на основе компонентов, берущих свое начало в базовых классах. И все трансляции осуществляются в термины ассемблера высокого уровня – это ассемблер Common Language Runtime (CLR), т. е. виртуальной машины. NET (рис. 8.2).

Рис. 8.1. Архитектурная схема. NET Framework и Visual Studio.NET

Рис. 8.2. Схема компиляции в Common Language Runtime

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

Естественно, трансляция осуществляется в терминал языка MSIL – это ассемблер высокого уровня, который в 3–5 раз плотнее, чем обычный ассемблер, если рассматривать, например, процессор Intel 8086 или ассемблер Z80.

Рис. 8.3. Схема выполнения CLR

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

Основные возможности, которые предоставляет среда CLR:

• поддержка стандартных типов и правил создания новых типов;

• межъязыковая интеграция:

– включение в код на одном ЯП классов на другом ЯП;

– обработка исключений из программы на одном ЯП программой на другом ЯП;

– и т. д.

• единый набор библиотек классов для всех поддерживаемых ЯП;

• самоописываемые компоненты – не требуют дополнительных файлов (IDL, TLB, Proxy/Stub и т. п.); компонент является самодостаточным, имеет всю необходимую информацию для встраивания его в программный продукт и разворачивания;

• поддержка версий компонентов и сборок кода;

• сервисы безопасности (запрет неавторизованного доступа к ресурсам для пользователей – Role-Based Security, доступ на основе безопасности кода – Code-Based Security и автор кода, версия сборки и др.).

Рассмотрим работу универсальной системы типизации (рис. 8.4).

В основе лежит понятие базисного типа, который в. NET называется System.Object (это очень похоже на Java). Он делится на две категории – типы-ссылки и типы-значения, при этом типы-значения и типы-ссылки различным образом хранятся и используются. Типы-значения при создании экземпляра класса каждый раз вводятся в память и т. д.

Типы-ссылки – это классы, интерфейсы, массивы, делегаты и т. д.

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

Рис. 8.4. Универсальная система типизации (UTS)

В основе архитектуры. NET лежит понятие «сборка».

Сборка кода (assembly) – группа ресурсов, типов и метаданные, описывающие эти ресурсы и типы, необходимые для функционирования компонентов. Сборка реализуется как единое целое. Сборка – это самодостаточная единица кода.

К особенностям сборок кода прежде всего относятся следующие:

• сборка распространяется и реализуется как единое целое;

• метаданные сборки содержат информацию о зависимостях между ресурсами, версиях и т. п.;

• сборка характеризуется номером версии (последняя, специфичная и т. п.).

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

• принцип. NET – «ПО как сервис»;

• следующий уровень архитектуры – уровень сервисов (рис. 8.5);

• сервисы доступны на уровне классов любого ЯП для. NET.

На нижнем уровне архитектуры существуют системные сервисы Microsoft Windows. На более высоких уровнях – различные надстройки, сервисы для работы с данными, сервисы интерфейсные и т. д. Сервисы. NET находятся на более высоком уровне, чем сервисы для Windows.

Рис. 8.5. Архитектура. NET – уровень сервисов

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

Абстрактная машина. NET. CLR располагается над уровнем сервисов ОС (Windows CE, Windows ME, Windows 2000, Windows.NET).

Системные сервисы располагаются над CLR (доступ – через библиотеки классов): доступ к функциям ОС, управление данными, отладка, другие сервисы и т. п.; еще выше – компоненты и сервисы для разработки веб-узлов, веб-сервисов, пользовательских интерфейсов (GUI).

Веб-приложения – архитектура клиент – сервер с доступом пользователей к данным через веб-браузер (технология ASP.NET).

Распределенные приложения на основе иных механизмов удаленного взаимодействия компонентов XML Web Services – на основе открытых стандартов, NET Remoting – на основе внутренних протоколов Microsoft и целый ряд других подходов.

По сути, NET представляет собой виды базовых классов для сервисов:

• доступ к сервисам ОС (Windows CE, ME, 2000, NET);

• доступ к графическим функциям (двумерная графика, обработка изображений, шрифты, в том числе технология ClearType, интеграция с GDI и DirectX);

• сетевые функции;

• управление потоками;

• глобализация;

• криптография;

• доступ к данным (библиотека классов ADO+ и OLE DB-драйверы);

• классы для средств разработки (отладка, трассировка, управление ресурсами, компиляция, установка ПО, протоколирование событий и т. д.);

• другие классы (в том числе поддержка протокола SOAP).

Назначение Windows Forms – обеспечение разработки традиционных Windows-приложений на основе сервисов Microsoft.NET и соответствующих библиотек классов.

Особенности разработки – унификация доступа:

• к библиотекам классов;

• механизмам распространения сервисов;

• механизмам поддержки версий;

• сервисам безопасности.

Вывод: создание Windows-приложений в архитектуре Microsoft.NET дает разработчикам существенные преимущества, поскольку огромное количество классов уже реализовано, и остается заполнить пробелы только с реализацией бизнес-логики по сравнению с традиционным API-ориентированным подходом.

Назначение Web Forms — основа веб-сервисов и веб-приложений в архитектуре Microsoft.NET.

Особенность – программная модель основана на ASP+ – новом поколении активных серверных страниц (эволюция технологии ASP – более 1 млн разработчиков).

Идея веб-форм (из Visual Basic 6): отделение логики веб-приложения от интерфейса (за счет объединения в рамках формы ASP– и HTML-кода).

Преимущества:

• более строгая структурированность приложений;

• широкий спектр (серверных) интерфейсных элементов;

• простая и мощная объектная модель;

• легкость разработки (и масштабирования) веб-приложений.

Основное средство для разработки приложений и сервисов в архитектуре. NET – Microsoft Visual Studio.NET (современная версия Microsoft Visual Studio).

Вот какого рода веб-сервисы можно создавать в. NET, так выглядит общая архитектура (рис. 8.6).

Рис. 8.6. Веб-сервисы в. NET

Веб-сервисы в. NET:

1) программируемые компоненты приложений, доступные посредством стандартных интернет-протоколов;

2) центральная часть архитектуры. NET;

3) распределяют функциональность по глобальной сети;

4) строятся на существующих и развивающихся стандартах: HTTP, XML, SOAP, UDDI, WSDL.

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

Поддерживаемые форматы: HTTP, XML, SOAP, UDDI, WSDL и др.

Компонентное программирование в. NET. Компоненты – это:

• независимые, повторно используемые и тиражируемые модули, из которых строятся приложения;

• в целом более крупные, чем объект (объекты – конструкции уровня ЯП);

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

• независимы от языка реализации.

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

Компонентная объектная модель (COM):

• основной стандарт Microsoft для компонентов;

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

• основа для ActiveX, OLE и многих других технологий взаимодействия;

• поддерживается в Visual Basic, C++, NET и др.

Модель Java Beans:

• основной стандарт Sun Microsystems для компонентов;

• зависима от языка реализации.

Сравнение компонентно– и объектно-ориентированного программирования.

Основные понятия объектно-ориентированного программирования:

• класс (class);

• интерфейс (interface).

Основные понятия компонентно-ориентированного программирования:

• свойство (property);

• событие (event);

• сборка (assembly).

Говоря об основных возможностях. NET, следует отметить, что кроме плюсов существуют и значительные недостатки.

Наиболее существенные недостатки. NET:

1) высокие требования к аппаратному обеспечению (минимум 256M RAM, 10G HDD для работы с Microsoft Visual Studio.NET);

2) сложности работы с некоммерческими релизами программного обеспечения (некоторая неустойчивость, отсутствие полномасштабной документации); сервис – это не всегда надежно и предсказуемо. Не всегда имеется документация. Некоторые языки не до конца стандартизованы, а некоторые не до конца реализованы как продукты;

3) поддержка ряда теоретически интересных и практически полезных языков программирвоания не в полном объеме (SML для Visual Studio.NET – в процессе реализации);

4) инструментарий. NET и компиляторы для языков программирования не ратифицированы по международным стандартам.

Платформа. NET – выводы.

1. Стратегическая идеология – это и технологическая платформа, и подход, который определяет стратегию Microsoft на ближайшее десятилетие.

2. Несомненное качественное превосходство над аналогами (Borland Delphi, Microsoft Visual Studio и др.) за счет:

• интероперабельности и межъязыкового взаимодействия;

• многоуровневой безопасности, SDL, безопасности на уровне компонентов;

• интеграции с веб-сервисами;

• облегчения разворачивания и использования.

3. Завершенность решения для широкого коммерческого использования в силу концептуальной новизны и грандиозности проекта.

4. NET – развитие платформы Windows, которое позволяет осуществлять компонентное проектирование.

5. NET – фундамент для создания корпоративных приложений нового поколения.

6. Основа. NET – принцип компонентной интеграция приложений на уровне сервисов, взаимодействующих посредством языка XML и протокола SOAP.

7. Стратегическая цель. NET – создание программной инфраструктуры для разработки и функционирования распределенных приложений на базе интернет-стандартов.

 

Глава 9

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

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

Когда говорят о корпорации, речь идет о территориально распределенной структуре, которая решает общие бизнес-задачи. Компании этой структуры отстоят далеко (территориально), но тем не менее необходимо обеспечить функционирование приложений корпоративных систем. Для этого используются разные технологии, в частности Remoting, также Windows Communication Foundation, технологии, связанные с веб-сервисами, которые реализуют решение как сервис, последовательно предлагаемые и реализуемые Microsoft в подходе. NET.

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

Прежде всего следует обсудить технологии построения интерфейсов на основе специализированных библиотек ввода данных. Задача ввода данных является нетривиальной, поскольку сотрудники корпорации должны интуитивно достаточно хорошо представлять себе, каким образом происходит ввод данных, и осуществлять его без коррекций, противоречий и дублирования. Интерфейсы должны быть эргономичны. В Microsoft сейчас работает, пожалуй, лучшая команда по usability. Большое количество пользователей во всем мире общается с ОС семейства Windows, офисными приложениями семейства Office, и эти интерфейсы им близки и естественны.

Рассматривая технологии Microsoft для ввода данных, представления данных и отчетов, следует сосредоточиться на технологии Windows Forms, которая служит не только для ввода данных, но и для построения отчетов. Одной из целей корпоративных систем является подготовка консолидированной отчетности, которая дает руководству возможность эффективно управлять корпорацией на основе динамики людских и финансовых ресурсов, основных средств, специализированных ресурсов (нефть, газ) и т. д. Здесь очень важны интерфейсы, их элементы, способы построения – все то, что дает возможность в интуитивно-явном режиме получать, интегрировать, консолидировать информацию и производить те самые формы вывода (отчеты) из интегрированных и гетерогенных систем, которые и учитывают различные корпоративные ресурсы. Информация об этих ресурсах в ряде случаев представляет собой не только хорошо структурированные данные, но и аудио-, видео-, отсканированные документы. Да и в случае структурированных документов они могут быть представлены в виде других приложений, и нам нужно объединять информацию из интернет-браузера (как тонкого клиента), из офисных приложений Word, Excel и строить достаточно сложные отчетные формы. Некоторые из них будут рассмотрены в данной главе.

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

Прежде всего рассмотрению подлежат основные понятия, связанные с технологией Windows Forms. Это определение, что такое формы как программные объекты, каким образом осуществляется взаимодействие с ними, технология умных клиентов Smart Clients и др. Следует отметить, что Windows Forms дает возможность взаимодействовать с клиентами в интерактивном режиме, что предполагает свободу и высокую степень вовлеченности пользователя в систему и взаимодействие с элементами интерфейса, знакомыми нам по офисным приложениям, такими как командные кнопки, контекстное меню и др.

Речь идет о том, что в одном из пространств имен, надстроенном на. NET Framework, над базовыми классами. NET существует серьезная и большая по объему коллекция классов, которые представляют собой элементы интерактивных элементов Windows Forms, некоторые из них были перечислены выше. Рассмотрим более подробно, как выглядит интерфейс CASE-средства Visual Studio и как осуществляется визуальное проектирование интерфейсов с использованием этого средства. Далее будет описано понятие «событие» в среде Windows применительно к корпоративным приложениями, обсудим, каким образом осуществляется обработка событий, т. е. создание программного кода на языке C# на платформе. NET, которая осуществляет реакцию на действия пользователя в направлении элементов управления, т. е. тех элементов, которые составляют элементы формы и отчетные формы, – библиотеку классов Windows Forms. Рассмотрим классификацию элементов управления Windows Forms и познакомимся с категориями, включая выпадающие списки, элементы, связанные с веб-интерфейсом, построением таблиц для отчетов баз данных и сложных отчетных форм, включающих гетерогенную информацию, например таблицы Excel. Пользователь имеет возможность не только использовать наперед определенные классы, библиотеки Windows Forms, но и создавать, в том числе на их основе с использованием концепции наследования в среде Visual Studio, собственные элементы управления. Зачем это необходимо пользователю? Заметим, что в Windows Forms существует достаточно большое количество предопределенных классов, с помощью которых можно создавать интерфейсы, и код событий уже предопределен. Но если существует необходимость создавать специализированные системы с расширенными возможностями, у пользователя также есть выбор и свобода это сделать. Также рассмотрим специализированный инструмент Windows Forms Designer, являющийся частью среды разработки Visual Studio.NET. Познакомимся с его возможностями и посмотрим, насколько удобно им пользоваться для создания Windows-приложений. Подводя итоги, мы рассмотрим важные аспекты, которые связаны с особенностями и преимуществами для таких сфер, как отображение данных и манипулирование данными, включая взаимодействия с СУБД SQL Server.

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

Итак, что такое Windows Forms? Это технология Microsoft, являющаяся надстройкой над. NET Framework – базовым семейством классов. NET и, по сути, это набор объектно-ориентированных библиотек – семейство классов, которые облегчают дизайн приложений и их интерфейсов. В первую очередь это ввод данных, вывод отчетов, использование файловой системы. То есть реализация интерактивных пользовательских интерфейсов. Каковы основные возможности приложений Windows Forms? Речь идет о создании компонентов на основе базовых классов, реализованных в этой библиотеке, т. е. о надстройках в приложении, о программной надстройке над. NET Framework. Какие возможности имеют эти приложения? Технология Windows Forms тесно интегрирована с Microsoft.NET. Более того, используется инструмент Form Designer, который позволяет нам быстро осуществлять построение программных интерфейсов. Прежде всего, пользователи получают возможность вывода данных и построения отчетов, обмена информацией с удаленными компьютерами по сети через Интернет или посредством сетевого соединения. При этом применяется технология Smart Client, строятся специальные приложения, использующие технологию обмена по сети этим специальным способом, не имея информации о пользователе, который запрашивает данные. Подробнее эта технология будет рассмотрена позже.

Итак, какие базовые элементы включает технология Windows Forms? Другими словами, какие интерфейсные элементы содержатся в этой библиотеке классов? Отметим важные особенности – все эти элементы являются интерактивными, т. е. дают возможность пользователю взаимодействовать с элементами управления, входящими в состав форм.

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

Еще одним важным элементом Windows Forms является элемент управления, или Control. По сути, это некий атом функциональности пользовательского интерфейса. Скажем, элементарная командная кнопка, или переключатель, или флажок, или строка ввода данных, которая предназначена для ввода или отображения данных, является достаточно примитивным элементом библиотеки Windows Forms и надстраивается над. NET Framework. Windows Forms – это некий класс, который представляет собой с точки зрения программирования код на языке C# и во многом для удобства бизнес-пользователей строится визуально, поскольку речь идет о достаточно сложных манипуляциях графическими объектами, достаточно сложным и ресурсоемким по времени занятием является ручная настройка формы. Если мы будем выверять форму и ее размеры вплоть до пикселя, процесс проектирования займет огромное время (если вводить линейные размеры вручную, код каждого управления и т. д.). Конечно же, визуальное создание приложений, особенно с таким приятным и удобным интерфейсом, который предоставляет Visual Studio.Net, является предпочтительным. Таким образом, создание элемента Windows Forms происходит так: сначала рисуется форма – прямоугольный объект, после этого на форму (как бы поверх) набрасываются, добавляются с помощью drag&drop (как фишки на игровое поле) те или иные элементы управления. Они упорядочиваются, при этом все это тоже происходит визуально. И все необходимые атрибуты для управления формой производятся автоматизированно в средстве Visual Studio.Net. Кроме того, определены базовые сценарии действий для основных событий, которые может инициировать пользователь, такие как щелчок мыши, двойной щелчок, нажатие клавиши, drag&drop, горячие клавиши и др.

Теперь рассмотрим, как выглядит визуальный интерфейс в Visual Studio.Net в Windows Forms. Скриншот Visual Studio при создании формы представлен на рис. 9.1.

Рис. 9.1. Интерфейс Visual Studio.NET

Итак, сначала создали элементарную форму Form1.cs, т. е. код, который описывает все ее детали – линейные размеры, имя, ряд других аспектов. В частности, можно заметить, что на ней расположена командная кнопка button1. Все это задается автоматически при перемещении кнопки из репозитория основных элементов формы, доступных в Visual Studio. Как только создали форму, становятся доступными и стандартные кнопки, к которым мы привыкли в Windows, – минимизация формы, разворачивания на весь экран, закрытия. И, естественно, все коды, связанные с событиями, доступны автоматически, и этот код уже существует.

В окне Solution Explorer мы видим, что нами создан код Form1.cs – это код на C#. А в правом окне мы видим все метаданные. У этой формы есть файл designer, файл ресурсов – res, где описаны все метаданные, и есть окно свойств, где описаны основные параметры этой формы. В частности, видно, что размер линейный в самом нижней строчке скриншота, является 300 на 300 точек. Кроме того, программный код создан на C# и описывает все действия, которые будут производиться с этой формой. Рассмотрим, каким образом происходит управление событиями, связанными с формами, каким образом пользователь может осуществлять контакт с формой. Речь идет об обработке событий. При взаимодействии пользователя с формой, при визуальном ее изменении: щелчок на «свернуть», drag&drop, щелчок левой кнопкой мыши по кнопке Button1, и целым рядом других действий пользователя автоматически генерируется событие – Event. Приложение реагирует на событие с помощью кода. Существует некий код на C#, связанный с событиями. Он автоматически активизируется при обработке события.

В окне «Свойства» (Properties) на рис. 9.1 мы можем увидеть список событий, которые связаны с этой кнопкой. Интересно, что справа от имени кнопки button1 мы видим, что она расположена в пространстве имен System.Windows.Forms.Form1, т. е. в том классе, который описывает форму, и кнопка является ее атрибутом. Далее следует список событий. Например, событие click – однократный щелчок по Button1. Если мы откроем свойство, связанное с этим событием, мы можем просмотреть стандартный код и изменить его, если это необходимо.

В описании события «щелчок левой кнопкой мыши» по командной кнопке Button1 присутствует код, представленный на рис. 9.2.

Рис. 9.2. Код события «щелчок левой кнопкой мыши»

Возникает класс Form1, который является, по сути, подклассом стандартного класса Form, и внутри существует метод, также общедоступный, который называется Form1 – по сути конструктор. Он вызывает единственный метод InitializeComponent. Дальше отправляется событие, что форма начала существовать с некими аргументами, связанными с событиями этой формы (е). Это также фигурирует в окне свойств Button1.

Достаточно интересна полнота представления различных видов элементов управления для создания форм ввода данных и построения отчетов. Microsoft подходит к этому достаточно гибко и широко. На рис. 9.3 видно, что существует большое количество предопределенных элементов управления – Control, а в левом окне можно открыть панель управления – Toolbox. Это десятки предопределенных элементов Windows Forms. Таким образом, там содержится много элементов управления, которые перетаскиванием мыши можно разместить на форме. Это Poiner, командная кнопка, Checkbox-флажок и т. д. Различного рода метки – текст со ссылкой, выпадающий список и целый ряд других элементов. Скажем, существует командная кнопка, которую можно представить как изображение. Progress Bar, т. е. индикатор некоторого процесса, к примеру загрузки файла через Интернет. Radio кнопка – переключатель. Rich text box – мини-текстовый редактор, который также доступен изначально как готовый элемент управления. Интересно, что даже веб-страница существует как готовый элемент управления.

Рис. 9.3. Набор предопределенных элементов управления

Кроме тех элементов, которые были перечислены, пользователь может создать свои элементы. Для этого используется специальный класс user control. Естественно, можно использовать те классы, которые уже предопределены в. Net, конкретно в Windows Forms, в пространстве имен System.Windows.Forms и на основе классов – каждый элемент управления является классом – можно создавать собственные элементы управления, добавляя и убавляя свойства.

Для создания собственных форм и элементов управления и коррекции их в визуальном режиме используется средство Windows Forms Designer. Это компонент, встроенный в Visual Studio. Он позволяет создавать свои формы путем комбинирования элементов управления. Существует возможность выравнивания без особых затрат труда, поскольку это происходит визуально. В связи с этим есть возможность построения интерактивных интерфейсов, поскольку пользователь может взаимодействовать с ними посредством событий, и интеграция с Microsoft Office. Это интерфейс, который основан на знакомых нам приложениях и ОС Windows, и MS Office. Скажем, существуют элементы управления Tool strip и Menu strip, как в Word. Это может быть представлено как в форме меню, так и в форме инструментов – командных кнопок. По сути, они уже существуют в виде примитивов в пространстве имен и могут быть использованы в нужной конфигурации и автоматически собраны при просто визуальном перенесении пользователем их на форму. Таким образом можно быстро создавать меню, глубокую вложенность подменю, которые могут содержать и другие элементы управления.

Как упоминалось ранее, пользователь может создавать собственные элементы управления, для этого используются классы, содержащиеся в System.Drawing. Напомним, что структура. NET Framework достаточно четко разграничена. Прямо на форме можно осуществлять прорисовку или выполнение несложных иллюстраций, скажем, рисовать линии, прямоугольники, овалы и т. д. В Word тоже есть панель рисования. Очень важным является вопрос интеграции данных из гетерогенных источников. В части корпоративных приложений речь идет о гетерогенных системах, которые могут включать как хорошо структурированную информацию, так и плохо структурированную – видео, аудио, сканы. К каждому фотоизображению прилагается информация о том, когда была сделана фотография, каким фотоаппаратом, каков ее размер. При этом Windows Forms имеет специальный элемент управления DataGrid-View, чтобы из гетерогенных источников можно было извлекать данные и формировать отчеты. При этом могут быть использованы разные источники данных – БД: SQL Server, Access. Позже мы посмотрим, как выглядит отчет в DataGridView. Это представление среза данных, которое хешируется и хранится на клиентской части приложения и необязательно отражает актуальное состояние базы данных. Можно брать данные из специализированных данных формата XML, веб-сервисов и т. д. Какие возможности получает пользователь при работе с этим сложным элементом управления? Какие потери могут быть понесены, если попытаться создавать его самостоятельно? Мы можем динамически менять размер строк и столбцов, фиксировать их, настраивать представление, цвет фона, шрифта и т. д. Наконец, можно осуществлять отображение сложных объектов внутри каждой ячейки – не только текст, но и фото, видео. При этом внедрение на форму элемента управления DataGridView происходит стереотипно и так же легко для пользователя, как и размещение элементарной кнопки – drag&drop из репозитория на форму.

Очень важным при этом является свойство Entry Point – связь с гетерогенным источником данных – различной природы. Это могут быть хорошо структурированные реляционные данные, гетерогенно представленные в хранилище данных на основе xml метаданных.

Еще одной технологией, которая активно используется в связи с WinForms, является технология интеллектуальных клиентов SmartClients. С помощью этой технологии есть возможность взаимодействия с источником данных через сетевое соединение (через интернет-канал). Это крайне важно для корпоративных систем, так как дает возможность получения корпоративных данных через Интернет из любой точки земного шара. Для корпорации значение этой технологии трудно переоценить. На рис. 9.4 показан компонент BindingSource, мы видим его в Solution Explorer и в левом окне, которое представляет собой Design View, т. е. визуальное представление формы. Данный компонент дает возможность связать определенный элемент DataGridView с тем или иным источником данных, который позволяет нам извлечь гетерогенные данные той или иной природы (мы уже описывали виды источников данных, которые используются) и разместить их в форме.

Рис. 9.4. Компонент BindingNavigator

Компонент BindingSource является частью среды Microsoft.NET Framework и позволяет управлять целым рядом параметров взаимодействия корпоративного пользователя с источником данных. Это такие характеристики, как параметры соединения с источником данных, организация связи данных, которые извлекаются из того или иного источника с элементами управления (например, с ячейкой DataGridView), с определенными текстовыми элементами, скажем, многострочный вывод, однострочный и т. д., веб-страница, навигация между записями источника данных, если этот источник возможно представить в виде нескольких записей, например файл или таблицу в базе данных, редактирование записей источника данных – можно вносить через сетевое соединение изменения в данные на этом удаленном источнике и записывать изменения в источник данных.

Здесь есть достаточно серьезная проблема, связанная с управлением транзакциями, поскольку корпоративных пользователей, которые занимаются редактированием или просмотром объекта одновременно, достаточно много. Возникает вопрос: какие изменения и в какой последовательности записывать и как они будут отражены? Оптимально при правильном управлении транзакциями пользователь должен воспринимать информацию в параллельном режиме с другими пользователями, как будто он взаимодействует с базой только один. BindingSource и технология SmartClients во многом, естественно вкупе с другими технологиями, позволяют решить эти проблемы. Кроме того, существует элемент управления BindingNavigator, который дает возможность разработчикам использовать данный интерфейс для визуальной обработки записей данных из гетерогенных источников через сетевое соединение. На рис. 9.5 показан пример применения BindingNavigator и его размещение на Windows Form (на форме Form1 в данном случае) и организации визуального интерфейса с гетерогенным источником данных. При этом используется компонент BindingSource, построен конкретный пример объекта этого класса, который называется BindingSource1 и присутствует как в Solution Explorer, так и в Design View.

Рис. 9.5. Применение BindingNavigator

Другой способ связи основан на взаимодействии приложений и называется Application Settings. Это тоже подход SmartClients, использующий Windows Forms. Форматом хранения данных является XML. Файл описывает состояние приложения и фиксирует такие параметры, как линейные размеры формы на экране, персональные предпочтения пользователя, какие элементы и в каком положении он хочет видеть на форме, как, скажем, мы можем создать «мой Яндекс», упорядочить или определить свои предпочтения по тому, каким образом представлены элементы управления и в каком порядке они расположены на Яндекс-баре или других элементах интерфейса, можно изменить место хранения файлов по умолчанию и целый ряд других параметров. При этом во время выполнения приложения возможна автоматическая загрузка в память элементов данных и фактически осуществление кэширования информации на клиенте.

Теперь следует рассмотреть, каким образом это происходит визуально, как осуществляется работа с гетерогенными источниками данных на основе Application Settings. Сначала создается элемент управления Application Settings, в Solution Explorer – Properties появляется описание метаданных, которые связаны с Application Settings, здесь есть параметр PropertyBinging и ряд параметров, которые показывают связи с целым рядом атрибутов конкретного приложения. Есть параметры, описывающие линейные размеры, – Margin, Location, шрифт, местоположение файлов и т. д. Таким образом, на форме можно в динамическом режиме конкретизировать параметры источника данных, из которого извлекается информация. При извлечении данных из приложения необходимо использовать параметр Location, чтобы увидеть, как они отображаются в визуальном интерфейсе.

Важным аспектом корпоративных систем, который обеспечивает сокращение совокупной стоимости владения, является технология экономичного развертывания приложения. Ранее была рассмотрена технологии ClickOnce, которая позволяет быстро и в ряде случаев одним щелчком мыши и без участия специалистов по администрированию систем на уровне пользователя осуществить установку стандартных компонентов корпоративных приложений. Под развертыванием стоит понимать установку пользователем на клиентском компьютере – своей машине. Это может быть ноутбук, рабочая станция, смартфон или коммуникатор, т. е. некое клиентское устройство, для которого существует. NET Framework и соответствующие компоненты, объектные библиотеки и прикладные интерфейсы. Естественно, речь идет о том, что приложение может быть установлено после того, как оно разработано и для последующего использования. При реализации концепции быстрого развертывания приложения существуют проблемы. Это прежде всего массовая рассылка обновлений. Естественно, в корпорации функционирует далеко не одна информационная система. В каждом офисе существует большое количество гетерогенных информационных систем, при этом каждая система имеет некий номер версии, и отслеживание взаимосвязи этих версий – достаточно сложный процесс. Для этого используется специальное ПО – контроль версий: нужно отслеживать возможность согласованного использования компонентов этих приложений и, естественно, тех дополнений, доработок, которые разработаны для этих приложений с целью обеспечения их взаимной совместимости. Достаточно сложно – если речь идет о десятках тысяч пользователей – упростить рассылку обновлений и установку приложений. Если предположить, что каждый пользователь должен тратить 5 минут в день для установки приложений и их согласованной работы, получим тысячи человеко-часов. Чтобы этого избежать и повысить отдачу от использования приложений и снизить стоимость владения, Microsoft разработала ClickOnce – по сути, механизм сборок, описание кода, компонентов корпоративных систем с точки зрения как хранимых данных, так и метаданных, которые требуются этим сборкам, и, естественно, политики безопасности. Технология ClickOnce позволяет достаточно просто и быстро развертывать приложения при наличии Visual Studio и. NET одним или несколькими щелчками мыши, без ввода данных с клавиатуры, т. е. стандартным образом. Пользователь практически не может запутаться, повести себя двусмысленно – есть только один путь установки приложения, прямой и простой, и за короткое время без участия администратора пользователь может установить и настроить дополнение к приложению, как мы устанавливаем дополнения к приложению в Windows или Office.

Именно поэтому еще одним достоинством является интернет-ориентированность. Пользователю необязательно получать весь код, просто URL-ссылку на веб-сервер, на котором хранится код приложения в форме сборки. И после щелчка мыши по установке сборка сама, вместе с технологией ClickOnce, определяет возможность установки, программной среды, версии сборки, подлинность сборки, уровень безопасности, и в соответствии с политикой безопасности осуществляется установка дополнения на клиентский компьютер. Продолжим описание преимуществ технологии Click-Once. Поскольку вся информация о компоненте приложения локализована в сборке, осуществляется унификация управления как элементами данных, так и зависимостями. Для корпоративной системы сложно переоценить значение сборки как средства управления зависимостями между компонентами приложения. Автоматически осуществляется определение возможности установки, сборки в программную среду пользователя, притом что программное окружение пользователя является сложным и гетерогенным и производится или не производится установка. Осуществляется проверка корректности установки – удалось/не удалось и почему. Если установить продукт не удалось, пользователь может обратиться к администратору и четко передать то сообщение, которое на экране свидетельствует о том, что версия сборки не соответствует версии программной среды. Более того, возможно автоматическое обновление приложения на основе информации из Интернета. Также автоматическое обновление осуществляется практически без участия клиента, если клиент подтверждает возможность осуществления такого обновления в принципе. Кроме того, при обновлении приложения разработчику, который осуществляет коррекцию кода в терминах сборки, достаточно опубликовать новый манифест, т. е. метаданные сборки по указанному URL. Следовательно, не нужно тиражировать на все компьютеры пользователя и заботиться о совместимости программной среды того компонента, который вновь разработан, и того, что имеется у пользователя. Каким образом осуществляется публикация изменений или вновь разработанных корпоративных приложений иллюстрирует рис. 9.6. Здесь речь идет о размещении приложения на локальном компьютере, тем не менее это можно сделать и на FTP– и HTTP-сервере при наличии соответствующих прав доступа. Кроме того, если мы один раз указали местоположение, то именно по этому местоположению будет производиться размещение последующих апдейтов, сервис-паков, патчей и т. д. Именно этот интерфейс и использует Publish Wizard, т. е. средство упрощения развертывания приложений. Эта технология основана на подходе ClickOnce, при этом пользователю также достаточно выбрать автоматизированное обновление, и при помощи технологии ClickOnce осуществляется обновление приложений, пополнение, коррекция в автоматизированном режиме.

Рис. 9.6. Публикация разработанного приложения

Какие особенности имеет смысл отметить в Windows Forms в связи с перечисленными задачами по поддержке корпоративных приложений? Прежде всего это высокая степень интерактивности. Ранее описывалось, каким образом осуществляется интеграция приложений, каким образом поддерживаются такие сложные элементы управления, как DataGridView, каким образом пользователь может получить доступ к гетерогенным источникам информации для работы с базами данных, для работы со слабоструктурированной информацией (аудио, видео). Кроме того, поддерживаются окна, ведение диалога, возможен диалог пользователя системы, общение в интерактивном режиме, сценария взаимодействия пользователя с корпоративной системой. Windows Forms поддерживает элементы управления печати корпоративных интерфейсов с WYSIWYG интерфейсом, с помощью интеграции с офисными приложениями. Естественно, интерфейс при этом выглядит привычным пользователю образом, поскольку поддерживаются традиционные командные кнопки, пункты меню и т. д. Можно достаточно легко оснастить компоненты справочной информацией, т. е. онлайновой справочной системой с возможностью гипертекстовых ссылок, контекстного поиска и т. д., как мы видим в Windows и Office, можно добавлять документацию к формам и т. д., можно достаточно легко осуществлять локализацию приложения, перевод на другой язык – важно использование кодировки в Unicode. Кроме того, поддерживаются различные единицы измерения (метры, футы), различные валютные системы (рубли, доллары, евро и т. д.). И еще одна важная особенность Windows Forms: поскольку это надстройка на. Net Framework, можно использовать встроенную систему информационной безопасности, которая основана на реализации механизма сборок. Каждая сборка имеет метаданные, в которых описываются, в частности, автор, версия, цифровая подпись. То есть сборку достаточно сложно подделать или использовать вне контекста приложения, поскольку автор достаточно однозначно определяется сборкой, и сборка, если она подделана, не подойдет, не сможет быть установлена в корпоративную систему и каким-то образом повредить ее целостность, надежность и т. д.

Итак, подводя итоги обсуждения технологии Windows Forms, технологии, поддерживающей эргономичный интерфейс корпоративных приложений, можно сделать следующие выводы. Во-первых, эта технология поддерживает высокую интерактивность, сценарную обработку данных, т. е. обработку данных на основе событий с высокой вариативностью – сценарии эти могут быть достаточно гибкими и адекватно реагирующими на самые разные действия пользователя. Windows Forms имеет огромное количество различных элементов управления, которые позволяют строить достаточно сложные и одновременно привычные пользователю и понятные ему элементы интерфейса – это DataGridView, командные кнопки, элементы меню и т. д. Пользователь в связи с этим получает возможность работать с корпоративными системами предсказуемым образом, повышает свою производительность и, следовательно, производительность труда в корпорации. Кроме того, осуществляется возможность доступа к гетерогенным источникам информации, что важно для корпоративных пользователей, в первую очередь посредством удаленного доступа. Пользователи получают возможность доступа к гетерогенным источникам данных, а также к аудио– и видеоинформации на основе XML-представления. И что очень важно, они имеют возможность агрегировать эту информацию, получать ее в едином интерфейсе, т. е. в гетерогенном отчете может быть представлен как текст, извлечение из отчета базы данных на основе запроса, так и определенная фото– и видеоинформация, которая извлечена из хранилищ данных. Технология Windows Forms позволяет без особых затрат производить обновление, коррекцию, усовершенствование отдельных компонентов программных систем и программных систем в целом. Пользователь получает возможность автоматического обновления, если осуществляется подписка на это обновление, поскольку Windows Forms является надстройкой на. NET и поддерживает все политики, протоколы шифрования данных, протоколы взаимодействия, в том числе по Интернету, которые реализованы для. NET Framework.

Итак, была рассмотрена технология Windows Forms, которая предназначена для создания эргономичных пользовательских интерфейсов корпоративных систем. При этом упоминалось, что эта технология поддерживает распределенные взаимодействия пользователей с гетерогенными источниками данных на основе таких элементов, как BindingSourceNavigator, и подобных средств организации доступа к гетерогенным источникам корпоративной информации. Теперь обсудим, каким образом осуществляется создание и поддержка распределенных приложений на платформе. NET, какие технологии используются. Прежде всего, речь пойдет о веб-сервисах и о технологии Remoting. Последняя разработана Microsoft, является достаточно жесткой, но тем не менее обеспечивает высокую безопасность и надежность приложений, что весьма важно для корпоративных систем. Обсудим ее в связи с другими технологиями сетевого взаимодействия компонентов распределенных приложений в корпоративной интернет-среде.

Во-первых, рассмотрим общий принцип функционирования распределенных приложений, а также их основные особенности, в которых явно выделяются роли клиента и сервера. Клиент и сервер – это не обязательно аппаратное обеспечение, это не обязательно один и тот же компьютер. Сервер может быть распределен по нескольким компьютерам – это, скорее, логические объекты. Мы рассмотрим различия и основные особенности веб-сервисов по отношению к технологии Remoting. Далее речь пойдет об основных понятиях, которыми следует оперировать при определении распределенных приложений. Рассмотрим низкоуровневые средства для работы с сетевыми приложениями и еще раз вернемся к технологии клиент-серверного взаимодействия для построения распределенных приложений корпоративного типа. Очень важна, особенно в связи с Remoting, процедура удаленного вызова процедур (RPC). Это важная технология, которая исторически достаточно рано возникла и, по сути, реализует базовую схему взаимодействия распределенных приложений, в том числе в интернет-среде. Мы обсудим, каким образом осуществляется компонентное проектирование и программирование в среде. NET, центральным понятием идеологии. NET является компонент, синонимом компонента выступает сборка.

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

Итак, перейдем к процедуре построения корпоративных распределенных приложений на основе технологии Remoting и других технологий, связанных с веб-сервисами и клиент-серверной архитектурой. Общий принцип построения подобных систем заключается в следующем: объекты или модули распределенного приложения в случае компонентного подхода к проектированию (компоненты или сборки) располагаются физически на нескольких компьютерах и логически – в нескольких процессорах ОС. За счет специализации выделяется слой бизнес-логики, который реализуется на клиентской части и на сервере. За счет этого оптимизируется производительность клиента и сервера и осуществляется взаимодействие элементов распределенного приложения в наиболее выгодном режиме для пользователей, по сути, оптимизируется производительность программной системы, время реакции, производительность пользователей.

Какие основные понятия характеризует веб-сервисы и технологии Remoting? Технология Remoting является достаточно жесткой по сравнению с общей методологией веб-сервисов. Microsoft продвигает принцип предоставления ПО как сервиса, поэтому понятие веб-сервиса не только не чуждо методологии. NET, но и является одним из ее основных компонентов. Веб-сервисы представляют собой слабосвязанную модель взаимодействия объектов на основе общедоступных мировых стандартов. Это в первую очередь протоколы взаимодействия HTTP, SMTP. Веб-сервисы независимы от языка программирования, в отличие от Remoting. Еще очень важно, что веб-сервисы поддерживают модель работы с объектами без сохранения внутреннего состояния. То есть объекты, по сути, не имеют памяти о своей истории. Подход. NET Remoting является более строгим, более жестким, нацеленным исключительно на среду. NET, т. е. прежде всего на ОС Windows. Конечно, NET поддерживается и для узкого круга Unix-систем, в рамках проекта mono, но в целом ориентация преимущественно на. NET и Windows. Кроме того, модель нацелена на более эффективное и безопасное выполнение объектов в. NET, так как содержит встроенную систему безопасности, она поддерживает сборки и подписи, алгоритмы шифрования, поддерживаемые средой. NET. Таким образом, реализуется сильно связанная модель, которая поддерживает память, т. е. состояние объектов, и обеспечивается более эффективное взаимодействие объектов в среде. NET. При этом объекты располагаются на разных компьютерах и в разных процессорах.

При исследовании слабо и сильно связанных (Loosely Coupled и Tightly Coupled) моделей распределенных приложений нужно отметить, что модель Loosely Coupled, также как и Tightly Coupled, предназначена для распределенных приложений. Различие состоит в более свободном выборе протоколов и отношении к сохранению состояния, которое используется в последнем подходе. Loosely Coupled модель подразумевает построение распределенных приложений на основе минимального набора приложений и взаимодействий. Tightly Coupled подход подразумевает более жесткую связь, более строгую однородность частей приложения и в отличие от Loosely Coupled основан на заранее согласованных более строгих протоколах и наборах данных. Loosely Coupled подход использует стандартные протоколы XML и HTTP. Что касается модели взаимодействия объектов, то здесь распределенные объекты взаимодействуют без сохранения памяти о своей истории. Таким образом, с точки зрения ООП можно конкретизировать подход взаимодействия клиента и сервера без сохранения состояния тем, что каждый вызов метода обрабатывает новый экземпляр объекта, который создается заново. В отличие от похода, связанного с наличием состояния, не меняется состояние объекта со старого на новое, а просто создается новый экземпляр объекта.

Что касается работы с сетью, позднее мы увидим, каким образом это связано с пространством имен Remoting. Напомним, что существует пространство имен System, внутри которого находится пространство. NET, а потом —.Sockets (рис. 9.7). Первое подпространство определяет основные параметры источников взаимодействия, т. е. таких точек взаимодействия на клиенте и сервере, как пространство доменных имен, характеристики точек взаимодействия и т. д. И пространство имен Sockets определяет более детально характеристики клиента и сервера, которые связаны с конкретным протоколом, скажем TCP/IP, и построением потока данных для обмена сетевой информацией.

Рис. 9.7. Иерархия пространств имен

 

Глава 10

Технологии сетевого взаимодействия корпоративных систем

Рассмотрим эволюцию технологий сетевого взаимодействия распределенных приложений и построение такого рода приложений. Одной из наиболее ранних технологий является удаленный вызов процедур – Remote Procedure Call. Во многом эта технология реализуется в Remoting при маршеринге, который будет рассмотрен несколько позднее. Еще одним подходом была передача сообщений, т. е. взаимодействие между распределенным приложением, между объектами. В одном из первых вариантов она называлась DCE – Distributed Computing Environment. Если рассматривать взаимодействие клиента и сервера, концепция открытых систем предполагает явное распределение ролей на клиент и сервер. При этом клиент – это компьютер, который осуществляет преимущественно запрос информации, в данном случае это вызов функции, которая на самом деле обращается к серверу, хотя это очевидно только из ее названия. Сервер осуществляет поиск, получение и предоставление отчетной информации для клиента в соответствии с его запросом. Кроме того, вспоминая главу об архитектуре, заметим, что помимо двух слоев клиент-серверной архитектуры (клиента и сервера), существует еще промежуточный слой, который предназначен для локализации взаимодействия. Но пока рассмотрим уровни клиента и уровни сервера.

Идея взаимодействия состоит в том, что функция, которая в данном случае называется Server Func, формально при чтении кода не должна вызывать ассоциации с сервером. С точки зрения клиента, осуществляется как бы выполнение этой функции. Функция имеет два параметра – символьный Hello и целочисленный 123. И результат должен быть присвоен некоему объекту J. На самом деле на клиенте функционирует специальный слой, который называется промежуточным и транслирует при переводе этой программы в промежуточный код из так называемого верхнего слоя (Top Layer), представляющего собой исходный текст на том или ином языке программирования (в данном случае это язык С), который транслирует этот вызов в некий внутренний вызов и упаковывает его нужным образом. Этот специализированный механизм называется Proxy-клиент. Он осуществляет трансляцию и упаковку этого вызова процедуры в обращение к другому компьютеру (серверу) с нужными параметрами, которые переупаковываются, меняют свои имена. Происходит передача некоего указателя на область памяти (*str) и некоего целочисленного значения v, с кодом, который у нас имеется на клиенте, осуществляется передача его после соответствующей упаковки серверу, Stub серверу, т. е. специальный функциональный компонент сервера осуществляет преобразование этого запроса во внутренний запрос сервера, организацию процедуры, заданной клиентом, и активизацию этой процедуры на сервере с заданными параметрами. Вычисление значений с переданными аргументами происходит путем подстановки вместо параметров их значений. Вычисление связано с работой процедуры на сервере. После этого осуществляется обратная упаковка и передача клиенту в ответ на его запрос. На нижнем уровне (Bottom Layer) осуществляется передача данных по сети на соответствующем уровне. Ниже находятся все последующие протоколы сетевого стека.

В ходе обсуждения взаимодействия RPC – это один из весьма важных механизмов взаимодействия по сети, который принципиально важен для понимания технологии Remoting. Осуществляется взаимодействие между Proxy и Stub. Proxy – это подпрограмма, которую может вызывать клиент на сервере. Поэтому технология называется процедурой удаленного вызова. Proxy передает серверу запрос на вызов подпрограммы, которая работает на сервере, с заданными параметрами, и ждет ответа от сервера. После выполнения процедуры результат возвращается клиенту. При этом вызов Proxy с точки зрения кода клиента не отличается от вызова внутренней подпрограммы или метода. Фактически эта логика взаимодействия удаленного вызова инкапсулируется внутри Proxy. Аналогично, но только на сервере, работает технология, связанная со Stub. Это тот код, который выполняется на сервере. Он получает от клиента запрос на вызов заданной подпрограммы. Осуществляется вызов подпрограммы, которая работает на сервере, а не на клиенте, как кажется клиенту. И результат, который записывается в переменную Result, автоматически после упаковки отправляется по сети на клиент. При этом Proxy и Stub создаются автоматически. Для этого, конечно же, требуется определенного рода описание открытых интерфейсов, т. е. сред взаимодействия между клиентом и сервером. Одним из примеров такого языка является IDL–Interface Definition Language, который используется в технологии брокеров объектных запросов (COBRA).

Итак, мы можем видеть три слоя взаимодействия, если абстрагироваться от сетевого уровня, где все просто описано с точки зрения кода, на уровне исходного текста программ – процедура на клиенте и процедура на сервере. На уровне Middle Layer происходит упаковка Proxy Stub клиента и упаковка параметров, выполнение процедуры на сервере после распаковки и передача упакованного результата через Middle Layer на клиент. Собственно, данные передаются на уровне Bottom Layer по протоколу передачи данных. Естественно, существует стек сетевых протоколов с целым рядом протоколов, которые лежат ниже перечисленных нами уровней процедурного взаимодействия.

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

Объектное RPC скрывает различия между объектами, которые разработаны в разных интегрированных средах и, возможно, на разных языках. В связи с этим сделан большой шаг вперед по сравнению с предыдущим подходом, который на самом деле достаточно жестко завязан на язык программирования. И, конечно же, по сути, объектного взаимодействия в 1980-е гг. в полной мере еще не было. При этом наиболее распространенными подходами следует считать подходы, основанные на компонентной модели COM c динамическим расширением Decom и COM+. И второй важный подход – CORBA. Это альтернативный подход, связанный с брокерами объектных запросов и использующий язык IDL, который описывает интерфейсы взаимодействия между различными объектами. Подход CORBA связан с Object Request Broker, которые реализуют функции, несколько похожие на Proxy и Stub, описанные ранее.

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

Рис. 9.8. Клиент-серверное взаимодействие по схеме COBRA

Итак, какие особенности можно выявить в объектных RPC, объектном подходе к удаленному вызову процедур, с точки зрения взаимодействии Proxy и Stub по сравнению с ранним подходом? Речь идет об объектном взаимодействии. Proxy и Stub выглядят как обычные объекты. Для клиента функция на С выглядит как локальная. Так же и объект при вызове будет выглядеть как локальный объект на клиенте. Но на самом деле этот объект осуществляет упаковку параметров и передачу их серверу. Этот процесс упаковки параметров и их передачи называется маршаллинг и является весьма существенным для. NET и Remoting, так как по сути означает передачу объекта через границу процесса.

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

Теперь обсудим, каким образом осуществляется взаимодействие между клиентом и сервером в RPC по объектной схеме. Как Proxy, так и Stub являются объектами и реализуют в полной мере объектно-ориентированное взаимодействие параметров Operation передачи от клиента серверу и параметров Reply возвращаемого значения от сервера клиенту. При этом взаимодействие между клиентом и сервером, кроме упаковки параметров и ответов, включает, что очень важно, передачу этих параметров через границу различных процессов (1 и 2), которые выполняются, возможно, в различных ОС или на различных машинах. Напомним, что процесс упаковки называется маршаллингом, процесс распаковки – анмаршаллингом. Если перейти от традиционной схемы объектно-ориентированного взаимодействия при реализации технологии удаленного вызова процедур RPC к той технологии, которая реализуется в среде Microsoft.NET и называется. NET Remoting, станет понятно, что взаимодействие организуется очень похоже.

Каким же образом осуществляется взаимодействие между клиентом и сервером через границы процессов и как при этом используются так называемые домены приложений? Рассмотрим это более подробно. При выполнении некоторой программы, написанной для. NET, естественно, следуя главе, в которой речь шла о среде. NET, выполнение это происходит в среде CLR. По сути, компоненты программ, которые реализуются и выполняются в этой среде, оттранслированы в код виртуальной машины. Microsoft Intermediate Language, зависящая от платформы, функционирует в терминах этого языка на той самой виртуальной машине, которая называется CLR машина. При этом загрузчик программы сначала создает хост CLR, по сути, экземпляр виртуальной машины и приложение машины, в которую по умолчанию загружаются сборки, необходимые для выполнения этой программы, и затем осуществляется передача управления этому процессу. В некоторых случаях в одном процессе может сосуществовать несколько различных доменов приложений. Среда CLR – виртуальная машина. NET может поддерживать независимое выполнение программ одного процесса в рамках нескольких доменов приложений. На рис. 9.9 представлен процесс, который на уровне операционной системы реализован в архитектуре приложений 32-разрядной машины Windows. При этом на уровне. NET осуществляется создание хоста CLR, в рамках которого могут функционировать в одном процессе несколько доменов приложений. Далее соотношение между процессами и доменами приложений выглядит следующим образом. В рамках одного и того же компьютера, скажем CLR, могут функционировать несколько процессов в архитектуре той же Windows 32. В каждом из них может быть также не один домен приложения, а несколько. Другой компьютер – это может быть сервер или другой клиент – также может иметь один или несколько процессов Windows 32, внутри которых также может быть несколько (в данном случае три) домена приложений.

Рассмотрим, каким образом осуществляется работа с удаленными объектами, расположенными на сервере? Со стороны клиента это выглядит точно так же, как и в среде. NET. Существует четкое разделение на взаимодействие по имени и взаимодействие по ссылке (Value и Reference). Если мы вспомним систему CPS, систему типизации, которая реализована для. NET, то увидим, что в рамках этой системы типизации существует изначальное четкое разграничение на две большие категории типов – Reference и Value. И обращение с объектами, обработка объектов этих больших категорий происходит различными способами. Напомним, что объекты классов категории Value, например, хранятся в стеке, при копировании создается физическая копия объекта, создается еще один объект стандартного размера, скажем, 4 или 2 байта, в зависимости от типа объекта. Он имеет фиксированный размер, и осуществляется физическое копирование значения. Если рассматривать объекты типа Reference, то осуществляется копирование ссылки, а не самого значения. Размер объекта, который имеет тип ссылку, изначально не определен, и на самом деле речь идем о том, что есть указатель на некую область памяти. Хранится в динамической памяти объект этого типа, т. е. взаимодействие между такого рода объектами, или маршаллинг, также происходит различными способами. То есть в. NET существует подход, который называется Marshal by Value и Marshal by Reference. Рассмотрим основные различия между этими подходами, а также их реализацию.

Рис. 9.9. Домены приложений в Windows

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

Итак, маршаллинг по значению разумен, целесообразен в тех случаях, когда, так же как и в случае объектов типа значения, речь идет о достаточно простых объектах – целочисленных, булевых или о тех объектах, которые редко претерпевают изменения во времени. Маршаллинг по ссылке предполагает передачу от сервера к клиенту параметров вызываемого метода, а не самого объекта. И методы объекта вызываются на стороне сервера. В случае маршаллинга по значению вызываются на стороне клиента, в случае маршаллинга по ссылке – на стороне сервера. В отношении маршаллинга по ссылке и по значению можно отметить следующую специфику: объект содержит ссылки на системные ресурсы, которые специфичны либо для процессора, либо для компьютера. Также объект содержит ссылки на большое количество других объектов на стороне сервера либо часто изменяет свое состояние. Если речь идет о маршаллинге по ссылке, то этот подход предпочтителен для сложных специфичных объектов конкретного процесса или компьютера, для объектов с большим количеством ссылок или для объектов, которые часто изменяют свое состояние. При работе с корпоративными системами также целесообразен маршаллинг по ссылке.

Рассмотрим явное создание объекта как вариант клиент-серверного взаимодействия по технологии Remoting. Здесь мы уже видим в примере кода, что явно используется метод маршаллинга объекта класса Remoting Services. То есть в пространстве имен. NET существует класс Remoting Services, который имеет ряд методов, связанных с реализацией объектов и передачей параметров от клиента серверу различными способами. Итак, при явном создании объекта осуществляется прежде всего создание некоего объекта, вызов конструктора, оператор NEW для объекта Obj класса Server Object. Осуществляется вызов конструктора без параметра, и создается новый объект. После чего осуществляется маршаллинг с явной передачей именно этого объекта путем вызова метода Marshal класса Remoting Services с параметром Obj. Таким образом, объект на сервере создается явно. Он будет иметь имя srv_obj. И объект на сервере существует до тех пор, пока на него имеются ссылки. Реализация уничтожения ссылок явным образом осуществляется посредством вызова специального метода, того же класса Remoting Services, который называется Disconnect. При этом необходимо явно указывать, что речь идет об объекте Obj.

При явном создании объекта клиент может получить ссылку на этот серверный объект двумя способами – используя либо метод Get Object класса Activator (здесь необходимо преобразование к классу Server Object), либо оператор type of, который определяет объект по типу. Для этого явно указывается имя объекта, которое было ранее определено и его местоположение, – Localhost. Другой подход связан с определением типа объекта и явным указанием этого объекта таким же образом, как и в предыдущем методе, а затем созданием объекта явным образом посредством конструктора Server Object.

Далее следует рассмотреть вопрос явной активизации объектов на сервере. Момент создания объекта в этом случае определяется сервером. При этом речь идет уже о передаче не экземпляра объекта, а его типа. То есть имя присваивается не экземпляру, а типу. И для обработки каждого вызова удаленного метода может создаваться собственно новый экземпляр объекта. При этом используется метод Single Call. Здесь явно указывается имя объекта srv_obj и осуществляется вызов метода Register Service Type, т. е. определенный метод реализации сервиса на основе класса Remoting Configuration. Нужно сказать, что все вызовы удаленного метода могут обрабатываться одним и тем же объектом, сервером, при этом используется метод Single в отличие от предыдущего Single Call. Клиент работает с удаленным объектом полностью аналогично предыдущему случаю. Другая форма взаимодействия между клиентом и сервером основана на активизации объектов клиента. При этом момент создания объекта определяется уже не сервером, а клиентом, и на сервере в этом случае может быть создано много объектов. В этом случае сервер объекта уникально однозначно определяется явным указанием имени компьютера. Мы видим, что осуществляется передача параметра методу Register Activated Service Type, т. е. осуществляется регистрация указанного типа сервиса с параметром того самого объекта типа «сервер», к которому реализуется обращение. При этом, по сути, мы работаем в том же пространстве имен Remoting с тем же классом Remoting Configuration, но другим образом определяем конфигурацию взаимодействия между клиентом и сервером. При активизации объектов клиентом на сервере клиент должен вначале осуществить регистрацию типа объекта с учетом его расположения на сервере, а затем создать объекты, для каждого обращения создается объект (Proxy), который осуществляет инкапсуляцию методов на сервере. Итак, мы используем метод Register Activator Client Type класса Remoting Configuration с явным указанием, что тип объекта расположен на сервере, и явным указанием этой машины. После чего для каждого вызова создается свой объект класса Server Object. По сути, это не совсем объекты, это Proxy. Но для каждого из них осуществляется свой вызов оператора New.

Последнее, что будет обсуждаться касательно Remoting, – это процедура сборки мусора. Вообще, процедура сборки мусора крайне важна для больших объектных систем. Здесь речь идет о том, что существует большое количество объектов типа «ссылки». Следует напомнить, что в. NET, в CTS – системе типизации, существуют два больших подкласса объектов – ссылки и значения. Если рассматривать корпоративные системы, то очевидно, что для реализации распределенных приложений, которые используют большое количество сложных объектов, а вместе с тем эти объекты имеют сложную структуру и динамически взаимодействуют друг с другом, целесообразно использовать типы-ссылки. В связи с этим часто возникают ситуации, когда не вполне корректно уничтожается информация о значении самого типа-ссылки при уничтожении собственно объекта этого типа. То есть не всегда разрывается связь между именем и значением объекта, на которое указывает ссылка с этого имени. Для уничтожения такого рода висячих ссылок, т. е. ссылок, указывающих на некорректную область памяти, которая уже освобождена и не содержит значения типа «ссылки», существует стандартный процесс сборки мусора.

По сути, эта технология характерна для большого количества программных инструментов, программных сред и реализована впервые достаточно давно, в частности одни из первых реализаций были связаны с языками функционального программирования, которые также поддерживают динамические структуры данных (например, LISP). Естественно, в Microsoft.NET, среде, которая призвана поддерживать работу с большим количеством языков программирования, распределенных сложных корпоративных программных систем, актуальность сборки мусора существенно возрастает в связи с частой сменой состояния и значений объектов. Конечно, имеет смысл и для технологии Remoting, и для технологии, которая поддерживает определенное взаимодействие компонентов таких систем, осуществить грамотный оптимальный и достаточно эффективный подход к сборке мусора. И здесь существуют разные подходы: обычный подход к сборке мусора в целом в среде. NET и поход, который связан с реализацией механизмов на основе. NET Remoting.

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

Что касается подхода Remoting, то здесь используется механизм аренды. Существует определенный интервал времени, который определяется для каждого серверного объекта. Каждому серверному объекту ставится в соответствие объект специального вида, который имеет интерфейс лизинга. И выглядит следующим образом: существует для маршаллинга по ссылке класс, который определяется как класс Marshal by Ref Object и содержит виртуальный объект, собственно и реализующий инициализацию процедуры обслуживания сборщика мусора. При этом интерфейс лизинга внутри класса осуществляет вычисление времени аренды для каждого объекта, который поставлен в соответствие и для которого существует возможность определения и обновления срока аренды, если такая возможность предоставляется.

На этом рассмотрение реализации технологий распределенных вычислений в среде. NET завершается. Мы познакомились с общим принципом распределенных вычислений, обсудили различие между подходом с сохранением состояний и подходом без сохранения состояний, а также подходом, который связан с Loosely Coupled и Tightly Coupled моделями взаимодействия. Оценили эффективность сильно связанной и большую универсальность слабо связанной модели взаимодействия объектов. Рассмотрели эволюцию архитектур, которые связаны с объектным и дообъектным подходами обмена информацией между клиентом и сервером по технологии RPC. Общим для этих подходов является наличие Proxy и Stub как механизмов упаковки и передачи параметров между клиентом и сервером. При упаковке речь идет о маршеринге, при распаковке – об анмаршаллинге. В объектном подходе имеет место инкапсуляция объектов, т. е. изоляция технологий сред взаимодействия и конкретных языков программирования, на которых реализуются процедуры, методы или функции для клиентов и серверов.

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

Как Remoting, так и более поздние технологии, с нашей точки зрения, основаны на интерфейсе, связанном с веб-формами, и существенно его используют. Более поздние технологии – это технологии веб-сервисов, речь о которых пойдет более подробно в следующей главе, и технологии, которые связаны с подходом WCF – Windows Communications Foundations. Эти технологии призваны реализовать подходы, связанные с клиент-серверным взаимодействием на основе более открытых протоколов и объектного распределенного взаимодействия в архитектуре клиент – сервер. Речь идет о сервисно-ориентированной архитектуре и таких протоколах, как SOA, HTTP. Более подробно этот вопрос будет освещен позднее.

 

Глава 11

Разработка веб-сервисов для корпоративных систем

Данная глава включает в себя две важные темы. Это прежде всего веб-сервисы, основополагающая для. NET технология, на которой зиждется все сетевое взаимодействие в этой среде. Вторая тема продолжает рассказ об архитектурах распределенного взаимодействия и представляет собой описание технологии Windows Communication Foundation (WCF). Исторически одной из наиболее ранних технологий, не считая веб-сервисов как таковых, была технология Remoting, но на сегодняшний день эта технология не является доминирующей, хотя на ее основе до сих пор производится достаточно много полезных приложений серьезного уровня. Напомним, что технология Remoting подразумевает жесткие связи между клиентом и сервером, строгий протокол взаимодействия, в связи с чем на ее основе производится программное обеспечение безопасных информационных систем. Технология же WCF не является, также как сам подход, связанный с веб-сервисами, столь жестким и, возможно, столь безопасным.

Веб-сервисы представляют собой, в том варианте, в котором мы рассмотрим их, вариацию на тему более общего и, может быть, более известного подхода, носящего название сервисно-ориентированной архитектуры, и изначально, наверное, во многом вместе с Microsoft или даже раньше, разрабатывался корпорацией IBM. Те решения, которые созданы на его базе IBM, являются в определенном смысле более открытыми, поскольку не только базируются на платформе операционной системы Microsoft Windows, но и поддерживают целый ряд других платформ, в частности Unix-системы. Поэтому подход SOAP (сервисно-ориентированной архитектуры), которому следуют в том числе и веб-сервисы, является несколько более широким, но поскольку мы сосредоточиваемся преимущественно на технологиях Microsoft, речь пойдет в основном об этих технологиях. Конечно, центральным понятием для архитектуры Microsoft.NET являются веб-сервисы. Ранее уже шла речь о клиент-серверных архитектурах, и понятно, что для реализации корпоративных приложений имеет смысл, конечно же, разделять логику взаимодействия компонентов системы на клиентскую и серверную части, когда у нас одна из них запрашивает ресурс или доступ, а другая этот доступ организует, а ресурс предоставляет. В данной главе будут рассмотрены веб-сервисы, возникновение этой концепции, а также ее особенности для. NET и то, каким образом следует ее использовать, а именно, каковы основные принципы, основные подходы, связанные с реализацией веб-сервисов. Мы рассмотрим достаточно подробно небольшой пример весьма простого веб-сервиса, который создается на основе инструментального средства Microcoft Visual Studio.NET. Покажем, каким образом создаются и применяются веб-сервисы. Более подробно рассмотрим модель реализации веб-сервиса в архитектуре Microsoft.NET, на платформе Microsoft.NET. Вспомним общую схему архитектуры. NET. На самом нижнем уровне находится операционная система Windows и ее сервисы, далее идут. NET Framework, базовые классы, которые осуществляют взаимодействие как с операционной системой, так и с более высокими прикладными уровнями различных информационных систем. И где-то на промежуточном этапе между собственно прикладной логикой и семейством классов. NET Framework находятся в том числе и веб-сервисы, рядом с такими архитектурными компонентами, как, скажем, ADO.NET (Active Data Objects), XML.NET, ASP.NET и целым рядом других элементов.

Более подробно стоит рассмотреть, каким образом веб-сервисы вписываются в общую концепцию и архитектуру Microsoft.NET и, кроме того, обсудить, каким образом осуществляется обнаружение или поиск веб-сервисов. Ведь, по сути, веб-сервис – это некий компонент, который опубликован или, проще сказать, размещен на интернет-сервере. Существует специальный язык, который называется Web Service Definition Language (WSDL) и предназначен для описания веб-сервисов. Это интерфейсный язык, в определенном смысле это достаточно нейтральный стандарт, который можно использовать для описания веб-сервисов. Существует также средство поиска с названием Disco (от слова discovery).

И, конечно же, необходимо обсудить то, как концепция веб-сервисов вписывается в общую архитектуру, в более общую картину SOAP и, естественно, веб-сервисы как элемент этой концепции, сервисно-ориентированной, подчиняются протоколу SOAP, на основе которого функционируют не только веб-сервисы от Micfosoft, но и веб-сервисы от IBM, и большое количество других веб-сервисов. Таким образом этот протокол поддерживается в среде веб-сервисов от Microsoft. Существуют потенциально более безопасные технологии, связанные с сетевым взаимодействием. Это прежде всего Remoting, если рассматривать Microsoft-технологии построения распределенных приложений. Обсудим безопасность веб-сервисов и способы обеспечения этой безопасности, а каким образом ВС, эта центральная часть архитектуры. NET, используется для реализации приложений Microsoft.NET.

Перейдем непосредственно к рассказу о ВС: что такое ВС, что понимается под этим термином. Первое слово, которое мы встречаем, – это WEB, т. е. речь идет об Интернете, и поскольку речь идет о сервисе, то здесь мы имеем дело с клиент-серверным взаимодействием, и клиентом, конечно же, является веб-браузер, точно так же, как в случае тонкого клиента. Напомним, что в этом случае на клиенте размещена только презентационная логика, собственно прикладная логика вся размещается на сервере, в связи с чем клиент у нас получается достаточно легким, или, как говорят, тонким. Он ограничен исключительно веб-браузером, и – что имеет принципиальное значение для корпорации – таких клиентов достаточно легко тиражировать, настраивать. Скажем, если появится необходимость из соображений безопасности провести какие-то настройки на клиенте, то это произойдет единообразно для всех компьютеров пользователей, а их в корпорациях тысячи. Если нужно внести какое-то изменение в программную среду клиента, это опять-таки делается и тиражируется с учетом тех средств, которые разработаны, в том числе МС, достаточно легко. Но, надо сказать, что есть интересные средства и у H P, и у Compaq, которые позволяют достаточно эффективно распределять или распространять изменения по компьютерам. И в связи с этим администрирование становится централизованным и во многом упрощается. Итак, ВС – это не просто интернет-приложение, это некий специальный тип, особый вид веб-приложений, который на самом деле не просто создает ответный HTML, появляющийся в браузере пользователя, а характеризуется использованием так называемых веб-методов, т. е. специализированных функций, описанных в среде. NET, которые можно вызывать из браузера. При рассмотрении традиционного клиент-серверного взаимодействия, когда клиент является веб-браузером, понятно, что он читает и воспринимает только статический HTML, в этой связи существует некоторое обобщение.

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

В чем состоят основные особенности реализации и применения ВС? Во-первых, ВС выполняются, конечно же, на сервере, потому что клиент является легким, тонким, по сути это веб-браузер, который имеет только презентационную логику, скажем, определенные формы, которые нужно заполнять, и он обращается к ВС, которые расположены, конечно же, не на клиенте, не в веб-браузере, не на компьютере пользователя, а на сервере. При этом средой выполнения является ASP.NET, т. е. как раз серверная технология, которая предусмотрена для работы в архитектуре клиент– сервер. При этом веб-сервисы осуществляют публикацию, т. е. размещение в Интернете методов, по сути, функций, которые могут быть вызваны внешними клиентами, т. е. интернет-браузерами пользователей, которые эти методы обнаруживают на том или ином сервере в Интернете. То есть сервер, выполняющий запрос пользователя и применяющий при этом ASP.NET, необязательно совпадает с сервером, который хранит и осуществляет взаимодействие пользователя с публикуемыми методами. Взаимодействие при этом, естественно, организуется на основе открытого протокола, стандартного протокола, который поддерживает веб-браузер, это, естественно, HTTP. Существенным минусом или существенной особенностью его является невозможность сохранения состояния, но важно, что это достаточно открытый, стандартный протокол, который поддерживает любой веб-браузер, даже необязательно Microsoft Internet Explorer. Из любого веб-браузера можно осуществить вызов веб-сервиса. Веб-сервисы, те их компоненты, которые отвечают за выполнение этих методов, выполняют запросы, которые могут носить достаточно сложный, гетерогенный, многокомпонентный характер, и возвращают веб-браузеру ответы от сервиса – результаты выполнения этих методов, естественно, с использованием протокола HTTP.

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

Если вести речь о корпоративных приложениях, корпоративных системах, то имеет смысл остановиться на корпоративном контенте – к нему относят реляционные данные, которые хранятся и обрабатываются реляционными СУБД, в случае Microsoft это Microsoft SQL Server. Что касается данных, нужно еще отметить, что это не только реляционные данные, но и, скажем, данные мультимедийные, которые поддаются анализу и обработке зачастую не так хорошо и хранятся они иначе, это могут быть отсканированные документы, аудио– и видеозаписи и т. д., но в любом случае над ними есть при корпоративном подходе некоторая надстройка из метаданных. Будем считать, что это XML-описание полей определенного рода и указания на те области, в которых можно хранить значения этих полей. То есть мы определенным образом индексируем видеоинформацию, информацию звуковую, фотоизображения, после чего можем осуществлять в том числе семантический, т. е. осмысленный, поиск по ним или, по крайней мере, по тем метаданным, которые у нас в итоге, скажем в формате XML, представляются. В результате мы получаем возможность посредством веб-сервисов по стандартному HTTP-протоколу со стандартными языками описания, скажем WSDL и др. в рамках стандартной архитектуры, ориентированной на сервисы, и в рамках протокола SOAP осуществить взаимодействие между этими достаточно разнородными системами. Нам открывается важная возможность построения решений принципиально еще более высокого уровня, чем корпоративные системы, которые называются B2B-решения (Business-to-Business), когда речь идет не об организации процессов внутри одной корпорации, а о взаимодействии нескольких корпораций или компаний между собой. Здесь веб-сервисы выступают своего рода каналом взаимодействия, неким gateway, можно сказать, шлюзом между разнородными и разноплановыми системами этих разных корпораций. Мы просто указываем правила этим ВС, по которым нужно осуществлять поставку информации из одних систем, а из других эту информацию консолидировать.

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

Одно интересное приложение веб-сервисов связано с технологией быстрой разработки приложений. Быстрая разработка достаточно важна для корпоративных систем, поскольку прототипирование, разработка быстрых прототипов позволяет экономить трудозатраты и создать рабочую модель программной системы на достаточно ранней стадии. Это стадия анализа и формирования требований к программному продукту, когда мы можем представить проект решения руководству заказчика. При этом речь может идти о заказчике, который находится внутри нашей корпорации и для которого мы (как другая компания этой корпорации) ведем разработку программных систем. Или же это может быть сторонний заказчик, для которого разрабатывается система. В случае корпоративной системы это достаточно большая, тяжелая, затратная система для реализации, мы можем в сжатые сроки, особенно если мы используем инструментарий от Microsoft Visual Studio.NET, представить прототип. То есть реализацию основных функций без уделения сколь-нибудь серьезного внимания надежности, документации, безопасности и т. д. Существует достаточно большая библиотека веб-форм и элементов управления этих веб-форм от Microsoft.NET – библиотека Windows Forms, для того чтобы эффективно строить классы элементов и эффективно прототипировать программное обеспечение до реализации.

Если рассматривать программное обеспечение, которое должно кроме предоставления локальных решений на технологии Web Form быть распределено по Интернету и обеспечивать доступ для пользователей из Интернета к этим функциям, то технология веб-сервисов совместно с таким мощным средством, как Visual Studio.NET, и таким большим количеством библиотек для реализации стандартных веб-сервисов, как в. NET, является достаточно хорошим решением. То есть быстрая разработка или, лучше сказать, быстрое прототипирование, построение вот таких решений позволяют нам обеспечить продуктивный диалог с заказчиком на ранней стадии проектирования и подготовить представление функциональных особенностей нашего программного обеспечения без существенных трудозатрат. И если речь здесь идет не о боевом продукте, который обладает достаточной надежностью, масштабируемостью, документацией, как это свойственно полномасштабным корпоративным приложениям, то веб-сервисы могут оказать существенную поддержку именно для прототипирования.

Каким же образом строятся веб-сервисы? Наверное, имеет смысл привести пример элементарного веб-сервиса, для того чтобы стало понятно, каким образом, используя инструментальные средства Microsoft Visual Studio.NET, осуществить построение более масштабных веб-сервисов и корпоративных информационных систем на их основе. Рассмотрим пример достаточно простого веб-сервиса, который будет вычислять квадратный корень числа, заданного пользователем в веб-браузере в соответствующей форме. Каким образом осуществляется создание такого рода веб-сервиса? Заметим, что мы работаем в рамках технологии ASP.NET, и поэтому, для того чтобы создать веб-сервис, мы должны создать веб-сервис именно этого класса. По сути, мы работаем в пространстве имен ASP.NET и строим веб-сервис на основе тех технологий, тех классов, которые изначально там имеются. В Microsoft Visual Studio.NET мы должны построить новый веб-сайт, мы выбираем в меню «new web site» и затем пункт подменю, который называется ASP.NET Web Service. После этого нужно задать его имя, предположим, мы его называем RootCalculateService. В соответствии с соглашением о наименовании это будет цепочка из трех слов, каждое из которых начинается с заглавной буквы, и между ними нет ни пробелов, ни подчеркиваний. Таким же образом у нас именуются классы в. NET Framework при реализации приложений на основе этой платформы. При этом у нас создается несколько файлов даже при том небольшом коде, который мы в этот веб-сервис внедряем. У нас существуют определенного рода конфигурационные файлы, Web Config, файл, который будет назван service.smx (подробнее структуру и назначение этих файлов рассмотрим далее) и, собственно, код веб-сервиса, который будет называться service.cs, т. е. на языке C# создается исходный код этого веб-сервиса и мы можем его видоизменять.

Такого рода интерфейс предоставляет нам Microsoft Visual Studio.NET, т. е. используются пространство имен, в частности System. Web, и подпространство имен в нем System.Web.Services, в котором у Microsoft Visual Studio.NET имеется достаточно большое количество классов, стандартным образом описывающих веб-сервисы. Здесь мы видим код, тот самый файл service.cs, С# код этого веб-сервиса. Веб-сервис представляет собой не что иное, как класс Microsoft.NET, общедоступный, который называется Public Class Service и включает некий метод, который тоже называется Service по умолчанию и который мы можем соответствующим способом изменять. Он может включать некоторые компоненты и методы для обработки этих компонентов. В рамках этого сервиса существует некий метод, который мы сейчас создали, он называется CalculateRoot, является общедоступным, имеет модификатор доступа Public и тип возвращаемого значения Double – число с плавающей точкой двойной точности. Точно так же и на вход он получает некий элемент Value типа Double, от которого будет вычислять квадратный корень. В итоге он должен выполнить стандартную функцию, которая находится в пространстве имен Math, математическую функцию, которая называется sqrt, и именно этот метод и вызывается с входным параметром Value, который передается веб-сервису. На основе выполнения этого метода он должен будет вернуть результат, что обозначается служебным словом Return.

По сути, весь наш код уместился в две строчки: это сигнатура метода – название метода, тип возвращаемого значения, тип входного значения, и одна строчка – вызов стандартной функции, которая должна вычислить значение и вернуть его сервису, для того чтобы сервис, отработав, передал его в виде HTML по HTTP-протоколу клиенту, т. е. веб-браузеру. Вот такого стандартного рода окно мы получаем при попытке открытия этого веб-сервиса из нашего клиента. Но сервис у нас хранится локально, и в адресе, в URL, у нас записано HTTP, и затем Localhost и нечто дальше. То есть наш сервис еще не размещен на сервере, и сервер мы эмулируем той же самой машиной, на которой размещен код веб-сервиса. Тем не менее в адресной строке мы вызываем тот самый сервис, который называется Service и имеет точный путь RootCalculateService, это в пути указано. В упрощенном варианте в этом примере мы видим, как осуществляется вызов веб-сервиса. При описании этого веб-сервиса мы видим ссылку под словом Service, которая стандартным образом, как это в веб-браузере и отображается, представляется текстом синего цвета с подчеркиванием: CalculateRoot, если мы по ней щелкаем, то осуществляется вызов веб-сервиса. Ниже, под чертой, осуществляется описание пространства имен, в котором выполняется вызов этого сервиса. Здесь указано, каким образом осуществлять вызов из. NET, используя язык C#, Visual Basic, C++. Возможно, существуют и другие интерфейсы. Кроме того, если мы хотим получить описание работы нашего веб-сервиса, мы можем щелкнуть по ссылке Service Description, которая расположена на строчку выше в описании нашего сервиса, и получить подробное описание этого сервиса.

На самом деле, если мы хотим увидеть, как представлен веб-сервис, так сказать, его внутреннее представление, мы можем обратиться к XML-версии и увидеть, что используются стандартный протокол SOAP, язык описания веб-сервисов WSDL и на этом языке (как мы видим, вариант XML версии 1.0) задается описание веб-сервиса. Здесь указывается, где у нас хранится этот веб-сервис, как называется, указано, что есть элемент, который называется CalculateRoot, и какого рода значения он получает на вход: это входной параметр с именем Value и типом Double. Если мы более внимательно просмотрим XML-структуру этого представления, а именно таким образом выглядит веб-сервис в XML-представлении, мы увидим ряд других параметров: параметры, которые он принимает на вход, параметры, которые он возвращает, и то, что взаимодействие осуществляется посредством передачи сообщений на языке WSDL от клиента к серверу и обратно. На самом деле, если посмотреть на скриншот (рис. 11.1), видно, что здесь представлена небольшая часть описания этого веб-сервиса. На самом деле описание даже такого небольшого веб-сервиса на языке XML занимает достаточно много места, поскольку используется большое количество стандартных функций, стандартных методов, которые применяются для. NET веб-сервисов.

Рис. 11.1. Описание веб-сервиса на языке WSDL

Далее при выполнении этого веб-сервиса пользователь в веб-браузере открывает ссылку на сервис, и под строчкой Service, где была ссылка на его имя CalculateRoot, на имя этого веб-сервиса, при щелчке левой кнопкой мыши получает новое окошко с описанием веб-сервиса CalculateRoot на языке XML и окно ввода данных. Здесь он должен ввести параметр, который имеет имя Value. Пользователь вводит сюда некоторое число. Можно было бы посмотреть, как отработал стандартный сервис, если бы пользователь ввел сюда, скажем, отрицательное число или строку символов, каким образом произошла бы обработка исключения. Но в данном случае пользователь вводит корректное число 4, здесь оно представлено как целое, но это вещественное число с точки зрения реализации нашего веб-сервиса. После этого пользователь нажимает на кнопку Invoke, и происходит обращение к серверу, где хранится описание метода, код которого мы видели. Там вызывается стандартный метод из пространства имен Math, который выполняет вычисление корня квадратного из вещественного числа двойной точности. В итоге мы получаем XML-представление в браузере, где фигурирует то самое число 2, которое и возвращается пользователю. Можно было бы это более аккуратно оформить, в виде окна. Таким образом, веб-сервис корректно отработал и вернул именно в том интерфейсе, в интерфейсе веб-браузера, из которого был запрошен, в новом окне этого интерфейса корректное значение. При этом на компьютере пользователя, хотя в данном случае он совпадает с сервером, в общем случае никаких действий по вычислению не производилось бы, а эта вычислительная процедура в форме метода на C# была бы расположена и хранилась на сервере, который производил вычисления.

После того как мы рассмотрели общее представление некоторого примера, пусть достаточно простого, реализации веб-сервиса, мы можем сделать некоторые предварительные выводы и заключения. В частности, у нас веб-сервис был создан как файл с расширением asmx. Именно это расширение регистрируется в файле mashine.config и именно здесь может храниться тот код веб-сервиса, который будет выполнен, тот код на C#, который мы создавали. Кроме того, этот код может храниться и отдельно. Какова структура asmx файла? По сути, он хранит класс, который задает веб-сервис, в данном случае метод CalculateRoot в классе Service, который и был доступен по ссылке. Файл начинается с директивы @service, т. е. показывает, что внутри этого файла содержится описание веб-сервиса, и существует еще атрибут Class, который описывает наш веб-сервис. Классы веб-сервиса могут быть описаны посредством атрибута Web Service, как и XML-описании, но этот атрибут не является обязательным. Важно, что в описании присутствует определение веб-методов, которые определяются как атрибут класса сервиса с тем же самым именем Web Method. При этом такой атрибут может быть присвоен только общедоступным методам заданного класса. То есть методам, которые имеют модификатор доступа Public, как у метода CalculateRoot класса Service.

Нужно сказать, что у Web Method имеется целый ряд атрибутов, связанных с различными параметрами, характеристиками обработки информации, которая поступает от пользователя и выполняется на сервере. При этом веб-сервисы изначально направлены на создание масштабируемых и достаточно мощных распределенных систем. В этой связи существуют такие параметры у веб-методов, как кэширование результата и буферизация. То есть специальные области памяти отводятся под хранение промежуточных результатов или результатов наиболее частых запросов. Существуют также специальные параметры, такие как Transaction Option, которые поддерживают обработку транзакций, т. е. атомов взаимодействия пользователей с данными. Естественно, каждый метод имеет некоторое имя – Message Name и описание – Description.

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

При создании веб-сервиса существует достаточно общий и достаточно широкий класс, который так и называется – Web Service, на его основе можно создавать собственные веб-сервисы. Он находится в пространстве имен System.Web.Services. Public Class Service мы создали как раз на основе этого класса System.Web.Services.Web Service, а класс Web Service создали как дочерний на основе этого системного класса, он обладает всеми свойствами своего родителя и реализует все его методы, поскольку речь идет о традиционном объектно-ориентированном подходе. Кроме того, поскольку можно не только использовать существующие атрибуты и методы класса, но и создавать новые, расширять его, мы можем доработать, развить код этого класса, чтобы сделать на его основе свой. Подобно тому, как мы это сделали в примере, когда расширили код созданием дополнительного метода CalculateRoot, который вычислял квадратный корень из числа с плавающей точкой двойной точности, которая в результате и публиковалась на клиенте в веб-браузере.

Мы перечислили целый ряд атрибутов веб-методов. Все эти характеристики доступны из класса Web Service, и мы можем организовать непосредственный доступ к таким параметрам класса Web Service, как сессия, контекст, пользователь, сервер, приложение и т. д. Все они имеются в перечне атрибутов этого класса, управляются его методами, доступны, их описание можно найти в описании этого класса, это свойства Application, Context, User, Server и т. д. И если мы осуществляем наследование от этого класса, т. е. создаем собственные классы на основе данного, мы можем применить технологию. NET Remoting, т. е. использовать не только стандартные средства, связанные с веб-сервисом, но и Remoting для организации удаленного взаимодействия компонентов приложения.

Ранее указывалось, что технология Remoting имеет достаточно развитую библиотеку классов, которая позволяет организовать сессии такого рода взаимодействия. Уже упоминалось слово Disco – это такая странная аббревиатура, которая, к сожалению, явной расшифровки не имеет. Она происходит от слова Discovery – обнаружение, поиск. Это механизм на основе файлов, который служит для обнаружения и поиска локальных веб-сервисов. Кроме того, используются специальный язык WSDL и специальная служба UDDI – Universal Description Discovery and Integration, которая применяется для глобального поиска веб-сервисов. Именно благодаря этой службе становится возможным отыскать веб-сервисы, опубликованные на различных серверах, т. е. компьютерах, расположенных в Интернете. Эта задача на порядок проще, и взаимодействие существенно конструктивнее, чем то, что было сделано в предварительной версии Windows, которая появилась в сети Интернет. Для описания веб-сервисов используется язык WSDL. По сути, это подмножество языка XML, т. е. все, что пишется на WSDL, укладывается в XML-стандарт, но здесь есть специальные теги, подтеги WSDL, которые начинаются со слова WSDL. Здесь описываются type, scheme, element и т. д. То есть речь идет о тех объектах, тех атрибутах объектов и методах, которые используются для описания веб-сервисов. Кроме того, описаны сообщения – Message Name, которыми обмениваются объекты при взаимодействии в рамках веб-сервиса. Здесь используется традиционный протокол, предназначенный для обмена данными по сервисно-ориентированной архитектуре, и язык WSDL.

На самом деле достаточно полезно самостоятельно ознакомиться с описанием веб-сервиса, для того чтобы понять, какое значительное количество кода в нем содержится изначально, который мы не писали, но который автоматически наследуется из стандартного класса Web Service, и, конечно, для того, чтобы понять, какова структура веб-сервиса, какие поля и методы используются, как организуется взаимодействие: как организуются сессии, обмен сообщениями и т. д. Многое можно понять и почерпнуть для себя просто из этого описания, которое на самом деле представляет собой достаточно полное описание всей функциональности и всех атрибутов веб-сервиса. С другой стороны, это описание на достаточно универсальном языке, пусть и несколько громоздком в данном случае, по сути, это XML. Здесь нет в чистом виде C#, а есть основные параметры конфигурации этого веб-сервиса: какие атрибуты ему потребуются. Скажем, у нас есть элемент, который называется Value, имеет тип Double и связан с результатом, который выдает метод CalculateRoot. Выдает он его через объект, называемый CalculateRootResponse. Достаточно много можно почерпнуть из этого описания, если внимательно его просмотреть.

На рис. 11.1 представлена относительно небольшая часть этого описания. Итак, язык WSDL – это не что иное, как просто диалект XML, вариант или подмножество языка XML. Если мы будем стандартным средством разбора просматривать этот текст как XML, мы поймем, что это на самом деле XML. Но сюда включены специфические теги, которые позволяют описывать веб-сервисы. А веб-сервис – это не что иное, как класс, который наследует от стандартного класса Web Service свои свойства и имеет определенные атрибуты и методы. Возвращаясь к рисунку с примером веб-сервиса и его описанием на языке XML, можно заключить, что здесь имеется достаточно глубокая вложенность. То есть это описание имеет не один, а несколько уровней абстракции – имеется XML-схема, которая содержит элементы, скажем, атрибуты и методы. Приблизительно в таком виде выдержано описание веб-сервиса. Следовательно, речь идет об описании класса с достаточно большим уровнем вложенности по атрибутам и методам.

Кроме того, WSDL описывает веб-сервис как модуль, т. е. как некоторую замкнутую, самодостаточную единицу кода, который решает узкую специализированную задачу. В данном случае решается единственная задача – подсчет квадратного корня от того числа, которое будет передано пользователем через Internet Explorer, через веб-интерфейс, и возврат значения в том же интерфейсе. Описание WSDL включается между тегами базового элемента, который называется Definitions и имеет ряд разделов. Эти разделы описывают не только структуру веб-сервиса, но и его функции, не только в смысле его прямого назначения и тех расчетов, которые он осуществляет в данном случае, но и, конечно, в смысле интерфейса, взаимодействия с пользователем. Здесь есть раздел Messages – это сообщения, на основе которых будет строиться обмен с сервером, порты, виды портов, сервисы, которые он задействует, определенного рода Boundings, т. е. связи при осуществлении взаимодействия. Об это речь пойдет более подробно при рассмотрении технологии WCF. Здесь просто отметим, что Bounding – это достаточно важная составляющая. Types and Operations – это, по сути, атрибуты и методы, с которыми имеет дело наш веб-сервис. Нет смысла детализировать каждый из этих разделов, каждый может сделать это самостоятельно, используя XML-представление. Оно, с одной стороны, достаточно большое, с другой – вполне наглядное. Веб-сервисы взаимодействуют между собой на основе протокола SOAP. На самом деле это протокол, который функционирует поверх HTTP. Этот протокол достаточно общего вида, т. е. он никак не связан с Microsoft, с веб-сервисами от Microsoft, по сути, это международный стандарт, который существует для построения веб-сервисов или, лучше сказать, сервисов на основе сервисно-ориентированной архитектуры. Во многом его свойства унаследованы от удаленного вызова процедур. С точки зрения клиента, не существует различия между локальным описанием процедуры, т. е. описанием процедуры, которая будет выполнена локально, и описанием процедуры, которая будет выполнена где-то на удаленном сервере. Примерно таким же образом можно заключить, что нет разницы между описанием сервиса, который будет выполнен локально, так как только в URI разделе фигурирует Localhost. Только поэтому можно заметить, что веб-сервис будет выполнен на том же самом компьютере, с которого и осуществляется вызов. URI – универсальный идентификатор ресурса в Интернете, который, как и любой интернет-адрес, может физически описывать компьютер, находящийся где угодно в Интернете. Таким образом, вызов фактически инкапсулируется внутри самого сервиса. И, что немаловажно, взаимодействие осуществляется по общему протоколу, что позволяет в принципе связывать веб-сервисы, как созданные на основе продуктов Microsoft, так и другие. То есть позволяет строить шлюзы между различными веб-сервисами и вообще различными корпоративными системами. Это очень важно, поскольку корпоративные системы изначально являются гетерогенными. Такая ориентация на открытый протокол позволяет нам реализовывать разветвленные распределенные системы достаточно большого объема и их взаимодействие, независимо или в незначительной степени зависимо от тех технологий, на которых они построены. По сути, так же как в большом количестве других протоколов взаимодействия, речь идет об обмене сообщениями в рамках сессии между клиентом и сервером при таком взаимодействии. Это отчасти похоже и на RPC, скажем, на взаимодействие в связи с подходом CORBA, который был описан ранее, отчасти на COM-модель. По сути, у нас есть некоторый протокол обмена сообщениями, когда каждое сообщение включает в себя заголовок сообщения, некоторое тело, в котором, собственно, говорится о том, что же нужно выполнить, и конверт. Протокол SOAP основан на XML-технологии. То есть он не имеет ничего общего с Microsoft и с технологиями от Microsoft. Он точно так же используется и IBM, и другими. Это открытый протокол, международный стандарт, описание процедур удаленного вызова, описание сообщений в нем реализовано на стандартном XML. При этом среда. NET позволяет настраивать формат сообщений, которые отправляются при помощи веб-метода. Здесь используется протокол SAOP и целый ряд атрибутов, которые являются атрибутами класса Web Service. В частности, имеет смысл отметить пару атрибутов, которые называются SOAP Method Attribute и SOAP RPC Method Attribute. То есть взаимодействие по протоколу SOAP может осуществляться разными способами, в том числе и с явным использованием технологии RPC.

Теперь чуть более подробно о структуре заголовков SOAP, о структуре сообщений в этом протоколе для обмена данными. Существует атрибут SOAP Header Attribute, который как раз и призван осуществлять настройку заголовков. И здесь есть стандартный класс, который называется SOAPHeader и расположен в иерархии пространства имен следующим образом: System.Web.Services, т. е. находится внутри пространства имен веб-сервисов, дальше существует пространство имен Protocols, где есть ряд протоколов, в том числе и SOAPHeader. При этом в описании веб-сервиса для этого атрибута указывается имя переменной класса заголовка. После создания Public Class Service1, который является классом System. Webservices.Webservice, т. е. веб-сервисом, мы создаем некий заголовок Public, имеющий идентфикатор m_full и тип Header1. Затем мы его связываем с классом SOAPHeader и производим дальнейшее преобразование уже с осуществленной привязкой к тому типу заголовка, который мы задали. У протокола SOAP имеется достаточно большое количество расширений, которые мы можем использовать в рамках технологии Web Service от Microsoft для того, чтобы осуществлять обмен данными внутри пакетов в рамках сессий по взаимодействию между клиентом и сервером посредством сообщений. При этом можно осуществлять настройку и обработку этих данных достаточно гибким образом, на основе широких возможностей. Для этого существует класс SOAPExtension, и на его основе можно создать свой класс и использовать атрибут SOAP Extension Attribute для создания собственных расширений и регулирования взаимодействия между компонентами веб-сервиса в рамках этих расширений.

Ранее уже были рассмотрены Proxy и Stub. Proxy является инкапсуляцией сервера веб-сервиса в приложении. При этом Proxy в данном случае объявляется объектом класса, который создается в рамках стандартной библиотеки классов Microsoft.NET Framework и использует наше описание веб-сервиса на языке WSDL. При этом методы класса, который создается и инкапсулирует логику веб-сервиса, соответствуют методам веб-сервиса. Генерация этих классов уже автоматически предполагается в Microsoft.NET Visual Studio. Можно использовать и специальную утилиту, специальное приложение, которое называется WSDL.exe и может осуществлять генерацию такого рода классов, генерацию Proxy веб-сервиса. Интересно, что веб-сервисы могут осуществлять как синхронную, так и асинхронную обработку данных посредством вызова методов. При этом асинхронные методы веб-сервиса отмечаются префиксами begin и end. Каждый раз мы помечаем в квадратных скобках имя метода Method Name, что служит сигналом окончания выхода из процедуры, окончанием вызова метода веб-сервиса. Реализуется специальный интерфейс, который называется IAsyncResult, также можно подписаться на уведомление о завершении метода путем передачи делегата или указателя на событие. Похожего рода обработку информации мы обсуждали во время описания технологии Remoting, возможен вызов метода в асинхронном режиме по похожим схемам.

Последний аспект, который хотелось рассмотреть в связи с веб-сервисами, – это безопасность. Следует напомнить, что достаточно безопасным подходом, который довольно часто, в том числе и в последнее время, используется для производства распределенных приложений на основе технологии. NET, является Remoting. Нужно сказать, что ряд методов может быть использован и в стандартных веб-сервисах, которые работают на основе открытого протокола SOAP, взаимодействуют с клиентом по протоколу HTTP и используются широко в. NET Framework. Наверное, следует разделить эти методы, прежде всего на внутрикорпоративные, т. е. те сети, которые будут использованы для доступных лиц внутри корпорации и, естественно, распределенных приложений, и Интернет – открытую среду. В интранет реализуются технологии межсетевых экранов, firewalls, технологии, связанные с ограничением безопасности на основе протокола IP и IP-конфигурации во внутренних сетях. Создаются и используются технологии на основе VPN – виртуальных частных сетей, также аутентификация на основе протокола взаимодействия SP.net и специализированное расширение, связанное с безопасностью на основе протокола HTTP – это протокол HTTPS и другие варианты. В интернет-системах можно использовать цифровые подписи, применяемые в связи с протоколом SOAP, а также аутентификацию, основанную на использовании элементов конкретных прикладных систем.

На этом закончим обсуждение веб-сервисов. Это достаточно общий подход, который позволяет объединить возможности, которые реализованы Microsoft в платформе. NET, и распространить их на решения более общего вида, на гетерогенные системы, которые функционируют в существенно более гетерогенных средах и объединяют решения не только Microsoft, но и других производителей, поскольку речь идет о взаимодействии на основе протокола SOA и протокола HTTP, которые являются открытыми, и на основе сообщений, которые кодируются или задаются внутри при помощи языка WSDL, который на самом деле есть диалект XML.

 

Глава 12

Разработка корпоративной сервисно-ориентированной архитектуры по технологии WCF

Нужно отметить, что существуют и другие подходы к построению распределенных приложений. Ранее был рассмотрен подход, связанный с технологией Remoting, он может использоваться также как расширение веб-сервисов. Сейчас будет рассмотрен еще один подход, который называется Windows Communication Foundations (WCF) и является более открытым и более современным, чем Remoting. Он также предназначен для создания и использования распределенных приложений, т. е. продолжает и развивает концепцию программного обеспечения как сервисов. Рассмотрим особенности общего подхода сервисно-ориентированной архитектуры, которая независима от Microsoft или какого-то другого производителя, является международным стандартом, и реализации этой архитектуры от Microsoft. Это как раз SOAP версия Microsoft. Важными понятиями являются контракты, каналы, связывания. Далее эти элементы и их роль в технологии WCF будут рассмотрены более подробно.

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

Рассмотрим достаточно простой, но важный пример реализации сервиса, по сути, тоже веб-сервиса, на основе технологии WCF. Итак, что такое сервисно-ориентированная архитектура, SOA? Речь идет о том, что это открытый протокол или открытая среда взаимодействия приложений, которая архитектурно основана на использовании сервисов, т. е. реализует концепцию программного обеспечения как сервиса. Естественно, приложения при этом представляют собой распределенные компоненты. Сервисно-ориентированная архитектура регламентирует протоколы и методы, т. е. способы и функции, по которым осуществляется взаимодействие. В концепцию сервисно-ориентированной архитектуры укладываются и веб-сервисы, и технология Remoting, и, конечно же, технология WCF, о которой пойдет речь позднее, и ряд других технологий. Очень важны идеология и подход, связанный с нейтральностью сервисов. То есть при реализации веб-сервисов они остаются независимыми друг от друга и взаимодействуют в независимом режиме. Кроме того, сервисы являются строительными блоками бизнес-процессов, на основе которых осуществляется взаимодействие корпоративных приложений. Каждый такой блок представляет собой либо бизнес-процесс в целом, либо часть этого бизнес-процесса.

Взаимодействие в рамках сервисно-ориентированной архитектуры основано на обмене сообщениями, и эта важная характеристика во многом отличает сервисно-ориентированную архитектуру от других подобных архитектур. Протоколы и технологии взаимодействия являются открытыми: SOAP, XML и т. д. По сути, технология WCF является вариантом реализации Microsoft общей стратегии SOA – сервисно-ориентированной архитектуры, которая была разработана в том числе и корпорацией IBM. Как и другие подходы распределенного взаимодействия на платформе. NET, этот подход связан с использованием библиотеки классов. В данном случае речь пойдет о. NET Framework 3.0 и WCF. Этот подход был разработан, чтобы решить ряд важных задач, в том числе таких, как унификация существующих технологий удаленного взаимодействия приложений, сервисно-ориентированная разработка приложений, т. е. разработка приложений, реализующих концепцию программного обеспечения как сервис, и, что очень важно, кросс-платформенное взаимодействие. То есть подход WCF дает возможность взаимодействия различных платформ. При этом устраняется целый ряд препятствий между корпоративными стандартами от Microsoft, IBM, Sun и других компаний, существует организация WSI Web Service Interability, которая реализует унификацию стандартов и спецификаций взаимодействия приложений, созданных в том числе этими разработчиками. Реализация этих стандартов делает возможным сервисно-ориентированное взаимодействие, в том числе и на основе технологий WCF. Набор стандартов не является монолитным, он реализован таким образом, чтобы давать возможность разработчикам его настраивать, развивать и осуществлять реализацию приложений в достаточно гибком режиме на этой основе. Кроссплатформенное взаимодействие основано на открытых протоколах и позволяет объединить решения от перечисленных производителей на основе целого ряда подходов, связанных с веб-сервисами от Microsoft, NET Remoting, службой распределенных транзакций Enterprise Services и др.

Рассмотрим обобщенную архитектуру WCF. Важными понятиями здесь являются контракты, среда исполнения сервисов, сообщения, хостинг. Контракты определяют целый ряд аспектов взаимодействия между сервисами. При этом существует несколько видов контрактов. Скажем, DataContract, ServiceContract и ряд других. DataContract описывает параметры взаимодействия между сообщениями. MessageContract задает части сообщений в стандартном протоколе SOAP, посредством которого взаимодействуют приложения или их компоненты. ServiceConctract определяет сигнатуру методов сервиса, Policy Bounding Contract – политику безопасности взаимодействия тех протоколов, которые будут использоваться в качестве транспортных, и ряд других аспектов. Среда исполнения определяет поведение сервисов и их обработку в то время, когда осуществляется выполнение кода этих сервисов: в каком режиме осуществляется обработка ошибок, как работает инспекция сообщений, как реализована фильтрация сообщений, как происходит диспетчеризация, т. е., по сути, управление сообщениями, как задаются метаданные, как осуществляется представление метаданных, какое количество экземпляров характеризует каждый сервис. Сообщения, слой сообщений определяет возможные форматы и шаблоны обмена сообщениями в общеархитектурной схеме. Наконец, активация и хостинг определяют последовательность запуска сервисов и контекст протоколов их взаимодействия.

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

В WCF реализуются три вида контрактов: контракт сервиса (Service Contract), контракт данных (Data Conctract), контракт сообщения (Message Contract). Контракты сервисов используются для описания функциональности, которую поставляет сервис. Вместе с операционными контрактами они определяют те методы из. NET Framework, которые описывают операции, осуществляемые сервисами, и те конкретные порты, посредством которых осуществляется взаимодействие. Порты описываются на языке WSDL. Здесь мы видим, что технология WCF тесно связана с технологией веб-сервисов. Она использует тот же самый язык описания. Контракты данных описывают структуры данных, которые служат для взаимодействия сервисов. В частности, определяются типы CLR, среды выполнения Common Language Runtime и XSD, т. е. полностью описываются сериализация и десериализация – преобразование данных при передаче от клиента к серверу. Третьим типом контрактов, на основе которых осуществляется взаимодействие в рамках WCF, являются контракты сообщений. Контракты сообщений описывают, каким образом типы среды взаимодействия CLR будут преобразованы на уровне данных в сообщения протокола SOAP. При этом существует возможность гибких настроек этих сообщений в SOAP, как заголовков, так и тел сообщений. Более подробно сервисные контракты определяют интерфейсы конечных точек веб-сервиса. При этом для указания контрактов используются атрибуты Service Contract и Operation Contract, которые применяются соответственно для классов и интерфейсов и для методов веб-сервисов. Данные контракты используются в технологии WCF как при проектировании, так и при выполнении веб-сервисов. При этом на стадии проектирования определяются те классы, которые при описании веб-сервиса должны быть описаны на языке WSDL как конечные точки сервисов, указываются операции, которые будут задействованы в этих элементах.

На стадии выполнения осуществляются поиск и выполнение методов на сервере, которые связаны с активацией тех или иных сервисов. Если речь идет о Service Contract и Operation Contract, то эти атрибуты задают порядок взаимодействия. В том числе возможно как однонаправленное взаимодействие, так и дуплексное. При однонаправленном взаимодействии, которое кодируется свойствам и атрибута Is One Way, клиент получает только подтверждение взаимодействия с веб-сервисом. При дуплексном взаимодействии устанавливается полноценный двунаправленный обмен сообщениями. При этом сообщения могут посылаться как от клиента серверу, так и от сервера клиенту. Сообщения для этого снабжаются соответствующими атрибутами, такими как адрес, способ связывания и контракт: Address, Binding and Contract. В WCF это основа взаимодействия, которая кодируется аббревиатурой ABC: Address, Binding, Contract. Это является важным порядком, по сути, описанием порядка взаимодействия. При таком взаимодействии используется один и тот же транспортный протокол, при необходимости создается новый канал. При этом в дуплексных контрактах используются контракты как клиента, так и сервера.

Обсудив контракты сервисов, переходим к рассмотрению контрактов данных. Данные сервиса представлены типами CLR, с другой стороны, это внутренние типы среды выполнения Common Language Runtime, извне они поступают как описание веб-сервиса на языке WSDL. Таким образом, контракты данных являются связующим звеном между внешним WSDL и внутренним CLR представлением. Для определения контрактов данных используются атрибуты Data Contract и Data Member. При этом Data Contract используется как атрибут класса, а атрибут Data Member используется как атрибут члена этого класса, семейства или как атрибут поля. Важно отметить, что оба эти атрибута – и Data Contract, и Data Member – используются как при проектировании класса, веб-сервиса, так и при его реализации. Контракт данных обеспечивает сериализацию данных, при этом используется атрибут Data Contract Serializer. Контракты сообщений – это третий тип контрактов, определяют собственно представление сообщений в формате SOAP, т. е. то, каким образом внутренние типы CLR будут представлены в формате взаимодействия. С помощью атрибутов контрактов сообщений – это Message Contract, Message Header, Message Body Member – осуществляется управление разработчиком над представлением данных в формате SOAP. Разработчик при этом получает достаточно мощное средство управления контрактами, представлением этих контрактов. Атрибут Message Contract определяет структуру SOAP сообщения, но не определяет их содержания. То есть он не определяет, скажем, нужно ли сворачивать, архивировать тело сообщения или не нужно. Другие атрибуты используются для настройки заголовка и тела сообщения SOAP. Данный вид контрактов не используется вместе с Data Contract. При этом при использовании с Message Contract необходимо наличие только одного входящего и одного исходящего параметра, поскольку осуществляется прямое преобразование в SOAP.

На рис. 12.1 представлен пример контрактов сервиса и контрактов данных. Следующим важным понятием, описывающим взаимодействие между клиентом и сервером, являются каналы обмена данными WCF. Каналы являются средством взаимодействия сообщениями между сервисами и их потребителями, при этом каналы используются как для подготовки сообщений, так и для их доставки. Для подготовки сообщений используются так называемые протокольные каналы, а для доставки – транспортные. В этом смысле существует разделение между каналами. Для транспортных протоколов по технологии WCF используются протоколы HTTP, TCP, WebSphere MQ и др. Также осуществляется взаимодействие в формате точка-точка и так называемые именованные каналы. Существуют и сторонние реализации, при этом используется ряд протоколов, скажем FTP, SMTP, на основе протокола, который используется для доставки почтовых сообщений, UDP и ряд других протоколов, скажем, WebSphere MQ, реализованный для поддержки продуктов корпорации IBM и основанный на передаче сообщений. По сути, речь идет о стеке каналов, т. е. в каналах существует несколько уровней: транспортный и протокольный. Протокольный уровень находится на более высокой позиции в стеке, чем транспортный. Протокольные каналы служат для осуществления транзакций, т. е. взаимодействия между клиентом и сервером посредством элементарных операций, и для шифрования. Таким образом, архитектура WCF дает достаточно высокую степень гибкости при настройке взаимодействия между сервисами и клиентами, которые запрашивают эти сервисы.

Рис. 12.1. Описание контракта сервиса и контракта данных

Для каналов WCF характерны три вида взаимодействия: 1) однонаправленное; 2) дуплексное или полноценное двунаправленное, когда и клиент, и сервер могут посылать друг другу сообщения; 3) взаимодействие по типу запрос – ответ. При рассмотрении контрактов достаточно подробно обсуждались эти виды взаимодействия, в частности однонаправленное и дуплексное. Для реализации этих шаблонов используется ряд интерфейсов, которые упоминались в примерах кода, в том числе такие как ISessionChannel, IInputSessionChannel, IDuplexSessionChannel, IRequestSessionChannel, IReplaySessionChannel, т. е. по сути интерфейсы реализуют каждое из этих конкретных видов взаимодействия. Кроме того, существует единый базовый интерфейс ICommunicationObject, который поддерживает взаимодействие всех классов объектов, участвующих в канальном взаимодействии. Этот общий интерфейс является неизменным для каналов, а также фабрик каналов и механизмов слушания запросов на сервере и используется для реализации всех механизмов взаимодействия. Таким образом, стек каналов представляет собой многоуровневый стек взаимодействия, включает транспортный и протокольный уровни, и может состоять как из одного канала, так и из нескольких. В этом смысле важным является определение «связанный» или Binding. Нужно сказать, что это понятие весьма важно для объектных систем вообще и в математических формализациях с объектными моделями имеет первостепенное значение, скажем, в теории конечных последовательностей в форме λ-исчисления, имеет реализацию в форме связывания переменной со значением. В данном случае под связыванием понимается заранее сконфигурированный стек каналов взаимодействия по технологии WCF. При этом с помощью связывания подход WCF инкапсулирует различные сценарии взаимодействия. Например, Basic HTTP Binding заранее сконфигурирован для взаимодействия со стандартными веб-сервисами по технологии SMX. WSHTTP Binding – для более сложного взаимодействия Web Service Addressing. Ряд других вариантов взаимодействия на основе связывания образует стек каналов, который использует также специализированные элементы, называемые элементами связывания. Всего в WCF определено и может быть использовано до девяти типов связывания. Это, по сути, предопределенные конфигурации, которые используют протоколы HTTP, TCP и др. Если ни одна из этих стандартных конфигураций не удовлетворяет разработчиков, есть возможность создания собственных конфигураций на основе существующих.

Взаимодействие между каналами с использованием механизмов связывания имеет достаточно сложную схему, которая логически представлена в форме следующего алгоритма. Прежде всего выявляется наличие необходимости интероперабельности или взаимодействия с другими платформами. Здесь оно представлено ромбом с надписью «Требуется интероперабельность?». При этом в случае позитивного ответа мы перемещаемся вниз, в случае негативного – вправо. Если интероперабельность требуется, то нужно уточнить, какой именно уровень интероперабельности будет использован: общий, на основе Basic HTTP Binding или более сложный, с поддержкой дуплексного взаимодействия, тогда используется WS Dual HTTP Binding. Если требуется повышенный уровень безопасности, будет использоваться еще один уровень связанности. Таким образом, все девять типов связывания присутствуют в схеме.

Локальное связывание использует подход NET Named Binding, а также очереди на основе MSNQ, с поддержкой расширений, в том числе на основе сервисно-ориентированных продуктов сторонних производителей. Могут быть также организованы сети по принципу точка-точка, и тогда используются механизмы, связанные с NET TCP Binding. Кроме того, может использоваться подход, связанный с NET Pear TCP Binding. То есть может быть использован целый ряд априори сконфигурированных сценариев взаимодействия в рамках этой технологии. Как упоминалось ранее, могут быть использованы дополнительные сценарии на основе существующих, полученные посредством их развития. Важным средством взаимодействия между клиентом и сервером является так называемый сценарий поведения. По сути, это класс, который реализован в рамках технологии WCF, существует в соответствующем пространстве имен и оказывает влияние на поведение системы во время выполнения приложения.

В WCF существуют следующие виды сценариев использования. Это сервисный сценарий или сценарий сервера. Он работает на уровне сервиса, реализован на сервере, имеет доступ ко всем конечным точкам сервера и влияет на поведение системы во время выполнения. Реализация этого сценария по принципу передачи сообщения от одной точки к другой. Кроме того, существует возможность создания пользовательских сценариев использования. Сценарии использования, которые отвечают за сервисы, поддерживают обработку транзакций, авторизацию пользователя на сервере, создания пользователями объектов и изменения этих объектов, а также аудит действий пользователя. Другим классом сценариев поведения является сценарий конечных точек или NetPoints. Здесь работа осуществляется на уровне конечных точек, реализуется инспекция, т. е. осмотр и обработка сообщений, которые поступают на сервер. Еще один сценарий – это Callback, сценарий обратного вызова, аналог сценария, который реализуется для сервера, сценария сервисного, и функционирует на клиенте в режиме дуплексного, т. е. полноценного, взаимодействия между клиентом и сервером. Следующий вид сценариев – сценарии операционные, они используются на уровне отдельных операций и управляют сериализацией, т. е. преобразованием форматов данных при передаче от клиента серверу, и наоборот, а также потоком транзакций, т. е. элементов взаимодействия между клиентом и сервером. Сценарии взаимодействия конечных точек отвечают за обработку данных до и после того, как они попадаются на обработку конечному методу. При этом на клиенте выделяются следующие три вида сценариев поведения: связанные с инспекцией параметров, сообщений и форматирования сообщений. При инспекции параметров данные исследуются, анализируются и преобразуются до их сериализации в XML-представление. При форматировании сообщений данные исследуются и преобразуются во время конвертации в XML в ходе преобразования. И, наконец, при инспекции сообщений представление данных в формате XML преобразуется при трансляции во внутреннее представление Microsoft.NET. При этом на сервере, кроме упомянутых сценариев, реализуются еще два вида специфических для серверной части сценариев. Это выбор операции, т. е. метода, и вызов этой операции. В первом случае рассматривается и анализируется входящее сообщение и происходит определение метода для обработки этого сообщения, того метода, который соответствует этой операции. Во втором случае осуществляется обслуживание этого вызова, т. е. обработка этой операции тем самым методом, который предназначен для нее на сервере.

Рассмотрим некоторые из сервисных сценариев поведения. Заметим, что они определяются соответствующими классами WCF, которые реализованы в. NET. Введем понятие меры параллельности. Это число задач, одновременно выполняемых тем или иным сервисом. То есть таких задач, которые можно понимать как отдельные задачи или отдельные работы. Под временем выполнения задачи будем понимать то время, которое сервис затрачивает на одну задачу. Производительностью будем считать число задач, которые сервис выполняет в единицу времени. Увеличить производительность можно одним из двух способов: либо уменьшить время выполнения, либо увеличить меру параллельности. При этом для задач существуют сценарии поведения, которые называются Instance Context Mode и Concurrency Mode и реализуют соответственно две эти стратегии, увеличивают количество экземпляров сервиса или количество потоков на экземпляр сервиса. Первый класс Instance Context Mode определяет, какое количество экземпляров сервиса будут обслуживать запросы. При этом возможны три режима выполнения: режим Single – единственный экземпляр сервиса для всех запросов, режим Percall – для каждого запроса создается свой отдельный экземпляр сервиса, режим Persession – для каждой сессии создается отдельный экземпляр сервиса. Другой подход связан с числом потоков на экземпляр сервиса и имеет возможные значения: Single, Reentrant, Multiple. Single определяет, что единственный поток имеет доступ к классу сервиса, он может покидать сервисный класс, но обязан вернуться и продолжить операцию. Режим Multiple реализует многопоточный доступ к одному и тому же сервису, а при режиме Reentrant только один поток имеет доступ к классу сервиса. Еще одним важным сценарием поведения является реализованный как класс WCF сценарий Service Meta Data Behaviour, который позволяет публиковать метаданные о сервисе, т. е. все параметры, которые его определяют. Достаточно сказать, что все описание в WSDL-формате может публиковаться этим классом. При этом метаданные предоставляются сервисом посредством конечной точки – Metadata Exchange. То есть существуют специальный формат данных и специальное средство предоставления метаинформации о сервисе.

Как упоминалось ранее, важным средством взаимодействия клиента и сервера при реализации технологии WCF являются транзакции. При этом сценарии поведения на основе этих транзакций могут быть реализованы различными способами. Транзакции бывают двух типов: многошаговые бизнес-процессы и так называемые короткие транзакции, которые, в отличие от первого типа, завершаются достаточно оперативно и затрагивают относительно небольшое количество объектов и связей, зависимостей или ограничений целостности. WCF поддерживает второй вид транзакций, короткие транзакции. Рассмотрим, для чего используется атрибут Operation Behaviour и его свойство Transactionscope Requirement. Это свойство определяет, будет ли операция выполняться в режиме так называемых транзакций, или будет ли транзакция завершаться автоматически (Transaction Scope Complete) при окончании работы метода, или же ее можно будет завершить. В таком случае потребуется поддержка механизма взаимодействия, который реализуется на основе сессий. Важным аспектом взаимодействия между клиентскими и серверными частями приложений по технологии WCF является сериализация и десериализация. Сериализация – это процесс преобразования графа объектов в поток байтов, т. е. в последовательный поток формата XML Info Set. Таким образом, сериализация является эффективным способом сохранения состояния объектов, которое может храниться в базе данных или файле. В WCF состояние объектов хранится исключительно в XML Info Set. Особенность в том, что здесь, в отличие от XML, не задается конкретного формата данных. Используется процесс кодировки, преобразования сообщения WCF в поток байт, во внутреннее представление процесса, и существуют различные виды кодировки, которые доступны в WCF. Всего таких представлений пять. Это двоичный формат, текстовый формат, формат Message Transmission Optimization Mechanism (MTOM), формат, связанный с Java Script, Java Script Object Notation, и формат POX, Plain Old XML, связанный с традиционным XML. При этом выбор кодировки зависит от конкретной ситуации, от конкретных требований ПО по надежности, производительности, интероперабельности, масштабируемости и т. д.

Рассмотрим методы сериализации WCF в сравнении. Произведем сравнение механизмов сериализации, которые реализуются процедурами Data Contract Serializer, Net Data Contract Serializer, XML Serializer и Data Contracts JSON Serializer. Стандартным сериализатором является первый из них, Data Contract Serializer. Он преобразует внутренние типы WCF во внешнее представление XSD, которое является платформенно-независимым. То есть, по сути, не несет связанных с. NET элементов и поэтому может использоваться для взаимодействия со сторонними приложениями, скажем, с приложения, реализованными на основе Java. Для того чтобы этот сериализатор работал с классом, класс необходимо снабдить атрибутом Data Contract, а свойство или поля, которые используются для сериализации, необходимо снабдить атрибутом Data Member. Следующий вид сериализации, Net Data Contract Serializer, близок к первому, но отличается возможностью добавления информации о внутренних типах CLR к тем возможностям, которые имеются у сериализатора по умолчанию. В отличие от первого вида, он используется для. NET приложений и при этом осуществляет взаимодействие между частями этого приложения, причем только одного. NET приложения. Третьим классом, который отвечает за сериализацию, является XML Serializer. Это стандартный сериализатор. NET, который появился еще на уровне Framework 2.0 и сохранился в Framework 3.0. Он позволяет реализовать стандартный механизм сериализации, т. е. работать со стандартными типами. NET, имеет возможность настройки XML-представления, позволяет настраивать выход XML, который генерирует сервис, и работает со стандартными сервисами формата ASP.NET. При этом существуют три основных подхода к использованию данного вида сериализации. Можно использовать стандартную сериализацию, а также атрибуты, связанные с XML: XML Attribute, XML Element. Кроме того, можно использовать интерфейс IXML Serializer, который позволяет организовать взаимодействие с XML-форматом. Еще один важный вид сериализации Data Contract JSON Serializer, который поддерживает стандартную нотацию объектов в формате Java Srcipt.

Важным понятием, характерным для технологии WCF, является понятие host или servicehost. По сути, данное понятие определяет процесс, который несет ответственность за обработку и контекст выполнения веб-сервиса. Это процесс операционной системы, который управляет выполнением сервиса и контекстом, отвечает за старт сервиса, остановку этого сервиса, а также предоставляет важные базовые функции управления сервисом. Хостом сервиса WCF может выступать любой процесс ОС. Такие приложения, как Internet Information Service, Windows Process Activation Service, имеют встроенную поддержку хостинга, т. е. внутреннюю инфраструктуру, которая этот хостинг реализует. Кроме этих подходов можно использовать другой сервис, любой Windows Service, а также любое приложение с пользовательским интерфейсом или консольное приложение для того, чтобы осуществить поддержку хостинга. В зависимости от того, что именно является хостом сервиса, его конфигурация и настройка осуществляются в целом единообразно. Выбор хостинга зависит от требований к приложению, его быстродействию, устойчивости, масштабируемости и т. д. Каждый хост WCF требует реализации трех функциональных элементов: это объект класса ServiceHost, конечная точка и запуск прослушивания сообщений на сервере или процедуры listen.

Перейдем к более подробному описанию среды хостинга Windows (Process) Activation Services или W(P)AS, которая является стандартной средой хостинга (рис. 12.2). Она встроена в новые операционные системы – Windows Vista и серверную ОС Windows Server 2008, поддерживает ряд возможностей, которые раньше были доступны только через Internet Information Service. W(P)AS позволяет размещать сервисы в гибкой среде, которая не требует обязательного использования протокола HTTP. Предположим, что есть однонаправленное взаимодействие с некоторым сервисом и конечный пользователь этого сервиса, который довольно часто находится в отсоединенном от сервиса состоянии. В данном случае в качестве транспортного уровня лучше использовать MSMQ, чем HTTP, который не сохраняет состояния. Или, допустим, у сервиса много клиентов, с которыми он часто обменивается небольшими по размеру сообщениями. В этом протокол HTTP также подходит в меньшей степени, и выгоднее использовать протокол TCP. При этом желательно поддерживать множественность протоколов. Такую возможность дает W(P)AS, эта среда многопротокольная, здесь не требуется обязательное использование протокола обмена HTTP, т. е. осуществляется возможность работы в гибкой среде. Эта возможность поддерживается за счет реализации шаблона Listener Adapter, который абстрагирует слушателей, осуществляющих взаимодействие с процессами, от клиента, от процессов управления.

Рис. 12.2. Схема реализации хостинга в среде W(P)AS

На рис. 12.2, где показана схема взаимодействия процессов различных протоколов с хостом процесса, т. е. с реализацией хостинга на основе технологии W(P)AS, видно, что могут использоваться различные протоколы взаимодействия, и с точки зрения хоста безразлично, каким образом, по какому конкретно протоколу организовано это взаимодействие. Возможно и взаимодействие точка-точка, и взаимодействие по протоколу, который не сохраняет состояние, HTTP, и взаимодействие по TCP-протоколу, и взаимодействие по протоколу, скажем, MSMQ. Рассмотрим небольшой пример веб-сервиса в рамках технологии WCF, который реализует функции калькулятора.

Рассмотренный в предыдущей главе (см. рис. 11.1) пример задействовал всего одну функцию – вычисление квадратного корня. В данном примере будет рассмотрен достаточно простой калькулятор, который осуществляет функции сложения, вычитания, умножения, деления (рис. 12.3). Он заимствован из стандартных примеров кода Microsoft (эти примеры расположены на Micfosoft.Servicemo del. Samples), реализован как интерфейс, который называется ICalculator.

Рис. 12.3. Описание сервиса WCF, реализующего функции калькулятора

На вход каждой операции, которая представляет собой контракт-интерфейс, снабженный атрибутом Service Contract, и в каждой операции мы используем атрибут Operation Contract. Каждая операция представляет собой метод, на вход которого поступают два значения типа Double – число с плавающей точкой двойной точности, выход тоже представляет собой число типа Double. Рассмотрим, каким образом реализуется класс, который выполняет этот контракт. Мы указываем, что это класс общедоступный Calculator Service и использует тот интерфейс, который был ранее определен, определенный нами интерфейсный контракт ICalulator. Контракт реализует соответствующий интерфейс и не требует никаких дополнительных атрибутов. Фактически реализуются те же операции, возвращаются значения суммы, разности, произведения или частного. При этом осуществление вычислений реализуется достаточно наивно, т. е. нет проверки, скажем, на нулевой делитель и других, возможно, важных проверок, которые потребовались бы. Здесь осуществляется просто обращение к стандартным функциям, и будет, видимо, задействовано стандартное исключение CLR, при ошибке, скажем, деления на ноль или другой арифметической ошибке, которая возникнет в случае исключения того или иного рода. Продолжим обсуждение примера – веб-сервиса, который реализует простейший калькулятор. Кроме того, что мы создали описание кода в форме интерфейса и контракта, мы должны реализовать конфигурационный файл, который будет расположен на сервере. Это, естественно, XML-подобное описание, и оно достаточно громоздкое.

В данном случае оно представлено на рис. 12.4. Что характерного в нашем описании сервиса с этой точки зрения можно заметить? Прежде всего, здесь описана конечная точка, через которую ведется взаимодействие. Связывание определено как WSHTTP Binding, т. е. мы используем тип связывания с учетом протокола HTTP. При описании веб-сервиса мы должны определить наше ABC. В рамках выбранной сервисной модели на основе пространства имен System должно быть описано определение, связанное с описанием Calculator Service, который определен ранее, реализует интерфейсный контракт и расположен внутри пространства имен Micfosoft.Servicemodel.Samples. При этом определяется конфигурация поведения Calculator Service Behaviour, а именно какой адрес интерфейса поставляется хостом, где хранится этот интерфейс. Далее указывается необходимый адрес, привязка ABC, которая имеет вид HTTPBinding, и, наконец, интерфейсный контракт, т. е. тот самый интерфейс ICalculator, который у нас описан. Особенности использования связывания типа wsHttpBinding состоят в том, что в качестве протокола взаимодействия используется протокол HTTP, который не сохраняет состояния, и используются стандартные протоколы веб-сервисов WS для организации взаимодействия между клиентом и сервером с точки зрения адресации, безопасности. Сервисы WCF не осуществляют экспорт своих метаданных по умолчанию при такого рода связывании. Для этого сервису необходимо явно указать точку обмена метаданных в виде Metadata Exchange, ее конфигурация явно присутствует в файле конфигурации: явно указаны ABC адрес, связывание и контракт. Вот такое небольшое описание кода завершает наш сервис.

По результатам реализации сервиса осуществляется автоматизированная генерация кода для клиента, которая выполняется при помощи утилиты SWSUtil.exe. Некоторые фрагменты реализации этого кода (рис. 12.5), представляющие собой основные элементы этого кода, выглядят следующим образом: в этом описании присутствуют интерфейсы, которые называются ICalculator и ICalculatorClient. Дано описание класса ICalculatorClient, все, что касается его конечных точек с точки зрения адресов и основных функций, которые он реализует. Функции add, substract, multiply, divide, которые реализованы для этого интерфейса.

Рис. 12.4. Файл конфигурации WCF-сервиса

Заканчивая описание технологий WCF, хочется отметить, что эта технология достаточно зрелая, связана во многом с ядром Indigo, с достаточно поздними реализацией ОС: это прежде всего Windows Vista, Windows Server 2008, и здесь реализуется достаточно открытое по сравнению, скажем, с технологией Remoting, взаимодействие между клиентом и сервером. Как мы видели, существует большое количество возможных протоколов взаимодействия, которые прозрачным образом инкапсулируются в технологии W(P)AS, возможны взаимодействия как по протоколу HTTP, так и по протоколу TCP, MSNQ и т. д. При этом поддерживается взаимодействие не только с приложениями, разработанными на основе технологии. NET, но и на основе целого ряда других технологий. Центральным понятием является понятие хостинга, это реализация процесса, которая отвечает за обработку контекста выполнения сервиса. Принципиально важны процессы преобразования графа объектов в формат XML и обратно, сериализация, десериализация. Существует большое количество сценариев для управления потоками данных как на клиенте, так и на сервере, при этом осуществляется выбор вида данных, которые взаимодействуют, это управление транзакциями, управление безопасностью и т. д. Существует большое количество видов связывания. Для того чтобы осуществить взаимодействие, используется схема ABC, адрес, связывание, контракт. Применяется девять типов связывания, которые зависят от необходимости обеспечить интероперабельное взаимодействие, степень безопасности, вид взаимодействия с учетом используемого протокола, с использованием вида сетевого взаимодействия в его конкретизации: требуется ли связь точка – точка или локальное соединение и т. д. Связь между клиентом и сервером осуществляется на основе каналов, которые представляют собой стек протоколов на основе единого интерфейса ICommunicationObject, каналы при этом делятся на транспортные и протокольные и подразумевают как однонаправленное взаимодействие, так и гибкое взаимодействие по двунаправленной дуплексной схеме. Контракты в WCF имеют троякое представление – для сервисов, для данных и для сообщений и являются важной частью обеспечения взаимодействия между клиентом и сервером по схеме ABC. WCF – это Microsoft-версия реализации стратегии сервисно-ориентированной архитектуры, реализации программного обеспечения как сервиса, она поддерживает все необходимые классы. NET Framework, т. е. большое количество базовых операций и атрибутов по взаимодействию клиента и сервиса, поддерживает технологию Remoting и другие технологии Microsoft, а также дает возможность взаимодействия по открытым протоколам SOAP и HTTP с программным обеспечением других производителей, в том числе на основе стандартизованного языка обмена сообщениями WSDL на основе протокола XML.

Рис. 12.5. Код клиентской части WCF-сервиса

 

Глава 13

Разработка компонентных корпоративных систем

Эта глава посвящена компонентному программированию, компонентной разработке программных систем, в том числе и корпоративных, и разработке офисных приложений. Как уже говорилось, одним из важных аспектов идеологии. NET является компонентно-ориентированная разработка, которая понимается как развитие объектно-ориентированной парадигмы. Когда обсуждались открытые системы, упоминалось, что компонентный подход достаточно важен при разработке больших открытых систем на основе стандартных протоколов обмена информацией, поскольку в этом случае достаточно легко открываются и используются возможности адаптации, коррекции, развития, расширения программных систем путем изменения относительно небольшой доли кода, заключенного в критически важных компонентах приложения. Компоненты могут разрабатываться в рамках подхода. NET, на разных языках, людьми в географически разных местах и в итоге стыковаться, собираться в приложение. При этом во многом, если говорить о подходе, связанном с. NET, понятие «компонент» близко понятию «сборка». Ниже будет рассмотрена структура сборки, процесс ее дизассемблирования, перевод из языка Microsoft Intermediate Language – промежуточного ассемблера высокого уровня – в язык программирования, например C#. Будет показано, насколько хорошо это делает. NET, а также как выглядят метаданные сборки – те объекты и системные ресурсы, которые требуются компоненту для существования. Все это находится внутри компонента. Необходимо напомнить еще раз, что компонент – это самодостаточная единица с точки зрения развертывания и встраивания в полномасштабное корпоративное приложение.

Вторая тема, которая будет рассмотрена, – это офисные приложения и их разработка на основе Visual Studio Tools for Microsoft Office, вернее, for Microsoft Office System, потому что Microsoft Office – это с недавних пор также платформа, некий базис, на основе которого можно строить свои приложения. И это достаточно важный аспект корпоративных систем, поскольку современные версии Microsoft Office позволяют вести коллективную работу над документом, визировать документ, вести распределенную работу с общим репозиторием, публиковать изменения в Интернете и т. д. На уровне Microsoft Office 2005 будет рассмотрено, до каких технологий и возможностей развилась эта платформа и какие у нее появились возможности. Следует еще раз подчеркнуть, что рассматриваемые офисные приложения понимаются как надстройка над стандартом Microsoft Office, вернее, даже корпоративной версией Microsoft, который сам по себе уже является платформой для корпоративной работы с документами и создания корпоративных приложений.

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

Будет описано, насколько связаны понятия компонента и сборки, каким образом происходит формирование сборки, как обеспечивается взаимодействие сборок между собой, как обеспечивается безопасность приложений при построении их на основе компонентного подхода в рамках идеологии Microsoft.NET. Будет обсуждаться, каким образом происходит развертывание приложений, построенных из компонентов, как строятся интерфейсы, и, кроме того, будет говориться о различных компонентных моделях, прежде всего о моделях на основе подхода. NET, и моделях, связанных с развитием компонентно-объектной модели, COM-модели. Кроме того, будут обсуждены возможности других компонентных подходов, достаточно раннего подхода CORBA, связанного с брокерами объектных запросов, универсальной шины для взаимодействия между объектами. Будет говориться о подходе, разработанном корпорацией Sun Microsystems, который называется Java Beans, или Enterprise Java Beans, и тоже позволяет строить корпоративные приложения на основе компонентов.

Итак, компонент – это структурная единица прикладной программной системы с четко определенным интерфейсом и способом взаимодействия с другими элементами приложения. При этом компонент, несмотря на то что изолирован, во многом выполняет задачу, характерную только для него, работает в среде и использует ряд ее механизмов. Если говорить о. NET, то среда называется Common Language Runtime – среда времени выполнения. И все зависимости и взаимосвязи компонента с программной средой должны быть полно, четко и недвусмысленно описаны в рамках интерфейса. В целях повторного и многократного применения разумного подхода вполне возможным является использование одного и того же компонента, с небольшими вариациями, в разных ролях, в разных соотношениях относительно других компонентов. Поэтому один компонент может иметь несколько различных интерфейсов, т. е. играть в системе разные роли. Ну скажем, сценарий входа в систему для различных пользователей внешне выглядит похоже, но с точки зрения процедур, действий, которые выполняются при входе в систему, и тех полномочий по доступу, которые открываются после корректного входа, конечно, следует соотносить это общую процедуру входа с ролями пользователей, будь то администратор, привилегированный пользователь, аудитор системы и т. д. Этот интерфейс, его описание, называется интерфейсным контрактом или программным контрактом для компонента. Ранее уже говорилось о контрактах, в частности о контрактах данных, когда обсуждалась технология Windows Communications Foundations, но на самом деле, если говорить о компонентах в принципе, взаимодействие организовано очень похожим образом.

Важно отметить, что для каждой операции компонента имеется набор условий, необходимых для корректного начала его работы и корректного ее завершения или, как говорят, предусловия и постусловия. По сути, компонент, или модуль, можно рассматривать как некоторую процедуру или с математической точки зрения – некоторую функцию, которая имеет, как и всякая функция, область определения, область значения, вход и выход, а также ограничения на диапазон входа и выхода. Здесь, в случае интерфейсного контракта, также имеются предусловия и постусловия, которые описывают возможности его операций. Предусловие операции должно быть выполнено при ее вызове, иначе сложно гарантировать корректность результатов выполнения этого компонента, операций в компоненте. Постусловие обеспечивает сам компонент. Если он корректно отрабатывает, то обеспечивается выполнение истинности постусловия. То есть ответственность за корректность состояния по завершении работы компонента возлагается прежде всего на разработчика этого компонента, конечно, при корректном понимании структуры программной системы. В случае корпоративной системы эта структура довольно сложна. Таким образом, постусловие определяет, какие из ее результатов можно считать корректными. В объектно-ориентированном подходе часто говорится о модулях, т. е. о некоторых самостоятельных единицах программного кода, нацеленного на выполнение одной специфичной операции. Но если говорить о корпоративных системах, модуль понимается более широко – как программная единица, которая решает целый ряд взаимосвязанных задач. Это может быть, например, модуль основных средств, модуль учета и управления и планирования основных средств в рамках корпоративной системы класса ERP, Oracle Business Suit.

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

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

Например, в группе компаний «Итера» в свое время была реализована система хранения изображений, которая использовала те DLL, которые отвечали за распознавание текста и стандартное его сканирование.

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

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

Конечно, в исходной системе необходимо соблюсти интерфейсы с этим компонентом, для этого существуют интерфейсные и программные контракты, а также определенного рода стандарты на изготовление интерфейсов. Уже упоминалось, что в подходе CORBA, связанном с брокерами объектных запросов, интерфейсы описывались на языке, который так и назывался Interface Definition Language (IDL). Это достаточно известный язык. К сожалению, может быть в силу того, что он является достаточно громоздким и не вполне удобным для описания, подход CORBA такого большого распространения не получил. Но в свое время, кстати, не так давно, лет десять назад, это был очень распространенный подход, на котором строились в том числе и корпоративные системы. При этом, что важно, он не зависел от программной платформы. Можно было объединять как решения на основе операционной системы Microsoft, компоненты, которые функционируют в Microsoft Windows, так и компоненты, которые работают под управлением UNIX-систем. Примерно то же можно сказать про Java Beans – этот подход также позволяет применять компонентные приложения, работающие на основе виртуальной Java-машины, которая погружается в среду операционной системы, т. е. реализуется принцип «написано раз – работает везде». Существует возможность портирования Java-кода или промежуточного кода из одной среды в другую благодаря различиям в реализации Java-машины и, наоборот, стандартам реализации языка Java.

Если говорить о модели, которую поддерживает Microsoft, то она называется компонентной или COM-моделью (Component-Object Model). Компоненто-объектной моделью с расширениями или дальнейшим развитием в форме DCOM является динамическая модель COM и COM+. Правила, по которым взаимодействуют компоненты, определяются самой моделью, при этом в компонентную модель входят правила, описывающие жизненный цикл компонента, т. е. последовательность состояний, через которые он проходит в рамках функционирования той или иной системы или той или иной процедуры в этой системе, когда он, например, активен, находится в кэше, т. е. области оперативной памяти, которая дает возможность быстрого обращения к нему при необходимости, или наоборот пассивен, загружен он или не загружен и т. д. И естественно, между этими состояниями существуют переходы, которые также описываются компонентной моделью. И как уже говорилось, компонент – более узкое понятие, чем программный модуль, если говорить о корпоративных системах, которые строятся по модульному принципу, где под модулем понимается блок, реализующий развитую функциональность и выполняющий большое количество элементарных функций, которые как раз и сводятся к классам, а на более высоком уровне – к компонентам. Интересно отметить, что если рассматривать компоненты, например, такие как DLL, единицы развертывания либо некоторые небольшие независимые модули – небольшие элементы, которые можно встраивать в программные системы, можно говорить о сборке программного обеспечения на заказ с включением в него только тех компонентов, которые нужны пользователю, которые для него принципиальны и которые он покупает. Таким образом, компонентную модель интересно рассматривать как модель распространения коммерческого программного обеспечения, когда поставка продукта осуществляется в виде того или иного набора взаимодействующих компонентов, выбранного пользователем.

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

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

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

Если говорить о классе, о компоненте, который реализует функцию, например логическую функцию управления верхнего уровня целым рядом более мелких классов системы, то, наверное, имело бы смысл использовать язык логического программирования типа Prolog или SmallTalk. Или использовать язык функционального программирования типа Lisp, SML и F#. И F# во многом используется в этом качестве. Если говорить о моделировании функций, о математическом моделировании, то вполне можно использовать функциональный язык типа F#. Если говорить, например, о построении графического интерфейса или интерфейса с операционной системой Windows, то, конечно, лучше использовать языки типа C#. То есть языки, с одной стороны, полностью объектно-ориентированные, а с другой – это родной язык. NЕT, он предельно тесно интегрирован с CLR, со средой выполнения и, собственно, с платформой. NET и ее виртуальной машиной. Поэтому языковая интероперабельность является достаточно важным преимуществом с точки зрения больших корпоративных систем и, конечно, с точки зрения учебного процесса, когда на единой программной платформе, на платформе. NET, можно показать, как строятся не только приложение на основе различных подходов к программированию (логического подхода, объектно-ориентированного подхода, функционального подхода и т. д.), но и гетерогенные предложения, которые представляют собой конгломераты или семейства компонентов, разработанных на различных языках программирования. И еще один подход – CORBA, который основан на построении обобщенной объектной шины для взаимодействия гетерогенных объектов на основе брокеров объектных запросов, т. е., по сути, механизма обмена сообщениями между объектами. К сожалению, он сейчас не так широко распространен в связи с достаточно громоздкими интерфейсами языка определения контрактов, средств взаимодействия между компонентами – IDL. И достаточно сложно представить отображение одного языка реализации в другой, поэтому сегодня не так популярен этот подход. Рассмотрим, каким образом строится приложение из компонентов. Существуют два основных уровня (рис. 13.1). Нижний уровень схематически представлен тремя блоками различной формы с отверстиями – это компонентная среда. По сути, речь идет о. NET и CLR, т. е. NET Framework большого количества классов, которые взаимодействуют друг с другом, и компонентах, построенных на основе этих классов, которые тоже имеют контракты, связаны друг с другом и позволяют разворачивать внешние компоненты – надстроечные компоненты прикладного уровня, которые расположены на уровень выше в виде двух больших блоков, подобных кубикам с различного рода шипами или, наоборот, пазами, схематически представляют собой интерфейсы и описываются контрактами. Каждый компонент имеет интерфейс, даже несколько интерфейсов того или иного рода, которые полностью описываются интерфейсными контрактами, программными контрактами и позволяют компонентам осуществлять взаимодействие на основе компонентной модели. То есть эти контракты в полной мере соответствуют компонентной модели, которая применяется.

Рис. 13.1. Основные элементы компонентных приложений

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

Уже говорилось об отличии компонента от модуля. Теперь обсудим взаимосвязь понятий «компонент» и «класс», если говорить об объектно-ориентированных языках. Класс не только определяет набор интерфейсов, которые он реализует, но и, как правило, описывает их реализацию, поскольку он явно содержит код методов, код функций, определяющих его возможности. Контракт компонента представляет собой прежде всего сигнатуру, т. е. описание интерфейсов, но не реализацию, не код на конкретном языке программирования, который выполняет те функции, для которых и создан компонент. То есть интерфейс отделен от реализации, если говорить о компоненте. Класс существует исключительно в связи с тем языком программирования, на котором он написан. Java-класс будет выглядеть одним образом, класс на C# – другим, если говорить об F#, то там тоже можно реализовать подобие класса, которое будет выглядеть иначе, и т. д.

Компонент, если это не ограничивается компонентной моделью, к языку не привязывается, т. е., по сути, компонентная модель является для компонента тем же, чем и язык для класса. И еще одно важное отличие, о котором уже упоминалось, – структурно компонент является более крупной единицей, чем класс. Как правило, при обсуждении компонента, представим себе, например, DLL из FineReader, понимается, что этот компонент реализует достаточно больше количество функций, а каждая функция связана с классом – как правило, одна функция при аккуратной реализации соответствует одному классу. Естественно, она может взаимодействовать с другими классами. Но компонент, как правило, является более крупной единицей, чем класс, и, как уже говорилось, более мелкой единицей, чем модуль.

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

Если говорить о платформе. NET, прежде всего необходимо упоминать операционную систему Windows. Существует проект Mono, который направлен на портирование. NET на UNIX-системы. Но этот проект не получил распространения, его результаты не так широко применимы с прикладной точки зрения, как среда. NET для Microsoft Windows. Под. NET Framework понимается не только библиотека классов Framework Class Library, но и CLR. По сути, это системная инфраструктура среды, в которой выполняются приложения. Она определяет особенности проектирования, функционирования, разработки и выполнения программного кода на платформе. Естественно, Microsoft.NET является платформой, т. е. не просто технология разработки программных систем, не просто совокупность средств разработки, таких как Microsoft Visual Studio, это нечто большее, это среда, в том числе и функционирования приложений, именно корпоративных.

Итак, NET Framework включает CLR и среду, которая определяет порядок взаимодействия классов FCL. При этом существует обобщенная спецификация языков программирования CLS – Common Language Specification, представляющая собой процедуру преобразования кода на каждом из языков программирования, который реализован для платформы. NET во внутренний ассемблер высокого уровня, в некий системный код. Ассемблер именно высокого уровня, потому что будут рассмотрены примеры MSIL-кода, и если читателю приходилось работать с ассемблером для какой-то другой классической платформы, например Intel 8080, 8086 или Z80 для компьютеров Sinclair, или Atari, или Yamaha, в прошлом это было достаточно популярно, то будет видно, что одна инструкция MSIL – это примерно 3–5 инструкций такого стандартного ассемблера.

И еще одно важное понятие – это. NET-приложение, прикладная система, разработанная для выполнения на платформе. NET. Важным ограничением здесь является то, что приложение реализуется, даже если это происходит в рамках компонентного подхода – в виде системы компонентов, только на тех языках программирования, которые поддерживает CLS. Следует заметить, что на самом деле можно разработать транслятор для нового языка программирования и встроить его в. NET. Более того, существует курс, достаточно давно (в начале 2000-х гг.) разработанный для студентов второго курса. Они могли в рамках этого курса за один семестр сделать транслятор для языка программирования для. NET и апробировать его. Это был небольшой язык программирования – подмножество языка C#. Но тем не менее этот пример показывает, что создание и реализация языка программирования для. NET – не такая сложная задача. Большое количество авторских коллективов работает над различными языками. Есть компилятор языка SML, который автор использовал для создания курсов введения в теорию программирования, точнее, той его части, которая посвящена функциональному подходу.

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

Поговорим более подробно о том, какого рода окружение может функционировать и какого рода операции могут выполняться. Естественно, осуществляется преобразование промежуточного языка MSIL в машинный код. Поддерживается доступ к метаданным, это понятие будет рассмотрено чуть позже. Осуществляется поддержка обработки исключительных ситуаций, в том числе и межъязыковых. Существует иерархия исключений, которая находится в пространстве имен System.Exceptions. И все нестандартные ситуации, которые могут возникать в том или ином языке приложения, который реализован для среды. NET, отслеживаются CLR и обрабатываются стандартным образом. Можно также создавать и свои пользовательские исключения и обрабатывать их. CLR позволяет осуществить взаимодействие между как управляемым, так и неуправляемым кодом, включая COM-объекты (более подробно об этом будет говориться в разделе, который связан с офисными приложениями). Поддерживаются сервисные возможности для приложений, для разработки программных систем. При этом независимо от того языка, который реализован для платформы. NET, все сервисные возможности поддерживаются в полной мере. Это и отладка кода, и тестирование, и профилирование, и кодирование, и документирование и т. д.

Если говорить о другом аспекте платформы. NET – FCL, то это объектно-ориентированная библиотека, которая включает описание классов, интерфейсов и внутренней системы типов. NET – Common Type System (CTS). Важно, что интерфейсы этой библиотеки классов могут использовать абсолютно все приложения, написанные для платформы. NET, независимо от языка программирования и конкретики программной архитектуры этих приложений. Естественно, это касается и встроенных типов, таких как целый, булевский, вещественный, символьный и т. д., а также типов, которые представлены в виде классов. Если говорить о платформе. NET, то постулируется принцип – каждая сущность является объектом. Поэтому все стандартные типы являются классовыми структурами. Кроме того, классы FCL могут использовать все классы Windows Forms (ранее говорилось об этом подходе к построению интерактивного пользовательского интерфейса), классы, предназначенные для разработки веб-сервисов и других приложений, основанных, например, на ESP.NET, это веб-формы, в частности. Классы, которые базируются на стандартных протоколах, предназначены для приложений в сервисно-ориентированной архитектуре, например Windows Communication Foundation, которая основана на стандартных протоколах XML, FTP, HTTP, SML и Soid и, естественно, протоколе, который поддерживает сервисно-ориентированную архитектуру. Кроме того, со стандартным. NET Framework взаимодействуют все классы, предназначенные для разработки приложений, в том числе и офисных, приложений, которые работают с базами данных, в том числе на основе технологии. NET, и ряд других классов.

Еще одним важным аспектом, о котором необходимо говорить в связи с компонентными приложениями, являются сборки. Понятие «сборка» во многом аналогично понятию «компонент», если говорить о среде. NET. Для CLR-среды выполнения сборка является нейтральной, независимой от языка программирования, на котором она была написана, будь это родной язык. NET С#, или F#, или какой-то другой язык, важно чтобы обеспечивалось соответствие CLS и CTS, т. е. системе типизации, системе описания языка, которая погружает язык в виртуальную машину. NET. Сборка – это базовый строительный блок приложения на основе. NET Framework, это некая самодостаточная единица или логическая группа одного или нескольких модулей или файлов-ресурсов. При этом модули в составе сборок выполняются под управлением CLR, и сборка может быть самостоятельным приложением, скажем EXE-файлом или динамически подключаемым библиотечным модулем. О DLL-библиотеках уже говорилось, и это тоже формат представления сборки.

Важным понятием является также манифест, или декларация сборки, по сути, это совокупность всех метаданных сборки. То есть служебная информация, которая описывает все ресурсы, необходимые для того, чтобы сборка могла функционировать в среде. NET. Манифест включает все классы и ресурсы, т. е. внешние по отношению к сборке элементы, которые необходимо привлечь, а также те ресурсы, которые экспортируются из сборки наружу, перечисляет зависимости от других сборок, т. е. каким образом сборка функционирует в среде, указывает набор прав, необходимых для корректной работы сборки, цифровую подпись, имя и версию сборки. Приведенная ниже схема (рис. 13.2) иллюстрирует трансляцию и выполнение приложения или сборки, поскольку приложение строится на основе сборок и является совокупностью сборок в среде CLR.

Рис. 13.2. Схема выполнения. NET-приложения в среде CLR

Исходным пунктом является текст, код на одном из языков, который поддерживается CLS и, скажем так, сертифицирован для. NET. Используется стандартный компилятор. NET или внешний компилятор, разработанный для. NET. И происходит трансляция в сборку. Подобная схема уже была рассмотрена, в ней присутствовали фрагменты кода, фрагменты приложений на языках C#, SML, F#, Visual Basic и т. д. В итоге получаются сборки в формате либо DLL, либо EXE. Внутрь этих файлов включены фрагменты кода на MSIL и необходимые метаданные сборки: классы, ресурсы, цифровые подписи, автор, версия и т. д. Далее осуществляется взаимодействие этих метаданных. Загрузчик объединяет их вместе с требуемыми ресурсами из библиотек базовых классов стандартного. NET Framework. Затем JIT компилятор осуществляет финальную трансляцию и сборку этих элементов в среде выполнения и собственно выполнение приложения.

При этом важным понятием является домен приложения, ранее говорилось о доменах в связи с технологией Remoting и другими технологиями, которые осуществляют создание и поддержку распределенных приложений в среде. NET, в частности WCF, веб-сервисы. Речь идет о логическом контейнере сборок, который применяется для осуществления локализации или изоляции приложения внутри процесса. Какие важные свойства доменов нужно запомнить, говоря о компонентных приложениях? Во-первых, что домены изолированы друг от друга. CLR может осуществлять загрузку и выгрузку домена со всеми сборками, которые участвуют в этих доменах. Возможно осуществление дополнительных конфигурационных настроек и надстроек, связанных с обеспечением безопасности, применительно к каждому из доменов. Технологии маршаллинга, о которых уже упоминалось, – это передача данных между границами доменов или процессов. При этом такой обмен данными осуществляется в безопасном режиме. Известно, что существует маршаллинг по имени, по значению, по ссылке. Кроме того, доменная модель поддержана на уровне. NET Framework, существует компонентная модель, в которой основными элементами являются сборки. А если берется более широкая модель COM-объектов, в частности, как это, скажем, происходит при работе с офисными или другими приложениями, что используются внутренние механизмы, которые называются COM InterOP и обеспечивают интероперабельность, взаимодействие. NET-объектов с COM-объектами, по сути, NET-сборок с COM-объектами, и наоборот. При этом не требуется регистрации компонентов в реестре Windows, если речь идет о. NET-приложении.

Что касается видов сборок, выделяются частные и общие, Private и Shared или разделяемые сборки. Если речь идет о частной сборке, то тот набор типов, который в ней описан, может быть использован только приложениями, в состав которых входит эта сборка. Если речь идет о сборках общего доступа, что они могут использоваться любым количеством приложений, не обязательно ограниченным на клиентском компьютере. Ранее говорилось о взаимодействии. NET-компонентов, т. е. по сути – сборок и COM-объектов – более общего класса компонентов. Взаимодействие этих компонентов в среде CLR реализовано на основе механизма оберток или временных оболочек Runtime Callable Wrapper (RCW), который инкапсулирует различия между управляемым и неуправляемым кодом.

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

При вызове COM-клиента. NET-среда CLR создает всего одну оболочку, всего одну обертку, независимо от количества ссылок на объект. Это происходит для того, чтобы все обращения к объекту осуществлялись централизованно, единообразно, только посредством этой оболочки. Кроме того, на основе метаданных создаются вызываемый объект и оболочка или обертка для возврата данных, т. е. для передачи данных обратно от. NET-среды COM-клиенту.

Обертка осуществляет управление сборкой мусора на уровне среды CLR. При этом разработка существенно упрощается, поскольку от программиста не требуется слежение за динамической памятью и своевременное ее освобождение. Содержимое сборки можно посмотреть, запустив программу, которая называется ILDAsm.exe (Intermediate Language Dis Assembler). Это достаточно интересная программа с точки зрения ее функционирования, потому что она является очень мощной и восстанавливает код фактически с точностью до идентификаторов. Если говорить об обычном дизассмеблере, то, как правило, он вместо идентификаторов вставляет какие-то свои, системные переменные, и код достаточно тяжело читать. Если для примера рассмотреть простое консольное приложение на C#, которое выводит единственное сообщение на экран – «Hello World», то видно, что оно имеет очень много идентификаторов. Вот SimpleApp – пространство имен, класс у нас называется Class1 и никак иначе, и использует стандартную функцию WriteLine внутри стандартного метода Main.

Посмотрим, как работает ILDAsm, если его запустить применительно к сборке, которая получена из этого приложения. Восстанавливается весь вид сборки, при этом в MSIL-коде присутствуют все идентификаторы, которые были в C#. Идентификатор Class1: существует вызов стандартной процедуры WriteLine с использованием единственного параметра String, при этом используется пространство имен System, и внутри используется класс Console, его метод WriteLine. Несколько иначе выставляются обозначения, но этот текст очень легко читается, несмотря на то, что это ассемблер. Он загружает строчку в память, вызывает функцию и осуществляет возврат управления из этой процедуры.

На уровень выше используется частный метод, он сохраняет все атрибуты, связанные с доступом, все идентификаторы доступа и представленные в графическом виде метаданные сборки. Это манифест, т. е. метаданные сборки, которые получены из приложения SimpleApp.exe, т. е. из EXE-файла, который, казалось бы, не должен был содержать ничего указывающего на идентификаторы, но восстанавливаются название приложения, имя Class1 и абсолютно все метаданные, все ресурсы.

Кроме того, существует средство Reflection, которое позволяет восстановить по DLL или по EXE-файлу, т. е. по сборке, собственно код. И код, который видно на экране, – фактически наш исходный код, написанный на C#. Если использовать средство Reflection, можно восстановить код из exe-файла фактически в том виде, в котором он был написан автором. Это таит в себе неприятности и опасности, поскольку надо каким-то образом защищать авторское право и код от просмотра. Существует средство, которое называется Obfuscator, или запутыватель. Оно внедряет ряд переходов, разбивает процедуры на более мелкие, в общем меняет структуру кода таким образом, чтобы было сложно, глядя на него, сказать, какой именно метод и из какого именно места программы вызывается. Таким образом, Microsoft борется с возможностью восстановления прямого кода. Но нужно сказать, что Reflection – очень сильное средство, если не защищать код специальным образом.

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

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

 

Глава 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

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

Библиотека классов для. 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-решений, так и для гетерогенных информационных хранилищ. При этом во многих более сложных ситуациях, например при поддержке центров обработки данных, использование подобного подхода оправданно и повышает эффективность.

Что касается потоков данных, попробуем рассмотреть некоторые примеры, в частности применение SSIS для поддержки процессов и работ, которые ориентированы на центры обработки данных. В основе лежит применение конвейерного подхода для преобразования данных. Архитектура конвейера поддерживает буферизацию, что позволяет конвейеру достаточно быстро осуществлять манипуляции над наборами данных после их загрузки в память. При этом суть похода заключается в выполнении всех этапов ETL-преобразований в рамках одной операции без промежуточного хранения. Хотя специфичные требования к преобразованию, операциям или оборудованию могут несколько осложнить реализацию этого подхода, тем не менее для повышения производительности архитектура позволяет в целом минимизировать объем промежуточного хранения данных. SSIS, по возможности, даже избегает копирования данных памяти, что принципиально отличается от традиционных ETL-средств, которые часто требуют промежуточного хранения данных практически на каждом этапе процесса преобразования, обработки, интеграции данных. Такого рода поддержка манипуляций над данными без промежуточного хранения позволяет существенно улучшить ETL-средства, а также дать возможность поддержки хранения и манипулирования с реляционными и плоскими данными. При этом гетерогенные данные, как структурированные, так и неструктурированные, хранящиеся в формате XML и т. д., перед загрузкой в буферы преобразуются в табличную структуру, т. е. разбиваются на строки и столбцы. И далее любую операцию с табличными данными можно выполнять на любой стадии функционирования конвейера поточной обработки данных. Это означает, что единственный конвейер способен интегрировать разнообразные источники данных и выполнять над этими источниками данных операции произвольной степени без промежуточного хранения. Конечно, если промежуточное хранение по эксплуатационным требованиям является необходимым, то SSIS дает возможность поддерживать и такого рода реализации. Эта архитектура позволяет применять SSIS в самых разных сценариях интеграции данных, от традиционных ETL-решений до нетрадиционных способов интеграции гетерогенной корпоративной информации.

SSIS судя по рис. 16.11 дает возможность комплексной полнофункциональной ETL-интеграции, обеспечивая возможности по функциональности, масштабируемости и производительности, существенно более высокие, чем у большинства конкурирующих аналогов, при значительно меньших затратах. Особенность решения составляет конвейерная архитектура, которая дает возможность получать данные из множества источников одновременно, выполнять целый ряд преобразований последовательно и передавать данные нескольким приемникам в параллельном режиме. Такого рода архитектура дает возможность применять SSIS-технологии не только для больших наборов данных, но и для множественных потоков данных. При перемещении данных из источника к приемнику или из нескольких источников к нескольким приемникам можно разделять, объединять, комбинировать потоки данных или иным образом манипулировать информацией. Рисунок 16.11 дает иллюстрацию примера манипулирования потоками данных при таком преобразовании. Рисунок 16.12 иллюстрирует процесс очистки данных.

Рис. 16.11. Схема интеграции данных

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

Рис. 16.12. Очистка данных

Пример использования потока как источника данных, эта важная особенность SSIS, представлен на рис. 16.13.

Имеется возможность загрузки данных в компонент Data Reader ADO.NET. Этот компонент можно включить в конвейер потока данных, что дает возможность использовать Data Reader как источник данных, которые предоставляются собственно ADO.NET. При этом можно использовать SSIS не только как традиционные ETL-инструменты для загрузки, преобразования данных в хранилище, но и как источник данных, который может предоставлять доступ к интегрированным и синхронизированным в очищенные данные источник, причем по запросу пользователя, и делать это даже из офисных приложений. Например, эту функциональность можно задействовать для того, чтобы службы отчетов, Reporting Services, извлекали данные из множества разнообразных источников, в которых хранится информация для корпоративных приложений. При этом SSIS-пакеты используются как источник данных. Для управляемости корпоративных систем на основе SQL Server используются подходы, связанные с политиками, автоматизированным обслуживанием на основе задач, и оповещение операторов и графиков, средства Performance Data Collection, которые позволяют оптимизировать производительность графическим образом, и специальный инструмент для оптимизации индексов таблиц баз данных и разделов, который называется Data Base Engine Tuning Advisor. Осуществляются принципы упреждающего управления, которые обеспечивают: логическое представление конфигурации системы, что позволяет администраторам заблаговременно определять желаемую конфигурацию служб данных, а не вносить изменения после того, как возникнут проблемы; интеллектуальный мониторинг, который поддерживает на основе политик инфраструктуры управление, отслеживание и запрещение изменений, несовместимых с желаемыми конфигурациями; а также виртуализацию управления, которая позволяет масштабировать изменения по инфраструктуре, структуре корпорации, передавать или распределять их по большому количеству серверов, что облегчает применение унифицированных политик во всей организации.

Рис. 16.13. Использование потока как источника данных

Каким образом осуществляется создание конфигурационных политик?

На рис. 16.14 представлен механизм инструментария для создания политик. SQL Server 2008 поддерживает существенно расширенный набор элементов управления конфигурациями и правилами настройки сервера баз данных.

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

Рис. 16.14. Создание политик

Aspect Surface Area позволяет управлять активными функциями и уменьшить потенциальную уязвимость сервера. Aspect Data Base управляет изменением определенных параметров баз данных, например параметров совместимости. Aspect Multipart Name обеспечивает соблюдение правил именования таблиц, представление других объектов баз данных, определенных в схеме. Ряд других аспектов позволяет реализовать приемы и методы работы, рекомендованные для конкретных решений или конфигураций баз данных, например хранение файлов с данными или файлов с журналом изменений на жестких дисках.

Еще один инструмент называется Performance Data Collection и позволяет осуществлять сравнение интегрированных отчетов о функционировании серверов в графическом виде. Он дает возможность быстро проанализировать собранные данные с использованием стабильно работающих системных наборов элементов сбора данных. Системный набор элементов данных сервера, Server Activity, является важной отправной точкой для большинства сценариев, осуществляющих мониторинг по устранению неполадок в системе. Группа отчетов, связанная с каждым из системных наборов данных сбора и набора элементов для сбора данных, публикуется в SQL Server Management Studio. На основе этих отчетов можно сделать приборную панель, которая информирует о производительности. Она так и называется – Performance Dashboard. При помощи этой приборной модели (рис. 16.15) можно анализировать производительность СУБД.

Кроме этих системных отчетов можно использовать другие отчеты Performance Studio о производительности, например, SQL Server Management Studio поддерживает другие отчеты, один из которых представлен на рис. 16.16 – стандартный отчет об использовании памяти. Важным средством работы системных администраторов с сервером в консольном виде на основе MMC (Microsoft Management Console) – стандартной оснастки, представлен на данном рисунке, это SQL Server Configuration Manager. В виде консоли можно осуществлять оптимизацию параметров сервера на основе целого ряда инструментов в жесткие сроки и в привычном интерфейсе. Средства конфигурирования SQL Server позволяют администратору управлять группами служб, ответственных за вверенные им функции. Это дает возможность администраторам сосредоточиться на управлении базами данных и оптимизации их производительности.

Рис. 16.15. Отчет о функционировании сервера

Что касается производительности и масштабируемости, то осуществляется как горизонтальное, так и вертикальное масштабирование. Это важно для крупных корпораций с большим количеством серверов. При горизонтальном масштабировании используется оптимизация мощностей сервера, возможно горячее переподключение или замена оборудования. При вертикальном масштабировании осуществляется обработка на основе использования резервных копий данных. Кроме того, поддерживается одноранговая репликация, маршрутизация данных, а также те возможности, о которых говорилось в связи с Performance Studio. Это крайне важно для больших корпораций с быстрым ростом объемов существенных данных, количества пользователей и для тех организаций, где масштабируемость приложений является бизнес-критичной. SQL Server 2008 предоставляет устойчивый обработчик баз данных, который может работать с большими реляционными базами данных и обеспечивает обработку сложных запросов.

Рис. 16.16. Отчеты SQL Management Studio

Что касается программируемости, то имеется целый ряд средств, которые поддерживают обработку на основе LINQ. Это средство формирования запросов на основе объектных технологий, а также используются все механизмы Visual Studio и SQL Server Compact Edition для работы с мобильными средствами связи. LINQ-ToSQL поддерживает оперативную разработку приложений с интеграцией программных объектов в SQL с элементами SQL, таблицами, представлениями, хранимыми процедурами и пользовательскими функциями. Существует также LINQToEntities, которым осуществляется поставление объектов реляционным таблицам, LINQToDataSet, поддерживаются также богатые возможности запросов на основе обычных и типизированных наборов данных, LINQToXML, это API для доступа к XML-объектам, хранимым в оперативной памяти, поддерживающей. NET языки и LINQToObject, обеспечивает взаимодействие с произвольными объектами данных в оперативной памяти, а также данными из сторонних источников.

Ряд средств осуществляет управление отчетами. Это управляемая система бизнес-отчетности, которая дает возможность автоматизированного создания отчетов по разным аспектам бизнеса и распространения их по всей инфраструктуре корпорации, обеспечивая в реальном времени доступ к информации каждому сотруднику. Автоматизированная система отчетности дает возможность пользователям создавать свои собственные отчеты с достаточно гибкими возможностями по извлечению, преобразованию информации. Также существует встроенная отчетность с интеграцией между бизнес-приложениями и веб-порталами на основе конкретных бизнес-процессов. При этом поддерживается тесная интеграция с SharePoint Server 2007, со средством создания веб-порталов, и централизованная библиотека отчетов на основе компонентов интегрирована с SharePoint.

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

Настройка службы отчетов может выполняться как автоматически, исходя из базовой конфигурации, так и посредством использования конфигурации служб отчетов Reporting Services, диспетчер для которой представлен на рис. 16.17.

Рис. 16.17. SQL Server Confguration Manager

Это существенно упрощает для администраторов выполнение ряда задач, необходимых для развертывания служб отчетов, сокращает затраты рабочего времени и ускоряет получение отчетности. Безопасность включает различные виды аутентификации, расширенное управление авторизацией и использование передовых технологий шифрования. Основные виды аутентификации: базовая аутентификация, хеш-аутентификация, аутентификация посредством сетевого протокола NTLM, аутентификация посредством протокола Kerberos, стандартного протокола для Windows 2000 и выше, и встроенная аутентификация.

Базовая аутентификация описывается протоколом HTTP, хеш-аутентификация дополнительно использует алгоритм MD5 перед отправкой данных на сервер, с возможностью подключения удостоверений. Аутентификация по методу NTLM использует протокол запрос-ответ и дает возможность обеспечить безопасную аутентификацию с учетом указания допустимой доменной учетной записи. Аутентификация Kerberos использует специализированный протокол, и необходима регистрация в Kerberos Services Principle Name с помощью специальной утилиты Set SPN, которая входит в набор базового инструментария. Встроенная аутентификация, или Integrated Autentification, объединяет NTLM и Kerberos и по запросу пользователя осуществляет выбор того или иного механизма аутентификации, что обеспечивает наиболее гибкую и безопасную аутентификацию из поддерживаемых возможностей.

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

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

Рис. 16.18. Пространственный индекс

На основе такого рода подхода можно задавать интеграцию с моделью Virtual Earth, это аналог Goolge Earth от Microsoft. На рис. 16.19 показаны районы, которые задаются почтовым индексом, и данные о населении и числе ресторанов на данном фрагменте географической карты.

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

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

Рис. 16.19. Интеграция с Virtual Earth

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

Были рассмотрены вопросы, связанные с программными архитектурами, CASE-средствами, т. е. средствами автоматизации проектирования корпоративных приложений, и архитектурами взаимодействия этих приложений в распределенных средах. Естественно, для проектирования таких сложных и больших систем, как корпоративная, необходимы специализированные средства, поддерживающие весь их жизненный цикл, от анализа и проектирования до управления сопровождением и документированием. Для иллюстрации корпоративных приложений была использована платформа Microsoft.NET, которая поддерживает языковую интероперабельность, т. е. проектирование компонентных приложений на различных языках программирования, наиболее полно соответствующих требованиям, которые выдвигаются для этих приложений. Надстройкой над классами, поскольку речь идет об объектно-ориентированном проектировании, о компонентно-ориентированном проектировании, постулируется, что всякая сущность есть объект, является целый ряд библиотек, в частности поддерживающих формы доступа к данным, клиентские интерфейсы, например на основе технологии Windows Forms, и проектирование распределенных приложений на основе технологии Remoting, внутренней технологии Microsoft, и более-менее открытых технологий на основе сервисов, сервисно-ориентированной архитектуры, это SOA. Это веб-сервисы и приложения, реализованные на основе Windows Communication Foundation (WCF).

Развитием объектного подхода является компонентно-ориентированная технология, которая дает возможность проектирования и реализации корпоративных приложений на основе открытых интерфейсов и концепции сборок, когда приложения могут поставляться на основе DLL– или EXE-файлов, которые независимы и могут надежно и безопасно интегрироваться друг с другом по запросу, и пользователь оплачивает только стоимость тех компонентов, которые его интересуют. На основе этих компонентов осуществляется построение офисных приложений – была рассмотрена библиотека Visual Studio Tools for Office и корпоративных приложений – библиотека Enterprise Library, которая осуществляет извлечение, преобразование и загрузку данных и интеграцию гетерогенных источников, что позволяет осуществить эффективное, надежное, безопасное и эргономичное манипулирование данными в корпоративных системах.