SOAr v1.1. Página 1/103 Copyright (c) Cesar Obach-Renner, Gurulab.org

Transcripción

1 Página 1/103

2 (SOA recargada) Un enfoque pragmático de Arquitectura Orientada a Servicios (SOA) para Integración de Aplicaciones Empresariales (EAI) Autor César Obach-Renner Junio 2008 Página 2/103

3 Copyright (c) Cesar Obach-Renner Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Section being Prefacio, no FrontCover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License. Página 3/103

4 1 Contenido 1 CONTENIDO PRÓLOGO PREFACIO SOBRE GURULAB QUIÉN DEBE LEER ESTE LIBRO? SITIO WEB DE APOYO E INFORMACIÓN DE CONTACTO SOBRE LOS TÉRMINOS EN INGLÉS WATERMARK DEDICATORIA Y AGRADECIMIENTOS INTRODUCCIÓN QUÉ ES SOAR? SOAR COMO 4TA GENERACIÓN DE EAI Primera generación: Integración punto a punto Segunda generación: Integración por Broker Tercera generación: SOA Cuarta generación: BENEFICIOS DE SOAR SOAR Y BPM ELEMENTOS CLAVES DE UNA IMPLEMENTACIÓN EXITOSA DE SOAR ESPECIFICACIÓN DE SERVICIOS DEL NEGOCIO (BSI) CALIDAD DE LA BSI Fenómeno del Cernido Criterios para generar una BSI de buena calidad HERENCIA FUNCIONAL Agregación de funcionalidades ortogonales Agregación de funcionalidades no ortogonales ESPECIFICACIONES ESTÁNDARES DE INDUSTRIA Telecomunicaciones etom TAM SID MTOSI OSS/J OTRAS INDUSTRIAS ASPECTOS TÉCNICOS ANATOMÍA DE LA PLATAFORMA DE INTEGRACIÓN Nivel Nivel Plataforma ideal DESARROLLO DE CONECTORES Características técnicas Características funcionales IMPLEMENTACIÓN DE SERVICIOS DEL NEGOCIO...58 Página 4/103

5 8 CONSIDERACIONES ESTRATÉGICAS SISTEMA NERVIOSO EMPRESARIAL ESTRATEGIA DE IMPLEMENTACIÓN Ejemplo de una Iteración ENFOQUE PRAGMÁTICO MODELO DE SERVICIO RECOMENDACIONES DE IMPLEMENTACIÓN MODELAJE DE PROCESOS Definición Componentes básicos Consideraciones Actores Cómo identificar un proceso? Aspectos relevantes Representación gráfica El diagrama Características Ventajas Recomendaciones NOMENCLATURA Flujos de Servicios Nodos (N** ) Nodos de Entrada/Salida (NIN_ / NOU_ ) Nodos de Mapeo (NMP_) Nodos de Transformación (NT*_) Servicios Genéricos & Servicios Específicos METODOLOGÍA PREMISAS COMPARACIÓN CON OTROS MODELOS IBM RUP Sun Microsystems SOA Institute SAP CICLO DE VIDA DE UN SERVICIO GOBERNABILIDAD Roles Funciograma PROCESO Documentación del requerimiento Análisis Criterios de Alcance de Integración Arquitectura Diseño Construcción y pruebas Pase a producción Herramientas de Software Libre GLOSARIO PROCESO...92 Página 5/103

6 11.2 PROCEDIMIENTO DIAGRAMA DE FLUJO INTERCAMBIOS VS SERVICIOS VS INTERACCIÓN WEBSERVICES GNU FREE DOCUMENTATION LICENSE...95 Página 6/103

7 2 Prólogo Página 7/103

8 3 Prefacio Luego de tres años en el proceso de conceptualización, ingeniería básica y detallada de una Arquitectura de Integración Orientada a Servicios, he sintetizado una aproximación a la integración de aplicaciones empresariales (EAI) que se basa en la implementación de una Arquitectura Orientada a Servicios (SOA). A lo largo de este documento, el lector tendrá la oportunidad de entender el valor diferenciador de esta aproximación de SOA la cual llamo SOA recargado (), respecto a cualquier otro enfoque de integración de aplicaciones. Aprenderá las razones que justificarán, tanto del punto de vista técnico como económico y de negocio implementar esta aproximación y adicionalmente tendrá a la mano una metodología probada que le ayudará a implementar un proyecto por muy grande o ambicioso que éste sea. A finales del año 2005 luego de la fase de concepción de y construcción de los elementos fundamentales de la arquitectura, llegó el momento de ponerlo en práctica en el primer proyecto con alcances, fechas y presupuesto reales. Para enfrentar dicho proyecto se realizó una importante búsqueda de metodologías para implantar SOA a través de las principales compañías de consultoría e integración de TI internacionales, la cual resultó en la conclusión de que no había a la mano ni una metodología ni la experiencia necesaria para implementar una arquitectura de integración basada en servicios. Ante esta situación, creé una metodología que fue utilizada durante las fases de análisis, diseño y construcción de las integraciones que el proyecto requería, la cual ha sido documentada en este libro. Dicha metodología es parte del framework de integración ( y siendo uno de sus componentes es llamada Metodología. El framework se encuentra en un proceso de mejora continua gracias a la colaboración de Gurulab.org y de su comunidad de usuarios que aportan sus experiencias y oportunidades de mejora. Adicionalmente a la la conceptualización y metodología, el framework contiene herramientas que facilitan la implementación de un proyecto de integración basada en SOA. 3.1 Sobre Gurulab Gurulab.org es un laboratorio de innovación tecnológica dirigido por Cesar Obach-Renner el cual busca el desarrollo de tecnologías de información y comunicación o usos innovadores de éstos, apalancados en la imaginación y conocimiento de sus miembros. Página 8/103

9 Adicionalmente a las innovaciones que ha incursionado en los últimos 10 años, Gurulab.org ha logrado una buena experiencia en la ejecución de hazañas tecnológicas para varios de sus clientes. El laboratorio opera de manera distribuida a nivel mundial y sus miembros se reúnen varias veces al año en convención para presentar sus trabajos. En su plan estratégico se plantea construir una base de operaciones que le permita con un presupuesto base desarrollar iniciativas de investigación, desarrollo y formación de especialistas técnicos en temas de Arquitectura, Tecnología e Innovación. El vehículo que Gurulab.org utiliza para entregar sus innovaciones son las licencias del proyecto GNU ( GPL para el software, y FDL para las practicas y documentaciones como. Entre sus iniciativas, además del framework, se encuentra un ESB software libre para implementación de integración SOA y llamado Mula, y un framework de desarrollo rápido de aplicaciones llamado Jasolina. Gurulab, adicionalmente a sus procesos de investigación y desarrollo, provee servicios de educación y asesoría para asegurar la adecuada adopción de las tecnologías que domina. 3.2 Quién debe leer este libro? Este libro está dirigido a quienes buscan una forma pragmática de implementar SOA, a quienes luchan por lograr una plataforma de sistemas estable y que le permita proveer mayor valor al negocio. Si bien este libro está orientado a Gerentes de Sistemas, Arquitectos de Tecnologías de Información y especialistas de integración; cubre el tópico de de manera introductoria sin exigir al lector un conocimiento previo más allá de lo que significa la practica de integración empresarial de aplicaciones (EAI). Esto significa que todo profesional del área de sistemas y/o tecnologías de información entenderá perfectamente los conceptos y planteamientos hechos aquí. El propósito es transmitir claramente el concepto de, cuáles son sus beneficios, cómo debe observarse la plataforma tecnológica a ser utilizada y una orientación inicial de cómo debe realizarse un proyecto de implementación con esta práctica. Por ser introductorio, este documento puede ser una referencia para todo aquel que quiera extender sus conocimientos en los temas de SOA e integración de aplicaciones empresariales. Página 9/103

10 3.3 Sitio web de apoyo e información de contacto Esta publicación es el documento oficial del concepto perteneciente al Framework de (en inglés Framework), ambos disponibles bajo licenciamiento de documentación Libre de GNU ( El URL oficial del Framework de es y en dicho lugar se encuentra descrito claramente su valor y cada uno de sus componentes. El Framework de es un conjunto de recursos disponibles a la comunidad de Tecnología de Información para lograr implantaciones exitosas de. En particular, los componentes del Framework de son: El libro " - El concepto" (Cookbook) Especificación de Servicios del Negocio (BSI) Cursos y Talleres Casos exitosos Integradores experimentados Plataformas de Integración (ESBs) 3.4 Sobre los términos en Inglés. La versión en español de este documento utiliza los acrónimos de los términos en inglés de manera estándar. Esto debido a mantener las referencias de los conceptos en su idioma de origen y no generar una traducción que pueda crear confusión en el lector. Seguramente a medida que estos conceptos vayan adoptándose de manera general en regiones de habla hispana, sus traducciones al español serán mejor conocidas y entonces tendrá sentido generar una revisión de este documento incluyendo dichas traducciones de facto. 3.5 watermark Minor Earth Mayor Thought That It Was She's Williams The Williams Página 10/103

11 3.6 Dedicatoria y Agradecimientos Le dedico este libro a mi esposa Alejandra, quien más allá de apoyarme incondicionalmente en todos mis proyectos, me dio el entusiasmo y soporte durante todo el tiempo que tomó su desarrollo; sin ella, realmente no hubiera terminado... gracias Ale por las porras! Quiero agradecer a todas las personas que han apoyado el proyecto de desarrollar este libro y de manera especial a las siguientes personas quienes le han dedicado tiempo ayudándome a mejorar su calidad de una u otra forma; en particular a mi amigo Argenis Gomez quien me dio la infraestructura para comenzar este proyecto y a quien le debo el nombre de este proyecto, a mis colaboradores Cesar Olivar, Jorlette Martinez, Santiago Ventura, Rossana Diaz y Danny Rodriguez, a Ana Isabel Rodriguez por su revisión; gracias a Antonio Plutino, Phillipe Lalande Christophe Ebro y el resto de los compañeros de OSS/J; muchas gracias a todos los que ayudaron a probar el concepto utilizando plataformas de Software Libre así como con software propietario, y a todos los lectores que durante este año han estado esperando pacientes por su publicación; muchas gracias a todos ustedes! Un especial agradecimiento al equipo de PESSO y en general a los equipos técnicos del ICE que me han brindado múltiples oportunidades de poner a prueba estos conceptos logrando sanos e interesantes discusiones sobre Arquitectura. Página 11/103

12 4 Introducción A nivel mundial, todas las empresas se enfrentan a un reto que con los años se ha venido intensificando independientemente del sector o industria; esto es, la reducción de sus costos mientras aumentan su agilidad y velocidad para innovar respecto a su oferta en el mercado. La reducción de costos siempre ha sido un elemento clásico en la optimización del valor de las empresas desde su existencia; sin embargo, cómo es esto posible esto a la vez que se mejoran las capacidades de innovación de la organización? Para innovar tradicionalmente se requiere de inversión en investigación y eso no es precisamente reducción de costos. Además, para apoyar la disminución de costos de la empresa, una de las mejores herramientas es el uso eficiente de Tecnología, lo cual implica un flujo mayor en esa área1. La respuesta que las grandes consultoras y los analistas han encontrado está en la optimización de los procesos a todo nivel de la empresa y el uso de plataformas tecnológicas extremadamente flexibles y poderosas sin dejar de ser simples. Han logrado mediante la mejora de procesos claves del negocio una respuesta sustancial respecto a la mejora del valor de sus clientes. Como respuesta a esa necesidad, Gurulab.org ha desarrollado un modelo referencial que define la Plataforma de Tecnología de Información de Nueva Generación (en inglés NGITP como siglas de New Generation Information Technology Platform); tiene como meta una plataforma ideal que provee todas las características necesarias para lograr que la tecnología esté al servicio del negocio a través del servicio de sus procesos, y no que el negocio se adapte a las limitaciones de la plataforma. Para conocer cuan cercano a ese ideal se encuentran las empresas, el modelo referencial NGITP viene acompañado de un modelo de madurez que describe 5 etapas o niveles de los cuales el nivel 5 es representa el ideal planteado por NGITP y el nivel 1 es el más básico en el que toda empresa se encuentra en el peor caso. Tradicionalmente los procesos de una empresa se encuentran programados (o como dicen los técnicos cableados ) en las aplicaciones empresariales que automatizan sus procesos y que utilizan para operar; cuando son varias las aplicaciones utilizadas, la sincronización de sus procesos ocurre de manera 1 Existen empresas que para optimizar sus flujos de salida utilizan un criterio puramente económico reduciendo los gastos e inversión en todas sus unidades incluyendo Tecnología, en vez de un criterio Sistémico de optimización de sus procesos lo cual apalancado en una inversión mayor en el área de tecnología permite resultados interesantísimos en el costo total de operación de toda la empresa. Página 12/103

13 más básica de forma manual. Esto último es lo que el modelo de madurez de NGITP llama el nivel 1 (ver Figura 1). En dicho nivel 1 de NGITP vemos un conjunto de n aplicaciones (App 1, App 2,..., App n), las cuales dan vida a j procesos (p 1, p 2,..., p j) y cada interactuando con sus usuarios a través de n interfaces hombre-máquina (GUI App 1, GUI App 2,..., GUI App n) todas a este nivel a través de un único canal de acceso Web (c1). Nivel de Madurez c1 c1 c1 c1 GUI App 1 GUI App 2 GUI App n p1 App 1 p2 App 2 p3 pj App n 1 - Silos NGITP Maturity Model Figura 1 Nivel 1 del modelo de madurez de NGITP Se presenta generalmente la disyuntiva respecto a si una empresa debe adaptarse a los procesos que lleva consigo una nueva aplicación, o por el contrario debe modificar dicha aplicación para que ésta implemente los procesos que la empresa lleva a cabo; cualquiera de ambas decisiones implica un gran costo y un matrimonio con la nueva configuración que implique la acción tomada. Por ejemplo, un fabricante de aplicaciones empresariales alemán con sede en Walldorf (Alemania) provee aplicaciones cuyo principal activo es la sólida seguridad que provee a sus clientes respecto a los procesos que sus aplicativos implementan; sus clientes tienden a adaptarse más que a modificar, claro está, siempre con la facilidad de ajustar los procesos para que calzar adecuadamente a ambos. Ahora bien, si imaginamos una plataforma cuyo costo de configuración sea despreciable, no solo implicaría una fácil decisión respecto a la adopción de los procesos que la empresa desee (independientemente de que sean actuales Página 13/103

14 o deseados, o sean buenos o malos, estén en la caja o fuera de ella), sino que le proveería de una gran flexibilidad en la modificación de sus procesos como respuesta a ambientes y mercados cambiantes y dinámicos. Bastaría con conseguir una aplicación que tuviese esa capacidad súper configurable y lograríamos el objetivo; sin embargo nos topamos con una realidad inevitable: en ambientes empresariales de mediana complejidad en adelante, nos conseguimos con el hecho ineludible de que no existe un solo fabricante que provea todos los componentes de la plataforma de TI cumpliendo con todos los requerimientos del negocio que van más allá de los técnicos como por ejemplo, seguridad, calidad, precios, soporte, relación, etc. Desarrollando solo algunos de los puntos indicados, respecto a seguridad, el hecho de que una empresa posea un solo proveedor de todos sus componentes de TI, implica un riesgo importante que tiende a desaparecer cuando se tienen a varios proveedores. Respecto al costo, el mercado puede ofrecer sin duda alguna más de un proveedor que ofrece una solución con las mismas prestaciones pudiendo ser el proveedor alternativo quien provea un mejor precio, resultando una mejor oferta de negocio. Esto implica un problema, ya que al tener aplicativos de distintos fabricantes, aún asumiendo que todos sean súper configurables, los procesos vivirán de manera aislada a menos que sean sincronizados a través de la integración entre dichas aplicaciones o exista algo de nivel superior, extra-aplicación que controle los procesos. En el caso de la sincronización, sin un elemento superior que controle los procesos, las aplicaciones perderían flexibilidad dado que la sincronización establecería una restricción a los procesos que sincroniza la cual debería ser administrada de manera independiente; en este escenario, las aplicaciones súper-configurables pierden su flexibilidad. La mayoría de las empresas que hoy en día tienen una práctica madura de integración se encuentran en este estadio, la cual corresponde independientemente de que las aplicaciones sean súper configurables o no, al nivel 2 del modelo de madurez del NGITP (ver Figura 2) Página 14/103

15 Nivel de Madurez c1 GUI App 1 c1 c1 GUI App 2 c1 GUI App n Bus p1 App 1 p2 App EAI p3 pj App n 1 - Silos NGITP Maturity Model Figura 2 Nivel 2 del modelo de madurez del NGITP Solo queda válido como respuesta a nuestro planteamiento el escenario en el que el proceso es controlado por algo de nivel superior. Este escenario implica que las aplicaciones no controlan procesos sino que sirven tareas o funcionalidades a ese ente superior que controla los procesos llamaremos Gestor de Procesos. Esta conclusión a la que estamos llegando es clara para muchos Arquitectos empresariales y fabricantes de aplicativos en todo el mundo, quienes convergen en la necesidad de desacoplar la gestión de los procesos de la musculatura de ejecución de transacciones que representan las aplicaciones bajo este nuevo enfoque. La casa de Walldorf lo acepta también no solo sacando al mercado herramientas para coreografía de procesos, sino generando rutas de evolución de sus aplicaciones para sacar los procesos de sus cajas hacia su coreógrafo de procesos. Ahora bien, cuál es el estado de nuestra solución? Hemos dibujado hasta ahora una plataforma que consta de una colección heterogénea de aplicaciones que exponen funcionalidades o tareas que son orquestadas por un gestor de procesos. Como puede verse, ahora lo súper configurable no es una característica a buscar en las aplicaciones, sino en la arquitectura que se establece entre el Gestor de Procesos y los aplicativos. Página 15/103

16 Para lograr esa característica súper configurable basta con proveerle al Gestor de Procesos tres (3) elementos fundamentales: 1) un mecanismo de desacoplamiento de las funciones que los procesos modelados desean ejecutar, de las aplicaciones que realmente serán las responsables de ejecutarlas. De esta manera, el desarrollo de las reglas del negocio basadas en procesos son independientes de la colección de aplicaciones que la plataforma de sistemas tenga en cualquier momento. Esto le devuelve al negocio el poder de sus procesos, delegando únicamente a Tecnología la tarea de proveer los componentes sobre los cuales viven los procesos. Esto es logrado a través de la exposición de servicios que muestran una vista de las funcionalidades y datos de las aplicaciones subyacentes en un formato canónico simple, idealmente estándar. Esto es lo que el modelo de madurez de NGITP plantea como nivel 3 (ver Figura 3). A estos servicios les llamamos Servicios del Negocio. Nivel de Madurez c1 c1 GUI App 1 S1 S2 c1 GUI App 2 S3 c1 GUI App n 3- Sm Bus p1 App 1 p2 App 2 Servicios Corporativos 2 - EAI p3 pj App n 1 - Silos NGITP Maturity Model Figura 3 Nivel 3 del modelo de madurez del NGITP 2) un gestor de procesos con una interfaz de definición simple y poderosa, el cual esté basado en la coreografía de los servicios corporativos expuestos. Página 16/103

17 Basado en los servicios corporativos, el gestor de procesos permite modelar procesos y ejecutarlos a lo largo y ancho de la plataforma de tecnología, permitiéndole al negocio evolucionarlo con la rapidez que sea requerido por lo dinámico del entorno, sin necesidad de depender de modificaciones a nivel de sistemas. En Figura 4 se muestra el nivel 4 del modelo de madurez del NGITP, el cual muestra cómo a diferencia del nivel anterior, los procesos viven en el Gestor de Procesos y no en las aplicaciones. Nivel de Madurez c1 c1 GUI p1 c1 GUI p2 p1 p2 p3 pj S1 S2 S3 c1 GUI pj Process Manager 3- Sm Bus App 1 App BPM Servicios Corporativos 2 - EAI App n 1 - Silos NGITP Maturity Model Figura 4 Nivel 4 del modelo de madurez del NGITP En dicha Figura note cómo la interfaz gráfica ya no corresponde a interfaces de aplicaciones sino de procesos, es decir, en lugar de que los usuarios interactúen con las funcionalidades de las aplicaciones a través de ellas, lo harán en el contexto de los procesos orquestados por el Gestor de Procesos y a través de él. 3) Una interfaz de usuario para ejecución de procesos que se construya automáticamente a partir de la definición del proceso. Como elemento final del modelo de madurez, tal como se muestra en la Figura 5, el nivel 5 incorpora tecnología que adapta de manera automática las interfaces de interacción hombre-máquina para permitir la interacción de los usuarios con los procesos modelados en el Gestor de Procesos. Página 17/103

