EJB-ить или не EJB-ить, вот в чем вопрос

Рассказ о трудностях и задачах при адаптации решений, основанных на EJB.

Обзор

С первых дней J2EE (Java 2 Platform, Enterprise Edition), технология Enterprise JavaBean (EJB) была источником споров и противоречий, с разработчиками и архитекторами, постоянно борющимися за эффективное использование EJB в своих проектах. Как следствие, в индустрии возник целый фольклор и набор шаманских правил по наилучшему использованию EJB -- некотрые из них правдивы, некоторые устарели, и часть просто неверна. В этой статье Хэмфри Шейл объясняет, когда и как использовать EJB в ваших J2EE приложениях, а также как узнать, являются ли EJBs наилучшим решением для вас. (3500 слов)

Оглавление

• EJB-ить или не EJB-ить, вот в чем вопрос.
• Сильные и слабые стороны EJB.
  • Достоинства.
  • Недостатки.
• Альтернативные решения.
• Шпаргалка.
  • «За».
  • «Против».
• Фольклор.
• Пример: Оптовая торговля пивом.
  • Месяц 0. Анализ требований.
  • Месяц 3. Проект разрастается.
  • Месяц 12. Переход на глобальный уровень.
• Знание – сила.
• Об авторе.
• Полезные ссылки.

To EJB, or not to EJB: that is the question.
Whether 'tis nobler in the mind, to suffer
The slings and arrows of outrageous licensing;
Or to take arms against a sea of potential overheads and features,
And by opposing end them? To roll your own: to reinvent the wheel;
No more; and by reinvent, to say, we continue
The heart-ache of low-level systems maintained in-house,
and the thousand natural shocks
That flesh is heir to; 'tis a consummation
Devoutly to be avoided.

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

Данная статья описывает алгоритм при помощи которого я принимаю подобные решения.

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

Более того, основная причина написания данной статьи – отзывы, которые я получил от читателей моей прошлой статьи «J2EE Project Dangers», опубликованной на сайте JavaWorld. В этой статье, я затронул ряд проблем, связанных с «тяжестью» EJB-технологии. Многие читатели просили более глубоко осветить эту проблему и, вуаля, перед Вами данный текст. 

Учитывая все вышесказанное, я бы сформулировал главную идею статьи следующим образом. Для того, чтобы принимать решение о целесообразности применения технологии EJB в Вашем проекте, Вы должно четко понимать предназначение EJB, сильные и слабые места этой технологии. Как и любая другая технология EJB имеет ряд уязвимых мест, и знание этих слабостей это первый шаг к избежанию проблем с EJB. Помимо дискуссии о сильных и слабых сторонах EJB, я кратко опишу основные альтернативы как для Java/J2EE, так и для принципиально других технологий. Наконец, финальная часть – пример применения подхода, описанного в статье. К этому моменту, Вы уже будете в состоянии применить описанные принципы к более- менее произвольной проблеме. Я опишу некую проблему (обещаю не приводить в качестве примера навязшие в зубах банкоматы и PetStore [1]). Я опишу свой вариант решения, а Вы в свою очередь попытаетесь оценить мою правоту.

Сильные и слабые стороны EJB.

Давайте попробуем сформулировать основные достоинства и недостатки технологии EJB.

Достоинства.

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

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

2. Интеграция с платформой J2EE. С тех пор как компания Sun в 1997 году представила технологию EJB широкой общественности, вокруг нее успел сложиться очень мощный и развитый сектор серверных технологий, включающий помимо EJB такие технологие как: сервлеты (servlets), JMS (Java Messaging Service), JSP (Java Server Pages), JCA (Java Connectors Architecture), JDBC (Java Database Connectivity), JAAS (Java Authorization & Authentication System), а также технологии управления транзакциями и многие другие. Наличие всех этих технологией, к тому-же объединенных общей идеологией делает платформу J2EE в целом и технологию EJB в частности, крайне привлекательным решением.

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

