Un estudio de caso de SOA: Agilidad en la práctica por Alcedo Coenen (barra lateral por el Dr. Chris Harding ) 

Publicado: 23 de octubre de 2006 (Revista de SOA II Edición: noviembre de 2006 / diciembre, Derechos de autor © 2006) 

Descargar PDF 

Este Digg • de.licio.us • Slashdot • Technorati • StumbleUpon • Agregar a favoritos Google

Resumen: En las fronteras dentro y entre las empresas cada vez más permeables, hay una mayor necesidad de flujo de información. Este es inhibida por los "silos de información", formado por las aplicaciones de software tradicionales. Arquitectura Orientada a Servicio (SOA) reemplaza estos silos con-junto de servicios libremente, permitiendo que la información fluya, según sea necesario, y la entrega de la agilidad empresarial. 

Se trata de un estudio de caso de ING Card, una división del Grupo ING, miembro del Foro de Jericó, de The Open Group. En él se describe la primera fase de su implementación de SOA, con servicios que son difíciles de cable en lugar de descubrir de forma dinámica. Se muestra cómo incluso esta etapa de SOA puede entregar la agilidad del negocio real, y contiene algunas lecciones interesantes para la implementación de SOA. 

Introducción 

ING Card [REF-1], ha entregado recientemente una solución de automatización hito que ha permitido vincular a los nuevos sitios Web, implementar nuevas funciones del producto, y mantener las reglas de puntaje de crédito, con una facilidad sin precedentes y eficiente. Esto se logró mediante la aplicación de tres principios de la construcción, el primero de los cuales fue la orientación a servicios. Este estudio de caso describe la aplicación y se explica cómo SOA ayuda a satisfacer las necesidades del negocio y los desafíos y de la tarjeta de crédito que emiten división de una institución financiera importante. 

Retos 

Un negocio de tarjetas de crédito combina dos de los servicios financieros: de pago y crédito al consumo. El pago por el plástico es aceptado en todo el mundo gracias a una red de grandes pagos, principalmente gestionada por las marcas de tarjetas de crédito como MasterCard y VISA. El emisor de la tarjeta por lo general también proporciona una línea de crédito renovable que permite la devolución tardía de la balanza.El producto completo se refiere a menudo como la "tarjeta de crédito renovable." 

ING tarjeta fue fundada como parte del Grupo ING [REF-2] en 2002, con el objetivo de centralizar el negocio de ING de tarjetas de crédito y su extensión al mercado europeo. ING se convirtió en una tarjeta de jugador importante en el

papel de emisor en la cadena de valor de la tarjeta de crédito compleja (ver Figura 1). 

ING tarjeta utiliza dos marcas de tarjetas de crédito Visa, Mastercard y que son propietarias de las redes de pago en todo el mundo y proporcionar a millones de comerciantes (tiendas, hoteles, restaurantes, arrendadores de vehículos, etc) con equipos de lectura de tarjetas. El lector de contratos son por lo general a cargo de los adquirentes: instituciones (generalmente bancos) que faciliten la conciliación entre los comerciantes y las marcas de tarjetas de crédito. Otro eslabón de la cadena está formada por los siguientesprocesadores: las organizaciones que ejecutan las transacciones reales, proporcione la autorización de la tarjeta en el momento de la venta, y llevar a cabo el acuerdo entre los compradores, las marcas de tarjetas de crédito y los emisores. Algunas instituciones combinar los papeles de comprador y el procesador. 

Figura 1: Funciones en el mundo de las tarjetas de crédito.

Desde el principio, ING Tarjeta tenido algunos problemas particulares que influyeron significativamente en la elección de la solución de TI. 

El primer reto fue para manejar los clientes que no tuviera ya una cuenta de ING actual. Anteriormente, las tarjetas de crédito solamente se proporcionaron a los clientes existentes con una cuenta establecida con la marca ING, que fue utilizado para los pagos mensuales. Ahora, los nuevos clientes podría tener una cuenta corriente en cualquier banco holandés. Todos los sistemas de cliente dentro de ING en Holanda fueron identificados y vinculados a una cuenta de cliente de ING, sin embargo, estos sistemas no pueden ser utilizados por ING Card. Un completo sistema de gestión de clientes nuevos que se necesitaba. 

