Java, Jetty y Algo Más.

 Durante los últimos años me han preguntado en varias ocasiones por qué AppDTE no fue desarrollado utilizando Spring Boot. La respuesta es bastante simple. Cuando conocí Spring Boot, AppDTE ya era un proyecto maduro. Los primeros años AppDTE no nació como una API REST. Los primeros desarrollos fueron aplicaciones de escritorio utilizando Java Swing. En aquella etapa el objetivo no era desarrollar una aplicación web, sino resolver un problema mucho más complejo: implementar correctamente la facturación electrónica chilena. Con el tiempo el proyecto evolucionó hacia una arquitectura web utilizando Jakarta Servlets y JSP. Posteriormente JSP fue reemplazado por Thymeleaf para simplificar la generación de las vistas administrativas. La interfaz cambió varias veces, pero el verdadero desafío permanecía exactamente igual. El verdadero problema nunca fue la aplicación web Cuando se desarrolla una aplicación tradicional, gran parte del esfuerzo suele concentrarse en la interfaz ...

  Cuando comencé a desarrollar AppDTE, el principal desafío no era construir una aplicación web. El verdadero desafío era implementar correctamente la facturación electrónica chilena. Durante el desarrollo pasé por distintas etapas: Una aplicación de escritorio con Swing. Una aplicación web basada en Servlets y JSP. Posteriormente Thymeleaf para la interfaz administrativa. Sin embargo, independientemente de la interfaz utilizada, el trabajo más complejo seguía siendo el mismo: Generar el XML conforme a los esquemas del SII. Implementar el timbraje electrónico (TED). Firmar digitalmente los documentos XML. Validar la estructura del documento. Enviar los documentos al SII. Procesar las respuestas y estados. Es decir, la mayor parte del esfuerzo estaba concentrado en el núcleo del sistema , no en la tecnología utilizada para presentar la información. Cuando ese núcleo comenzó a estabilizarse, la aplicación terminó con una arquitectura basada en: Java SE ...

El problema de la enseñanza de Java Durante muchos años Java se enseñó muchas veces desde la herramienta y no desde los conceptos. Un estudiante podía aprender: Applets. Swing. JSP. Servlets. JDBC. En mi caso particular, el primer acercamiento a Java fue mediante un applet. La enseñanza se enfocaba en ver que Java podía ejecutarse dentro de una aplicación gráfica o un navegador, pero no necesariamente en comprender conceptos más amplios como diseño orientado a objetos, separación de responsabilidades o arquitectura de aplicaciones. Porque un applet por sí solo no explica: Clase | Objeto | Responsabilidad | Colaboración entre objetos | Sistema completo Un alumno podía entender cómo crear un Applet y sobrescribir un método como paint() , pero eso no necesariamente lo preparaba para diseñar una aplicación empresarial. En mi caso no llegaba a comprender: programación orientada a objetos; responsabilidades de una clase; separación de capas; arquitectura...

Al simplificar una aplicación originalmente pensada para GlassFish descubrí que Jakarta EE puede utilizarse en una expresión mucho más pequeña de lo que normalmente se muestra. No es obligatorio implementar todo el stack empresarial. Dependiendo del problema, basta con utilizar los componentes necesarios para construir la aplicación. Una arquitectura web mínima puede quedar así:                                   Navegador | ▼ Jakarta Servlet | ▼ Capa de servicio | ▼ JDBC | ▼ Base de datos Y para la vista: Servlet | ▼ Thymeleaf | ▼ HTML Mientras que el servidor: Main Java | ▼ Jetty embebido | ▼ Servlet Container La...

Durante mucho tiempo fui de los que decía: "WinForms ya está obsoleto. Hoy todo debería ser web." Era una idea que repetía con bastante convicción. Sin embargo, con el tiempo conversé con tres desarrolladores que mantenían sistemas POS desarrollados en WinForms. Al principio pensé que simplemente estaban conservando aplicaciones antiguas, pero mientras conversábamos y conocía cómo estaban construidos esos sistemas, me di cuenta de que estaba juzgando la tecnología de la interfaz y no la arquitectura completa. Los tres tenían algo en común: utilizaban un cliente WinForms para la operación diaria del punto de venta, pero también contaban con un servidor Linux que cumplía funciones específicas, como la autenticación y la administración de recursos necesarios para operar. Lo que más me llamó la atención fue que ninguno de estos sistemas utilizaba un API para procesar toda la lógica del negocio. La API existía, pero cumplía funciones muy concretas, como la autenticación, la distr...

El SII no proporciona APIs de facturación electrónica: proporciona especificaciones técnicas. Una API (Application Programming Interface) es una interfaz que expone operaciones o funciones para que un cliente las consuma. El proveedor de la API implementa la lógica; el consumidor solo la utiliza siguiendo las reglas establecidas. En cambio, con el SII ocurre algo diferente: El SII publica especificaciones técnicas : formatos XML,especificaciones de firma, esquemas XSD, servicios SOAP, autenticación y envio por http. El desarrollador debe implementar gran parte de la lógica necesaria para generar los documentos, firmarlos, validarlos y comunicarse con el SII. Es decir, el SII no entrega una biblioteca o un SDK que resuelva todo el proceso; entrega la documentación para que tú construyas la integración. Por eso muchas empresas crean su propia capa de servicios o API. Por ejemplo, una empresa puede exponer un endpoint como: POST /api/envioFactura y ese endpoint puede internamente: ...