3. «Прозрачная» масштабируемость. Так как разработчик приложения перекладывает большинство функций по управлению ресурсами на плечи сервера приложений, производители последних могут применить сложные алгоритмы масштабирования для удовлетворения практически произвольной нагрузки. Тем не менее, слово «прозрачная» не случайно заключено в кавычки, т.к. масштабируемость к сожалению накладывает свой отпечаток на логику приложения. Так в случае горизонтального масштабирования, когда мы создаем кластер серверов приложений, разработчику придется модифицировать конфигурационный файл приложения (deployment descriptor) для того, чтобы оповестить сервер приложений о том, что он работает в связке с другими серверами.
4. Свободный доступ к сложным системам управления ресурсами. Когда Вы приобретаете сервре приложений, удовлетворяющий спецификации EJB, Вы в дополнение получаете целый спектр решений для доступа и управления ресурсами, включающий в себя подсистемы управления транзакциями, безопасностью, временем жизни компонентов, JNDI (Java Naming and Directory Interface) и т.д., вообщем все-те десятки тысяч строк кода, реализующие необходимые для серверного приложения механизмы, которые в противном случае пришлось-бы реализовывать самостоятельно.
5. Большое и энергичное сообщество разработчиков и развитый рынок решений. Практически все крупные IT компании за исключением Microsoft[2]поддерживают J2EE и EJB, что означает высокую стабильность и перспективность данной технологии. Кроме того, это означает, что технология не стоит на месте, а постоянно совершенствуется подстраиваясь под требования рынка. Так текущая спецификация имеет номер версии 2.0, пройдя через версии 1.0 и 1.1, причем очевидно, что этот процесс будет продолжаться.

Недостатки.

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

1. Большая по объему и сложная спецификация. Надо сказать, что это не вина компании Sun, разработавшей спецификацию. Ни одна из существующих спецификаций, описывающих распределенную систему вычислений, не страдает лаконичностью. Для примера можно взять спецификацию стандарта CORBA от консорциума OMG (Object Management Group) или архитектуру .Net компании Microsoft. Тем не менее, хотелось бы чтобы спецификация предоставляла несколько вариантов прочтения в зависимости от объема необходимой информации. Например, EJB-разработчикам требуется прочесть только содержание глав 6 и 9 для того, чтобы понять что такое session и entity beans. Кроме того, по моему опыту, достаточно выделять две роли вместо шести описанных в спецификации: это роли разработчика сервера/контейнера и разработчика приложения, который кроме того выполняет функции администратора EJB сервера. В этом случае, спецификация бы намного точнее отражала то как EJB используются на практике и как организованы команды разработчиков.
2. Увеличение времени разработки. В данном случае, имеется ввиду большее время на разработку решения с использованием EJB по сравнению с написанием обычного java-кода, а не с использованием другой платформы поддержки распределенных вычислений. Давайте смотреть правде в глаза, написание EJB отнимает довольно много времени и в случае возникновения проблем, отладка также более длительна по сравнению с отладкой обычного java-кода. Как правило, повышенная сложность отладки проистекает из того, что ошибка может быть как в Вашем EJB коде, так и в коде контейнера/сервера.

Основной метод решения данной проблемы – повышение квалификации разработчиков путем регулярных тренингов по работе с конкретным сервером приложений. Разработчики должны четко понимать, какие функции должен предоставлять сервер приложений (по спецификации) и как он их реализует (по информации из документации на конкретный сервер, семинаров проводимых компанией-разработчиком сервера, и т.д.). Подобные тренинги позволяют сильно сократить время разработки. Кроме того, важно применять усовершенствованные средства отладки, в частности, среды разработки (IDE), поддерживающие интерфейс JPDA (Java Platform Debugger Archtecture), которые позволяют отлаживать Ваш EJB-код.

3. Повышенная сложность по сравнению с обычным java-кодом. Даже на первый взгляд EJB-код достаточно сложен, так для реализации каждого session bean, Вы должны написать 3 класса, 4 класса на каждый entity bean, кроме того для снижения трафика Вам может понадобиться реализовать дополнительные объекты- значения (value objects). И при этом я еще не упомянул deployment descriptors, один стандартный, описывающий необходимые по спецификации свойства и второй, содержащий, свойства специфичные для конкретного сервера приложений.