En segundo lugar, las ventas se concentra en los canales directos (Internet, call center y el correo directo) con instalaciones de cuenta en línea que proporcionan al cliente información sobre sus transacciones en una base

diaria. Por otra parte, el cliente sería capaz de cambiar los importes de pago mensual (con restricciones) y pedir un crédito límite plantea a través de canales directos. 

Esta estrategia de marketing significa que:

• Un sitio Web que se necesitaba para la gestión de cuenta en línea por el cliente;

• El centro de llamadas debe ser capaz de entrar en las solicitudes de tarjetas y preguntas de los clientes;

• Todas las instalaciones de entrada de datos debe ser compatible con todos los canales con el fin de obtener la misma información en todos los canales, y

• Los procesos de gestión de clientes debe estar vinculada al procesador de tarjetas, que se encarga de la distribución de la tarjeta, la cuenta real, y todas las transacciones.

Luego vino el tercer desafío, que fue relacionado con una de las competencias básicas de cualquier emisor: la puntuación de crédito, que es necesaria para gestionar el riesgo. El sistema debe evaluar todas las solicitudes de tarjetas utilizando indicadores de solvencia y el fraude. 

El cuarto desafío estaba en relación con acontecimientos futuros que se conoce de antemano. ING tarjeta estaba planeando un despliegue de múltiples países consistió en la entrega de productos de tarjetas diferentes. El sistema debía ser lo suficientemente flexible como para el despliegue en múltiples localizaciones geográficas, donde los procesos, productos, y la puntuación de crédito está sujeta a cambios.

El desafío final para TI surgió porque ING se convirtió en la tarjeta comercial responsable de todas las carteras de tarjetas de crédito existentes de ING en Holanda (las marcas que se Postbank y el Banco ING), con más de un millón de clientes. Esto significaba que el nuevo sistema debe ajustarse a los procesos existentes y las organizaciones. Pronto quedó claro que la puntuación de crédito se debe realizar de forma centralizada y hecho a disposición de todos los sistemas de tarjetas de otros dentro de ING, con lo que se establece una única fuente para las reglas de negocio de crédito. 

En resumen, los siguientes requisitos debían cumplirse: 

Funcionales

• cliente de administración

• servicios en línea para el cliente

• multi-canal de soporte

• de puntuación de crédito

• apoyo a varios países

• el apoyo a múltiples productos

Características del sistema

• agilidad a los diferentes procesos

• agilidad a los cambios en las características del producto

• acoplamiento a otros procesos, basado en la misma lógica de negocio

La solución 

Se tomó la decisión en una etapa inicial para construir el sistema desde cero. Además, se decidió que la solución se basa en IBM Websphere y plataformas de Oracle y se le dará el nombre de "Nueva tarjeta del sistema" (NCS). 

El nivel necesario de agilidad en última instancia, se logró mediante la construcción de tres principios fundamentales:

1. Una arquitectura en capas (conocida entonces como la "arquitectura n-tier").

2. Servicio de orientación (que también se conoce como "el concepto de servicio").

3. Parametrización de las clases de negocios seleccionados.

El tradicional de tres niveles (presentación, lógica de negocio, datos) se enriquecieron con la orientación a servicios a través de la introducción de una capa de servicios y un modelo de capa de negocio, los cuales residían en la capa de lógica de negocio. Por otra parte, el nivel de datos global fue reforzada por la separación de la capa de acceso a datos de la capa de almacenamiento de datos. Las capas se muestran en la Figura 2, junto con las técnicas y tecnologías utilizadas para su aplicación. 

Figura 2 - La arquitectura en capas de la SAE.

La capa de presentación constituye el exterior del sistema y se compone de una serie de pantallas de apoyo a la automatización de los procesos de negocio principales. NCS tiene actualmente los siguientes casos de la capa de presentación:

• Varios sitios web públicos (www.ingcard.nl y www.ingcard.de) que proporcionan las pantallas para solicitar una nueva tarjeta. Estas pantallas llamar a los servicios de la capa de servicios que implementan el proceso de solicitud.

• Un entorno de Web cerrado y seguro que es accesible por el cliente. Aquí el cliente puede iniciar la sesión, las operaciones de revisión y estados de cuenta mensuales, y administrar su cuenta. El hotel ofrece instalaciones para solicitar un aumento de crédito límite, cambiando la cantidad del pago mensual, solicitando una tarjeta secundaria, e introducir cambios personales (por ejemplo, a la dirección del cliente).

• Un sistema de entrada de datos para el centro de llamadas con funciones similares a las que el cliente tiene y con funciones adicionales, tales como ver el perfil del cliente y los datos de la historia.

• Un sistema de entrada de datos para el back-office, el apoyo a la tramitación de las solicitudes de la tarjeta.

De conformidad con el principio de arquitectura en capas, la capa de negocio sólo es accesible a través de la capa de presentación. Esto permite que la pantalla de diseños para ser independiente de la lógica de negocio. 

La capa de modelo de negocio es a su vez accesibles sólo a través de la capa de servicio. Los servicios son funciones que son significativos para el negocio. Los servicios no se ejecutan estas mismas funciones, no son más que una cáscara o fachada, detrás de la cual se ejecuta la función real de la capa de modelo de negocio. 

Un ejemplo de la capacidad del servicio es findCreditRegistrationPerson, que se encarga de encontrar la persona adecuada en el sistema de crédito de la oficina de la (BKR es la agencia de crédito nacional holandesa). Ver Tabla 1 para su definición completa. 

Tabla 1 - Un ejemplo de un servicio de definición.

La capa de presentación se podría decir que la capa de negocio, "Encuentra a esta persona en BKR, he aquí los datos que usted necesita para ello". La capa de presentación a continuación, puede confiar en la ejecución de esta solicitud y en la obtención de una respuesta. Este diseño tiene tres ventajas:

1. La capa de presentación no es necesario tener en cuenta consideraciones de carácter técnico (por ejemplo, no tiene por qué saber que la conversión de algunos datos que se necesita antes de que pueda ser utilizado).

2. La secuencia en que los servicios se les llama se puede cambiar fácilmente sin ningún cambio en la capa de lógica de negocio.

3. La llamada de servicio no necesita ser cambiado cuando su aplicación se cambia, por ejemplo,findCreditRegistrationPerson no necesita ser cambiado cuando la implementación de la claseCreditRegistrationPerson se cambia.

Independencia de presentación de la lógica de negocios se incrementa en comparación con el modelo tradicional de arquitectura de tres niveles. Por ejemplo, el orden de las tareas se pueden cambiar o otro sitio web puede ser añadido con una selección limitada de los servicios requeridos de salida que requiere la información del cliente. No hay necesidad de modificar la capa de lógica de negocio de esos cambios.Cuando ING tarjeta se lanza en otro país, el servicio findCreditRegistrationPerson tendrá otra aplicación técnica de otra oficina de crédito. El diálogo en la capa de presentación también no necesita ser cambiado, porque el nombre y la llamada del servicio sigue siendo el mismo. 

El principio de construcción de la tercera clase de parametrización se aplicó dentro de la capa modelo de negocio. Esta capa contiene la lógica de negocio real, implementado como operadores en las clases que representan

el modelo de objetos de negocio (BOM). La lista de materiales se determina el "lenguaje" y consiste en un conjunto de clases con sus interrelaciones, aplicadas en forma de clases de Java, como se muestra en la Figura 3 (tenga en cuenta que algunas de las clases son parámetros). 

Figura 3 - Un extracto del Modelo de objetos de negocio en la notación de clases UML.

