Доступ к архитектуре соединителя Java (JCA) из неуправляемой среды

Мы использовали JCA для взаимодействия с низкоуровневым сетевым ресурсом из WebSphere, однако у нас есть требование иметь доступ к тому же сетевому ресурсу извне из Tomcat (т. е. не в управляемой среде). Макеты сетевых коммуникаций и протоколов очень многословны, поэтому мы бы не стали копировать/вставлять несколько тысяч строк кода (и затем поддерживать их отдельно).

Судя по спецификации JCA, предположительно существует некоторая поддержка выполнения кода в неуправляемой среде (например, Tomcat). К сожалению, я понятия не имею, что должны делать интерфейсы или как вызывать их вне управляемой среды (спецификация довольно расплывчата).

Существуют ли какие-либо примеры реализации, показывающие, как модифицировать JCA, чтобы его можно было использовать в неуправляемой среде?

Спасибо!


java jca jakarta-ee
person Paul Kuykendall    schedule 03.05.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

У нас был похожий случай, когда мы разработали коннектор для доступа к внешнему хранилищу WebDav и хотели использовать его также из автономного приложения (неуправляемого).

Я считаю, что проще всего решить эту проблему на уровне проектирования и организовать код таким образом, чтобы основная логика коннектора не зависела от JCA и могла быть легко использована повторно. Затем вы можете обернуть это кодом, специфичным для JCA, который предоставляет соединитель для AS. Вероятно, его можно было бы даже упаковать в два jar — по крайней мере, это решение, которое мы выбрали (но мы упаковали все в один .jar).

В противном случае разъем JCA является «клеем» между следующими тремя сторонами:

  1. сервер приложений
  2. ЕИС
  3. Компонент приложения.

Должна быть возможность смоделировать AS с облегченной реализацией необходимых классов, а затем напрямую использовать коннектор JCA.

Одной из основных задач AS по отношению к коннектору JCA является управление объединением соединений, и, насколько я помню, соответствующий интерфейс, который вы затем должны реализовать, это ConnectionManager.

Соединитель JCA получает ссылку на ConnectionManager, но реализация зависит от AS. Написание облегченной реализации, обеспечивающей элементарное объединение (или вообще отсутствие объединения), кажется осуществимым.

Однажды я написал диаграмму последовательности механизма распределения соединений. Может быть, вы найдете это полезным. Другой интерфейс — ResourceAdapter, где вы определяете запуск/завершение работы, но его легко вызвать вручную.

(Вероятно, это немного больше, и это, конечно, зависит от того, что использует ваш коннектор JCA. Например, если он использует Work и WorkManager, то становится намного сложнее имитировать. То же замечание, если коннектор является транзакционным. , но похоже это не ваш случай.)

В противном случае, я думаю, что Spring имеет некоторую поддержку JCA, возможно, стоит посмотреть, как они это сделали.

Судя по спецификации JCA, предположительно есть некоторая поддержка выполнения кода в неуправляемой среде.

Можете ли вы упомянуть конкретную часть спецификации, о которой вы говорите?

person ewernli    schedule 03.05.2010
comment
Моя ссылка на спецификацию основана на различных подразделах, таких как 3.4, 5.3.8, 6.4.2 и т.п., в спецификации JCA 1.5. Спасибо за помощь. К сожалению, похоже, что наш код слишком тесно привязан во всех неправильных местах к управляемым частям спецификации. - person Paul Kuykendall; 07.05.2010