Решение этой проблемы – средства автоматической генерации кода. Например, XDoclet, который позволяет существенно сократить объем ручного кодирования и при этом является совершенно бесплатным. Большинство современных сред разработки (IDE) также поддерживают авто-генерацию кода и размещение его на ряде популярных сервреров приложений. К недостаткам, использования IDE по сравнению с XDoclet-подобным решениям следует отнести привязку к определенному серверу приложений, а также возможность генерации кода только с использованием пользовательского интерфейса, что означает невозможность использования средств автогенерации кода в пакетном режиме, например при написании автоматических тестов или для автоматической сборки (build) приложения.

4. Потенциальная угроза переусложнения решения. Этот недостаток тесно связан со сложностью спецификации. Грубо говоря, наличествует ситуация, что «либо ты, либо тебя». Иными словами, если Вы не понимаете в достаточной степени идеологию EJB, Вам не удастся эффективно ее использовать и скорее всего Вы только переусложните проект. Более того, велик риск, что Вы не понимая всех взаимосвязей, существующих между компонентами, решите реализовать или переписать какие-либо подсистемы самостоятельно [3], что приведет к потере переносимости, масштабируемости или просто к серьезным, трудно отлаживаемым ошибкам.
5. Постоянные изменения спецификации. Поскольку EJB – очень быстро развивающаяся технология, то неизбежны случаи, когда написанный Вами код успевает к моменту выхода уже устареть, так как выходят новые версии спецификации, причем далеко не всегда сохраняющие обратную совместимость.  В первую очередь это касается разработчиков контейнеров/серверов. К сожалению, такая ситуация неизбежна и Вам придется смириться с тем, что написанный Вами EJB-код придется довольно часто пересматривать на соответствие с последней версией спецификации. Новые версии серверов приложений выходят достаточно часто, что совершенно не сравнимо скажем с частотой появления новых версий СУБД. Такая ситуация довольно серьезно влияет на стоимость решения на базе EJB, т.к. сервера приложений относятся к достаточно дорогостоящему ПО и Вам следует заранее заложить в бюджет средства для обновления версий, используемого Вами сервера приложений.

Альтернативные решения.

Если указанные выше недостатки EJB-подхода серьезно смутили Вас, то Вы наверняка с интересом рассмотрите альтернативные решения. Существуют-ли они? Если говорить честно, то если Вы не собираетесь использовать различные экзотические варианты, а хотели бы использовать какую-либо из mainstream технологий, желательно базирующуюся на языке Java, то выбор – невелик.

Откажитесь от EJB, но не отказывайтесь от Java.

Java не равно EJB. Вы можете просто писать обычные java-классы для решения Вашей задачи. Это означает, всего лишь, что Вы должны будете взять на себя управление многопоточностью, безопасностью, транзакциями и т.д. Если Ваше приложение не нуждается в подобной функциональности, то Вам не нужна технология EJB. Вам достаточно средств предоставляемых языком Java.

Тем не менее, даже в случае, если Вам необходимо поддерживать механизмы транзакций и т.д., но Вы не хотите использовать EJB, вполне возможно, что Вы будете в состоянии реализовать низкоуровневые системы поддержки необходимых Вам функций самостоятельно. Как правило, подобные подсистемы начинаются с горстки классов-фабрик, предоставляющих методы, подобные getConnection() и closeConnection(), а также нескольких классов-контроллеров вида XXXManager. В дальнейшем подобные классы вырастают, как правило, в некий усеченный вариант EJB контейнера. Поддержка подобного контейнера конечно целиком ложится на Ваши плечи, не самое лучшее решение, хотя и имеющее право на жизнь.

Использование EJB-подобной архитектуры.

