Индивидуальные проектные решения и решения, обусловленные спецификой J2EE

Следствия применения J2EE

В этом разделе рассматривается логическое обоснование ряда решений, приня­тых в рамках архитектуры Luther относительно использования J2EE.

В ходе проектирования системы в исполняемой cpeде J2EE одни решения проекти­ровщик принимает самостоятельно, а другие — исходя из правил и структуры J2EE. К примеру, J2EE устанавливает местоположение сервлетов JSР и EJB в составе кон­тейнера: сервлеты и JSP находятся в веб-звене, а элементы EJB — в EJB-звене.

В то же время архитектура J2EE в некоторых случаях допускает принятие гибких проектных решений — к примеру, в том, что касается реализации безопас­ности (декларативной и программной), поддержки транзакций (декларативной и программной) и доступа к данным (с контейнерным управлением и с самоуп­равлением bean).

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

Проблемы многозвенности в J2EE

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

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

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