Введение

Это руководство посвящено идентификации bean-объектов, управляемых сообщениями. Дополнительное руководство о bean-объектах, управляемых сообщениями предоставлено в разделе Руководство по рабочему продукту: bean-объекты, управляемые сообщениями. Общее руководство об объектах EJB находится в разделе Руководство по рабочему продукту: Объекты EJB.

Некоторые характеристики bean-объектов, управляемых сообщениями:

• Они не сохраняют состояния.
• Они не возвращают значений или исключительных ситуаций клиентам.
• Они не имеют интерфейсов, клиенты не получают к ним прямого доступа, а осуществляют его, посылая сообщения назначению (или конечной точке), которое обслуживается bean-объектом. Существует один метод получателя запросов ("onMessage()" в случае bean-объекта JMS, управляемого сообщениями), который обрабатывает все сообщения. Это означает, что во время выполнения с помощью операции "instanceOf()" должна выполняться проверка типов, чтобы определить тип сообщения.

Сообщения могут посылаться контейнеру откуда угодно, в том числе из других объектов EJB, Web-компонентов и клиентских приложений. Контейнер по мере необходимости вызывает управляемые сообщениями объекты EJB, чтобы обработать входящие сообщения. Объекты EJB, управляемые сообщениями, могут получать непосредственный доступ к другому сеансу, объектам EJB сущности или уровню EIS для обработки сообщений.

Идентификация bean-объектов, управляемых сообщениями

Bean-объекты, управляемые сообщениями, предоставляют асинхронный способ обработки сообщений. Сущностные bean-объекты и bean-объекты сеанса могут вызываться только синхронно. Bean-объекты, управляемые сообщениями, идентифицируются как часть определения параллелизма для всей системы. Общее руководство о параллелизме находится в разделе Руководство: Параллелизм, в том числе, шаблоны проектирования для разделения инициатора и вызываемого кода. Bean-объекты, управляемые сообщениями, обычно определяются как часть Задача: Описание архитектуры выполнения в качестве средств обеспечения параллелизма с помощью контейнера EJB. Как таковые они, в общем случае, не определяются непосредственно от классов анализа, а определяются для разрешения специфических проблем проекта, таких как быстродействие или разделение обязанностей.

Некоторые причины для введения bean-объектов, управляемых сообщениями, состоят в следующем:

• Разделение обязанностей между разными областями программного обеспечения. Сообщения могут отправляться в очередь, не имея связи с их получателем. Могут поддерживаться множественные отправители и получатели.
• Увеличение производительности с помощью разрешения отправителю сообщения выполнять обработку вместо его блокировки при синхронном вызове (который происходит при вызове сущностного bean-объекта или bean-объекта сеанса).
• Повышение надежности с помощью разрешения отправителю сообщения продолжать работу, даже если получатели сообщений не подключены.
• Другие преимущества могут быть получены с помощью ориентированного на сообщения промежуточного программного обеспечения (MOM), которое находится за интерфейсом сообщений , например, гарантированная доставка сообщений.
• Существование элемента проекта (например, унаследованной системы), который использует сообщения для взаимодействия.
  

Моделирование bean-объектов, управляемых сообщениями

Общее руководство по моделированию объектов EJB приведено в разделе Руководство: Идентификация объектов EJB. Заметьте, однако, что bean-объекты, управляемые сообщениями, обычно моделируются как часть Представления процесса. Специфические указания по моделированию управляемых сообщениями bean-объектов в Представлении процесса находятся в разделе Руководство: Описание архитектуры выполнения приложения J2EE.

Возврат результатов отправителям сообщений

Bean-объект, управляемые сообщениями не могут прямо посылать ответы отправителю сообщения.

Обычная стратегия отправки ответа состоит во введении другого назначения или конечной точки для ответов. Более подробная информация об этой стратегии находится в разделе [ROM02].