SEPGLA 2007 Migración a Ambientes de Arquitectura Orientada a Servicios (SOA) Grace Lewis

1

© 2007 Carnegie Mellon University

Migración a Ambientes de Arquitectura Orientada a Servicios (SOA)

Grace A. LewisSoftware Engineering Institute, USANoviembre 26, 2007

2Versión 1.5 (SEPG-LA 2007)


Contenido

Introducción a SOA

• Desde los 50,000 Pies de Altura



Pilares del Desarrollo de Sistemas Basados en SOA

Técnica para la Migración y Reutilización de Servicios (SMART)

Implicaciones para los Procesos de Desarrollo de Sistemas

Conclusiones

Conceptos Básicos

2



¿Qué es SOA?

Arquitectura orientada a servicios es una manera de diseñar, desarrollar, desplegar y administrar sistemas en la cual

• Servicios proveen funcionalidad reutilizable.

• Las definiciones de interfaces de servicios son artefactos de primera clase.

• Una infraestructura SOA posibilita el descubrimiento, composición e invocación de servicios.

• Protocolos son en su mayoría, pero no exclusivamente, intercambios de documentos basados en mensaje.

• Consumidores de servicios son construidos utilizando la funcionalidad brindada por los servicios disponibles.

Conceptos Básicos



Servicios

Servicios son componentes reutilizables que representan tareas del negocio.

• Consulta de clientes

• Validación de tarjeta de crédito

• Consulta del estado del tiempo

• Reservación de hotel

Servicios pueden

• Estar distribuidos globalmente en múltiples organizaciones

• Reconfigurados en nuevos procesos de negocio

Las definiciones de interfaces de servicios son artefactos de primera clase, bien definidos e idealmente disponibles en un registro de servicios

Conceptos Básicos

3



Infraestructura SOA

Conjunto de tecnologías que conectan consumidores de servicios a servicios

• Productos, estándares y protocolos que soportan la comunicación—Típicamente intercambio de documentos basado en mensajes

— Web Services (HTTP, SOAP, WSDL)

— Message-oriented middleware (i.e. IBM Websphere MQ)

— Publish/subscribe (i.e. Java Messaging Service — JMS)

— CORBA …

• Servicios de infraestructura disponibles para proveedores y/o consumidores de servicios

— Seguridad, descubrimiento, transformación de datos, …

• Herramientas y guías para desarrollo, despliegue y administración

Conceptos Básicos



Consumidores de Servicios

Clientes de la funcionalidad brindada por los servicios

• Aplicaciones de usuario final

• Sistemas internos

• Sistemas externos

• Servicios compuestos

Consumidores se conectan de forma programática a servicios.

Conceptos Básicos

4



Componentes de un Sistema Basado en SOA

Aplicación Usuario

Final

Servicio A

Infraestructura SOA

Sistema de Información

Gerencial

Portal

Internet

Sistema Externo

Servicio B

Servicio C

Servicio D

Usuarios Internos

DescubrimientoSeguridadHerramientas de Desarrollo

Código Nuevo o Existente

Sistema Interno


Infraestructura

Implementación de Servicios

Interfaces de Servicios

Consumidor Externo

Conceptos Básicos



En Resumen …

SOA es una manera de desarrollar sistemas en la cual

• Servicios contienen funcionalidad reutilizable con interfaces bien definidas.

• Una infraestructura SOA permite el descubrimiento, composición e invocación de servicios.

• Consumidores de servicios son construidos utilizando funcionalidad de los servicios disponibles.

Si es manejado bien, la adopción de SOA puede llevar a

• Eficiencia de costos

• Agilidad de negocios

• Adaptabilidad

• Aprovechamiento de la inversión en sistemas existentes

Conceptos Básicos

5



Contenido

Introducción a SOA



— Operaciones Básicas

— OASIS SOA Reference Model (SOA RM)

— Web Services





Conclusiones

Desde los 10,000 Pies



Contexto Operacional de un Sistema Basado en SOA

Sistema de Gestión de

Pedidos

Sistema Financiero

Organización 1Organización 2

Sistema de Validación de

Tarjetas de Crédito

Infra

estru

ctu

ra S

OA

Aplicación de Proceso de Pedidos

Aplicación de Gestión de Clientes

Sistema de Envíos

FedEx

Sistema de Envíos

UPS

Sistema de Envíos

DHL

Aplicación de Pedidos

Organización Cliente

Aplicaciones pueden

interactuar con sistemas de diferentes organizaciones a través de interfaces estándar

Aplicaciones pueden

interactuar con sistemas

internos a través de interfaces estándar

Organizaciones externas

pueden acceder a funcionalidad

internaAplicaciones pueden automatizar sus

procesos utilizando funcionalidad externa

Nuevas aplicaciones pueden ser creadas reutilizando funcionalidad existente

Fire

wa

ll

Internet

Operaciones Básicas

6



Tres Operaciones Básicas Para Soportar Sistemas Basados en SOA

Descubrimiento de Servicios

• Repositorios de servicios son consultados buscando servicios con ciertas características.

Composición de Servicios

• Aplicaciones/Consumidores de servicios son construidos mediante la integración de funcionalidad brindada por servicios.

Invocación de Servicios

• Los consumidores invocan los servicios necesarios y el código correspondiente a la implementación de los servicios es ejecutado.




Estático vs. Dinámico

Estático—Con la tecnología actual, el descubrimiento y la composición de servicios se hace durante diseño del sistema.

• El desarrollador descubre servicios y obtiene sus direcciones.

• El desarrollador escribe código para invocar los servicios localizados en estas direcciones.

Dinámico—Hay una gran cantidad de investigación en el área de descubrimiento y composición de servicios en tiempo de ejecución.

• La aplicación descubre servicios y obtiene direcciones.

• La aplicación contiene código para invocar el servicio descubierto y “sabe” que información es necesaria para la ejecución del servicio.

Hay muchas técnicas Intermedias.

• La aplicación descubre los servicios, pero se requiere intervención del usuario para seleccionar servicios y proveer la información requerida.

• “Portals” son configurados del tal manera que sus “portlets” corresponden a servicios.


7



Descubrimiento de Servicios

Sistema Financiero


Aplicación de

Facturación


Pedidos


Clientes

Servicios son registrados en un

Registro de Servicios que es parte de la infraestructura SOA.

El Sistema de Gestión de Clientes registra sus dos servicios- Búsqueda de Clientes- Directorio de Clientes

Desarrolladores de consumidores de servicios consultan el registro buscando servicios que contengan una funcionalidad deseada.

Hay algún servicio que pueda devolver toda la información de un cliente dado un código de cliente?

Infraestructura SOA Descubrimiento

SeguridadHerramientas de Desarrollo

Registro de Servicios


Mayores retos: Descripción de servicios y mantenimiento del repositorio



Composición de Servicios

Sistema Financiero


Sistema de Gestión Pedidos


Clientes

La aplicación de proceso de pedidos necesita producir un reporte impreso que para un cliente contenga información del cliente, estado financiero y pedidos pendientes.

Infraestructura SOA Descubrimiento

SeguridadHerramientas de Desarrollo


El servicio de Estado Financiero Cliente es invocado para obtener el saldo del cliente.

El servicio de Búsqueda de Clientes es utilizado para obtener la información del cliente.

El servicio de Pedidos Pendientes es invocado para obtener los pedidos pendientes.


Mayores retos: Incompatibilidad de procesos/datos y manejo de transacciones

8



DiscoveryDiscovery

Invocación de Servicios

Co

ns

um

ido

r d

e S

erv

icio

sService Request

Service Response

1

Service Request

Service Response

2

Service Query

Service Location

Service Request

Service Response

3

Service Query

Service Location

Service Query

Service Location

Servicio

Discovery

Discovery

Service Broker


Mayor reto: Trabajar con servicios que pueden no estar disponibles



¿Entonces Qué Es Diferente?

Conceptualmente no hay nada nuevo, pero, finalmente se han integrado tecnologías y prácticas existentes en una manera que realmente funciona.

• Mayor alineamiento entre TI y el negocio

— Servicios representan tareas/actividades del negocio

• Gran apoyo por parte de la industria

• Basado en estándares

• Mayor rigor en la especificación de interfaces