18 Nivel de Madurez c1 c2 ci SmartInterface p1 p2 p3 pj S1 S2 S3 Process Manager App BPM 3- Sm Bus App SmartInterface Servicios Corporativos 2 - EAI App n 1 - Silos NGITP Maturity Model Figura 5 Nivel 5 del modelo de madurez del NGITP En la figura del nivel 5, se puede observar que existe una sola lógica de interfaz que se adapta a todos los procesos por cada canal. En particular, el primer canal ejemplificado es el canal Web. Este nivel provee no solo la ventaja de bajo costo en el mantenimiento de las interfaces para soportar nuevos canales, sino que al final del día para poder cambiar los procesos que se ejecutan en la empresa, basta con cambiar su definición e instantáneamente el sistema se adapta a la nueva definición. El modelo de interfaz adaptable es llamado SmartInterface como un concepto incorporado por NGITP. Página 18/103

19 5 Qué es? es una forma de integrar aplicaciones y procesos basado en una Arquitectura Orientada a Servicios (SOA), la cual tiene como objetivo principal aislar toda aplicación de la plataforma de tecnología o proceso del negocio, del resto de la arquitectura; logra esto simplificando de manera importante cualquier esfuerzo de integración empresarial, logrando: Desacoplar la plataforma de TI de los procesos del negocio. Desacoplar las aplicaciones unas de otras, escondiendo la complejidad del conjunto de aplicaciones existente a cualquier nueva aplicación que se desea integrar. Controlar reduciendo los riesgos derivados de los cambios de aplicaciones de la plataforma de sistemas. Aprovechar al máximo las capacidades de las herramientas tecnológicas existentes actualmente. Para entender bien como funciona, imaginemos el caso (ver Figura X) de integrar los procesos de una empresa (por ejemplo, a través de una plataforma de gestión de procesos -BPM-) o una nueva aplicación, a su plataforma de Tecnologías de Información (TI). Figura 6: Caso de uso: Integración de procesos del negocio o nueva aplicación con plataforma de TI La plataforma de TI del caso de uso que estamos estudiando, independientemente de la industria a la que pertenece, tiene una gran cantidad de funcionalidades las cuales de manera ideal, estarían implementadas por un grupo ordenado y concreto de Aplicaciones Ideales las cuales llamamos Componentes Funcionales. (ver figura X) Página 19/103

20 Los componentes funcionales tienen nombres comunes a diferencia de las aplicaciones que tienen nombres propios ; por ejemplo podríamos decir que la aplicación GNU/Linux (nombre propio) es un Sistema de Operación (nombre común); como otros ejemplos tenemos Sistema de Contabilidad, Sistema de Recursos Humanos, Facturador, etc. Si una empresa tuviese una aplicación para cada Componente Funcional requerido, su Plataforma de TI luciría como la figura antes mostrada, la cual muestra un grupo ordenado y simple de aplicaciones con las cuales los procesos o nueva aplicación han de integrarse. Sin embargo, la realidad de la mayoría de las empresas es que tienen más de una aplicación cumpliendo el mismo Componente Funcional. (ver figura X) Adicionalmente, todas esas aplicaciones no solo generan una gran redundancia funcional que representa grandes complejidades de administración y mantenimiento, sino que la naturaleza de las integraciones entre las aplicaciones que tradicionalmente han sido utilizadas (fundamentalmente punto a punto), nos presentan una plataforma de TI más compleja como la mostrada en la figura X. Página 20/103

21 El caos reflejado por la lámina trata de mostrar el caos existente debido a: Integraciones punto a punto Solapamientos funcionales totales Solapamientos funcionales parciales Sistemas en proceso de sustitución La siguiente y última lámina de la secuencia muestra cómo todo ese caos en la plataforma de TI es ocultado y encapsulado por un conjunto simple de Servicios del Negocio agrupados por Componentes Funcionales, los cuales son la fachada que la plataforma de TI expone a los procesos y nuevas aplicaciones que han de integrarse. Los Servicios del Negocio expuestos simplifican la Plataforma de TI expuesta dado que encapsula los solapamientos funcionales y complejidades técnicas propias de la heterogeneidad de los componentes de un ambiente de sistemas. En otras palabras, en vez de que los procesos y nuevas aplicaciones se integren a múltiples aplicaciones a través de múltiples tecnologías con múltiples consideraciones respecto a en qué circunstancias que patrón de interacción aplica y en qué otro, simplemente se integran con un único y simple componente funcional a través de una única tecnología. Página 21/103

22 De esta manera, la estrategia de integración de aplicaciones provee: Simplicidad, porque esconde la complejidad resultante de la redundancia y solapamientos funcionales de las aplicaciones existentes. Por ejemplo, en vez de tener tres sistemas de facturación, expone uno solo; en vez de tener dos sistemas contables, expone uno solo. Estabilidad, porque para todo cliente de las aplicaciones expuestas por, estas últimas nunca cambian; esto es debido a que aún cuando en realidad las aplicaciones en realidad si cambian, lo hace transparente a los clientes de manera que estos últimos no se dan cuenta. Por ejemplo, al instalar un nuevo CRM, le expone los servicios estándares del Gestor de Ordenes de Servicio. Tras bastidores orquesta y resuelve la complejidad de tener cinco Gestores de Ordenes de Servicio. Cuando otro proyecto en la búsqueda de la racionalización de las aplicaciones de Gestión de Ordenes de Servicio sustituye tres de los cinco existentes por uno nuevo, el CRM no se entera de tal sustitución gracias a. Conveniencia, porque en el contexto del modelo referencial NGITP de Gurulab, representa un mecanismo para lograr el establecimiento de una Plataforma de Tecnología de Información de Nueva Generación nivel 3. Eficiencia, porque aprovecha al máximo las características de las plataformas tecnológicas actuales al definir claramente cómo utilizar cada componente de la plataforma de la empresa, independientemente de quien sea el proveedor de cada uno. Página 22/103

