Подключение приложения Java EE к внешней системе - PullRequest
4 голосов
/ 10 декабря 2011

У нас есть приложение Java EE, работающее на Glassfish 3.1, которое должно принимать уведомления от устаревшей системы, написанной на Java. Эта устаревшая система предоставляет файл JAR, который должен использоваться любыми внешними приложениями, желающими подписаться на уведомления системы.

При использовании в приложении Java SE библиотека работает следующим образом:

  1. Библиотека инициализируется с параметрами подключения к устаревшей системе
  2. Библиотека подключается к системе и прослушивает уведомления
  3. Наше приложение регистрирует уведомления, реализуя интерфейс
  4. Всякий раз, когда приходит уведомление, метод в классе реализации называется

Мы хотели бы воспроизвести то же самое в Java EE таким образом, чтобы метод EJB вызывался всякий раз, когда система отправляет уведомление.

JCA - это путь? Как насчет одноэлементного EJB, инициализирующего библиотеку и регистрирующего себя в качестве слушателя?

Хорошие примеры по этой теме трудно найти, поэтому, если у вас есть какие-либо рекомендации, я был бы признателен.

1 Ответ

6 голосов
/ 11 декабря 2011

Теоретически JCA действительно будет выделенным API для этого.

Если приложение представляет собой EAR и классы EJB живут в чистом модуле EJB, существуют некоторые ограничения на то, что EJB разрешено делать. JCA может делать именно те вещи, которые EJB запрещены (отражение, статические поля, создание потоков, загрузка собственных библиотек и т. Д.).

Недостатком является то, что JCA - это «тщательно» недокументированный API, который больше предназначен для использования продавцами таких устаревших систем, которые вы описываете, чем «обычными» программистами приложений. Если вы хотите пойти по пути JCA, возможно, одним из источников информации является исходный код Quartz, который содержит адаптер входящего ресурса JCA для Quartz .

Непосредственную регистрацию синглтона в качестве слушателя следует делать осторожно. Устаревшая библиотека должна получить ссылку на прокси-класс Singleton, а не на фактическую реализацию (т.е. не передавать this в унаследованную библиотеку).

Другим вариантом может быть предоставление обычного класса, который реализует необходимый интерфейс и регистрируется в устаревшей библиотеке. Получив уведомление, он может найти фабрику соединений JMS и очередь из JNDI, а затем отправить сообщение JMS, которое прослушивает компонент, управляемый сообщениями.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...