Когда нужно применять компоненты, управляемые сообщениями
Можно указать несколько ситуаций, в которых применение управляемых сообщениями компонентов будет целесообразным.
· Имеется старое приложение, которое надо интегрировать в приложение уровня предприятия на J2EE. Можно не переписывать это приложение заново, а связать его с новой системой на базе J2EE через компонент, управляемый сообщениями.
· В приложении требуются функции нижнего уровня, которые можно выполнять автономно. Иначе говоря, хотя эта функция должна выполняться для пользователя, главный поток событий приложения не обязательно должен ждать, пока она завершится. Примером такой функции может быть регистрация поступающих заказов.
· Управляемые сообщениями компоненты представляют собой удобный механизм доставки одной и той же информации нескольким получателям. Для этого используется принцип публикации и подписки. Каждое сообщение от издателя доставляется каждому подписчику. Например, если издатель публикует сообщение в тему, которая имеет трех подписчиков, каждый из них получает сообщение автоматически, без каких-то дополнительных усилий издателя. Данные издателей или подписчиков можно легко изменить, не затрагивая остальных частей системы.
Версии J2EE
Как и все компоненты EJB, управляемые сообщениями компоненты развертываются с по-* мощью контейнера EJB, который в свою очередь располагается на сервере приложений. Конкретные возможности и уровень совместимости сервера с J2EE определяют, с какой версией спецификации EJB следует работать.
Большая часть материала этой главы применима только к версии J2EE 1.3, так как в предыдущих версиях не было компонентов, управляемых сообщениями.
Сведения по JMS применимы и к другим версиям.
Представления компонентов, управляемых сообщениями, и UML
Со структурной точки зрения компоненты, управляемые сообщениями, состоят из главного класса Java, часто называемого классом реализации или классом компонента. Это единственный нужный элемент. Компонент, управляемый сообщениями, не имеет ни интерфейсов, ни других классов, если только для данного приложения не требуется, чтобы EJB содержал какие-то вспомогательные классы для поддержки логики приложения.
Так как это единственный класс, нет надобности рассматривать отношения между элементами. Легко видеть, что благодаря этому компоненты, управляемые сообщениями, обычно меньше по размеру и гораздо проще в создании, чем другие разновидности EJB.
Клиентское представление
Основной интерфейс между клиентом и компонентом, управляемым сообщениями, складывается из сообщений, которые клиент должен передавать для компонента. Клиент не может обращаться к компоненту напрямую.
Вследствие этого компоненты, управляемые сообщениями, не имеют особого клиентского представления, как сеансовые компоненты или компоненты-сущности.
Клиент контактирует с адресатом JMS, который предоставляется ему контейнером EJB для каждого развернутого компонента. Кроме этого, у клиента нет доступа ни к каким другим интерфейсам.
Средствами UML управляемый сообщениями компонент изображается просто как класс UML со стереотипом <<EJBMessage». Такое представление показано на рис. 14.1. Конечно, управляемые сообщениями компоненты можно изображать так же, как изображаются сеансовые компоненты или компоненты-сущности, но они гораздо менее сложны и поэтому представление в виде класса более ясно и больше соответствует реальности.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.