Еще одна альтернатива, это использование EJB-подобной архитектуры, позволяющей с минимумом проблем переключиться на EJB позднее, когда Вы будете четче представлять потребности Вашего приложения. Существует целый ряд стандартных шаблонов проектирования (design patterns), некоторые из них описаны в классическом документе от Sun "Designing Enterprise Applications with the J2EE Platform". Как правило, подобные решения построены с использованием архитектуры Модели 2 (Model 2), с четким разделением между представлением в виде JSP страниц и бизнес-логикой в виде сервлетов, с возможностью перехода на более мощную и масштабируемую трехзвенную архитектуру в будущем.

Использование кардинально иной технологии.

Если Вы сомневаетесь не только в применении >EJB, но и языка Java в целом, Вам имеет смысл обратить внимание на конкурирующие платформы, такие как CORBA и Microsoft .Net. Существуют и другие альтернативы, но тройка J2EE, CORBA, .Net является основной.

Если Вам кажется что J2EE/EJB слишком сложная технология для Вашей задачи, не стоит даже пробовать использовать CORBA, она по крайней мере не проще. Большинство производителей серверов приложений, поддерживавших CORBA уже переключились на J2EE.

Microsoft в настоящее время серьезно продвигает свою технологию. .Net, помимо того, что как и J2EE является платформно-независимой [4]технологией, вдобавок еще и не зависит от языка программирования (J2EE привязана к Java). Набор сервисов предоставляемых обоими платформами примерно идентичен, но т.к. .Net является относительно новой разработкой, она пока не играет серьезной роли, т.к. многие смотрят на эту платформу как на «темную лошадку». Тем не менее, не надо закрывать на правду глаза, через какое-то время MS .Net станет очень серьезным соперником для J2EE.

Экзотические варианты.

Если ни одна из вышеперечисленных альтернатив не удовлетворяет Вашим потребностям, возможно Вам стоит обратить на менее известны решения, такие как Jini/JavaSpaces или SandStorm.

• Связка Jini/JavaSpaces не сумела занять заметной доли на рынке и рассматривается многими скорее как «академическая» технология. Однако идея лежащая в основе Jini достаточно интересна и предоставляет все базовые возможности для построения сложных серверных решений. Я добавил Jini/JavaSpaces в этот список во-многом потому, что я использую Jini/JavaSpaces в исследовательских целях и поражен элегантностью этой платформы. Тем не менее, в настоящей момент я бы не рекомендовал Вам основываться на Jini как на основной серверной платформе для Вашего приложения. Впрочем, это всего лишь мое частное мнение.
• Очень интересная технология SandStorm, посвящена в основном вопросам масштабируемости приложений, но оставляет в стороне вопросы безопасности и управление транзакциями. Тем не менее, для ряда случаев подобный подход может быть оправдан. Мне было бы крайне любопытно посмотреть на сервер приложений, поддерживающий технологию SandStorm.

Шпаргалка.

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

«За»

1. Использование EJB целесообразно, если Ваше приложение должно гладко масштабироваться между малым количеством пользователей на ранних стадиях (как правило на этапе разработки и тестирования) и массовой аудиторией в реальной жизни.
2. Вам необходима грамотная работа с транзакциями. Для онлайн-каталогов и других ресурсов где основная масса клиентов не может изменять информацию использование EJB избыточно. В то же время для финансовых и прочих систем, где должны соблюдаться ACID правила ( atomicity, consistency, isolation, and durability) использование EJB крайне желательно.  
3. Используйте EJB если Вам нужна развитая модель безопасности и защиты информации.

«Против».

1. EJB избыточны в ситуации когда Вам не нужно управление транзакциями, масштабируемость, безопасность. Чаще всего такая ситуация происходит в системах рассчитанных на малое количество пользователей, использующих систему преимущественно в режиме «только чтение».
2. Вам не нужна кросс-платформность и Вас не волнует привязка к конкретному поставщику программного обеспечения. В этом предложение нет сарказма, такая ситуация например достаточно встречается при написании приложений для корпоративных сетей, где важно сделать продукт как можно быстрее, избегая ненужных усложнений. В этом случае, например платформа .Net даже в виде бета-версии может оказаться более привлекательной.
3. Ни в коем случае не используйте EJB если Ваша команда не обладает опытом в применении этой технологии. В крайнем случае, Вы должны выделить дополнительное время и ресурсы для проведения обучения Ваших разработчиков.
4. Не используйте EJB просто потому, что Ваша компания получило некоторое количество лицензий на сервер приложений какого-либо производителя.

