Implementación de una visión de arquitectura Experiencias y Resultados

Presentación del tema: "Implementación de una visión de arquitectura Experiencias y Resultados"— Transcripción de la presentación:

1 Implementación de una visión de arquitectura Experiencias y Resultados
Andrés Camilo Bustamante Analista de Arquitectura Gerencia de Desarrollo Suramericana de Seguros S.A.

2 Agenda Visión Inicial Proceso de conformación del equipo
Experiencias y productos Arquitectura Inicial Plataforma de Publicación de Servicios Logros Preguntas y Respuestas

3 Visión Inicial Problemática
Respuestas rápidas a requerimientos del negocio Ofrecer disponibilidad de soluciones de negocio en cualquier momento, desde cualquier lugar Aprovechar relaciones de gran valor para el negocio con clientes, socios y proveedores Facilitar la automatización de procesos de negocio complejos Proveer seguridad y confiabilidad en las transacciones de negocio Soportar un gran número de usuarios dificil de medir y que puede crecer a gran velocidad

4 Visión Inicial Reto Velocidad (de desarrollo y de ejecución)
Construir aplicaciones con prácticas de diseño e infraestructura lo suficientemente robustas que nos brinden: Velocidad (de desarrollo y de ejecución) Disponibilidad Confiabilidad Proyección Seguridad Calidad en nuestros productos

5 Visión Inicial Objetivo General
Definir una Arquitectura eficiente para la construcción de aplicaciones basada en plataformas abiertas y escalables sobre la cual se implementará toda la estrategia de desarrollo informático a largo plazo.

6 Objetivos Específicos
Visión Inicial Objetivos Específicos Definir las especificaciones: Arquitectura de aplicaciones, de integración y de datos. Definir la infraestructura: Estándares tecnológicos, plataformas y herramientas. Definir el esquema de gobierno: políticas y normas, mejores prácticas, esquemas de coordinación y reporte.

7 Agenda Visión Inicial Proceso de conformación del equipo
Experiencias y productos Arquitectura Inicial Plataforma de Publicación de Servicios Logros Preguntas y Respuesta

8 Proceso de Conformación del Equipo

9 Proceso de conformación del equipo
Infraestructura Estándares tecnológicos Plataforma de integración y Servidor de Aplicaciones Herramientas y esquemas de administración Especificaciones Arquitectura ( Diseño ) Aplicaciones Técnica Modelo de Integración Modelo de Información Modelo de Interfaces Equipo de Arquitectura Gobierno Coordinación y reporte Políticas y normativas Mejores prácticas (Patrones, Frameworks) Publicación y Documentación

10 Proceso de conformación del equipo
Iniciativa gerencial Necesidad evidente en todos los equipos Definición de perfil de arquitecto Habilidades Responsabiliddes Finalidades Entorno Formulación de proyectos

11 Proceso de conformación del equipo
Definición de perfil de arquitecto - Habilidades Las principales habilidades se deben concentrar en el análisis y diseño de sistemas. Debe conocer y dominar todos los elementos de la infraestructura tecnológica que tiene a su disposición. Se debe concentrar en la optimización y reutilización de todos estos elementos de infraestructura en los desarrollos de software de la organización. Para ello su principal herramienta de trabajo es el uso de patrones de software (patrones de diseño y arquitectura). Estos patrones de diseño se pueden definir como las mejores prácticas que son reconocidas y que buscan solucionar un problema recurrente.

12 Proceso de conformación del equipo
Definición de perfil de arquitecto - Responsabilidades Definición y desarrollo del marco de referencia técnico dentro del cual se logran satisfacer las necesidades de negocio Diseño y reutilización de todos los elementos que conforman la arquitectura Proveer las bases técnicas y administrativas para el diseño y la implementación de sistemas Soportar el procesos de análisis en los proyectos para mantener una consistencia entre los requisitos y la arquitectura

13 Proceso de conformación del equipo
Definición de perfil de arquitecto - Finalidades Análisis y diseños de sistemas (evaluaciones de arquitectura) Soporte técnico y metodológico Evaluación e implantación de nuevas tecnologías (investigación) Definición y administración de toda lógica no funcional Definición y evaluación de esquemas de integración

14 Proceso de conformación del equipo
Entorno El cargo se desarrolla internamente en la Gerencia de Desarrollo informático. Es un puente entre las áreas técnicas y las áreas de desarrollo informático, brindando un soporte en lo relacionado con toda la infraestructura que soportan las aplicaciones (software de la compañía)

15 Proceso de conformación del equipo
Vicepresidencia Administrativa Visión Gerencia de Desarrollo Coordinación Gerencia Técnica Políticas EQUIPO DE ARQUITECTURA Proyecto Gerencia de Grupo de Integración Cambio en Producción Apoyo metodológico Directrices

