5. Заключение

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

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

Зависимость от J2EE, с одной стороны, стимулировала развитие коммерче­ских задач Inmedius, а с другой — обусловила необходимость в принятии допол­нительных проектных решений, связанных с пакетированием в виде тех или иных типов beans. В этом мы усматриваем пример обратного воздействия архитектур­но-экономического цикла, акцентирующего переход от единичных решений к уни­версальным решениям.

5. Дополнительная литература

Читателям, желающим подробнее изучить переносные компьютеры, мы рекомен­дуем ознакомиться с изданием [Barfield 01] и сдокладами на организуемом Институтом программной инженерии (SEI) ежегодном Международном симпозиу­ме по переносным компьютерам (http://iswc.gatech.edu/).

Описание применяемого в архитектуре Luther образца «бизнес-делегат» со­держится n работе [Alur 01]. О деятельности группы rio технологическому управ­лению (Workflow Management Coalition) можно узнать на сайте этой организа­ции по адресу http://www.wfmc.org

5. Дискуссионные вопросы

   0. 1. В большинстве рассматриваемых в этой книге конкретных примеров архи­тектура предусматривает отделение производителей данных в системе от их потребителей. Почему это так важно? Что можно сказать об этой такти­ке? Составьте список тактик или методик проектирования, с помощью ко­торых осуществляется такое разделение; начните с тех, что упоминаются в настоящей главе.

   1. 2. В архитектуре Luther и в других конкретных примерах серьезное внимание уделяется отделению пользовательского интерфейса от остальных элемен­тов приложения. С чем, по вашему мнению, связана чрезвычайная распро­страненность этой тактики?

Глава 18

Конструирование систем из коробочных компонентов

(в соавторстве с Робертом С. Сикордом и Мэтью Бассом)¹⁰

На блюде все это смотрится так красиво — чьи-то пальчики основательно потрудились!

Джулия Чайлд о повой французской кухне

Мы постоянно делаем упор на связь между требованиями по качеству и архитек­турой. Утверждение это основывается на допущении о том, что контроль над проектным решением системы подразумевает контроль над реализуемыми ею атрибутами качества. Чем дальше, тем больше оно опровергается реальной прак­тикой. Готовые компоненты для конструирования систем со временем получают широкое распространение — связано это с экономическими соображениями, а так­же с тем, что во многих технических областях для разработки приложений требу­ются крайне специализированные знания. Компоненты, с одной стороны, вносят в процесс проектирования существенные коррективы, но с другой — ограничива­ют архитектуру. Отбираемые для реализации определенного функционального набора, компоненты выражают те или иные архитектурные допущения (а значит, и допущения по качеству). Задача архитектора состоит в том, чтобы обеспечить корректность выбора этих допущений и их совместимость.

Начиная с 1960-х годов принятие многих проектных решений в значительной степени зависит от конкретной операционной системы. Системы управления ба­зами данных сформировались как фактор влияния в начале 1970-x. Повсемест­ное распространение компьютеров привело к повышению возможностей исполь­зования для реализации системных задач компонентов, разработанных третьей стороной. Само по себе наличие компонентов не является принудительным стимулом к их использованию (и этом контексте см. врезку «Quack.com»), что, од­нако, не сокращает потребность в изучении механизмов их внедрения в систему Процесс отбора коробочных компонентов для системы предполагает поиск сборок (assemblies) совместимых компонентов, формулирование механизма реа­лизации с их помощью атрибутов качества и принятие решений относительно возможности их интеграции в конструируемую систему.

QUACK.COM

Истоки

Компания Quack.com основана в конце 1998 года двумя бывшими сотрудниками Инсти­тута программной инженерии (Джероми Карье (Jeromy Carriere) и Стивом Вудсом (Steve Woods)), а также профессором Гавайского университета Алексом Квилиси (Alex Quilici). Вооружившись идеей обеспечить доступ к коммерческой информации и данным иного характера no телефону, они сконструировали демонстрационную версию программы и к концу лета 1999-го добились финансирования со стороны ряда «благодетелей» и вен­чурных компаний. Осознавая важность голосовой архитектуры, они выстроили «реаль­ную» систему в виде голосового портала поверх комплекта инструментов и платформы публикации голосовых приложений. В результате им удалось оперативно сконструировать и организовать сопровождение широкого ряда приложений. В принципе, спроектирован­ная ими платформа имела все шансы на доминирование в зарождающейся индустрии. Через десять месяцев после начала финансирования они выпустили предварительную версию потребительского голосового веб-портапа. Он предоставлял услуги доступа к ин­формации о погоде, кинофильмах, курсах акций и прочим данным потелефону, 31 авгус­та 2000-го компания вошла в состав America Online. Вскоре — 25 октября 2000 года — AOL выпустила приложение AOLbyPhone, сконструированное группой разработчиков Quack на основе их же платформы и инструментального набора.

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

Первый портал Quack, внесший весомый вклад в последующий успех проекта, оказался вполне полезным сам по себе, однако широкого внимания пользователей так и не получил. После приобретения проекта корпорацией AOL коммерческие приоритеты резко поменялись. Располагая базой из 34 000 000 подписчиков, AOL вывела на первый план такие коммерче­ские факторы, как готовность и производительность. Портал Quack.com предстояло подго­товить к более интенсивному режиму использования и обеспечить соответствие более жест­ким требованиям по готовности.

Для подгонки проекта под новые требования было решено переписать компоненты. Верти­кальное масштабирование и повышение готовности в рамках гибкой архитектуры не представ­ляло особых проблем; в то же время предсказать реакцию компонентов на предполагаемые изменения оказалось категорически невозможно. Получить контроль над производительно­стью и готовностью системы в целом можно было лишь путем их переписывания (в порядке убывания критичности).

Многие другие системы прошли аналогичный этап. Недавно мы посетили небольшую на­чинающую компанию, занятую построением новой линейки программных продуктов. Пони­мая, что второго шанса произвести первое впечатление не будет, ее сотрудники поставили надежность и масштабируемость на вершину списка архитектурных задач. По словам их ар­хитектора, «если функция не слишком важна, мы ограничиваемся коробочным компонентом. Если в отношении того или иного аспекта системы существует официальный или фактиче­ский стандарт, подходящий коробочный компонент можно выбрать — скорее всего, этот стан­дарт соблюдается разными производителями. Если же у нас есть какие-то сомнения и мы не можем найти очевидных решений, значит, нужно конструировать компонент собственными силами». Прежде чем перейти к работе над новым проектом, этот архитектор участвовал в создании крупной поисковой системы и контент-провайдера. За четыре года число суточных посещений увеличилось с 45 000 до 45 000 000. Работая с системой многомиллионной посе­щаемости, он очень быстро научился действовать так, чтобы не просыпаться по ночам в свя­зи с очередной проблемой, угрожающей коммерческой деятельности.

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

- LJB и PCC

В настоящей главе мы рассмотрим упрощенный процесс отбора компонентов исходя из практических соображений. Сначала формулируются гипотезы о том, как должны «работать» выбранные компоненты. Затем для проверки этих гипо­тез строятся простые макеты. Наконец, после оценки функционирования маке­тов, на случай опровержения гипотез составляется запасной план. Основной прин­цип этой методики состоит в том, что отбирать единичные компоненты не имеет смысла. Отбирать и тестировать нужно сборки совместно функционирующих компонентов.

Кроме того, ниже мы опишем приложение данного процесса к недавно со­зданной системе.