Предпосылки появления технологии компонентного программирования.

Технологии программирования

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

классов без перекомпиляции использующих их приложений.

Здесь стоит отметить, что роль интерфейсов в COM значительно более важная, чем роль посредника. Все в COM начинается с интерфейсов. Они определяются первыми и задают семантику некоторого сервиса. Различные классы могут реализовывать заданный интерфейс, обеспечивая тем самым полиморфизм на новом уровне.

Имеются различные технологии, реализующие парадигму компонентного программирования. Среди них COM (DCOM, COM+), CORBA, .Net.

Таким образом, обеспечивается выполнение двух важных принципов компонентного программирования:

􀁺 независимость от языка программирования,

􀁺 прозрачность местоположения сервера для клиента.

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

􀁺 Инкапсуляция

В COM инкапсуляция находится на более высоком уровне чем в ООП. Между клиентом и реализацией класса находятся интерфейсы. Интерфейс - абстрактный базовый класс, который не имеет элементов данных и который является прямым

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

При соблюдении данных ограничений различные компиляторы генерируют эквивалентный код для вызовов методов

интерфейса со стороны клиента. Клиент без перекомпиляции может вызывать методы новой версии класса (при сохранении

интерфейса). Новая версия может иметь расширенную функциональность за счет добавления новых интерфейсов. Эти

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

интерфейсами, не зная о существовании новых.

􀁺 Наследование интерфейсов

В отличие от ООП, технология компонентного программирования не поддерживает наследование реализации класса.

Наследуются только интерфейсы. Каждый интерфейс получает свой уникальный идентификатор и может реализовываться в

различных классах, включаемых в различные компоненты. Новый интерфейс может наследовать ранее описанным

интерфейсам. Например, в COM, любой интерфейс должен наследовать стандартному интерфейсу IUnknown. Наследование

интерфейса в частности означает, что при реализации методов нового интерфейса будут реализованы и все методы,

описанные в наследуемом интерфейсе.

Предпосылки появления технологии компонентного программирования.

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

Проблема взаимодействия приложений Windows имеет две стороны: взаимодействие на одном компьютере и в сети Intranet или Internet. Взаимодействие приложений, размещенных на удаленных компьютерах, обеспечивается технологией DCOM (Distributed COM – распределенная модель компонентных объектов), а также и технологией COM.

Технология COM

COM (англ. Component Object Model — объектная модель компонентов;) — это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих компонентов, каждый из которых может использоваться во многих программах одновременно. Стандарт воплощает в себе идеи полиморфизма и инкапсуляции объектно-ориентированного программирования. Стандарт COM мог бы быть универсальным и платформо-независимым, но закрепился в основном на операционных системах семейства Microsoft Windows. В современных версиях Windows COM используется очень широко. На основе COM были реализованы технологии: Microsoft OLE Automation, ActiveX, DCOM, COM+, DirectX, а также XPCOM.

Основным понятием, которым оперирует стандарт COM, является COM-компонент. Программы, построенные на стандарте COM, фактически не являются автономными программами, а представляют собой набор взаимодействующих между собой COM-компонентов. Каждый компонент имеет уникальный идентификатор (GUID) и может одновременно использоваться многими программами. Компонент взаимодействует с другими программами через COM-интерфейсы — наборы абстрактных функций и свойств. Каждый COM-компонент должен, как минимум, поддерживать стандартный интерфейс «IUnknown», который предоставляет базовые средства для работы с компонентом. Интерфейс «IUnknown» включает в себя три метода: QueryInterface, AddRef, Release.

CORBA

CORBA - это аббревиатура от названия Common Object Request Broker Architecture, что на русский язык переводится как "общая архитектура брокера объектных запросов". Разработана эта технология с целью обеспечения объектно-ориентированной коммуникации между частями одного приложения так, как если бы они не были распределены.

Суть CORBA состоит в следующем: каждый компонент распределённого приложения имеет доступ к открытым методам других компонентов, которые он может вызывать на выполнение. О том, какие есть методы, он узнаёт с помощью интерфейсов, описание которых осуществляется на специальном языке IDL - Interface Definition Language.

Понятие сборки в .NET

В платформе .NET появилось новое понятие - сборка (assembly). В первом приближении сборку можно воспринимать как аналог EXE или DLL; более того, в случае приложения, состоящего из одного файла, сборка даже имеет расширение .exe или .dll. Несмотря на это сходство, сборка содержит существенно больше информации о приложении, чем традиционные исполняемые файлы.

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