Si bien las clases de cuentas, el Partido y la tarjeta son directas (que sólo representan la cuenta, el cliente y la tarjeta), las clases de solicitud, la regla del producto y tienen una estructura mucho más parámetros que proporciona una mayor flexibilidad. Cuando una variación de un producto se lanza en una campaña de marketing, sólo la configuración de la clase de producto tiene que ser cambiado, no la estructura de la propia clase. Eso es posible gracias a la definición de un atributo genérico llamado de funciones que puede contener alguna de las funciones posibles para un producto y lo que hace que la clase de productos configurables según las necesidades. 

Una característica como "un año gratis" se pueden añadir fácilmente sin necesidad de reconstrucción. La aplicación efectiva de dicha característica no está implementada en la SAE, pero es ejecutado por el procesador de la tarjeta; NCS sólo necesita que transmita las características adecuadas para el procesador.La solicitud y las clases se definen en la regla de manera similar. Para la clase de artículo que es un motor de reglas independiente que permite una configuración flexible de las normas de crédito. 

En resumen, la capa de negocio ofrece servicios a la capa de presentación y se ocupa de las transacciones en la capa de modelo de negocio de una manera que refleja el lenguaje de la administración de tarjetas de crédito. La capa de modelo de negocio se ha creado con clases simples y parámetros, las clases de parámetros permiten cambios en las características del producto, normas de puntuación de crédito y artículos de solicitud sin afectar todo el sistema. 

El Resultado 

NCS ha cumplido con las expectativas mediante el establecimiento de sí mismo como el sistema responsable de la gestión de clientes. Además, NCS fiable ejecuta todos los servicios que los clientes se ofrecen a través de Internet (tales como hacer cambios de dirección o de solicitar un aumento de límite de crédito). Por último NCS ahora también realiza la evaluación de las solicitudes de tarjetas, con lo que podrá mediar en todo tipo de riesgos de crédito y el fraude. 

Los tres principios de construcción de la arquitectura en capas, la orientación a servicios, y la parametrización de clase individual y colectivamente, han contribuido al cumplimiento de los requisitos originales, en particular los relacionados con la agilidad (Tabla 2). 

Tabla 2 - Requisitos satisfecho por el principio.

La arquitectura en capas es necesaria para ofrecer soporte multi-canal. Si la misma información, (y en parte la misma funcionalidad) se va a presentar al cliente a través de Internet, el centro de llamadas, o por un empleado de oficina, a continuación, una separación entre la capa de presentación y de negocios es esencial para evitar el duplicado de la implementación de la funcionalidad . parametrización de la clase se podrá lograr que el tiempo necesario a precios de mercado para la introducción de nuevos productos y para la adaptación de puntuación de crédito y las reglas de detección de fraudes. 

Servicio de orientación resultó ser el más importante de los tres principios. Mediante el establecimiento de una fachada de la lógica de negocios fue posible desplegar NCS con relativa facilidad en otros países. Por otra parte, la orientación a servicios habilitados optimización de los procesos sin tener que cambiar el sistema y la conectividad incluso facilitó con otros procesos y sistemas. 

La mejor demostración de la potencia suministrada por la capa de servicios se incluyen con el despliegue internacional. Ahora es relativamente fácil de ING Tarjeta de utilizar SAE en cualquier otro país, aun cuando existen importantes diferencias ambientales. 

Comprobación de la oficina de crédito nacional, por ejemplo, requiere una aplicación diferente en cada lugar. El trabajo de construcción de la interfaz sigue siendo, pero el servicio que está llamado a ejecutar el cheque no tiene por qué cambiar. 

Otro ejemplo es la capacidad de un centro de llamadas para utilizar su propio sistema prefiere que soporta más que el producto de tarjeta de crédito. Este sistema sólo tiene que llamar a los servicios competentes de la SAE, cuando un agente de call center se encarga de una solicitud de tarjeta de crédito, utilizando las pantallas y diálogos de su propia solución. En otras palabras, no hay necesidad de una profunda integración entre los sistemas. Hay muchas situaciones en que la independencia de la capa de servicios muestra su valor, algunas de las cuales se ilustran en la Figura 4. 