23 Como veremos en la siguiente sección, representa la 4ta generación de la práctica de EAI2, y corresponde a una forma particular de SOA con características resaltantes que lo apuntalan como una práctica diferente y con beneficios concretos. 5.1 como 4ta generación de EAI La práctica de EAI a lo largo de su historia ha ido evolucionando logrando un avance en su madurez pasando por cuatro generaciones. A continuación veremos cada una de estas generaciones a saber: i) ii) iii) iv) Punto a Punto Broker SOA Primera generación: Integración punto a punto El modelo de EAI Punto a Punto corresponde fundamentalmente con la conexión entre los aplicativos de manera directa entre si todos contra todos; tal como se muestra en la Figura 7, cada aplicación tiene tantas conexiones como el resto de las aplicaciones existentes. Figura 7 Primera generación de EAI: Punto a punto El orden de complejidad de las conexiones existentes en este modelo es 2 C n= 2 n! n = 2 2! n 2! EAI por sus siglas en inglés de Enterprise Application Integration. Página 23/103

24 en donde n es el total de aplicaciones a interconectar. Por ejemplo, para 30 aplicaciones, la combinatoria da 435 conexiones; para 90 aplicaciones, da 4005 conexiones. El modelo EAI punto a punto puede considerarse como el modelo primal, el cual es resultante de la resolución de las necesidades de integración sin ningún tipo de planificación y con un crecimiento descontrolado Segunda generación: Integración por Broker Un Broker es el elemento que actuando como centralizador de toda comunicación que haya entre cualesquiera aplicaciones de la arquitectura, se encarga de enrutar los mensajes que vienen de una aplicación origen, hacia la aplicación destino (Ver Figura 8) Figura 8 Segunda generación de EAI: Hub o Broker de integración La presencia del Broker logra una menor complejidad en la comunicación entre las aplicaciones. Se simplifica la cantidad de conexiones entre ellas aún cuando a través de estas puedan pasar múltiples tipos de mensajes que el broker al interpretar debe enrutar a la aplicación destino. Los mensajes que cada una de las aplicaciones envía al broker, además de contener la información que el Broker interpreta para saber hacia qué aplicación enviarlos, contiene la estructura y mensaje que la aplicación destino espera recibir; es decir, el mensaje que una aplicación envía al Broker cumple con el Contrato establecido por la aplicación destino. Debido a que entonces todas las aplicaciones solo requieren conectarse con el Broker, entonces en este modelo la cantidad de conexiones se simplifica a n, donde n es la cantidad de aplicaciones a interconectar. Página 24/103

25 5.1.3 Tercera generación: SOA Desde la perspectiva de Arquitectura Empresarial, SOA (del inglés Service Oriented Architecture ) o Arquitectura Orientada a Servicios es un patrón de Arquitectura que afecta todas los diferentes puntos de vista bajo los cuales cualquier tema o artefacto de TI puede ser discretizado; desde la perspectiva del modelo referencial de Arquitectura Empresarial de Gurulab, los dominios pilares a los que el patrón de SOA afectaría son Datos, Aplicación, Integración, Acceso, Infraestructura, Seguridad y Gestión de Sistemas. Muchos fabricantes de aplicaciones suelen promocionar la idea de que al incluir en su producto un conjunto de servicios web que exponen las funcionalidades de su aplicativo, están proveyendo una aplicación Compatible con SOA. Si bien esto no es equivocado, lo que ha ocurrido en el mercado es que las empresas han entendido que al integrar sus aplicaciones al hacer uso de estos servicios expuestos por los aplicativos, están implementando una Arquitectura Orientada a Servicios. Sin generar ningún juicio de valor, Gurulab ha catalogado esta práctica como tercera generación de EAI, mejor conocido como integración SOA, una colección de servicios que colaboran entre si. Dado que el planteamiento de arquitectura tradicional se ha basado en un modelo de colección de aplicaciones que encapsula completamente todas sus funcionalidades detrás de sus interfaces gráficas, SOA provee la gran ventaja de permitir y fomentar el reuso de funcionalidades ya implementadas por los aplicativos existentes al estar éstas expuestas completamente a través de servicios disponibles para cualquiera que los requiera. Para los fanáticos del modelo de arquitectura de n-capas, SOA representa la colección de funcionalidades de la capa de lógica de negocio que toda aplicación tiene en dicho modelo. En este contexto SOA plantea que toda aplicación expone todas sus funcionalidades a través de servicios. En el modelo de EAI de 3ra generación, la comunicación que existe entre aplicaciones no se basa en el enrutamiento de mensajes de un lado a otro (como ocurre con la del broker de la segunda generación), sino en el consumo de servicios que cada aplicación expone con su respectivo Contrato, en una forma punto a punto. Página 25/103

26 Figura 9 Tercera generación de EAI: SOA La Figura 9 muestra como cada aplicación expone un conjunto de Servicios que están disponibles para que cualquier otra aplicación que los requiera se conecte en tiempo de ejecución y lo consuma. De aquí se desprende que cualquier aplicación puede cumplir tanto el rol de proveedor de un servicio como el rol de cliente de otro. En esta generación de EAI la integración empieza a dinamizarse ya que las conexiones dejan de ser configuraciones estáticas y a la medida y empiezan a exponerse servicios que cualquier otra aplicación pueda reutilizar en el momento que lo desee. Esto provee una gran ventaja en la práctica de EAI ya que esa reutilización de servicios representa menos trabajo a llevar a cabo la próxima vez que se requiera integrar una aplicación que desee consumir justamente el mismo servicio ya expuesto. Originalmente esta Arquitectura Orientada a Servicios era implementada utilizando la tecnología CORBA3 especificada y estandarizada por la OMG4. Si bien las prestaciones que esta especificación proveía para la integración de aplicaciones en el entorno empresarial (proveyendo seguridad, transaccionalidad, alta disponibilidad, etc.) eran completas, resultaban complejas y por ende costosas de implementar. A finales de los años 90, IBM en conjunto con Microsoft desarrollaron una especificación de distribución de servicios con la simplicidad en mente para resolver los problemas que CORBA enfrentaba; de aquí nació la tecnología de Servicios Web, la cual se apalanca en tres elementos fundamentales: el 3 CORBA, del inglés Common Object Request Broker Architecture OMG, Organización internacional de estandarización de manejo de objetos. Siglas del inglés Object Management Group. 4 Página 26/103

27 protocolo de comunicación SOAP5, la especificación de Contratos de servicios WSDL6 y el catálogo dinámico de servicios UDDI7. Si bien la tendencia del mercado es que SOA se implementa con Webservices, dado que SOA es una arquitectura, puede ser implementada utilizando cualquier tecnología incluyendo Webservices; por ejemplo, CORBA, EJBs, RMI, SUN RPC, propietario/socket, Webservices (SOAP/HTTP), etc. El papel del UDDI es generalmente menospreciado, si bien es fundamentalmente un catálogo que le permite a cualquier cliente de un servicio específico descubrir la ubicación física del proveedor de dicho servicio para conectarse en tiempo de ejecución y consumirlo, es quien realmente desacopla el servicio de su proveedor. En la medida que los clientes hagan uso del UDDI siempre que requieran del consumo de un servicio (y no con una referencia física compilada en el cliente), el proveedor estará desacoplado pudiendo cambiar dicho proveedor de la arquitectura con tan solo modificar el registro físico de dicho servicio en el UDDI (similar al funcionamiento del DNS8). Es importante resaltar que en SOA, los clientes de cualquier servicio deben cumplir con el contrato impuesto por la aplicación proveedora del servicio, por lo que si ésta cambia afectando el Contrato, entonces el cliente debe ser modificado para que pueda cumplir con el nuevo contrato. De aquí se desprende la pregunta: qué ventaja nos daría el contar con una especificación de contratos estándar que no cambie independientemente de que se cambien las aplicaciones proveedoras? Cuarta generación: es la evolución de SOA en cuanto que al redefinir la forma de implementación, cubre los vacíos que SOA por si sólo deja sin solución. Estos son: i) Evolución de la especificación de los contratos de los proveedores sin afectar a los clientes: El estado ideal del SOA es contar con una especificación estándar de contratos y con un ecosistema de aplicativos que cumplan con dicha especificación 5 SOAP (siglas de Simple Object Access Protocol): protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML 6 WSDL (siglas de Web Services Description Language): formato XML que se utiliza para describir servicios Web. 7 UDDI (siglas de Universal Description, Discovery, and Integration) : es un Directorio en línea que las aplicaciones utilizan para descubrir de forma dinámica otros servicios en línea. 8 DNS (siglas de Domain Name System): Sistema de nombre de dominios, provee una taxonomía de etiquetas alfanuméricas que permiten asociar un servicio en Internet sin la necesidad de utilizar la dirección física. Página 27/103

28 estándar; de esta manera cuando uno cambie un proveedor por otro los clientes no se ven afectados. ii) Duplicidad funcional: Cuando un servicio es provisto por dos aplicaciones diferentes, diferenciados por criterios particulares tales como tipos de cliente (un tipo de cliente procesado por el proveedor A y para el otro tipo de cliente por el proveedor B), calidad de servicio, ubicación geográfica del cliente o del material, etc.9 iii) Cohesión: Cuando la dinámica de las empresas exige hoy en día un continuo cambio de sus aplicativos para ir evolucionando en la dirección de su plataforma ideal, con cada cambio todas las aplicaciones integradas se ven afectadas. Como alternativa a una arquitectura que no da respuestas a la realidad empresarial actual se presenta, una arquitectura en la que se expone un conjunto de proveedores intermedios llamados Servicios del Negocio o Servicios del Negocio. Dichos Servicios del Negocio representan en la plataforma de tecnología el mapa ideal de aplicaciones, los cuales se exponen simples y sencillos de utilizar, escondiendo las complejidades de una realidad redundante (por las duplicidades, cambiantes y disímiles (por las evidentes diferencias entre las implementaciones de mismos conceptos por diferentes sistemas/proveedores). incorpora a la arquitectura una capa adicional de Servicios del Negocio que bien podrían representar Aplicaciones Virtuales en la arquitectura ideal de la empresa. Para muchos especialistas, los servicios expuestos por la plataforma corresponden con servicios compuestos, sin embargo en esas aproximaciones, los servicios compuestos se plantean como complementos de los servicios atómicos provistos directamente por los aplicativos., por el contrario, utiliza la capacidad de las plataformas de integración actuales para creación de servicios compuestos para generar nuevos servicios tanto atómicos como compuestos, pero cumpliendo el rol de Servicios del Negocio. Los elementos principales de una arquitectura son: 1) Aplicaciones: Conjunto de programas de software diseñados y escritos para realizar operaciones especificas, las cuales van a ser 9 Dicha duplicidad funcional no es necesariamente una consecuencia de una plataforma inmadura; condiciones del negocio pueden implicar que dicha duplicidad funcional represente el estado del arte en cuanto a la solución tecnológica. Página 28/103

29 clientes o proveedores de la plataforma de integración. Es importante resaltar que una misma aplicación puede ser cliente en algunos casos y en otro proveedor. 2) Especificación de Servicios del Negocio (BSI10): Define la sintaxis y semántica de cada uno de los servicios corporativos de la Arquitectura. Idealmente son estándares, sin embargo aún cuando no lo sean provee las características distintivas de sobre SOA. 3) Plataforma de integración: Es una plataforma que soportada sobre mecanismos de alta disponibilidad, transaccionalidad y seguridad provee funcionalidades poderosas de alto nivel de conectividad, adaptación (mapeo) y coreografía para exponer servicios definidos por la Especificación de Servicios del Negocio componiendo aplicaciones Proveedoras. Figura 10 Cuarta generación de EAI: Al ver la Figura 10 se puede observar en el centro los servicios corporativos expuestos por la plataforma, los cuales son consumidos por las aplicaciones; adicionalmente las aplicaciones exponen servicios proveedores que son utilizados por la plataforma para exponer los corporativos. 10 BSI (del inglés Corporate Service Interface): Es la especificación o contratos de los servicios corporativos. Página 29/103

