Presentaci

1
Arquitectura SOA Una experiencia práctica en
Telefónica
Luis Arévalo Muñoz Gerencia de Arquitectura Sistem
as de Información Corporativos Telefónica,
S.A. Abril 2007
2
Algunas cifras sobre Telefónica hoy

• Más de 203 millones de clientes
• Tercer operador mundial por número de clientes
  después de China Mobile y China Telecom
• Más de 220.000 empleados
• Operando en 19 países
• Equilibrio Geográfico
• 43 España
• 33 LATAM
• 24 Europa
• Primer Operador integrado de telecomunicaciones
  en Europa y LATAM (capitalización)
• Distribución equilibrada del negocio
• 44 Fija
• 56 Móviles

3
Índice

• 00 Introducción Evolución hacia SOA
• 01 La etapa inicial Conectores y Multicanalidad
• 02 El crecimiento Integración de Aplicaciones
• 03 La madurez repositorio de servicios,
  arquitectura de desarrollo y aplicaciones
  compuestas
• 04 El futuro próximos pasos

4
La evolución hacia una Arquitectura SOA en
Telefónica
SOA
Repositorio y Arquitectura de Desarrollo
Integración de Aplicaciones
Conectores y Multicanalidad
5
Índice

• 00 Introducción Evolución hacia SOA
• 01 La etapa inicial Conectores y Multicanalidad
• 02 El crecimiento Integración de Aplicaciones
• 03 La madurez repositorio de servicios,
  arquitectura de desarrollo y aplicaciones
  compuestas
• 04 El futuro próximos pasos

6
El desarrollo de un Conector de Arquitectura
resuelve el acceso a la lógica de negocio de las
aplicaciones

• En 1997, la mayor parte de los sistemas de
  información de Telefónica de España está sobre
  plataforma Mainframe

7
El Conector de Arquitectura NA de Telefónica
permite el acceso multicanal y la independencia
de middleware
Aplicación Web/Java
WAS
Servlet/Applet Java
NA
Cliente Pesado
Windows
.NET
NA
Aplicación Midrange
UNIX
App C
NA
Oracle
8
API del Conector NA de acceso a Servicios

• Intuitivo con curva de aprendizaje mínima
• Multilenguaje (VB, C, C, Java,..)
• Single method Object Oriented
• Tratamiento unificado de excepciones

