Principios de diseño previstos para Jakarta EE

Hola Habr! Recientemente publicamos el libro " Aprendizaje de Java EE. Programación moderna para grandes empresas " del campeón alemán de Java Sebastian Dashner.


El Sr. Dashner escribe y habla activamente sobre temas relacionados con Java EE moderno, por lo que su blog no ignoró los principios generales de diseño de la plataforma Jakarta EE, ahora desarrollada por Eclipse. La traducción de este artículo en particular (junio) les presentamos hoy.

La plataforma Jakarta EE se está haciendo cargo gradualmente, y junto con ella están surgiendo nuevas especificaciones para el desarrollo empresarial. Para acordar los diversos estándares y tecnologías que están por surgir, toda la comunidad Java EE solo se beneficiará si se desarrollan los principios generales de diseño para las especificaciones de Jakarta EE.

Creo que la tecnología Java EE ha tenido tanto éxito con solo unos pocos principios. A continuación, presentaré mi punto de vista sobre qué principios de diseño que se han desarrollado en Java EE me parecen los más importantes, que merecen un estudio más profundo y que potencialmente pueden servir como recomendaciones para el diseño en Jakarta EE.

Decidí escribir este artículo, inspirado en las propuestas de Dmitry Kornilov sobre la dirección en la que debería ir el desarrollo técnico de Jakarta EE.

Lo primero es la lógica de negocios.

El modelo de programación adoptado en Java EE permite al desarrollador centrarse exactamente en lo que se requiere, es decir, en la lógica empresarial. Ya no necesita heredar clases de API; el desarrollador puede expresar la lógica de su área temática en el lenguaje Java habitual y controlar predominantemente de forma declarativa (mediante anotaciones) el comportamiento del servidor de aplicaciones. Por lo tanto, el marco se integra perfectamente en su código y, en esencia, es igual de fácil de eliminar desde allí. Al diseñar, no confíe en la reutilización, sino en la fácil extracción.

Sin embargo, las implementaciones deberían liberar al desarrollador del trabajo más difícil, es decir, permitirle escapar de los requisitos técnicos que no están relacionados con la lógica empresarial. Algunos ejemplos son el subprocesamiento múltiple, las transacciones, la inversión de control o el procesamiento de solicitudes HTTP. Por el lado de la aplicación, aburrido es bueno :)

Me parece importante que el marco no solo no interfiera con la implementación de la lógica empresarial, sino que también aliente a los programadores a llevar rápidamente las características desarrolladas a la producción. No es necesario pulir el marco para que brille: es mejor llevar el código de la lógica empresarial al ideal. Compare Java EE o Spring modernos con las versiones antiguas de J2EE. Creo que comprenderá de inmediato lo que quiero decir.

Jakarta EE debe desarrollarse en la misma línea y, en consecuencia, centrarse en especificaciones que permitirán a los desarrolladores implementar rápidamente la lógica empresarial.

Convenciones de configuración

Java EE minimiza la configuración requerida para definir una aplicación empresarial típica. En la mayoría de las situaciones prácticas, los acuerdos funcionan desde el primer momento; no se requiere configuración. Por lo tanto, ya no necesita ningún archivo XML para configurar una aplicación Java EE simple. Otro ejemplo es que JAX-RS proporciona códigos de respuesta HTTP predeterminados que corresponden a los valores de retorno de los métodos JAX-RS.

Java EE tiene la flexibilidad de modificar el comportamiento e implementar scripts más complejos; Sin embargo, no hay acuerdo sobre esto.
Yakarta EE debe continuar convirtiendo lo simple en fácil y lo complejo en posible.

Especificaciones de interoperabilidad

Jakarta EE debería continuar y ampliar la interoperabilidad de las especificaciones. Java EE cumple con las especificaciones existentes y la funcionalidad presente en ellas que ya se ha convertido en parte del estándar.

Los desarrolladores pueden confiar en especificaciones dispares para interactuar bien entre sí, sin necesidad de configuración. Estándares exigidos: si el entorno de ejecución admite tanto la especificación A como la especificación B, entonces A + B deben interactuar entre sí. Ejemplos: la validación de componentes, JAXB o JSON-B se pueden usar en las clases de recursos JAX-RS, y no se requiere configuración adicional.

Inyección de dependencia y CDI

