Para poder entender mejor a Xorcery vamos a explicar los bloques de construcción sobre los cuales reside el framework. En Xorcery hacemos uso de Jetty y Jersey.
Jetty
Jetty, es un servidor web y contenedor de servlets ligero preparado para ser embebido en nuestras aplicaciones. La distribución que usamos es la de eclipse y posee las siguientes características:
- Es un servidor HTTP asíncrono
- Es un Contenedor de Servlet estándar
- Es un servidor de Web Sockets
- Posee un cliente HTTP asíncrono
- Soporta OSGI, JNDI, JMX, JASPI, AJP.
Jersey
Desarrollar servicios web RESTful que admitan sin problemas la exposición de sus datos en una variedad de tipos de medios de representación y abstraigan los detalles de bajo nivel de la comunicación cliente-servidor no es una tarea fácil sin un buen conjunto de herramientas. Para simplificar el desarrollo de servicios web RESTful y sus clientes en Java, se ha diseñado una API JAX-RS estándar y portátil.
El framework Jersey RESTful Web Services 2.x es un marco de código abierto y de calidad de producción para desarrollar servicios web RESTful en Java que brinda soporte para las API JAX-RS y sirve como implementación de referencia JAX-RS (JSR 311, JSR 339 y JSR 370).
El framework Jersey RESTful Web Services 3.x brinda soporte para Jakarta RESTful Web Services 3.0.
El framework Jersey es más que la implementación de referencia JAX-RS. Jersey proporciona su propia API que amplía el kit de herramientas JAX-RS con funciones y utilidades adicionales para simplificar aún más el servicio RESTful y el desarrollo de clientes. Jersey también expone numerosos SPI de extensión para que los desarrolladores puedan ampliar Jersey para satisfacer mejor sus necesidades.
Módulos en Java
Todo el código en Xorcery está desarrollado usando Java Modules. Si tienes problemas para entender esta organización disponible desde Java 9, te recomiendo ver este link (puedes usar los subtítulos en español o inglés).
En español encontré esta buena charla para que puedan entender el trabajo de un proyecto en módulos: Modularidad en Java, creación y migración de aplicaciones.
GlassFish HK2 - Inyección de Dependencias
GlassFish HK2 3.0 API, es un framework declarativo para servicios usando anotaciones como Contract y Service. Está basado en Jakarta Dependency Injection (DI) standard annotation. Lo estamos usando como framework de inyección de dependencias en Jersey y habilitando el auto-scanning para auto-descubrir los componentes marcados como @Contract y @Service.
Puede encontrar un ejemplo al respecto en este link: https://mkyong.com/webservices/jax-rs/jersey-and-hk2-dependency-injection-auto-scanning/
Uso en Xorcery para tener mTLS
En la búsqueda de conseguir comunicación encriptada mTLS de servidor a servidor, se ha activado el TLS para HTTP 1.1 y HTTP/2 y el soporte para certificados cliente y así obtener soporte mTLS.
Este tipo de comunicación lo debe ud. Haber leído o conocido al usar un Service Mesh. Pero Xorcery, lo que desea es evitar tal complejidad y ofrecerle el mismo tipo de comunicación segura entre servicios.
Por tal motivo, en el código fuente encontrará:
- xorcery-certificates: el código que inicia el aprovisionamiento, configura el programador de renovación de certificados y almacena el certificado en el KeyStore, etc. Esto puede ejecutarse tanto en el cliente como en el servidor, y define un SPI
- xorcery-certificates-client: implementa SPI y delega al servidor remoto a través de HTTP. Opcionalmente, puede admitir el reto HTTP01 ACME
- xorcery-certificates-server: proporciona API JAXRS que los clientes (2.) pueden llamar y luego delega en implementaciones SPI
- xorcery-certificates-letsencrypt: Implementación Let's Encrypt de SPI, se puede ejecutar en "cliente" o "servidor", ambos funcionarían.
- xorcery-certificates-ca: nuestra propia implementación CA del SPI
Se ha buscado diseñar el SPI cuidadosamente, para tener una configuración más limpia y que haga posible el uso de Let's Encrypt y nuestro propio CA al mismo tiempo (hacen cosas diferentes y tienen ventajas y desventajas cada uno).
Se pueden ejecutar en modo independiente (donde cada servidor realiza el aprovisionamiento por sí mismo) o en modo cliente-servidor donde el aprovisionamiento/renovación está centralizado.
Los servidores ahora pueden recibir certificados de nuestra propia CA o Let's Encrypt, o ambos (lo que hace posible el SNI).
La validación de la Solicitud de firma de certificado ahora admite opcionalmente la autofirma, por lo que no es necesario distribuir la clave de aprovisionamiento si sabe que todas las CSR provienen de su propia red.
JWT Autenticación y Autorización
También tenemos un módulo xorcery-jwt que:
- Expone un login endpoint (username/password). De esta manera, los clientes podrán realizar la autenticación.
- Tiene un SPI para permitir que el plugin provea JWT Claims.
En xorcerty-jetty-server también se ha agregado soporte para Jetty contraints mappings de manera que se pueda agregar requerimientos de autorización. Básicamente, se verificará los "roles" de los claims JWT (como una serie de nombres de roles) con los requisitos de roles de una ruta mapeada. Con esto último ya tenemos un nivel de autorización.
Uso en clientes
Con todo lo anteriormente explicado, ahora podrá configurar en sus clientes la información de certificados, recursos REST API, información del jetty server, JWT issuer, etc.
La siguiente configuración la tomo de xorcery-examples:
application.name: "forum"instance.home: "{{ SYSTEM.jpackage_app-path ? jpackage.app | SYSTEM.user_dir}}"jpackage.app: "{{ SYSTEM.jpackage_app-path }}/../../lib/app"# So that we can generate a SSL certificate for the local hostname. Replace with whatever domain name you actually useinstance.domain: local# Add local convenience names for your own computer into the SSL certcertificates:dnsNames:- localhost- "{{ instance.host }}"ipAddresses:- 127.0.0.1- "{{ instance.ip }}"# REST API resourcesjersey.server.register:- com.exoreaction.xorcery.examples.forum.resources.api.CommentResource- com.exoreaction.xorcery.examples.forum.resources.api.ForumResource- com.exoreaction.xorcery.examples.forum.resources.api.PostCommentsResource- com.exoreaction.xorcery.examples.forum.resources.api.PostResource- com.exoreaction.xorcery.examples.forum.resources.api.PostsResourcedns.client.search:- xorcery.testdns.client.hosts:_certificates._sub._https._tcp : "https://127.0.0.1"dns.client.nameServers:- 127.0.0.1:8853jetty:server:http:port: 8080ssl:port: 8443security:jwt:issuers:server.xorcery.test: "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQ....."# These features can be extracted into separate servicesjwt.server.keys:- keyId: "2d3f1d1f-4038-4c01-beb7-97b260462ada"alg: "ES256"publicKey: "secret:MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQ...."privateKey: "secret:MEECAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQ...."dns.server.port: 8853# Log configurationlog4j2.Configuration:name: Xorcery Example Forumstatus: warnthresholdFilter:level: traceappenders:Console:name: STDOUTtarget: SYSTEM_OUTPatternLayout:Pattern: "%d [%t] %-5level %marker %c{1.}: %msg%n%throwable"# Log4jPublisher:# name: Log4jPublisher# PatternLayout:# Pattern: "%d [%t] %-5level %marker %c{1.}: %msg%n%throwable"Loggers:logger:- name: org.apache.logging.log4jlevel: debugadditivity: falseAppenderRef:ref: STDOUT- name: com.exoreaction.xorcery.core.Xorcerylevel: debug- name: com.exoreaction.xorcery.servicelevel: debug- name: com.exoreaction.xorcery.dnslevel: traceRoot:level: infoAppenderRef:- ref: STDOUT# - ref: Log4jPublisher
En los siguientes artículos vamos a explicar que otros bloques de construcción posee Xorcery y el porqué de su uso para finalmente terminar en las demos de micro servicios.
Sean bienvenidos de antemano sus Pull Requests a este framework.
Enjoy!
Jose
0 comentarios:
Publicar un comentario