Рисунок 1. Основные фазы принятия решения по использованию какой-либо технологии (данные фазы применимы не только к EJB).

Фольклор.

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

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

EJB-приложение свободно портируется между серверами приложений разных производителей. Полу-правда. EJB портируется только, если Вы создате их с учетом портируемости. Как правило относительно легко портируются session beans и BMP (bean managed persistence) beans. В свою очередь CMP (container managed persistence) beans как правило требуют немало усилий для переноса на другой сервер приложений. Очень часто массу усилий приходится затрачивать на портирование приложений, активно поддерживающих кластеризацию, т.к. поддержка кластеризация довольно сильно отличается у различных производителей, во многом, вследствии того, что кластеризация не слишком подробно описана в спецификации. В основном работа по портированию заключается не в  переписывании кода, а в правке настроек сервера приложений и в корректировке deployment descriptors. Учитывая то, что средства настройки и конфигурации как правило специфичны у каждого вендора, то Вам придется затратить некоторое время на изучение данных средств. Кроме того, часто приходится корректировать скрипты для компиляции и установки приложения, если конечно Вы не используете Ant.

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

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

Что быстрее:CMP или BMP? Недопонимание. Скорость работы механизма CMP зависит от реализации его производителем. У разных серверов производительность данного механизма различна. Кроме того, производители могут добавлять различные расширения, которые улучшают производительность, но затрудняют портируемость приложения.

Entity beans работают медленно. Действительно, entity beans работают медленно и во многих случаях выгоднее заменять их комбинацией session beans и объектов-данных (value objects). Чаще всего проблемы с производительностью возникают в случае когда метод findXXX возвращает выборку из тысяч записей, в этом случае нужно менять архитектуру так, чтобы избежать подобных ситуаций. Некоторые сервера приложений пытаются оптимизировать подобные ситуации применяя такие методы как «загрузка по требовнию» (load on demand), но полагаться на это не стоит.

Следует избегать применения stateful session beans. Миф. Stateful session beans выполнют одну полезную функцию – сохраняют состояние сессии между запросами, использовать их для чего-то другого неправильно. В тоже время следует помнить, что сохранение состояния сессии на сервере приводит к проблемам масштабируемости, поэтому следует избегать использования этого приема. Хорошее правило – проектировать все session beans как stateless и затем только по мере необходимости преобразовывать часть из них в stateful.

Пример: Оптовая торговля пивом.

Помните, я обещал не приводить в качестве примера PetStore или банкомат? Поэтому, для иллюстрации вышесказанного я возьму в качестве примера систему автоматизации компании торгующей оптовыми партиями пива Ice-Cold Beer Boutique (ICB).

Месяц 0: Анализ требований.

Итак, мне было получено разработать проект системы автоматизации компании, занимающейся оптовыми поставками пива. Изначальные требования включали в себя:

• Для начала компания хотела открыть web-сайт для ограниченного круга своих клиентов (около 30). Сайт должен представлять из себя онлайн-каталог элитных сортов пива. Никаких средств авторизации и аутентикации не предусматривается.
• Бюджет проекта очень мал, по крайней мере до того момента, как будет приянто решение об увеличении масштаба проекта. Команда разработчиков имеет хороший опыт работы с Java, но совершенно не владеет технологией EJB.
• В будущем, компания планирует расширить предоставляемый сервис путем предоставления возможности онлайн-заказов ряду привелегированных клиентов. Кроме того, в будуще планируется увеличить количество пользователей данного сервиса до 100 клиентов.

График описывает предложенную архитектуру и ее изменения по мере изменения требований к проекту.

Рисунок 2. Эволюция системы от простого онлайн-каталога до полноценного B2B сервиса, построенного по технологии EJB.

Решение.

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

