Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Cumplimiento normativo
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC.
La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto.
En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica.
Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabezeras de la tablas dónde se indican las fechas de entrada en vigor y versión.
Modelo lógico
Para conseguir la independencia, robustez y escalabilidad de los sistemas, y en base a las pautas generales del modelado y diseño de los sistemas de información, las aplicaciones desarrolladas por la STIC deberán ser diseñadas como aplicaciones Web siguiendo un modelo arquitectónico basado en el principio de Separación de Problemas (SoC, Separation of Concerns). Este principio permite el estudio de cada uno de los componentes de un sistema de forma aislada. Es un principio fundamental en el diseño de sistemas complejos empresariales y de la programación Orientada a Objetos.
Este principio aplicado al desarrollo de aplicaciones para el SAS resulta en la siguiente separación lógica:
- Presentación y Control.
- Negocio.
- Integracion.
En la imagen lateral puede verse la arquitectura propuesta por SAS para el desarrollo de aplicaciones web.
Esta separacion nos permite dividir el aplicativo en modulos mas mantenibles y sencillos de evolucionar.
En general la arquitectura de referencia del SAS está basada en el patrón Boundary Control Entity (BCE), esta se aplicara si no se especifica lo contrario.
Como puede observarse, la arquitectura propuesta es independiente de la tecnología a usar, siendo válida tanto para los desarrollos realizados en Java como .NET. Además, es importante destacar que la propuesta que aquí se presenta es un modelo a seguir de forma obligatoria por todos los proveedores de software, si bien es posible la modificación de la misma si fuera necesario, para lo cual será necesario presentar y justificar una propuesta de cambio a la STIC para su valoración y aceptación.
Pautas de diseño
Existen unas pautas básicas a considerar de forma general durante el diseño de los diferentes modulos. Las principales se muestran a continuación.
Presentación y Control
La Presentación muestra el sistema al usuario, presentándole la información y capturando aquella proporcionada por el usuario en un mínimo proceso de filtrado. Esta modulo se debe comunicar únicamente con el modulo de negocio.Se ara uso principalmente del patrón MVC.
Las pautas de diseño generales a adoptar en este modulo son:
- Separación de la lógica de negocio y presentación. La vista debe limitarse únicamente a la presentación de la información al usuario o a solicitársela, nunca a procesarla ni tomar decisiones sobre ella. Tales tareas serán competencia del negocio.
- Desacoplamiento entre modulos. La vista sólo debe contener lógica de visualización, nunca de tratamiento de la información, evitando de esta forma el acoplamiento entre modulos.
- Aspecto gráfico externo. Todos los sistemas deben tener el mismo aspecto gráfico externo a nivel de proyecto, corporativo y/o de función de negocio.
- Modularidad. Las vistas deben diseñarse de forma modular, evitando que cada módulo haga referencia a otros de la misma o de otras vistas. Es el caso, por ejemplo, de los módulos correspondientes a la cabecera, el cuerpo, el menú o pie de las vistas, que deberán integrarse dinámicamente. El grado de reusabilidad de los módulos así como el encapsulamiento de la funcionalidad en cada caso debe de ser muy elevado.
- Internacionalización. Las vistas y por extensión las aplicaciones deben permitir su adaptación a diferentes idiomas y convenciones (formatos de fecha, moneda, etc.) sin necesidad de realizar cambios en su código.
- Validaciones. Deben de realizarse las validaciones formales de los datos introducidos en las vistas, así como las correspondientes a campos obligatorios.
- Elaborar un catálogo de controles. Es recomendable elaborar un catálogo con la lista de controles oficiales en la que se especifique la función de cada control, los posibles validadores/conversores que se le puedan asociar, los eventos que pueda lanzar y los atributos que puedan cambiarse para manipular su aspecto externo. Este catálogo de controles facilitará la creación de las vistas de forma estándar e independiente de los componentes del modulo de negocio. De forma generalizada, no se recomienda la inclusión en este catálogo de controles desarrollados por terceros.
- Gestión de los mensajes de interfaz de usuario. Los mensajes que las aplicaciones devuelvan deben proceder de los controles, del procesado de los datos de la vista (el resultado) o del negocio.
Negocio
El Negocio ocupa un lugar angular en la definición de una infraestructura de software base que permita el crecimiento y la extensibilidad de servicios para todas las aplicaciones existentes y futuras.
La definición de los límites de cada modulo permite definir correctamente la colaboración que proveerá cada una de ellas.
Las principales pautas para el diseño de esta modulo son:
- Elementos constitutivos. El negocio engloba toda la lógica de negocio: reglas, workflow y operaciones no persistentes. Aunque no son parte del negocio como tal las operaciones persistentes deben ser ubicadas junto al negocio.
- Reglas de negocio. El negocio debe ser visto como el punto de acceso único y centralizado al conjunto de servicios expuestos a los modulos que lo usen
- Validaciones de datos. Los servicios de negocio deben realizar las comprobaciones necesarias sobre los datos proporcionados para garantizar su validación previa al inicio de los procesos de negocio requeridos.
- Comunicación entre modulos. La definición de la estrategia de negocio, basada en la creación de las entidades del negocio o los objetos del modelo, se presenta como una fase fundamental en el desarrollo. La comunicación entre modulos se establece mediante estos objetos.
- Transacciones. El manejo de transacciones debe realizarse desde el negocio.
- Tratamiento de excepciones. Debe establecerse una gestión de excepciones según la cuál las mismas se propaguen hacia los modulos que usen el negocioLas excepciones generadas desde la capa de integración o persistencia deben ser encapsuladas en esta capa para ser trasladadas de forma correcta a la capa superior. Debe evitarse, además, el uso de métodos genéricos para la captura de las excepciones, empleando métodos específicos relativos al objeto en cuestión.
- Encapsular los servicios de negocio. Los servicios de negocio son el "puente" entre el usuario y los servicios de datos. Responden ante peticiones del usuario (u otros servicios de negocios) para ejecutar una tarea de este tipo aplicando procedimientos formales y reglas de negocio a los datos relevantes. Cuando los datos necesarios residen en un servidor de bases de datos, garantizan los servicios de datos indispensables para cumplir con la tarea de negocios o aplicar su regla. Esto aísla al usuario de la interacción directa con la base de datos.
- Control sobre el uso de servicios. El control del acceso a los servicios de negocio debe hacerse en el negocio, bien a nivel de servicio vertical (cada Fachada) o a nivel de método dentro de cada servicio.
- Persistencia. Aunque no suele incluirse en el negocio, la persistencia para la mayoria de desarrollos estara modularizada junto con el negocio, aplicando junto con el, el patron BCE.
- Mapeo Objeto-Relacional (ORM). La implementación debe realizarse en base a un mapeo Objeto-Relacional, empleando un motor de persistencia que asegure el correcto funcionamiento.
- Cada objeto debe ser creado en la base de datos para que sea persistente. El patrón CRUD indica que cualquier objeto debe de ser creado como un elemento persistente en la base de datos. Es necesario asegurar que existen operaciones que permitan leer, actualizar o simplemente borrar. Para ello, debe implementarse un DAO distinto por cada objeto de negocio en el sistema.
- Manejo de la Cache. El uso de cachés en el acceso a datos debe realizarse siempre teniendo en cuenta las características del sistema y las necesidades de sincronización. No hay que olvidar el coste de rendimiento derivado de su uso, por lo que el manejo de cachés deberá estar siempre justificado.
- Permitir la concurrencia de usuarios. Debe permitir que múltiples usuarios trabajen en la misma base de datos protegiendo los datos de ser escritos equivocadamente, minimizando las restricciones en su capacidad concurrente para lectura y escritura.
- Evitar las referencias circulares entre objetos. En la medida de lo posible, se deben evitar las referencias circulares, facilitando la localización de los objetos, proporcionando un acceso más efectivo a la información.
- Buen uso de la información oculta. Existen numerosas columnas de tablas que no necesitan ser mapeadas a una propiedad del objeto, conteniendo información oculta para el modelo de objetos pero necesaria para el modelo relacional. En esta categoría entran los mecanismos de auditoría. Al leer el objeto, se lee esta información, que es ocultada al objeto pero mantenida por el framework de persistencia.
- Actualización en cascada. Debe utilizarse la posibilidad que ofrecen los frameworks para la actualización en cascada de objetos. Esta característica permite que las modificaciones hechas a un objeto se repliquen en los objetos relacionados, mejorándose su mantenimiento, la replicación eficiente de los cambios y la integridad de los datos.
- Operaciones en masa. Se deben de permitir las operaciones en masa sobre los datos almacenados, lo que mejora de forma sensible el rendimiento de las operaciones.
Integracion
El modulo de integracion permite tener separado del negocio todas las necesidades de datos de servicios externos a la aplicacion.
Las pautas de diseño generales a adoptar en este modulo son:
- Integraciones con terceros. En este modulo se deben de englobar todos las integraciones con los sistemas externos, exponiendo al negocio una fachada adaptada a las necesidades del propio negocio.
- Adaptadores o mapeadores. Se debe evitar el uso de clases de librerias de integracion de terceros, para ello se propone el uso de adaptadores o mapeadores que faciliten la conversion de los dto externos a internos.
- Librerias de terceros. Las dependencias con librerias de terceros deben estar contenidas en este modulo. Evitando que el negocio dependa directamente con estas librerias.
Infraestructura o Transversales
Adicionalmente a las modulos ya comentadas, puede existir la necesidad de contar con una base que de soporte de herramientas funciones comunes que son usadas a lo largo de la aplicación. En estos modulos cubririán entre otros, los siguientes aspectos:
- La seguridad
- La trazabilidad
- La instrumentación
- El uso de caché
- La gestión de excepciones
- La validación de datos
Estos modulos no seran necesarios a menos que por el tamaño del desarrollo asi lo requiera.
Patron Boundary-Control-Entity (BCE)
El patron BCE llevado a la practica en los desarrollos del SAS define una estructura basica con la siguiente separacion:
- <proyecto>/<business layer>/boundary/
- Se incluyen todos los servicios que proveen de una entrada a esta area de negocio concreta, incluyendo servicios rest, soap y otros servicios usados desde otras areas de negocio.
- <proyecto>/<business layer>/control/
- Aqui se incluyen todos los servicios que proveen funcionalidades/utilidades exclusivamente a los servicios del boundary de su propia area de negocio.
- <proyecto>/<business layer>/entity/
- Objetos de dominio concretos del area de negocio.
La separaciones de cada area de negocio implica cada control solo puede ser usado por su boundary.
Entorno Tecnológico
Estas recomendaciones también serán de aplicación para los desarrollos evolutivos y/o correctivos de sistemas ya desarrollados, si bien se debe tener en cuenta que para tecnologías anteriores (como PHP, Visual Basic, etc.) la inclusión o migración a las nuevas tecnologías no será siempre viable, pudiendo ser recomendable en muchos casos continuar con las tecnologías actuales del proyecto, como la elección de alguna tecnología diferente a las aquí descritas.
Tecnologías de Base y Requerimientos de Entorno
La arquitectura de referencia plasmada en este documento se basa en unas herramientas y tecnologías tomadas como base, y en las que se apoyarán muchas de las decisiones tecnológicas adoptadas. Será necesario por ello tener en cuenta las Normas de Referencia elaboradas por la STI para:
- La Base de Datos Oracle.
- La Explotación de Datos.(BI)
- Integración y Comunicación. (OTI)
- Clientes Web
Asimismo, existen otros requerimientos de entorno propios para que puede consultar cada tecnología JAVA ó .NET .
Referencias
Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Cumplimiento normativo
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC.
La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto.
En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica.
Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es
Obsolescencia
Los nuevos desarrollos enmarcados dentro de la STIC hacen uso de algunas soluciones tecnológicas más actuales. El documento actual, pretende servirle de ayuda para aquellos desarrollos más antiguos, puede ser que su solución provea de una pila tecnológica más actual que la que aquí está descrita. En tal caso se propondrán los asuntos al área de arquitectura para determinar el enfoque.
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabezeras de la tablas dónde se indican las fechas de entrada en vigor y versión.
1. Normativa de Clientes Web
Para una continua actualización y uso de los aplicativos en tecnologías y navegadores modernos, se proponen unas técnicas para eliminar o minimizar la incompatibilidad de los aplicativos entre diferentes navegadores, tecnologías y estilos.
Se recomienda la técnica de "Graceful degradation" para la construcción de los aplicativos, esto quiere decir que se proveerá con la máxima experiencia de usuario en los navegadores más modernos, y esta ira degradándose de manera controlada a un nivel menor en navegadores antiguos, siempre ofreciendo la misma funcionalidad básica.
Hay que hacer foco en tres áreas principales a la hora de la compatibilidad, JavaScript, CSS, y HTML
- JavaScript:
Uso de la especificación ECMAScript 6 (En este enlace podéis comprobar los navegadores compatibles: https://kangax.github.io/compat-table/es6/) CSS3 : Especificación estable de 2021 que contempla multiples temas ( https://www.w3.org/TR/css-2021/ ), en este punto hemos de prospectar la situación de los navegadores, respecto a los selectores que son especificos del navegador, tipo moz- webkit- etc.
En caso de necesitar etiquetas especificas por vendor, se incluiran ambas para dar soporte a mozilla y webkit.
Otras detalles a la hora de desarrollar:
- Seguir el estándar w3c
- Evitar el uso de "hacks", sobre todo hacks de CSS
- No extender el DOM
- Hacer test automáticos de la interfaz
El software desarrollado debe certificar un uso adecuado en navegadores Evergreen ( Se actualizan de forma automática y frecuentemente):
- Basados en motor Chromium
- Firefox
El software debe certificar que en al menos dos versiones anteriores puede ejecutarse sin problemas.
2. Comunicación entre cliente servidor
Para la comunicación cliente servidor, siempre y cuando no haya ningún inconveniente de aplicación de la tecnológica por obsolescencia en los navegadores, será de obligado cumplimiento hacer uso de fetch para articularla.
Dicho modelo se basa en la siguiente especificación viva https://fetch.spec.whatwg.org/#http-network-fetch.
Tenga en cuenta aspectos concretos que pueden resultarle nuevos por el modo en que los navegadores modernos manejan la comunicación, cómo:
- Capitalización en las cabeceras
- Preste atención al modo en que fetch ha de tratar las cabeceras
- Todas las propiedades de las cabeceras a incluir han de ser byte-case-insensitive, aunque se recomienda el uso de: PascalCase (capitalizando todas las palabras) + kebab-case (separando las palabras con guiones) → p.e. "Content-Type"
- Preste atención al modo en que fetch ha de tratar las cabeceras
- Preflight requests
- Fetch hace uso en las implementaciones mas recientes de una llamada previa conocida como "preflight request" que permiten a su cliente web determinar que verbos están disponibles para un recurso rest, y que cabeceras serán obligatorias en posteriores peticiones a dicho recurso. Si su solución contiene tanto una implementación del cliente web y el servidor del recurso, siga las consideraciones indicadas en la información relativa a la implementación de soluciones de servicios rest.
Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Resumen
| Arquitectura tecnológica de referencia Java EE PRE-RELEASE
|
|---|
Cumplimiento normativo
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC.
La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto.
En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica.
Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabezeras de la tablas dónde se indican las fechas de entrada en vigor y versión.
1. Thin Server
La arquitectura microservicios es una aproximación a un modelo de sistemas distribuidos con un estilo que adopta el enfoque de división en componentes. Concretamente es una división que permite la construcción de servicios, entendidos estos como pequeñas unidades de negocio independientes , que pueden funcionar a su vez en conjunto para ofrecer servicios de más alto nivel, comunicándose entre sí a través de peticiones, como por ejemplo HTTP/HTTPS o Websocket , e incluso pueden estar desarrollados en tecnologías diferentes. Este tipo de servicios nos permite contar con infraestructuras de TI adaptables y flexibles, ya que para modificar un único servicio no es necesario alterar el resto de la infraestructura.
Este modelo de arquitectura toma como enfoque la delimitación clara de las unidades de negocio y al independizarlas mantiene las premisas de los principios de responsabilidad asegurando un bajo acoplamiento mejorando la cohesión del código.
Los microservicios suelen presentar las siguientes características:
- Autonomía: Son piezas software independientes que suelen ser desplegadas como servicios aislados, habitualmente sobre plataformas PaaS bajo uso de contenedores como Docker.
- Heterogeneidad: La pila tecnológica de referencia puede ser diferente entre los microservicios ya que en caso de tener que interactuar entre ellos se realizará mediante mecanismos de petición respuesta haciendo uso de una API que cada uno de ellos expone.
- Resiliencia: Este es un factor clave que lo distingue de la arquitectura monolítica, y es que cuando un microservicio falla, este no debe afectar al funcionamiento de los demás. Con esto se consigue que en estos casos se podría tener una degradación de funcionalidades pero no fallas del sistema completo. Esto se consigue con mecanismos de tolerancia a fallos.
- Escalabilidad: Debido a que son piezas software de menor tamaño permiten hacer un escalado mucho más óptimo y utilizar de forma eficiente los recursos de infraestructura permitiendo escalar solo los microservicios necesarios y evitando el desperdicio habitual que puede generar el escalado de las arquitecturas monolíticas.
- Facilidad de despliegue: Al ser de un tamaño reducido se minimiza el riesgo asociado al cambio, ya que el nº de pruebas a realizar es menor y se puede realizar una mayor cobertura de estas. Ante fallos el problema suele aislarse fácilmente, y se pueden liberar rápidamente nuevas versiones. Suelen estar muy vinculados al concepto de "Despliegue Continuo" automatizando tanto un conjunto de pruebas de regresión como el despliegue en los entornos.
- Reutilización de servicios: Facilita enormemente la reutilización, permitiendo por ejemplo que un microservicio pueda ser consumido por una aplicación web, dispositivo móvil, o cualquier otro dispositivo.
- Cohesión: Son piezas de software que resuelven problemas muy concretos (cohesionados).
Para profundizar más sobre los conceptos asociados a los microservicios se puede tomar como referencia los siguientes enlaces:
1.1 - Tecnología de referencia
La arquitectura de referencia para el desarrollo de microservicios en el SAS está basada en Java. Tradicionalmente el desarrollo en Java ha estado marcado por el uso de estándares, y en el caso de aplicaciones empresariales estos se aglutinaron en forma de plataforma bajo la denominación Java EE. Hace algún tiempo Oracle ha cedido el proyecto Java a la comunidad Eclipse y este finalmente ha pasado a denominarse Jakarta. La última versión de esta plataforma es Jakarta EE 8 la cual pone el foco en el desarrollo cloud-native.
En relación a los microservicios la comunidad Eclipse ha elaborado Microprofile el cual permite a los desarrolladores de Java EE aprovechar su conjunto de habilidades existente mientras cambian su enfoque de las aplicaciones tradicionales a microservicios. Este se compone de un subconjunto de estándares Java EE que son extendidos para abordar patrones comunes en el uso de microservicios.
El beneficio de adoptar MicroProfile es que sus especificaciones son impulsados por la comunidad, gratuitos y abiertos, y de las cuales existen múltiples implementaciones eliminando el riesgo del denominado "vendor lock-in" y mantiene la libertad de elección de los desarrolladores. Este continúa evolucionando entregando aproximadamente tres lanzamientos anuales.
La arquitectura de referencia para el desarrollo de microservicios en el SAS estará basada en Microprofile y en el estándar Jakarta EE 8 para aquellos requerimientos técnicos necesarios y no cubiertos actualmente por Microprofile.
| Especificación de referencia: | Microprofile |
|---|---|
| Implementación de referencia: | Cualquier implementación verificada por Eclipse para la versión de Microprofile (https://wiki.eclipse.org/MicroProfile/Implementation). |
| Versión JDK: | Open JDK 11.x (LTS) con la última versión update existente |
Especificaciones a utilizar en la versión de Microprofile: | |
| Conectividad a BBDD: | Se utilizará exclusivamente JPA 2.2 con alguna de las siguientes implementaciones: |
1.2 - Catálogo de verificaciones:
| Identificador | Descripción | Carácter |
|---|---|---|
| ARQ.REF.MSC.01 | Uso de versión Microprofile. | OBLIGATORIO |
| ARQ.REF.MSC.02 | Implementación de conexión a BBDD. | OBLIGATORIO |
1.3 - Documentación de referencia:
2. Fat Server
Java Enterprise Edition o Java EE es una plataforma de programación para desarrollar y ejecutar software de aplicaciones en lenguaje de programación Java. Permite utilizar arquitecturas de N capas distribuidas y se apoya ampliamente en componentes de software modulares, ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE está definida por una especificación, similar a otras especificaciones del Java Community Process (JCP), Java EE es un estándar debido a que los proveedores deben cumplir ciertos requisitos para declarar que sus productos son conformes al mismo.
Java EE tiene varias especificaciones de API, tales como JDBC, EJB, CDI, JMS, JAX-WS, JAX-RS, etc. y define cómo coordinarlos. Ello permite al desarrollador crear una aplicación de empresa portable entre plataformas y escalable, a la vez que integrable con otras tecnologías. Otros beneficios añadidos son, por ejemplo, que el servidor de aplicaciones puede manejar transacciones, seguridad, escalabilidad, concurrencia y gestión de los componentes desplegados, significando que los desarrolladores pueden concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de desarrollo y mantenimiento de bajo nivel.
En los siguientes apartados se detalla las especificaciones técnicas de los servidores existentes en la STIC, siendo por tanto la norma que debe seguirse de forma estricta.
2.1 - Plataforma de ejecución del servidor
| Arquitectura de ejecución | x86-64bits (AMD64/EM64T) |
|---|---|
| Sistema Operativo | Oracle Linux Release 7 Update 3 x86 64 bits |
| Java | Oracle JDK 1.8 |
| Servidor de aplicaciones | Oracle Weblogic Suite 12cR2 12.2.1.3 |
2.2 - Especificaciones de Weblogic
Partiendo de que el servidor de aplicaciones corporativo actualmente es Weblogic Server 12.2.1.3, es necesario tener en cuenta que esta versión cumple la especificación de Java EE7 al completo. Por otro lado, hay que considerar el último PSU disponible para la citada versión de WLS (12.2.1.3) indicada en la siguiente URL de Oracle:
- https://blogs.oracle.com/fusionmiddlewaresupport/july-2019-oracle-weblogic-server-patch-set-update-have-been-released#one
- Patch: 29814665
- Unique Patch ID: 22937216
- Patch description: "WLS PATCH SET UPDATE 12.2.1.3.0(ID:20190522.070630)"
En el siguiente listado se muestra el conjunto de versiones concretas disponibles en esta versión de weblogic:
| Especificación | Weblogic 12.2.1.3 |
|---|---|
Batch Application Processing (JSR 352) | 1.0 |
Contexts and Dependency Injection for Java EE | 1.1 |
Dependency Injection for Java EE | 1.0 |
Concurrent Managed Objects (JSR 236) | 1.0 |
Expression Language (EL) | 3.0, 2.2, 2.1, 2.0 Only JSP 2.0 and greater supports Expression Language 2.x. |
Java API for JSON Processing (JSR-353) | 1.0 |
Java API for XML-Based Web Services (JAX-WS) | 2.2, 2.1, 2.0 |
Java API for RESTful Web Services (JAX-RS) | 2.0 |
Java API for WebSocket | 1.1 |
JavaBeans Activation Framework | 1.1 |
Java EE | 7.0 |
Java EE Application Deployment | 1.2 |
Java EE Bean Validation | 1.1 |
Java EE Common Annotations | 1.2 |
Java EE Connector Architecture | 1.7 |
Java EE EJB | 3.2, 3.1, 3.0, 2.1, 2.0, and 1.1 |
Java EE Enterprise Web Services | 1.3, 1.2, 1.1 |
Jave EE Interceptors | 1.2 |
Java EE JDBC | 4.0, 3.0 |
Java EE JMS | 2.0, 1.1, 1.0.2b |
Java EE JNDI | 1.2 |
Java EE JSF | 2.2, 2.1.*, 2.0, 1.2, 1.1 |
Java EE JSP | 2.3, 2.2, 2.1, 2.0, 1.2, and 1.1 JSP 1.2. and 1.1 include Expression Language (EL), but do not support EL 2.x or greater. |
Java EE Managed Beans | 1.0 |
Java EE Servlet | 3.1, 3.0, 2.5, 2.4, 2.3, and 2.2 |
Java RMI | 1.0 |
JavaMail | 1.5 |
Java Transaction API | 1.2 |
JAX-B | 2.2, 2.1, 2.0 |
JAX-P | 1.3, 1.2, 1.1 |
JAX-R | 1.0 |
JAX-RPC | 1.1 |
JDKs | 8.0 (8.0 and 7.0 for clients) See JDK 8 Certification for details. |
JMX | 2.0 |
JPA | 2.1, 2.0., 1.0 |
JSR 77: Java EE Management | 1.1 |
JSTL | 1.2 |
Managed Beans | 1.0 |
OTS/JTA | OTS 1.2 and JTA 1.2 |
RMI/IIOP | 1.0 |
SOAP Attachments for Java (SAAJ) | 1.3, 1.2 |
Streaming API for XML (StAX) | 1.0 |
Web Services Metadata for the Java Platform | 2.0, 1.1 |
Para mas detalle sobre el entorno Weblogic que finalmente se monta podeis consultar la documentacion de CTI aqui: http://bit.ly/2McFWXD
La arquitectura de referencia establecida por norma para el desarrollo de aplicaciones con tecnología Java EE está basada en el principio de Separación de Problemas ( SoC, Separation of Concerns ). Este principio permite el estudio de cada uno de los componentes de un sistema de forma aislada. Es un principio fundamental en el diseño de sistemas complejos empresariales y de la programación Orientada a Objetos.
Este principio aplicado junto a el patron BCE para la especificacion de Java EE resulta en la separación lógica indicada en la Arquitectura de Referencia Común.
Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Cumplimiento normativo
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC.
La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto.
En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica.
Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabezeras de la tablas dónde se indican las fechas de entrada en vigor y versión.
.NET Framework es un entorno de ejecución administrado que proporciona diversos servicios a las aplicaciones en ejecución. Consta de dos componentes principales: Common Language Runtime (CLR), que es el motor de ejecución que controla las aplicaciones en ejecución, y la biblioteca de clases de .NET Framework, que proporciona una biblioteca de código probado y reutilizable al que pueden llamar los desarrolladores desde sus propias aplicaciones. Los servicios que ofrece .NET Framework a las aplicaciones en ejecución son los siguientes:
- Administración de la memoria. En muchos lenguajes de programación, los programadores son responsables de asignar y liberar memoria y de administrar la vida útil de los objetos. En las aplicaciones de .NET Framework, CLR proporciona estos servicios en nombre de la aplicación.
- Sistema de tipos comunes. En los lenguajes de programación tradicionales, el compilador define los tipos básicos, lo que complica la interoperabilidad entre lenguajes. En .NET Framework, los tipos básicos los define el sistema de tipos de .NET Framework y son comunes a todos los lenguajes que tienen como destino .NET Framework.
- Biblioteca de clases extensa. En lugar de tener que escribir cantidades extensas de código para controlar operaciones comunes de programación de bajo nivel, los programadores pueden usar una biblioteca de tipos accesible en todo momento y sus miembros desde la biblioteca de clases de .NET Framework.
- Marcos y tecnologías de desarrollo. .NET Framework incluye bibliotecas para determinadas áreas de desarrollo de aplicaciones, como ASP.NET para aplicaciones web, ADO.NET para el acceso a los datos y Windows Communication Foundation para las aplicaciones orientadas a servicios.
- Interoperabilidad de lenguajes. Los compiladores de lenguajes cuya plataforma de destino es .NET Framework emiten un código intermedio denominado Lenguaje intermedio común (CIL), que, a su vez, se compila en tiempo de ejecución a través de Common Language Runtime. Con esta característica, las rutinas escritas en un lenguaje están accesibles a otros lenguajes, y los programadores pueden centrarse en crear aplicaciones en su lenguaje o lenguajes preferidos.
- Compatibilidad de versiones. Con raras excepciones, las aplicaciones que se desarrollan con una versión determinada de .NET Framework se pueden ejecutar sin modificaciones en una versión posterior.
- Ejecución en paralelo. .NET Framework ayuda a resolver conflictos entre versiones y permite que varias versiones de Common Language Runtime coexistan en el mismo equipo. Esto significa que también pueden coexistir varias versiones de las aplicaciones, y que una aplicación se puede ejecutar en la versión de .NET Framework con la que se compiló.
- Compatibilidad con múltiples versiones (multi-targeting). Al usar la Biblioteca de clases portable de .NET Framework, los desarrolladores pueden crear ensamblados que funcionen en varias plataformas, como Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Phone y Xbox 360.
NET Core es una versión modular de .NET Framework diseñada para que sea portátil entre plataformas, a fin de permitir la reutilización del código al máximo y su uso compartido.
.NET Core es portátil entre plataformas porque, aunque se trata de un subconjunto de la versión completa de .NET Framework, proporciona una funcionalidad clave para implementar las características de la aplicación que necesita y reutilizar este código independientemente del destino de la plataforma. Antes, las distintas versiones de .NET para diferentes plataformas carecían de funcionalidad compartida para las tareas clave, como por ejemplo la lectura de archivos locales.
Las plataformas de Microsoft que podrá establecer como destino con .NET Core incluyen Windows, Linux, MacOs, así como dispositivos y teléfonos usando herramientas como Xamarin,permitiendo el uso en dispositivos Windows, IOS y Android.
1. Plataforma de ejecución del servidor
| Arquitectura de ejecución | x86-64bits (AMD64/EM64T) |
|---|---|
| Sistema Operativo | Windows Server XXXX |
| Plataforma Objetivo | .NET Framework 4.6.1 .NET Standard 1.4 .NET Core 1.0 |
2. Entorno Tecnológico
| Lenguaje | C# v6 |
|---|---|
| Framework Desarrollo Web | ASP.NET MVC 5 / ASP.NET Core |
| ORM | Entity Framework 6 / Entity Framework Core |
| Ioc/DI | DryIoc / LightInject / Simple Injector |
| Identidad | ASP.NET Identity |
3. Diseño y Modularidad
Tener una estructura común y estandarizada permite a desarrolladores trabajar de forma similar en cualquier proyecto, simplificando con ello el entendimiento del mismo.
Modulo de presentación
Se recomienda el uso de ASP.NET Core, aunque se permita el uso de ASP.NET MVC 5.
La estructura de un proyecto .NET Web para el modulo de Presentacion debe adaptarse lo maximo posible ha esta organización:
ASP.NET MVC
- Directorio App_Data.
Este directorio está pensado para ubicar archivos de datos, normalmente bases de datos MSSQL. También es el lugar adecuado para archivos XML o cualquier otra fuente de datos. - Directorio App_Start.
Este directorio contiene los archivos de código que se ejecutan al inicializar la aplicación.. - Directorio Content.
El directorio Content está pensado para el contenido estático de la aplicación, especialmente útil para archivos css e imágenes asociadas. - Directorio Scripts.
El directorio scripts está pensado para ubicar los archivos de javascript (*.js). El código javascript es ejecutado en el contexto del navegador, es decir, en la parte cliente, y nos permite ejecutar acciones sin necesidad de enviar los datos al servidor.
ASP.NET Core
- Directorio wwwroot
En este directorio se ubica todo el contenido estatico del projecto - Directorio Dependencies
Es el directorio usado para gestionar las dependencias de Bower y NPM - Fichero Program.cs
Es el fichero mas importante del proyecto. Esta clase es usada para inicializar, construir, y ejecutar el servidor(IIS y Kestrel) y alojar la aplicacion. Aqui tambien se define la raiz del proyecto. - Fichero Startup.cs
Esta clase es la que permite configurar los Middlewares necesarios para las peticiones a la aplicacion.
Comun
- Directorio Controllers.
El directorio controllers en el lugar para los controladores, que son las clases encargadas de recibir y gestionar las peticiones http de la aplicación. - Directorio Models.
El directorio models es la ubicación que nos propone ASP.NET para las clases que representan el modelo de la aplicación, los datos que gestiona nuestra aplicación. - Directorio Views.
El directorio Views contiene los archivos de vista. Los controladores devuelven vistas sobre las que inyectamos el modelo de nuestra aplicación. Estas vistas son interpretadas por el motor de renderización. Son archivos similares a aplicaciones de ASP clasico, donde tenemos código HTML estático y determinadas zonas de código que son ejecutadas en el servidor.
Otros Módulos
Para el resto de módulos se debe de seguir una estructura guiada por el patrón BCE segun se describe en la documentación de Arquitectura de Referencia Común.
Se recomienda el uso de .NET Standard para mayor compatibilidad de entornos.
Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Resumen
- Versión: v01r13
- Fecha publicación:
- Entrada en vigor desde
Cumplimiento normativo
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC.
La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto.
En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica.
Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabezeras de la tablas dónde se indican las fechas de entrada en vigor y versión.
1. Arquetipo de Ejemplo
Desde el el Área de Arquitectura proporcionamos un ejemplo de aplicativo funcional que permite a los proveedores entender mejor como debería de ser un proyecto siguiendo las normativas vigentes.
El objetivo de este arquetipo es ofrecer a los proveedores de software un ejemplo típico de sistema de información con interfaz web, ilustrando como debe gestionarse la navegación entre pantallas, controladores, servicios y bases de datos
Dependencias
Arquetipo de ejemplo | ||||
|---|---|---|---|---|
| 6.0.0 | 1.0.0.1 | 1.4.0.1 | 1.3.0.1 | 1.0.0.1 |
Funcionalidad del ejemplo
El ejemplo diseñado se trata de un pequeño sistema de información capaz de gestionar historias clínicas y episodios, contando además con un sistema de gestión de usuarios que se encargará de autenticar a los operadores del sistemas y validar los permisos de acceso que tiene cada uno
Diseño
En la siguiente imagen puede observarse las principales clases que componen nuestro proyecto, marcando en amarillo aquellas clases que representan entidades de información y en azul a los servicios de acceso a los mismos.
1. Introducción
Esta librería permitirá obtener configuración de diferentes orígenes y hacer uso de ellos de una forma simplificada en los aplicativos.
Puede encontrarse un ejemplo de integración de esta librería en el repositorio Git de esta librería.
2. Desplegar arquetipo
Requisitos
El presente ejemplo se ha realizado siguiendo la arquitectura de referencia propuesta por la STIC para el desarrollo de aplicaciones java. Por ello, este proyecto de ejemplo necesita los siguientes elementos de configuración:
- Oracle Weblogic 12.1.3
- Base de datos Oracle 11gR2
(*) Si lo desea, en el archivo persistence.xml puede modificar la unidad de persistencia y configurar el proyecto para que funcione con una base de datos en memoria, no siendo necesario contar con una base de datos externa
Instrucciones de uso
- En base de datos, crear un esquema de usuario, por ejemplo TEST_OWN
- En Weblogic, crear un Origen de datos llamado "jdbc/myDatasource"
- En Weblogic, desplegar las siguientes librería en weblogic (Oracle_Home\wlserver\common\deployable-libraries):
- Archivo WAR jax-rs-2.0.war
- Archivo WAR jsf-2.0.war
- En nuestro IDE de desarrollo, por ejemplo Eclipse, importar proyecto "javaee7-sample" desde el del SAS (http://git.sas.junta-andalucia.es/examples/javaee7-sample/)
- Añadimos el proyecto a Weblogic
- Iniciar Weblogic
- Introducir ruta de acceso en un navegador: http://localhost:7001/sample/faces/pages/patients/patients.xhtml
(*) El sistema de autenticación y autorización ha sido implementado haciendo uso de Apache Shiro
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2