16 Procesos de Conformación
Conformación actual: Un ejecutivo de arquitectura Tres analistas de arquitectura Un DA (Data Administrator) Un practicante Fuerte relación con la Gerencia Técnica Administración de la plataforma de Bases de Datos Administración de la plataforma Web Application Server J2EE Plataforma Microsoft Soporte para la gerencia de desarrollo

17 Agenda Visión Inicial Proceso de conformación del equipo
Experiencias y productos Arquitectura Inicial Plataforma de Publicación de Servicios Logros Preguntas y Respuesta

18 Experiencias y Productos
Service Oriented Architecture – SOA Plataforma de Publicación de Servicios

19 Experiencias y Productos
Definción de modelo de arquitectura general y un modelo de arquitectura de aplicaciones: SOA MVC Lógica no funcional para el desarrollo de aplicaciones Oracle Application Server 10g Oracle Database 10g Microsoft .NET Framework Definición de modelo de gobierno Especificación de normas, estándares y técnicas Definición de herramientas de desarrollo Jdeveloper, Enterprise Architect, REM, CVS Definición de metodología de desarrollo

20 Propuesta Inicial de Arquitectura
Directorio de Componentes Servicios Servicios de Autenticación y Autorización Servicios de Manipulación de inconsistencias

21 Persistencia Almacenar y recuperar instancias de objetos del negocio
Solucionar la impedancia entre el modelo objetual y el relacional Acceso a repositorios de datos heterogéneos

22 Persistencia

23 Persistencia En este nivel se almacena la información permanente de la aplicación. Estos datos pueden almacenarse en un modelo de datos relacional, un servidor NDS, colas de mensajes, archivos texto o XML, o cualquier otro mecanismo de almacenamiento permanente. Repositorio De Datos Archivos XML Oracle MQ

24 Persistencia

25 Persistencia Manipulación y consulta de datos
Operaciones permitidas por cada tipo de repositorio No tiene inteligencia de negocio Entrega de datos a través de XML Encapsula la complejidad de acceso a cada repositorio Para su implementación se aplicarán los patrones DAO y Factory que facilitan el desacople entre el nivel de Repositorio y el de Persistencia

26 Persistencia

27 Persistencia Recuperar instancias de objetos del negocio en los repositorios de datos Almacenar instancias de objetos del negocio en los repositorios de datos Saber cómo construir objetos del negocio a partir del XML obtenido de la capa inferior de Acceso a Datos Saber cómo almacenar un objeto del negocio utilizando el componente DAO adecuado Utilizar el Cache de objetos para mejorar el rendimiento y la escalabilidad de los sistemas

28 Persistencia

29 Persistencia Responsabilidades Restricciones
Mantener en memoria principal información utilizada frecuentemente por las aplicaciones Ofrecer esquemas de vencimiento de cache Restricciones Los objetos en este nivel deben estar relacionados a entidades cuyos cambios en el tiempo sean mínimos, por ejemplo ciudades y parámetros de aplicación Los objetos en el modelo de cache no debe permitir actualizaciones o entradas diferentes a las existentes en el repositorio de datos.

30 Persistencia Espejismos Realidades
Con la capa de persistencia se solucionarán todos los problemas de acceso a datos de las aplicaciones (Framework de Persistencia, Framework de mapeo Objeto Relacional) El cache será una buena solución para mejorar el rendimiento de las aplicaciones Realidades Mucha de la lógica de negocio está implementada en procedimientos almacenados que deben ser reutilizados por todo el software de la compañía Las bases de datos corporativas son accedidas por muchos sistemas diferentes, por lo que el a menudo el uso de cache no resulta factible

31 Persistencia Productos
Conjuntos de mejores prácticas para el acceso a datos Bind Variables, patrón DAO, patron Factory, DTO Framework liviano de persistencia “casero” Utilidades que aceleran el desarrollo e implementan buenas prácticas. Por ejemplo: Liberación adecuada de recursos (conexiones), uso adecuado de fechas, etc. Evaluación de Frameworks de Persistencia Evaluación de productos como BC4J, TopLink, Hibernate

32 Propuesta Inicial de Arquitectura

33 Componentes de Negocio
Los componentes del negocio son unidades de software autónomas capaces de realizar operaciones puntuales. La unión de varios componentes del negocio en una operación conforma un servicio. En esta capa, los programadores también cuentan con un Framework unificado de utilidades, desarrolladas tanto por proveedores como internamente.

34 Componentes de Negocio

35 Componentes de Negocio
Uno de los objetivos de crear una arquitectura base para la construcción de aplicaciones es poder reutilizar la funcionalidad existente. El nivel de Componentes de Aplicación se crea para facilitar la reutilización. Aquí se crearan unidades atómicas de software, es decir, programas con funcionalidad puntual y sin dependencias ni prerrequisitos de procesamiento. En este nivel se encontrará gran parte del core del negocio. La combinación de esta unidades de software conformarán los servicios.

