Параметрические модули

Сопровождение крупных, заранее интегрированных блоков

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

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

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

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

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

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

Фактически, многочисленность параметров — это скорее проблема учета; мы не знаем ни одного случая, когда некорректное функционирование можно было бы отнести исключительно к недостаткам спецификаций параметров. Зачастую крупный модуль импортируется с тем же набором параметров, который приме­нялся в предыдущем случае.

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

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

Архитектура, впрочем, продемонстрировала себя основой всей методики — как с технической, так и с культурной точки зрения. В некотором смысле, она оказа­лась тем осязаемым объектом, создание и конкретизация которого заявлялись как конечная цель. В силу своей значимости архитектура оказалась в высшей степени видимой. Власть над ней, но, с другой стороны, и ответственность за ее развитие ложилась на участников компактной, высокопрофессиональной группы архитекторов. В результате была достигнута та «концептуальная целостность» архитектуры, которую Брукс [Brooks 95] считает основным условием успеха лю­бого программного проекта.

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

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

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

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

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

Есть два сообщения, повествующие о переходе CelsiusTech к методике постро­ения линейки продуктов. Первое — составленное сотрудниками Института про­граммной инженерии [Brownsword 96] — послужило основным источником ма­териала для данной главы. Второе — это диссертация, защищенная в шведском университете г. Линкопинг [Cederling 92].

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

1. Можно ли на основе архитектуры CelsiusTech создать систему управления воздушным движением наподобие описанной в главе 6? Могла ли Celsius­Tech, напротив, обратиться к архитектуре этой системы? В чем сущност­ные различия между двумя вариантами архитектуры?

2. В период разработки линейки продуктов SS2000 структура управления CelsiusTech несколько раз претерпевала изменения. Учитывая высказан­ный нами в главе 7 тезис о том, что структура продукта должна отражать структуру проекта, оцените воздействие этих изменений.

Глава 16

J2EE/EJB. Конкретный пример стандартной вычислительной инфраструктуры

(в соавторстве с Анной Лиу^[7])

Пишется однажды, исполняется везде.

Девиз Java от Sun Microsystems

Пишется однажды, тестируется везде.

Присказка особо циничных программистов Java

В настоящей главе мы намерены представить вашему вниманию обзор специфи­кации корпоративной архитектуры Java 2 (Java 2 Enterprise Edition, J2EE) и по­подробнее остановиться на одной из ее важнейших частей — системе корпора­тивных JavaBeans (Enterprise JavaBeans, EJB). J2EE — это стандартное описание методов проектирования и разработки распределенных объектно-ориентирован­ных программ на языке Java, а также передачи данных и взаимодействия между различными компонентами Java. Спецификация EJB содержит описание компо­нентной модели программирования на стороне сервера. В целом, J2EE, помимо прочего, описывает разного рода корпоративные службы, в частности, именова­ния, транзакций, жизненного цикла компонентов и устойчивости (persistence), а также методы единообразного обслуживания и обращения к службам. Нако­нец, эта спецификация регламентирует механизм инфраструктурного обслужи­вания разработчиков приложений производителями, направленный (при условии соответствия стандарту) на переносимость конечного приложения и масштабах любых платформ J2EE.

J2EE/EJB — это лишь одна из многих методик конструирования распределен­ных объектно-ориентированных систем. В частности, в последнее десятилетие довольно широкое распространение получила обобщенная архитектура постро­ения брокеров объектных запросов (Common Object Request Broker Architecture, CORBA) от рабочей группы по объектному менеджменту (Object Management Group, OMG). Согласно этой архитектуре, брокер объектных запросов (object request broker, ORB) позволяет объектам публиковать их интерфейсы, а кли­ентским программам (а иногда и другим объектам) — обнаруживать местонахож­дение удаленных объектов во всей компьютерной сети и запрашивать у них об­служивание. Компания Microsoft предлагает собственную технологию конструи­рования распределенных систем — она называется.NET. В архитектуре.NET аналогичные возможности построения распределенных объектных систем предо­ставляются для Windows-платформ.

В начале главы мы рассмотрим коммерческие факторы, обусловившие созда­ние стандартной архитектуры распределенных систем; затем разберем реализа­цию соответствующих потребностей в архитектуре J2EE/EJB. Ознакомившись с типичными требованиями по качеству, предъявляемыми к веб-приложениям, мы постараемся уяснить механизм их удовлетворения средствами J2EE/EJB.

16.1. Связь с архитектурно­экономическим циклом