Figura 4 - servicio de los consumidores diferentes que utilizan los servicios en distintos escenarios de uso.

No todos los aspectos de lo que hoy SOA han sido realizados por la SAE. Por ejemplo, las capas NCS comunicarse a través de objetos J2EE, no mensajes. Por lo tanto no hay bus de mensajes y las tecnologías Web (SOAP, WSDL y UDDI) comúnmente utilizado para crear servicios como los servicios web no se utilizan.Los contratos de servicio han sido publicados en un documento de Word y la gestión de estos servicios son los procesos manuales. 

En la superficie, la solución no parece ser muy diferente de una de las aplicaciones tradicionales, basada en API. Hay una diferencia significativa, sin embargo. Los servicios no están integrados con la lógica específica. En otras palabras, no hacen nada por su cuenta debido a que su principal responsabilidad es para componer e invocar las funciones de negocios adecuado en la secuencia correcta. Estos servicios - los componentes moldeados por la orientación a servicios - por lo tanto establecerse como miembros mucho más independiente de la solución que si se hubieran desarrollado de la abeja como funciones en un diseño tradicional, basada en API. 

La implementación de SOA de la SAE fue diseñado para ser realizado en fases. En la primera fase, NCS existe como un sistema simple con un número limitado de capas de presentación. Por ello, los servicios no tiene por qué ser publicados y se pueden invocar sin el uso de protocolos

estandarizados. Pero tan pronto como los servicios de NCS necesidad de ser llamado desde otras aplicaciones, será necesario que los invoca de forma estandarizada (lo más probable uso de servicios web) y establecer mecanismos estandarizados para la publicación y descubrimiento. Como resultado, la SAE tiene el potencial para participar en una red de múltiples sistemas, lo que contribuye y fomenta los niveles necesarios de la agilidad del negocio. 

Lecciones aprendidas 

Aunque los principios arquitectónicos fueron seleccionados y se estableció en antes del desarrollo de la SAE, muchas cuestiones que requieren nuevos principios y enfoques surgieron durante el proceso de desarrollo. 

A continuación se enumeran algunas de las lecciones aprendidas más interesante:

• Los administradores de TI deben estar preparados para el nuevo papel de guardián de servicio de catálogo. SOA requiere la gestión activa de la recolección o inventario de los servicios que se acumula de manera que cuando los proyectos posteriores ofrecer nuevas funcionalidades de la duplicación accidental de los servicios es constantemente evitado.

• Todas las partes deben estar familiarizados con el servicio de orientación. Esto incluye los accionistas de la empresa, así como los administradores y desarrolladores de aplicaciones de software. Cuando alguno de estos partidos se deja fuera del circuito, hay un mayor riesgo de malentendidos y, posteriormente, la toma de decisiones pobres. Por ejemplo, los diseñadores tradicionalmente educadas que sólo saber acerca de la orientación a objetos puede estar inclinado a los servicios de par con demasiada fuerza a las funciones reales.

• cuestiones de servicio granularidad (por ejemplo, la cantidad de la lógica encapsulada por cada servicio) debe ser resuelta durante la fase de diseño y antes no. Los debates acerca de granularidad puede llegar a ser inmanejable y sin sentido si no relacionados con el análisis de las funciones reales que requieren la encapsulación.

• Debería ser una regla de que la capa de modelo de negocio sólo se puede acceder a través de (y por lo tanto sólo resumieron) la capa de servicio. Es tentador para llamar a los explotadores de empresas de clase, directamente en la capa de presentación, especialmente cuando el sistema todavía se encuentra aislada y aún no relacionada con otras aplicaciones o capas de presentación. Desde esta perspectiva, la capa de servicio puede parecer redundante y presiones típicas y los plazos pueden inclinar a los desarrolladores de derivación de servicios como acceso directo táctico. Estos accesos directos, sin embargo, tienen un efecto desastroso en el tiempo de lanzamiento al mercado de soluciones de futuro que tendrá que depender de la interconexión estándar establecido por los servicios.

