Как использовать HTTPClient изнутри EJB в TomEE

Question

У меня есть компонент EJB3, который должен GET или POST с нескольких HTTP-серверов. Я прочитал документацию по написанию адаптеров JCA, а также документацию по Apache HTTPComponents, в частности управляемые соединения, управляемые фабрики подключений и т. Д., Которые предлагает HTTPClient.

Отметьте, что в документации для BasicHttpClientConnectionManager указано, что оно используется, а не PoolingHttpClientConnectionManager «Внутри контейнера EJB». Неясно, относится ли «внутри контейнера EJB» к пользовательскому коду в EJB для запуска в контейнере или к собственному коду реализации контейнера (например, что-то, что вы могли бы поместить в адаптер JCA.

Я . еще немного непонятно, архитектурно, как справиться с задачей взять максимальное преимущество Servics предлагаемого контейнера до сих пор мой выбор кажется:

1. Изнутри EJB, создать новый BasicHttpClientConnectionManager, а затем создать клиент, например:

    
       BasicHttpClientConnectionManager cxMgr = new BasicHttpClientConnectionManager() 
       HttpClients.custom().setConnectionManager(cxMgr).build() 
   

   Это, я считаю, приведет к объединению пулов соединений, а скорее к пулу экземпляров EJB, который, вероятно, не будет таким, поскольку он не знает, какой экземпляр компонента содержит активное соединение с которым удаленный HTTP-сервер ,

2. Написать (довольно минимальный) JCA адаптер, который облегает PoolingHttpClientConnectionManager, а затем, в EJB, возьмите этот адаптер с @Resource аннотацией и использовать его, чтобы построить HTTPClient

3. Написать адаптер JCA, что управляет пулом HTTPClients и передает их, когда это необходимо.

Я неясно на какой подход следует принять, или я или нет, я не обращая внимания какой-то службы управления HTTP Connection, который уже встроен в контейнер (в данном случае, TomEE плюс). Как мне это сделать?

Answer 1

Это не так просто: ни один из этих вариантов не соответствует. Конкретный ответ зависит от того, является ли удаленная сторона вашего HTTP-соединения единственным ресурсом или нет.

Если это единственный логический ресурс, то JCA соответствует лучшим. Тем не менее, вы вряд ли сможете избежать ссылок на его характер HTTP в своем адаптере: создать правильный логический интерфейс для вашей удаленной системы, а затем реализовать адаптер ресурсов на этом интерфейсе. Ваши клиенты запрашивают данные, которые им нужны, а затем получают их не как строки HTML, а как готовые к использованию Java-компоненты. Вы сможете использовать большую часть преимуществ, предоставляемых контейнером EJB, без нарушения требований.

Если вам нужна точка входа для доступа к неуказанному количеству внешних сервисов (поиск в индексах HTML-страниц может быть такой работой), тогда все становится сложным. JCA не предназначен для использования для такого рода вещей, но он вполне уверен в них: я поддерживаю проект TCP SocketConnector, который делает почти то же самое, и все работает как шарм. EJB здесь не подойдет: объединение с фатальными бинами трудно контролировать, синглтоны потребуют от вас написать неблокирующую реализацию объединения, а состояния - это однопоточные.

Существует также дополнительная опция: в то время как JCA будет легче интегрироваться в существующую среду Java EE, может быть сложно реализовать адаптер ресурсов с нуля, если вы делаете это в первый раз. Здесь может быть полезен внешний инструмент HTTP-запросов, который связан с JMS-очередью.JMS упростит балансировку рабочей нагрузки, но удалит любую интерактивность и может замедлить всю цепочку.

P.S. Для третьего варианта вашего исходного вопроса: нет необходимости реализовывать объединение в JCA, поскольку контейнер уже поддерживает пул соединений для всех экземпляров адаптера ресурсов по умолчанию. Просто сохраните одно HTTP-клиентское соединение на ManagedConnection JCA, и все будет работать готово.