Septiembre 27 a Octubre 01 de 2005 Bogotá, Colombia Implementación de una visión de arquitectura Experiencias y Resultados Andrés Camilo Bustamante Analista

Septiembre 27 a Octubre 01 de 2005Bogotá, Colombia

Implementación de una visión de arquitectura

Experiencias y Resultados

Andrés Camilo BustamanteAnalista de ArquitecturaGerencia de [email protected]

Suramericana de Seguros S.A.

XXV Salón de Informática “Arquitecturas Empresariales de Software” Septiembre 28-Octubre 01 de 20052

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


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


Visión Inicial

RetoConstruir aplicaciones con prácticas de diseño e infraestructura lo

suficientemente robustas que nos brinden:

Velocidad (de desarrollo y de ejecución)Velocidad (de desarrollo y de ejecución)

DisponibilidadDisponibilidad

ConfiabilidadConfiabilidad

ProyecciónProyección

SeguridadSeguridad

Calidad en nuestros productosCalidad en nuestros productos


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.


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.


Agenda



+Logros+ Preguntas y Respuesta


Proceso de Conformación del Equipo


Proceso de conformación del equipo

Equipo de Arquitectura

Especificaciones

Arquitectura ( Diseño ) Aplicaciones Técnica

Modelo de Integración Modelo de Información Modelo de Interfaces

Gobierno

Coordinación y reporte Políticas y normativas

Mejores prácticas (Patrones, Frameworks)

Publicación y Documentación

Infraestructura

Estándares tecnológicos Plataforma de integración

y Servidor de Aplicaciones Herramientas y esquemas

de administración



+Iniciativa gerencial+Necesidad evidente en todos los equipos+Definición de perfil de arquitecto

– Habilidades– Responsabiliddes– Finalidades– Entorno

+Formulación de proyectos



+ 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.



+ 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



+ 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



+ 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)



Vicepresidencia Administrativa

EQUIPO DE ARQUITECTURA

Apoyo metodológicoDirectrices

Visión

Proyecto

Gerencia de Proyecto

Grupo de Integración

Cambio en Producció

n



Proyecto



Gerencia de Desarrollo

Coordinación

Gerencia Técnica

Políticas


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


Agenda





Experiencias y Productos

Service Oriented Architecture – SOAPlataforma de Publicación de Servicios


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


Propuesta Inicial de Arquitectura

Directorio de Componentes

Servicios

Servicios de Autenticación y Autorización

Servicios de Manipulación de inconsistencias


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


Persistencia

Repositorio de Datos

ACCESO A DATOS

PERSISTENCIA

CACHE


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

OracleArchivos XML MQ


Persistencia


ACCESO A DATOS

PERSISTENCIA

CACHE


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


Persistencia


ACCESO A DATOS

PERSISTENCIA

CACHE


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


Persistencia


ACCESO A DATOS

PERSISTENCIA

CACHE


Persistencia

+ Responsabilidades– 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.


Persistencia

+ Espejismos– 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


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



SERVIDOR DE APLICACIONES

Componentes del

Negocio

Servicios

Pers

iste

ncia



Ap

licacio

nes

Dir

ecto

rio

de S

erv

icio

s

Servicios de manipulación de inconsistencias


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.



COMPONENTES DE APLICACIÓN

BASE SURAMERICANA

BA

SE

1

BA

SE

2

BA

SE

N

. . . . . .



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.



Reglas de Construcción de Unidades de Software

1. Atomicidad

2. Acoplamiento débil entre componentes

3. Orientación hacia Procesos

4. Construcción con base en estándares

5. Reutilización de Funcionalidad



COMPONENTES DE APLICACIÓN

BASE SURAMERICANA

BA

SE

1

BA

SE

2

BA

SE

N

. . . . . .



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



+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



+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.




Componentes del

Negocio

Servicios

Pers

iste

ncia



Ap

licacio

nes

Dir

ecto

rio

de S

erv

icio

s


Servicios



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

Serv

icio

s

Dire

ctor

io d

e Co

mpo

nent

es

Dire

ctor

io d

e Se

rvic

ios


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.

Reglas de Construcción de Servicios


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.



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.



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


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




Componentes del

Negocio

Servicios

Pers

iste

ncia



Ap

licacio

nes

Dir

ecto

rio

de S

erv

icio

s





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


Sistema de Seguridad X


ConsumidorC