• Toda la funcionalidad de flujo de trabajo relacionados con el debe

¿Cómo se hace la empresa SOA de su éxito? 

Arquitectura Orientada a Servicios (SOA) es ahora ampliamente aceptada como un estilo arquitectónico organizaciones están aprovechando para alcanzar la agilidad empresarial y Flujo de Información sin fronteras ™. Pero, como en cualquier ámbito de la implementación de TI, existen dificultades y escollos. La decisión de utilizar SOA no garantiza de por sí el éxito. Los arquitectos de TI debe entender lo que SOA puede y no puede hacer, y cómo se aplican dentro de las circunstancias particulares de su empresa. 

SOA The Open Group Grupo de Trabajo ofrece un foro para la gente de las compañías que implementan SOA y las empresas que proporcionan soluciones SOA SOA para discutir y trabajar en SOA-relacionados que se beneficiará la comunidad de TI.Como director de ese grupo, he observado un crecimiento muy fuerte en el último año de la confianza en SOA, como el que crece la evidencia de las empresas que han tratado de SOA y se encontró que funciona. Al mismo tiempo, la infraestructura de apoyo necesaria para la implementación de SOA - herramientas, formación, etc - se ha convertido en mucho más establecido. Las condiciones ahora existen para SOA para convertirse en un estilo importante de la arquitectura de TI - tal vez el estilo predominante - en los próximos cinco años. 

Este estudio de caso de ING Card es un buen ejemplo del poder de la arquitectura SOA para ofrecer agilidad empresarial. Viene del sector financiero, un área que ha estado a la vanguardia de la adopción de SOA. Sin embargo, SOA es, por supuesto, también se utiliza ampliamente en otros sectores, como el gobierno, manufactura, telecomunicaciones y servicios públicos. De hecho, en todos los campos que utiliza tecnología de la información, arquitectos de TI de la empresa está pensando en SOA, y lo que pueden hacer, y cómo usarlo. 

La mejor manera de hacer su SOA en

mantenerse fuera de la capa de servicio. Cuando la orden de una serie de funciones depende del conocimiento externo que no está disponible en el sistema, se recomienda poner el control en una capa de flujo de trabajo independiente. Esto conserva los servicios como recursos agnóstico que pueden ser reutilizados en el futuro.

• El uso de las herramientas que la coherencia entre la fuerza (UML) modelos es muy recomendable. En el proyecto de desarrollo de NCS, usando una sola herramienta para la clase, la actividad, y los diagramas de secuencia resultó ser un ahorro de tiempo significativo.

Conclusión 

Servicio de orientación es un método de construcción distintos. Por lo tanto, los conceptos detrás de SOA se puede aplicar a un solo sistema, en particular cuando este sistema tiene que compartir funciones con otros sistemas o capas de presentación. Servicio de orientación sigue el diseño basado en componentes como la próxima generación de la distribución informática. Los servicios pueden ser posicionados para proporcionar un depósito o fachada que sea significativo para el negocio, mientras que abstraer los componentes técnicos y los detalles de implementación. La aplicación de la orientación a servicios puede ayudar a las organizaciones lograr la flexibilidad y la agilidad que requieren, como se demostró en el caso de ING Card. 

Referencias 

[REF-1] www.ingcard.nl , www.ingcard.be y www.ingcard.de 

[REF-2] www.ing.com 

Nota: Este artículo fue publicado originalmente en holandés. Una versión más corta fue publicada como "dankzij SOA Wendbaarheid" en Informatie noviembre de 2005, n º 47 / 9, página 64-69. La versión extendida fue publicada en Charles M. Hendriks y Arno J. Oosterhaven (red.), Architectuur en Ontwikkeling.Landelijk Architectuur Congreso de 2005, Académico de servicio Den Haag, 2006, ISBN 9012113199, página 93 a 105. Original de traducción por el autor, con la ayuda de Chris Harding.