Где проходят границы сети в архитектуре Java Connector (JCA)?

Question

Я пишу адаптер ресурсов JCA.Я также, по ходу дела, пытаюсь полностью понять часть спецификации JCA, касающуюся управления подключениями.В качестве мысленного эксперимента представьте, что единственным клиентом этого адаптера будет клиент приложения Swing Java, расположенный на другом компьютере.Также предположим, что адаптер ресурсов также будет взаимодействовать со своей "корпоративной информационной системой" (EIS) по сети.

Насколько я понимаю спецификацию JCA, файл .rar развертывается на сервере приложений.Сервер приложений создает реализацию интерфейса ManagedConnectionFactory в файле .rar.Затем он запрашивает его создать фабрику соединений, которая представляет собой непрозрачный объект, развернутый в JNDI, чтобы пользователь мог использовать его для получения подключения к ресурсу.(В случае JDBC фабрикой соединений является javax.sql.DataSource.)

Требуется, чтобы фабрика подключений сохраняла ссылку на ConnectionManager, предоставляемый сервером приложений, который, в свою очередь, должен быть сериализуемым.Это имеет смысл - для того, чтобы фабрика соединений хранилась в JNDI, она должна быть сериализуемой, а для того, чтобы она сохраняла ссылку на ConnectionManager, ConnectionManager также должен быть сериализуемым.Итак, этот маленький объектный граф устанавливается в дереве JNDI клиента приложения.

Вот тут-то меня и начинает подташнивать.Является ли ConnectionManager - часть, предоставляемая сервером приложений, которая должна обрабатывать управление соединениями, общий доступ, объединение в пулы и т.д., - Полностью присутствующей на клиенте на данный момент?Одной из его задач является создание экземпляров ManagedConnection, и ManagedConnection не обязательно должно быть сериализуемым, и пользовательские дескрипторы подключений, которые он использует, также не обязательно должны быть сериализуемыми.Это наводит меня на мысль, что весь механизм объединения пулов соединений оптом поставляется клиенту приложения и помещается в его дерево JNDI.

Означает ли все это, что взаимодействия JCA со стороны клиента обходят серверные компоненты сервера приложений?Где находятся границы сети в JCA API?

Answer 1

Означает ли все это, что JCA взаимодействия со стороны клиента обходят серверные компоненты сервера приложений?Где границы сети в JCA API-интерфейс?

АФАИК, да.Будет локальный JNDI, и локальный JNDI будет возвращать локальные соединения.То же самое, если true для объектов другого типа в JNDI, такое значение конфигурации (env-entry).Конечно, если вы ищете EJB, фабрика возвращает прокси удаленному компоненту, но, насколько мне известно, JNDI по-прежнему является локальным.

Клиент встраивает свой собственный пул.Это означает, как вы указали, что соединения, полученные на клиенте, будут недоступны серверному оборудованию.

Ситуация становится еще хуже, когда мы начинаем играть с распределенными транзакциями.Клиент может получить UserTransaction для запуска и остановки распределенных транзакций на стороне клиента (не для всех приложений.однако сервер поддерживает это).Контекст транзакции будет распространяться во время вызовов удаленного EJB.Затем распределенная транзакция может охватывать соединения на стороне клиента и на стороне сервера.

Согласно философии J2EE, клиентское приложение обычно не должно использовать транзакции и получать соединение напрямую;он должен взаимодействовать исключительно с удаленным EJB.

В спецификациях не совсем ясно, что касается более сложного сценария, и информации не так уж много.Спецификация, например, не обязывает сервер приложений предоставлять UserTransaction для клиента.

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