anexo1-documento-arquitectura-referencia

Vista previa del material en texto

DOCUMENTO DE ARQUITECTURA DE REFERENCIA PARA APLICACIONES WEB 
GESTIÓN INFORMÁTICA 
UNIVERSIDAD DE ANTIOQUIA 
 
Este documento se estructura teniendo en cuenta las recomendaciones del artículo de IBM 
“Reference Architecture: The best of best practices” 
http://www.ibm.com/developerworks/rational/library/2774.html puede encontrarse también en 
Alfresco: Company Home > Sistemas > ArquitecturaDeSoftware. 
 
Capas de la arquitectura de referencia 
El documento de referencia está dividido en las siguientes capas: 
Capa de Interfaz de usuario: estándares y herramientas para soportar la interfaz de usuario y/o 
los servicios de presentación. (p.e: html, interfaces de usuario enriquecidas). 
Capa de negocio: estándares y herramientas para soportar la lógica de negocio. (p.e: lenguajes, 
estándares de componentes). 
Capa media: estándares y herramientas para soportar la gestión de transacciones y la 
comunicación entre procesos. (p.e: servidores de aplicaciones, APIs de IPC). 
Capa de software de sistema: estándares y herramientas para soportar la gestión de sistemas. 
(p.e: sistemas operativos y sistemas de gestión de bases de datos). 
 
A continuación se detalla cada una de las capas: 
Capa de interfaz de usuario 
Área Productos/servicios/componentes 
Estilos y usabilidad Ver el documento “Estandarización de línea grafica.doc” que se encuentra 
en alfresco Company Home > Sistemas > FormatosyEstandares. Este 
documento define los estándares de línea gráfica que deben seguirse para 
el desarrollo de aplicaciones web. 
Herramientas de construcción 
Lenguajes 1. Para aplicaciones nuevas web se debe usar JSF 1.2 y Icefaces 1.8. 
 Para creación de reportes se debe usar JasperReports 3.7.4 
2. Para aplicaciones preexistentes en lenguaje PHP 5, el mantenimiento 
se debe realizar con el mismo lenguaje y versión. 
Entorno de 1. Se debe usar el IDE Netbeans 6.5.1, e incluir el plugin para generar 
http://www.ibm.com/developerworks/rational/library/2774.html
http://makuna:8080/alfresco/faces/jsp/dialog/container.jsp
http://makuna:8080/alfresco/faces/jsp/dialog/container.jsp
http://makuna:8080/alfresco/faces/jsp/dialog/container.jsp
desarrollo (IDE) proyectos usando la plantilla básica de aplicaciones web. Ver 
documento “ManualPlantilla.doc” que se puede encontrar en Alfresco 
Company Home > Sistemas > ArquitecturaDeSoftware, el cual explica 
la forma de instalación y el uso de este plugin. 
Se deben incluir los plugins: jasperserver-plugin-3.7.4.nbm, iReport-
3.7.4.nbm, Facelets support, ICEfaces run-time libraries versión 1.8.2.2 
2. Para php: Dado que en PHP se hacen solo modificaciones a 
aplicaciones existentes, debe utilizarse lo que actualmente se tiene. 
Estrategias de 
diseño 
Para aplicaciones en Java, se debe implementar el patrón de diseño MVC, 
el cual se apoya en JSF 1.2 y Icefaces 1.8 para las capas de Vista y 
Controlador. Como aplicación de referencia puede consultarse el proyecto 
ejemploPlantilla que se encuentra en la raíz del CVS instalado en sikuani. 
Seguridad Toda página que use datos personales del usuario debe utilizar el 
protocolo https y por ende todos los componentes usados en esta, con el 
fin de no generar en el navegador del usuario alertas de seguridad. La 
Universidad dispone de certificado de seguridad válido en su servidor de 
aplicaciones de producción y de un certificado no válido en pruebas. 
Componentes 
1. Presentación de 
errores al 
usuario 
Para la presentación de errores al usuario se debe usar el estándar de JSF 
1.2 
 
