JCA의 이점은 무엇입니까?

Question

우리의 어플리케이션은 종종 웹 서비스, MQ, JDBC, 독점적 인 (직접 소켓 위) 및 다른 전송 애들을 통해 다른 백엔드 왕들과 연결됩니다. 우리는 이미 애플리케이션에서 이러한 백엔드로 연결할 수있는 여러 가지 구현을 가지고 있으며 이러한 모든 구현은 일반적인 Java 인터페이스를 구현하지만 다른 것들은 공유하지 않습니다.

우리는 이러한 모든 특정 커넥터 구현에 공통적 인 의미있는 부분 코드가 있다는 것을 깨달았으며, 하나의 범용 커넥터를 통해 향후 커넥터 개발을 간소화하기로 결정했습니다. 이 커넥터는 백 엔드가 예상하는 형식으로 메시지를 형식화하고 사용 가능한 전송 메커니즘을 사용하여 메시지를 보낼 수 있습니다. 예 : MQ 또는 소켓을 통한 고정 길이 메시지 형식.

우리가 직면하고있는 딜레마 중 하나는 이러한 종류의 커넥터에 가장 적합한 기술입니다. 지금까지 우리 커넥터는 공통 자바 인터페이스를 구현하는 기본 자바 클래스였습니다. 일반적으로 일부 Java EE 응용 프로그램 서버에서 응용 프로그램을 호스팅하기 때문에 Java Connector Architecture가이 소프트웨어에 가장 적합한 기술이 될 것입니다. 그러나 JCA 호환 커넥터를 구현하는 것은 상대적으로 복잡해 보입니다. 표준 (JCA)에 따라 얻을 수있는 유익한 이점은 무엇이며 혜택으로 추가 노력을 정당화 할 수 있습니까?

Answer 1

실제로 JCA 은이 가장 적합합니다. 이미 탁월한 인수, 즉 이식성, 표준화 된 인터페이스, 연결 풀링 및 트랜잭션 지원이 이루어졌습니다. 그리고 보안을 잊지 마십시오.

WebSphere Process Server에서는 어댑터가 SCA 서비스로 공개 될 수 있으며, 이는 중요한 경우 이점을 많이 가질 수 있습니다.

또한 일부 개발 도구에는 JCA 커넥터 개발 및 테스트를위한 광범위한 지원이 있습니다.

Java EE 관리자 및 Java EE 개발자 (경험)는 표준을 알고 있으므로 관리 및 개발이 간소화되어야합니다.

하지만 결국 프로젝트의 범위, 프로젝트의 향후 계획 또는 회사 정책에 따라 JCA를 구현해야하는 이유를 찾아야합니다.

Answer 2

바인딩 구성 요소가있는 JBI 컨테이너에 적합합니다. JCA 대 JBI의 Discussion.

Answer 3

방금 ​​독점 프로토콜을 통해 통신하는 GPS 장치 용 인바운드 리소스 어댑터를 개발했습니다. 나가는 사람을 개발하는 것이 더 많은 작업을 필요로한다는 인상을 받았지만 그렇게 많은 번거 로움이 아니었다. JCA의 최악은 문서가 없다는 것입니다. 모든 책과 기사는 같은 멍청한 예를 가지고있는 것처럼 보입니다.

내가 가장 기뻐하는 것은 이식성입니다. 어댑터를 작성한 후에는 rar (자원 어댑터 아카이브)를 응용 프로그램 서버에 꽂아 배포 된 응용 프로그램에 지원되는 eis와 통신 할 수있는 기능을 제공 할 수 있습니다. 또는 rar를 war/ear에 묶을 수 있습니다.

Answer 4

이점은 주로 Websphere가 아닌 Websphere에서만 작동하는지 여부를 염려하지 않고 커넥터에 드롭 할 수있는 고객을 위해 모든 응용 프로그램 서버와 함께 사용할 독점 백엔드 시스템에 커넥터를 판매하고자하는 공급 업체를위한 것입니다. 실제로 이것은 일반적으로 Java EE의 목표입니다.

JBoss는 몇 가지를 JCA에 넣기로 결정했습니다. 예를 들어 JDBC 연결은 JCA를 통해 진행됩니다.

향후 클라이언트 코드에는 표준화 된 인터페이스, 일부 풀링 및 트랜잭션 지원 등이 있지만 더 큰 그림을 계속 유지하는 것이 중요합니다. 즉, 혜택은 귀하와 귀하의 특정 프로젝트를 대상으로하는 것이 아니라 많은 응용 프로그램 서버, 많은 백엔드 시스템, 많은 커넥터 등으로 구성된 소프트웨어 환경 시스템에서 이루어집니다.

Answer 5

짧은 답변 : 다른 기술에 비해 JCA를 선택하는 데별로 도움이되지 않습니다. Java EE 컨테이너가 필요하기 때문에이 기술은 단점이라고 생각합니다.

긴 대답은 :

지금은 약간의 시간이 자바 EE 표준에 대한 회의론자있었습니다. 나는 모든 기술에 대한 더 나은 오픈 소스 구현이 있기 때문에 더 이상 완전한 기능의 Java EE 서버를 사용하는 이유가 나타나지 않습니다. 기능이 제공됩니다. 필자는 "enterprisey solutions"로 /에서 "enterprisey solutions"로 이동할 때 구현 불일치로 여러 번 물었습니다.

JCA에 대한 아이디어가 지금 당장 등장하고 있으며 apache camel 또는 spring integration을 대신 사용해 보려고합니다. 나는 어디에서나 사용할 수있는 오픈 소스 구현을 위해 최선을 다하고 있습니다. 그리고 계속 진행되고 있습니다. this list of components을 확인하십시오. 물론, JCA로 이미 개발 된 것보다 작을 수도 있지만 모든 비트는 오픈 소스이며 모든 것이 한 위치에 있습니다. 또한 문서가 더 간단하고 완벽하다고 생각합니다. 통합에 대한 열망은 같은 방식으로 개발 된 동일한 소스에서 발견 할 수있는 많은 오픈 소스, 실제 라이브 예제를 갖춘 강력한 SPI를 필요로합니다.

나는 부정적인 것을 싫어하지만 전 기능을 갖춘 응용 프로그램 서버가 마음에 들지 않습니다. 예를 들어, 나는 바람둥이와 테라코타 에 대해 다른 "enterprisey"제품보다 제품을 사용합니다. JCA에 대한 필요성이 입증 될 때까지 JCA 전에 낙타를 타기 만하면됩니다. 나는 자바위원회가 내가 자신들의 어플리케이션을 어떻게 개발할 것인가를 말하는 것을 좋아하지 않는다. 왜냐하면 내가 그들을 신뢰하지 않기 때문이다. Java EE 환경이나 순수 서블릿 컨테이너 에서처럼 Java SE/RCP 에서처럼 소프트웨어 조각이 쉽게 작동 할 수 있다는 것이 내 최선의 이익이라고 생각합니다.