Текст книги "Основы проектирования корпоративных систем"

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