Lecture12 (1133569), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

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

Примерыизвестных компонентных сред — различные реализации J2EE, .NET, CORBA. Сами по себеJ2EE, .NET и CORBA являются спецификациями компонентных моделей и набора базовыхслужб, которые должны поддерживаться их реализациями.Компоненты, которые работают в компонентных средах, по-разному реализующих одну иту же компонентную модель и одни и те же спецификации базовых служб, должны быть всостоянии свободно взаимодействовать.

На практике этого, к сожалению, не всегда удаетсядостичь, но любое препятствие к такому взаимодействию рассматривается как серьезная,подлежащая скорейшему разрешению проблема.Соотношение между компонентами, их интерфейсами, компонентной моделью икомпонентной средой можно изобразить так, как это сделано на Рис. 65.•Компоненты отличаются от классов объектно-ориентированных языков.o Класс определяет не только набор реализуемых интерфейсов, но и саму их реализацию,поскольку он содержит код определяемых операций. Контракт компонента, чаще всего,не фиксирует реализацию его интерфейсов.o Класс написан на определенном языке программирования. Компонент же не привязан копределенному языку, если, конечно, его компонентная модель этого не требует, —компонентная модель является для компонентов тем же, чем для классов является языкпрограммирования.o Обычно компонент является более крупной структурной единицей, чем класс.Реализация компонента часто состоит из нескольких тесно связанных друг с другомклассов.КомпонентыПредоставляют илитребуют интерфейсыСоответствуюткомпонентной моделиРазвертываются вкомпонентной средеИнтерфейсыПредоставляемыекомпонентамиОписываютсяконтрактамиИнтерфейсТребуемыйкомпонентомОписываетсяконтрактомБазовые службыКомпонентная модельОпределяет требования кработающим в ее рамкахкомпонентам, видыкомпонентовИногда требует реализоватьопределенные интерфейсыКомпонентная средаВ ней развертываютсякомпонентыПредоставляеткомпонентную модель инабор базовых службОбеспечиваютработоспособностьнабора компонентовРисунок 65.

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

Компоненты, хотя и не являются законченными продуктами,могут разрабатываться и продаваться отдельно, если они следуют правилам определеннойкомпонентной модели и реализуют достаточно важные для покупателей функции, которыете хотели бы иметь в рамках своей программной системы.Надо отметить, что, хотя рынок ПО существует достаточно давно, а компонентныетехнологии разрабатываются уже около 20 лет, рынок компонентов развивается довольномедленно. Поставщиками компонентов становятся лишь отдельные компании, тесносвязанные с разработчиками конкретных компонентных сред, а не широкое сообществоиндивидуальных и корпоративных разработчиков, как это представляли себе создателикомпонентных технологий при их зарождении.По-видимому, один из основных факторов, мешающих развитию этого рынка, — это«гонка технологий» между поставщиками основных компонентных сред.

Ее следствиемявляется отсутствие стабильности в их развитии. Новые версии появляются слишком часто,и достаточно часто при выходе новых версий изменяются элементы компонентной модели.Так что при разработке компонентов для следующей версии приходится следовать уженесколько другим правилам, а старые компоненты с трудом могут быть переиспользованы.Общие принципы построения распределенных системВ дальнейшем мы будем рассматривать компонентные технологии в связи с разработкойраспределенных программных систем. Прежде чем углубляться в их изучение, полезноразобраться в общих принципах построения таких систем, без привязки к компонентномуподходу. Тогда многие из решений, применяемых в рамках таких технологий, становятся гораздоболее понятными.Построение распределенных систем высокого качества является одной из наиболее сложныхзадач разработки ПО. Технологии типа J2EE и .NET создаются как раз для того, чтобы сделатьразработку широко встречающихся видов распределенных систем — так называемых бизнесприложений, поддерживающих решение бизнес-задач некоторой организации, — достаточнопростой и доступной практически любому программисту.

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

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

Кроме того, прозрачностьсистемы и ее производительность обычно находятся в обратной зависимости — например,при попытке преодолеть отказы в соединении с сервером большинство Web-браузеровпытается установить это соединение несколько раз, а для пользователя это выглядит каксильно замедленная реакция системы на его действия.• Открытость (openness).Открытость системы определяется как полнота и ясность описания интерфейсов работы сней и служб, которые она предоставляет через эти интерфейсы.

Такое описание должновключать в себя все, что необходимо знать для того, чтобы пользоваться этими службами,независимо от реализации данной системы и платформы, на которой она развернута. Одиниз основных элементов описания службы — ее контракт.Открытость системы важна как для обеспечения ее переносимости, так и для облегченияиспользования системы и возможности построения других систем на ее основе.Распределенные системы обычно строятся с использованием служб, предоставляемыхдругими системами, и в то же время сами часто являются составными элементами илипоставщиками служб для других систем.••Именно поэтому использование компонентных технологий при разработке практическиполезного распределенного ПО неизбежно.Масштабируемость (scalability).Масштабируемость системы — это зависимость изменения ее характеристик от количестваее пользователей и подключенных ресурсов, а также от степени географическойраспределенности системы.

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

Дляфункциональности же, опять, чем быстрее растет число доступных функций при ростечисла вовлеченных в систему элементов, тем лучше.Большую роль играет административная масштабируемость системы — зависимостьудобства работы с ней от числа административно независимых организаций, вовлеченных вее обслуживание.При реализации очень больших систем (поддерживающих работу тысяч и болеепользователей, включающих сотни и более машин) хорошая масштабируемость можетбыть достигнута только с помощью децентрализации основных служб системы иуправляющих ею алгоритмов. Вариантами такого подхода являются следующие.o Децентрализация обработки запросов за счет использования для этого несколькихмашин.o Децентрализация данных за счет использования нескольких хранилищ данных илинескольких копий одного хранилища.o Децентрализация алгоритмов работы за счет использования для алгоритмов:ƒ не требующих полной информации о состоянии системы;ƒ способных продолжать работу при сбое одного или нескольких ресурсов системы;ƒ не предполагающих единого хода времени на всех машинах, входящих в систему.o Использование, где это возможно, асинхронной связи — передачи сообщений безприостановки работы до прихода ответа.o Использование комбинированных систем организации взаимодействия, основанных наследующих схемах.ƒ Иерархическая организация систем, хорошо масштабирующая задачи поискаинформации и ресурсов.ƒ Репликация — построение копий данных и их распределение по системе длябалансировки нагрузки на разные ее элементы.

Характеристики

Список файлов лекций