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

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