Consejería de Hacienda y Administración Pública · 3 ARQUITECTURA EN JAVA.....9 3.1...

Consejería de Hacienda y Administración Pública

Dirección General de Tecnologías de la Información y Comunicación

MADES

Arquitectura

06/03/2018

Queda prohibido cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación pública y/o transformación,total o parcial, por cualquier medio, de este documento sin el previo consentimiento expreso y por escrito de la Consejería de Hacienda yAdministración Pública de la Junta de Extremadura.



Avda. Valhondo S/NEdificio III MilenoMódulo 2 - 3ª planta06800 - Mérida

JUNTA DE EXTREMADURA

MADES

Arquitectura

HOJA DE CONTROL

Proyecto MADES (Marco para el Desarrollo y Mantenimiento de los S.I.)

Documento Arquitectura

Nombre del Fichero MADES - Arquitectura.odt

Autor

Versión/Edición 1.0 Fecha Versión 06/03/2018

Aprobado por Fecha Aprobación

REGISTRO DE CAMBIOS

Versión Causa del Cambio Responsable del Cambio Área Fecha del Cambio

CONTROL DE DISTRIBUCIÓN

Nombre y Apellidos Cargo Área Nº Copias

Página 2 de 31





MADES

Arquitectura

ÍNDICE

1 INTRODUCCIÓN ........................................................................................................ 4

1.1 Objeto .................................................................................................................................................. 4 1.2 Alcance ................................................................................................................................................. 4 1.3 Ámbito de Responsabilidades ......................................................................................................... 4 1.4 Revisión de la Norma ....................................................................................................................... 4 1.5 Publicación de la Norma .................................................................................................................. 4

2 CRITERIOS GENERALES ............................................................................................ 5

2.1 Diseño y construcción por capas .................................................................................................. 5 2.2 Frameworks de Desarrollo ............................................................................................................. 8 2.3 Arquitectura Cliente-Servidor ....................................................................................................... 8

3 ARQUITECTURA EN JAVA ....................................................................................... 9

3.1 Introducción ........................................................................................................................................ 9 3.2 Visión general ..................................................................................................................................... 9 3.3 Spring .................................................................................................................................................. 12 3.4 Capa de acceso a datos ................................................................................................................. 14 3.5 Capa de negocio .............................................................................................................................. 16 3.6 Capa de presentación ..................................................................................................................... 17 3.7 Gestión de excepciones ................................................................................................................ 17 3.8 Gestión de ficheros de log ............................................................................................................ 19 3.9 Configuración de proyectos Maven ............................................................................................ 19 3.10 Herramientas ................................................................................................................................. 22

4 ARQUITECTURA EN PHP ....................................................................................... 24

4.1 Desarrollo en Capas ....................................................................................................................... 24 4.2 Frameworks ...................................................................................................................................... 25 4.3 Interoperabilidad ............................................................................................................................. 28

5 CRITERIOS ESPECÍFICOS .NET ............................................................................. 30

5.1 Net Core ........................................................................................................................................... 30 5.2 Net Framework ............................................................................................................................... 30

Página 3 de 31





MADES

Arquitectura

1 INTRODUCCIÓN

1.1 Objeto

El objetivo del documento es describir la arquitectura a utilizar dentro del Marcopara el Desarrollo y Mantenimiento de Sistemas de Información. El Área de Arquitecturadefine las arquitecturas recomendadas a implantar en los desarrollos así como losframeworks de soporte a las mismas.

1.2 Alcance

Todos los proyectos de desarrollo y mantenimiento de sistemas de información enlenguajes JAVA, PHP y .NET de la DGTIC.

1.3 Ámbito de Responsabilidades

De aplicación a los proveedores y responsables de proyectos de sistemas deinformación de la DGTIC, así como por la unidad responsable de calidad que velará por sucumplimiento en cada sistema o aplicación.

1.4 Revisión de la Norma

La norma que describe el Marco de Desarrollo de Sistemas de Información de laDGTIC, desarrollada en este documento será revisada de forma anual, para adaptar, corregiry ampliar en su caso tanto su alcance como su contenido. La unidad competente de laDGTIC será quien determine los responsables de la revisión, adaptación y modificación de lanorma.

1.5 Publicación de la Norma

El presente documento, así como las revisiones, serán de dominio público y sepondrá a disposición de cualquier ciudadano interesado utilizando los medios que la DGTICestime oportunos, preferentemente a través de Internet, desde los portales de informaciónque la Junta de Extremadura tiene de acceso público.

Página 4 de 31





MADES

Arquitectura

2 CRITERIOS GENERALES

2.1 Diseño y construcción por capas

Toda aplicación de software desarrollada desde la DGTIC debe seguir un diseño yuna construcción por componentes basada en capas que permitan el mayor nivel dedesacoplamiento, reutilización, independencia y facilidad de mantenimiento posible,persiguiendo el principio de ortogonalidad en software. Para ello, se recomienda el uso delpatrón de arquitectura de software Modelo-Vista-Controlador (MVC) que separa los datos yla lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado degestionar los eventos y las comunicaciones. El patrón MVC propone la construcción de trescomponentes distintos que son el modelo, la vista y el controlador, es decir, por un ladodefine componentes para la representación de la información, y por otro lado para lainteracción del usuario.

Este patrón de arquitectura de software se basa en las ideas de reutilización decódigo y la separación de conceptos, características que buscan facilitar la tarea dedesarrollo de aplicaciones y su posterior mantenimiento.

