Пакетирование компонентов

Все без исключения приложения в рамках Luther обращаются к среде J2EE и ее службам. Учитывая это ограничение, компоненты в данной среде можно пакети­ровать в виде элементов EJB, компонентов Java beans, отдельных библиотек классов Java, апплетов, сервлетов или произвольного сочетания перечисленных элемен­тов. Другими словами, компонент, не являясь синонимом EJB, гем не менее до­пускает разные варианты пакетирования.

Выбор стратегии пакетирования конкретной возможности обусловливается набором применяемых служб J2EE и решениями, уравновешивающими ряд зна­чимых факторов (частоты межобъектного взаимодействия, местонахождения объектных экземпляров, а также необходимости применения разного рода служб J2EE — в частности, службы транзакций и службы устойчивости состояния объ­екта в продолжение нескольких пользовательских сеансов). К примеру, обмен данными с элементами EJB осуществляется путем удаленного вызова методов (RMI) — довольно тяжеловесного механизма взаимодействия. Некоторые контейнеры J2EE допускают оптимизацию обмена данными с элементами EJB (ко­торый в таком случае производится путем локального вызова методов); однако делается это лишь в том случае, если обмен данными происходит в рамках одной виртуальной машины Java (Java Virtual Machine, JVM). Тем не менее, поскольку оптимизация не входит в число требований к контейнерам J2EE, обмен данными между элементами EJB всегда связан с риском серьезного увеличения издержек, в связи с чем к этому вопросу следует относиться с осторожностью — если, ко­нечно, вас заботит производительность. В качестве альтернативного решения можно создать библиотеку клaccoв Java, которая позволяет избежать удаленного вызова методов, а следовательно, и связанных с этим механизмом издержек. Впро­чем, в таком случае компонентам приходится брать на себя дополнительные обя­занности, которые обычно выполняются контейнерами, — в частности, связан­ные с созданием и удалением экземпляров компонентов.

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

Как мы говорили в главе 16, модель EJB поддерживает несколько типов beans: beans-сущности (entity beans), сеансовые beans (session beans) и сеансовые beans без состояния (stateless session beans). Эти типы beans ориентированы на разные формы бизнес-логики и, соответственно, по-разному обрабатываются контейне­рами. К примеру, bean-сущность допускает самостоятельное управление устой­чивостью, которое осуществляется посредством поддерживаемых контейнером обратных вызовов (так называемая устойчивость под управлением beans, или самоуправляемая устойчивость); кроме того, эти задачи может вынолнять сам контейнер (так называемое контейнерное управление устойчивостью). В любом случае, эти операции связаны со значительными непроизводительными издерж­ками, которые ограничивают практическое применение beans-сущностей долго­временными бизнес-объектами, характеризующимися крупноблочным доступом к данным.

Что делает контейнер J2EE?

Приложения выказывают потребность в самых разных возможностях — напри­мер, в поддержке транзакций, безопасности и выравнивании нагрузки. Эги воз­можности очень сложны (многие корпорации даже организуют специальные под­разделения, предназначенные исключительно для их обеспечения) и находятся за рамками любого конкретного приложения или прикладной области. Один из основных мотивов, которым руководствовалась компания Inmedius, принимая решение о создании архитектуры Luther на основе J2EE, состоял в том, что по­добные характеристики реализованы в коммерческих общедоступных совмести­мых cJ2EE контейнерах, и, следовательно, Inmedius не пришлось реализовывать их самостоятельно.

Многие из этих возможностей можно конфигурировать для конкретного эле­мента EJB в период размещения приложения. Есть и другая альтернатива — они могут присутствовать в контейнерах J2EE и носить прозрачный характер. В лю­бом случае, разработчикам EJB не приходится встраивать вызовы к ним непо­средственно в код; следовательно, их можно без труда сконфигурировать с уче­том потребностей любого конкретного заказчика. Тем самым упрощается процесс создания компонентов EJB, независимых от конкретного приложения, и гаранти­руется их исполнение в рамках любых совместимых с J2EE контейнеров.

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

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

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

Что делает разработчик компонентов?

Разработчик компонента создает для него клиентское представление, или ин­терфейс прикладного программирования, а также реализацию компонента. В отношении простых элементов EJB его действия ограничиваются написа­нием всего лишь трех классов: home-интерфейса, remote-интерфейса и класса реализации.

Кроме того, разработчик компонента составляет определение типов данных, выставляемых напоказ клиентам через интерфейс прикладного программирова­ния. Они реализуются как дополнительные классы и во многих случаях прини­мают форму объектов значения (value objects), которые посредством интерфейса прикладного программирования передаются элементу EJB и извлекаются из него.

Пример повторно используемого компонента: компонент технологического управления

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