От одной системы к множеству (стр. 13 )

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

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

454  Глава 15. CelsiusTech. Конкретный пример разработки линейки продуктов

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

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

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

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

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

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

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

Глава 16

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

(в соавторстве с Анной Лиу2)

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

Пишется однажды, тестируется везде. Присказка особо циничных программистов Java

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

456  Глава 16. J2EE/EJB

соответствия стандарту) на переносимость конечного приложения в масштабах любых платформ 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) позволяет объектам публиковать свои интерфейсы, и, в каком бы местоположе­нии компьютерной сети они ни находились, клиентские программы могут обра­щаться к ним за обслуживанием.

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

Период, в течение которого CORBA оставалась единственной жизнеспособ­ной технологией распределенных объектов, оказался непродолжительным. Вско­ре компания Sun Microsystems выпустила язык программирования Java, преду­сматривавший поддержку удаленного вызова методов (remote method invocation, RMI) и, по сути, встраивавший специализированную для 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.

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

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

458  Глава 16. J2EE/EJB

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

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