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

Компонент технологического управления пакетируется в двух элементах EJB: u сеансовом bean без состояния, предназначенном для управления экземплярами модели технологического управления, и bean-сущности, предназначенной для управления самой моделью (рис. 17.8). Это решение о пакетировании компонен­та обусловливается исключительно характеристиками различных типов EJB,

Рис. 17.8. Диаграмма пакетов компонента технологического управления

Абстракции, реализуемые в приложении сущностными EJB, выражают сов­местно используемые ресурсы, в рамках которых данные устойчивого объекта доступны многочисленным компонентам и пользователям. Модель технологи­ческого управления представляет единственный ресурс подобного рода, а имен­но процесс, допускающий многократную конкретизацию. Любой пользователь приложений Inmedius, независимо от своего местоположения, может запускать новые процессы, основанные на упомянутой модели технологического управле­ния, и участвовать в их действиях.

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

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

С тем, как пакетировать отдельные объекты в рамках модели технологическо­го управления, было связано еще одно компромиссное решение. Следует ли их пакетировать в виде сущностных EJB или в виде Java-клaccoв, пакетированных в другой структуре (например, в библиотеке)? Поскольку эти объекты взаимо­действуют и зависят друг от друга, при их пакетировании в виде сущностных EJB нужно было бы постоянно обнаруживать местонахождение и сохранять мно­гочисленные EJB-дескрипторы приложения, а следовательно, вводить дополни­тельные издержки. Кроме того, как мы помним, вызов любого метода в EJB про­изводится удаленно (в виде RMI), а значит, также связан с непроизводительными издержками. Большинство контейнеров J2EE способны определять, относится ли вызываемый метод к той же виртуальной машине Java, к которой принадле­жит вызывающая сторона, и, таким образом, оптимизировать его до локального вызова, но все-таки это делают далеко не все. Исходя из этих соображений было принято следующее проектное решение. Крупные абстракции (такие, как модель технологического управления) в приложении предполагалось выразить в виде объектных EJB, а относительно мелкие — реализовать в сущностных EJB в виде библиотеки классов. Все эти операции были направлены на снижение допол­нительных издержек, связанных с тяжеловесными отношениями между сущно­стными EJB.

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

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

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

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