¿Cuáles son los beneficios de JCA?

Question

Nuestra aplicación a menudo se conecta a diferentes servidores de back-ends sobre servicios web, MQ, JDBC, de propiedad (directo sobre socket) y otros hijos de transporte. Ya contamos con varias implementaciones que nos permiten conectarnos desde nuestra aplicación a estos back-ends y, aunque todas estas implementaciones implementan la interfaz común de Java, no comparten nada más.

Nos hemos dado cuenta de que hay porciones de código de significación que son comunes para todas estas implementaciones de conector en particular y hemos decidido simplificar el desarrollo de futuros conectores a través de un conector universal. Este conector será capaz de formatear los mensajes a un formato esperado por el back-end y enviarlos usando el mecanismo de transporte disponible. Por ejemplo: formato de mensaje de longitud fija sobre MQ o sobre socket.

Uno de los dilemas que enfrentamos es la tecnología más adecuada para este tipo de conector. Hasta ahora, nuestros conectores eran clases básicas de Java que implementan la interfaz común de Java. Como generalmente alojamos nuestras aplicaciones en algún servidor de aplicaciones Java EE, parece que Java Connector Architecture sería la tecnología más adecuada para este software. Sin embargo, la implementación del conector compatible con JCA parece ser relativamente compleja. ¿Cuáles son los beneficios palpables de ir con el estándar - JCA y los beneficios justifican un esfuerzo adicional?

Answer 1

Indeed JCA parece la tecnología más adecuada para usted. Ya se han realizado argumentos excelentes, a saber, la portabilidad, la interfaz estandarizada, la agrupación de conexiones y el soporte de transacciones. Y no olvides la seguridad.

Con WebSphere Process Server, los adaptadores se pueden exponer como un servicio SCA que puede tener muchos beneficios si eso es importante para usted.

También algunas herramientas de desarrollo cuentan con un amplio soporte para desarrollar y probar conectores JCA.

Otro beneficio es (experimentado) Los administradores de Java EE y los desarrolladores de Java EE (deberían) conocer el estándar por lo que la administración y el desarrollo deberían ser fáciles de simplificar.

Pero al final debe tener que encontrar razones para implementar JCA en función del alcance de su proyecto, los planes futuros que tenga para su proyecto o tal vez dentro de la política de su empresa.

Answer 2

Suena como un buen uso para un contenedor JBI con componentes de unión. Discussion de JCA vs JBI.

Answer 3

Acabo de desarrollar un adaptador de recursos entrantes para un dispositivo gps que se comunica a través de un protocolo propietario. No fue mucha molestia, aunque tengo la impresión de que desarrollar un mensaje de salida podría requerir más trabajo. Lo peor con el JCA es la falta de documentación. Todos los libros y artículos parecen tener el mismo tonto ejemplo.

Lo que más me agrada es la portabilidad. Una vez que haya escrito el adaptador, puede conectar el rar (archivo de adaptador de recursos) en cualquier servidor de aplicaciones para proporcionar a las aplicaciones implementadas la capacidad de comunicarse con eis compatibles con su ra. O puede agrupar el rar en la guerra/oreja.

Answer 4

Las ventajas son principalmente para los proveedores que desean vender conectores a sistemas finales propietarios para usar con cualquier servidor de aplicaciones, para clientes que desean colocar un conector sin preocuparse de si solo funciona en WebLogic o Websphere , etc. De hecho, este es el objetivo de Java EE en general.

Tenga en cuenta que JBoss ha decidido incluir varias cosas en JCA, por ejemplo, las conexiones JDBC pasan por JCA.

Su futuro código de cliente tendrá una interfaz estandarizada, un poco de agrupación y soporte de transacciones, etc. pero es importante tener una visión más amplia; a saber, que los beneficios no están dirigidos específicamente a usted ni a su proyecto, sino a un ecosistema de software que consta de muchos servidores de aplicaciones, muchos sistemas de respaldo, muchos conectores, etc.

Answer 5

Respuesta corta: No veo ningún beneficio en seleccionar JCA sobre otras tecnologías, lo veo como un inconveniente ya que necesita un contenedor Java EE.

Respuesta larga:

he sido escéptico acerca de estos estándares Java EE desde hace algún tiempo. No veo una razón convincente técnica razón para utilizar un servidor Java EE con todas las características más, ya que hay mejores implementaciones de código abierto para cada característica que se ofrece. Me han picado varias veces las incompatibilidades de implementación cuando me movía hacia/desde "soluciones empresariales".

La idea de JCA está emergiendo aquí ahora mismo y estoy presionando para probar apache camel o spring integration en su lugar. Estoy totalmente de acuerdo con las implementaciones de código abierto que puede usar en cualquier lugar. Y están sucediendo muchas cosas. Compruebe this list of components. De acuerdo, tal vez es más pequeño de lo que ya se desarrolló con JCA, pero cada bit es de código abierto y está todo en un solo lugar. Además, creo que la documentación es más simple y completa. El impulso de integración requiere un SPI potente con muchos ejemplos de código abierto y real, desarrollados de la misma manera y que se pueden encontrar en el mismo lugar.

Odio la negatividad, pero no me gustan los servidores de aplicaciones con todas las funciones. Por ejemplo, iría por tomcat y terracota cualquier día sobre otros productos "empresariales", al igual que iría con camello antes que JCA, hasta que se demuestre la necesidad de JCA. No me gusta la idea del Comité Java para decirme cómo debo desarrollar mis propias aplicaciones porque no confío en ellas. Creo que es lo mejor para mí cuando la pieza de software puede funcionar con la misma facilidad en Java SE/RCP que en entornos Java EE o en un contenedor Servlet puro.