• Verdadero acoplamiento débil entre servicios y consumidores

— Consumidores no tiene que instalar componentes específicos

— Independencia de la plataforma de implementación

o Lo que está detrás de la interface es irrelevante para el consumidor del servicio


9



¿Entonces Cuál Es El Reto? ¡Crear Buenos Servicios!

Representan tareas comunes de múltiples casos de uso o procesos del negocio

Tienen (o pueden tener) múltiples consumidores

Posibilitan la integración programática entre consumidores y servicios

Corresponden a funcionalidad que no requiere mantener un estado (el servicio no conserva información acerca de pasadas invocaciones o el orden en que debe ser invocado)

Las entradas y salidas de sus operaciones no requieren la construcción de consumidores muy complejos

Son de naturaleza “request-response”

• Aunque SOA 2.0 introduce el manejo de eventos

Miremos una definición más formal de SOA …




OASIS SOA RM

Modelo de referencia para SOA

Objetivo es “definir la esencia de la arquitectura orientada servicios, y

construir un vocabulario y un entendimiento común acerca de SOA.”

Independiente de la tecnología de implementación

Versión 1.0 (Octubre 2006) disponible en

http://www.oasis-open.org/specs/index.php#soa-rmv1.0

Fuente: OASIS SOA RM v1.0

OASIS SOA RM

10



Definiciones Básicas

“Arquitectura Orientada a Servicios es un paradigma para organizar y

utilizar capacidades distribuidas que pueden estar bajo el control de diferentes dueños. Brinda una manera uniforme de ofrecer, descubrir,

interactuar y utilizar capacidades para producir efectos deseados que

son consistentes con precondiciones y expectativas medibles.”

“Un servicio es la manera mediante la cual las necesidades de un

consumidor son reunidas con las capacidades de un proveedor.”


OASIS SOA RM



Características de Sistemas Basados en SOA

Tienen entidades que pueden ser identificadas como servicios de acuerdo con la definición del modelo

Permiten identificar cómo se establece visibilidad entre proveedores y consumidores de servicios

Permiten identificar cómo es mediada la interacción

Permiten identificar el efecto de utilizar servicios

Tienen descripciones asociadas a servicios

Permiten la identificación del contexto de ejecución requerido para soportar la interacción

Puede ser posible identificar cómo son manejadas las políticas y cómo los contratos pueden ser modelados y obligar su cumplimiento


OASIS SOA RM

Ahora miremos Web Services como una implementación específica de SOA …

11



Web Services

Web Services es un mecanismo para la implementación de sistemas basados en SOA.

• Interfaces de servicios son descritas utilizando Web Services Description Language (WSDL).

• Datos son transmitidos utilizando SOAP sobre HTTP.

• UDDI es opcionalmente utilizado como el servicio de directorio.

Debido a que es el mecanismo más común, con frecuencia Web Services es utilizado como un equivalente de SOA.

Web Services



Stack de Protocolos de Web Services

• Los estándares en verde son los más utilizados y más estables, los amarillos están emergiendo como estándares de preferencia, y los rojos están desapareciendo.

• La mayoría de estándares para Web Services están emergiendo y algunos incluso compiten.

• Seguridad, QoS, Transacciones y Administración tienen que manejarse en todos los niveles.

DiscoveryUDDI

DescriptionWSDL

Message FormatSOAP, REST

EncodingXML

TransportHTTP

Security

Man

age

me

nt

Tra

nsactio

ns

Qu

ality

of S

erv

ice

Orchestration and

ChoreographyWSCL, WSCI, BPEL,

WS-Coordination

BPML, BPSS

Base

Stack

Adapted from “XML and Web Services Unleashed”, SAMS Publishing

Web Services

12



Web Services en Tiempo de Diseño—Estático

Alice (consumidor de

servicios) obtiene el documento WSDL que

corresponde al Web Service de Bob (e.g. busca en el repositorio

UDDI).

Alice utiliza el documento

WSDL como entrada para herramientas que generan

todo el código para

construcción de mensajes (e.g. WSDL2Java).

Bob (proveedor de servicios)

expone funcionalidad en su sistema como un Web Service (o crea un Web

Service específico) y

coloca un documento

WSDL en un “lugar accesible” (e.g. repositorio

UDDI).

Alice adiciona código a su

aplicación que ejecuta el código de construcción

de mensajes para conectarse al Web Service de Bob y código

adicional que utiliza la

respuesta del Web Service de

Bob.

Web Services



Web Services en Tiempo de Diseño—Dinámico

Alice (consumidor de

servicios) escribe código

en su aplicación que consulta el repositorio de servicios en tiempo de ejecución.

Alice escribe código en su

aplicación que selecciona un servicio de la lista retornada por la consulta.

Bob (proveedor de servicios) crea un Web Service,

lo describe utilizando WSDL, y lo registra en un

repositorio de servicios (e.g.

UDDI).

Alice escribe código en su

aplicación que invoca el servicio

seleccionado con los

parámetros apropiados.

Para que esto sea completamente transparente, Alice y Bob tienen que compartir una ontología utilizada para describir la semántica del servicio.

Web Services

13



Web Services en Tiempo de Ejecución

1. Usuario ejecuta la aplicación de Alice.

3. Cuando el servidor HTTP de Bob ve un mensaje SOAP, lo envía al SOAP engine.

2. Aplicación construye un mensaje SOAP y lo envía al servicio de Bob vía HTTP.

4. El SOAP engine interpreta el mensaje y construye el llamado al sistema de Bob.

5. El sistema de Bob ejecuta la operación invocada.

6. El sistema de Bob retorna los resultados de la operación.

HTTPRequest Call

ReturnHTTPResponse

7. El SOAP engine construye el mensaje de respuesta y lo retorna vía HTTP.

Servidor HTTP Sistema de BobUsuario de la Aplicación de

Alice

8. La aplicación de Alice interpreta la respuesta y muestra resultados al usuario.

Web Services



En Resumen …

• Ambientes SOA tienen que soportar tres operaciones básicas.

• Descubrimiento de servicios

• Composición de servicios

• Invocación de servicios

• Conceptualmente, no hay nada diferente en SOA

• Lo que pasa es que las tecnologías y las prácticas que soportan la integración de sistemas se están utilizando en una manera que funciona.

• El OASIS SOA RM presenta una definición muy abstracta de SOA, servicio y sistema basado en SOA que está abierta a múltiples interpretaciones

• Web Services es el mecanismo más utilizado para la implementación de SOA—pero no el único

Desde los 10,000 Pies

14



Contenido

Introducción a SOA







Conclusiones

Desde los 1,000 Pies de Altura



Un Potencial Problema

Si servicios, consumidores de servicios e infraestructura SOA son desarrollados por la misma organización, los retos son menores.

• La comunicación es más simple entre desarrolladores (o quizás son los mismos desarrolladores)

Sin embargo, es cada vez más común encontrar que los tres tipos de componentes son desarrollados por diferentes organizaciones de manera independiente—es un nuevo modelo de negocios.

• Las decisiones tomadas localmente por cada uno de estos grupos de desarrollo puede tener un efecto sobre los demás grupos.


15




1. Identificar servicios apropiados (internos y

externos) que puedan ser reutilizados


Pedidos

Sistema Financiero

Organización 1

Organización 2



Infra

estru

ctu

ra S

OA



Sistema de Envíos

FedEx

Sistema de Envíos

UPS

Sistema de Envíos

DHL

Aplicación de Pedidos

Organización Cliente

2. Entender la infraestructura y las interfaces de servicios en términos de funcionalidad y calidad de servicios

Un consumidor de servicios necesita crear una nueva aplicación

basada en SOA.

3. Crear la nueva aplicación utilizando tantos servicios como sea posible

4. Diseñar la aplicación de tal manera que pueda fácilmente

acomodar cambios en los servicios

Fire

wa

ll

5. ¡¡Pruebas!!

Internet




Retos para Consumidores de Servicios

Servicios disponibles pueden no satisfacer requerimientos funcionales y no funcionales.

Servicios pueden cambiar o desaparecer sin notificación.

Herramientas y programas que hacen parte de la infraestructura pueden ser incompatibles con el ambiente de desarrollo.