36 Componentes de Negocio
Reglas de Construcción de Unidades de Software Atomicidad Acoplamiento débil entre componentes Orientación hacia Procesos Construcción con base en estándares Reutilización de Funcionalidad

37 Componentes de Negocio

38 Componentes de Negocio
En este nivel se encontrará un conjunto de utilidades que faciliten el desarrollo de componentes de negocio. La construcción de este nivel se implementa bajo un patrón Fachada

39 Componentes de Negocio
Espejismos Los componentes de negocio siempre utilizarán el framework centralizado sin tener que hacer invocaciones directas de utilidades de terceros, de esta forma los cambios en estas utilidades no afectarán la estabilidad de los componentes de negocio Facilita la capacitación de los desarrolladores en las utilidades disponibles. El diseño es más claro y fácil de entender Se reduce considerablemente el tiempo de diseño de las aplicaciones Permite la convivencia de diferentes versiones de las utilidades

40 Componentes de Negocio
Realidades El esfuerazo necesario para mantener la fachada actualizada es muy grande, por lo que se convierte en un cuello de botella para el proceso de desarrollo. Se debe proveer un conjunto de frameworks estándar de la compañía de manera que sea posible su mantenimient y que contenga las utilidades más importantes Cada proveedor tiene gran parte de su propiedad intelectual en frameworks que aceleran el desarrollo. Estos frameworks deben ser mantenidos por el propio proveedor y en lo posible no deben ser compartidos entre aplicaciones. Cada aplicación tiene su propia versión.

41 Propuesta Inicial de Arquitectura
Directorio de Componentes Servicios

42 Servicios Los servicios son componentes que, a través de las llamadas a componentes del negocio en un orden específico, orquestan las funciones para ejecutar procesos. Los objetivos de los servicios son facilitar la composición de aplicaciones, reutilizar funcionalidades existentes y mantener disponibles las soluciones del negocio en cualquier momento y desde cualquier lugar Servicios

43 Servicios Reglas de Construcción de Servicios
Encapsulamiento: La lógica de servicios debe ser accedida sólo a través de una interfaz pública bien definida. Acoplamiento débil: Su ejecución no depende de la interacción con componentes externos Construcción con base en componentes: Los servicios son una combinación de componentes de negocio. Su lógica de procesamiento se debe limitar a instanciar los componentes y a tomar decisiones simples dependiendo de los resultados de los métodos invocados.

44 Servicios Reglas de Construcción de Servicios
4. Enfoque en procesos: La combinación de los componentes utilizados por un servicio debe representar un proceso. 5. Orientación a uso en la red: Un servicio debe tener una interfaz accesible desde la red. Para nuestra tecnología los servicios deben exponerse como componentes límite. En el momento de adquirir la infraestructura adecuada, los servicios podrán exponerse como EJBs, WebServices, etc.

45 Servicios Reglas de Construcción de Servicios
6. Reutilización: Los servicios deben ser diseñados para ser reutilizables, evitando la duplicidad de implementación de la misma lógica. 7. Construcción con base en estándares: Disminuye el tiempo de mantenimiento y hace mas fácil la capacitación en su funcionamiento, además fortalece la reutilización.

46 Servicios Espejismos El desarrollo de aplicaciones orientadas a servicios es más fácil pues se reutilizan los servicios existentes Debido a que los servicios son sólo una combinación de componentes, las modificaciones se hacen en forma rápida y sencilla Se tiene claramente ubicado en que parte de la aplicación se encuentran los procesos de negocio

47 Servicios Realidades El desarrollo de aplicaciones a partir de servicios requiere un cambio del proceso de desarrollo, pues hay que pensar en servicios y no solamente en funciones específicas del sistema Mientras no cambie la especificación de la interfaz y su semántica, cualquier cambio en los servicios será transparente para los consumidores. Si hay un cambio en alguno de estos dos aspectos se hace necesaria la verificación de TODOS los consumidores de los servicios Durante el ciclo de desarrollo y pruebas el ambiente de ejecución debe ser MUY estable pues una aplicación depende de servicios por fuera de su dominio

48 Propuesta Inicial de Arquitectura
Servicios de Autenticación y Autorización

49 Servicios de Autenticación y Autorización
Reto Los servicios deben ser publicados y consumidos entre aplicaciones con sistemas de seguridad heterogeneos Objetivo Los servicios de autenticación y autorización deben facilitar la labor del desarrollador implementando una solución estándar reutilizable

50 Servicios de Autenticación y Autorización
Sistema de Seguridad X Sistema de Seguridad Y Consumidor A Consumidor B Consumidor C Servicio Autenticación Autorización

