В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 59
Текст из файла (страница 59)
Он может быть присоединен костальной системе, когда она уже некоторое время работает, и должен после этоговыполнять все свои функции, если в исходной системе уже были все компоненты, откоторых он зависит. Он может быть удален из нее. Естественно, после этого могутперестать работать те компоненты, которые зависят от него. Он может быть встроен впрограммные продукты третьих партий и распространяться вместе с ними. В то же времяникакая его часть не обладает этими свойствами.В идеале такой компонент может быть добавлен или полностью замещен другойреализацией тех же интерфейсов прямо в ходе работы системы, без ее остановки. Хотя и невсе разновидности компонентов обладают этим свойством, его наличие признается крайнежелательным.Все это означает, что такой компонент должен быть работоспособен в любой среде, гдеимеются необходимые для его работы другие компоненты.
Это требует наличияопределенной инфраструктуры, которая позволяет компонентам находить друг друга ивзаимодействовать по определенным правилам.Набор правил определения интерфейсов компонентов и их реализаций, а также правил, покоторым компоненты работают в системе и взаимодействуют друг с другом, принятообъединять под именем компонентной модели (component model) [2]. В компонентнуюмодель входят правила, регламентирующие жизненный цикл компонента, т.е. то, черезкакие состояния он проходит при своем существовании в рамках некоторой системы(незагружен, загружен и пассивен, активен, находится в кэше и пр.) и как выполняютсяпереходы между этими состояниями.Существуют несколько компонентных моделей.
Правильно взаимодействовать друг сдругом могут только компоненты, построенные в рамках одной модели, посколькукомпонентная модель определяет «язык», на котором компоненты могут общаться друг сдругом.Помимо компонентной модели, для работы компонентов необходим некоторый наборбазовых служб (basic services). Например, компоненты должны уметь находить друг другав среде, которая, возможно, распределена на несколько машин. Компоненты должны уметьпередавать друг другу данные, опять же, может быть, при помощи сетевыхвзаимодействий, но реализации отдельных компонентов сами по себе не должны зависетьот вида используемой связи и от расположения их партнеров по взаимодействию. Набортаких базовых, необходимых для функционирования большинства компонентов служб,вместе с поддерживаемой с их помощью компонентной моделью называетсякомпонентной средой (или компонентным каркасом, component framework).
Примерыизвестных компонентных сред — различные реализации J2EE, .NET, CORBA. Сами по себеJ2EE, .NET и CORBA являются спецификациями компонентных моделей и набора базовыхслужб, которые должны поддерживаться их реализациями.Компоненты, которые работают в компонентных средах, по-разному реализующих одну иту же компонентную модель и одни и те же спецификации базовых служб, должны быть всостоянии свободно взаимодействовать. На практике этого, к сожалению, не всегда удаетсядостичь, но любое препятствие к такому взаимодействию рассматривается как серьезная,подлежащая скорейшему разрешению проблема.Соотношение между компонентами, их интерфейсами, компонентной моделью икомпонентной средой можно изобразить так, как это сделано на Рис.
65.Компоненты отличаются от классов объектно-ориентированных языков.o Класс определяет не только набор реализуемых интерфейсов, но и саму их реализацию,поскольку он содержит код определяемых операций. Контракт компонента, чаще всего,не фиксирует реализацию его интерфейсов.o Класс написан на определенном языке программирования.
Компонент же не привязан копределенному языку, если, конечно, его компонентная модель этого не требует, —компонентная модель является для компонентов тем же, чем для классов является языкпрограммирования.212o Обычно компонент является более крупной структурной единицей, чем класс.Реализация компонента часто состоит из нескольких тесно связанных друг с другомклассов.КомпонентыПредоставляют илитребуют интерфейсыСоответствуюткомпонентной моделиРазвертываются вкомпонентной средеИнтерфейсыПредоставляемыекомпонентамиОписываютсяконтрактамиИнтерфейсТребуемыйкомпонентомОписываетсяконтрактомБазовые службыКомпонентная модельОпределяет требования кработающим в ее рамкахкомпонентам, видыкомпонентовИногда требует реализоватьопределенные интерфейсыКомпонентная средаВ ней развертываютсякомпонентыПредоставляеткомпонентную модель инабор базовых службОбеспечиваютработоспособностьнабора компонентовРисунок 65.
Основные элементы компонентного программного обеспечения.••Понятие компонента является более узким, чем понятие программного модуля. Основноесодержание понятия модуля — наличие четко описанного интерфейса между ним иокружением. Понятие компонента добавляет атомарность развертывания, а такжевозможность поставки или удаления компонента отдельно от всей остальной системы.Возможность включения и исключения компонента из системы делает его отдельнымэлементом продаваемого ПО. Компоненты, хотя и не являются законченными продуктами,могут разрабатываться и продаваться отдельно, если они следуют правилам определеннойкомпонентной модели и реализуют достаточно важные для покупателей функции, которыете хотели бы иметь в рамках своей программной системы.Надо отметить, что, хотя рынок ПО существует достаточно давно, а компонентныетехнологии разрабатываются уже около 20 лет, рынок компонентов развивается довольномедленно.
Поставщиками компонентов становятся лишь отдельные компании, тесносвязанные с разработчиками конкретных компонентных сред, а не широкое сообществоиндивидуальных и корпоративных разработчиков, как это представляли себе создателикомпонентных технологий при их зарождении.По-видимому, один из основных факторов, мешающих развитию этого рынка, — это«гонка технологий» между поставщиками основных компонентных сред. Ее следствиемявляется отсутствие стабильности в их развитии. Новые версии появляются слишком часто,и достаточно часто при выходе новых версий изменяются элементы компонентной модели.Так что при разработке компонентов для следующей версии приходится следовать уженесколько другим правилам, а старые компоненты с трудом могут быть переиспользованы.213Общие принципы построения распределенных системВ дальнейшем мы будем рассматривать компонентные технологии в связи с разработкойраспределенных программных систем.
Прежде чем углубляться в их изучение, полезноразобраться в общих принципах построения таких систем, без привязки к компонентномуподходу. Тогда многие из решений, применяемых в рамках таких технологий, становятся гораздоболее понятными.Построение распределенных систем высокого качества является одной из наиболее сложныхзадач разработки ПО. Технологии типа J2EE и .NET создаются как раз для того, чтобы сделатьразработку широко встречающихся видов распределенных систем — так называемых бизнесприложений, поддерживающих решение бизнес-задач некоторой организации, — достаточнопростой и доступной практически любому программисту. Основная задача, которую пытаютсярешить с помощью распределенных систем — обеспечение максимально простого доступа квозможно большему количеству ресурсов как можно большему числу пользователей.
Наиболееважными свойствами такой системы являются прозрачность, открытость, масштабируемость ибезопасность.• Прозрачность (transparency).Прозрачностью называется способность системы скрыть от пользователя физическоераспределение ресурсов, а также аспекты их перераспределения и перемещения междуразличными машинами в ходе работы, репликацию (т.е. дублирование) ресурсов,трудности, возникающие при одновременной работе нескольких пользователей с однимресурсом, ошибки при доступе к ресурсам и в работе самих ресурсов.Технология разработки распределенного ПО тоже может обладать прозрачностьюнастолько, насколько она позволяет разработчику забыть о том, что создаваемая системараспределена, и насколько легко в ходе разработки можно отделить аспекты построениясистемы, связанные с ее распределенностью, от решения задач предметной области илибизнеса, в рамках которых системе предстоит работать.Степень прозрачности может быть различной, поскольку скрывать все эффекты,возникающие при работе распределенной системы, неразумно.
Кроме того, прозрачностьсистемы и ее производительность обычно находятся в обратной зависимости — например,при попытке преодолеть отказы в соединении с сервером большинство Web-браузеровпытается установить это соединение несколько раз, а для пользователя это выглядит каксильно замедленная реакция системы на его действия.• Открытость (openness).Открытость системы определяется как полнота и ясность описания интерфейсов работы сней и служб, которые она предоставляет через эти интерфейсы.
Такое описание должновключать в себя все, что необходимо знать для того, чтобы пользоваться этими службами,независимо от реализации данной системы и платформы, на которой она развернута. Одиниз основных элементов описания службы — ее контракт.Открытость системы важна как для обеспечения ее переносимости, так и для облегченияиспользования системы и возможности построения других систем на ее основе.Распределенные системы обычно строятся с использованием служб, предоставляемыхдругими системами, и в то же время сами часто являются составными элементами илипоставщиками служб для других систем.Именно поэтому использование компонентных технологий при разработке практическиполезного распределенного ПО неизбежно.• Масштабируемость (scalability).Масштабируемость системы — это зависимость изменения ее характеристик от количестваее пользователей и подключенных ресурсов, а также от степени географическойраспределенности системы.
В число значимых характеристик при этом попадаютфункциональность, производительность, стоимость, трудозатраты на разработку, навнесение изменений, на сопровождение, на администрирование, удобство работы ссистемой. Для некоторых из них наилучшая возможная масштабируемость обеспечиваетсялинейной зависимостью, для других хорошая масштабируемость означает, что показатель214•не меняется вообще при изменении масштабов системы или изменяется незначительно.Система хорошо масштабируема по производительности, если параметры задач, решаемыхею за одно и то же время, можно увеличивать достаточно быстро (лучше — линейно илиеще быстрее, но это возможно не для всех задач) при возрастании количества имеющихсяресурсов, в частности, отдельных машин.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