Servicios pueden ser semánticamente incompatibles desde el punto de vista del consumidor.

Servicios provenientes de diferentes organizaciones pueden ser inconsistentes.

La prueba total del sistema requiere que instancias de prueba de todos los servicios estén disponibles.


16



Desarrolladores de Servicios


Pedidos

Sistema Financiero

Organización 1

Organización 2



Infra

estru

ctu

ra S

OA



Sistema de Envíos

FedEx

Sistema de Envíos

UPS

Sistema de Envíos

DHL4. Diseñar, crear y publicar servicios para consumidores

internos y/o externos

3. Anticipar requerimientos de futuros consumidores

2. Analizar requerimientos de la

infraestructura, interfaces,

funcionalidad y QoS de consumidores

1. Identificar funcionalidad de

negocios que pueda ser expuesta como

un servicio

Internet




Retos para Desarrolladores de Servicios

Si requerimientos de consumidores no son entendidos, los servicios podrían nunca ser utilizados.

El esfuerzo de transformación de tipos de datos podría ser mayor de lo esperado.

En ambientes SOA propietarios podrían existir

• Múltiples restricciones sobre los servicios desarrollados

• Dependencias en herramientas y programas de la infraestructura que están en conflicto con el ambiente de desarrollo

Aún no existen guías claras para el desarrollo de Acuerdos de Nivel de Servicios (SLAs).


17



Desarrolladores de Infraestructura


Pedidos

Sistema Financiero

Organización 1Organización 2



Infra

estru

ctu

ra S

OA



Sistema de Envíos

FedEx

Sistema de Envíos

UPS

Sistema de Envíos

DHLServicios de

Infraestructura

Descubrimiento

Seguridad

Herramientas de Desarrollo


Selección de productos y estándares

Mecanismos de conexión

Herramientas para desarrolladores de

servicios y consumidores

Documentación y soporte

Internet




Retos para Desarrolladores de Infraestructura

Minimizar el efecto de cambios en estándares y productos utilizados por la infraestructura sobre sus usuarios.

• Especialmente estándares emergentes

Estimar correctamente el esfuerzo para el desarrollo, soporte y entrenamiento a usuarios.


18



Granularidad de Servicios 1

La granularidad de las interfaces de servicio puede afectar desempeño porque los servicios son ejecutados como el intercambio de una petición de servicio y una respuesta del servicio a través de una red.

• Si las interfaces de servicio son de alta granularidad, sus consumidores van a recibir más datos de los necesarios en el mensaje de respuesta.

• Si las interfaces de servicio son de baja granularidad, sus consumidores van a tener que hacer múltiples viajes al servicio para obtener los datos necesarios.




Granularidad de Servicios 2


Pedidos

[Info Básica, Historia Pedidos, Pedidos Pendientes]

getInfoCliente( IdCliente )

El Sistema de Gestión de Pedidos puede exponer la funcionalidad de obtener toda la información

de un cliente como una sola operación …

HistPedidos getHistoriaPedidos( IdCliente)

InfoCliente getInfoBasica( IdCliente )

Pedido[] getPedidosPendientes( IdCliente )

… o el servicio puede ser más granular y tener tres operaciones diferentes para los

tres tipos de información


19



Manejo de Transacciones 1

La decisión de asignación de responsabilidad del manejo de transacciones tiene un efecto sobre el desarrollo de sistemas basados en SOA.

Escenario

• La Aplicación de Proceso de Pedidos necesita colocar un pedido.

• Tres sistemas están involucrados

— El Sistema de Gestión de Pedidos controla la creación del pedido.

— El Sistema Financiero contiene la información financiera del cliente.

— El Sistema de Inventarios contiene información sobre partes y cantidad en inventario.

• Un pedido se considera completo después de verificar el estado financiero del cliente y las partes en inventario son marcadas para envío.






Pedidos

↓↓↓↓ colocarPedido

�� Responsabilidad: Proveedor de Servicios

Infraestructura SOA


Sistema de

Inventario

Sistema Financiero


↓↓↓↓ marcarInventario ↓↓↓↓ getInfoFinanciera

1. Aplicación invoca el servicio

colocarPedido.

4. Sistema de Gestión de Pedidos invoca

getInfoFinancera.

2. Infraestructura localiza el servicio colocarPedido.

3. Sistema de Gestión de Pedidos inicia

transacción

5. Sistema de Gestión de Pedidos invoca

marcarInventario.

6. Aplicación recibe el estado de

la operación.

NOTA: El proveedor de servicio podría decidir hacer

llamados directos en vez de utilizar las interfaces de

servicio


20





Pedidos

↓↓↓↓ crearPedido

�� Responsabilidad: Infraestructura

Infraestructura SOA


Sistema de

Inventario

Sistema Financiero



1. Aplicación invoca el servicio

colocarPedido.

3. Infraestructura invoca getInfoFinanciera.

2. Infraestructura sabe que es una

operación transaccional e

inicia transacción.

5. Infraestructura invoca crearPedido.

4. Infraestructura invoca marcarInventario.

6. Aplicación recibe el estado de

la operación.

NOTA: Dependiendo de

la implementación, las operaciones podrían requerir operaciones

compensatorias.






Pedidos


�� Responsabilidad: Consumidor de Servicios

Infraestructura SOA


Sistema de

Inventario

Sistema Financiero

↓↓↓↓ getInfoFinanciera

↓↓↓↓ marcarInventario



2. Aplicación invoca los tres

servicios.1. Aplicación inicia transacción.


NOTA: Dependiendo de

la implementación, las operaciones podrían requerir operaciones

compensatorias.

21



En Resumen …

Hay tres grupos de desarrollo en un sistema basado en SOA.

• Desarrollo de consumidores de servicios

• Desarrollo de proveedores de servicios

• Desarrollo de la infraestructura

Entre más distribuidos estos grupos de desarrollo, mayores los retos del desarrollo de sistemas basados en SOA.




Contenido

Introducción a SOA




Conclusiones

Pilares

22




Alin

ea

mie

nto

E

stra

tég

ico

Principios de Diseño para SOA

Desarrollo de Sistemas Basados en SOA

Eva

lua

ció

n d

e

Te

cn

olo

gía

SO

A

Go

ve

rna

nc

e

Ca

mb

io d

e

Me

nta

lida

d

Pilares



Alineamiento con Objetivos del Negocio

Cualquier estrategia SOA exitosa tiene que estar alineada con los objetivos del negocio.

Ejemplos

• Reducir tiempo de mercado para aplicaciones

• Incrementar información disponible a clientes

• Integrar partners de negocio

• Reducir costo de desarrollo mediante reutilización

• Reducir costo de mantenimiento

• Mejorar servicio al cliente

• Mejorar procesos internos

Pilares: Alineamiento Estratégico

23



Diferentes Necesidades y Objetivos de Negocio Requieren Diferentes Estrategias SOA

Necesidades y Objetivos del Negocio

Estrategia SOA

Incrementar información disponible para los clientes del negocio

• Portals intuitivos

• Creación de servicios relacionados con información de interés para clientes

Integrar partners de negocio • Interoperabilidad heterogénea

• Integración de sistemas internos

• Identificación de reglas del negocio

Mejorar procesos de negocio • Identificación de procesos clave

• Eliminación de redundancia

• Consistencia entre procesos

• Servicios que utilizan sistemas existentes




Relación entre Procesos de Negocio y Servicios

1. Identificar procesos de negocio que apoyan los objetivos del negocio.

2. Identificar candidatos para servicios.

• De arriba hacia abajo (Top-Down)

— Pasos comunes entre procesos de negocio se convierten en candidatos para servicios.

• De abajo hacia arriba (Bottom-Up)

— Hacer un inventario de los sistemas existentes.

— Sistemas con funcionalidad que apoya los procesos de negocio se convierten en candidatos para migración a servicios.

3. Servicios son seleccionados y priorizados con base en su relación con los objetivos del negocio.


24



Adopción Disciplinada de SOA

Adaptado de “Meeting the Challenges of SOA Adoption,” keynote de Roy Schulte en la SOA In Action Virtual Conference, Noviembre 2006.




Falta de Governance Inhibe la Adopción de SOA