https://es.wikipedia.org/wiki/Modelo–vista–controlador

Programar usando MVC separa una aplicación en tres partes principalmente:

La capa del Modelo

Página 5 de 31

https://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93controlador





MADES

Arquitectura

El modelo representa la parte de la aplicación que implementa la lógica de negocio.Esto significa que es responsable de la recuperación de datos, convirtiéndolos en conceptossignificativos para la aplicación, así como su procesamiento, validación, asociación y cualquierotra tarea relativa a la manipulación de dichos datos.

A primera vista, los objetos del modelo pueden ser considerados como la primeracapa de la interacción con cualquier base de datos que podría estar utilizando la aplicación.Pero en general representan los principales conceptos en torno a los cuales se deseaimplementar un programa.

La capa de modelo o de persistencia de datos utilizará bases de datos relacionales. Elmodelo de objetos difiere en muchos aspectos del modelo relacional. Se requiere el uso deuna interfaz que una esos dos modelos, lo que se conoce como mapa objeto-relacional(ORM en inglés). Una capa de persistencia encapsula el comportamiento necesario paramantener los objetos, es decir, para leer, escribir y borrar objetos en el almacenamientopersistente (base de datos). Se debe usar un mapeador Objeto Relacional para implementarla capa de persistencia.

La asociación objeto-relacional (más conocido por su nombre en inglés, Object-Relational Mapping, o sus siglas O/RM, ORM, y O/R mapping) es una técnica deprogramación para convertir datos entre el sistema de tipos utilizado en un lenguaje deprogramación orientado a objetos y el utilizado en una base de datos relacional. En lapráctica, esto crea una base de datos orientada a objetos virtual, sobre la base de datosrelacional. Esto posibilita el uso de las características propias de la orientación a objetos(básicamente herencia y polimorfismo). Hay paquetes comerciales y de uso libre disponiblesque desarrollan la asociación relacional de objetos.

Un objeto está compuesto de propiedades y métodos. Como las propiedadesrepresentan a la parte estática de ese objeto, son las partes que se dotan de persistencia.Cada propiedad puede ser simple o compleja. Por simple se entiende que tiene algún tipo dedatos nativos como por ejemplo: entero, coma flotante o cadena de caracteres. Porcomplejo se entiende algún tipo definido por el usuario, ya sean objetos o estructuras. Porrelación se entiende asociación, herencia o agregación. Para dotar de persistencia lasrelaciones, se usan transacciones, ya que los cambios pueden incluir varias tablas.

Para vincular las relaciones, se usan los identificadores de objetos (OID). Estos OIDse agregan como una columna más en la tabla donde se quiere establecer la relación. Dichacolumna es una clave foránea a la tabla con la que se está relacionada. Así, queda asignada larelación. Recordar que las relaciones en el modelo relacional son siempre bidireccionales.

Página 6 de 31





MADES

Arquitectura

La capa de la Vista

La vista hace una presentación de los datos del modelo estando separada de losobjetos del modelo. Es responsable del uso de la información de la cual dispone paraproducir cualquier interfaz de presentación de cualquier petición que se presente.

La capa de presentación es la que ve el usuario, presenta el sistema al usuario, lecomunica la información y captura la información del usuario en un mínimo proceso (realizaun filtrado previo para comprobar que no hay errores de formato). Esta capa se comunicaúnicamente con la capa de negocio. También es conocida como interfaz gráfica y debe tenerla característica de ser "amigable" (comprensible y fácil de usar) para el usuario, adoptandolas mejores recomendaciones existentes en materia de experiencia de usuario (UX).

La capa de la Vista no se limita únicamente a HTML o texto que represente los datos,sino que puede ser utilizada para ofrecer una amplia variedad de formatos en función de susnecesidades tales como XML, json, documentos y cualquier otro formato establecido.

La vista será la responsable de la primera validación de los datos introducidos por losusuarios. Las validaciones deben ser sólo de obligatoriedad de campos y validacionesformales.

La capa del Controlador

La capa del controlador gestiona las peticiones de los usuarios. Es responsable deresponder a la información solicitada con la ayuda tanto del modelo como de la vista.

Los controladores pueden ser vistos como administradores cuidando de que todoslos recursos necesarios para completar una tarea se deleguen a los trabajadores másadecuados. Espera peticiones de los clientes, comprueba su validez de acuerdo a las normasde autenticación o autorización, delega la búsqueda de datos al modelo y selecciona el tipode respuesta más adecuado según las preferencias del cliente. Finalmente delega esteproceso de presentación a la capa de la Vista.

Esta capa debe de garantizar que los datos requeridos para procesarla fuerondebidamente validados, y sólo si es exitosa la validación se puede iniciar el flujo del procesode negocio. Para ello debe comprobarse la validez de los datos obtenidos desde la capa depresentación para preservar a la aplicación de ataques de código malintencionado.

Se debe de establecer un modelo de excepciones que se propague a la capa depresentación. Las excepciones son generadas desde la capa de acceso a datos y deben serencapsuladas en esta capa para trasladarlas de forma correcta a la capa superior.

Página 7 de 31





MADES

Arquitectura

2.2 Frameworks de Desarrollo

Un framework, entorno de trabajo o marco de trabajo, es un conjunto estandarizadode conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirvecomo referencia, para enfrentar y resolver nuevos problemas de índole similar.

