Где находятся границы сети в Java Connector Architecture (JCA)? - PullRequest
3 голосов
/ 10 февраля 2010

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

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

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

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

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

1 Ответ

1 голос
/ 16 марта 2010

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

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

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

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

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

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

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

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