Una encuesta de Infoworld llamada 2007 SOA Trend Survey indica que la falta de governance es el inhibidor principal de la adopción de SOA (50%).

• En la encuesta del 2006 era 43%.

Mayor que otros inhibidores que parecen más obvios

• Dificultad para construir un SOA roadmap (40%)

• Desempeño y confiabilidad (39%)

• Estándares incompletos e inmaduros (39%)

Pilares: SOA Governance

25



SOA Governance

SOA governance es el conjunto de políticas, reglas y mecanismos de cumplimiento para el desarrollo, utilización y evolución de elementos de un sistema basado en SOA y el para el análisis de su valor para el negocio.

• Políticas y procedimientos

• Roles y responsabilidades

• Governance en tiempo de diseño

• Governance en tiempo de ejecución

Fuente: Integration and SOA: Concepts, Technologies and Best Practices. Beth Gold-Bernstein & Gary So.




Governance en Tiempo de Diseño

Conjunto de reglas y procedimientos que buscan alineamiento estratégico y consistencia en el diseño y despliegue de servicios

• Identificación de servicios

• Procesos de desarrollo (ciclo de vida completo)

• Diseño para medición y monitoreo

• Uso de estándares

• Acceso a la infraestructura

• Migración de componentes

• Evaluación y selección de tecnología

• Gestión de acuerdos de nivel de servicio (SLAs)


26



Governance en Tiempo de Ejecución

Reglas que buscan el cumplimiento de políticas

• Ejecución de servicios en maneras legales

• Seguridad

• Reemplazo de servicios

• Consistencia en interacción con la infraestructura

Colección de métricas

• Validación de cumplimiento de SLAs

— Identificación de problemas

• Métricas, colección de datos, reportes y recuperación

— Frecuencia de uso

— Identificación de excepciones a las reglas

— Identificación de áreas problemáticas

Manejo de problemas




Beneficios de SOA Governance

Mayor alineamiento con los objetivos del negocio

Mayor control sobre la creación, despliegue y utilización de servicios

Centralización de políticas y reglas

• Incrementa la posibilidad de automatización

Posibilidad de incluir mecanismos de cumplimiento con reglamentación gubernamental o industrial

• Sarbanes-Oxley, HIPAA, GLBA


27



Retos para la Implementación de SOA Governance

Parece “al revés”

• ¿Si SOA es acoplamiento débil y flexibilidad, por qué tanto control? ¡Automatización es clave! ¡ Registro es crucial!

Múltiples organizaciones

• ¿ Cómo crear governance para proveedores de servicio, proveedores de infraestructura y consumidores de servicios? ¿Qué pasa si las políticas están en conflicto?

Manejo de excepciones

• ¿Cómo registrar y manejar excepciones a las reglas que son necesarias?

Obligación de cumplimiento

• ¿Cómo hacer para asegurar que políticas y procedimientos se cumplan en tiempo de diseño y de ejecución? ¿Cuáles son los incentivos para el cumplimiento?




Todas estas preguntas sugieran la necesidad de experimentación contextual

Encontrar la Tecnología Adecuada para el Problema

Se necesita un verdadero entendimiento de lo que diferentes tecnologías pueden hacer en un dominio específico.

¿Cómo entender y mantenerse al tanto de la “sopa de letras”?

• ¿XML, SOAP, WSDL, UDDI, WS-Security?

¿Cómo determinar cuáles estándares y tecnologías implementar en situaciones específicas?

¿Cómo construir sistemas que aguanten cambios en estándares y los productos comerciales que los implementan?

¿Cómo determinar si tecnologías seleccionada van a satisfacer requerimientos de calidad de servicio? ¿Seguridad? ¿Disponibilidad? ¿Desempeño?

Pilares: Evaluación de Tecnología

28



T-CheckSM

Experimento con el objetivo de verificar el comportamiento de una tecnología en un contexto específico

Pasos

1. Formular hipótesis acerca de la tecnología

2. Examinar estas hipótesis contra criterios muy específicos mediante experimentación

Extremadamente eficiente

• La idea es implementar el experimento más simple posible que permita validar o contradecir la hipótesis

• El principio es que si el experimento falla en lo simple, va a fallar en lo complejo

Develop

Hypotheses

Develop

Criteria

Design and

Implement Solution

Evaluate Solution

Against Criteria

[Hypotheses Sustained] [Hypotheses Refuted]

Context




Ejemplo de T-Check: Contexto

Organización migrando un conjunto de aplicaciones y bases de datos de imágenes a una solución basada en Web Services

Objetivo: Establecer factibilidad de

• Adaptar sistemas actuales

• Mantener (o mejorar) tiempo de respuesta actual

• Transferir imágenes

• Tener un punto único de autenticación (single sign-on)


29



Ejemplo de T-Check: Hipótesis y Criterios de Evaluación

Hipótesis Criterios de Evaluación

75% o más de las aplicaciones pueden ser adaptadas a tecnologías de Web Services.

1. Hay librerías SOAP que pueden ser fácilmente integradas a 75% o más aplicaciones.

2. Sino, existe un mapeo claro entre tipos de datos nativos y tipos de datos de XML Schema que facilite la construcción e interpretación manual de mensajes SOAP.

El tiempo de respuesta no será degradado debido al uso de Web Services.

El tiempo de respuesta utilizando Web Services será del mismo orden de magnitud que los tiempos de respuesta actuales de aplicaciones representativas.

Imágenes pueden ser transmitidas como parte de mensajes SOAP.

Una imagen puede ser solicitada utilizando Web Services y visualizada en una aplicación cliente.

Es posible tener single sign-on utilizando Web Services.

Un usuario hace login una vez y pude obtener información de tres Web Services diferentes en tres máquinas diferentes.




El Desarrollo de Sistemas Basados en SOA Requiere un Enfoque Diferente

Desarrollo de Sistemas Tradicionales

Desarrollo de Sistemas Basados en SOA

Acoplamiento fuerte entre componentes del sistema

Acoplamiento débil entre consumidores y servicios

Semántica compartida explícitamente en tiempo de desarrollo

Tecnologías permiten compartir semántica sin mayor comunicación entre servicios y consumidores– en el futuro incluso en tiempo de ejecución

Conjunto conocido de usuarios y patrones de uso

Conjunto potencialmente desconocido de usuarios de servicios y patrones de uso

Componentes del sistema pertenecen a la misma organización

Componentes del sistema potencialmente pertenecen a múltiples organizaciones

Pilares: Cambio de Mentalidad

30



Menos Control

Requiere abandonar la idea de control completo—no es fácil

• La ventaja es agilidad del negocio

• Automatización de governance es clave

Hay que anticipar las objeciones y entender su validez

• Seguridad

• Desempeño

• Control

Mayores retos proviene de

• Puede no existir una única organización que sea dueña del sistema completo

• Servicios pueden potencialmente ser utilizados de manera desconocida por usuarios desconocidos

Se necesita educación y entrenamiento en esta nueva mentalidad.Pilares: Cambio de Mentalidad



Contenido

Introducción a SOA




Conclusiones

SMART

31



Reutilización en el Contexto SOA

Reutilización a un más alto nivel

• Reutilización de funcionalidad de negocio

• Encapsulación de detalles técnicos

Reutilización entre organizaciones

• Nuevo modelo de negocios

— Organizaciones pueden “vender” sus capacidades como servicios

• Funcionalidad puede ser adquirida en vez de desarrollada—potencial ahorro

Opción para mantener la inversión en sistemas existentes

• En muchos casos, componentes pueden ser expuestos como servicios, independiente del proveedor, plataforma y tecnología

SMART: Introducción



Aspectos Que Pueden Complicar la Migración

Comunidad de usuarios• Pequeña vs. grande

• Conocida vs. desconocida

Requerimientos tecnológicos del ambiente• Estándar vs. propietario

• Requerimientos de calidad de servicio

Características de los sistemas existentes• Pobre modularización de código (separation of concerns)

• Disponibilidad de herramientas

• Incompatibilidad entre arquitecturas (architectural mismatch)

• Incompatibilidad operacional (operational mismatch)

• Dependencias en productos comerciales


32



Service Migration and Reuse Technique (SMART)

SMART analiza la factibilidad de reutilizar componentes como la base para servicios mediante la búsqueda de respuestas a las siguientes preguntas:

• ¿Tiene sentido migrar el sistema a servicios?

• ¿Qué servicios son apropiados?

• ¿Qué componentes tienen la funcionalidad para satisfacer estos servicios?

• ¿Qué cambios hay que hacer para la migración?

• ¿Qué estrategias de migración son las más apropiadas?

• ¿Cuáles son las estimaciones preliminares de costo y riesgo?




Tres Elementos de SMART

ProcesoCuestionario para la

Migración a Servicios (SMIG)

Artefactos

Recoge información acerca de

• Objetivos y expectativas de la migración

• Servicios candidatos

• Sistemas /componentes a migrar

• Ambiente SOA

Analiza el gap entre el sistema existente y el ambiente SOA

Guía la discusión en las actividades iniciales de SMART

• Lista de Stakeholders

• Lista de Características

• Lista de Riesgos de Migración

• Mapeo entre Procesos de Negocio y Servicios

• Tabla de Servicios

• Tabla de Componentes

• Arquitectura de Alto Nivel del Sistema SOA

• Alternativas Servicio-Componentes

• Estrategia de Migración

SMART: Elementos

33



Actividades de Proceso de SMART

SMART: Actividades de Proceso

Establish

Migration

Context

Describe

Existing

Capability

Describe

Target SOA

Environment

Analyze the

Gap

Develop

Migration

Strategy

Migration

Feasible?No

Define

Candidate

Services

YesYes



Cuestionario para la Migración a Servicios (SMIG)

62 categorías de preguntas que buscan recolectar información acerca del contexto de migración, sistemas existentes, servicios candidatos y el ambiente SOA

SMART: SMIG

El objetivo es asegurar un cubrimiento amplio y consistente de los factores que influencian el costo, esfuerzo y riesgo de la migración a servicios.

Guía la recolección de información en el primer conjunto de actividades

Establish

Migration

Context

Describe

Existing

Capability

Describe

Target SOA

Environment

Analyze the

Gap

Develop

Migration

Strategy

Migration

Feasible?No

Define

Candidate

Services

YesYes

34



Artefactos SMART

Establecer Contexto de Migración

Definir Servicios

Candidatos

Describir Capacidad Existente

Describir Ambiente

SOA

Analizar el Gap

Desarrollar Estrategia de

Migración

Lista de Stakeholders

Crear Actualizar Actualizar Actualizar Actualizar Actualizar

Lista de Características


Lista de Riesgos de Migración


Mapeo Procesos de Negocio-Servicios


Tabla de Servicios Crear Actualizar Actualizar Actualizar Actualizar

Tabla de Componentes

Crear Actualizar Actualizar Actualizar

Arquitectura Alto Nivel Sistema SOA

Crear Actualizar Actualizar

Alternativas Servicio-

ComponentesCrear Actualizar

Estrategia de Migración

Crear

SMART: Artefactos



Contexto de Caso de Estudio: Sistema de Información de Laboratorios (LIS)

Paciente

Clínica(Ambulatorio)

Visita Médica

Hospital (Interno)

Admisión Hospital

Sistema de Información de Laboratorios

Orden Examen

Orden Examen

Cobros

Compañía de

Seguros

Datos Agregados para Información y

Análisis

Centro de Investigación /

Centro de Salud Pública

Resultados

Portal de Pacientes

Datos Paciente

Datos Paciente

Resultados

Resultados

Caso SMART: Contexto

35



Contexto de Caso de Estudio: Diagrama de Contexto de LIS

Información de laboratorio compartida entre varios sistemas

Necesidad de migrar a un ambiente SOA para incrementar la reutilización de tareas de laboratorio comunes

Preguntas clave

1. ¿Qué servicios deben ser creados?

2. ¿En qué orden?

3. ¿Es mejor reemplazar algunos componentes por componentes nuevos?

LIS

Sistemas Pacientes

Ambulatorios

Sistemas Pacientes Internos

Sistemas de Investigación y Salud Pública

Sistema En Línea de

Información de Pacientes

Sistemas de

Seguros

Alcance de la Aplicación de SMART

Caso SMART: Contexto



Establecer Contexto de Migración

• Entender el contexto de negocio y el contexto técnico de la migración

• Identificar stakeholders

• Entender el sistema existente y el ambiente SOA a un alto nivel

• Identificar un conjunto de servicios candidatos para migración

SMART: Establecer Contexto de Migración

Establish

Migration

Context

Describe

Existing

Capability

Describe

Target SOA

Environment

Analyze the

Gap

Develop Migration

Strategy

Migration

Feasible?No

Define

Candidate

Services

YesYes

36



LIS: Objetivos de la Migración

Mejorar el cuidado a pacientes

• Tener acceso a información de laboratorio desde cualquier sistema clínico en tiempo real (acceso actual es en su mayoría batch)

• Proveer acceso vía Web a información de laboratorio a pacientes a través del portal de pacientes

Reducir costos de TI

• Crear servicios comunes y reutilizables

• Reducir múltiples interfaces punto a punto entre sistemas

• Reducir costos de mantenimiento y actualización de sistemas

Caso SMART: Establecer Contexto de Migración



LIS: Descripción de Alto Nivel del Sistema

Sistema de Información de Laboratorios (LIS)

• 800,000 líneas de código

• Seis módulos principales—~2500 clases C++ y ~1500 clases Java

— El módulo de Catálogo de Exámenes de Laboratorio está escrito en Java pero realmente es un wrapper a un sistema escrito en COBOL

• Algunos componentes corren en Windows y otros en Linux OS

Interacción con sistemas externos es punto-a-punto a través de sockets dedicados

• Algunas transferencias de datos de hacen en modo batch en la noche (i.e., resultados de exámenes)

• No toda la información intercambiada utiliza la misma versión de HL7 (V3 vs. V2.X)

Dependencias en varios productos comerciales

• Oracle Database

• Weblogic Application Server


37



LIS: Ambiente SOA a un Alto Nivel

Evaluando varios productos Enterprise Service Bus (ESB) para el soporte de Web Services

• Un ESB es un producto de middleware que conecta y media toda la comunicación e interacción entre consumidores de servicios y servicios, usualmente basado en estándares

• Funcionalidad típica (Fuente: Wikipedia)

Categoría Funciones

Invocación Soporte para protocolos de transporte síncronos y asíncronos

Enrutamiento Manejo de direcciones, enrutamiento basado en contenido (itinerary routing)

Mediación Adaptadores, traducción de protocolos, transformación de datos

Orquestación de Procesos

Definición de procesos de negocio

Procesamiento de Eventos Complejos

Interpretación de eventos, correlación, pattern matching y publish/subscribe

Calidad de Servicio Seguridad (encripción y firmas), entrega garantizada y transacciones

Management Monitoreo, auditoría, logging, medición, consola de administración y monitoreo de actividades de negocio (BAM)




Establecer Contexto de Migración: Ejemplos del SMIG

Tema de Discusión

Preguntas Relacionadas Potenciales Riesgos de Migración

Objetivos y Expectativas

• ¿Cuál es la motivación de negocio y técnica del esfuerzo de migración?

• ¿Cuáles son los objetivos a corto y a largo plazo?

• No hay estrategia para la adopción de SOA

• Objetivos de la migración no son claros

Entendimiento de Alto Nivel del Sistema Existente

• ¿Cuál es la funcionalidad principal del sistema?

• ¿Cuál es la arquitectura de alto nivel del sistema?

• ¿Cómo es la interface de usuario del sistema?

• Conocimiento del sistema no está disponible

• Incompatibilidad con ambiente SOA• Complejidad de la interface de

usuario difícil de replicar en consumidores de servicios

Entendimiento de Alto Nivel del Ambiente SOA

• ¿Cuáles son los principales componentes del ambiente SOA?

• ¿Es este el primer proyecto de desarrollo de servicios en este ambiente?

• Ambiente SOA no ha sido identificado

• Conocimiento del ambiente SOA no está disponible en casa

Potenciales Consumidores de Servicios

• ¿Quiénes son los potenciales consumidores de servicios?

• Consumidores de servicios no han sido identificados


38



Propósito del SMIG

Identificación de riesgos potenciales de migración

