Компонентная модель EJB. Преимущества и недостатки

АРСЕН ИБРАГИМОВ, НИЯУ «МИФИ», инженер-программист, занимается теорией алгоритмов, дискретной математикой, а также разработкой приложений на С, С++ и Java

Компонентная модель EJB
Преимущества и недостатки

В российской корпоративной среде возрос интерес к платформе Java 2 Enterprise Edition (J2EE) и, в частности, к входящей в её состав компонентной модели Enterprise Java Bean (EJB).

Не стреляйте из пушки по воробьям

Я хотел бы кратко описать устройство этой модели, а также рассмотреть её преимущества, недостатки и границы применимости. Последний пункт очень часто опускается, хотя, безусловно, он чрезвычайно важен.

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

• необходимость присутствия или отсутствия дальнейшей расширяемости приложения;
• упрощение разработки бизнес-логики при увеличении размеров и сложности приложения в течение всего его жизненного цикла (усложнения, которые потребуют больших усилий на начальных этапах разработки кода, могут привести к более простой его доработке в будущем);
• затраты на техническую поддержку и устранение неисправностей.

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

С чего начиналось?

Когда Интернет перестал полностью состоять из статического HTML, в нем появилось динамическое содержимое, весь динамизм обеспечивался с использованием интерфейса CGI, а впоследствии – интерпретируемыми языками, среди которых особенно выделялись Perl, PHP и ASP.

Архитектура такого рода динамических приложений (см. рис. 1) была трудно расширяемой, достаточно скудной в планах разделения задач разработчика и дизайнера, возможностей повторного использования кода. Кроме того, она не обеспечивала стандартных средств для лёгкого выполнения множества рутинных операций, которые совершенно не были связаны с бизнес-логикой, но отнимали массу сил и времени разработчиков.

Рисунок 1. Двухуровневая модель приложения

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

Указанные выше недостатки не кажутся значительными в случае приложений малого масштаба, но для корпоративной среды, где необходимы гибкая масштабируемость, динамический модульный подход и быстрота разработки сложного кода, этот путь нельзя назвать практичным. Чем более функциональным и сложным будет готовое приложение в результате своей эволюции, тем труднее станет его поддерживать и расширять. По сути, в этом случае возникает та же самая проблема со сложностью, которая когда-то привела к возникновению объектно ориентированного программирования в противоположность процедурному, однако здесь она проявляется на более высоком уровне абстракции – не на уровне объектов, а на уровне модулей.

Многоуровневая структура приложения

Если принять во внимание текст предыдущего раздела, мы приходим к мысли о том, что модульная архитектура является наиболее приемлемой для сложных приложений бизнес-уровня. Кроме того, в любом таком приложении всегда можно выделить как минимум три основных логических уровня: уровень представления, уровень бизнес-логики и уровень данных (см. рис. 2). Как минимум, потому что для обеспечения большей масштабируемости вышеназванные уровни могут быть разделены ещё на несколько частей. Рассмотрим теперь каждый уровень подробнее.

Рисунок 2. Трёхуровневая модель приложения

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

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

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

Может возникнуть вопрос: почему нельзя просто объединить все функции, отвечающие за бизнес-логику, в отдельную библиотеку и таким образом добиться отделения кода бизнес-логики от кода представления? Все не так просто, как кажется на первый взгляд. Например, таким путём невозможно добиться лёгкой масштабируемости, а кроме того, многие дополнительные задачи наподобие создания пула соединений с базой данных и управления параллельной обработкой данных придётся заново реализовывать в каждом новом приложении. Таким образом, выделив второстепенные (то есть не включающие саму бизнес-логику) задачи, необходимые для функционирования уровня бизнес-логики, и реализовав их однажды в виде сервера приложений, можно добиться стабильности, надёжности, безопасности, а также лёгкой расширяемости приложения. Это происходит за счёт того, что прикладной программист может сконцентрировать внимание только на бизнес-логике приложения, ведь второстепенная работа уже сделана за него разработчиками сервера приложений.

Организация трёхуровневой модели приложения в J2EE