51 Servicios de Autenticación y Autorización
Espejísmos El problema de la seguridad está resuelto en la lógica no funcional de las plataformas La seguridad declarativa es suficiente para las aplicaciones empresariales Se pueden consolidar los sistemas de seguridad corporativos en un único sistema de seguridad centralizado

52 Servicios de Autenticación y Autorización
Realidades El problema de seguridad en las aplicaciones empresariales es complejo, pues se tienen conjuntos de restricciones, perfiles, cargos, etc... Estos escenarios no son fácilmente implementados con la LNF de las plataformas o con la seguridad declarativa. Se requiere la seguridad dinámica o “programática” Es un hecho que existen muchos sistemas de software tanto internos como externos que probablemente no compartan los requisitos de seguridad y que requieran sistemas de seguridad diferentes. Esto situación no cambiará mucho, aunque se deben tratar de consolidarlos para tener una cantidad administrable

53 Productos – Aplicación Orientadas a Servicios
VISTAS Opciones de Usuario Parámetros de servicios SERVICIO 1 SERVICIO 2 CONTROLLER Administrador de Vistas Control de flujo de aplicación SERVICIOS Propios Reutilización SERVICIO N

54 Productos – Aplicación Orientadas a Servicios
1. HTTP Request Desde opción de aplicación 2. Solicutud Descripción Servicio (http Request) 4. Descripción Del Servicio (http Response) Directorio De Servicios NSS 3. Consuta Detalles Servicio

55 Productos – Directorio de Servicios
Vista de Descripción del Servicio XML de solicitud de descripción de servicio

56 Productos – Sistema de Seguridad de Servicios
Respuesta a Requerimiento REQUERIMIENTO XML Patrón Fachada Sistema de Seguridad SQL SERVER MVM MUS

57 Producto - Publicación de Servicios PUBS

58 Productos – Publicación de Servicios PUBS
¿Qué es PUBS? Conjunto de frameworks, programas y prácticas que pretenden solucionar los problemas comunes de los desarrolladores cuando quieren lograr la integración entre aplicaciones

59 Productos – Publicación de Servicios PUBS
¿Qué hace PUBS? Define e implementa un modelo de seguridad extensible que facilita la integración de sistemas con modelos de seguridad heterogéneos Provee herramientas para publicar y consumir servicios desde plataformas Java, Microsoft y C/S Ofrece un lenguaje común (interoperabilidad) entre las diferentes plataformas Provee un servicio de localización dinámica Provee un directorio de servicios

60 Productos – Publicación de Servicios PUBS
Módulo de Seguridad Proxy de Seguridad Módulo de Localización CONSUMIDOR Framework Consumidor Framework Publicador HTTP Request SERVICIO HTTP Response - XML

61 Productos – Publicación de Servicios PUBS
XML es el lenguaje común, los frameworks se encargan de la interpretación de esta información

62 Productos – Publicación de Servicios PUBS
Registro y consulta de servicios y localización dinámica

63 Productos – Publicación de Servicios PUBS
FrameworksPubs.pbl FrameworksPubs.jar FrameworksPubs.dll Aplicaciones Proxy PUBS C/S AplicaciónJ2EE Directorio Localizador Middleware Adaptadores en PL/SQL Acceso a Datos Adaptadores de seguridad Middleware Base de Datos Metadata Sesiones Repositorios de seguridad Autenticación Autorización Backend

64 Productos – Publicación de Servicios PUBS
Conclusiones Logra integrar aplicaciones, incluso, aplicaciones desarrolladas en plataformas diferentes Provee mecanismos para compartir servicios de procesamiento y servicios con interfaz de usuario Resuelve el problema de autenticación y autorización entre plataformas de seguridad diferentes Se logra reutilizar funcionalidad clave entre las aplicaciones (calidad de la información, p.e.)

65 Agenda Visión Inicial Proceso de conformación del equipo
Experiencias y productos Arquitectura Inicial Plataforma de Publicación de Servicios Logros Preguntas y Respuesta

66 Logros Se logró consolidar el área de arquitectura y están claramende definidas sus responsabilidades y alcance Se logró implementar una Arquitectura Orientada a Servicios mediante la adquisición de productos y el diseño de una plataforma de acuerdo con nuestras necesidades Se logró la especificación de un conjunto de normas y políticas claras para el diseño e implementación de aplicaciones

67 Logros Se tienen herramienta y procedimientos para la evaluación de la arquitectura de los proyectos presentados por los proveedores e internos Los proyectos tiene un soporte técnico importante que les facilita el análisis y la mitigación de riesgos de tecnología Se está mejorando el proceso de desarrollo mediante la implementación de una metodología de desarrollo clara y acorde con las condiciones tecnológicas y del negocio

68 Agenda Visión Inicial Proceso de conformación del equipo
Experiencias y productos Arquitectura Inicial Plataforma de Publicación de Servicios Logros Preguntas y Respuesta

69 Preguntas y Respuestas