Я рекомендовал использовать подход с использованием JSP и сервлетов, доступ к данным осуществляется путем использования объектов-данных, обращающимся к базе данных при помощи интерфейса JDBC и библиотеки тэгов (taglibs) для доступа к базе данных из JSP.

Месяц 3. Проект разрастается.

Проект отлично развивается. Запуск версии прошел на «ура» и руководство компании решает расширить набор предоставляемых услуг. Теперь сервис должен обслуживать до 100 клиентов, причем должно обеспечиваться бесперебойное функционирование в режиме 24x7. Кроме того, необходимо предоставить возможность принимать онлайн- платежи используя ПО другой компании.

Решение.

Теперь у нас появляются причины для применения EJB:

• Масштабируемость: За три месяца эксплуатации количество пользователей увеличилось более чем в 3 раза. Это должно служить сигналом к тому, что рост может продолжаться и система должна справляться с возрастающей нагрузкой.
• Безопасность: сервлеты позволяют организовать процесс аутентикации пользователя, но не позволяют осуществлять авторизацию вызова различных методов на индивидуальной основе. EJB предоставляет эту возможность.
• Транзакции: Спецификация J2EE 1.3 требует, чтобы сервлеты и JSP могли получать доступ к механизму управления транзакциями через интерфейс javax.transaction.UserTransaction. Тем не менее, EJB предоставляет намного более гибкий подход к управлению транзакциями (например, смотри главу 17 в Enterprise JavaBeans > 2.0 Specification)

Месяц 12. Переход на глобальный уровень.

Через год после запуска сервиса возникает необходимость еще больше расширить набор услуг. Это связано с тем, что компания вступила в Ассоциацию Торговцев Пивом и теперь наш сервис должен поддерживать до 300 пользователей. Кроме того, необходимо иметь возможность работать совместно с нашими новыми бизнес- партнерами, компаниями WeissenBeer из Германии и Abbey Beer из Нидерландов. Наши новые партнеры используют протокол XML-RPC для публикации данных о своих операциях. Кроме того, они предоставляют Java интерфейс к своим системам планирования (ERP –Enterprise Resource Planning) для отслеживания количества товаров на складах и проведения сделок в реальном режиме времени.

Решение:

Вот теперь мы в полной мере можем почувстовать силу технологии EJB. Конечно, предстоит немало работы, но основной костяк системы уже существует и не требует изменений, даже в связи с трехкратным ростом числа клиентов. Интеграция с ERP- системой также не представляет особой сложности, т.к. мы можем разместить на сервере любой Java-код, который удовлетворяет ограничениям накладываемым спецификацией. Таким образом мы размещаем библиотеку для работы с ERP на сервере и используя ее интерфейс, заставляем наш сервис работать с этой библиотекой. Наиболее очевидным решением для взаимодействия являются message-driven beans и технология JMS. Для работы с возросшим количеством клиентов мы проводим масштабирование системы, включая серьезное тестирование, позволяющее выяснить насколько хорошо наша система справляется с возросшей загрузкой и с работой в режиме кластера.

Знание – сила.

Практически любой проект может быть создан на базе технологии EJB/J2EE, однако далеко не всегда это действительно необходимо. Когда я начал писать эту статью, технология EJB как раз получила ряд весьма нелестных отзывов в прессе, в часности можно прочитать отзыв одного из аналитиков, в котором он не рекомендует ориентироваться на применение серверов приложений (см. “Gartner: Don’t Overspend on Application Server Tech”).

Похоже, что первоначальная волна восторга по поводу EJB прошла и теперь со всех сторон слышатся упреки – «Слишком медленно, слишком дорого, слишком сложно...». Такая точка зрения недальновидна. Технология EJB идеально подходит для определенного круга задач – приложений с высокими требованиями к масштабируемости и управлению транзакциями. Цены на сервера приложений стремительно падают, появляются бесплатные сервера приложений такие как JBoss, а многие крупные компание, такие как HP, выпускают бесплатные варианты своих коммерческих серверов приложений. Возрастающая конкуренция как внутри индустрии, так и со стороны таких компаний как Microsoft также положительно влияет на развитие технологии.

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