30 5.2 Beneficios de La implantación del modelo en la práctica de integración corporativa provee a la empresa y en particular a la unidad de Tecnología una gran variedad de beneficios que al ser propios de su diseño arquitectural no son logrados de otra manera. Si bien a continuación se presentan con precisión los beneficios de implantar el modelo, en general todo converge en una verdadera agilidad en la provisión de servicios para nuevos desarrollos que permitan a la organización de Tecnología responder a la dinámica demanda del negocio. 1. Desacopla los procesos del negocio de la plataforma de tecnologías de información; de esta manera ambos, tanto los procesos como la plataforma evolucionan de manera independiente, pudiendo el negocio evolucionar sus procesos con menos dependencia de las unidades de TI, y las unidades de TI evolucionar sus plataformas con un menor impacto en los procesos del negocio. 2. Expone de manera simple todos los datos y lógica del negocio presentes a lo largo de toda la infraestructura de tecnología. Esto lo hace exponiendo los servicios corporativos con las siguientes características: a. Especificaciones conocidas, sin necesidad de aprender semántica y sintaxis específicas de las aplicaciones existentes o por llegar. b. Ausencia de complejidad por solapamientos o duplicidad funcional; en otras palabras, expone una plataforma en la que para una función nunca hay dos aplicaciones que hagan lo mismo. c. Sin la heterogeneidad tecnológica típica de los ambientes empresariales, debido a que esto también es escondido por. En otras palabras, todos los servicios y datos accesibles a través de la misma tecnología. 3. Reduce de manera importante los costos en riesgo, tiempo y dinero de integración de nuevas aplicaciones debido a la sencillez que expone la plataforma a las nuevas aplicaciones. 4. Elimina la duplicidad de esfuerzos para lograr el mismo resultado al tener disponible de manera muy sencilla la lógica y datos existentes en la plataforma tecnológica. Página 30/103

31 5. Elimina los impactos de un cambio de aplicación en las otras aplicaciones. Al estar las aplicaciones encapsuladas, cuando una es cambiada ninguna de las aplicaciones que son clientes de ella requieren ser tocadas. 6. Simplifica los procesos de migración de aplicaciones por partes. La migración del uso de una aplicación vieja por una nueva es controlada por la plataforma por lo que los procesos de Pase a producción gradual pueden ser llevados a cabo de manera transparente al resto de las aplicaciones respecto a la que es sustituida y la que sustituye. 7. Provee a la empresa de la infraestructura modelada como Nivel 3 del modelo de madurez NGITP de Gurulab. En el contexto del modelo referencial NGITP de Gurulab, representa un mecanismo para lograr el establecimiento de una Plataforma de Tecnología de Información de Nueva Generación nivel 3. Nivel de Madurez c1 c2 ci SmartInterface p1 p2 p3 S1 S2 pj S3 Process Manager Sm Bus App 1 App SmartInterface 4 - BPM 3- Servicios Corporativos 2 - EAI App n 1 - Silos NGITP Maturity Model Figura 11 en NGITP 8. Maximiza el uso de manera eficiente de la plataforma tecnológica de integración a nivel corporativo, debido a que provee un Modelo Tecnológico que indica claramente como utilizar cada componente para tal fin. Página 31/103

32 9. Provee un control de la evolución tecnológica de la arquitectura que tradicionalmente las unidades de Tecnología no tienen. La plataforma de integración puede controlar todos los procesos de pase a producción alineándose perfectamente con las prácticas de ITIL y BPM Como ya se ha dicho anteriormente, desacopla los procesos del negocio de la plataforma de tecnologías de información; esto exponiendo un conjunto de servicios corporativos que están disponibles tanto a las herramientas de modelaje y análisis de procesos, como al motor de ejecución. De la misma manera como Protege las integraciones con aplicaciones cuando una de ellas es cambiada, protege los procesos de los cambios de aplicaciones. 11 ITIL (del inglés IT Infrastructure Library): es un modelo de referencia operacional para servicios de TI. Página 32/103

33 Dado que los procesos consumen servicios corporativos, y éstos no cambian sino las aplicaciones que encapsula, ningún cambio de aplicaciones de la pataforma de TI afecta la ejecución de procesos implementada sobre la capa de BPM. 5.4 Elementos claves de una implementación exitosa de Asumiendo como premisa la intención de utilizar el concepto de para implementar una plataforma de integración orientada a servicios (EAI basada en SOA), para su exitosa implementación es necesario contar con cuatro (4) elementos muy importantes: Buena Especificación de Servicios del Negocio (BSI) Plataforma flexible Metodología pragmática de implementación Equipo de integración En los siguientes capítulos se verán en detalle cada uno de estos temas con el fin de proveer al lector de los criterios suficientes para proveerse de dichos componentes y asegurar un exitoso proyecto. La aproximación que este libro tiene a cada uno de estos elementos claves es de manera estructural, es decir, independiente de estándar, tecnología o proveedor. En el sitio web además estar disponible este documento están disponibles registros de experiencias que se han tenido con tecnologías, estándares y proveedores específicos; de esta manera usted posee tanto los criterios como las referencias para tomar sus propias decisiones respecto a cómo considera más conveniente llevar a cabo una implementación de un EAI basado en SOA. Página 33/103

34 6 Especificación de Servicios del Negocio (BSI) La importancia de la Especificación de Servicios del Negocio (BSI) se fundamenta en que en la medida que sea definida con suficiente calidad (generalidad, flexibilidad, etc.) la implementación podrá realmente lograr la promesa respecto a que un cambio en un aplicativo de la arquitectura no impacte en ningún otro aplicativo o en los procesos del negocio soportados por. En la medida que la BSI sea de mayor calidad, menor impacto tendrá el cambio de un elemento de la plataforma de TI en otros y los procesos del negocio; es por esto que es importante conocer las características que se deben asegurar a la hora de generar una especificación de este tipo. Este capítulo le presentará los criterios que le permitirán asegurar que la BSI que usted utilice tenga la mejor calidad posible y por ende garantizar el éxito de la promesa de su Plataforma de Integración basada en una Arquitectura Orientada a Servicios. Adicionalmente, también se presentarán los estándares de industria conocidos por Gurulab que presentan especificaciones que pueden ser utilizados como BSI. Estos estándares aseguran de manera razonable que el BSI basado en ellos es de muy buena calidad. La calidad de su BSI es fundamental para asegurar las premisas que usted puede utilizar en la justificación del caso de negocio que sustente su proyecto de implantación de. En la medida que su BSI tenga mayor calidad, menor riesgo tendrá la cuotaparte de su caso de negocio relacionado con los ahorros por eliminación de impactos por evolución de la plataforma tecnológica. 6.1 Calidad de la BSI Para poder definir claramente qué es la Calidad de una BSI y cómo se consigue, es necesario definir previamente los siguientes conceptos: Página 34/103

35 Composición de Funcionalidades Se dice que una funcionalidad es Compuesta cuando ésta puede expresarse en función de la ejecución de otras funcionalidades diferentes a ella. Derivación Funcional Se dice que una función F es derivable cuando existe un conjunto de funciones Fi diferentes de F tales que F es la composición de las Fi. Funcionalidad Atómica Se dice que una funcionalidad F0 es atómica si y sólo si no existen otras n funcionalidades F1, F2,..., Fn diferentes a partir de las cuales se puede derivar F1. Subconjunto Funcional Se dice que una funcionalidad F1 es subconjunto funcional de una funcionalidad F2 sí y sólo si la F2 es derivable a partir de un conjunto de funcionalidades entre las cuales se encuentra F1. Toda funcionalidad es subconjunto funcional de si misma. Funcionalidades Ortogonales Se dice que dos funcionalidades F1 y F2 son ortogonales si y sólo si no existe una funcionalidad F3 tal que F3 es subconjunto de F1 y F3 es subconjunto de F2. Corolario Dos funcionalidades son no ortogonales si alguna de ellas es subconjunto funcional de la otra. Calidad de una BSI La calidad de una BSI es directamente proporcional a su capacidad de absorber, sin modificación en su API, nuevas funcionalidades no ortogonales respecto a las existentes, o nuevos rasgos en los datos del negocio Fenómeno del Cernido Entendiéndose por especificación de grano fino a una basada en funcionalidades atómicas, y por una de grano grueso a una basada en funcionalidades compuestas (no atómicas), se define como el fenómeno del Página 35/103

36 cernido a la situación que se presenta cuando a un proceso del negocio o aplicativo de la plataforma de TI, teniendo la expectativa de consumir servicios grano grueso, se le presenta un conjunto de servicios del negocio basado en una especificación de grano fino. Para entender este fenómeno, es posible hacer referencia a una metáfora diferente a la de las especificaciones de servicios del negocio como por ejemplo la complejidad lexicográfica de los idiomas Inglés (o Español) y Japonés. Para expresar una idea en idioma Inglés (o Español), es necesario muchas menos construcciones lexicográficas (palabras) que las necesarias en el idioma Japonés. Esto es claramente evidenciado por la gran dificultar que tiene la industria cinematográfica para sincronizar las traducciones de una película Japonesa en el Inglés (o Español). La cineasta Sofía Coppola atrapó de manera graciosa esta situación en su película Lost in Translation en las primeras escenas cuando el personaje principal (interpretado por Bill Murray) se encuentra en Japón para grabar un comercial para un Whiskey; en la escena el director japonés le indica en japonés al personaje actor una serie de instrucciones durante 26 segundos (contados por reloj) para luego escuchar a la traductora el significado en inglés con unas instrucciones que le tomó 2 segundos. En la foto, el actor escucha atentamente a la traductora mientras observa al director quien espera que finalice la traducción; luego de escuchar la traducción de 2 segundos repondió: Eso es todo? Me pareció que él dijo algo más que eso! (En inglés Is that everything? It seemed like he said quite a bit more than that. ). Página 36/103

37 Entre el Inglés y el Japonés existe el fenómeno del cernido, en donde el Inglés es de grano grueso y el Japonés de grano fino. De aquí se desprende fácilmente que el tamaño del grano habla de la expresividad de sus palabras, y en el caso de las especificaciones de servicios del negocio el grano corresponde a la expresividad de su API Criterios para generar una BSI de buena calidad Con el fin de lograr una especificación de servicios del negocio de buena calidad, es importante que el arquitecto de la especificación tome en cuenta una serie de consideraciones las cuales se resumen en los siguientes preceptos: La BSI debe diseñarse pensando en un sistema ideal de referencia. Dicho sistema de referencia puede estar expresando en términos de documentación formal, o en función de la visión de un experto o especialista. En la medida que el experto o especialista es representado por el arquitecto de la BSI, mejor será la expresión de dicha visión en la BSI. Las especificaciones de los servicios del negocio deben ser de grano fino, aún cuando los procesos o aplicaciones que requieren consumirlos requieran de una especificación de grano grueso, es decir, deben expresarse en función de funcionalidades atómicas independientemente de que esto implique el fenómeno del cernido. Uso de excepciones para manejo de errores Basado fundamentalmente en los siguientes patrones de diseño: Session Façade Pattern Value Object Pattern, Data Transfer Object Factory Pattern, Data Transfer Object Factory Generic Attribute Access Version Number Iterators for Bulk Transfer (Value List Handler) Template-based Queries Generic Named Queries Bulk Operation with Best effort and Atomic Semantics Meta-Data Discovery Los patrones son referencias generales las cuales pueden estar expresadas en términos de lenguajes específicos como Java, o pueden estar expresados en términos agnósticos como UML. Como referencia a continuación se presentan fuentes de información de patrones de diseño orientado a objetos: API; del inglés Application Program Interface. Página 37/103

38 El desarrollo de una especificación de servicios del negocio, incluyendo la especificación de datos, es una tarea muy extensa la cual se aconseja ser llevada a cabo por etapas en amplitud y por iteraciones para cubrir profundidad (detalles). A la fecha, junto con mi equipo he tenido ya dos experiencias grandes y contundentes, una entre los años 1997 y 1999, y la segunda entre los años 2003 y 2005; con ambas experiencias hemos aprendido a crear especificaciones de servicios de negocio de muy alta calidad. Los criterios indicados en esta sección corresponden a la documentación de las lecciones aprendidas a lo largo de los proyectos de ejecución de. Detalle de estos criterios, o estrategias prácticas respecto a cómo llevarlo a cabo se encontrarán documentados en próximas entregas de este libro, o en el talleres especializados dictados por Gurulab. 6.2 Herencia funcional Debido a la dinámica de la integración de aplicaciones empresariales, la plataforma de servicios del negocio se verá afectada para cumplir con los constantes cambios y nuevas necesidades. Los cambios que puede sufrir la BSI pueden clasificarse de dos tipo: Agregación de funcionalidades ortogonales. Agregación de funcionalidades no ortogonales. Es de esperar en un ambiente ideal que los sistemas y procesos que consumen servicios del negocio hereden las nuevas funcionalidades de la plataforma sin necesidad de ser modificados. Esta expectativa es alcanzable a través de una BSI de alta calidad ante modificaciones de la plataforma que agreguen nuevas funcionalidades no ortogonales. Para que la plataforma provea esa herencia ante agregaciones de funcionalidades ortogonales, la BSI debe ser definida basado en un conocimiento de expectativas funcionales a futuro, más que de una práctica de especificación con calidad. En otras palabras, en RUNTIME, si uno agrega nuevas funcionalidades noortogonales, y la BSI es de buena calidad, los procesos y sistemas que consuman de la BSI heredarán las nuevas funcionalidades sin necesitar de cambiar código en los consumidores. Por ejemplo, en un momento dado un CRM basado en el hecho de que el sistema de Gestión de Ordenes no permite la selección de una característica particular del producto o servicio a vender, simplemente asume la característica default. Si el CRM está integrado al Servicio de Negocio de Gestión de Ordenes a través de una BSI de alta calidad, en el momento que el Gestor de Ordenes provea la funcionalidad de elección de la característica particular a la que hacemos referencia en este ejemplo, el CRM heredaría la Página 38/103

