Java 커넥터 아키텍처 (JCA)의 네트워크 경계는 어디에 있습니까?

Question

JCA 리소스 어댑터를 쓰고 있습니다. 또한 JCA 사양의 연결 관리 부분을 완전히 이해하려고 노력 중입니다. 생각한 실험으로,이 어댑터의 유일한 클라이언트는 다른 컴퓨터에있는 Swing Java 응용 프로그램 클라이언트 일 것입니다. 또한 자원 어댑터가 네트워크를 통해 "엔터프라이즈 정보 시스템"(EIS)과 통신 할 것이라고 가정하십시오.

JCA 사양을 이해하면 .rar 파일이 응용 프로그램 서버에 배포됩니다. 응용 프로그램 서버는 .rar 파일의 ManagedConnectionFactory 인터페이스 구현을 만듭니다. 그런 다음 연결 팩토리를 생성하도록 요청합니다. 연결 팩토리는 사용자가 자원에 대한 연결을 확보하는 데 사용할 JNDI에 배치되는 불투명 한 객체입니다. (JDBC의 경우, 연결 팩토리는 javax.sql.DataSource입니다.)

연결 팩토리는 응용 프로그램 서버가 제공하는 ConnectionManager에 대한 참조를 보유해야하며, 이는 다시 필요합니다 직렬화 가능. 이것은 의미가 있습니다. 연결 팩토리를 JNDI에 저장하려면 직렬화 가능해야하며 ConnectionManager에 대한 참조를 유지하려면 ConnectionManager도 직렬화 가능해야합니다. 그러면이 작은 객체 그래프가 응용 프로그램 클라이언트의 JNDI 트리에 설치됩니다.

이것은 내가 기만적으로 시작하는 곳입니다. ConnectionManager - 연결 관리, 공유, 풀링 등을 처리하기로되어있는 응용 프로그램 서버에서 제공하는 부분입니다 -이 시점에서 클라이언트에 전적으로 존재합니까? 그 일의 1 개 (살)은 ManagedConnection 인스턴스를 작성하는 것이고, ManagedConnection은 Serializable 일 필요는 없으며, 사용자 연결 처리는 또한 Serializable 일 필요는 없다. 이는 전체 연결 풀링 기계가 애플리케이션 클라이언트에게 도매로 배송되고 JNDI 트리에 채워진다는 것을 의미합니다.

이는 모두 클라이언트 측의 JCA 상호 작용이 응용 프로그램 서버의 서버 측 구성 요소를 우회 함을 의미합니까? JCA API의 네트워크 경계는 어디에 있습니까?

Answer 1

이 있습니까 모든 의미 JCA가 클라이언트 측 우회에서 상호 작용 응용 프로그램 서버의 서버 측 구성품이? JCA API에서 네트워크 경계는 어디입니까? ?

AFAIK, 예. 로컬 JNDI가 있으며 로컬 JNDI는 로컬 연결을 리턴합니다. JNDI의 다른 종류의 객체에 대해 true 인 경우, 그러한 구성 값 (env-entry). 물론 EJB를 검색하면 팩토리가 원격 빈에 프록시를 반환하지만 JNDI는 여전히 내 지식에 국한됩니다.

클라이언트가 자체 풀을 포함합니다. 즉, 클라이언트에서 얻은 연결이 서버 측 시스템에서 탈출한다는 것을 지적했습니다.

분산 트랜잭션으로 게임을 시작할 때 더욱 악화됩니다. 클라이언트는 UserTransaction을 획득하여 클라이언트 측에서 분산 트랜잭션을 시작하고 중지 할 수 있습니다 (모든 app 서버가 지원하지는 않습니다). 트랜잭션 컨텍스트는 원격 EJB 호출 중에 전파됩니다. 그런 다음 분산 트랜잭션은 클라이언트 측 연결과 서버 측 연결을 확장 할 수 있습니다.

J2EE 철학에 따르면 응용 프로그램 클라이언트는 일반적으로 트랜잭션을 사용하지 않고 직접 연결을 가져야합니다. 그것은 원격 EJB와 전적으로 통신해야합니다.

스펙은 더 복잡한 시나리오에 대해서는 분명하지 않으며 많은 정보가 없습니다.예를 들어, 응용 프로그램 서버가 클라이언트에 UserTransaction을 노출하도록 요구하지 않습니다.

필자가 여기서 쓴 글은 적어도 Glassfish에 적용되지만 모든 응용 프로그램 서버에서 일관된 기능 구현에 의존하지는 않습니다.