Об авторе

Хэмфри Шейл (Humphrey Sheil) сертифицированный системный аррхитектор, участвоваший более чем в 25 проектах с применением J2EE в США и Европе. Помимо основной деятельности, он занимается исследованиями параллельных вычислений при расчете нейронных сетей для обработки биологической информации в Дублинском University College.

Ресурсы

• Reader inquiries about my second JavaWorld article, "J2EE Project Dangers," (March 2001) prompted me to write the above article:
  http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html
• You can download the Enterprise JavaBeans 2.0 Specification from:
  http://java.sun.com/products/ejb/docs.html
• The Jakarta Project's free Ant build tool removes much of the pain in deploying EJBs to application servers, and, best of all, it's extensible:
  http://jakarta.apache.org/ant
• Check out XDoclet for an elegant way to reduce hand-maintained code and increase efficiency through auto-generation:
  http://xdoclet.sourceforge.net/
• "Designing Enterprise Applications with the J2EE Platform" (Sun Microsystems, 2001) from the J2EE Blueprints series offers good information on design patterns for EJB/J2EE projects:
  http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/index.html
• The OMG produces and maintains computer industry specifications for interoperable enterprise applications, most notably CORBA:
  http://www.omg.org/
• Jini.org offers in-depth information about Jini and JavaSpaces:
  http://www.jini.org/
• Sandstorm, an interesting technology out of the University of California, Berkeley, provides good information for scalable applications:
  http://www.cs.berkeley.edu/~mdw/papers/seda-sosp01.pdf
• For more information on .Net, check out this site, specifically designed to appeal to developers and architects: http://gotdotnet.com/
• "Gartner: Don't Overspend on Application Server Tech," Scarlet Pruit (NetworkWorldFusion, August 2001) -- like all research notes, this one is refreshingly honest and wonderfully accurate:
  http://www.nwfusion.com/news/2001/0821gartnerapp.html
• My first JavaWorld article, "Frameworks Save the Day" (September 2000), outlines the basic necessities of a J2EE framework and also an extension strategy. If you're not using a standard framework on your project, you are leaving yourself open to a whole raft of quality and maintenance issues:
  http://www.javaworld.com/javaworld/jw-09-2000/jw-0929-ejbframe.html
• Born and bred from XP (extreme programming) and JUnit, continuous integration makes your development cycle a lot easier:
  http://www.martinfowler.com/articles/continuousIntegration.html
• For more EJB stories, visit the Enterprise JavaBeans section of JavaWorld's Topical Index:
  http://www.javaworld.com/channel_content/jw-ejbs-index.shtml
• Discuss EJB in our Enterprise Java discussion:
  http://forums.idg.net/webx?50@@.ee6b80a
• Sign up for JavaWorld's free Enterprise Java newsletter:
  http://www.idg.net/jw-subscribe
• You'll find a wealth of IT-related articles from our sister publications at IDG.net

[1] (Прим. перев.) Petstore – стандартный пример реализации электронного магазина с использованием EJB-технологии, который поставляется практически с каждым сервером приложений.

[2] (Прим. перев.) По последним данным Microsoft также предлагает ограниченную поддержку платформы J2EE, по крайней мере позволяя сопрягать собственные технологии с J2EE.

[3] (Прим. перев.) Синдром «not invented here», весьма распространенный среди разработчиков, когда Вы решаете переписать или написать с нуля какую-либо подсистему, вместо того, чтобы воспользоваться кодом, написанным каким-либо внешним разработчиком.

[4] (Прим. перев.) Хотя в настоящий момент, Win32 является единственной реально работающей платформой, поддерживающей MS .Net, в отличие от J2EE, которая уже поддерживается большим количеством платформ (в основном различные варианты unix).

---

Reprinted with permission from the December 2001 edition of JavaWorld magazine. Copyright © ITworld.com, Inc., an IDG Communications company.
View the original article at: http://www.javaworld.com/javaworld/jw-12-2001/jw-1207-yesnoejb.html