39 nueva funcionalidad y en el acto, sin la necesidad de ser modificado, empieza a ofrecer la opción de selección de la característica particular. A continuación veremos cada una de estos dos tipos: Agregación de funcionalidades ortogonales En el escenario de agregación de nuevas funcionalidades ortogonales respecto a las existentes en la BSI, los procesos y aplicativos que consuman de la BSI serán afectados en la medida que se requiera que éstos los aprovechen. La agregación podrá ser implementada a través de la incorporación de nuevos servicios o incluso con la evolución de los servicios existentes en nuevas versiones; si bien el último caso es poco probable en el escenario de nuevas funcionalidades ortogonales, si ocurre y afecta servicios que están siendo utilizados, pueden ser expuestos ambas versiones simultáneamente. La publicación de dos versiones de un mismo servicio es una práctica que debe llevarse a cabo de manera cuidadosa. Si bien permite en las circunstancias indicadas en esta sección evitar el impacto de la evolución de la BSI en los sistemas y procesos que consumen servicios del negocio, es un foco de redundancia y complejidad de mantenimiento. La convivencia de varias versiones de un mismo servicio debe ser manejada a través de la ejecución de una adecuada gestión del ciclo de vida de los servicios. Adicionalmente, deben considerarse políticas de mantenimiento de la plataforma que permitan desincorporar versiones viejas de servicios generando proyectos de actualización tecnológica a nivel de los consumidores de esos servicios a desincorporar. Es importante entender que si bien ante el proceso de actualización tecnológica indicado en el párrafo anterior hay un impacto a nivel de las aplicaciones y procesos usuarios de los servicios del negocio, éste impacto no ocurre por cambios en la plataforma, sino por procesos de mantenimiento que pueden ser implementados en periodicidades bianuales y sin ningún tipo de restricciones respecto a otros proyectos Agregación de funcionalidades no ortogonales Cuando la BSI es afectada por la incorporación de nuevas funcionalidades no ortogonales a las existentes en la BSI, el impacto dependerá de la calidad de la BSI. En la medida que la BSI sea de mayor calidad, menor la cantidad de cambios en los procesos o sistemas consumidores, aun disfrutando de las nuevas funcionalidades incorporadas en la plataforma a través de la Herencia que les confiere. Página 39/103

40 6.3 Especificaciones estándares de industria A continuación se presentan los casos particulares para los cuales cuenta con valores agregados. El que una industria no esté enunciada en este capítulo no implica que no pueda utilizar, sino que para el momento de la publicación de este documento, Gurulab no poseía información de artefactos estándares que faciliten el trabajo de implementación Telecomunicaciones TeleManagement Forum ( es para las TI de la industria de Telecomunicaciones, los que la ITU es para las redes de la misma industria, o la ISO para cualquier industria.; agrupa un conjunto de artefactos estándares y mejores prácticas que permiten lograr una plataforma tecnológica de operaciones de nueva generación. El planteamiento fundamental de TMForum es el logro de la plataforma de operación de nueva generación de una Telco; dicho planteamiento se encuentra en la forma de una colección de especificaciones llamada NGOSS y la especificación de interfaces estándares en las tecnologías Webservices, XML y Java llamada OSS/J. En el contexto de, el gran valor que estas especificaciones aportan es que la Especificación de Servicios del Negocio que requiere es fundamentalmente la implementación de NGOSS (etom, SID, TAM, MTOSI, OSS/J) en la tecnología requerida por la plataforma (Webservices, Java, CORBA, etc.). En particular, OSS/J provee las especificaciones requeridas para Servicios Web, tecnología utilizada ampliamente en la actualidad. Página 40/103

41 Figura 12 Representación gráfica de NGOSS de TMForum A continuación se presentan los artefactos del TMForum que son relevantes para etom etom, componente del marco de referencia NGOSS del TMForum, es un marco referencial de procesos de una empresa de telecomunicaciones. Este marco referencial clasifica todos los procesos hasta un nivel de detalle casi de la especificación de tareas específicas. Sirve inicialmente como referencia estándar a la hora de nombrar los procesos o partes de ellos (subprocesos). Para ello enumera una cantidad de procesos clasificados en varias dimensiones según se muestra en la Figura 13. Página 41/103

42 Figura 13 Representación gráfica de etom; componente de NGOSS del TMForum El modelo etom brinda un catálogo completo de los procesos de una telco y puede ser utilizado como modelo referencial a partir del cual se realiza el modelaje de los procesos a implementar TAM El Telecom Operations Map representa un catálogo que identifica y clasifica el conjunto de Componentes Funcionales de una empresa de Telecomunicaciones. A continuación se presenta la figura que muestra la clasificación actual. Página 42/103

43 Este estándar presenta lo que llama las aplicaciones ideales o plicaciones virtuales ; es por esto que sus elementos representan componentes de agrupación de los servicios de negocio implementados en su ESB SID Siendo también elemento de NGOSS del TMForum, SID es un modelo canónico de datos, agnóstico de tecnología, representado en modelos UML. La Figura 14 muestra los dominios de SID que clasifican todas las clases (modelo orientado a objetos) que representan el estándar. Página 43/103

44 Figura 14 Representación gráfica de SID; elemento de NGOSS del TMForum El grupo técnico encargado de la evolución de este modelo está constantemente extendiéndolo para cubrir los dominios en donde hay brechas en la especificación. En la medida que una empresa desea utilizar este modelo puede hacerlo utilizando los lineamientos de extensión para asegurar que todas las consideraciones arquitecturales del modelo sean preservadas. Este modelo es la mejor referencia inicial a partir de la cual se puede trabajar para desarrollar los datos de la especificación de servicios corporativos de una arquitectura de integración. La mejor manera de implementar SID en su modelo de Servicios del Negocio es implementando OSS/J y extendiendo OSS/J (ver más adelante). Basado en la experiencia adquirida en el proyecto de integración en CANTV, recomiendo de manera enfática que de trabajar con este modelo y requerir su extensión, hágalo trabajando de manera muy cercana al equipo de desarrollo; de esta manera usted asegura que el producto resultante de su trabajo se convierta en el estándar y así evitar que el SID evolucione en una dirección diferente quedando usted con su versión específica desactualizados MTOSI Al igual que etom y el SID, MTOSI es una especificación agnóstica de tecnología que define las interfaces entre elementos de la plataforma operativa de una telco. En particular representa la especificación que Página 44/103

45 requiere de manera concreta y específicamente en la tecnología que sea utilizada para su implementación. Dado que MTOSI es un artefacto relativamente nuevo no cubre de manera relevante los componentes de la arquitectura que se requiere especificar OSS/J Originalmente una iniciativa independiente del TMForum, fue desarrollando a lo lardo del tiempo una implementación concreta del SID y de interfaces de servicios (lo que MTOSI busca lograr) para aplicaciones concretas como Gestor de Problemas (Trouble Ticket), Inventario, Gestor de Ordenes de Servicio, Facturador, etc. Desde el 1 de Julio del 2006 es un capítulo oficial del TMForum y además de ser accesible a través de la página oficial del TMForum ( es accesible a través de su URL propio Hoy en día mantiene las especificaciones en Weservices, XML y Java de los APIs que se listan a continuación: JSR # OSS/J API Status Maintenance Release () OSS Quality of Final Release Service (v1.0) Final Release OSS Trouble Ticket (v1.0) Maintenance OSS Billing Mediation Release () Final Release OSS Inventory (v1.0) Maintenance OSS Common Release 3 (v1.3) OSS Service Quality Early Draft Review Management OSS Service Activation 251 Pricing 254 OSS Discovery Spec Lead & Company Java.net Andreas Ebbert Nokia Corporation Srinivasa Samudrala Motorola Axel Terfloth IP Value Tulika Pradhan Infozech public Software Limited Pierre Gauthier public MetaSolv Software Vincent Perrot Sun Microsystems public Thierry Supplisson Vallent John Wilmes Early Draft Review Ceon Corporation Andrew Paterson Public Draft Review Nakina Systems public public Página 45/103

46 JSR # OSS/J API 263 Fault Management 264 Order Management 285 Performance Management Spec Lead & Company David Raymer Early Draft Review Motorola Andreas Ebbert Public Draft Review Nokia Corporation David Raymer Expert Group Motorola Status Java.net public public Las especificaciones generadas por OSS/J son gestionadas a través de la Java Community Process ( aún cuando incorpora especificaciones de Webservices y XML. Igualmente son publicadas a través de la comunidad java.net ( En la siguiente figura (Figura 15) se muestra el mapeo de las especificaciones de OSS/J con etom. Figura 15 Mapa visual que muestra cómo OSS/J cubre los dominio de proceso etom Página 46/103

47 En la Figura 16 se muestra el mapeo de las especificaciones de OSS/J con el modelo SID de NGOSS y en la Figura 17 las dependencias entre las principales entidades de OSS/J. Figura 16 Mapeo de las especificaciones de OSS/J con SID de TMForum Página 47/103

48 Figura 17 Dependencias entre las especificaciones fundamentales de OSS/J Mayor información sobre el plan de desarrollo de OSS/J puede ser obtenida directamente de la documentación del mapa de ruta en Las especificaciones de OSS/J además de incluir las especificaciones de API, incluyen una implementación del SID, por lo que la adopción de OSS/J como especificación de Servicios del Negocio implica el uso del SID, es decir, adopción de mejores prácticas de la industria de Telecomunicaciones y el uso de una BSI de alta calidad, probada por varios operadores a nivel mundial. 6.4 Otras industrias Para el momento de la publicación de este documento no se tiene conocimiento de frameworks o propuestas de estandarización de especificaciones de interfaces entre aplicaciones para otras industrias además de las indicadas en esta sección 6 Especificación de Servicios del Negocio (BSI). Sin embargo, así como hemos evaluado que la propuesta de TMForum para la industria de Telecomunicaciones puede ser aplicada para la industria de Banca con unas pequeñas modificaciones, podría evaluarse para resolver otras ; es previsible que dicha extrapolación funcione muy bien al menos en los dominios independiente de industria como Contabilidad, RRHH, Facturación, CRM, etc. Página 48/103

49 Página 49/103

50 7 Aspectos técnicos 7.1 Anatomía de la Plataforma de Integración Como premisa fundamental de se tiene que es posible implementarlo sobre cualquier plataforma tecnológica que la empresa tenga. Ya sea que utilice herramientas de alto nivel como productos especializados para integración basado en SOA, o utilice un simple compilador de su lenguaje de preferencia y un editor del código fuente. Independientemente de la herramienta que utilice, y de su esquema de licenciamiento (sea software propietario, software abierto o software libre), a continuación se presenta una descripción anatómica de los elementos que la plataforma que usted va a utilizar para implementar debe tener. Es importante resaltar que esta descripción es lo suficientemente abierta para que cualquier plataforma pueda ser descrita, lo importante es que usted pueda detectar claramente cuál componente de la plataforma corresponde a cuál elemento de este modelo tecnológico de referencia. Teniendo en mente el modelo de referencia tecnológica de en vez del modelo arquitectural de la plataforma provista por el fabricante, usted tendrá los siguientes beneficios: Desacoplamiento del proyecto de implementación de la plataforma utilizada. De esta manera, si en algún momento usted se topa con alguna limitación de la plataforma de integración, fácilmente podrá incorporar nuevos elementos que completen su arquitectura referencial y así lograr los objetivos fundamentales de la implementación aquí descrita. Aseguramiento de un lenguaje común independiente de un fabricante específico de tecnología de integración. De esta manera le será mucho más fácil comunicarse con cualquier especialista, además del propio proveedor de la tecnología que usted utilice. Le provee el esqueleto a armar en caso de decidir implementar su proyecto utilizando elementos de Software Libre o Software abierto seleccionando las mejores implementaciones que cubran mejor las funcionalidades que usted necesite y valore más. A continuación se presenta la radiografía de la arquitectura referencial de la tecnología a utilizar en dos niveles de detalle diferentes. El primer nivel muestra la menor cantidad de elementos para entender la plataforma. El nivel Página 50/103

51 2 explota cada uno de los elementos presentando un mayor detalle que permita entender mejor la arquitectura desde el punto de vista físico. Aclaratoria Importante Es muy importante resaltar que a lo largo de este documento nunca se utiliza la expresión Adaptador como sustantivo (si es utilizado como verbo: adaptación ); esto es debido a que se quiere evitar la confusión que se genera con los proveedores de conectores en el mercado. En general los proveedores de conectores resaltan la gran cantidad de atributos de sus conectores como por ejemplo la capacidad de hacer Adaptaciones, por lo que les llaman Adaptadores y no Conectores. En este documento les llamamos Conectores y no Adaptadores para hacer énfasis en que a ese nivel NO DEBE OCURRIR ADAPTACIÓN ALGUNA. Le recomiendo que usted siga esta práctica y nunca llame Adaptador a los Conectores, aún cuando la pieza de software sea un Adaptador; en otras palabras, llámelo por su nombre común Conector y no por su nombre propio Adaptador. De esta manera asegura que nunca su gente confundirá sus palabras y asumirá que tiene la intención de realizar funciones de Adaptación a nivel de los Conectores. Algunos autores/proveedores hacen énfasis en este modo de uso de los conectores llamándolos redundantemente Conectores livianos Nivel 1 Tal como se muestra en la Figura 18, la arquitectura de la plataforma de integración tiene dos elementos fundamentales: i) la plataforma (mostrado en el centro de la figura) y ii) las aplicaciones (satélites a la plataforma). Página 51/103

