java-ee => Архитектура Java Connector (JCA)

замечания

Давайте сначала разъясним некоторые термины:

Исходящие сообщения - это сообщение, когда сообщение начинается с сервера (чтобы быть более точным, он инициируется из вашего приложения, которое у вас есть на сервере, WebSphere Liberty в этом случае) и заканчивается в EIS.
Входящие сообщения - это сообщение, которое начинается с EIS и заканчивается на сервере.
Конечная точка сообщения, в общем, место, где сообщение заканчивается сидением / получением на определенном этапе его жизненного цикла.

Таким образом, с исходящей связью мы ссылаемся на ситуацию, когда приложение получает соединение с внешним EIS и считывает или записывает данные на него. С входящей связью мы ссылаемся на ситуацию, когда Resource Adapter (RA) прослушивает события из внешнего EIS и вызывает в ваше приложение при возникновении такого события.

Иллюстрация исходящего RA

Иллюстрация входящего RA

Что означает значение MessageEndPoint в JCA?

Сервер приложений (например, WebSphere Liberty ) предоставляет MBEans конечных точек сообщения, которые помогут вам управлять доставкой сообщения вашим битам, управляемым сообщениями, которые действуют как слушатели на определенных конечных точках, которые являются точками назначения, и в управлении ресурсами EIS, которые используемые этими бобами, управляемыми сообщениями. Компоненты, управляемые сообщениями, которые развертываются как конечные точки сообщения, не совпадают с управляемыми сообщениями компонентами, которые настроены на порт прослушивателя. Компоненты, управляемые сообщениями, которые используются в качестве конечных точек сообщения, должны быть развернуты с использованием ActivationSpecification которая определена в конфигурации RA для JCA (найдена в файле ra.xml ).

Что значит активировать MessageEndPoint?

С помощью MBeans конечной точки сообщения вы можете активировать и деактивировать определенные конечные точки в ваших приложениях, чтобы гарантировать, что сообщения доставляются только для прослушивания управляемых сообщениями компонентов, которые взаимодействуют со здоровыми ресурсами EIS. Эта возможность позволяет оптимизировать производительность ваших JMS-приложений в ситуациях, когда ресурс EIS работает не так, как ожидалось. Доставка сообщения в конечную точку обычно терпит неудачу, когда прослушиваемый bean-компонент сообщения вызывает операцию против ресурса, который не является работоспособным. Например, поставщик сообщений, который является адаптером входящего ресурса, совместимым с JCA, может не доставить сообщения в конечную точку, когда его базовый компонент, управляемый сообщениями, пытается совершить транзакции с сервером базы данных, который не отвечает.

Должен ли MessageEndPoint быть компонентом?

Должно. В противном случае вы окажетесь в большом беспорядке, создав свой собственный нетрадиционный способ делать вещи, которые в первую очередь преследуют цель следовать спецификации Java EE. Создайте свои обработчики сообщений, чтобы делегировать обработку бизнеса другим корпоративным компонентам. Не обращайтесь к ресурсам EIS непосредственно в компоненте, управляемом сообщениями, но делайте это косвенно через компонент делегата.

Можете ли вы показать простой пример работы / развертывания MessageEndPoint?

Проверьте второй ресурс, о котором я расскажу ниже, для полезного примера.

Полезные учебные ресурсы:

Пример адаптера ресурсов

class MyResourceAdapter 
   implements javax.resource.spi.ResourceAdapter {
  
   public void start(BootstrapContext ctx){..}
   public void stop(){..}

   public void endpointActivation (MessageEndpoingFactory mf, ActivationSpec a){..}
   public void endpointDeactivation (MessageEndpoingFactory mf, ActivationSpec a){..}
   public void getXAResources(ActivationSpec[] activationSpecs){..}
}

Modified text is an extract of the original Stack Overflow Documentation

Лицензировано согласно CC BY-SA 3.0

Не связан с Stack Overflow

java-ee
Архитектура Java Connector (JCA)

Поиск…

замечания

Пример адаптера ресурсов