На протяжении 1980-х годов соотношение «цена/производительность» для пер­сональных компьютеров постепенно приближалось к аналогичному показателю для профессиональных рабочих станций и «серверов». Этот приток вычисли­тельных мощностей и ускорение сетевых технологий сделал возможным широ­кое распространение распределенной обработки данных.

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

Для решения этой проблемы в начале 1990-х годов силами рабочей группы по объектному менеджменту (Object Management Group, OMG) была разработана обобщенная архитектура построения брокеров объектных запросов (Common Object Request Broker Architecture, CORBA). Модель CORBA представляла со­бой стандартную программную платформу, на которой распределенные объекты могли обмениваться данными и взаимодействовать прозрачно и беспрепятствен­но. В таких условиях брокер объектных запросов (object request broker, ORB) позволяет объектам публиковать свои интерфейсы, и, в каком бы местоположе­нии компьютерной сети они ни находились, клиентские программы могут обра­щаться к ним за обслуживанием.

Период, в точение которого CORBA оставалась единственной жизнес/юсоб- noii технологией распределенных объектов, оказался непродолжительным. Вско­ре компания Sun Microsystems выпустила язык программирования Java, преду­сматривавший поддержку удаленного вызова методов (remote method invocation, RM1) и, по сути, встраивавший специализированную для Java функциональность брокеров объектных запросов во все виртуальные машины Java (Java Virtual Machine, JVM). У Java есть такое преимущество, как переносимость. Код разра­ботанного Java-приложения становится переносимым в масштабах всех JVM, которые реализованы на всех основных аппаратных платформах.

Sun Microsystems не стала останавливаться на Java. К концу 1990-х относится появление спецификации J2EE с Java RMI в качестве базовой инфраструктуры передачи данных. Для всего сообщества разработчиков программных средств она вскоре стала стандартом, упрощающим конструирование объектных систем на языке программирования Java. Позиции J2EE укрепились еще больше, когда про­изводители программного обеспечения судорожно взялись за ее реализацию; с на­ступлением «эпохи Интернета» Java-программисты по всему миру активно осва­ивали каркас J2EE, разрабатывая приложения электронной коммерции. Таким образом, J2EE вступила в прямую конкуренцию одновременно с CORBA и со специализированными технологиями от Microsoft.

Архитектурно-экономический цикл J2EE/EJB изображен на рис. 16.1.

Рис. 16.1. Архитектурно-экономический цикл в связи с компанией Sun Microsystems

и ее продуктами J2EE/EJB

16.2. Требования и атрибуты качества

Какие цели преследовала компания Sun Microsystems, взявшись за разработку спецификации J2EE/EJB? Как эти задачи отражены в атрибутах качества архи­тектуры J2EE/EJB?

Всемирная паутина и J2EE

В ответ на повышение требований, предъявляемых к коммерческим веб-систе­мам, все больше количество корпоративных информационных систем констру­ируется на основе технологии распределенных объектов. Такие системы должны быть масштабируемыми, высокопроизводительными, переносимыми и безопас­ными. Обрабатывая огромное количество запросов от деятелей интернет-сооб­щества, они должны реагировать на них своевременно.

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

Истории о сайтах электронной коммерции, не выдержавших неожиданного притока посетителей, слышны чуть ли не на каждом углу. К примеру, в 1999 году во время Уимблдонского теннисного турнира на его сайт поступил почти 1 мил­лиард обращений, а во время одного из матчей число обращений достигло 420 ООО в минуту (7000 в секунду)! Не стоит забывать, что Интернетом в настоящее время пользуется лишь незначительная часть населения Земли, — все только начинается.

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

Разрабатывая спецификацию J2EE, компания Sun Microsystems стремилась создать технологическую базу, упрощающую конструирование подобного рода систем. В частности, спецификация EJB, входящая в состав J2EE, направлена на решение следующих задач.

♦ Создание компонентной архитектуры построения на языке Java распреде­ленных объектно-ориентированных бизнес-приложений. Система EJB по­зволяет конструировать распределенные приложения за счет сочетания компонентов, разработанных инструментальными средствами разных про­изводителей.

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

Таблица 16.1. Типичные требования по атрибутам качества, предъявляемые к веб-приложениям

Конкретнее, архитектура EJB выполняет следующие задачи:

♦ влияет на аспекты разработки, размещения и исполнения жизненного цик­ла корпоративного приложения;

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

♦ взаимодействует с другими интерфейсами прикладного программиро­вания API;

♦ обеспечивает способность к взаимодействию между корпоративными beans и He-Java-приложеииями;

♦ взаимодействует с CORBA.