Identificación de áreas que van a requerir esfuerzo o costo extra

Información de características que tienen que ser recolectadas de cada componente

Lista de Características

Se traduce en

Capturadas en




LIS: Lista de Características

Descripción

Servicios

Lenguaje

Dependencia Producto COTS

Tamaño

Número Versión y Release

Plataforma

Complejidad

Java

C++

Perl

Alta

Media

Baja

Muy Alta

Componente Wrapper

Características básicas pre-definidas

Características específicas al contexto del sistema

…


39



LIS: Lista Inicial de Riesgos de Migración

Descripción: Todos los consumidores de servicios no piensan moverse a la versión XML (v3) de HL7.Tipo: Técnico Impacto: Medio

Descripción: Algunos componentes están diseñados sólo para operaciones batch; se necesitan cambios fundamentales en estos componentes.Tipo: Proceso Impacto: Alto




Punto de Chequeo para Factibilidad de Migración

Se debe tomar la decisión de continuar o no con el proceso.

Las posibilidades son

• La migración es inicialmente factible.

• La migración tiene potencial pero requiere información adicional para poder tomar una decisión.

• La migración no es factible.

Describe

Existing

Capability

Describe

Target SOA

Environment

Analyze the

Gap

Develop

Migration

Strategy

Migration

Feasible?No

Define

Candidate

Services

YesYes

Establish Migration

Context

SMART: Punto de Chequeo para Factibilidad de Migración

40



Definir Servicios Candidatos

Seleccionar un número pequeño de servicios, usualmente 3-4, de la lista inicial de servicios candidatos.

Para los servicios seleccionados, el objetivo es definir completamente sus entradas y salidas.

SMART: Definir Servicios Candidatos

Define

Candidate

Services

Describe

Existing

Capability

Describe

Target SOA

Environment

Analyze the

Gap

Develop

Migration

Strategy

YesYes

Establish

Migration

Context

Migration

Feasible?No



LIS: Mapeo Inicial entre Procesos de Negocio y Servicios

Proceso de Negocios Servicios Candidatos

Buscar en Catálogo de Exámenes de Laboratorio

Obtener Catálogo Exámenes, Obtener Detalles Examen

Ordenar/Re-Ordenar Examen Obtener Catálogo Exámenes, Obtener InformaciónPaciente, Obtener Detalles Examen, Crear Orden Examen

Obtener Estado de Exámenes Obtener Información Paciente, Obtener Detalles Examen

Proveer Información de Cobros

Obtener Información Paciente, Obtener Detalles Examen

Revisar y Reportar Resultados de Exámenes

Obtener Información Paciente, Obtener Detalles Examen,Obtener Resultados Examen

Análisis de Tendencias Obtener Resultados Examen, Obtener ResultadosAgregados Examen

Caso SMART: Definir Servicios Candidatos

41



LIS: Tabla de Servicios Inicial

NOTA: Al final de este proceso iterativo, entradas y salidas deben tener un tipo de dato asociado.

Servicio Descripción TipoConsumidores

Potenciales

Obtener Resultados Examen

Obtiene resultados detallados de examen(es) para un paciente(s) o para todos los pacientes que se hicieron exámenes en un día específico en una sede específica

Negocio Sistemas Cínicos

Obtener Catálogo ExámenesObtiene el catálogo de exámenes disponibles en un laboratorio Negocio Sistemas Clínicos

Servicio Formato DatosFormatea mensaje de acuerdo con una versión específica de HL7 Infraestructura Servicios internos y

aplicaciones

… … … …

Servicio Entradas SalidasAtributos de Calidad

Claves…

Obtener Resultados Examen

ID Paciente (s)ID ExamenID SedeFecha

Detalles Resultados Examen Seguridad

Obtener Catálogo Exámenes Tipo(s) Examen Catálogo de Pruebas Configurabilidad

Servicio Formato Datos Datos, Versión HL7 Datos Formateados HL7 Interoperabilidad

… … … … …

Caso SMART: Definir Servicios Candidatos



Describir Capacidad Existente

SMART: Describir Capacidad Existente

Describe

Existing

Capability

Define

Candidate

Services

Describe

Target SOA

Environment

Analyze the

Gap

Develop

Migration

Strategy

Establish

Migration

Context

Migration

Feasible?No

Yes

Obtener información descriptiva acerca de los componentes a migrar

• Nombre, función, tamaño, plataforma, edad, versión, etc.

Cuestionar personal técnico acerca de

• Arquitectura y paradigmas de diseño

• Complejidad, acoplamiento, interfaces

• Calidad de documentación

• Dependencias entre componentes/productos

Recolectar información acerca de

• Calidad, madurez, problemas

• Historia de cambios

• Satisfacción de usuarios

42



Describir Capacidad Existente: Ejemplos del SMIG

Tema Preguntas Relacionadas Potenciales Riesgos

Características del Sistema Existente

• ¿Cuál es la historia de sistema? • ¿Es un prototipo, sistema en desarrollo, sistema

en pruebas, sistema en producción?• ¿Qué documentación del sistema hay?• ¿El sistema tiene interfaces con otros sistemas? • ¿Se perciben problemas de locking, persistencia

o de manejo de transacciones si el sistema es accedido por múltiples usuarios cuando se migre a servicios?

• Desarrollo en paralelo con esfuerzo de migración

• Documentación limitada del sistema• Interfaces a otros sistemas van a abrir

puertas para consumidores• Sistema mono-usuario puede presentar

problemas en un ambiente multi-usuario

Arquitectura del Sistema Existente

• ¿Qué perspectivas de la arquitectura existen? • ¿Cuáles son los módulos principales del sistema

y la dependencia entre ellos?• ¿El código de interface de usuario está separado

del código de lógica del negocio? • ¿Hay paradigmas de diseño implementados en

el sistema? • ¿Qué atributos de calidad están implementados

en la arquitectura actual del sistema?

• Falta de documentación de la arquitectura puede llevar a estimaciones incorrectas de complejidad

• Acoplamiento fuerte entre código de interface de usuario y lógica del negocio incrementa esfuerzo de migración

• Violaciones indocumentadas de patrones de diseño pueden causar problemas

• Atributos de calidad claves pueden no mantenerse en un ambiente de servicios

Características del Código

• ¿Cómo está la documentación del código?• ¿Se siguen estándares de programación?

• Prácticas de programación pobres incrementan el esfuerzo de migración

SMART: Describir Capacidad Existente



LIS: Tabla de Componentes

Componente Descripción Servicios Lenguaje PlataformaTamaño (SLOC)

CatalogoExamenes

Maneja el catálogo de todos los exámenes de laboratorio disponibles

Obtener Catalogo Exámenes, Obtener Detalles Examen, Crear Orden Examen

Java Linux 1,000

ProcesadorResultados

Contiene reglas del negocio para procesar resultados y comunicarlos a sistemas externos

Obtener Resultados Examen, Obtener Resultados Agregados Examen

C++, Java, Perl

Unix, Windows

XP8,000

Componente Complejidad VersiónNivel de

Documentación Ultimo Release

CatalogoExamenes Media 5.6 Alto 02/10/2005

ProcesadorResultados Muy Alta 8.2 Medio 06/01/2005

ComponenteComponente

WrapperDependencia Productos COTS

Llamados Directos UI

Políticas y Reglas en Código

CatalogoExamenes Si Librerías de terceros, HL7 v2.3 No No

ProcesadorResultados NoOracle Database, Weblogic Application Server

Si Si

Nuevo

Caso SMART: Describir Capacidad Existente

43



LIS: Perspectiva Modular

Procesamiento de Ordenes

Catálogo de Exámenes de Laboratorio

Archivo(Exámenes,

Ordenes)

Gestión de Exámenes y

Muestras

Reporte y Procesamiento de Resultados de Exámenes

Procesamiento de Cobros

SistemasPacientes

Ambulatorios

Sistemas Pacientes

Interno


Sistema En Línea de

Información de Pacientes

Sistemas de

Seguro

Sistema de Información de Laboratorios

C++ Java Implementación de interface diferente para cada sistema

Diferentes versiones de HL7 (no todas basadas

en XML)

Realizado a diario en modo batch

Comunicación con sistemas externos a través de sockets

dedicados