// ejemplo API programación Java try
NAServicio serv1 new
NAServicio(C8F0001") serv1.setCampo("
MSI-COD-CLI-CD ",
"HJ3XX023") serv1.ejecutar() System.out.println
(Cuenta serv1.getCampo("MSO-COD-CTA-CD
",1)) serv1.unload() catch (NAWRException
exc) System.out.println("Excepción "
exc)
Creación de un objeto de Arquitectura que toma
como propiedad el nombre lógico del Servicio de
Negocio a invocar
Asignar valores a los campos de entrada del
Servicio
Ejecutar el servicio
Leer los campos de salida devueltos por el
Servicio
Tratamiento unificado de errores basado en
excepciones
9
Para potenciar el uso de Conectores y Servicios
NA se establece un primer modelo de gobierno...

• Normativa de construcción de Servicios NA en
  host
• Componentes Cobol/CICS/DB2 con Commarea
• Cabecera estándar para uso de Arquitectura y
  tratamiento de errores

• Consultoría de Arquitectura y Tecnología
• Revisión de la arquitectura de los proyectos de
  desarrollo
• Recomendación de utilizar Servicios NA
• Conectores NA como único medio de acceso a
  mainframe

• Facilidades para entorno de Producción
• Logs y trazas en mainframe y entorno cliente
• Ayudas a la determinación de problemas

10
...lográndose un uso masivo del Conector NA (año
2000)
Aplicación Web/Java
WAS
Servlet/Applet Java
NA
Interfaz única de acceso a Servicios NA de
negocio en entorno mainframe
Cliente Pesado
Windows
Utilización de API desde Visual Basic (cliente
pesado) y desde servlets de Java (cliente ligero)
.NET
NA
Aplicación Midrange
UNIX
App C
NA
Oracle
Las aplicaciones desarrollan su lógica de negocio
en Servicios NA mainframe
Alto volumen transaccional (más de 4 millones
tran/día)
11
Índice

• 00 Introducción Evolución hacia SOA
• 01 La etapa inicial Conectores y Multicanalidad
• 02 El crecimiento Integración de Aplicaciones
• 03 La madurez repositorio de servicios,
  arquitectura de desarrollo y aplicaciones
  compuestas
• 04 El futuro próximos pasos

12
Encaminador un primer paso hacia la
integración de aplicaciones

• El Encaminador (desarrollado en 1996) enruta
  mensajes MQSeries para comunicación asíncrona
  entre diferentes aplicaciones y tecnologías

Aplicación
Aplicación
Encaminador OS/390
MQSeries
MQSeries
Servicio - Destino
Aplicación
Aplicación
MQSeries
MQSeries
Hub de mensajes MQSeries sobre OS/390 basado en
tabla Servicio-destino
Simplifica conectividad de N aplicaciones (N
conexiones MQ en lugar de N(N-1)
Uso inicial 100.000 mensajes/día
13
El uso combinado de Conectores NA y Encaminador
proporcionan una Arquitectura de Integración de
Aplicaciones que se potencia con la
generalización de los conectores NA y el
desarrollo de Servicios en múltiples
plataformas...
Extensión del API de NA para envío y recepción de
mensajes asíncronos
Conectores NA
Soporte de múltiples lenguajes
Soporte de múltiples middlewares
Soporte de múltiples plataformas
14
...con lo que se consigue una Arquitectura de
Integración completa...

• Arquitectura NA para
• Envío de mensajes asíncronos
• Invocación de servicios síncronos

Nodo Servidor
Encaminamiento de mensajes entre aplicaciones
NA Ejecutar Servicio
NA Enviar Mensaje
Arquitectura sobre Message Broker comercial
EAI(opcional)
ENCAMINADOR
Nodo Servidor
Sistema Externo
Nodo Servidor
NA Recibir Mensaje
NA Servicio
Web Service
WSDL

• Arquitectura NA para
• Recepción de mensajes asíncronos

Invocación desde Web Services externos de
Servicio de Negocio NA-ASSCC

• Arquitectura NA para
• Ejecución de Servicios

15
...incluyendo herramientas de prueba unitaria y
de integración (NATester)
Prueba unitaria de Servicios de Negocio sin
requerir aplicación cliente

• Almacenamiento y ejecución de casos de prueba
  para
• Pruebas de Lógica de Presentación sin codificar
  Servicios de Negocio
• Pruebas de integración de aplicaciones sin
  requerir aplicación destino

16
Índice

• 00 Introducción Evolución hacia SOA
• 01 La etapa inicial Conectores y Multicanalidad
• 02 El crecimiento Integración de Aplicaciones
• 03 La madurez repositorio de servicios,
  arquitectura de desarrollo y aplicaciones
  compuestas
• 04 El futuro próximos pasos

17
El uso intensivo de Servicios requiere un modelo
de gobierno y herramientas adecuados, por lo que
se crea un Grupo de Integración de Aplicaciones

• El Grupo de Integración de Aplicaciones nace con
  el objetivo principal de estandarizar la creación
  de Servicios e incrementar su reutilización
  mediante dos acciones principales

Adaptar la Metodología para el desarrollo de
aplicaciones orientadas a servicios
Implementar un Repositorio de Servicios único y
homogéneo que permita compartir entre las
aplicaciones toda la información relativa a los
Servicios
18
La Metodología de desarrollo se orienta a la
creación y reutilización de Servicios

• Asegurar el uso correcto de la Arquitectura
• Revisar los Elementos de Información necesarios
  para la construcción
• Revisión de interfaces de Servicios

• Revisión de puntos de integración
• Determinar los nuevos Elementos de información
  necesarios
• Revisión de interfaces de Servicios

• Planificar la actividad del grupo de integración
  en el proyecto
• Determinar los sistemas involucrados en el
  proyecto
• Registrar puntos y escenarios de integración
• Asignar un consultor de integración al proyecto

• Revisión de puntos de integración
• Servicios a crear reutilizar
• Revisión del Modelo de Datos

19
El Repositorio de Servicios NA (desarrollo propio
de Telefónica) es la pieza clave para el
desarrollo de aplicaciones orientadas a servicios
y para fomentar la reutilización de Servicios
El Repositorio es utilizado por toda la
organización de IT y contiene toda la información
del diseño técnico de una aplicación y su
documentación
Es posible cargar los Elementos de Información a
partir del modelo físico de datos
Modelo Físico de Datos
Repositorio ASSCC

• Elementos de Información Normalizados

Elementos de Información
COD-CLI-CD
Cliente
Almacenamiento de toda la información en Base de
Datos relacional
Pedido
Componentes lógicos de Aplicación y sus relaciones
Producto
Relaciones entre Componentes
Metamodelo de datos extensible permite definir
cualquier estructura de componentes
Documentación asociada a Componentes
Componentes de Aplicación
Servicio
Análisis de Impacto de cambios
Interfaz
Interfaz
Información para Gestión de Configuración
20
Ejemplo de componentes definidos en Repositorio
de Servicios de Telefónica de España
Función de Negocio adaptador de servicios de
negocio
Componente de Integración de Servicios hace
llamadas a uno o más servicios de negocio. Se
ejecuta en OS/390
Servicio de Negocio Compuesto Java Agrupa varios
Servicios de Negocio Java
Servicio de Negocio Lógica de negocio de la
Aplicación. Se ejecuta en OS/390
Servicio de Negocio Java Lógica de negocio de la
Aplicación.
Message definición de la interfaz de un servicio
Documento en formato word, pdf, , asociado a
cada componente, describe su funcionalidad,
características, formatos, etc. Elementos de
Información elementos pertenecientes al modelo
de datos y de la interfaz de los Servicios
21
El Repositorio de Servicios incluye una potente
herramienta de administración y visualización de
la información

• Funcionalidad de la herramienta
• Diseño lógico de los componentes de la aplicación
• Propiedades parametrizables de componentes
• Visualización de árbol jerárquico de componentes
• Menús contextuales
• Definición y mantenimiento de Elementos de
  Información
• Búsqueda de componentes
• Análisis de impacto
• Generación de documentación de la aplicación
• Informes preconstruidos
• Generación de descriptores XML y WSDL de Servicios

22
Utilización del Repositorio de Servicios y de la
Arquitectura NA en Telefónica de España
gt 20 Millones de ejecuciones de servicios al día
gt 4,5 Millones de mensajes asíncronos al día
23
La Arquitectura permite la exportación de
Servicios NA como Web Services, lo que garantiza
su interoperación con otros enfoques SOA
(aplicaciones de mercado, terceras empresas, etc.)
Generación automática del WSDL asociado a los
Servicios
Consumo de Web Services externos
Repositorio
Descarga WSDL
Plataforma Servicios WS
Cliente NA
Servicio WS
Config MW-WS
24
La Arquitectura se complementa con una
Arquitectura de Desarrollo (DIANA) que permite el
diseño de lógica de presentación y su
almacenamiento en el mismo Repositorio de
Servicios...
HDTC (Herramienta de Diseño Técnico y
Construcción)

• Diseño gráfico de ventanas
• Controles Visuales de Negocio, facilitados por
  ASSCC, asociados a Elementos de Información
• Validaciones simples a nivel de Control Visual
• Validaciones cruzadas entre controles
• Externalización de literales multidioma

Ventanas
xxxxx
Paleta Extensible de Controles
Elementos de Información
Controles (botones, listas, etc.)
Editor de Ventanas
COD-CLI-CD
xxxxx
Repositorio
Validaciones

• Diseño de flujo de ventanas
• Flujo de Navegación entre ventanas.
• Asociaciones de eventos de controles con
  Ejecución de Servicios
• Actualización automática de controles de negocio
  basado en Contexto manejado por Arquitectura

Navegación
Ejec. de Servicios
25
...y con herramientas de generación de código a
partir del Repositorio
HDTC (Herramienta de Diseño Técnico y
Construcción)
Mecanismo de generación extensible/adaptable (XML
XSLT)
Repositorio ASSCC
ltXMLgt
XSLT
ltXSLgt
Componentes de la Aplicación generados
Genéración de elementos de soporte del motor
de Arquitectura (parámetros, literales
multiidioma, descriptores XML y WSDL)
Generación completa de Lógica de
Presentación para distintos canales (Html, Java)
Java
Cobol
XML
Parámetros
Genéración de código de aplicación y
documentación asociada
WS Java
Nodo Servidor
Nodo Intermedio
WS Html
Generación de esqueletos de Lógica de Negocio
y Datos
26
HERA un ejemplo de aplicación compuesta basada en
la reutilización de servicios de diferentes
aplicaciones

• Apertura de reclamaciones de pedidos o facturas
• Consulta de reclamaciones
• Actuaciones en domicilio

• Datos básicos de cliente
• Direcciones
• Interlocutor del cliente
• Programas de fidelidad
• Venta cruzada
• Self-service para clientes
• Indicadores de consumo
• Parque instalado
• Alarmas y mensajes

• Integración con CTI
• Gestión de contactos
• Tipificación de contactos
• Consulta de últimos contactos
• CTI Integration
• Anexar información a contacto

• Facturas
• Duplicados de facturas
• Avisos de pago
• Consulta de pagos
• Conexiones y desconexiones

Estrategia SOA en HERA

• Consulta de averías
• Gestión de averías
• Actuaciones sobre averías

• Alarmas
• Boletines pendientes
• Tareas pendientes
• Agenda
• Mensajes

• Pedidos pendientes
• Histórico de pedidos
• Actuaciones
• Incidencias en pedidos

27
que utiliza los elementos de Arquitectura NA

• La estrategia de desarrollo está basada en el uso
  de la Arquitectura NA

• Prototipado de interfaz de usuario en DIANA
• El usuario valida la interfaz GUI mediante un
  prototipo y, al mismo tiempo, se identifican los
  Servicios de integración necesarios.
• Los consultores de integración trabajan muy cerca
  de los desarrolladores para definir adecuadamente
  las integraciones precisas.

• Se definen los Servicios de negocio necesarios
  
• El prototipo ayuda en la identificación de los
  servicios requeridos.
• Se identifica alto nivel las aplicaciones a las
  que pertenecen los Servicios..
• Se definen los nuevos Servicios y se reutilizan
  los existentes.

Estrategia de desarrollo en HERA

• Beneficios para el negocio
• Estandarización del front-end de usuario para
  todas las aplicaciones (usabilidad)
• Informacion 360º del cliente
• Reducción de TMO
• Beneficios para IT
• 70 Servicios reutilizados
• Incremento de productividad de desarrollo
• Disminución de incidencias en pruebas

Arquitectura NA

• Desarrollo separado de la lógica de presentación
  y de la lógica de negocio.
• Se diseña el front-end de usuario en DIANA, que
  genera el código. Las pruebas unitarias se
  realizan a través de NATester contra casos de
  prueba.
• Se construyen los Servicios necesarios,
  probándose con NATester.

28
Índice

• 00 Introducción Evolución hacia SOA
• 01 La etapa inicial Conectores y Multicanalidad
• 02 El crecimiento Integración de Aplicaciones
• 03 La madurez repositorio de servicios,
  arquitectura de desarrollo y aplicaciones
  compuestas
• 04 El futuro próximos pasos

29
La evolución del Repositorio de Servicios se
centra fundamentalmente en las facilidades de
integración con otros Repositorio (UDDI, SAP,
etc.) y la creación de un plug-in de Eclipse

• Integración con otros Repositorios (UDDI, SAP...)
• Integración con herramientas de orquestación y
  herramientas BPM
• Búsquedas mejoradas

• Mejorar la documentación de servicios
• Clasificación y taxonomías de servicios
• Plug-in para Eclipse
• Nuevos componentes para representar BPEL y flujos
• Importacion de WSDL

• Generación de información sobre servicios en
  ejecución

• Mejoras del Ciclo de vida de los servicios.
• Notificaciones y alertas por e-mail

• Integración con CMDB

30
La Arquitectura está preparada para utilizar SOA
basada en Orquestación de servicios y BAM

• Prueba de concepto exitosa (2005)

• Proyecto de Innovación SOA Orquestación de
  Procesos de Negocio y Servicios y Monitorización
  de Actividad del Negocio
• Actividades
• Análisis de estándares de orquestación BPML,
  BPEL y XPDL.
• Análidid de herramientas comerciales y open
  source
• Estado del arte de workflow humano y herramientas
  de orquestación
• Adaptación de procesos de negocio de Adonis a
  BPEL.
• Proyecto piloto de herramientas de orquestación
  de Oracle, Software AG y Twister (open source)
• Prueba de concepto de monitorización de
  actividades con la herramienta de Oracle

31
Muchas gracias!
Para cualquier información adicional contactar
con Luis Arévalo E-mail luis.arevalomunoz_at_telefo
nica.es
32
(No Transcript)