52 Figura 18 Nivel 1 - Arquitectura de la plataforma tecnológica de integración Los aplicativos son los elementos de Software tal como lo conocemos, sin embargo, destacamos de ellos los que denominaremos el Canal. El Canal es la colección de recursos de una aplicación específica que se encuentran disponible para los objetivos de integración. Como ejemplo de estos recursos se encuentran: Transacciones CICS Procedimientos Almacenados en un DBMS Dataschema e instancia de un DBMS Archivo plano Procedimientos disponibles en librerías Agentes de RPC estándares (SunRPC según RFC 1057, DCOM de Microsoft, CORBA, Servicios Web, etc.) o propietarios (SAP RFC, SAP BAPIS, etc.) La plataforma es un agente que está compuesta a nivel macro por tres capas: capa de conexión, capa de adaptación y núcleo. La primera de las capas es la de Conexión, en la cual se encuentran los elementos necesarios para vincular las aplicaciones con la plataforma, en particular contiene a los Conectores y los Proxy. Los Conectores son los responsables de resolver cualquier dificultad tecnológica para acceder al Canal Página 52/103

53 de las aplicaciones; éstos exponen dentro de la plataforma tantos Proxys como Canales se quiera integrar, siendo los Proxys representaciones en la plataforma de los Canales de las aplicaciones. A esta altura, gracias a los Conectores hacer uso de los servicios representados en los Proxy implica hacer uso de los servicios implícitos en los canales de la aplicaciones. En el centro de la plataforma se encuentra el Núcleo; en dicha capa viven los Servicios del Negocio, los cuales son construidos como una secuencia de llamadas a los Proxys. Dichas llamadas atraviesan la capa de Adaptación, sufriendo las transformaciones requeridas para que los objetos que son manejados a nivel de la interfaz de los Servicios del Negocio sean transformados a los objetos manejados a nivel de la interfaz de los Proxys; esto último es llamado también mapeo. Adicionalmente en la capa de Adaptación viven los Servicios Específicos de Aplicación, los cuales al ser opcionales, pueden proveer la adaptación que pudiese requerir una aplicación Cliente para poder hacer uso de un Servicio Corporativo. También se dice que estos Servicios específicos implementan la adaptación de la lógica. En los Servicios del Negocio que viven en el núcleo de la plataforma es donde ocurre la abstracción de las aplicaciones subyacentes; aquí es donde se implementa la lógica y criterios que son utilizados para exponer el servicios de una aplicación ideal basada en la cruda y compleja realidad subyacente. Por ejemplo, si en la realidad se tienen tres aplicaciones diferentes para manejar los Recursos Humanos, es en estos Servicios del Negocio donde se expone un (1) solo servicio de Recursos Humanos (como si fuera una sola aplicación); allí se está implementada la lógica y criterios de enrutamiento para que cada llamada al servicio corporativo se convierta en las llamadas que sean necesarias a las tres aplicaciones subyacentes. En particular, suponiendo que las tres aplicaciones de RRHH estén manejando cada una un grupo de Empleados diferente, el servicio se comunica con la aplicación adecuada basada en cuál aplicación maneja el empleado para el cual debe atender los servicios de RRHH Nivel 2 Explotando la figura de la plataforma nivel 1, se tiene el nivel 2 el cual se muestra en la Figura 19. La diferencia fundamental entre los dos niveles está en la diferenciación de sub-capas. Página 53/103

54 Figura 19 Nivel 2 - Arquitectura de la plataforma tecnológica de integración Para el caso de la capa de Conexión, se muestran las dos subcapas Conexión.Proxies y Conexión.Conectores. La Figura 19 muestra una separación física que puede existir entre estas capas, viviendo en este caso los proxys en los límites de la plataforma. La capa de Adaptación se separa en dos subcapas, aquella donde viven las adaptaciones y aquella donde ocurre el Mapeo Plataforma ideal Idealmente, una plataforma que implemente esta arquitectura referencial utilizaría dos conceptos que considero clave para tener una plataforma de integración más ágil: La lógica de los servicios, ya sean a nivel de adaptaciones o Servicios del Negocio, debe ser una herramienta visual o metalenguaje que abstraiga la noción de la morfología de los datos. Los mapeos se definen entre pares de Objetos sin necesidad de hacer una vinculación explicita en la lógica de los servicios. Página 54/103

55 La ejecución de la lógica de servicios indicada de primero, al pasar por la capa de Adaptación.mapeos, de manera implícita ejecute los mapeos indicados anteriormente de manera automática logrando así la satisfacción de los contratos cuya lógica de integración está encarando. 7.2 Desarrollo de conectores Los conectores poseen la funcionalidad de habilitar la comunicación entre dos ambientes tecnológicos dispares, sin embargo, aquellos provistos por 3ros (fabricantes) poseen adicionalmente capacidades de adaptación; estas capacidades de adaptación son las de realizar transformaciones semánticas en las estructuras intercambiadas. Es por esto que los fabricantes llaman Adaptadores a sus conectores. Para tener un conector funcionando, basta con proveerse de uno ya sea construido en casa o tecnología de 3ros, cumpliendo las características técnicas del mismo, y luego configurarle las semánticas que se desean exponer al ESB, o características funcionales Características técnicas El conector es una pieza compleja en si misma, tanto como lo es el ESB, y debido a su naturaleza de uso, de manera general los proveedores de tecnología de integración además de proveer el ESB, también proveen tecnología de conexión. Como ya hemos visto en este libro, plantea hacer uso únicamente de las funcionalidades de Conexión de estas tecnologías, delegando al ESB las funciones de Adaptación. Es por esto que en el planteamiento de, se hace referencia a Conectores (cosas) y a Adaptación (función, que es llevada a cabo en el ESB), y nunca se hace referencia a Adaptadores. Adicionalmente a las funciones ya mencionadas, los Conectores cumplen con las siguientes características: Mecanismos de compensación: el conector debe permitir establecer sesiones y ejecutar transacciones proveyendo un mecanismo para la compensación o rollback según lo que permita el aplicativo que conecta. Notificación de eventos como servicio de suscripción en tiempo de ejecución: generando las listas de suscripción como un elemento dinámico y no compilado en el conector o la aplicación Implementación completa los cuatro (4) contratos fundamentales: a saber: Página 55/103