LIS: Riesgos de Migración Adicionales

Descripción: Todos los consumidores de servicios no piensan moverse a la versión XML (v3) de HL7.

Descripción: Algunos componentes están diseñados solo para operaciones batch …

Descripción: Algunos componentes hacen llamados directos entre código de lógica del negocio y código de interface de usuario.Tipo: Técnico Impacto: Medio

Descripción: Diferentes políticas de filtrado son aplicadas al mismo conjunto de datos dependiendo del sistema externo. Tipo: Organizacional, Políticas Impacto: Alto

Nuevo

Nuevo


44



Describir Ambiente SOA

Describe

Target SOA

Environment

Define

Candidate

Services

Describe

Existing

Capability

Analyze the

Gap

Develop

Migration

Strategy

Establish Migration

Context

Migration

Feasible?No

Yes

• Identificar el impacto de tecnologías, estándares y guías específicas para la implementación de servicios

• Determinar el estado del ambiente SOA

• Identificar cómo los servicios deben interactuar con el ambiente SOA

• Determinar expectativas de calidad de servicio y del ambiente de ejecución para servicios

SMART: Describir Ambiente SOA



Describir Ambiente SOA: Ejemplos del SMIG

Tema de Discusión

Preguntas Relacionadas Potenciales Riesgos de Migración

Características del Ambiente SOA

• ¿Cuál es el estado del ambiente SOA?• ¿Cuáles son los principales componentes de la

infraestructura SOA ?• ¿Existen servicios de infraestructura en el

ambiente SOA (i.e., comunicaciones, descubrimiento, seguridad, transformación de datos)?

• ¿Cuál es el modelo de comunicaciones? • ¿Qué restricciones coloca la infraestructura sobre

servicios? • ¿Hay algún comportamiento en el sistema que sea

incompatible con el ambiente SOA?• ¿Dónde van a correr los servicios?

• Ambiente SOA indefinido• Redundancia/conflictos entre servicios

de infraestructura y código existente• Falta de herramientas para el apoyo de

la migración• Cumplir con las restricciones de la

infraestructura requiere esfuerzo adicional

• Incompatibilidad entre arquitectura del sistema existente y el ambiente SOA

• No se ha pensado en el despliegue y ejecución de servicios

Soporte • ¿Se deben proveer scripts de pruebas para los servicios?

• ¿Cómo se va a manejar el reporte de problemas por parte de consumidores?

• ¿Cómo se van a reportar a consumidores los cambios de interface o tiempos de indisponibilidad debido a problemas o actualizaciones de servicios?

• Estimación incorrecta del esfuerzo para soportar consumidores de servicios

• Desconocimiento de los requerimientos de soporte a servicios

SMART: Describir Ambiente SOA

45



LIS: Restricciones del Ambiente SOA

Servicios necesitan soportar diferentes versiones del estándar HL7.

• Portal de Pacientes va a utilizar la nueva versión (v3) de HL7 basada en XML.

• Sistemas Clínicos (Ambulatorio, Interno) piensan moverse a HL7 v3 en el corto plazo mientras que los demás sistemas no tienen planes para ello.

Servicios necesitan tener en cuenta las diferentes políticas para el manejo del mismo conjunto de datos.

• Datos de pacientes para organizaciones de investigación deben ser completamente anónimos.

• Datos de pacientes para sistemas clínicos deben estar ser completamente identificables.

Caso SMART: Describir Ambiente SOA



LIS: Arquitectura de Alto Nivel del Sistema Basado en SOA


Servicio Crear Orden

Examen

Servicio de

Seguridad

Servicio Obtener

Resultados Examen

Servicio Obtener

Resultados Agregados

Examen

Enterprise Service Bus (ESB)

Procesamiento de Ordenes

Reporte y Procesamiento de

Resultados Exámenes

Sistemas de Pacientes Internos

Sistemas de Pacientes

Ambulatorios

Sistemas de Seguros

Servicio de

Formato de Datos

Portal de Pacientes

Policy Manager

…

Caso SMART: Describir Ambiente SOA

Servicio de Transferencia

de Datos

46



Analizar el Gap

• Definir el esfuerzo, riesgo y costo de habilitar componentes existentes como servicios, dados los requerimientos de servicios y las características del ambiente SOA

• Determinar la necesidad de análisis adicionalesAnalyze the

Gap

Define

Candidate

Services

Describe

Existing

Capability

Describe

Target SOA

Environment

Develop

Migration

Strategy

Establish

Migration

Context

Migration

Feasible?No

Yes

SMART: Analizar el Gap



LIS: Tabla de Componentes Actualizada

Componente … …Método

de Migración

Resumen de Cambios RequeridosEsfuerzo (Persona/Semana)

CostoNivel de

Dificultad

Nivel de

Riesgo

CatalogoExamenes

Wrapping 1. Crear una interface con los métodos necesarios para buscar en el catálogo con los múltiples criterios de búsqueda definidos.

2. Reutilizar la lógica presente en CatalogoExamenes mediante el llamado a los métodos existentes.

3 Bajo Bajo

ProcesadorResultados

Extracción + Nuevo

1. Crear una interface con los métodos para obtener resultados de exámenes con los múltiples criterios de búsqueda definidos.

2. Reutilizar las reglas de negocio en ProcesadorResultados, adicionando modificaciones para acomodarse a la nueva interface de servicio.

3. Crear código para los métodos que no se encuentran en ProcesadorResultados.

4. Adicionar código para validación de entradas.

5. Adicionar elementos a la estructura de datos ResultadosExamen para guardar información requerida por la nueva interface de servicio.

6. …

15 Medio Medio

Caso SMART: Analizar el Gap

47



Desarrollar Estrategia de Migración

Desarrollar una o más estrategias de migración que pueden incluir

• Orden en el cual crear servicios

• Guías para la creación de servicios

• Arquitecturas de referencia

• Fuentes del código de servicios—sistemas existentes, COTS, servicios externos, etc.

• Mecanismo—wrapping, reescribir, extracción, nuevo

• Caminos específicos para la migración—e.g., wrapping primero y reescribir luego)

• Necesidades de entrenamiento, evaluación de tecnología, investigación de mercados, etc.

Develop

Migration

Strategy

Define Candidate

Services

Describe Existing

Capability

Describe Target SOA

Environment

Analyze the

Gap

Establish

Migration

Context

Migration

Feasible?No

Yes

SMART: Desarrollar Estrategia de Migración



Proceso Revisitado …

Información colectada durante Establecer Contexto de Migración, Definir

Servicios Candidatos, Describir Capacidades Existentes y Describir

Ambiente SOA

Riesgos de Migración

Genera

Mitigados en

Provee la base para

Colocan restricciones sobre

Estimaciones de Costo y Esfuerzo

Estrategia de Migración

SMART: Desarrollar Estrategia de Migración

48



Estrategia de Migración para LIS 1

1. Reunión de Trabajo con Stakeholders

• Compartir planes de migración para LIS

• Llegar a un acuerdo sobre los tiempo de release de servicios y la suspensión de interfaces actuales

• Obtener necesidades de consumidores de servicios

• Discutir soporte a ser brindado para la utilización de servicios LIS

2. Selección Inicial de un ESB

• Hacer una selección preliminar basada en resultados de evaluación existentes

• Trabajar con el proveedor para obtener una licencia de evaluación de corto plazo

• Implementar la infraestructura SOA inicial

Caso SMART: Desarrollar Estrategia de Migración




3. Implementar el servicio Obtener Catálogo Exámenes como un proyecto piloto

• Servicio que puede ser fácilmente expuesto a sistemas externos para que puedan empezar a hacer pruebas

• Va a suministrar datos para ajustar las estimaciones

• También va a determinar si el “doble-wrapper” va a presentar problemas de desempeño

4. Validar Requerimientos de Seguridad y Privacidad

• T-Checks pueden determinar si los requerimientos de seguridad y privacidad son satisfechos por el ESB seleccionado

• Si requerimientos no son satisfechos, T-Checks pueden proveer información para determinar si es necesario adicionar elementos a la infraestructura


49




5. Entender el Policy Manager del ESB

• T-Checks pueden utilizar las políticas de información de LIS como contexto para la experimentación