En el desarrollo de software, un marco de trabajo es una estructura conceptual ytecnológica de asistencia definida, normalmente, con artefactos o módulos concretos desoftware, que puede servir de base para la organización y desarrollo de software.Típicamente, puede incluir soporte de programas, bibliotecas, y un lenguaje interpretado,entre otras herramientas, para así ayudar a desarrollar y unir los diferentes componentes deun proyecto.

Representa una arquitectura de software que modela las relaciones generales de lasentidades del dominio, y provee una estructura y una especial metodología de trabajo, la cualextiende o utiliza las aplicaciones del dominio. (Ref.: https://es.wikipedia.org/wiki/Framework)

Cualquier sistema de información desarrollado dentro del marco definido en estedocumento debe basarse en un framework de desarrollo, concretamente en alguno de losindicados en las secciones siguientes. En la época actual, con los medios, herramientas ysoftware disponibles, desde la DGTIC, no se concibe el diseño y la implementación de unsistema de información no basado en un framework de desarrollo, debido a la gran cantidadde beneficios que aporta, ahorro de trabajo y calidad en el trabajo final. Por lo tanto,cualquier aplicación web desarrollada desde o para la DGTIC DEBE estar diseñada eimplementada utilizando uno de los frameworks descritos a continuación.

2.3 Arquitectura Cliente-Servidor

Todas las aplicaciones de software realizadas desde y para la DGTIC DEBEN seguiruna arquitectura cliente-servidor, en la que el cliente es una aplicación disponible para elusuario que permite acceder a las funcionalidades que proporcionan los diversos servidores,ya sea una aplicación específica del sistema operativo o un navegador web que permitaacceder a las aplicaciones web de la DGTIC.

Página 8 de 31

https://es.wikipedia.org/wiki/Framework





MADES

Arquitectura

3 ARQUITECTURA EN JAVA

3.1 Introducción

En este apartado, se describe cómo se adapta la arquitectura definida en el puntoanterior al caso concreto de las aplicaciones desarrolladas en JAVA.

Se ha elegido una arquitectura por capas con el objetivo de separar la lógica denegocio de la lógica de diseño. De esta forma, se facilita el mantenimiento de las aplicacionesy la posible inclusión de nuevas funcionalidades en el futuro. Además, el organizar losproyectos de esta forma permite reutilizar partes del desarrollo de un proyecto en otro.

Todos los proyectos JAVA deben seguir la estructura propuesta por MAVEN ydeben poder compilarse con esta herramienta.

Se indicarán los frameworks permitidos para cada una de las capas y cómo serelacionarán estas capas entre ellas. Además, dada la diversidad de formas que existen paraconfigurar un mismo framework, se establecerá la que se debe utilizar, con el objetivo deunificar todos los proyectos lo máximo posible.

3.2 Visión general

Página 9 de 31





MADES

Arquitectura

3.2.1 Capa de presentación

Es la encargada de presentar información al usuario y aceptar entradas del mismo.No desarrolla ningún procesamiento de negocio o reglas de validación de negocio, si no quedelega esto a la capa de negocio. A su vez se puede subdividir en dos módulos:

Página 10 de 31





MADES

Arquitectura

Lógica de interfaz de usuarios

Sus funciones son:• Recoger la información del Usuario. • Enviar esta información a la Capa de Negocios. • Recoger resultados de la Capa de Negocios • Presentar los resultados al usuario.

Interfaz de usuario

Controla:• Navegabilidad del sistema.• Validación de datos de entrada.• Formateo de los datos de salida.• Internacionalización.• Renderizado de presentación, etc.

3.2.2 Capa de negocios

La lógica de negocios debe mantenerse separada de la capa de presentación y de losservicios de datos.

Deberá encapsular la lógica de negocio en un conjunto de objetos o componentesque no contienen presentación o código de servicios de datos.

Sus funciones son:

• Recibir la información de la capa de presentación.

• Interactuar con los servicios de datos para realizar la lógica de negocio y de laaplicación.

• Enviar resultados a la capa de presentación.

3.2.3 Capa de datos

Esta capa sirve de puente entre la lógica de negocio y el proveedor de datos. Hay quetener en cuenta que desde el punto de vista de esta arquitectura los datos pueden estaralmacenados en cualquier sistema (bases de datos, servicios web, ficheros, hojas decálculo,...). Es decir, debe existir una capa independiente de cualquier entidad externa. Para

Página 11 de 31





MADES

Arquitectura

acceder a cualquier tipo de entidad externa, el código debe ir en su correspondiente capa dedatos específica, encapsulando las especificidades del proveedor de datos a la siguiente capa(negocio). Esta capa únicamente recibe solicitudes de almacenamiento o recuperación deinformación desde la capa de negocio.

Sus principales funciones son:

• Almacenar Datos • Recibir datos • Mantenimientos de los datos • Integridad de los datos

3.3 Spring

Spring es el framework principal de todos los proyectos. Esto significa que se utilizarápor una parte como motor de inyección de dependencias y por otra como integrador de losframeworks que se utilicen. Para cualquier ampliación de la arquitectura, siempre sepreferirá la utilización módulos de Spring frente a otros frameworks.

A continuación, se describen los aspectos básicos de configuración y utilización deSpring que deben cumplir todos los proyectos, con el objetivo de mantener unahomogeneidad entre los mismos.

3.3.1 Configuración

La configuración de Spring siempre partirá de un fichero applicationContext.xml quese encontrará en el directorio WEB-INF del proyecto. Este fichero contendrá la referencia alfichero de configuración de la capa de presentación y al resto de ficheros de configuraciónque sean necesario.

De igual forma, los ficheros de configuración de cada una de las capas contendrán lareferencia al fichero de configuración de la capa inferior y al resto de ficheros deconfiguración que necesite.

Si el fichero de configuración de alguna de las capas es excesivamente grande, sedividirá en ficheros más pequeños según su funcionalidad.

Página 12 de 31





MADES

Arquitectura

3.3.2 Inyección de dependencias

Preferentemente, la declaración de los Beans y de las inyecciones de dependencias sehará mediante anotaciones. Para cada una de las distintas capas se utilizarán las siguientesanotaciones:

@Repository para la capa de datos.

@Service para la capa de negocio.

@Controller para la capa de presentación.

@Autorwired para la inyección de dependencias.

Si algún determinado Bean necesita que se defina un gran número de propiedadespara su configuración, esta se podrá realizar en un xml.

3.3.3 Integración de Spring con otros frameworks

Como se ha indicado anteriormente, Spring será el integrador del resto deframeworks. Esto hay que tenerlo especialmente en cuenta en la capa de acceso a datoscuando éstos se encuentren en una BBDD, ya que para los DAOs nunca se utilizarán lasclases que proporcionan Hibernate/MyBatis, sino las clases con las que las recubre Spring:

Página 13 de 31





MADES

Arquitectura

● En el caso de Hibernate se utilizaráorg.springframework.orm.hibernate4.support. HibernateDaoSupport.

● En el caso de MyBatis se delegará la creación de los DAOs en Spring a travésde org.mybatis.spring.mapper.MapperFactoryBean.

En lo referente a la capa de presentación, para integrar JSF con Spring se utilizará elmotor de inyección de dependencias de Spring en vez del de JSF. Para ello, hay que activarloen el fichero faces-config.xml con <el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver> y se anotarán los controllers con @Component("nombreController") en vez de utilizar la anotación @ManagedBean.

3.4 Capa de acceso a datos

3.4.1 Bases de datos

En general, se pueden tener aplicaciones orientadas a tablas (utiliza entidades paracompartir datos entre las capas) o aplicaciones orientadas a objetos (utiliza objetosindependientes de las tablas como transporte entre capas). Cualquiera de las dosaproximaciones está permitida, pero se deberá tener en cuenta el punto del que se parte(bases de datos nuevas o heredadas) para escoger el método que mejor se adapte a eseescenario. De la misma forma, se escogerá Hibernate o MyBatis teniendo en cuenta laslimitaciones que estos frameworks para trabajar con uno u otro enfoque.

● Hibernate (orientación a tablas, entities):

○ Tanto las entities como los DAOs podrán generarse automáticamente concualquier tipo de herramienta, pero la generación de los mismos nunca seincluirá como una tarea en la compilación del proyecto: se deben generar yposteriormente incluirse en el mismo.

○ Como excepción a la definición de paquetes descrita en el documento decriterios de desarrollo, el mismo se debe aproximar lo máximo posible almodelo es.juntaex.AREATEMATICA.APLICACION.[SUBSISTEMA].[CAPA].[TIPO] descrito en dicho documento, pero no deben cumplirlo estrictamentesi ello implica la imposibilidad de generar las entidades automáticamente.

○ Como fichero de configuración de Hibernate, se debe utilizar únicamente elapplicationContext-proyecto-per.xml, evitando el uso del ficherohibernate.cfg.xml. En este fichero se definirá el dataSource, sessionFactory y eltransactionManager, así como cualquier propiedad de hibernate(hibernate.dialect,...).

Página 14 de 31





MADES

Arquitectura

● MyBatis (orientación a objetos):

○ Se podrán generar automáticamente los objetos de transporte de datos,objetos de criterios de búsqueda (*Example) y objetos mapeadores (*Mappery *Mapper.xml).

○ Como excepción a la definición de paquetes descrita en el documento decriterios de desarrollo, y dado que se trata de clases generadas, se utilizaránlos paquetes que genere la herramienta, de forma que se ajuste lo máximoposible al descrito en dicho documento. De la misma forma, se utilizará elnombrado de clases propio de MyBatis (Example, Mapper,...) en lugar deldescrito en el documento de criterios de desarrollo.

○ No se codificarán DAOs manualmente, si no que esta tarea se delegará enSpring.

○ Los ficheros de configuración serán los siguientes:■ applicationContext-proyecto-per.xml: contendrá el datasource y la

configuración de MyBatis.■ Ibatis.xml: contendrá las referencias a *Mapper.xml.

○ En cuanto a los mapper, se pueden utilizar bien clases java con anotaciones obien ficheros xml. Se preferirá el uso de clases cuando el código de lasanotaciones no sea muy complejo. En caso contrario, se aconseja utilizarficheros xml.

Siempre se preferirá el uso de uno de los dos frameworks anteriores, pero en el casode que se tenga que utilizar conexiones JDBC u otro tipo de acceso a las bases de datos, seutilizará un framework especializado (Spring-JDBC,...). En todo caso, nunca se crearánconexiones a las bases de datos dentro del código de forma manual y siempre se accederá alas bases de datos a través de los datasources definidos en el servidor de aplicaciones.

3.4.2 Consumo de servicios web

Se utilizará la API JAX-WS para la creación de los clientes que consumen serviciosweb. Estos clientes se considerarán como parte de la capa de datos, por tanto siempre seránllamados desde la capa de negocio y nunca desde la capa de presentación.

En principio, todos los servicios web se consumirán a través del bus corporativo.Para llamar al bus, obligatoriamente se deben incluir los siguientes ficheros de properties:

Fuera del war y por cada servicio web que se consuma, deben existir dos ficheros:

Página 15 de 31





MADES

Arquitectura

● keystore<nombreservicioaconsumir>.properties: contendrá los siguientesdatos:

- Ubicación del almacén- Tipo del almacén- Contraseña del almacén- Alias de la firma- Contraseña de la firma

● url<nombreservicioaconsumir>.properties: contendrá la url del servicio aconsumir.

En el fichero application.properties de la aplicación, se guardarán las rutas dondeestán todos los properties.

Por ejemplo, si una aplicación necesita consumir los servicios web WS1 Y WS2, laforma de organizar los ficheros de properties sería:

● keystoreWS1.propertiesbus.ws1.almacen.ruta=/var/www/.../config/almacen.jksbus.ws1.almacen.tipo=JKSbus.ws1.almacen.contrasena=contraseñabus.ws1.firma.alias=firmabus.ws1.firma.contrasena=contraseña

● urlWS1.propertiesbus.ws1.endPoing=https://...

● keystoreWS2.propertiesbus.ws2.almacen.ruta=/var/www/.../config/almacen.jksbus.ws2.almacen.tipo=JKSbus.ws2.almacen.contrasena=contraseñabus.ws2.firma.alias=firmabus.ws2.firma.contrasena=contraseña

● urlWS2.propertiesbus.ws2.endPoing=https://...

● aplication.propertiesbus.ws1.properties.keystore=/.../keystoreWS1.propertiesbus.ws1.properties.conexion=/.../urlWS1.propertiesbus.ws2.properties.keystore=/.../keystoreWS2.propertiesbus.ws2.properties.conexion=/.../urlWS2.properties

3.5 Capa de negocio

Página 16 de 31





MADES

Arquitectura

La principal función de esta capa es hacer de puente entre la capa de datos y la depresentación. Dado que la capa de datos sólo debe leer/escribir datos sin realizar ningunaoperación sobre ellos y que la capa de presentación sólo debe presentar/recibir datos delusuario sin realizar ninguna tarea que no sea la validación de los mismos, cualquier operaciónsobre los datos se debe realizar en esta capa.

Además de la modificación de los datos, será habitual que en esta capa se realicenotra serie de operaciones que se describen a continuación:

3.5.1 Transacciones

Las transacciones siempre se definirán en esta capa, a nivel de método.

Para gestionarlas, se utilizarán las facilidades del bean transactionManager queproporciona Spring (org.springframework.orm.hibernate4.HibernateTransactionManagerpara Hibernate, org.springframework.jdbc.datasource.DataSourceTransactionManager paraMyBatis).

En cualquier caso, nunca se gestionarán en ninguna de las otras dos capas.

3.5.2 Problemas transversales

Para resolver problemas que afecten a una gran parte de los objetos de negocio(auditoría,…), se utilizará el paradigma de Programación Orientada a Aspectos (AOP). Enconcreto, se deben utilizar las facilidades proporcionadas por los módulos spring-aop yspring-aspects de Spring.

Preferiblemente, se utilizarán etiquetas en vez de xml para su configuración.

3.6 Capa de presentación

Únicamente está permitido el uso del framework PrimeFaces integrado con Spring.

El fichero de configuración faces-config.xml, además de los parámetros que seconsideren oportunos, deberá incluir obligatoriamente la integración con Spring, la definiciónde una página general de error, y la clase que se encargará de gestionar las excepciones.

3.7 Gestión de excepciones

Se distinguirán entre dos tipos de excepciones:

Página 17 de 31





MADES

Arquitectura

● Excepciones controladas: como norma general, este tipo de excepcionesdeben ser capturadas y tratadas por el método que las provoca. En cuanto asu manejo, se deben tener en cuenta las siguientes normas:

○ Capturar las excepciones más específicas primero:

public void capturarLasMasEspecificasPrimero() { try { hacerAlgo("Un mensaje"); } catch (NumberFormatException e) { log.error(e); } catch (IllegalArgumentException e) { log.error(e) }}

○ No ignorar nunca las excepciones: cuando se capture una excepciónsiempre se hará algo con ella. Evitar código como el siguiente:

public void noIgnorarExcepciones() { try { // hacer algo } catch (NumberFormatException e) { // Esto no ocurrirá nunca, luego no la trato }}

○ No relanzar excepciones una vez que han sido capturadas. Evitarcódigo como el siguiente:

public void lanzarExcepcion(String input) throwsMiPropiaException { try { // hacer algo } catch (NumberFormatException e) { throw new MyBusinessException("Describe el error.", e); }}

● Excepciones no controladas: este tipo de excepciones siempre se lanzaránhacia arriba y serán manejadas por la aplicación en un sólo punto. Enconcreto, se definirá en el fichero faces-config.xml un controlador deexcepciones que será el encargado de escribir el error en el log y mostrar

Página 18 de 31





MADES

Arquitectura

una pantalla de error al usuario. La página que muestra este tipo de erroresdebe ser única para toda la aplicación.

3.8 Gestión de ficheros de log

Para gestionar los logs de las aplicaciones, se utilizará log4j.

Por cada aplicación, debe incluirse un sólo fichero de configuración log4j.properties,que estará en la carpeta resources del proyecto web.

En el fichero de configuración, de debe definirse obligatoriamente la ruta en la que seescribirá el log y una política de rotación de logs.

Un ejemplo del fichero log4j.properties mínimo puede ser el siguiente:

# Root logger optionlog4j.rootLogger=ERROR, file

# Redirect log messages to a log file, support rolling backup file.log4j.appender.file=org.apache.log4j.RollingFileAppenderlog4j.appender.file.File=/var/www/prueba/log/prueba.loglog4j.appender.file.MaxFileSize=5MBlog4j.appender.file.MaxBackupIndex=10log4j.appender.file.layout=org.apache.log4j.PatternLayoutlog4j.appender.file.layout.ConversionPattern= %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n

3.9 Configuración de proyectos Maven

En este punto, se definen los tipos de módulos que deben incluirse en los proyectos,así como su nomenclatura.

3.9.1 Tipos de módulos Maven

Con el objetivo de promover todo lo posible la reutilización de código, se hadecidido que todos los proyectos se estructurarán en módulos. Cada uno de estos móduloses a su vez un proyecto Maven que se corresponde con una de las capas descritas en laarquitectura.

Todos los proyectos contendrán un proyecto padre o base(<packaging>pom</packaging>) que declarará los módulos que se utilizan para ese proyecto

Página 19 de 31





MADES

Arquitectura

en concreto, pero desde los proyectos hijo no se hará referencia al proyecto padre. Elconvenio a seguir para nombrar los proyectos Maven será el siguiente:

● Módulo padre:○ Nombre: el nombre del proyecto, sin sufijo alguno.○ Tipo: pom.○ Finalidad: incluirá las referencias a los módulos hijos que se utilizan en

el proyecto.

● Módulo de persistencia:○ Nombre: nombre del proyecto más el sufijo “-per”.○ Tipo: jar.○ Finalidad: contendrá las clases encargadas de almacenar o leer datos

de un repositorio externo (base de datos, ficheros,....).

● Módulo de cliente de servicio web:○ Nombre: nombre del proyecto más el sufijo “-swc”.○ Tipo: jar.○ Finalidad: contendrá las clases encargadas de almacenar o leer datos a

través de un servicio web.

● Módulo de negocio:○ Nombre: nombre del proyecto más el sufijo “-neg”.○ Tipo: jar.○ Finalidad: contendrá las clases de negocio que hacen de puente entre

la capa de persistencia y la de presentación.

● Módulo web:○ Nombre: nombre del proyecto más el sufijo “-web”.○ Tipo: war.○ Finalidad: contendrá las clases correspondientes a la capa de

presentación.

3.9.2 Estructura del pom.xml

El pom.xml de cada uno de los proyectos descritos anteriormente deberá seguir lamisma estructura. Como mínimo, se debe incluir la siguiente información:

● Información del proyecto:○ <groupId>: siempre será es.juntaex.○ <artifactId>: nombre del proyecto más el sufijo correspondiente al

tipo del módulo (-per, -neg,...).○ <version>: versión del módulo maven. Será un número con el formato

x.x.x seguido obligatoriamente del sufijo -SNAPSHOT si se trata de

Página 20 de 31

MADES

Arquitectura

una versión en desarrollo o del sufijo .RELEASE si se trata de unversión que se considera terminada.

○ <packaging>: tipo del proyecto (pom, jar ó war).○ <description>: breve descripción del proyecto.

● Modules: sólo se incluirá para el módulo padre. Contiene las referencias a losmódulos hijo que se vayan a utilizar en ese proyecto, indicando su ruta deforma relativa:

<modules><module>../proyecto-per</module><module>../proyecto-neg</module><module>../proyecto-web</module>

</modules>

● Properties: contendrá, al menos, la declaración de la codificación utilizada.Además, contendrá también las constantes que se consideren oportunas,como número de las versiones de las dependencias, ...

<properties><spring.version>4.3.9.RELEASE</spring.version><project.build.sourceEncoding>UTF-8</

project.build.sourceEncoding></properties>

● Dependencias: incluirá las dependencias externas que necesite ese proyecto.En cuanto a la versión de las dependencias, se hará referencia a las constantesdeclaradas en las propiedades anteriores. Las dependencias se incluirán en elsiguiente orden, separando cada una de las partes por un comentario:

○ Dependencias a otros módulos del mismo proyecto.○ Dependencias a librerías proporcionadas por la DGTI.○ Dependencias externas relativas a librerías externas.

<dependencies>

<dependency><groupId>es.juntaex</groupId><artifactId>proyecto-neg</artifactId><version>${proyecto-neg.version}</version></dependency>

<dependency><groupId>es.juntaex</groupId>

Página 21 de 31

MADES

Arquitectura

<artifactId>seguridadWeb</artifactId><version>${seguridadWeb.version}</version></dependency>

<dependency><groupId>org.springframework</groupId><artifactId>spring-context</artifactId><version>${spring.version}</version></dependency>

</dependencies>

● Build: contendrá los plugins necesarios para compilar el proyecto. Además delos que se consideren necesarios, será obligatorio utilizar el plugin maven-compiler-plugin indicando la versión de Java que se está utilizando y la etiquetaresources con el filtering activado.

<build><plugins>

<plugin><artifactId>maven-compiler-plugin</artifactId><configuration>

<source>1.7</source><target>1.7</target>

</configuration></plugin>

</plugins><resources>

<resource><directory>src/main/resources</directory><filtering>true</filtering><includes><include>**/*.*</include></includes>

</resource></resources>

</build>

3.10 Herramientas

Para facilitar el en todo lo posible el desarrollo de nuevos proyectos la DGTIfacilitará las siguientes herramientas:

Página 22 de 31





MADES

Arquitectura

● Un prototipo de proyecto base que cumple las normas descritas en estedocumento.

Página 23 de 31

Sidera CakePHP 3 Laravel

CakePHP 2

Bootstrap

HTML CSS javascript

jQuery

PHP

Apache Web Server

Oracle, SQL Server, MySQL JasperServer

Web App

Web App

Web App

Web App

Web App

Web App





MADES

Arquitectura

4 ARQUITECTURA EN PHP

4.1 Desarrollo en Capas

Siguiendo lo descrito en los criterios generales, toda aplicación desarrollada en PHPdesde o para la DGTIC debe estar estructurada en capas que minimicen lo posible elacoplamiento del código. Concretamente, las aplicaciones en PHP siguen el patrón MVCpuro utilizando un conjunto jerarquizado de clases para representar dicho patrón. De igualforma, establece las relaciones mínimas necesarias que permitan independizar lo máximoposible las capas:

Página 24 de 31





MADES

Arquitectura

4.2 Frameworks

4.2.1 CakePHP

Versión: 3.x, URL: http://cakephp.org/

CakePHP hace que la construcción de aplicaciones web sea más simple, más rápida yrequiera menos código. Se trata de un framework moderno, que soporta PHP 7, que ofreceuna capa de acceso a bases de datos flexible y un potente sistema de scaffolding que haceque la construcción de sistemas pequeños y complejos sea más sencilla, fácil y, por supuesto,más útil.

Estas son las características más destacadas:

● Soporta PHP 5.5+

● Sistema de scaffolding

● Implementación rápida

● Arquitectura MVC

● Idóneo para aplicaciones web comerciales (Licencia MIT)

● Soporte interno para:

○ acceso a base de datos,

○ caché,

○ validación,

○ autenticación,

○ autorización

● Elementos avanzados de seguridad que previenen:

○ cross-site scripting (XSS),

○ inyección de SQL,

○ CSRF (Cross-site request forgery o falsificación de petición en sitioscruzados)

Página 25 de 31

http://cakephp.org/





MADES

Arquitectura

○ validación de formularios

● Buena documentación

● Desarrollo activo

4.2.2 Sidera

Versión: 3.0, URL: https://devrepo.juntaex.es/PHP/SIDERA. Requiere la versión de PHP 5.6+.

Sidera es una herramienta web modular de código abierto, que permite construiraplicaciones web completas de forma rápida y eficaz, generando un código limpio, simple yde calidad.

La potencia de Sidera reside en la combinación de frameworks de desarrolloaltamente testados, con una serie de funcionalidades y automatismos que ponen aldesarrollador en un punto muy avanzado en el ciclo de vida de su proyecto web.

Sidera integra múltiples frameworks y librerías como CakePHP, Bootstrap, jQuery,TCPDF, elFinder,... que permiten disponer de todas sus ventajas, pero si a esto le sumamoslas propias de Sidera, obtenemos un sistema robusto y bastante completo de característicasy funcionalidades, de las cuales podrán beneficiarse tanto desarrolladores como usuariosfinales de las aplicaciones.

El 1 de febrero de 2013 surge la primera versión de Sidera, creada por variosprogramadores de la Junta de Extremadura, y cuya única motivación es la de compartir ymejorar una herramienta que intenta aportar soluciones a problemas comunes en eldesarrollo de aplicaciones web.

Sidera persigue los siguientes objetivos:

● Reducir considerablemente los tiempos de desarrollo

● Homogeneizar el proceso de desarrollo para facilitar los mantenimientos deproyectos propios o ajenos

● Aportar un alto nivel de seguridad de la información

● Crear aplicaciones de alta fiabilidad y calidad

● Mejorar la usabilidad y la experiencia de usuario

Página 26 de 31

https://devrepo.juntaex.es/PHP/SIDERA





MADES

Arquitectura

Sidera es un proyecto en continuo crecimiento que se retroalimenta de laexperiencia de los proyectos desarrollados con él y que busca la mejora continua con cadaversión.

Las características más destacables del framework son:

● Framework gratuito y de código abierto basado en CakePHP 2.x

● Arquitectura Modelo Vista Controlador (MVC)

● Diseño web responsive (smartphone, tablet o PC)

● Buena usabilidad y experiencia de usuario

● Desarrollos estructurados y limpios

● Aplicaciones funcionales desde el inicio del desarrollo

● Facilidad de mantenimientos correctivos, adaptativos y evolutivos

● Alto nivel de seguridad en las aplicaciones

Además, aporta las siguientes funcionalidades para el desarrollador:

● Gestión de la configuración de la aplicación

● Constructor automatizado de módulos CRUD

● Gestión de menús

● Gestión de usuarios y grupos

● Gestión de permisos a grupos

● Auditoría de actividad y control de accesos

● Gestión de contenidos

● Búsqueda y exportación de datos (Excel y PDF)

● Validación de formularios

● Visualización de errores y logs

Página 27 de 31





MADES

Arquitectura

4.2.3 Laravel

Versión: 5.1, URL: https://laravel.com. Requiere la versión de PHP 5.5.9.

Laravel es un marco completo diseñado para aplicaciones de construcción rápidautilizando la arquitectura MVC. Es el framework PHP más popular hoy en día con una grancomunidad de desarrolladores.

Entre otras características se pueden destacar:

● Organizar archivos y código

● Desarrollo rápido de aplicaciones

● Arquitectura MVC

● Pruebas unitarias

● Buena documentación

● Alto nivel de abstracción

● Capacidades de sobrecarga mediante métodos dinámicos

● Gran cantidad de funcionalidades

● Paquetes de cifrado muy fuertes

● ORM

4.3 Interoperabilidad

La DGTIC utiliza un Bus de Servicio Empresarial (ESB) como arquitectura desoftware para la gestión de la comunicación entre servicios web. De esta forma, tanto losservicios como los consumidores de estos servicios han de estar registrados, autenticados ycontrolados por este bus.

Un ESB generalmente proporciona una capa de abstracción construida sobre unaimplementación de un sistema de mensajes que permite a los expertos en integraciónexplotar el valor del envío de mensajes sin tener que escribir código. Un bus de servicio deempresa se construye sobre unas funciones base que se dividen en sus partes constituyentes,

Página 28 de 31

https://laravel.com/





MADES

Arquitectura

con una implantación distribuida cuando se hace necesario, de modo que trabajenarmoniosamente según la demanda.

Un ESB no implementa en sí mismo una arquitectura orientada a servicios (SOA),sino que proporciona las características mediante las cuales sí se puede implementar. El ESBtrata de aislar el acoplamiento entre el servicio solicitado y el medio de transporte. Lamayoría de los proveedores de ESB incorporan principios de SOA y permiten formatos demensaje independientes.

Un servicio web implementado en PHP ha de registrarse en el ESB para disponer deun punto de enlace o endpoint que permite a los consumidores hacer uso del servicio. PHPdispone internamente de las librerías necesarias tanto para crear un servicio como unconsumidor web a través de un juego de clases y métodos.

El ESB corporativo de la DGTIC utiliza Web Service Security (WSS), que es unprotocolo de comunicaciones que suministra un medio para aplicar seguridad a los serviciosweb. El protocolo contiene las especificaciones sobre cómo debe garantizarse la integridad yseguridad en la mensajería de servicios web. El protocolo WSS incluye detalles en el uso deSAML y Kerberos, y formatos de certificado tales como X.509.

Las aplicaciones que acceden a los endpoints del ESB para utilizar los servicios webnecesitan tener una certificación válida y autorizada por la DGTIC. Para ello se usa elprotocolo WSS y un certificado digital que asegure la identidad del peticionario.

La API de PHP para crear un consumidor de servicio web no dispone de forma nativade la implementación del protocolo WSS por lo que es necesaria extender su funcionalidad através de clases originales o bien a través de clases de los framework de desarrollo en PHPutilizados en la DGTIC.

En el enlace https://devrepo.juntaex.es/PHP/utilidades/CertifiedSoapConsumer, sepuede encontrar la utilidad CertifiedSoapConsumer para enlazar al ESB corporativoutilizando WSS. Se trata de un conjunto de clases que se pueden utilizar en cualquieraplicación en PHP e incluso en cualquiera de los frameworks de desarrollo indicados en estedocumento.

En este otro enlace https://devrepo.juntaex.es/PHP/utilidades/PHPWebServiceServer,se puede encontrar un ejemplo de cómo crear un servicio web en PHP.

Página 29 de 31

https://devrepo.juntaex.es/PHP/utilidades/PHPWebServiceServer

https://devrepo.juntaex.es/PHP/utilidades/CertifiedSoapConsumer





MADES

Arquitectura

5 CRITERIOS ESPECÍFICOS .NET

Actualmente el desarrollo de aplicaciones con la tecnología Microsoft, abarca un grantipo de aplicaciones, agrupadas en 2 principales marcos de desarrollo:

5.1 Net Core

Referencia: https://www.microsoft.com/net/learn/architecture

Nuevo marco de desarrollo Multiplataforma y código abierto, soportado en sistemasWindows, MAC, Linux y Docker (para Linux y Windows)

Tipos de Aplicaciones .Net Core:

● Aplicación de Consola● Biblioteca de Clase● Aplicación Web MVC .NET Core● Aplicaciones ASP.NET con Angular● Aplicaciones ASP.NET con React● Aplicación Web .NET Core con páginas Razor● Aplicaciones Web Api: para creación de servicios RESTful HTTP● Proyectos de Pruebas

5.2 Net Framework

Es el otro marco de desarrollo que, de momento, continúa en desarrollo y mejora deversiones. Evolución continua desde la versión 1.0 (2002). Se ha adoptado la última versiónestable de 2017, la versión 4.6.

Es con este framework con el que se ha desarrollado la última aplicación .Net

Tipos de Aplicaciones con .Net Framework 4.6:

● Web Forms: aplicaciones web controladas por eventos tipo “drag and drop”, concontroles y componentes● MVC: para el desarrollo de aplicaciones mediante la arquitectura de Modelo-Vista-Controlador● Web Api: para crear proyectos de servicios HTTP REST

Página 30 de 31

https://www.microsoft.com/net/learn/architecture





MADES

Arquitectura

● SPA: para creación de aplicaciones HTML 5, CSS3 y Javascript● Aplicaciones para Azure

Página 31 de 31

Consejería de Hacienda y Administración Pública · 3 ARQUITECTURA EN JAVA.....9 3.1...

Documents

Transcript of Consejería de Hacienda y Administración Pública · 3 ARQUITECTURA EN JAVA.....9 3.1...