С точки зрения структуры любая сборка .NET (* . dll или * . ехе) включает в себя следующие элементы.

• заголовок файла Windows;

• заголовок файла CLR;

• CIL-код;

• метаданные типов;

• манифест сборки;

• дополнительные встроенные ресурсы.

Приватные сборки.

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

Идентификационные данные приватной сборки включают дружественное имя и

номер версии, которые фиксируются в манифесте сборки. Дружественным называется имя

модуля, в котором содержится манифест сборки, без файлового расширения. Например,

заглянув в манифест сборки CarLibrary. dll, там можно будет обнаружить следующее:

.assembly CarLibrary

{

.ver 1:0:0:0

}

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

Процесс зондирования.

Исполняющая среда .NET определяет местонахождение приватной сборки с применением так называемой технологии зондирования.

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

Явный запрос осуществляется программно за счет применения метода Load () или

LoadFromO (оба являются членами класса System.Reflection.Assembly) и обычно

предназначен для выполнения позднего связывания или динамического вызова членов

интересующего типа

Разделяемые сборки.

Подобно приватной сборке, любая разделяемая сборка представляет собой коллекцию

типов и (необязательно) ресурсов. Самое очевидное отличие между разделяемой и приватной сборкой состоит в том, что одна копия разделяемой сборки может использоваться сразу в нескольких приложениях на одной и той же машине.

Как не трудно догадаться, разделяемые сборки не развертываются внутри того же

самого каталога, что и приложения, в которых они должны использоваться. Вместо

этого они устанавливаются в так называемом глобальном кэше сборок (Global Assembly

Cache — GAC). Этот кэш размещен в каталоге Windows внутри подкаталога под

названием Assembly – курсивом скорее всего как пример, я и сам не понял.

Понятие GAC.

Манифест сборки.

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

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

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

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

Уникальность сборки

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

Управление версиями сборок.

Версия сборки задается атрибутом AssemblyVersion. Номер версии физически состоит из 4х частей – чисел разделенных точками:

<старший номер версии>.<младший номер версии>.<номер сборки>.<ревизия>

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

[assembly:AssemblyVersion(«1.0.*»)]

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

Можно использовать номера версий с автоматическим увеличением или задавать их в сборочном процессе вручную.

Политика издателя.

Технологии программирования

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

классов без перекомпиляции использующих их приложений.

Здесь стоит отметить, что роль интерфейсов в COM значительно более важная, чем роль посредника. Все в COM начинается с интерфейсов. Они определяются первыми и задают семантику некоторого сервиса. Различные классы могут реализовывать заданный интерфейс, обеспечивая тем самым полиморфизм на новом уровне.

Имеются различные технологии, реализующие парадигму компонентного программирования. Среди них COM (DCOM, COM+), CORBA, .Net.

Таким образом, обеспечивается выполнение двух важных принципов компонентного программирования:

􀁺 независимость от языка программирования,

􀁺 прозрачность местоположения сервера для клиента.

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

􀁺 Инкапсуляция

В COM инкапсуляция находится на более высоком уровне чем в ООП. Между клиентом и реализацией класса находятся интерфейсы. Интерфейс - абстрактный базовый класс, который не имеет элементов данных и который является прямым

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

При соблюдении данных ограничений различные компиляторы генерируют эквивалентный код для вызовов методов

интерфейса со стороны клиента. Клиент без перекомпиляции может вызывать методы новой версии класса (при сохранении

интерфейса). Новая версия может иметь расширенную функциональность за счет добавления новых интерфейсов. Эти

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

интерфейсами, не зная о существовании новых.

􀁺 Наследование интерфейсов

В отличие от ООП, технология компонентного программирования не поддерживает наследование реализации класса.

Наследуются только интерфейсы. Каждый интерфейс получает свой уникальный идентификатор и может реализовываться в

различных классах, включаемых в различные компоненты. Новый интерфейс может наследовать ранее описанным

интерфейсам. Например, в COM, любой интерфейс должен наследовать стандартному интерфейсу IUnknown. Наследование

интерфейса в частности означает, что при реализации методов нового интерфейса будут реализованы и все методы,

описанные в наследуемом интерфейсе.

Предпосылки появления технологии компонентного программирования.

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

Проблема взаимодействия приложений Windows имеет две стороны: взаимодействие на одном компьютере и в сети Intranet или Internet. Взаимодействие приложений, размещенных на удаленных компьютерах, обеспечивается технологией DCOM (Distributed COM – распределенная модель компонентных объектов), а также и технологией COM.