• Si requerimientos no son satisfechos, T-Checks pueden proveer información para determinar si es necesario adicionar elementos a la infraestructura

6. Evaluar Infraestructura SOA Inicial

• Identificar requerimientos que no son satisfechos por la infraestructura, restricciones sobre servicios, problemas con calidad de servicios, incompatibilidades con código existente

• Podría incluso determinarse que la selección inicial de ESB no es apropiada





7. Implementar Infraestructura SOA Final

• Definir responsabilidades de los componentes de la infraestructura

• Definir e implementar SLAs y mecanismos para cumplimiento en tiempo de ejecución

• Identificar áreas en las cuáles se necesita soporte del proveedor del ESB

8. Documentar Guías de Implementación

• Diseño de interfaces de servicio

• Listas de chequeo para desarrollo

• Arquitectura de referencia para servicios

• Procedimientos de prueba y despliegue

• …

Service Interface Layer

Performs transformations between messages from

service consumers and LIS code

LIS Code Layer

Contains existing LIS code plus new code that had to be

developed to meet service requirements

Data Access Layer

Contains code to access internal and

external data sources

Policy Layer

Contains code to

access Policy

Manager


50




9. Ajustar Estimaciones y Crear Plan de Migración

• Finalizar entradas/salidas de servicios basados en los requerimientos de consumidores

• Ajustar estimaciones de esfuerzo para la migración que incluyan requerimientos de la infraestructura SOA y cualquier cambio en entradas/salidas

• Priorizar servicios candidatos

• Definir necesidades de entrenamiento y proveer el entrenamiento

10. Implementar Plan de Migración

• Asegurarse que haya retroalimentación entre iteraciones—incorporar lecciones aprendidas y evaluar cambios en tecnología




En Resumen …

SMART analiza la factibilidad de reutilizar componentes como la base para servicios mediante la búsqueda de respuestas a las siguientes preguntas:

• ¿Tiene sentido migrar el sistema a servicios?

• ¿Qué servicios son apropiados?

• ¿Qué componentes tienen la funcionalidad para satisfacer estos servicios?

• ¿Qué cambios hay que hacer para la migración?

• ¿Qué estrategias de migración son las más apropiadas?

• ¿Cuáles son las estimaciones preliminares de costo y riesgo?

SMART

51



Contenido

Introducción a SOA




Conclusiones

Implicaciones Actividades de Desarrollo



Implicaciones Generales

Procesos deben reflejar el enfoque estratégico

Procesos deben ser iterativos

• Iteraciones cortas para poder responder a las necesidades del negocio

Procesos de governance deben aplicar al ciclo de vida completo

• Énfasis en áreas problemáticas

• Automatización en lo mayor posible

Diferenciación entre integración con servicios internos e integración con servicios externos

Diferenciación entre procesos para proveedores de servicios, consumidores de servicios y proveedores de infraestructura

Evaluación de tecnología se convierte en parte integralImplicaciones Actividades de Desarrollo

52



Algunas Implicaciones sobre Actividades de Requerimientos

Requiere un enfoque basado en gerencia de procesos de negocio (BPM)

Debe manejar un mayor número de stakeholders

Primer paso es revisar el inventario de procesos y el inventario de servicios

• Negociación y adaptación con el fin de incrementar reutilización

• Puede causar un “refactoring” de servicios

• Un “registry” de alta calidad facilita el proceso

En el caso de proveedores de servicios, se requiere trabajar con requerimientos potenciales

• Tal como lo hacen los vendedores de productos comerciales




Algunas Implicaciones sobre Actividades de Arquitectura y Diseño

Decisiones sobre responsabilidades de cada componente del sistema—consumidores, servicios e infraestructura

Constante evaluación de tecnología

Evaluación de calidad de servicio (QoS) esperada

• Tradeoff analysis

• Experimentación contextual

• Implicaciones debidas a consumidores o servicios externos

Decisiones deben promover la reutilización


53



Algunas Implicaciones sobre Actividades de Implementación

El ambiente de desarrollo debe ser similar/igual al ambiente de producción—como en cualquier sistema distribuido

• En algunos casos puede ser necesaria la simulación del ambiente de producción

El estado emergente de las tecnologías para implementación de SOA causa inestabilidad en los procesos de implementación

Requiere el establecimiento de procesos para implementación de interfaces de servicio y de componentes de la infraestructura

• Los procesos tradicionales aplican a la implementación de servicios.




Algunas Implicaciones sobre Actividades de Pruebas

La prueba completa de un sistema consumidor de servicios requiere que todos los servicios (o instancias de prueba) estén en línea

• Desde el punto de vista del consumidor, un servicio es una “caja negra”

Se requiere un mayor y más diverso manejo de excepciones

• Por ejemplo, qué pasa si el servicio no está disponible?

Pruebas de regresión deben evaluar contra requerimientos y contra acuerdo de nivel de servicio (SLAs)


54



Algunas Implicaciones Sobre Actividades de Mantenimiento

El análisis del impacto de cambios afecta a un mayor número de usuarios

• Internos y externos

• Usuarios del servicio y usuarios del sistema que implementa el servicio

La gestión de configuraciones se vuelve más complicada

• Qué artefactos se colocan bajo gestión de configuraciones? Consumidores? Servicios? Infraestructura?

Mayor coordinación de ciclos de “release”

• Entre servicios y consumidores

• Entre infraestructura y servicios/consumidores




En Resumen …

Las actividades del proceso de desarrollo de sistemas orientados a servicios se ven afectadas por

• Enfoque estratégico necesario para adopción de SOA

• Distribución de componentes

• Nivel de control sobre componentes

Cualquier actividad de procesos que tiene como objetivo controlar o guiar el desarrollo en ambientes SOA debe convertirse en parte de SOA

Governance.


55



Contenido

Introducción a SOA




Conclusiones

Conclusiones



Conclusiones 1

SOA ofrece el potencial para

• Aprovechar inversiones en sistemas existentes mediante interfaces modernas a capacidades existentes

• Exponer funcionalidad a un mayor número de usuarios

Esto es posible mediante

• Construcción de consumidores a partir de servicios existentes

• Independencia de plataforma y lenguaje

• Acoplamiento débil entre consumidores de servicios y servicios

• Fácil actualización de servicios debido a la separación de la interface de servicio de la implementación del servicio

Conclusiones

56



Conclusiones 2

El desarrollo exitoso de sistemas basados en SOA requiere

• Alineamiento estratégico

• SOA governance

• Evaluación contextual de tecnología

• Cambio de mentalidad

Reutilización de servicios es más complejo que la reutilización de módulos o componentes

• El diseño de servicios reutilizables requiere un enfoque, habilidades y mentalidad diferente

• La comunidad de stakeholders es más grande porque los servicios son típicamente reutilizados a nivel organizacional o departamental

Conclusiones



Conclusiones 3

Reutilización en el mundo de servicios requiere

• Identificación de requerimientos del ambiente SOA en el cual van a operar los servicios

• Clara distinción entre las necesidades que pueden ser satisfechas por sistemas existentes y aquellas que no pueden ser satisfechas

• Análisis sistemático de los cambios necesarios para operar dentro del ambiente SOA

Un método como SMART permite analizar la posibilidad de reutilizar componentes existentes como la base para la implementación de servicios.

Conclusiones

57



Bibliografía

SMART: The Service Migration and Reuse Technique

• http://www.sei.cmu.edu/publications/documents/05.reports/05tn029.html

• SMART: Analyzing the Reuse Potential of Legacy Components in a Service-Oriented Architecture Environment. Proceedings of the 2007 AIAA Infotech@Aerospace Conference.

T-Check

• Proceso: http://www.sei.cmu.edu/publications/documents/05.reports/05tn025.html

• Aplicaciones:

— Web Services: http://www.sei.cmu.edu/publications/documents/06.reports/06tn021.html

— OWL-S (OWL Web Ontology Language for Services): http://www.sei.cmu.edu/publications/documents/06.reports/06tn018.html

— MDA (Model-Driven Architecture): http://www.sei.cmu.edu/publications/documents/05.reports/05tn022.html

Bibliografía

Education

SEPGLA 2007 Migración a Ambientes de Arquitectura Orientada a Servicios (SOA) Grace Lewis