Глава 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.