Sistema de Seguridad Y

ConsumidorB

ConsumidorA

Servicio

Autenticación 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



+ 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


Productos – Aplicación Orientadas a Servicios

APLICACIÓN

GU

IO

pcio

nes U

suar

ioP

arám

etro

s de

Ser

vici

os

CO

NT

RO

LL

ER

SERVICIO 1

SERVICIO 2

SERVICIO N

VISTASOpciones de UsuarioParámetros de servicios

CONTROLLERAdministrador de VistasControl de flujo de aplicación

SERVICIOSPropiosReutilización

SERVICIO 1

SERVICIO 2

SERVICIO N


Productos – Aplicación Orientadas a Servicios

Contenedor WEB

Front EndController ( Servlet, Asp )

Servicio de VisualizaciónY

HTTP RequestDesde una opción de una

aplicación

Directorio deServicios

Serviciode

Procesamiento

3. C

onsulta

de

los d

eta

lles d

el

serv

icio

1. S

olic

utu

d d

e

descrip

ció

n d

el

Serv

icio

(http

request) 4

.Descripció

n d

el

serv

icio

(http

response)

NSSHTTP RequestAutenticación

5. Solicitud al servicio (HTTP Request + XML)

6. Repuesta XML del Servicio (HTTP Response)

5. Solicitud al servicio(HTTP Request + XML)

6. Repuesta HTML del Servicio(HTTP Response)

Controller View1

View2

Model

Controller

Model

Aute

nticació

n

y

Auto

rizació

n

Aute

nticació

n

y

Auto

rizació

n

Repositorio de Datos de Servivios

1. HTTP RequestDesde opción de aplicación

2. SolicutudDescripción

Servicio(http Request)

3. ConsutaDetallesServicio

4. DescripciónDel

Servicio(http Response)

DirectorioDe

Servicios

DirectorioDe

ServiciosNSSNSS


Productos – Directorio de Servicios

MODELO

DIRECTORIO DE SERVICIOS

Generador XML

Manejador de Datos

Controller

Cache de Servicios

VISTA:XML Descripción de Servicio

HTTP RequestDesde un Servicio

HTTP ResponseXML de descripción del servicio

Repositorio de Datos de Serv iv ios

XML de solicitud de descripción de servicio

Vista deDescripcióndel Servicio


Productos – Sistema de Seguridad de Servicios

MODELO

NSS

Controller

GENERACIÓN DE XML

HTTP RequestDesde un Servic io

HTTP Response

MUSMV MSQL

SERVER

Repositorio de Datos de Serv iv ios

Sistema de Seguridad

REQUERIMIENTOXML

Respuesta aRequerimiento

Sistema de SeguridadSistema de Seguridad

SQLSERVER

SQLSERVER MVMMVM MUSMUS

PatrónFachada


Producto - Publicación de Servicios PUBS


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



¿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



Fra

mew

ork

Con

su

mid

or

Fra

mew

ork

Con

su

mid

or

SER

VIC

IOS

ER

VIC

IO

Pro

xy d

e

Seg

uri

da

d

Pro

xy d

e

Seg

uri

da

d

Mód

ulo

de

Localiza

ció

n

Mód

ulo

de

Localiza

ció

n

Fra

mew

ork

Pu

blicad

or

Fra

mew

ork

Pu

blicad

or

HTTP RequestHTTP Request

Mód

ulo

d

e

Seg

uri

dad

Mód

ulo

d

e

Seg

uri

dad

CO

NS

UM

IDO

RC

ON

SU

MID

OR

PUBSHTTP Response - XMLHTTP Response - XML



XML es el lenguaje común, los frameworks se encargan de la interpretación de esta información



Registro y consulta de servicios y localización dinámica



Adaptadores de seguridad

FrameworksPubs.dllFrameworksPubs.jar

Base de DatosMetadataSesiones

AplicaciónJ2EEDirectorio

Localizador

Repositorios de seguridad

AutenticaciónAutorización

FrameworksPubs.pbl

Proxy PUBS C/S

Adaptadores en

PL/SQL

Acceso a Datos

Aplicaciones

Middleware

Backend

Middleware



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.)


Agenda





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


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


Agenda





Preguntas y Respuestas

Documents

Septiembre 27 a Octubre 01 de 2005 Bogotá, Colombia Implementación de una visión de arquitectura Experiencias y Resultados Andrés Camilo Bustamante Analista