Por supuesto, no es deseable que Jakarta EE reinvente las cosas que ya existen, por ejemplo, la inyección de dependencia relacionada con CDI. Es deseable que las especificaciones utilicen y enfaticen las fortalezas del JSR 330 o, si es necesario, del CDI.

Un ejemplo UriInfo es el uso de UriInfo de JAX-RS en métodos de recursos. Anotación @Inject aún no admite la implementación de este tipo de método. Es más conveniente para el programador trabajar, cuanto más confía en el mecanismo universal.

Otra medida específica es esta: los proveedores de CDI deben proporcionarse en las especificaciones y, si es necesario, calificadores de tipo seguro para los tipos que deben crearse. Por lo tanto, en este momento, la instancia del cliente JAX-RS solo se puede obtener mediante programación, a través de la API ClientBuilder . Los fabricantes y los calificadores simplifican el trabajo de un programador al proporcionar definiciones declarativas.

Enfoques declarativos

Por todo esto, la API Java EE se basa en gran medida en un enfoque declarativo, mientras se utiliza la inversión de control. Por lo tanto, los desarrolladores no llaman a la funcionalidad directamente; el contenedor es responsable de llamar a lo funcional, mientras confiamos en las definiciones de código. Ejemplos (de las especificaciones más actuales) son JAX-RS, JSON-B o CDI.

Jakarta EE no solo proporciona API de software más completas, sino que también debe facilitar el uso de definiciones declarativas e inversiones de control.

Estrategias de despliegue

Una característica distintiva (y en mi opinión una gran ventaja) de Java EE es que el modelo de implementación propuesto aquí, en el cual los problemas de lógica de negocios se disocian de la implementación. Los programas de desarrollador exclusivamente para la API, que no forma parte del artefacto de implementación y se implementa mediante el contenedor de la aplicación.
Estos artefactos de implementación compactos simplifican y aceleran la entrega del programa, incluido el ensamblaje, la publicación y la implementación como tal. También son compatibles con los niveles del sistema de archivos contenedor utilizado, por ejemplo, en Docker. Durante el proceso de ensamblaje, solo necesita reconstruir o volver a enviar los elementos modificados.

Idealmente, los artefactos de implementación deberían contener solo lógica de negocios y nada más; Las implementaciones de tiempo de ejecución y las bibliotecas de terceros potencialmente agregadas se entregan en un nivel inferior, por ejemplo, en las bibliotecas del servidor de aplicaciones agregadas en la etapa anterior del ensamblaje del contenedor.

En Yakarta EE, los artefactos desplegados también deben considerarse entidades de primera clase. Tal vez habrá una oportunidad para reforzar aún más el entorno de tiempo de ejecución según la especificación requerida por la aplicación. Sin embargo, Jakarta EE espera prestar la máxima atención a la lógica empresarial y la productividad del desarrollador, y el refinamiento del tiempo de ejecución ya es secundario.

Testabilidad

Aplicando los principios anteriores, especialmente dando preferencia a la programación declarativa y la inyección de dependencia, estamos mejorando la capacidad de prueba del código comercial. Por lo tanto, los desarrolladores pueden crear instancias de objetos directamente en scripts de prueba, porque ahora no necesita heredar clases de API o llamar a funcionalidades inconvenientes que anteriormente necesitaría simular.

Sin embargo, en Jakarta EE es necesario refinar seriamente la estandarización de las pruebas de integración a nivel de código, de modo que no dependa del fabricante. Anteriormente, esto era exactamente con lo que tenía que lidiar cuando trabajaba con Arquillian. En proyectos reales, tal estándar sería útil, lo que le permite declarar solo escenarios de implementación de prueba y funcionalidad de llamada para uno o más componentes. Anteriormente, escribí que no considero que las pruebas de integración a nivel de código sean extremadamente importantes, por ejemplo, cuando ejecuto una aplicación en contenedores integrados. Sin embargo, si estandariza las pruebas de integración a nivel de código, esto claramente tendrá un efecto positivo.

Conclusión

Creo que no es casualidad que las API de Java EE se utilicen tanto en proyectos reales: estas API están bien pensadas y diseñadas de acuerdo con principios claros, gracias a lo cual fue posible unificar no solo una sola especificación, sino una plataforma completa. Le permiten utilizar varias especificaciones a la vez, sostenidas en el mismo espíritu. Aquí, logramos deshacernos de obstáculos artificiales que solo complican el trabajo del programador; por lo tanto, creo que todo el desarrollo empresarial se ha vuelto mucho más agradable.