J2EE допускает повторное использование Java-компонентов в рамках инфра­структуры на стороне сервера. При наличии подобающих инструментов сборки и размещения компонентов задача заключается в том, чтобы перенести удобство программирования в конструкторах с графическим пользовательским интерфей­сом (типа Visual Basic) на процесс построения серверных приложений. Учитывая то обстоятельство, что стандартный каркас продуктов J2EE основывается на од­ном языке (Java), компонентные решения J2EE (по крайней мере, в теории) де­монстрируют независимость от конкретных продуктов и переносимость в преде­лах платформ J2EE от разных производителей. Таким образом, в дополнение к представленным в табл. 16.1 базовым требованиям компания Sun вводит набор требований, касающихся действий группы программистов. Эти добавочные тре­бования по атрибутам качества перечислены в табл. 16.2.

Таблица 16.2. Требования по атрибутам качества, предъявляемые компанией Sun применительно к J2EE

16.3. Архитектурное решение

Рассматриваемая в предыдущем разделе методика удовлетворения требований по атрибутам качества, предложенная компанией Sun Microsystems, опирается на спецификации двух основных вариантов архитектуры: J2EE и EJB. J2EE описы­вает общую многозвенную архитектуру проектирования, разработки и размеще­ния компонентных корпоративных приложений. Спецификация EJB как основ­ной элемент технологии J2EE отражает более глубокие технические требования к возможности построения, расширяемости и способности к взаимодействию. Как J2EE, так и EJB выражают умеренную специфичность (balanced specificity) — иначе говоря, способность конкурирующих сторон дифференцировать свои пред­ложения, сохраняя их в то же время на универсальной базе.

Основными характеристиками платформы J2EE являются:

♦ многозвенная распределенная прикладная модель;

♦ серверная компонентная модель;

♦ встроенное управление транзакциями.

Простое представление размещения многозвенной модели изображено на рис. 16.2. Элементы этой архитектуры расписаны более подробно в табл. 16.3.

Таблица 16.3. Обзор компонентов и служб в рамках технологии J2EE

♦ Звено клиента. Клиентским звеном в веб-приложении является интернет- браузер, подающий HTTP-запросы и загружающий с веб-сервера страницы HTML. В приложениях, размещаемых в обход браузера, возможно участие автономных Java-клиентов или апплетов, которые напрямую взаимодей­ствуют со звеном бизнес-компонентов. (Пример использования J2EE в об­ход браузера приводится в главе 17.)

♦ Веб-звепо. Веб-звено сводится к веб-серверу, который обрабатывает клиент­ские запросы и отвечает на них путем запуска сервлетов J2EE или JavaSer­ver Pages G^SPs)* Сервлеты запускаются сервером в зависимости от типа пользовательского запроса. Они запрашивают на предмет требуемой ин­формации звено бизнес-логики, а затем, перед тем как посредством сервера возвратить ее пользователю, выполняют форматирование. JSP являют со­бой статические страницы HTML, в которых содержатся фрагменты кода сервлета. Код, запускаемый механизмом JSP, принимает обязанность по форматированию динамической части страницы.

Рис. 16.2. Представление размещения многозвенной архитектуры J2EE. Ниже расписаны роли отдельных звеньев

♦ Звено бизнес-компонентов. Бизнес-компоненты составляют основу бизнес- логики приложения. Реализуются они посредством EJB (это программно­компонентная модель, поддерживаемая J2EE). EJB принимают запросы от сервлетов, относящихся к веб-звену, затем в целях их удовлетворения, как правило, обращаются к источникам данных и, наконец, возвращают ре­зультаты сервлету. Размещаются компоненты EJB в среде J2EE внутри EJB- контейнера. Последний предоставляет своим EJB ряд служб — в частности, связанных с управлением транзакциями и жизненным циклом, управлени­ем состоянием, безопасностью, многопоточной обработкой и организацией пула ресурсов. EJB лишь указывают тип поведения, которого контейнер должен придерживаться в период исполнения, а в остальном полностью полагаются на обслуживание со стороны контейнера. В результате при­кладные программисты избавляются от необходимости забивать бизнес- логику кодом в целях решения системных задач и задач среды.

♦ Звено корпоративных информационных систем. Как правило, оно состоит из одной или нескольких баз данных и серверных приложений — напри­мер, мэйнфреймов или каких-либо других унаследованных систем, к кото­рым при обработке запросов обращаются EJB. С базами данных — а в этом качестве чаще всего выступают системы управления реляционными база­ми данных (Relational Database Management Systems, RDBMS)) — обычно применяются драйверы JDBC.

Дата добавления: 2015-04-25