Рассмотрим теперь, каким образом архитектура J2EE организует каждый уровень трёхуровневой модели приложения. Принципиальная схема, иллюстрирующая это, представлена на рис. 3. Из неё видно, что уровень представления реализуется либо толстым клиентом, либо связкой тонкого клиента, HTML, JavaScript и Applet на стороне клиента и JSP, Servlet на стороне сервера. Уровень бизнес-логики реализуется компонентами EJB, взаимодействие которых с уровнем представления производится только через Home и Remote интерфейсы, а уровень данных – одной из имеющихся на рынке баз данных, доступ к которой осуществляется при помощи Java Database Connectivity (JDBC).

Рисунок 3. Организация трёхуровневой модели приложения в J2EE

Уровень бизнес-логики в J2EE

Уровень бизнес-логики в J2EE реализуется с использованием компонентов EJB. Однако каждый такой компонент взаимодействует с уровнем представления не напрямую, а с помощью домашнего (Home) и удалённого (Remote) интерфейсов. Назначением функций первого является создание, удаление и поиск объектов EJB, функции же второго как раз и составляют бизнес-логику приложения.

EJB, как и любая другая технология, имеет свои преимущества и недостатки. Хотел бы подробно рассмотреть основные из них, чтобы помочь читателю сделать выбор: стоит ему использовать EJB-компоненты в своём приложении или стоит отказаться от них в пользу другой, более простой по архитектуре технологии.

Основные преимущества EJB

• Наличие открытой спецификации. Спецификация определяет все основные аспекты разработки и реализации EJB-компонентов, начиная от используемых типов данных и заканчивая распределением ролей между разработчиками. Такая подробная спецификация служит одной-единственной цели – возможности полной взаимозаменяемости серверов приложений и контейнеров различных поставщиков. В идеале должна существовать возможность взять любой такой сервер и развернуть на нем разработанное приложение без каких-либо изменений. К сожалению, на практике с этим обычно возникают проблемы, связанные как с некоторыми неточностями самой спецификации, так и с неточностями её реализации.
• Переносимость компонентов. Компоненты, как впрочем, и серверы приложений написаны на языке Java, что даёт им полную переносимость на все платформы, для которых существуют Java Virtual Machine (JVM). Этот аспект не имеет отношения к спецификации EJB напрямую, но всё же является неоспоримым преимуществом.
• Полная интеграция с другими технологиями Java. Этот аспект позволяет говорить о EJB не как об отдельной, обособленной технологии, а как о части платформы J2EE, являющейся полномасштабным решением практически любой задачи, которая ставится перед современным прикладным программистом. Кроме EJB платформа J2EE включает в себя такие технологии, как Servlet, Java Server Pages (JSP), Java Messaging Service (JMS), Java Connectors Architecture (JCA), Java Database Connectivity (JDBC), Java Authorization and Authentication System (JAAS), Remote Method Invocation (RMI) и др. Всё это даёт единый подход к разработке всевозможных приложений.
• Быстрый цикл разработки. Наличие большого количества технологий, составляющих J2EE, а также огромного количества разработчиков Java позволяет утверждать, что для большинства распространённых задач созданы библиотеки классов. Это даёт возможность повторно использовать написанный кем-то ранее код в своих приложениях.
• Лёгкость разработки. При разработке EJB-компонентов большинство функций по управлению ресурсами с целью увеличения производительности перекладываются на плечи разработчиков серверов и контейнеров приложений EJB. Все эти функции реализуются на основе достаточно сложных алгоритмов, так как должны обеспечить отличное функционирование как при повседневных, так и при пиковых нагрузках. Это позволяет прикладному программисту сосредоточиться на бизнес-логике приложения и к тому же сокращает время разработки.
• Масштабируемость. Серверы приложений позволяют на лету добавлять в приложение новые компоненты EJB, а также приостанавливать и прекращать работу старых. Это позволяет легко масштабировать приложения в соответствии с текущими потребностями.
• Доступ к системам управления ресурсами. Серверы приложений включают в себя целый спектр решений, связанных с управлением ресурсами: системы управления транзакциями, безопасностью, временем жизни компонентов, системными ресурсами, Java Naming and Directory Interface (JNDI).
• Компонентность. Технология EJB основана на компонентах, а значит, не обязательно разрабатывать всё приложение самостоятельно. Можно купить или использовать свободно распространяемые компоненты EJB, реализующие часть (или даже все) функций разрабатываемого приложения.
• Возможность конфигурирования без перекомпиляции. Каждый компонент EJB сопровождается дескриптором развёртывания, который содержит конфигурационную информацию для развёртывания приложения. Это позволяет производить переконфигурирование приложения без изменения кода и перекомпиляции самих компонентов.
• Распространённость. Технология EJB поддерживается почти всеми крупными ИТ-компаниями, что говорит о её стабильности и перспективности, а кроме того, гарантирует, что данная технология будет поддерживаться ещё в течение достаточно длительного периода, а не канет в Лету в один момент.