Capa de negocio 
Área Productos/servicios/componentes 
Componentes 
1. Lenguajes 1. Java (máximo 1.5.018) 
2. PHP 5 para mantenimiento de aplicativos hechos en este lenguaje. 
2. Entorno de 
desarrollo (IDE) 
Se debe usar el IDE Netbeans 6.5.1 
Uso de patrones 
Patrón DAO Patrón recomendado por J2EE 
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObj
ect.html para acceso a datos. 
Este patrón aplica tanto para aplicaciones Java como para aplicaciones 
PHP. 
Patrón Factory Patrón recomendado por J2EE para complementar el patrón DAO. Este 
patrón se usa para dar la posibilidad de acceder a los datos a través 
Hibernate o JDBC. La configuración del acceso debe hacerse a través de 
DataSource, por ende la aplicación no debe almacenar contraseñas de 
acceso a base de datos. 
La url de referencia es la misma que para el patrón DAO. 
Este patrón aplica tanto para aplicaciones Java como para aplicaciones 
PHP. 
Patrón DTO Patrón recomendado por J2EE 
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.
html para transferencia de datos. Este patrón se usa transversal a toda la 
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
aplicación. 
Este patrón aplica tanto para aplicaciones Java como para aplicaciones 
PHP. 
Componentes de servicio 
1. Seguridad Para aplicaciones java, utilizar el OID institucional para la autenticación y el 
MUA (Módulo Único de Autorización) para la autorización a través de un 
filtro de seguridad proveído por la institución. 
1. Manejo de logs Log4j versión 1.2.9. En el archivo de propiedades log4j.properties incluido 
en el proyecto de referencia se detallan los parámetros que se deben 
configurar para el uso de la librería log4j. 
Los llamados a la librería pueden ser mediante un método que existe en el 
backing bean común que se llama redirectError o mediante un llamado 
directo al servicio de registro de log de la librería log4j. 
2. Lógica de 
negocio 
La lógica de negocio se debe manejar a través de clases dentro del paquete 
“bl” (business logic). 
3. Servicios web Las clases clientes de servicios web, deben ubicarse dentro del paquete 
“bl”. 
Para el consumo de servicios web proveídos por la institución se debe 
usar la librería OrgSistemasSecurity.jar tal como se indica en el manual 
“Para consumir servicios web UdeA. docx“ 
4. Enrutamiento de 
peticiones desde 
la interfaz de 
usuario hacia la 
lógica de 
negocio 
Esto es gestionado por IceFaces y JSF 1.2. 
5. Filtros Cualquier filtro necesario en la aplicación, deberá ubicarse en el paquete 
“flt”. 
Componentes de acceso a datos 
1. Procedimientos 
almacenados 
Con el fin de hacer más segura la aplicación y sus transacciones, todas las 
operaciones (consulta, actualización, creación y eliminación) sobre la base 
de datos deben realizarse a través de procedimientos almacenados y 
funciones. 
El usuario con el cual se accede a la base de datos debe ser diferente al 
dueño del esquema, normalmente debe llamarse consultaXXXXX donde 
XXXXX es el nombre del sistema (P.E. consultaReune, consultaMares, etc.). 
A dicho usuario se le deben otorgar los permisos necesarios para la 
ejecución de los procedimientos y funciones creados. 
2. Tipos de acceso 
a datos 
1. Utilizar Hibernate 3.0 cuando la aplicación no requiera ejecutar un alto 
contenido de consultas. 
2. Utilizar JDBC en caso contrario. 
De acuerdo con las condiciones de la aplicación, puede darse una 
combinación de ambos tipos de acceso. Esta decisión se toma durante la 
etapa de diseño de la aplicación. 
La configuración del acceso debe hacerse a través de DataSource, por ende 
la aplicación no debe almacenar contraseñas de acceso a base de datos. 
 
Capa media 
Área Productos/servicios/componentes 
Servidores de 
aplicaciones 
Para aplicaciones web Java, Oracle Application Server 10.1.3.5 
 
Servicios de 
directorio 
Oracle Internet Directory (OID). 
 
Capa de software de sistema 
Área Productos/servicios/componentes 
Sistemas operativos Estaciones para desarrollo: Microsoft Windows 7 y posteriores. 
SGBD Oracle 10g 
 
Ambientes: desarrollo, pruebas y producción – 
 
Diagrama general del estándar de arquitectura para desarrollode 
aplicaciones web en java