56 Ciclo de vida: todo conector debe implementar mecanismos que permitan las acciones de inicializar, comenzar, detener, recargar, terminar (init, start, stop, reset & finalize) Seguridad: Para asegurar la identificación y autenticación del cliente y cifrado de la comunicación. Transaccionalidad: asegurando la atomicidad de la transacción, capacidad de participación en una transacción distribuida implementando algún esquema de TWO PHASE COMMIT preferiblemente compatible con el estándar XA. Funcionalidad: A través del cual se acceden al contrato funcional que ofrece el conector. Aseguramiento de las representaciones binarias: el conector es responsable de asegurar las representaciones binarias, utilizando diversas herramientas tales como uso de referencia de codificación como UNICODE, y cambios de representaciones BIG INDIAN y LITTLE INDIAN. Alta Disponibilidad: medida en un número de 9's13 que debe ser definido siguiendo los estándares de la empresa, garantizando que el conector tenga al menos el mismo nivel de disponibilidad de la plataforma del ESB. Generalmente se espera que al menos tenga 99,9% de disponibilidad. Interfaz de gestión SNMP: el protocolo simple de administración de red ( SNMP por sus siglas en inglés ) permite supervisar el desempeño, identificar y resolver problemas utilizando mensajes a nivel de capa de aplicación, las consolas de administración SNMP son estándares y por medio de este se puede mantener una coordinación centralizada de los mismos y su estado. Eficiencia y Gestión: acordes con la plataforma, el uso apropiado de los recursos tanto de memoria, cpu y disco del conector así como su capacidad de administración tanto remota como local debe seguir los mismos principios establecidos para el ESB. Integración estándar con el ESB: utilizando el protocolo estándar JCA (o implementación de JCA en WS) o propietarios específicos para el ESB a utilizar. En caso de que no sea posible, al menos utilizar WS/JMS como mecanismo de transporte. El uso de JMS como transporte es para asegurar la persistencia de la transacción. La forma para medir la disponibilidad de un sistema es a través del cálculo del porcentaje de tiempo activa en un período de un año, este cálculo se hace dividiendo el número total de minutos de actividad por el total de minutos en el año ( aprox ), el resultado se expresa comúnmente por el número de 9's seguidos que la expresión resultante tiene, así por ej ,9% = 525,6 minutos de inactividad / año, 43.8 minutos de inactividad / mes, es llamado tres nueves ( tres 9's ) 2. 99,99% = 52,5 minutos de inactividad / año, 4,38 minutos de inactividad / mes, es llamado cuatro nueves ( cuatro 9's ) 3. 99,999% = 5,25 minutos de inactividad / año, 0,44 minutos de inactividad / mes, es llamado cinco nueves ( cinco 9's ) 13 Página 56/103

57 Interfaz de comando POSIX: los comandos de sistema utilizados para trabajar con el conector deben estar basados en el estándar de Interfaz de Sistema Operativo Portátil basado en UNIX (POSIX por sus siglas en inglés) o en una versión estándar sucesora. Debido al gran costo y tiempo que representa desarrollar un conector que incorpore todas estas consideraciones, las organizaciones consiguen en la adquisición de tecnologías de conexión provistas por 3ros una alternativa de menor costo y menor tiempo de implementación. En general, los fabricantes proveen junto con su ESB una lista pequeña de conectores fundamentales; es relevante que a esa lista inicial se le incorporen los conectores adicionales requeridos para integrar todas las plataformas de su ambiente. A modo de referencia, un fabricante especializado en conectores que provee los conectores a prácticamente todos los ESB del mercado es la empresa iway ( Características funcionales Encapsulamiento, ocultando las decisiones de diseño interno de cada módulo del resto. Separación de responsabilidades y responsabilidad única, de forma de que cada módulo del conector tenga una y sólo una responsabilidad y sea claramente distinguible las responsabilidades todos y cada uno de los módulos. No duplicidad, el conector debe evitar repetir la duplicidad de código en sus módulos minimizando el riesgo de inconsistencias y aumentando la mantenibilidad de las piezas. Página 57/103

58 No adaptaciones, a pesar de que muchos fabricantes de software generan conectores con capacidades de adaptación éstas no deben ser utilizadas dejando al ESB las responsabilidades de adaptación. 7.3 Implementación de servicios del negocio Página 58/103

59 8 Consideraciones estratégicas A continuación se presentan un conjunto de herramientas estratégicas que le permitirán planificar y ejecutar un proyecto de implementación de. 8.1 Sistema Nervioso Empresarial Si bien usted podría utilizar la aproximación de para proveer servicios de integración de 4ta generación a soluciones de negocio concretas como por ejemplo la implementación de un CRM, es preferible plantearse la implementación de desde una perspectiva corporativa. Al implementar una plataforma corporativa de integración basada en Servicios del Negocio, se está implementando el llamado Sistema Nervioso Empresarial14; esta plataforma provee servicios de integración a todas las iniciativas de integración de la empresa. Los proyectos que consideran pueden tenerla como meta a nivel corporativo, o como una solución de integración para una solución de negocio específica. En el primer caso, el objetivo al final del día es la implementación del Sistema Nervioso Empresarial, lo cual es muy adecuado como práctica de Arquitectura Empresarial. En el segundo caso, si bien el objetivo no es implementar el Sistema Nervioso Empresarial, puede enfocarse de tal manera que represente el primer paso en el plan de implementación corporativa. Para lograr esto, la consideración que debe realizarse es la de incluir al final del sub-proyecto de implementación de para la solución de negocio, las actividades de Pase a Producción de la práctica a las unidades operativas de la organización. El pase a producción debe incorporar las consideraciones estándares de la empresa para esto incluyendo una extensión de capacidad (tiempo y recursos) de la unidad que haya realizado la primera implementación para que acompañe a las unidades operativas por un tiempo prudencial que permita una de dos cosas: 14 Establecimiento de una relación contractual entre el proveedor de servicios de integración y la unidad operativa, basada en una fábrica de integración. Transferencia de tecnología, de manera que la unidad operativa aprehenda la práctica y lograr así el control total de la práctica de integración empresarial. Del inglés ENS, Enterprise Nerve System Página 59/103

60 8.2 Estrategia de implementación Para implementar un Sistema Nervioso Empresarial, la forma más adecuada de llevarlo a cabo es a través de aproximaciones sucesivas. Cada iteración se basa en la provisión de servicios de negocio a proyectos de Soluciones de Negocio. Con cada iteración, va asimilando nuevas aplicaciones de la plataforma de tecnología, hasta llegar a un punto en el cual todas las aplicaciones se encuentran integradas a través de. A continuación se presenta una secuencia de pasos correspondiente a una iteración que muestra como se encapsula una aplicación que ha de ser sustituida, para luego ser sustituida utilizando los beneficios de Ejemplo de una Iteración Inicialmente, la plataforma de tecnología se encuentra completamente integrada a través de cualquier mecanismo no. En la figura se muestra un ambiente de aplicaciones integradas todas entre si a través del modelo punto a punto de primera generación. Cada una de las cuatro aplicaciones implementa una Función particular, la cual está identificada debajo de cada aplicación, desde la Función 1, hasta la Función 4. Figura 20: Situación inicial Página 60/103

61 Como primer paso, se instala el bus de servicios de integración (ESB), se instalan los conectores para cada una de las tecnologías relacionadas con cada una de las aplicaciones relacionadas con la iteración; finalmente se conectan las aplicaciones en el ESB exponiendo dentro del ESB los proxys cada uno de los canales. Figura 21: Paso 1 de la Iteración Como segundo paso, se exponen los Servicios del Negocio (BSI) en la plataforma de servicios, implementando la lógica de integración encapsulando la realidad compleja y exponiendo servicios del negocio simples organizados por Componentes Funcionales. Figura 22: Paso 2 de la Iteración Página 61/103

62 Luego, como paso numero tres (3), se realiza el Encapsulamiento de la aplicación o aplicaciones que van a ser sustituidas; el Encapsulamiento se basa en asegurar que cualquier interacción que ocurre con la aplicación a Encapsular se haga a través de la plataforma de servicios del negocio y nunca directamente. En el ejemplo, será sustituida la aplicación numero tres por lo que todas las demás que interactúan con esta aplicación son modificadas para que consuman los servicios del negocio que proveen las funcionalidades propias de la aplicación numero tres. Figura 23: Paso 3 de la Iteración Note que en la misma figura que muestra el paso tres explicita con una flecha en rojo que las peticiones que reciben los servicios del negocio que expone la función propia de la aplicación tres es (tercer cuadrado dispuesto sobre la plataforma ) son respondidos apalancado sobre la aplicación tres. En el siguiente paso (numero 4), se instala y se conecta al ESB la nueva aplicación que será la sustituta. En el ejemplo aparece la numero cinco, la cual también implementa la misma Función que la aplicación que va a sustituir; evidentemente la nueva aplicación incorporará nuevas funcionalidades o características que no disponía la aplicación tres. Página 62/103

63 Figura 24: Paso 4 de la Iteración Como siguiente paso (paso 5), la plataforma de integración con cada solicitud de los servicios del negocio relacionados con la Función a sustituir emite una copia de la solicitud a la nueva aplicación, con el fin de generar un paralelo. Figura 25: Paso 5 de la Iteración Luego de que puede considerarse como culminado la etapa de paralelo de la nueva aplicación, es posible configurar el Servicio del Negocio para que solo responda con los resultados de la nueva aplicación, entrando oficialmente En Producción. Página 63/103

64 Figura 26: Paso 6 de la Iteración Una vez pasado un tiempo prudencial de estabilidad de la nueva aplicación en producción, la aplicación sustituida puede ser desincorporada (ver Paso 7). Figura 27: Paso 7 de la Iteración 8.3 Enfoque pragmático La dinámica de los proyectos de implementación de soluciones de negocio tiende a ser de bastante presión y tiempos de entrega subdimensionados. Esta situación plantea al equipo técnico responsable de implementar la plataforma el reto de proveer la solución de 4ta generación en tiempos de proyecto a lo más como lo que tomaría implementarlo punto a punto. Página 64/103

65 Si bien podríamos pensar que los tiempos de implementar una integración punto a punto podrían ser comparables con la de integración a través de servicios, en el último caso se requiere como paso preliminar (y no para el de punto a punto) la creación de la especificación de servicios del negocio (BSI), lo cual crea un costo adicional en tiempo que puede generar los siguientes inconvenientes: Especialistas de integración tradicionales podrían atacar su propuesta de EAI basado en SOA con el argumento de mayor costo (al menos por tiempo) para implementar. La implementación de los servicios del negocio podría estar en la ruta crítica de los proyectos de solución de negocio, con lo cual usted estaría asumiendo un riesgo importante desde la perspectiva de gestión de proyecto, y consecuentemente del rendimiento como actor en su entorno empresarial. Con el fin de evitar por completo estas circunstancias, a continuación se presenta el enfoque pragmático de implementación que le permitirá lograr los objetivos de integrando aplicaciones en tiempos de una integración punto a punto. Dado que la actividad que retrasa el proceso de integración respecto a la referencia de punto a punto es la generación del BSI, el enfoque pragmático plantea sacar esa actividad de la ruta crítica, generando una integración que implementa las adaptaciones para cada consumidor en función de los proxy y no en función de los servicios del negocio (core). En la siguiente lámina se muestra como, desde la perspectiva de la anatomía agnóstica de proveedor de, las adaptaciones implementan internamente la lógica de integración directamente contra los proxy. Página 65/103

66 Figura 28: Enfoque pragmático de implementación de - Estado temporal El estado en el que se encuentra la implementación de la solución de integración mostrado en la lámina anterior es temporal; mientras este estado entra en producción, entregando resultados a sus clientes. En paralelo es definida la BSI y los servicios del negocio expuestos y probados para luego modificar las adaptaciones para que hagan uso de los servicios del negocio; entonces, queda la arquitectura interna del ESB como se muestra en la siguiente figura. Página 66/103

67 Figura 29: Enfoque pragmático de implementación de - Estado final 8.4 Modelo de servicio Existen dos formas de implementar un servicio corporativo de integración, la primera a través de un modelo Inflexible y el segundo usando un modelo Flexible. Cada forma define el modelo de servicio que una entidad corporativa puede adoptar. En el primer modelo, llamado Inflexible, las aplicaciones deben adaptarse a los Contratos canónicos que implementan los Servicios del Negocio que viven en la plataforma de integración. Esto implica que el equipo desarrollador, encargado de la realización de cambios en las aplicaciones, debe modificar algunos módulos de las aplicaciones existentes o en su defecto crear módulos nuevos, siempre y cuando existan diferencias entre los contratos de los servicios corporativos y los que cumple la aplicación. Desde la perspectiva del modelo tecnológico de la plataforma de integración, este modelo inflexible implica las aplicaciones consumen directamente los Página 67/103

68 Servicios del Negocio sin necesidad de que la plataforma exponga servicios específicos de aplicación. En el segundo modelo, llamado Flexible, la plataforma de integración no sólo expone los servicios corporativos con su Contrato canónico, sino que expone un servicio a la medida de cada aplicación cliente llamado Adaptación. De esta manera, el aplicativo no debe ser modificado para poder hacer uso de los servicios corporativos. La decisión de implementar alguno de los modelos propuestos anteriormente va a depender fundamentalmente de la cultura organizacional de la empresa. A continuación se presenta un análisis de las diferencias entre ambos modelos que le permitirán decidir cuál se ajusta más a su realidad y por ende representa la mejor opción de valor y sobre todo mayor probabilidad de éxito. Página 68/103

69 9 Recomendaciones de implementación 9.1 Modelaje de procesos Definición Tres definiciones de proceso: Actividad que se lleva a cabo en una serie de etapas para producir un resultado específico o un grupo coherente de resultados específicos, o bien como un grupo de acciones que tienen un propósito común que hace avanzar el negocio en alguna forma. Organización racional de personas, materiales, energía, equipos y procedimientos en actividades concebidas para producir un resultado final específico. Conjunto de pasos que se realizan de forma sucesiva en distintas dependencias, con el objeto de transformar una serie de entradas específicas en una salidas (bienes o servicios) deseadas, añadiendo valor Componentes básicos Qué (Actividades) Página 69/103

70 Quién (Recursos) Cuándo (Tiempo) Dónde (Ubicación) Cómo (Documentos de Entrada, Salida, Métodos manual / automatizado / combinado) Consideraciones No se concibe un proceso sin un objetivo. Las actividades de un proceso deben estar escritas en infinitivo y deben plasmar el fin que se busca. Ejemplo: Verificar la morosidad del cliente. El documento o insumo inicial se convierte en valor agregado. Tienen un principio y un fin: inician con determinada acción o evento y finalizan en otro. Cada paso se ubica en determinado lugar, por eso es importante la secuencia dentro del proceso. Los procesos en la organización se identifican a partir de la norma de constitución de la entidad, quien define sus objetivos, productos o servicios, y funciones. Estos en conjunto con la definición de la misión de la organización, la cual determina el valor agregado de la entidad, formalizan los procesos y subprocesos que debe adelantar el ente gubernamental o empresa, a fin de cumplir con sus objetivos, productos o servicios que le son demandados Actores Cuando se define un proceso es indispensable identificar los actores que participan en cada una de las actividades del mismo, típicamente son los siguientes: Los proveedores: son quienes suministran los materiales y las informaciones requeridas para ejecutar el proceso. Los responsables del proceso o productores: son todos aquellos que aportan su trabajo personal en las diferentes etapas del proceso para Página 70/103

71 lograr que el resultado cumpla con todos los requisitos exigidos por el cliente. Los clientes: Los destinatarios finales del producto o servicio y los que en definitiva juzgan su calidad, en la medida en que satisface sus necesidades y expectativas. La relación cliente-proveedor se produce entre las distintas unidades, grupos de trabajo o personas que intervienen en un proceso. Esto quiere decir que cada una es a la vez un cliente para aquella que la precede en la generación de un producto, y un proveedor para quien la sucede. Cada unidad, grupo de trabajo o persona ha de realizar su labor de forma que cumpla con todos los requisitos que necesita su cliente, para que este último pueda continuar eficazmente con su parte en el proceso. Y así sucesivamente Cómo identificar un proceso? Para identificar un proceso bastaría con adoptar la perspectiva de los clientes como punto de partida, identificando en primer lugar todos los productos o servicios puestos a su disposición y, a continuación, todos los pasos que se realizan para proporcionárselos Aspectos relevantes Si nos detenemos un momento a reflexionar sobre la entidad que vive, se transforma y crece, encontramos que los procesos: Son mutuamente dependientes, ya que ninguno coexiste sin la ayuda o intervención de otro. No existen procesos autónomos, así se trate del más breve o humilde. Se interceptan unos con otros y se retroalimentan en forma permanente. Se agregan valor o se desgastan entre sí. Tienen cabeza o iniciación que son la finalización o cola de otros. Página 71/103

72 Bien ejecutados facilitan la ejecución exitosa de otros Cruzan líneas fronterizas organizacionales, porque usualmente tienen que ver con más de una dependencia de manera directa o indirecta Representación gráfica El diagrama La representación gráfica del proceso, se convierte en un instrumento muy importante para guiar su ejecución en forma ordenada; busca mostrar en forma dinámica y lógica la secuencia del trabajo, permitiendo conocer y comprender el proceso que se describe, a través de los elementos como las actividades, los documentos y las unidades administrativas y cargos que intervienen en él Características El flujograma es una herramienta de representación gráfica de gran importancia para el levantamiento, análisis, diseño, mejoramiento y control de los procesos. Estandariza la representación gráfica de los procesos de trabajo Identifica con facilidad los aspectos más relevantes del trabajo Facilita el análisis y mejoramiento de los procesos, propendiendo por la eliminación de trámites innecesarios, suprimiendo lo que no es esencial y simplificando lo que sí es. Muestra la dinámica del trabajo y los responsables del mismo Facilita la ejecución del trabajo Impide las improvisaciones y sus consecuencias Evita el desvío o distorsión de las prácticas de la empresa Provee elementos que facilitan el control del trabajo Ventajas Describe en forma sencilla el paso a paso de cada proceso y complementa la descripción literal, facilitando su consulta Página 72/103

73 Engloba las acciones realizadas con el propósito de transformar la información de entrada en los resultados esperados Verifica el desarrollo real del proceso y representa objetivamente aquello que ocurre cotidianamente en la rutina normal de trabajo Facilita la comprensión rápida del trabajo Describe cualquier proceso, desde el más simple hasta el más complejo Permite la visualización rápida e integrada de un proceso, facilitando el examen de los pasos, la secuencia y las responsabilidades de los ejecutantes Identifica rápida y fácilmente los puntos débiles y fuertes del proceso Propicia la visualización de la distribución del trabajo entre los empleados y entre las dependencias Recomendaciones Todos los pasos del proceso deben estar organizados en una secuencia lógica Todos los pasos deben agregan valor Los procesos deben medirse o controlarse No se concibe un proceso sin un objetivo. Las actividades de un proceso deben estar escritas en infinitivo y deben plasmar el fin que se busca. El lenguaje de actividades del proceso debe ser cónsono con la cultura organizacional 9.2 Nomenclatura Para todo proyecto de integración es siempre recomendable establecer un conjunto de convenciones de nombre que ayuden a mantener de forma ordenada y auto-descriptible los objetos, los nombres escogidos serán utilizados a lo largo de diversas plataformas por lo cual debe escoger una convención que sea transparente y desvinculada de la tecnología subyacente. La mayoría de los ESB permiten los nombres tanto en mayúsculas como minúsculas, sin embargo son sensitivos a la variación, por lo cual debe tener cuidado y no ser ambiguo en la descripción. Existen además, ocasiones especiales en los que la plataforma de sistemas tiene restricciones específicas Página 73/103

74 sobre el uso mayúsculas/minúsculas, si este es su caso, por favor adapte estas recomendaciones de acuerdo con esas reglas. Debido a las restricciones recogidas de los ESB mas populares, los caracteres permitidos para los nombres de los elementos a lo largo de la plataforma son los caracteres del alfabeto inglés, números, el subrayado (_) y el punto (.) exclusivamente; el largo de los nombres esta delimitado en algunas ocasiones. Las reglas generales para los objetos internos se describen a continuación, adicionalmente más adelante se describen los casos particulares y sus condiciones específicas. Los nombres que representan los paquetes deben estar en todo minúscula. Los nombres que representan tipos deben ser sustantivos y en minúsculas, la inicial de cada palabra debe ser en mayúscula. Los nombres de variables deben estar en minúsculas, en caso de mas de una palabra la inicial de cada palabra luego de la primera debe ser mayúscula. Los nombres que representan los constantes (variables finales) deben ser en mayúsculas usando el subrayado (_) para separar palabras. Los nombres que representan métodos deben ser verbos, en caso de mas de una palabra la inicial de cada palabra luego de la primera debe ser mayúscula. Los subrayados y otros caracteres especiales no se deben utilizar en los nombres de variables, nombres de método. Las variables genéricas de los nombres de clase deben tener el mismo nombre que su tipo. Los nombres de variables binarias negadas deben ser evitados. Las reglas generales se aplican a todos los objetos, en particular a la programación interna de ellos, el consumo de servicios o la exposición de los mismos. En adelante se explican los detalles internos de cada tipo de objeto Flujos de Servicios La definición formal de un flujo de servicios es una secuencia de pasos de procesamiento o nodos que se ejecutan en el ESB luego de la recepción de un mensaje. Siempre se debe incluir al menos un nodo de entrada para poder construir un servicio. Según la definición del proceso a crear se configura el flujo del mensaje, se determina qué acciones se realizan en un mensaje cuando se recibe, y la orden en la cual se terminan las acciones. Se pueden utilizar flujos propietarios o del fabricante, subflujos o invocar flujos externos. Página 74/103

75 El esquema general para definir los objetos dentro del ESB sigue la siguiente definición: [Proyecto/Proceso]_<funcionalidad>_<nombreObjeto><TipoObjeto>.<versió n>, donde: [Proyecto/Proceso] reflejando por 3 caracteres las siglas del proceso/proyecto en cuestión. En la sección de Servicios Genéricos y Servicios Específicos se explica cuando usar uno u otro. <funcionalidad> indicando la razón específica del servicio <nombreobjeto> representa al nombre del objeto en cuestión, según las reglas que serán descritas mas adelante en el presente documento. <TipoObjeto> reflejando por 3 caracteres en mayúsculas el tipo de objeto al que se hace referencia. Cada uno de los objetos definido mas adelante indica su abreviación para ser colocada como tipo de objeto. <versión> indicando la versión del objeto. En algunos casos los productos permiten manejar un control interno de la versión facilitando y automatizando su manejo. Aún siendo este el caso es recomendable mantener el número de la misma (aunque sólo represente cambios mayores), de esa forma se obtiene una rápida comprensión del elemento y su evolución. El esquema presentado es sencillo, directo y concreto, permite en una sola vista del nombre conocer el tipo de objeto en cuestión, la granularidad y generalidad de la funcionalidad a la que corresponde, su direccionalidad, evolución e incluso para los casos que corresponde su Transaccionalidad. De esta forma se coordina el trabajo de los distintos miembros del equipo y el proceso de pase a producción es automatizable en el mejor de los casos ( dependiente de las herramientas utilizadas ) y en cualquiera de ellos procedimentable sin ambigüedades, los equipos de arquitectura, desarrollo, administración y operación conocen exactamente que esperar el uno del otro sin necesidad de frecuentes y largas reuniones de sincronización Nodos (N** ) Un nodo es un elemento en el flujo de un servicio que recibe un mensaje, realiza un conjunto de acciones sobre el mensaje, y opcionalmente, pasa el mensaje modificado al nodo siguiente en el flujo. Los nodos pueden ser propietarios, del fabricante o sub flujos. Los nodos personalizados son los que ofrecen la capacidad de generar código específico a una acción determinada no contemplada en los nodos del fabricante, estos nodos deberán contener el prefijo NPR_ en el nombre del objeto. La mayoría de los ESB contemplan esquemas que permiten programar a cualquier nivel los nodos, esta opción debe ser sin embargo tomada con cautela y generar un registro de nodos personalizados creados. Los nodos del fabricante pueden ser de entrada o salida, mapeo o transformaciones, las Página 75/103

76 funcionalidades especiales de los productos específicos de algún fabricante no son objeto del presente documento. Los subflujos, son flujos de servicios compuestos de nodos y conectores y están diseñado para ser embebido en otro flujo o subflujo, debe componer al menos un nodo de entrada y uno de salida y permite encapsular rutinas o servicios específicos internos. Los subflujos siguen las mismas reglas de nomenclatura de los flujos Nodos de Entrada/Salida (NIN_ / NOU_ ) Los nodos de entrada / salida representan son los accesos de dato o exposiciones de los flujos, su trabajo es manejar la representación inicial o final de los mensajes. Estos nodos deben ser identificados con NIN_ (nodos de entrada ) y NOU_ ( nodos de salida ) en el nombreobjeto Nodos de Mapeo (NMP_) Los nodos de mapeo son utilizados para construir uno o mas mensajes a partir de varias fuentes de información. Los nuevos mensajes se pueden construir a partir de información nueva, información modificada de un mensaje recibido o información tomada de una fuente de datos externa ( típicamente una base de datos ). Los componentes del mensaje de salida se pueden definir usando los mapeos que se basan en elementos del mensaje y de los datos de la entrada de una fuente externa. Se pueden modificar las asignaciones hechas por estos mapeos utilizando funciones propietarias definidas por el usuario o de la librería del fabricante Nodos de Transformación (NT*_) Los nodos de transformación son los componentes que analizan un segmento de la información del mensaje de entrada y crean una representación interna de el, que será utilizada para generar un mensaje de salida con una representación distinta. Su nomenclatura inicia con una T y un caracter adicional para indicar el tipo de transformación que es utilizada. Las transformaciones son capaces de obtener una representación distinta de documentos en XML, IDOC, JMS, MIME, BLOB o tipos propietarios, la mayoría de los ESB cuentan con nodos predefinidos que permiten generar estas transformaciones de forma sencilla y automática. Página 76/103

77 9.2.6 Servicios Genéricos & Servicios Específicos Los flujos de mensajes representan servicios que permiten a través el ESB generar una comunicación entre aplicativos disimiles resolviendo sus necesidades de integración. Estos servicios son distintos entre sí de acuerdo a su nivel de abstracción ( representando las necesidades del negocio ) o particularidad ( representando las necesidades de un aplicativo específico ). Los servicios genéricos representan las funcionalidades del negocio definidas a partir de las mejores prácticas, provenientes de un análisis de procesos y mapas de funcionalidades ( i.e. ETOM & TAM ). Los servicios específicos representan las necesidades de los consumidores y típicamente contienen alguna adaptación ( de la forma de filtrado o segmentado ) que permite utilizar lo conceptos propios del aplicativo. Según las urgencias planteadas en los proyectos estos servicios pueden temporalmente ser construidos para consumir directamente los servicios de la plataforma de legados, sin embargo lo recomendable es la utilización de uno o mas servicios genéricos para la ejecución de sus actividades. Los servicios generales están asociados a un proceso específico y a una funcionalidad del mapa derivado de los procesos, son altamente reusables y su granularidad varía según las necesidades de la empresa siendo permisible la coexistencia de niveles distintos aparentemente redundantes, las reglas de nomenclatura para estos flujos indican lo siguiente: <siglasproceso>_<funcionalidad>_[<funcionalidad nivel inferior>_]_<nombreobjeto> donde, <siglasproceso> indica las siglas del proceso al pertenece <funcionalidad> indica la funcionalidad que el servicio esta ejecutando. Estas funcionalidades en cualquiera de sus niveles deben provenir del mapa derivado de los procesos. Típicamente esta funcionalidad no tiene una representación directa en la plataforma de sistemas. Los servicios específicos están asociados a necesidades de integración de proyectos o aplicativos, su utilidad esta directamente relacionada con el proyecto o aplicativo al que sirven y son poco reusables, su construcción esta basa internamente en el uso de servicios generales a modo de nodos de subflujos. Las reglas de nomenclatura para estos flujos indican lo siguiente: <siglasproyecto/aplicativo>_<funcionalidad>_<nombreobjeto> donde, <siglasproyecto/aplicativo> indica las siglas del proyecto al que pertenece el servicio <funcionalidad> indica la funcionalidad que el servicio esta ejecutando. Página 77/103

78 10 Metodología Esta sección presenta la metodología de, el cual documenta la metodología de implementación de que se creó basado en la experiencia lograda en el proyecto de sustitución del Facturador, Recaudador y Gestor de Crédito de CANTV. Aún cuando la experiencia que fundamenta esta metodología está en el dominio de las Telecomunicaciones (Proyecto de CANTV), la aproximación es completamente agnóstica de industria de manera de que sea 100% útil y válida para otras industrias como Banca, Finanzas, Petróleos, Manufactura, Farmacéuticos, etc. Actualmente dicha metodología documenta su versión 2, la cual incorpora las lecciones aprendidas de la primera corrida para la creación de más de 200 servicios de negocio, en forma de una actualización metodológica y de instrumentos Premisas Página 78/103

79 Es compatible con proyectos de sustitución y migración de aplicaciones. Se compone de un proceso, artefactos de especificación, criterios de decisión, algoritmos de procesamiento y listas de validación de QA.4 Considera enfoque pragmático Alineado con: SAP ASAP Fases de Business Blue Print y Gap Analysis. RUP y UP TMForum Basado en Contratos Ciclo de cuatro (4) cuadrantes Artefactos de NGOSS (TAM, SID, OSS/J) Programa Prosspero de TMForum Comparación con otros modelos Los fabricantes de tecnología (ej. IBM, Sun, SAP, Oracle, etc.) y organizaciones internacionales de estandarización (ej. Open Group, SOA Institute, etc.) han desarrollado sus modelos de Ciclo de vida de SOA, asignándole de manera general el concepto presentado aquí como a las siglas SOA. Todos y cada uno de ellos presentan con nombres diferentes lo que de manera estándar la evolución de la Ingeniería de Software propone como metodologías de desarrollo de Tecnologías de Información en el siglo XXI. A continuación se presentan algunos de ellos y su correspondiente mapeo con el modelo de, el cual tiende a ser más completo y extensivo. Página 79/103

80 10.2.1IBM RUP Sun Microsystems Página 80/103

81 10.2.4SOA Institute Página 81/103

82 10.2.5SAP 10.3 Ciclo de vida de un servicio En la medida que se van atendiendo las necesidades del negocio, la metodología genera una evolución en los servicios en forma de ciclo de vida la cual se muestra a continuación. Página 82/103

83 En la figura del ciclo de vida de un servicio, cada paso representa lo indicado a continuación: Descubrir En esta etapa el servicio se ha descubierto del análisis de los procesos del negocio. Especificar El servicio ha sido especificado desde el punto de vista del requerimiento del proceso. Refactorizar Los arquitectos han generado la refactorización que identifica el contrato que ha de ser realizado. Realizar (Creación / Evolución) Cumplimiento del contrato basado en la evolución de contratos existentes o creación de uno nuevo. Disponibilizar Disponibilidad del servicio que implementa el contrato en la plataforma de ESB Desincorporar Desincorporación del servicio de la plataforma de ESB Es importante resaltar que un servicio puede tener múltiples versiones disponibilizados a la vez; se espera que la versiones más viejas tiendan a desincorporarse de manera que sean utilizadas las versiones más recientes. Página 83/103

84 10.4 Gobernabilidad La ejecución de un proyecto de SOA / BPM requiere la participación de un equipo de personas con roles variados, teniendo cada rol funciones y exigencias de conocimientos y competencias diferentes. A continuación se presentan los roles y el funciograma recomendado Roles A continuación se listan los roles principales que deben ser suplidos por el equipo; las personas pueden ser las mismas para varios roles siempre que entiendan las distintas necesidades de cada rol que asumen en cada instante del tiempo. Funcionales Representantes del negocio ; dueños de los procesos. Analista, de procesos Encargado de entender el proceso del negocio, modelarlo en la herramienta y proponer oportunidades de eficiencia Arquitecto, de servicios Encargado de llevar a cabo el análisis de brecha, refactorización e ingeniería de los servicios. Especialista, de conexión Encargado de disponibilizar el canal de las aplicaciones como proxies del ESB. Probador Encargado de ejecutar los protocolos de prueba Operador, de plataforma Encargado de mantener la plataforma de ESB y BPM funcionando y disponible Funciograma El equipo puede estar organizado de manera tal que sus funciones puedan ser coordinadas por agregación funcional hasta llegar al gerente del proyecto o encargado del grupo que atiende los requerimientos. Página 84/103

85 10.5 Proceso Página 85/103

86 Plan Planificación de tiempo y recursos Personas claves en múltiples lugares al mismo tiempo! Página 86/103