Преимущества использования компонентной архитектуры:

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

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

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

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

24/////////////////////////////////////////////24////////////////////////////////////////////////////////////////////24///////////////////////////////////////////////////////////////////////////////////24

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

Программа или компонент, использующие другой компонент, называются клиентом (client). Клиент подсоединяется к компоненту через интерфейс (interface).

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

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

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

25////////////////////////////////////////////////////////////////////////////25//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////25

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

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

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

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

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

Ответы на 22/23/24/25

26/////////////////////////////////////////////////////26//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////26///////////////////26

В начале 90-х годов минувшего века фирмой Microsoft была предложена технология OLE 1.0 (Object Linking and Embedding - связывание и внедрение объектов). В основу OLE 1.0 были положены механизмы динамического обмена данными (DDE). Она основывалась на концепции составных документов (compound documents). С точки зрения пользователя, такой документ выглядит единым набором информации, но фактически содержит элементы (фрагменты) более чем одного типа (т. е. созданные разными приложениями, например, текст и графику). Эта технология фактически предложила документно-ориентированную модель работы с компьютером - "пользователь должен больше думать об информации и меньше - о приложениях, ее обрабатывающих". Технология изначально разрабатывалась как средство интеграции приложений пакета MS Office, обеспечивающее взаимодействие между его компонентами (Excel, Word, Power Point и т.п.) [ ].

Как и в большинстве случаев, первая версия OLE не была совершенна. И в следующей версии OLE претерпела глобальные изменения. Разработчиками была создана группа технологий, область применения которых выходила за рамки составных документов. Основой этих технологий стала COM - Component Object Model (модель компонентных объектов). На этом фундаменте была построена более совершенная версия продукта - OLE2, появившаяся в мае 1993 года.

OLE2 объявила новый стандарт, который позволил создавать не только составные документы, но и регламентировать общие правила взаимодействия любых типов программ. Отныне все новые технологии, основанные на COM, получили общее название – OLE - Microsoft более не рассматривала данный термин как аббревиатуру, также было решено опустить номер версии. Однако, в дальнейшем, начиная с операционной системы Windows 95 (и старше), технология COM стала базовой технологией Windows, которую, сегодня можно рассматривать как систему, состоящую из нескольких тысяч "кирпичиков" – COM-объектов. Причем, эти COM-объекты доступны не только средствам операционной системы, но и любым другим программным средствам, поддерживающим стандарт OLE2. Для корпоративной ОС Windows NT в 1996 году Microsoft разработала распределенную СОМ (Distributed СОМ - DCOM), которая позволяла клиенту создавать и использовать объекты, как на удаленных системах, так и на локальной. Более того, клиент может даже не осознавать различия между этими двумя случаями. С появлением Internet, технология COM нашла свою нишу и здесь под именем ActiveX [12] (одно время эту технологию называли OLE3). Постепенно ActiveX стала отвоевывать пространства исконно занятые OLE, и сегодня все вернулось на круги своя - термин OLE относится только к технологии создания составных документов, и применяется, в основном, при автоматизации и интеграции компонентов пакета MS Office. а на основе технологии COM, помимо OLE и ActiveX, создан ряд других технологий – DirectX, Microsoft Agent и т. п.

технология СОМ+ появилась в конце 1998 года, и, представляет собой дальнейшее развитие компанией Microsoft новой генерации технологии СОМ для корпоративной ОС Windows 2000. Ее можно рассматривать как дальнейшее развитие DCOM, предоставляющее множество новых возможностей, включая управление объектами во время выполнения и основанный на языках программирования инструментарий.

В настоящее время фирмой Microsoft активно внедряется кросплатформенная архитектура .net. Поскольку технология СОМ ориентирована на работу в среде Windows, то первоначально казалось, что при таком подходе фирма вынуждена будет отказаться от поддержки этой технологии. Однако Microsoft выпустила специальный документ, разъясняющий, что .NET Framework основывается на тех же базовых компонентных сервисах, что и COM+: транзакции, очереди, пулы объектов. Естественно, что существующие ныне возможности технологии COM+ будут при этом существенно расширены. При этом в .NET сохранится возможность использования COM-объектов в "старом стиле". Причем во многих случаях, можно выполнить преобразование из объекта COM в .NET и обратно.

27////////////////////////////////////////////////////////////////////////////27/////////////////////////////////////////////////////////////////////////////////////////27////////////////////////////////////////////27