Основные недостатки EJB

• Сложность изучения. Это, пожалуй, один из главных недостатков, останавливающих многие компании от перехода к EJB. Мало того что спецификация самих EJB достаточно объёмна, она ещё основывается или вплотную связана с другими J2EE-технологиями, поэтому для понимания структуры EJB нужно как минимум знать JNDI, RMI и JDBC.
• Сложность архитектуры. Здесь имеется в виду сложность по сравнению с другим Java-кодом. Например, для создания одного EJB придётся написать как минимум два интерфейса, один класс и один дескриптор развёртывания, а потом скомпоновать их в JAR-архив. Это создаёт некоторые сложности для отладки приложения и увеличивает время его разработки, хотя и не всегда.
• Возможность неоправданного усложнения приложения. Это в большей степени не недостаток EJB, а проблема плохой квалифицированности специалистов, принимающих решение об использовании той или иной платформы для разрабатываемого приложения. Иными словами, если архитектор не до конца понимает все тонкости спецификации EJB, он может неэффективно её использовать. Кроме того, есть риск, что какая-то часть приложения будет дублировать уже реализованные возможности сервера приложения, или, что ещё хуже, EJB будет использоваться там, где и сейчас, и в будущем вполне достаточно таких технологий, как Servlet и JSP.
• Быстрое изменение спецификации. Как и любая другая динамично развивающаяся технология, EJB подвержена постоянным, порой очень серьёзным, изменениям. Это опять-таки усиливает роль первых трёх недостатков, так как разработчикам постоянно приходится переучиваться (доучиваться) и принимать во внимание всё новые возможности серверов приложений.
• Обилие серверов приложений. Хотя спецификация и призвана как можно полнее описать технологию EJB, однако вследствие различий в реализации каждый сервер приложений имеет некоторые особенности, которые должны учитываться при проектировании и развёртывании приложений. Различия могут проявляться как в другом расположении и распределении конфигурационных файлов, так и в ошибках (неточностях) реализации, не позволяющих правильно работать конкретному приложению.

Границы применимости и возможные Java-альтернативы

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

Но всё же можно дать несколько рекомендаций, позволяющих даже плохо разбирающемуся в спецификации EJB системному архитектору решить, стоит ли ему вообще рассматривать EJB как один из возможных вариантов для разрабатываемого приложения. Необходимо обратить внимание на описанные выше преимущества и недостатки. Если недостатки являются более существенными с экономической или кадровой позиции, то, скорее всего, стоит отказаться от архитектуры на основе EJB.

Использование EJB будет полностью оправданно, если приложению нужны лёгкая масштабируемость, управление транзакциями и повышенная безопасность, или если разрабатывается система, где должны соблюдаться ACID-правила (Atomicity, Consistency, Isolation, and Durability).

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

Всегда следует учитывать, что компонентная модель EJB разрабатывалась для масштабных, распределённых приложений уровня предприятия, рассчитанных на достаточно сильные нагрузки, вызванные большим количеством обращений клиентов. Она необходима и в динамических приложениях, где важную роль играет лёгкая и быстрая масштабируемость. Для простых приложений, которые не требуют много ресурсов и не будут расширяться в ближайшем будущем, использовать EJB не стоит. В этом случае значительно дешевле и эффективнее обратить своё внимание на JSP/Servlet и реализовать с их помощью, например, хорошо зарекомендовавшую себя Model 2.

Стоит также ознакомиться с классическим документом от компании Sun: Designing Enterprise Applications with the J2EE Platform, находящимся по адресу: http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/index.html.