SOAr v1.

1

Página 1/103

Copyright (c) 2007-2008 Cesar Obach-Renner, Gurulab.org
info@gurulab.org, http://www.gurulab.org/

SOAr v1.1

SOAr v1.1
(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

Copyright (c) 2007-2008 Cesar Obach-Renner, Gurulab.org
info@gurulab.org, http://www.gurulab.org/

SOAr v1.1

Copyright (c)

2007-2008

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

Copyright (c) 2007-2008 Cesar Obach-Renner, Gurulab.org
info@gurulab.org, http://www.gurulab.org/

.....................................................................34 6..................48 7 ASPECTOS TÉCNICOS............................................................................................2 Características funcionales............................................................2 Agregación de funcionalidades no ortogonales.....4 2 PRÓLOGO..................................................2..3 Plataforma ideal.....................................................................................................................................................1 Nivel 1..............11 4 INTRODUCCIÓN....................................................................................4 SOBRE LOS TÉRMINOS EN INGLÉS.....................1 Primera generación: Integración punto a punto....................................................37 6.................4 MTOSI.....SOAr v1................................57 7..............1...........................................7 3 PREFACIO.35 6..............2 Segunda generación: Integración por Broker............................................................2 Nivel 2.......40 6..............................................................................45 6...................................................................................................1 SOAR COMO 4TA GENERACIÓN DE EAI....................................................................................3............................................................1 Telecomunicaciones......3.......50 7............1........ http://www..3 IMPLEMENTACIÓN DE SERVICIOS DEL NEGOCIO.......24 5..........................................................................................39 6.........................3 SITIO WEB DE APOYO E INFORMACIÓN DE CONTACTO.....2..............2 BENEFICIOS DE SOAR..........................................................3.................3 Tercera generación: SOA...........1 1 Contenido 1 CONTENIDO.....................................33 6 ESPECIFICACIÓN DE SERVICIOS DEL NEGOCIO (BSI).................1....................................................................................................................30 5.........................................................50 7.....................................10 3..........................................................2......................................1 Agregación de funcionalidades ortogonales...3...............4 ELEMENTOS CLAVES DE UNA IMPLEMENTACIÓN EXITOSA DE SOAR.....................................40 6......3 SID..6 DEDICATORIA Y AGRADECIMIENTOS.............................................................1...............................................................1.........................................2 TAM..................................................................................25 5............12 5 ¿QUÉ ES SOAR?..............................................27 5....................................................5 OSS/J...........................................................................................................3 SOAR Y BPM.................................................................................2......................................2 DESARROLLO DE CONECTORES................58 Página 4/103 Copyright (c) 2007-2008 Cesar Obach-Renner.............................org.....................41 6.....................................3 ESPECIFICACIONES ESTÁNDARES DE INDUSTRIA.......8 3........................32 5..................................5 WATERMARK...............................................55 7..............................8 3.......23 5...................................org info@gurulab.......55 7.......34 6........................................................................................................................................................38 6............................1..........2 Criterios para generar una BSI de buena calidad..............1 SOBRE GURULAB......................2 HERENCIA FUNCIONAL......................................................42 6..............................................................1....54 7...........1..........................................................................4 OTRAS INDUSTRIAS..................51 7......................................3..............23 5............9 3............................1..........1.......................org/ ...........................1 eTOM......................................44 6....................................................1..........................................2 ¿QUIÉN DEBE LEER ESTE LIBRO?..........................................10 3...................................19 5.......1......................................................................1........................................1..................... Gurulab................................................................................................................................................................................................................10 3.................................................................................................1 Fenómeno del Cernido................................43 6........................gurulab........................39 6.....................................................................................................1 Características técnicas ...........................................................1 CALIDAD DE LA BSI..............................................................53 7.............3.....................................4 Cuarta generación: SOAr..1 ANATOMÍA DE LA PLATAFORMA DE INTEGRACIÓN.........

....4 MODELO DE SERVICIO..............3 Ventajas....................................................................................................................7 Herramientas de Software Libre.....7................1 IBM................77 10 METODOLOGÍA...................... http://www...............78 10..........................................................................................2............................1...........................................................75 9...........2 RUP....................................................................................................................1.................................................................................................................................1........67 9 RECOMENDACIONES DE IMPLEMENTACIÓN...........................................5..................................1........................................88 10.............................................................................2..............................................................org/ ......................5...........................................................................2.............................................4 Diseño...........84 10................5.......................gurulab.....................5...........8 Recomendaciones..................................90 10......79 10.....................................................76 9........................81 10........................................92 11..................69 9....................69 9...84 10....................................................60 8..............................................85 10...................5 SAP.......................5...............................90 10.....................................4.................2...................71 9......7 Representación gráfica ............................................................4...............84 10...........2............5......70 9..69 9...................................................................76 9.2......................................4 GOBERNABILIDAD.4 Actores...........................................89 10.................................1..................3 ENFOQUE PRAGMÁTICO.......90 10...................................2 ESTRATEGIA DE IMPLEMENTACIÓN.......1 Criterios de Alcance de Integración........................................................................1 PROCESO....................71 9......76 9................................70 9.............................................................................................................................................................2.....1 Flujos de Servicios........................73 9.80 10...................................................................7...............................................................................3 Arquitectura...............................................................................................................................................2 COMPARACIÓN CON OTROS MODELOS...................................................3 CICLO DE VIDA DE UN SERVICIO......................5 PROCESO..................................................................................................................................................82 10.............2 Características.......................................82 10.........................4 Nodos de Mapeo (NMP_).........72 9.....................2.................................1 Documentación del requerimiento............................................................................................59 8.......................................................................................................6 Aspectos relevantes.........................59 8.....6 Pase a producción...........1 El diagrama.....................................72 9.............6 Servicios Genéricos & Servicios Específicos...............................................................................................................................5 ¿Cómo identificar un proceso?......1...........78 10..5...................................91 11 GLOSARIO..................................................................................................72 9..............3 Nodos de Entrada/Salida (NIN_ / NOU_ )............1.................................2 NOMENCLATURA......................5 Construcción y pruebas..........72 9........................................................1 Definición..........org.....................................................1..........................................................................................................................5.........................64 8...........................................................................................................................................2..................89 10.....................74 9................SOAr v1...............................................92 Página 5/103 Copyright (c) 2007-2008 Cesar Obach-Renner..................................60 8.......org info@gurulab..............................................................4 SOA Institute.........1 SISTEMA NERVIOSO EMPRESARIAL....1.........................................................................73 9........................................1 Roles........80 10......................................................................1..2 Funciograma...................2 Análisis.............1 MODELAJE DE PROCESOS........2 Nodos (N** ).............................................................1 8 CONSIDERACIONES ESTRATÉGICAS................................................................................................................................................................................ Gurulab...................69 9........................2.80 10.....1 Ejemplo de una Iteración...........................2..........7..................................1...........5 Nodos de Transformación (NT*_).............................................2 Componentes básicos.........................................................3 Sun Microsystems..............3 Consideraciones............................................................2..........................................................................2.......................................................................................................................1 PREMISAS...........88 10....

................................................................................5 WEBSERVICES........................................95 Página 6/103 Copyright (c) 2007-2008 Cesar Obach-Renner..........92 11...........................................................................1 11..........org info@gurulab.....................gurulab.................. Gurulab........92 11....................org/ .........org.....SOAr v1................................................... http://www.......92 11........................94 12 GNU FREE DOCUMENTATION LICENSE.............................................................4 INTERCAMBIOS VS SERVICIOS VS INTERACCIÓN.................3 DIAGRAMA DE FLUJO.................................2 PROCEDIMIENTO..........................

Gurulab. http://www.org/ .SOAr v1.org.gurulab.1 2 Prólogo Página 7/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org info@gurulab.

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. apalancados en la imaginación y conocimiento de sus miembros. El framework se encuentra en un proceso de mejora continua gracias a la colaboración de Gurulab. A lo largo de este documento. Ante esta situación. http://www.1 3 Prefacio Luego de tres años en el proceso de conceptualización. Página 8/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org info@gurulab. Gurulab. A finales del año 2005 luego de la fase de concepción de SOAr y construcción de los elementos fundamentales de la arquitectura. la cual ha sido documentada en este libro. 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.org y de su comunidad de usuarios que aportan sus experiencias y oportunidades de mejora.gurulab. Dicha metodología es parte del framework de integración SOAr (http://www. 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. Aprenderá las razones que justificarán.org/) y siendo uno de sus componentes es llamada “Metodología SOAr”. llegó el momento de ponerlo en práctica en el primer proyecto con alcances. Adicionalmente a la la conceptualización y metodología.soarframework. ingeniería básica y detallada de una Arquitectura de Integración Orientada a Servicios. creé una metodología que fue utilizada durante las fases de análisis. 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). fechas y presupuesto reales. respecto a cualquier otro enfoque de integración de aplicaciones.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.org. el framework SOAr contiene herramientas que facilitan la implementación de un proyecto de integración basada en SOA.SOAr v1. el lector tendrá la oportunidad de entender el valor diferenciador de esta aproximación de SOA la cual llamo “SOA recargado” (SOAr). diseño y construcción de las integraciones que el proyecto requería. 3.org/ .1 Sobre Gurulab Gurulab.

El vehículo que Gurulab. Gurulab. 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. 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. http://www. Arquitectos de Tecnologías de Información y especialistas de integración. desarrollo y formación de especialistas técnicos en temas de Arquitectura. El propósito es transmitir claramente el concepto de SOAr. y un framework de desarrollo rápido de aplicaciones llamado Jasolina.org utiliza para entregar sus innovaciones son las licencias del proyecto GNU (http://www. En su plan estratégico se plantea construir una base de operaciones que le permita con un presupuesto base desarrollar iniciativas de investigación. además del framework SOAr.org info@gurulab. adicionalmente a sus procesos de investigación y desarrollo. Si bien este libro está orientado a Gerentes de Sistemas. y FDL para las practicas y documentaciones como SOAr. se encuentra un ESB software libre para implementación de integración SOA y SOAr llamado Mula.SOAr v1. cubre el tópico de SOAr 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). 3. Página 9/103 Copyright (c) 2007-2008 Cesar Obach-Renner. Entre sus iniciativas.org ha logrado una buena experiencia en la ejecución de hazañas tecnológicas para varios de sus clientes.gnu.org/ .1 Adicionalmente a las innovaciones que ha incursionado en los últimos 10 años. Gurulab. Gurulab. Esto significa que todo profesional del área de sistemas y/o tecnologías de información entenderá perfectamente los conceptos y planteamientos hechos aquí.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. provee servicios de educación y asesoría para asegurar la adecuada adopción de las tecnologías que domina.gurulab. Por ser introductorio.org/) GPL para el software.org. 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. cuáles son sus beneficios. Tecnología e Innovación.

org/).El concepto" (Cookbook) Especificación de Servicios del Negocio (BSI) Cursos y Talleres Casos exitosos Integradores experimentados Plataformas de Integración (ESBs) 3.org/ y en dicho lugar se encuentra descrito claramente su valor y cada uno de sus componentes.4 Sobre los términos en Inglés. Gurulab.org/ . El URL oficial del Framework de SOAr es http://www. El Framework de SOAr es un conjunto de recursos disponibles a la comunidad de Tecnología de Información para lograr implantaciones exitosas de SOAr. En particular.org info@gurulab. los componentes del Framework de SOAr son: ● ● ● ● ● ● El libro "SOAr . 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.1 3. ambos disponibles bajo licenciamiento de documentación Libre de GNU (http://www.SOAr v1. La versión en español de este documento utiliza los acrónimos de los términos en inglés de manera estándar. Seguramente a medida que estos conceptos vayan adoptándose de manera general en regiones de habla hispana.gurulab. http://www.gnu. 3.org.gurulab. 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”.5 watermark Minor Earth Mayor Sky @A-Ha Thought That It Was You @A-Ha She's Madonna @Robbie Williams The 80's @Robbie Williams Página 10/103 Copyright (c) 2007-2008 Cesar Obach-Renner.3 Sitio web de apoyo e información de contacto Esta publicación es el documento oficial del concepto SOAr perteneciente al Framework de SOAr (en inglés SOAr Framework).

SOAr v1.1

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

Copyright (c) 2007-2008 Cesar Obach-Renner, Gurulab.org
info@gurulab.org, http://www.gurulab.org/

SOAr v1.1

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

Copyright (c) 2007-2008 Cesar Obach-Renner, Gurulab.org
info@gurulab.org, http://www.gurulab.org/

SOAr v1.1

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 GUI App 1 c1 GUI App 2 c1 … c1 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

Copyright (c) 2007-2008 Cesar Obach-Renner, Gurulab.org
info@gurulab.org, http://www.gurulab.org/

o sean buenos o malos. La mayoría de las empresas que hoy en día tienen una práctica madura de integración se encuentran en este estadio. el hecho de que una empresa posea un solo proveedor de todos sus componentes de TI. seguridad. aún asumiendo que todos sean “súper configurables”. Respecto al costo. sin embargo nos topamos con una realidad inevitable: en ambientes empresariales de mediana complejidad en adelante.1 o deseados. 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. estén en la caja o fuera de ella). etc. 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. 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. Esto implica un problema. precios. 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. soporte. implica un riesgo importante que tiende a desaparecer cuando se tienen a varios proveedores.org info@gurulab. calidad. resultando una mejor oferta de negocio. Desarrollando solo algunos de los puntos indicados. sin un elemento superior que controle los procesos. ya que al tener aplicativos de distintos fabricantes. En el caso de la “sincronización”.org/ . Bastaría con conseguir una aplicación que tuviese esa capacidad “súper configurable” y lograríamos el objetivo. 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. las aplicaciones súper-configurables pierden su flexibilidad. relación. al nivel 2 del modelo de madurez del NGITP (ver Figura 2) Página 14/103 Copyright (c) 2007-2008 Cesar Obach-Renner. en este escenario. extra-aplicación que controle los procesos. respecto a “seguridad”. Gurulab. http://www.org.gurulab.SOAr v1. la cual corresponde independientemente de que las aplicaciones sean “súper configurables” o no.

sino en la arquitectura que se establece entre el Gestor de Procesos y los aplicativos.org/ . La casa de Walldorf lo acepta también no solo sacando al mercado herramientas para coreografía de procesos. http://www.gurulab. Esta conclusión a la que estamos llegando es clara para muchos Arquitectos empresariales y fabricantes de aplicativos en todo el mundo.SOAr v1.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.org. 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. ahora lo “súper configurable” no es una característica a buscar en las aplicaciones. Gurulab.1 Nivel de Madurez c1 GUI App 1 c1 GUI App 2 c1 … c1 GUI App n Bus 2 . Ahora bien.org info@gurulab.EAI p1 App 1 p2 App 2 p3 … … pj App n 1 . Como puede verse. Página 15/103 Copyright (c) 2007-2008 Cesar Obach-Renner. sino generando rutas de evolución de sus aplicaciones para sacar los procesos de sus cajas hacia su coreógrafo de procesos. ¿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. 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”.

SOAr v1.1 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. Gurulab.gurulab. Página 16/103 Copyright (c) 2007-2008 Cesar Obach-Renner. Esto le devuelve al negocio el poder de sus procesos. idealmente estándar. Nivel de Madurez c1 GUI App 1 c1 GUI App 2 c1 … c1 GUI App n S1 S2 S3 … Bus Sm 3- Servicios Corporativos 2 .org/ . Esto es lo que el modelo de madurez de NGITP plantea como nivel 3 (ver Figura 3). de las aplicaciones que realmente serán las responsables de ejecutarlas.org.EAI p1 App 1 p2 App 2 p3 … … pj App n 1 . 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.org info@gurulab. delegando únicamente a Tecnología la tarea de proveer los componentes sobre los cuales viven los procesos. De esta manera. A estos servicios les llamamos “Servicios del Negocio”. 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. http://www.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.

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.org. Como elemento final del modelo de madurez. los procesos viven en el Gestor de Procesos y no en las aplicaciones. Nivel de Madurez c1 GUI p1 c1 GUI p2 c1 … c1 GUI pj p1 p2 p3 … pj Process Manager 4 . el gestor de procesos permite modelar procesos y ejecutarlos a lo largo y ancho de la plataforma de tecnología. el cual muestra cómo a diferencia del nivel anterior. En Figura 4 se muestra el nivel 4 del modelo de madurez del NGITP. Gurulab.EAI App 1 App 2 … App n 1 .org/ . http://www.gurulab. 3) Una interfaz de usuario para ejecución de procesos que se construya automáticamente a partir de la definición del proceso. permitiéndole al negocio evolucionarlo con la rapidez que sea requerido por lo dinámico del entorno.org info@gurulab.BPM S1 S2 S3 … Bus Sm 3- Servicios Corporativos 2 .SOAr v1.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. Página 17/103 Copyright (c) 2007-2008 Cesar Obach-Renner. sin necesidad de depender de modificaciones a nivel de sistemas.1 Basado en los servicios corporativos. lo harán en el contexto de los procesos orquestados por el Gestor de Procesos y a través de él.

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

Desacoplar las aplicaciones unas de otras. Gurulab. SOAr logra esto simplificando de manera importante cualquier esfuerzo de integración empresarial. tiene una gran cantidad de funcionalidades las cuales de manera ideal. Aprovechar al máximo las capacidades de las herramientas tecnológicas existentes actualmente. estarían implementadas por un grupo ordenado y concreto de “Aplicaciones Ideales” las cuales llamamos Componentes Funcionales. http://www. imaginemos el caso (ver Figura X) de integrar los procesos de una empresa (por ejemplo. a su plataforma de Tecnologías de Información (TI).org.1 5 ¿Qué es SOAr? SOAr es una forma de integrar aplicaciones y procesos basado en una Arquitectura Orientada a Servicios (SOA). Controlar reduciendo los riesgos derivados de los cambios de aplicaciones de la plataforma de sistemas.gurulab.org/ . Para entender bien como funciona SOAr. la cual tiene como objetivo principal aislar toda aplicación de la plataforma de tecnología o proceso del negocio. 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. logrando:     Desacoplar la plataforma de TI de los procesos del negocio.SOAr v1.org info@gurulab. del resto de la arquitectura. escondiendo la complejidad del conjunto de aplicaciones existente a cualquier nueva aplicación que se desea integrar. (ver figura X) Página 19/103 Copyright (c) 2007-2008 Cesar Obach-Renner. a través de una plataforma de gestión de procesos -BPM-) o una nueva aplicación.

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

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 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.gurulab. Página 21/103 Copyright (c) 2007-2008 Cesar Obach-Renner. los cuales son la fachada que la plataforma de TI expone a los procesos y nuevas aplicaciones que han de integrarse.org info@gurulab. http://www.1 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”.SOAr v1.org/ .org. Gurulab. En otras palabras. simplemente se integran con un único y simple componente funcional a través de una única tecnología.

la estrategia de integración de aplicaciones SOAr provee: Simplicidad.org. al instalar un nuevo CRM. Por ejemplo. independientemente de quien sea el proveedor de cada uno. SOAr expone uno solo. Por ejemplo.1 De esta manera. el CRM no se entera de tal sustitución gracias a SOAr.SOAr v1. Gurulab. Página 22/103 Copyright (c) 2007-2008 Cesar Obach-Renner. porque para todo cliente de las aplicaciones expuestas por SOAr. Estabilidad. SOAr lo hace transparente a los clientes de manera que estos últimos no se dan cuenta. SOAr le expone los servicios estándares del Gestor de Ordenes de Servicio. en vez de tener tres sistemas de facturación. SOAr representa un mecanismo para lograr el establecimiento de una Plataforma de Tecnología de Información de Nueva Generación nivel 3. estas últimas nunca cambian. SOAr expone uno solo. 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. 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. porque esconde la complejidad resultante de la redundancia y solapamientos funcionales de las aplicaciones existentes. esto es debido a que aún cuando en realidad las aplicaciones en realidad si cambian.org info@gurulab. Eficiencia.gurulab. Tras bastidores SOAr orquesta y resuelve la complejidad de tener cinco Gestores de Ordenes de Servicio.org/ . porque en el contexto del modelo referencial NGITP de Gurulab. http://www. en vez de tener dos sistemas contables. Conveniencia.

gurulab.1 Como veremos en la siguiente sección.SOAr v1.org. A continuación veremos cada una de estas generaciones a saber: i) ii) iii) iv) Punto a Punto Broker SOA SOAr 5. Figura 7 Primera generación de EAI: Punto a punto El orden de complejidad de las conexiones existentes en este modelo es C n= 2 2  n! n = 2 2 !−  n−2  ! EAI por sus siglas en inglés de Enterprise Application Integration. SOAr representa la 4ta generación de la práctica de EAI2. cada aplicación tiene tantas conexiones como el resto de las aplicaciones existentes. http://www.1. Página 23/103 Copyright (c) 2007-2008 Cesar Obach-Renner. tal como se muestra en la Figura 7.org info@gurulab.org/ . Gurulab.1 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.1 SOAr 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. 5. y corresponde a una forma particular de SOA con características resaltantes que lo apuntalan como una práctica diferente y con beneficios concretos.

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.org. contiene la estructura y mensaje que la aplicación destino espera recibir. Debido a que entonces todas las aplicaciones solo requieren conectarse con el Broker. http://www. 5.org/ . da 4005 conexiones. el mensaje que una aplicación envía al Broker cumple con el Contrato establecido por la aplicación destino.SOAr v1. El modelo EAI punto a punto puede considerarse como el modelo primal. Página 24/103 Copyright (c) 2007-2008 Cesar Obach-Renner. donde n es la cantidad de aplicaciones a interconectar.1. 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. la combinatoria da 435 conexiones. 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.gurulab. Por ejemplo. Gurulab. es decir.2 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. entonces en este modelo la cantidad de conexiones se simplifica a n. para 90 aplicaciones. para 30 aplicaciones.org info@gurulab. además de contener la información que el Broker interpreta para saber hacia qué aplicación enviarlos. se encarga de enrutar los mensajes que vienen de una aplicación “origen”.1 en donde n es el total de aplicaciones a interconectar.

desde la perspectiva del modelo referencial de Arquitectura Empresarial de Gurulab. En el modelo de EAI de 3ra generación. Seguridad y Gestión de Sistemas. SOA representa la colección de funcionalidades de la capa de “lógica de negocio” que toda aplicación tiene en dicho modelo. 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.1 5.1. 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).org. Si bien esto no es equivocado. los dominios pilares a los que el patrón de SOA afectaría son Datos. sino en el consumo de servicios que cada aplicación expone con su respectivo Contrato. mejor conocido como integración SOA. Gurulab. 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”. En este contexto SOA plantea que toda aplicación expone todas sus funcionalidades a través de servicios. están implementando una Arquitectura Orientada a Servicios. 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. Gurulab ha catalogado esta práctica como tercera generación de EAI.gurulab.org/ . Aplicación.3 Tercera generación: SOA Desde la perspectiva de Arquitectura Empresarial. Para los fanáticos del modelo de arquitectura de n-capas. en una forma punto a punto.org info@gurulab. Infraestructura. Sin generar ningún juicio de valor. 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. Integración. Página 25/103 Copyright (c) 2007-2008 Cesar Obach-Renner. 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.SOAr v1. Acceso. http://www.

gurulab.) eran completas. Organización internacional de estandarización de manejo de objetos. http://www. Siglas del inglés Object Management Group.SOAr v1. 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.org. del inglés “Common Object Request Broker Architecture” OMG.omg. alta disponibilidad. la cual se apalanca en tres elementos fundamentales: el 3 4 CORBA. 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.1 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”. etc. 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. Si bien las prestaciones que esta especificación proveía para la integración de aplicaciones en el entorno empresarial (proveyendo seguridad.org/ . Gurulab. A finales de los años 90. transaccionalidad.org/ Página 26/103 Copyright (c) 2007-2008 Cesar Obach-Renner. resultaban complejas y por ende costosas de implementar. http://www.org info@gurulab. Originalmente esta Arquitectura Orientada a Servicios era implementada utilizando la tecnología CORBA3 especificada y estandarizada por la OMG4. de aquí nació la tecnología de Servicios Web. 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.

los clientes de cualquier servicio deben cumplir con el contrato impuesto por la aplicación proveedora del servicio. cubre los vacíos que SOA por si sólo deja sin solución. CORBA. Si bien la tendencia del mercado es que SOA se implementa con Webservices. 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.1. la especificación de Contratos de servicios WSDL6 y el catálogo dinámico de servicios UDDI7. dado que SOA es una arquitectura.1 protocolo de comunicación SOAP5. 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? 5.gurulab. 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).org/ . RMI. 8 DNS (siglas de Domain Name System): Sistema de nombre de dominios. etc. and Integration) : es un Directorio en línea que las aplicaciones utilizan para descubrir de forma dinámica otros servicios en línea.org info@gurulab. es quien realmente desacopla el servicio de su proveedor. por ejemplo. 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. Es importante resaltar que en SOA. propietario/Socket. El papel del UDDI es generalmente menospreciado.SOAr v1. 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. 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). Gurulab. SUN RPC. http://www. Webservices (SOAP/HTTP). 7 UDDI (siglas de Universal Description. EJBs.4 Cuarta generación: SOAr SOAr es la evolución de SOA en cuanto que al redefinir la forma de implementación. entonces el cliente debe ser modificado para que pueda cumplir con el nuevo contrato.org. por lo que si ésta cambia afectando el “Contrato”. Página 27/103 Copyright (c) 2007-2008 Cesar Obach-Renner. Discovery. puede ser implementada utilizando cualquier tecnología incluyendo Webservices.

los servicios expuestos por la plataforma corresponden con servicios “compuestos”.9 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. etc. Los elementos principales de una arquitectura SOAr son: 1) Aplicaciones: Conjunto de programas de software diseñados y escritos para realizar operaciones especificas. Para muchos especialistas. cambiantes y disímiles (por las evidentes diferencias entre las implementaciones de mismos conceptos por diferentes sistemas/proveedores).gurulab. con cada cambio todas las aplicaciones integradas se ven afectadas. SOAr. Gurulab. una arquitectura en la que se expone un conjunto de proveedores intermedios llamados “Servicios del Negocio” o “Servicios del Negocio”. 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). iii) Como alternativa a una arquitectura que no da respuestas a la realidad empresarial actual se presenta SOAr.1 estándar. ubicación geográfica del cliente o del material. ii) Duplicidad funcional: Cuando un servicio es provisto por dos aplicaciones diferentes. las cuales van a ser 9 Dicha duplicidad funcional no es necesariamente una consecuencia de una plataforma inmadura. pero cumpliendo el rol de Servicios del Negocio.SOAr v1. http://www. de esta manera cuando uno cambie un proveedor por otro los clientes no se ven afectados. SOAr 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. calidad de servicio.org info@gurulab. sin embargo en esas aproximaciones. 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.org. los servicios compuestos se plantean como complementos de los servicios atómicos provistos directamente por los aplicativos. Dichos Servicios del Negocio representan en la plataforma de tecnología el mapa ideal de aplicaciones.org/ . los cuales se exponen simples y sencillos de utilizar. Página 28/103 Copyright (c) 2007-2008 Cesar Obach-Renner. escondiendo las complejidades de una realidad redundante (por las duplicidades. condiciones del negocio pueden implicar que dicha duplicidad funcional represente el estado del arte en cuanto a la solución tecnológica.

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

En otras palabras. b. http://www. Página 30/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org info@gurulab. Expone de manera simple todos los datos y lógica del negocio presentes a lo largo de toda la infraestructura de tecnología. 2. 4. Reduce de manera importante los costos en riesgo. Sin la heterogeneidad tecnológica típica de los ambientes empresariales. 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. y las unidades de TI evolucionar sus plataformas con un menor impacto en los procesos del negocio. Especificaciones conocidas.2 Beneficios de SOAr La implantación del modelo SOAr 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. pudiendo el negocio evolucionar sus procesos con menos dependencia de las unidades de TI. Si bien a continuación se presentan con precisión los beneficios de implantar el modelo SOAr.org/ . 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. Esto lo hace SOAr exponiendo los servicios corporativos con las siguientes características: a. sin necesidad de aprender semántica y sintaxis específicas de las aplicaciones existentes o por llegar. de esta manera ambos. todos los servicios y datos accesibles a través de la misma tecnología. debido a que esto también es escondido por SOAr. 1.SOAr v1.gurulab. Ausencia de complejidad por solapamientos o duplicidad funcional. Gurulab. Desacopla los procesos del negocio de la plataforma de tecnologías de información. 3. SOAr expone una plataforma en la que para una función nunca hay dos aplicaciones que hagan lo mismo. tanto los procesos como la plataforma evolucionan de manera independiente. c.1 5.org. en otras palabras. tiempo y dinero de integración de nuevas aplicaciones debido a la sencillez que SOAr expone la plataforma a las nuevas aplicaciones.

Silos NGITP Maturity Model Figura 11 SOAr en NGITP 8. 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. Maximiza el uso de manera eficiente de la plataforma tecnológica de integración a nivel corporativo. En el contexto del modelo referencial NGITP de Gurulab.org/ . 6.1 5.org info@gurulab. SOAr representa un mecanismo para lograr el establecimiento de una Plataforma de Tecnología de Información de Nueva Generación nivel 3. Simplifica los procesos de migración de aplicaciones “por partes”. http://www.org. Nivel de Madurez c1 c2 … ci SmartInterface 5 . debido a que provee un “Modelo Tecnológico” que indica claramente como utilizar cada componente para tal fin.gurulab. Al estar las aplicaciones encapsuladas.SOAr v1. Gurulab. 7.BPM S1 S2 S3 … Bus Sm SOAr 3- Servicios Corporativos 2 .EAI App 1 App 2 … App n 1 . Página 31/103 Copyright (c) 2007-2008 Cesar Obach-Renner. cuando una es cambiada ninguna de las aplicaciones que son “clientes” de ella requieren ser tocadas. Elimina los impactos de un cambio de aplicación en las otras aplicaciones.SmartInterface p1 p2 p3 … pj Process Manager 4 . Provee a la empresa de la infraestructura modelada como Nivel 3 del modelo de madurez NGITP de Gurulab.

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

4. Gurulab. es decir. estándares y proveedores específicos. independiente de estándar. 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. 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. http://www. 5. tecnología o proveedor. La aproximación que este libro tiene a cada uno de estos elementos claves es de manera estructural. 3. ningún cambio de aplicaciones de la pataforma de TI afecta la ejecución de procesos implementada sobre la capa de BPM.org info@gurulab.org. En el sitio web www.SOAr v1. y éstos no cambian sino las aplicaciones que SOAr encapsula. para su exitosa implementación es necesario contar con cuatro (4) elementos muy importantes: 1.4 Elementos claves de una implementación exitosa de SOAr Asumiendo como premisa la intención de utilizar el concepto de SOAr para implementar una plataforma de integración orientada a servicios (EAI basada en SOA). Página 33/103 Copyright (c) 2007-2008 Cesar Obach-Renner.soarframework.1 Dado que los procesos “consumen” servicios corporativos. 2.gurulab.org/ .org además estar disponible este documento están disponibles registros de experiencias que se han tenido con tecnologías.

org. 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 SOAr. En la medida que su BSI tenga mayor calidad. Gurulab.1 Calidad de la BSI Para poder definir claramente qué es la Calidad de una BSI y cómo se consigue.) 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 SOAr. es necesario definir previamente los siguientes conceptos: Página 34/103 Copyright (c) 2007-2008 Cesar Obach-Renner. 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. 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. En la medida que la BSI sea de mayor calidad.org info@gurulab.org/ . flexibilidad.SOAr v1. http://www. etc. 6.1 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. también se presentarán los estándares de industria conocidos por Gurulab que presentan especificaciones que pueden ser utilizados como BSI.gurulab. Estos estándares aseguran de manera razonable que el BSI basado en ellos es de muy buena calidad. menor impacto tendrá el cambio de un elemento de la plataforma de TI en otros y los procesos del negocio. Adicionalmente. 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.

..org info@gurulab. y por una de grano grueso a una basada en funcionalidades compuestas (no atómicas). F2. sin modificación en su API.org. o nuevos rasgos en los datos del negocio..SOAr v1.1 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. Corolario Dos funcionalidades son “no ortogonales” si alguna de ellas es subconjunto funcional de la otra.1 Fenómeno del Cernido Entendiéndose por especificación de grano fino a una basada en funcionalidades atómicas. nuevas funcionalidades “no ortogonales” respecto a las existentes. 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. se define como el fenómeno del Página 35/103 Copyright (c) 2007-2008 Cesar Obach-Renner. . Toda funcionalidad es subconjunto funcional de si misma.1. 6. Funcionalidad Atómica Se dice que una funcionalidad F0 es atómica si y sólo si no existen otras n funcionalidades F1. Gurulab. 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.gurulab. 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. Calidad de una BSI La calidad de una BSI es directamente proporcional a su capacidad de absorber. Fn diferentes a partir de las cuales se puede derivar F1. http://www.org/ .

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. 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. Página 36/103 Copyright (c) 2007-2008 Cesar Obach-Renner. es necesario muchas menos construcciones lexicográficas (palabras) que las necesarias en el idioma Japonés. http://www. 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. 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.org info@gurulab.”). Gurulab.1 cernido a la situación que se presenta cuando a un proceso del negocio o aplicativo de la plataforma de TI. En la foto. Para entender este fenómeno.org/ .org. 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. 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).SOAr v1.gurulab. el “actor” escucha atentamente a la traductora mientras observa al director quien espera que finalice la traducción. Para expresar una idea en idioma Inglés (o Español).

com/designpatterns/ 12 API.SOAr v1. http://www. aún cuando los procesos o aplicaciones que requieren consumirlos requieran de una especificación de grano grueso. En la medida que el experto o especialista es representado por el arquitecto de la BSI.1 Entre el Inglés y el Japonés existe el fenómeno del cernido. mejor será la expresión de dicha visión en la BSI.ibm.research. o pueden estar expresados en términos agnósticos como UML. es importante que el arquitecto de la especificación tome en cuenta una serie de consideraciones las cuales se resumen en los siguientes preceptos: 1. 4. deben expresarse en función de funcionalidades atómicas independientemente de que esto implique el fenómeno del cernido.com/developer/technicalArticles/J2EE/patterns/ http://www. Dicho sistema de referencia puede estar expresando en términos de documentación formal. Uso de excepciones para manejo de errores Basado fundamentalmente en los siguientes patrones de diseño: ● Session Façade Pattern ● Value Object Pattern.org info@gurulab. Gurulab. y en el caso de las especificaciones de servicios del negocio el grano corresponde a la expresividad de su API12.gurulab. 3. Como referencia a continuación se presentan fuentes de información de patrones de diseño orientado a objetos: ● ● http://java.1.sun. Página 37/103 Copyright (c) 2007-2008 Cesar Obach-Renner. De aquí se desprende fácilmente que el tamaño del grano habla de la expresividad de sus palabras. La BSI debe diseñarse pensando en un sistema ideal de referencia.org/ . 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 2.org.2 Criterios para generar una BSI de buena calidad Con el fin de lograr una especificación de servicios del negocio de buena calidad. o en función de la visión de un experto o especialista. Los patrones son referencias generales las cuales pueden estar expresadas en términos de lenguajes específicos como Java. del inglés Application Program Interface. es decir. Las especificaciones de los servicios del negocio deben ser de grano fino. Data Transfer Object ● Factory Pattern. 6. en donde el Inglés es de “grano grueso” y el Japonés de “grano fino”.

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. ● 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. más que de una práctica de especificación con “calidad”. 6. Por ejemplo. o en el talleres especializados dictados por Gurulab. o estrategias prácticas respecto a cómo llevarlo a cabo se encontrarán documentados en próximas entregas de este libro. una entre los años 1997 y 1999. Esta expectativa es alcanzable a través de una BSI de alta calidad ante modificaciones de la plataforma que agreguen nuevas funcionalidades no ortogonales. En otras palabras.org/ . 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. Gurulab.org info@gurulab. si uno agrega nuevas funcionalidades noortogonales. Si el CRM está integrado al Servicio de Negocio de Gestión de Ordenes a través de una BSI de alta calidad. Para que la plataforma provea esa “herencia” ante agregaciones de funcionalidades ortogonales. incluyendo la especificación de datos. y la BSI es de buena calidad. 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.org. es una tarea muy extensa la cual se aconseja ser llevada a cabo por etapas en amplitud y por iteraciones para cubrir profundidad (detalles). junto con mi equipo he tenido ya dos experiencias grandes y contundentes. Detalle de estos criterios.SOAr v1. el CRM heredaría la Página 38/103 Copyright (c) 2007-2008 Cesar Obach-Renner. A la fecha. Los cambios que puede sufrir la BSI pueden clasificarse de dos tipo: ● Agregación de funcionalidades ortogonales. la BSI debe ser definida basado en un conocimiento de expectativas funcionales a futuro.1 El desarrollo de una especificación de servicios del negocio. simplemente asume la característica “default”. en RUNTIME.gurulab. http://www. 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 SOAr. con ambas experiencias hemos aprendido a crear especificaciones de servicios de negocio de muy alta calidad. y la segunda entre los años 2003 y 2005. los procesos y sistemas que consuman de la BSI heredarán las nuevas funcionalidades sin necesitar de cambiar código en los “consumidores”.

SOAr v1.2.org/ . 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. http://www. Adicionalmente. sino por procesos de mantenimiento que pueden ser implementados en periodicidades bianuales y sin ningún tipo de restricciones respecto a otros proyectos.gurulab. Página 39/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org info@gurulab. pueden ser expuestos ambas versiones simultáneamente. si bien el último caso es poco probable en el escenario de nuevas funcionalidades ortogonales. 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. éste impacto no ocurre por cambios en la plataforma. 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. el impacto dependerá de la calidad de la BSI.1 nueva funcionalidad y en el acto. Gurulab.1 Agregación de funcionalidades ortogonales En el escenario de agregación de nuevas funcionalidades ortogonales respecto a las existentes en la BSI. menor la cantidad de cambios en los procesos o sistemas “consumidores”. A continuación veremos cada una de estos dos tipos: 6. empieza a ofrecer la opción de selección de la característica particular. si ocurre y afecta servicios que están siendo utilizados. 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. los procesos y aplicativos que consuman de la BSI serán afectados en la medida que se requiera que éstos los aprovechen.2. aun disfrutando de las nuevas funcionalidades incorporadas en la plataforma a través de la “Herencia” que SOAr les confiere. La publicación de dos versiones de un mismo servicio es una práctica que debe llevarse a cabo de manera cuidadosa. sin la necesidad de ser modificado. 6.org. En la medida que la BSI sea de mayor calidad.2 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. 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.

CORBA.3. los que la ITU es para las redes de la misma industria.3 Especificaciones estándares de industria A continuación se presentan los casos particulares para los cuales SOAr cuenta con valores agregados. XML y Java llamada OSS/J. El que una industria no esté enunciada en este capítulo no implica que no pueda utilizar SOAr. TAM. Página 40/103 Copyright (c) 2007-2008 Cesar Obach-Renner.1 Telecomunicaciones TeleManagement Forum (http://www. En particular.). OSS/J) en la tecnología requerida por la plataforma (Webservices. MTOSI. etc.SOAr v1.org/ . SID. tecnología utilizada ampliamente en la actualidad.. http://www. sino que para el momento de la publicación de este documento. Gurulab. o la ISO para cualquier industria. Gurulab no poseía información de artefactos estándares que faciliten el trabajo de implementación.tmforum.gurulab.org/) es para las TI de la industria de Telecomunicaciones. el gran valor que estas especificaciones aportan es que la Especificación de Servicios del Negocio que requiere SOAr es fundamentalmente la implementación de NGOSS (eTOM.1 6. 6. Java.org info@gurulab. agrupa un conjunto de artefactos estándares y mejores prácticas que permiten lograr una plataforma tecnológica de operaciones de nueva generación. OSS/J provee las especificaciones requeridas para Servicios Web. En el contexto de SOAr. 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.org.

Gurulab. 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. componente del marco de referencia NGOSS del TMForum.gurulab. Página 41/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org.1.SOAr v1.1 eTOM eTOM.1 Figura 12 Representación gráfica de NGOSS de TMForum A continuación se presentan los artefactos del TMForum que son relevantes para SOAr.org/ . Para ello enumera una cantidad de procesos clasificados en varias dimensiones según se muestra en la Figura 13.org info@gurulab. http://www. 6.3. Sirve inicialmente como referencia estándar a la hora de nombrar los procesos o partes de ellos (subprocesos).

1 Figura 13 Representación gráfica de eTOM.gurulab. http://www.3. A continuación se presenta la figura que muestra la clasificación actual.org. Página 42/103 Copyright (c) 2007-2008 Cesar Obach-Renner. 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.SOAr v1. Gurulab. 6.2 TAM El Telecom Operations Map representa un catálogo que identifica y clasifica el conjunto de Componentes Funcionales de una empresa de Telecomunicaciones.org/ .1.org info@gurulab.

representado en modelos UML. Gurulab.org/ . SID es un modelo canónico de datos.SOAr v1. es por esto que sus elementos representan componentes de agrupación de los servicios de negocio implementados en su ESB.1 Este estándar presenta lo que SOAr llama las ”aplicaciones ideales” o ”plicaciones virtuales”. http://www.3 SID Siendo también elemento de NGOSS del TMForum.gurulab. Página 43/103 Copyright (c) 2007-2008 Cesar Obach-Renner. agnóstico de tecnología. La Figura 14 muestra los dominios de SID que clasifican todas las clases (modelo orientado a objetos) que representan el estándar.3. 6.org.1.org info@gurulab.

gurulab. 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.4 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. 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 SOAr. Gurulab.1.org. 6. 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.org info@gurulab. Basado en la experiencia adquirida en el proyecto de integración en CANTV. hágalo trabajando de manera muy cercana al equipo de desarrollo. 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.1 Figura 14 Representación gráfica de SID. En particular representa la especificación que SOAr Página 44/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org/ .3.SOAr v1. http://www. 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). recomiendo de manera enfática que de trabajar con este modelo y requerir su extensión.

0) Final Release OSS Trouble Ticket (v1.ossj.org info@gurulab. 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 (http://www. Facturador. XML y Java de los APIs que se listan a continuación: JSR # 89 90 91 130 142 144 210 251 254 OSS/J API OSS Service Activation Status Spec Lead & Company 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 Java.1) OSS Quality of Final Release Service (v1.5 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). Gurulab. Hoy en día mantiene las especificaciones en Weservices. Gestor de Ordenes de Servicio.SOAr v1. etc.tmforum.0) Maintenance OSS Billing Mediation Release (v1.gurulab.org/ . Dado que MTOSI es un artefacto relativamente nuevo no cubre de manera relevante los componentes de la arquitectura que se requiere especificar.org/.1) Final Release OSS Inventory (v1.org.org/) es accesible a través de su URL propio http://www. http://www.1.3.0) Maintenance OSS Common Release 3 (v1. 6.net Maintenance Release (v1.3) OSS Service Quality Early Draft Review Management Pricing OSS Discovery Thierry Supplisson Vallent John Wilmes Early Draft Review Ceon Corporation Andrew Paterson Public Draft Review Nakina Systems public public Página 45/103 Copyright (c) 2007-2008 Cesar Obach-Renner. Inventario.1 requiere de manera concreta y específicamente en la tecnología que sea utilizada para su implementación.

jcp.org info@gurulab.1 JSR # 263 264 285 OSS/J API Fault Management Order Management 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.org/) aún cuando incorpora especificaciones de Webservices y XML.net (http://www.org/ .net public public Las especificaciones generadas por OSS/J son gestionadas a través de la Java Community Process (http://www. Igualmente son publicadas a través de la comunidad java.gurulab. http://www.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 Copyright (c) 2007-2008 Cesar Obach-Renner.SOAr v1.org. Gurulab.

gurulab.SOAr v1. Figura 16 Mapeo de las especificaciones de OSS/J con SID de TMForum Página 47/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org/ .1 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.org info@gurulab. Gurulab. http://www.org.

etc. 6. por lo que la adopción de OSS/J como especificación de Servicios del Negocio implica el uso del SID. es previsible que dicha extrapolación funcione muy bien al menos en los dominios independiente de industria como Contabilidad. es decir. http://www.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)”.org. Facturación.SOAr v1. 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.ossj.org/ . Gurulab. RRHH. incluyen una implementación del SID. adopción de mejores prácticas de la industria de Telecomunicaciones y el uso de una BSI de alta calidad.org/downloads/docs/wp_ossj_api_roadmap.org info@gurulab. CRM. podría evaluarse para resolver otras . Página 48/103 Copyright (c) 2007-2008 Cesar Obach-Renner. Sin embargo.gurulab.1 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 http://www.pdf Las especificaciones de OSS/J además de incluir las especificaciones de API. probada por varios operadores a nivel mundial.

1 Página 49/103 Copyright (c) 2007-2008 Cesar Obach-Renner.SOAr v1.org/ .org info@gurulab.gurulab.org. Gurulab. http://www.

además del propio proveedor de la tecnología que usted utilice. si en algún momento usted se topa con alguna limitación de la plataforma de integración. 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. usted tendrá los siguientes beneficios:  Desacoplamiento del proyecto de implementación de la plataforma utilizada. software abierto o software libre). El primer nivel muestra la menor cantidad de elementos para entender la plataforma. Es importante resaltar que esta descripción es lo suficientemente abierta para que cualquier plataforma pueda ser descrita. a continuación se presenta una descripción anatómica de los elementos que la plataforma que usted va a utilizar para implementar SOAr debe tener.1 7 Aspectos técnicos 7. Independientemente de la herramienta que utilice. fácilmente podrá incorporar nuevos elementos que completen su arquitectura referencial y así lograr los objetivos fundamentales de la implementación SOAr aquí descrita. o utilice un simple compilador de su lenguaje de preferencia y un editor del código fuente.org/ .1 Anatomía de la Plataforma de Integración Como premisa fundamental de SOAr se tiene que es posible implementarlo sobre cualquier plataforma tecnológica que la empresa tenga. Teniendo en mente el modelo de referencia tecnológica de SOAr en vez del modelo arquitectural de la plataforma provista por el fabricante.   A continuación se presenta la radiografía de la arquitectura referencial de la tecnología a utilizar en dos niveles de detalle diferentes.org info@gurulab. Ya sea que utilice herramientas de alto nivel como productos especializados para integración basado en SOA.gurulab. De esta manera le será mucho más fácil comunicarse con cualquier especialista. El nivel Página 50/103 Copyright (c) 2007-2008 Cesar Obach-Renner. Aseguramiento de un lenguaje común independiente de un fabricante específico de tecnología de integración. 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. Gurulab. http://www. De esta manera.SOAr v1.org. y de su esquema de licenciamiento (sea software propietario.

Le recomiendo que usted siga esta práctica y nunca llame Adaptador a los Conectores. http://www.1. por lo que les llaman Adaptadores y no Conectores.org/ . esto es debido a que se quiere evitar la confusión que se genera con los proveedores de conectores en el mercado. 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. 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”). Página 51/103 Copyright (c) 2007-2008 Cesar Obach-Renner.1 2 explota cada uno de los elementos presentando un mayor detalle que permita entender mejor la arquitectura desde el punto de vista físico.SOAr v1. En este documento les llamamos Conectores y no Adaptadores para hacer énfasis en que a ese nivel NO DEBE OCURRIR ADAPTACIÓN ALGUNA. En general los proveedores de conectores resaltan la gran cantidad de atributos de sus conectores como por ejemplo la capacidad de hacer Adaptaciones. en otras palabras. 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).1 Nivel 1 Tal como se muestra en la Figura 18. Algunos autores/proveedores hacen énfasis en este modo de uso de los conectores llamándolos redundantemente “Conectores livianos”. llámelo por su nombre común “Conector” y no por su nombre propio “Adaptador”. 7. aún cuando la pieza de software sea un Adaptador.org info@gurulab. Gurulab.gurulab.org.

Servicios Web. CORBA. Gurulab. Los Conectores son los responsables de resolver cualquier dificultad tecnológica para acceder al Canal Página 52/103 Copyright (c) 2007-2008 Cesar Obach-Renner.) La plataforma es un agente que está compuesta a nivel macro por tres capas: capa de conexión.) o propietarios (SAP RFC.1 Figura 18 Nivel 1 . http://www.SOAr v1. en particular contiene a los Conectores y los Proxy. destacamos de ellos los que denominaremos el Canal.org. etc. DCOM de Microsoft. El Canal es la colección de recursos de una aplicación específica que se encuentran disponible para los objetivos de integración.org/ . La primera de las capas es la de Conexió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. en la cual se encuentran los elementos necesarios para vincular las aplicaciones con la plataforma. SAP BAPIS. sin embargo. capa de adaptación y núcleo.org info@gurulab.Arquitectura de la plataforma tecnológica de integración SOAr Los aplicativos son los elementos de Software tal como lo conocemos.gurulab. etc.

los cuales son construidos como una secuencia de llamadas a los Proxys. Dichas “llamadas” atraviesan la capa de Adaptación.1. se tiene el nivel 2 el cual se muestra en la Figura 19. http://www. 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.1 de las aplicaciones. Página 53/103 Copyright (c) 2007-2008 Cesar Obach-Renner. En el centro de la plataforma se encuentra el Núcleo.SOAr v1. 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. 7. suponiendo que las tres aplicaciones de RRHH estén manejando cada una un grupo de Empleados diferente. en dicha capa viven los Servicios del Negocio. 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). 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. éstos exponen dentro de la plataforma tantos Proxys como Canales se quiera integrar. Gurulab. En particular.gurulab.org. Adicionalmente en la capa de Adaptación viven los “Servicios Específicos de Aplicación”. A esta altura. 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.org/ . También se dice que estos “Servicios específicos” implementan la adaptación de la lógica. La diferencia fundamental entre los dos niveles está en la diferenciación de sub-capas. esto último es llamado también “mapeo”.org info@gurulab. En los Servicios del Negocio que viven en el núcleo de la plataforma es donde ocurre la abstracción de las aplicaciones subyacentes. siendo los Proxys representaciones en la plataforma de los Canales de las aplicaciones. los cuales al ser opcionales. Por ejemplo. 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.2 Nivel 2 Explotando la figura de la plataforma nivel 1. pueden proveer la adaptación que pudiese requerir una aplicación “Cliente” para poder hacer uso de un Servicio Corporativo.

org info@gurulab. Página 54/103 Copyright (c) 2007-2008 Cesar Obach-Renner. 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. 7. La capa de Adaptación se separa en dos subcapas. ya sean a nivel de adaptaciones o Servicios del Negocio.org/ . La Figura 19 muestra una separación física que puede existir entre estas capas.org.gurulab. debe ser una herramienta visual o metalenguaje que abstraiga la noción de la morfología de los datos.Proxies y Conexión. http://www. viviendo en este caso los proxys en los límites de la plataforma.1.SOAr v1.Arquitectura de la plataforma tecnológica de integración SOAr Para el caso de la capa de Conexión.Conectores. Los mapeos se definen entre pares de Objetos sin necesidad de hacer una vinculación explicita en la lógica de los servicios. aquella donde viven las adaptaciones y aquella donde ocurre el Mapeo.3 Plataforma ideal Idealmente. Gurulab.1 Figura 19 Nivel 2 . se muestran las dos subcapas Conexión.

Adicionalmente a las funciones ya mencionadas. 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.1  La ejecución de la lógica de servicios indicada de primero. 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. tanto como lo es el ESB. aquellos provistos por 3ros (fabricantes) poseen adicionalmente capacidades de adaptación.org info@gurulab.1 Características técnicas El conector es una pieza compleja en si misma. Para tener un conector funcionando.2.mapeos. y debido a su naturaleza de uso. 7. Como ya hemos visto en este libro. cumpliendo las características técnicas del mismo. estas capacidades de “adaptación” son las de realizar transformaciones semánticas en las estructuras intercambiadas. al pasar por la capa de Adaptación. se hace referencia a Conectores (cosas) y a Adaptación (función. de manera general los proveedores de tecnología de integración además de proveer el ESB.2 Desarrollo de conectores Los conectores poseen la funcionalidad de habilitar la comunicación entre dos ambientes tecnológicos dispares. http://www. o características funcionales. basta con proveerse de uno ya sea construido “en casa” o tecnología de 3ros. y nunca se hace referencia a Adaptadores.gurulab. SOAr plantea hacer uso únicamente de las funcionalidades de Conexión de estas tecnologías. 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 Copyright (c) 2007-2008 Cesar Obach-Renner. 7. sin embargo. Es por esto que los fabricantes llaman “Adaptadores” a sus conectores.SOAr v1. que es llevada a cabo en el ESB). Es por esto que en el planteamiento de SOAr. también proveen tecnología de conexión. Gurulab.org. delegando al ESB las funciones de Adaptación. y luego configurarle las semánticas que se desean exponer al ESB.org/ .

identificar y resolver problemas utilizando mensajes a nivel de capa de aplicación. 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.org/ . 99. así por ej. terminar (init. detener.25 minutos de inactividad / año.38 minutos de inactividad / mes.99% = 52. 0. es llamado tres nueves ( tres 9's ) 2. 99. comenzar.1 ● ● ● ● ● Ciclo de vida: todo conector debe implementar mecanismos que permitan las acciones de inicializar. al menos utilizar WS/JMS como mecanismo de transporte. 4. El uso de JMS como transporte es para asegurar la persistencia de la transacción. Generalmente se espera que al menos tenga 99. En caso de que no sea posible. Alta Disponibilidad: medida en un número de 9's13 que debe ser definido siguiendo los estándares de la empresa. Eficiencia y Gestión: acordes con la plataforma. el resultado se expresa comúnmente por el número de 9's seguidos que la expresión resultante tiene.8 minutos de inactividad / mes.9% = 525. recargar. 43. utilizando diversas herramientas tales como uso de referencia de codificación como UNICODE.org info@gurulab. Aseguramiento de las representaciones binarias: el conector es responsable de asegurar las representaciones binarias.6 minutos de inactividad / año. ● Transaccionalidad: asegurando la atomicidad de la transacción. garantizando que el conector tenga al menos el mismo nivel de disponibilidad de la plataforma del ESB. reset & finalize) ● Seguridad: Para asegurar la identificación y autenticación del “cliente” y cifrado de la comunicació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.SOAr v1. start. es llamado cuatro nueves ( cuatro 9's ) 3. este cálculo se hace dividiendo el número total de minutos de actividad por el total de minutos en el año ( aprox 525.gurulab. el uso apropiado de los recursos tanto de memoria.999% = 5.600 ). 1. http://www. 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. 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. 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. 99. es llamado cinco nueves ( cinco 9's ) 13 Página 56/103 Copyright (c) 2007-2008 Cesar Obach-Renner. y cambios de representaciones BIG INDIAN y LITTLE INDIAN.44 minutos de inactividad / mes.5 minutos de inactividad / año. stop.9% de disponibilidad. Gurulab.org. ● 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. ● Funcionalidad: A través del cual se acceden al contrato funcional que ofrece el conector.

iwaysoftware.2. un fabricante especializado en conectores que provee los conectores a prácticamente todos los ESB del mercado es la empresa iWay (http://www.1 ● 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. ocultando las decisiones de diseño interno de cada módulo del resto. 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. A modo de referencia. 7.com/).org info@gurulab.gurulab.org. En general. ● Página 57/103 Copyright (c) 2007-2008 Cesar Obach-Renner. 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. 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. los fabricantes proveen junto con su ESB una lista pequeña de conectores fundamentales. No duplicidad.2 Características funcionales ● ● Encapsulamiento. http://www.org/ .SOAr v1. Debido al gran costo y tiempo que representa desarrollar un conector que incorpore todas estas consideraciones. Gurulab. Separación de responsabilidades y responsabilidad única. es relevante que a esa lista inicial se le incorporen los conectores adicionales requeridos para integrar todas las plataformas de su ambiente.

7.SOAr v1.org. http://www. Gurulab.gurulab.org/ . 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.org info@gurulab.3 Implementación de servicios del negocio Página 58/103 Copyright (c) 2007-2008 Cesar Obach-Renner.1 ● No adaptaciones.

gurulab. ● 14 Del inglés ENS. 8.SOAr v1.org. En el primer caso. En el segundo caso. Transferencia de tecnología. 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: ● Establecimiento de una relación contractual entre el proveedor de servicios de integración y la unidad operativa. esta plataforma provee servicios de integración a todas las iniciativas de integración de la empresa.org info@gurulab. Al implementar una plataforma “corporativa” de integración basada en Servicios del Negocio SOAr. lo cual es muy adecuado como práctica de Arquitectura Empresarial.1 Sistema Nervioso Empresarial Si bien usted podría utilizar la aproximación de SOAr para proveer servicios de integración de 4ta generación a soluciones de negocio concretas como por ejemplo la implementación de un CRM. basada en una fábrica de integración. Para lograr esto. el objetivo al final del día es la implementación del Sistema Nervioso Empresarial. Enterprise Nerve System Página 59/103 Copyright (c) 2007-2008 Cesar Obach-Renner. http://www. Gurulab. se está implementando el llamado Sistema Nervioso Empresarial14. o como una solución de integración para una solución de negocio específica. las actividades de Pase a Producción de la práctica a las unidades operativas de la organización. puede enfocarse de tal manera que represente el primer paso en el plan de implementación corporativa. la consideración que debe realizarse es la de incluir al final del sub-proyecto de implementación de SOAr para la solución de negocio.org/ . de manera que la unidad operativa aprehenda la práctica y lograr así el control total de la práctica de integración empresarial SOAr. es preferible plantearse la implementación de SOAr desde una perspectiva corporativa. si bien el objetivo no es implementar el Sistema Nervioso Empresarial.1 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 SOAr. Los proyectos que consideran SOAr pueden tenerla como meta a nivel corporativo.

Figura 20: Situación inicial Página 60/103 Copyright (c) 2007-2008 Cesar Obach-Renner.1 Ejemplo de una Iteración Inicialmente. 8.SOAr v1.2 Estrategia de implementación Para implementar un Sistema Nervioso Empresarial SOAr.2. 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.org/ .1 8. http://www. SOAr va asimilando nuevas aplicaciones de la plataforma de tecnología. para luego ser sustituida utilizando los beneficios de SOAr. la plataforma de tecnología se encuentra completamente integrada a través de cualquier mecanismo no SOAr. Cada iteración se basa en la provisión de servicios de negocio a proyectos de Soluciones de Negocio. la forma más adecuada de llevarlo a cabo es a través de aproximaciones sucesivas. Cada una de las cuatro aplicaciones implementa una Función particular. la cual está identificada debajo de cada aplicación.gurulab.org info@gurulab. Con cada iteración. Gurulab. hasta la Función 4. desde la Función 1. hasta llegar a un punto en el cual todas las aplicaciones se encuentran integradas a través de SOAr.org. 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.

org/ . http://www. 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.1 Como primer paso. se exponen los Servicios del Negocio (BSI) en la plataforma de servicios. Figura 22: Paso 2 de la Iteración Página 61/103 Copyright (c) 2007-2008 Cesar Obach-Renner.gurulab.org info@gurulab. 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.org. implementando la lógica de integración encapsulando la realidad compleja y exponiendo servicios del negocio simples organizados por Componentes Funcionales. Gurulab.SOAr v1.

gurulab. En el ejemplo aparece la numero cinco.org info@gurulab. 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. http://www. la cual también implementa la misma Función que la aplicación que va a sustituir.org/ . En el siguiente paso (numero 4). evidentemente la nueva aplicación incorporará nuevas funcionalidades o características que no disponía la aplicación tres. En el ejemplo.1 Luego. Gurulab. 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 SOAr) son “respondidos” apalancado sobre la aplicación tres. se realiza el “Encapsulamiento” de la aplicación o aplicaciones que van a ser sustituidas. se instala y se conecta al ESB la nueva aplicación que será la sustituta.SOAr v1.org. Página 62/103 Copyright (c) 2007-2008 Cesar Obach-Renner. 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. como paso numero tres (3).

org. Gurulab.SOAr v1.org info@gurulab. http://www. 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. es posible configurar el Servicio del Negocio para que solo responda con los resultados de la nueva aplicación. con el fin de generar un paralelo. Página 63/103 Copyright (c) 2007-2008 Cesar Obach-Renner. Figura 25: Paso 5 de la Iteración Luego de que puede considerarse como culminado la etapa de “paralelo” de la nueva aplicación.1 Figura 24: Paso 4 de la Iteración Como siguiente paso (paso 5).org/ . entrando oficialmente “En Producción”.gurulab.

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.SOAr v1.org info@gurulab. la aplicación sustituida puede ser desincorporada (ver Paso 7). Esta situación plantea al equipo técnico responsable de implementar la plataforma SOAr 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 Copyright (c) 2007-2008 Cesar Obach-Renner.org.1 Figura 26: Paso 6 de la Iteración Una vez pasado un tiempo prudencial de estabilidad de la nueva aplicación “en producción”.gurulab. http://www. Gurulab. Figura 27: Paso 7 de la Iteración 8.org/ .

org. y consecuentemente del rendimiento como actor en su entorno empresarial. 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).gurulab. 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). el enfoque pragmático plantea sacar esa actividad de la ruta crítica. 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. En la siguiente lámina se muestra como. 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. desde la perspectiva de la anatomía agnóstica de proveedor de SOAr.1 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.SOAr v1. Gurulab. Con el fin de evitar por completo estas circunstancias. 2.org info@gurulab. La implementación de los servicios del negocio podría estar en la ruta crítica de los proyectos de solución de negocio. http://www. a continuación se presenta el enfoque pragmático de implementación que le permitirá lograr los objetivos de SOAr integrando aplicaciones en tiempos de una integración punto a punto.org/ . lo cual crea un costo adicional en tiempo que puede generar los siguientes inconvenientes: 1. con lo cual usted estaría asumiendo un riesgo importante desde la perspectiva de gestión de proyecto. las adaptaciones implementan internamente la lógica de integración directamente contra los proxy. Página 65/103 Copyright (c) 2007-2008 Cesar Obach-Renner.

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. queda la arquitectura interna del ESB como se muestra en la siguiente figura.gurulab.org/ .SOAr v1. Página 66/103 Copyright (c) 2007-2008 Cesar Obach-Renner.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. entonces. entregando resultados a sus “clientes”.org.org info@gurulab. http://www. mientras este estado entra en producción.1 Figura 28: Enfoque pragmático de implementación de SOAr . Gurulab.

Esto implica que el equipo desarrollador. encargado de la realización de cambios en las aplicaciones. En el primer modelo.gurulab.Estado final 8. la primera a través de un modelo Inflexible y el segundo usando un modelo Flexible. Desde la perspectiva del modelo tecnológico de la plataforma de integración.1 Figura 29: Enfoque pragmático de implementación de SOAr . llamado Inflexible.4 Modelo de servicio Existen dos formas de implementar un servicio corporativo de integración.SOAr v1.org/ . este modelo inflexible implica las aplicaciones consumen directamente los Página 67/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org info@gurulab. 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. Cada forma define el modelo de servicio que una entidad corporativa puede adoptar. Gurulab. las aplicaciones deben adaptarse a los Contratos canónicos que implementan los Servicios del Negocio que viven en la plataforma de integración.org. http://www.

gurulab.1 Servicios del Negocio sin necesidad de que la plataforma exponga servicios específicos de aplicación.org/ . 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.org info@gurulab. Página 68/103 Copyright (c) 2007-2008 Cesar Obach-Renner. la plataforma de integración no sólo expone los servicios corporativos con su Contrato canónico. llamado Flexible. En el segundo modelo. La decisión de implementar alguno de los modelos propuestos anteriormente va a depender fundamentalmente de la cultura organizacional de la empresa. Gurulab.org. sino que expone un servicio “a la medida” de cada aplicación cliente llamado “Adaptación”. el aplicativo no debe ser modificado para poder hacer uso de los servicios corporativos.SOAr v1. http://www. De esta manera.

materiales.1 9 Recomendaciones de implementación 9.1.1 Modelaje de procesos 9. Conjunto de pasos que se realizan de forma sucesiva en distintas dependencias.gurulab. equipos y procedimientos en actividades concebidas para producir un resultado final específico.org.org/ . energía. Organización racional de personas. Gurulab. http://www. ● ● 9.1.2 Componentes básicos ● Qué (Actividades) Página 69/103 Copyright (c) 2007-2008 Cesar Obach-Renner. añadiendo valor. o bien como un grupo de acciones que tienen un propósito común que hace avanzar el negocio en alguna forma.org info@gurulab.1 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. con el objeto de transformar una serie de entradas específicas en una salidas (bienes o servicios) deseadas.SOAr v1.

a fin de cumplir con sus objetivos. productos o servicios. formalizan los procesos y subprocesos que debe adelantar el ente gubernamental o empresa.1. Cada paso se ubica en determinado lugar. Estos en conjunto con la definición de la misión de la organización. Las actividades de un proceso deben estar escritas en infinitivo y deben plasmar el fin que se busca. Gurulab.1 ● ● ● ● Quién (Recursos) Cuándo (Tiempo) Dónde (Ubicación) Cómo (Documentos de Entrada. la cual determina el valor agregado de la entidad. Métodos manual / automatizado / combinado) 9.gurulab. ● ● ● Los procesos en la organización se identifican a partir de la norma de constitución de la entidad.1. típicamente son los siguientes: ● Los proveedores: son quienes suministran los materiales y las informaciones requeridas para ejecutar el proceso.org/ . y funciones. Salida.3 Consideraciones ● ● No se concibe un proceso sin un objetivo. por eso es importante la secuencia dentro del proceso. 9.org.4 Actores Cuando se define un proceso es indispensable identificar los actores que participan en cada una de las actividades del mismo.org info@gurulab. quien define sus objetivos.SOAr v1. productos o servicios que le son demandados. http://www. Tienen un principio y un fin: inician con determinada acción o evento y finalizan en otro. Ejemplo: “Verificar la morosidad del cliente”. 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 Copyright (c) 2007-2008 Cesar Obach-Renner. El documento o insumo inicial se convierte en valor agregado.

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

7. a través de los elementos como las actividades.1.org.3 Ventajas Describe en forma sencilla el paso a paso de cada proceso y complementa la descripción literal. mejoramiento y control de los procesos.1. http://www.gurulab.SOAr v1. 9.org/ . los documentos y las unidades administrativas y cargos que intervienen en él.2 Características El flujograma es una herramienta de representación gráfica de gran importancia para el levantamiento. busca mostrar en forma dinámica y lógica la secuencia del trabajo. 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.1.1. suprimiendo lo que no es esencial y simplificando lo que sí es. diseño. propendiendo por la eliminación de trámites innecesarios.7 Representación gráfica 9.7. Gurulab. permitiendo conocer y comprender el proceso que se describe.7. se convierte en un instrumento muy importante para guiar su ejecución en forma ordenada.1 ● ● Bien ejecutados facilitan la ejecución exitosa de otros Cruzan líneas fronterizas organizacionales.1 El diagrama La representación gráfica del proceso.org info@gurulab. análisis. 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 9. porque usualmente tienen que ver con más de una dependencia de manera directa o indirecta 9. facilitando su consulta Página 72/103 Copyright (c) 2007-2008 Cesar Obach-Renner.

SOAr v1. Existen además. ocasiones especiales en los que la plataforma de sistemas tiene restricciones específicas Página 73/103 Copyright (c) 2007-2008 Cesar Obach-Renner. La mayoría de los ESB permiten los nombres tanto en mayúsculas como minúsculas. facilitando el examen de los pasos. 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.gurulab.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.org. sin embargo son sensitivos a la variación. 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 9.1. Gurulab. por lo cual debe tener cuidado y no ser ambiguo en la descripción. desde el más simple hasta el más complejo Permite la visualización rápida e integrada de un proceso. http://www. Las actividades de un proceso deben estar escritas en infinitivo y deben plasmar el fin que se busca.8 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.1 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. El lenguaje de actividades del proceso debe ser cónsono con la cultura organizacional 9.org info@gurulab.org/ .

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

El esquema presentado es sencillo.2. los equipos de arquitectura. y opcionalmente.2 Nodos (N** ) Un nodo es un elemento en el flujo de un servicio que recibe un mensaje.gurulab. realiza un conjunto de acciones sobre el mensaje.org. 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. desarrollo. esta opción debe ser sin embargo tomada con cautela y generar un registro de nodos personalizados creados. La mayoría de los ESB contemplan esquemas que permiten programar a cualquier nivel los nodos. administración y operación conocen exactamente que esperar el uno del otro sin necesidad de frecuentes y largas reuniones de sincronización. pasa el mensaje modificado al nodo siguiente en el flujo. Los nodos del fabricante pueden ser de entrada o salida. 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. permite en una sola vista del nombre conocer el tipo de objeto en cuestión.<versió n>. Los nodos pueden ser propietarios. las Página 75/103 Copyright (c) 2007-2008 Cesar Obach-Renner. su direccionalidad. <funcionalidad> indicando la razón específica del servicio <nombreObjeto> representa al nombre del objeto en cuestión. de esa forma se obtiene una rápida comprensión del elemento y su evolución. directo y concreto. <TipoObjeto> reflejando por 3 caracteres en mayúsculas el tipo de objeto al que se hace referencia. En la sección de Servicios Genéricos y Servicios Específicos se explica cuando usar uno u otro. donde: [Proyecto/Proceso] reflejando por 3 caracteres las siglas del proceso/proyecto en cuestión. Cada uno de los objetos definido mas adelante indica su abreviación para ser colocada como tipo de objeto. estos nodos deberán contener el prefijo NPR_ en el nombre del objeto. mapeo o transformaciones. 9.org/ .1 El esquema general para definir los objetos dentro del ESB sigue la siguiente definición: [Proyecto/Proceso]_<funcionalidad>_<nombreObjeto><TipoObjeto>. Aún siendo este el caso es recomendable mantener el número de la misma (aunque sólo represente cambios mayores).SOAr v1. http://www. <versión> indicando la versión del objeto. Gurulab. del fabricante o sub flujos. evolución e incluso para los casos que corresponde su Transaccionalidad. En algunos casos los productos permiten manejar un control interno de la versión facilitando y automatizando su manejo. según las reglas que serán descritas mas adelante en el presente documento. la granularidad y generalidad de la funcionalidad a la que corresponde.org info@gurulab.

5 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. información modificada de un mensaje recibido o información tomada de una fuente de datos externa ( típicamente una base de datos ). la mayoría de los ESB cuentan con nodos predefinidos que permiten generar estas transformaciones de forma sencilla y automática. Los subflujos siguen las mismas reglas de nomenclatura de los flujos. 9.gurulab.org info@gurulab.3 Nodos de Entrada/Salida (NIN_ / NOU_ ) Los nodos de entrada / salida representan son los accesos de dato o exposiciones de los flujos. http://www. Los subflujos. Las transformaciones son capaces de obtener una representación distinta de documentos en XML. 9. que será utilizada para generar un mensaje de salida con una representación distinta. JMS. Su nomenclatura inicia con una T y un caracter adicional para indicar el tipo de transformación que es utilizada. MIME. Los nuevos mensajes se pueden construir a partir de información nueva.2. 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. 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.org/ . Estos nodos deben ser identificados con NIN_ (nodos de entrada ) y NOU_ ( nodos de salida ) en el nombreObjeto. Página 76/103 Copyright (c) 2007-2008 Cesar Obach-Renner. su trabajo es manejar la representación inicial o final de los mensajes. BLOB o tipos propietarios.SOAr v1. Gurulab. 9. IDOC.org. Se pueden modificar las asignaciones hechas por estos mapeos utilizando funciones propietarias definidas por el usuario o de la librería del fabricante.4 Nodos de Mapeo (NMP_) Los nodos de mapeo son utilizados para construir uno o mas mensajes a partir de varias fuentes de información.2.1 funcionalidades especiales de los productos específicos de algún fabricante no son objeto del presente documento.2.

SOAr v1.1

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

Copyright (c) 2007-2008 Cesar Obach-Renner, Gurulab.org
info@gurulab.org, http://www.gurulab.org/

SOAr v1.1

10 Metodología
Esta sección presenta la metodología de SOAr, el cual documenta la metodología de implementación de SOAr 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.

10.1 Premisas

Página 78/103

Copyright (c) 2007-2008 Cesar Obach-Renner, Gurulab.org
info@gurulab.org, http://www.gurulab.org/

SOAr v1.1

● ● ● ●

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.

10.2 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 SOAr 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 SOAr, el cual tiende a ser más completo y extensivo.

Página 79/103

Copyright (c) 2007-2008 Cesar Obach-Renner, Gurulab.org
info@gurulab.org, http://www.gurulab.org/

org info@gurulab. http://www.2.SOAr v1.3Sun Microsystems Página 80/103 Copyright (c) 2007-2008 Cesar Obach-Renner.2RUP 10.1 10.1IBM 10.org.org/ .2.gurulab. Gurulab.2.

1 10.2.org/ . Gurulab.org info@gurulab. http://www.4SOA Institute Página 81/103 Copyright (c) 2007-2008 Cesar Obach-Renner.SOAr v1.org.gurulab.

5SAP 10.SOAr v1.org/ . Página 82/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org info@gurulab. la metodología SOAr genera una evolución en los servicios en forma de ciclo de vida la cual se muestra a continuación. Gurulab.gurulab.3 Ciclo de vida de un servicio En la medida que se van atendiendo las necesidades del negocio.2.org.1 10. http://www.

Gurulab.SOAr v1. 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.org info@gurulab. Especificar ● El servicio ha sido especificado desde el punto de vista del requerimiento del proceso. 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. se espera que la versiones más “viejas” tiendan a desincorporarse de manera que sean utilizadas las versiones más recientes.gurulab.org.org/ . Realizar (Creación / Evolución) ● Cumplimiento del contrato basado en la evolución de contratos existentes o creación de uno nuevo.1 En la figura del ciclo de vida de un servicio SOAr. Refactorizar ● Los arquitectos han generado la refactorización que identifica el contrato que ha de ser “realizado”. http://www. Página 83/103 Copyright (c) 2007-2008 Cesar Obach-Renner.

4. 10.1 10. A continuación se presentan los roles y el funciograma recomendado. Analista. refactorización e ingeniería de los servicios.org. modelarlo en la herramienta y proponer oportunidades de eficiencia Arquitecto. dueños de los procesos.gurulab. Probador ● Encargado de ejecutar los protocolos de prueba Operador. de procesos ● Encargado de entender el proceso del negocio.1Roles A continuación se listan los roles principales que deben ser suplidos por el equipo.4 Gobernabilidad La ejecución de un proyecto de SOA / BPM requiere la participación de un equipo de personas con roles variados.org info@gurulab. de conexión ● Encargado de disponibilizar el “canal” de las aplicaciones como proxies del ESB. ● ● ● ● 10. Gurulab. Página 84/103 Copyright (c) 2007-2008 Cesar Obach-Renner. ● ● Funcionales ● Representantes del “negocio”. de servicios ● Encargado de llevar a cabo el análisis de brecha. teniendo cada rol funciones y exigencias de conocimientos y competencias diferentes. Especialista.org/ .SOAr v1.2Funciograma 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. de plataforma ● Encargado de mantener la plataforma de ESB y BPM funcionando y disponible. http://www. 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.4.

http://www.org/ .org info@gurulab.SOAr v1.org.5 Proceso Página 85/103 Copyright (c) 2007-2008 Cesar Obach-Renner.1 10.gurulab. Gurulab.

gurulab. http://www.1 Plan ● ● Planificación de tiempo y recursos Personas claves en múltiples lugares al mismo tiempo! Página 86/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org/ .SOAr v1.org. Gurulab.org info@gurulab.

● Define secuencia de interacciones ● Defines en detalle cada dato a ser intercambiado así como protocolo. 5. Arquitectura ● Identifica la realización de cada especificación de interacción.1 0.org info@gurulab. Definición funcional ● Procesos y funcionalidades ToBe. 3.org/ . Documentación del requerimiento ● “intercambios” y “casos de uso” Análisis ● Especificaciones basadas en “interacciones”.gurulab. Página 87/103 Copyright (c) 2007-2008 Cesar Obach-Renner.SOAr v1. ● Eliminación de redundancias dentro del lote de requerimientos. ● Requerimientos técnicos previstos 1.org. 2. Gurulab. http://www. ● Reuso y extensión de servicios existentes (Ciclo de vida de servicios) Diseño ● Contratos físicos ● Transformación de datos Construcción y prueba ● Transformaciones de datos ● Lógica de servicios ● Conexiones y adaptaciones 4.

2Análisis Para cada “Caso de Uso” identificado en la etapa anterior. Gurulab.5. El rol de cada aplicación se identifica según el siguiente criterio: ● En Intercambios que acceden a “Lógica del negocio”: ● Cliente: Transmisor ● Proveedor: Receptor ● En Intercambios de Data/Eventos ● Proveedor: dueño de la data/evento Validación del alcance de Integración basado en los criterios de alcance de integración (documentado más adelante) Generación de propuesta de “oportunidades de optimización” de interacciones.1 10.org info@gurulab.gurulab. se lleva a cabo las siguientes actividades: ● El equipo funcional presenta los procesos y funcionalidades “Meta” ● El equipo técnico (incluyendo el grupo de integración) hace preguntas y genera sugerencias respecto a los procesos y funcionalidades.1Documentación del requerimiento En sesiones de levantamiento de requerimientos. orientadas por “procesos”. ● Los procesos y funcionalidades son confirmadas desde el punto de vista técnico.org/ .org.5. http://www. ● El equipo de integración identifica “intercambios” y “casos de uso” ● Las sesiones concluyen con una lista de brechas y cambios funcionales. 10. ● ● ● Página 88/103 Copyright (c) 2007-2008 Cesar Obach-Renner. el grupo responsable de lleva a cabo el análisis lleva a cabo las siguientes actividades: ● Revisión de validaciones ejecutadas por mecanismos preliminares estableciendo el mismo objetivo del intercambio (generalmente las reglas de validación de los mecanismos existentes punto a punto) Identificar Servicios del Negocio y el rol de cada aplicación.SOAr v1.

org. Eliminación de redundancias dentro del lote de requerimientos.org/ . Evaluación de las “oportunidades de optimización” con el equipo de proyecto y arquitectos de aplicativos.gurulab. Considerar aplicación de refactorización para mantener servicios genéricos y cumplir con los nuevos requerimientos al mismo tiempo. Decisión respecto a las “oportunidades de optimización”.org info@gurulab. Gurulab.1Criterios de Alcance de Integración ● Lógica de integración ● En los Servicios del Negocio ● Resolución de solapamiento funcional de Componentes Funcionales ● En las Adaptaciones ● Fenómeno del Cernido Validaciones ● Sintaxis -> A nivel del conector ● Semántica -> A través de mapeos contra el BSI ● Dependencias -> Fuera del alcance ● Sentido -> Fuera del alcance Desnormalización ● Derivación de un dato a partir de otro sin acceder a recursos externos. http://www.2.1 ● ● ● ● Todo proveedor debe atender “en línea” Los consumidores pueden integrarse basado en su preferencia (archivo plano. Página 89/103 Copyright (c) 2007-2008 Cesar Obach-Renner. en línea.SOAr v1. Por ejemplo. conversión. catálogo de producto.3Arquitectura ● ● ● Identifica la realización de cada spec de interacción. etc.5. ● ● 10. Reuso y extensión de servicios existentes (Ciclo de vida de servicios). Transformación de catálogos ● Correlación de referencias cruzadas entre datos entre diferentes sistemas representando el mismo “objeto”. ● ● ● ● 10.5. tales como convivencia. etc. Apilamiento.) ● Ejecución de transformación de espacios vectoriales para simplificación y flexibilidad. Documentación de requerimientos especiales. Documentación del mapeo de los datos en los “intercambios”. para proveer un servicio en línea basado en un proveedor en lotes (batch).

1 10. Retorno de estatus explícito para intercambios asíncronos.4Diseño Para cada servicio debe especificarse la siguiente información: ● ● ● ● “Namespace” y “id scheme” único. 10.gurulab.org info@gurulab.6Pase a producción Una vez entrado en producción un nuevo servicio debe asegurarse un correcto seguimiento de la Gestión del Ciclo de Vida del Servicio: ● Gestión de Ciclo de Vida del Servicio ● Especificación ● Construcción ● Publicación ● Inicio del “Fin de Vida” Página 90/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org. menor su tiempo y pruebas del código de integración.5. Sincronía: Síncrono o Asíncrono Naturaleza: En línea. http://www. Gurulab. o por lotes (Batch) API por Mecanismo: ● WS ● WSDL ● XSD ● CICS Tx ● Commarea ● TX ID ● Flat Files ● XSD ● Example file ● RDBMS ● Connection URL ● Select Seguridad ● login/password para autenticación Transacción o Servicio Compensatorio.org/ .5.SOAr v1.5Construcción y pruebas El proceso de construcción y ejecución de pruebas es específico de la plataforma y en la medida que se realice con herramientas de mayor nivel.5. Información no técnica: ● Cantidad (tráfico) ● Frecuencia ● Tiempo de respuesta requerido Protocolos de pruebas unitarias ● ● ● ● ● 10.

Página 91/103 Copyright (c) 2007-2008 Cesar Obach-Renner.org/ .codehaus. Gurulab. se encuentra desarrollando un software de integración ESB basado en las expectativas de la plataforma ideal planteado en este documento. SOAr puso a prueba el concepto implementando y poniendo en producción un ambiente de integración SOAr utilizando el ESB de Software Libre Mule (http://mule. y así asegurar que la forma como se implementa sea la adecuada para tener una arquitectura de integración EAI de 4ta generación.gurulab.org puede proveer talleres de formación en el uso de Mule. Con el fin de asegurar el concepto en un ambiente Libre. El capítulo “Anatomía de la Plataforma de Integración” provee información concreta que le permitirá identificar cada uno de los elementos del producto de su proveedor.org) Si bien Gurulab.org. http://www. El proyecto de ESB ideal de Gurulab se llama Maya y su código se encuentra varios años en producción intermediando mensajería de texto.7Herramientas de Software Libre Cualquier ESB del mercado hoy en día puede ser utilizado para hacer una implementación de SOAr.1 ● Fin de Vida 10.org info@gurulab.5.SOAr v1. Sin embargo. es muy importante asegurar que la forma como estas herramientas es utilizada es tal como usted lo ha arquitectado. en particular como este documento le muestra debe de implementarse.

mostrando la dinámica y lógica de la secuencia del trabajo. al primero le hemos llamados “Modelo de Intercambio” y al segundo “Modelo de Interacción”.SOAr v1. En un Modelo de Intercambio las aplicaciones se comunican entre si directamente. donde A y B son aplicativos que requieren comunicarse.org info@gurulab.2 Procedimiento Conjunto o sucesión de pasos.1 11 Glosario 11. incluyendo el qué. atienda las peticiones emitidas por un aplicativo y este tenga la capacidad de emitir una respuesta que pueda ser entendida por la aplicación solicitante del servicio. es decir no existe intermediario alguno entre ellas. Gurulab.gurulab.4 Intercambios vs Servicios vs Interacción Existen básicamente dos modelos de comunicación entre aplicativos. esta comunicación está representada en la siguiente Figura. 11. en el que se agrega valor a un insumo y se contribuye a satisfacer una necesidad. http://www. Intercambio: es la interacción entre dos sistemas o envío de información de un sistema a otro mediante un mediador ya sea on line o batch.org/ . cómo y a quién corresponde el desarrollo de la tarea. por lo tanto los servicio manejados por ambas deben tener un mismo estándar o al menos deben estar diseñadas de tal forma que la aplicación proveedora del servicio. orientadas a la consecución de un resultado.1 Proceso Serie de actividades secuenciales e interdependientes.org. ampliamente vinculados y cronológicamente dispuestos. 11.3 Diagrama de flujo Representación gráfica de un proceso o de un procedimiento que permite la observación sistemática de su ejecución. realizados al interior de la entidad por el servidor público y dirigidos a precisar la forma de hacer algo. 15 Página 92/103 Copyright (c) 2007-2008 Cesar Obach-Renner. 11. Para este modelo. la comunicación está constituida por un intercambio15 entre dos aplicaciones.

resultan en un trabajo realizado por otros computadores llamados servidores17.org info@gurulab. pues es una arquitectura que proporciona al usuario final el acceso transparente a las aplicaciones. este intermediario es la plataforma de integración. Página 93/103 Copyright (c) 2007-2008 Cesar Obach-Renner. En el segundo modelo llamado Modelo de Interacción. El planteamiento descrito anteriormente se ilustra en la siguiente Figura. El servidor (S) es un proveedor de servicios.org. es decir existe un intermediario. Figura 31: Interacción 16 17 El cliente (C) es un consumidor de servicios. debe solicitar el servicio a la plataforma de integración P y esta gestiona la petición interactuando directamente con B. servicios de cómputo o cualquier otro recurso del grupo de trabajo y/o. http://www. datos. posteriormente B emite una respuesta la cual viaja hasta P y esta la entrega al aplicativo A. Gurulab.org/ .1 Figura 30: Intercambio La arquitectura Cliente Servidor podría ser considerado un ejemplo de comunicación de intercambio. en múltiples plataformas.SOAr v1. De tal forma que es si un aplicativo A desea comunicarse con un aplicativo B. a través de la organización. la comunicación entre las aplicaciones no se realiza directamente.gurulab. Esta arquitectura soporta un medio ambiente distribuido en el cual los requerimientos de servicio hechos por estaciones de trabajo inteligentes o clientes16.

siendo algunas de estas las siguientes: 1. que forman parte de un intercambio. 18 Página 94/103 Copyright (c) 2007-2008 Cesar Obach-Renner. básicamente comunican mensajes XML utilizando el protocolo SOAP (protocolo de acceso simple a objetos) y son descritos por un IDL llamado WSDL (WebService Description Language). Define un protocolo que garantiza la confiabilidad del mensaje 3. pues la plataforma de integración podría establecer mecanismos para adaptar los mensajes de tal forma que puedan ser entendidos por los aplicativos que desean comunicarse. WS-Reliability. 11.org info@gurulab. Todo intercambio tiene como mínimo 2 interacciones. WS-Security.5 Webservices El servicio web es esencialmente un conjunto de protocolos y estándares que sirven para ejecutar servicios e intercambiar datos entre aplicaciones.SOAr v1.org. Define un mecanismo para el manejo de transacciones Interacción: Es la acción que se ejecuta entre una aplicación y la capa de integración. Gurulab. http://www.1 Por lo tanto se pueden afirmar que las aplicaciones se comunican a través de una interacción18 con una plataforma de integración utilizando un mecanismo de pasaje de mensajes.org/ . Adicionalmente a las especificaciones de los servicios web. Define cómo cifrar y firmar ( para su autenticación ) el contenido de un mensaje xml transportado por el servicio web 2. Esto implica que no necesariamente los servicios manejados por las aplicaciones deben tener un mismo estándar.gurulab. WS-Transaction. el consorcio de interoperabilidad de webservices (WS-I) ha establecido una serie de extensiones que complementan su utilidad.

which is a copyleft license designed for free software. because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. APPLICABILITY AND DEFINITIONS Página 95/103 Copyright (c) 2007-2008 Cesar Obach-Renner. MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document.2002 Free Software Foundation. but changing it is not allowed. textbook. 1. regardless of subject matter or whether it is published as a printed book. Fifth Floor. November 2002 Copyright (C) 2000.html No se presenta una versión en el Idioma Español por no existir una versión oficial en dicho idioma. http://www. But this License is not limited to software manuals.org/ . We recommend this License principally for works whose purpose is instruction or reference. Boston.org. either commercially or noncommercially. while not being considered responsible for modifications made by others.gnu. Gurulab. it can be used for any textual work. 51 Franklin St. PREAMBLE The purpose of this License is to make a manual.1 12 GNU Free Documentation License A continuación se presenta la licencia de Documentación Libre según la FSF la cual está publicada en http://www.2001.org info@gurulab. It complements the GNU General Public License. GNU Free Documentation License Version 1.SOAr v1. this License preserves for the author and publisher a way to get credit for their work.org/copyleft/fdl. This License is a kind of "copyleft". Inc. Secondarily. 0. which means that derivative works of the document must themselves be free in the same sense. or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it. We have designed this License in order to use it for manuals for free software.gurulab. with or without modifying it.2.

1 This License applies to any manual or other work. A "Transparent" copy of the Document means a machine-readable copy.org info@gurulab. (Thus. commercial. The "Invariant Sections" are certain Secondary Sections whose titles are designated. A Front-Cover Text may be at most 5 words. or with modifications and/or translated into another language. that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor. as being those of Invariant Sections. to use that work under the conditions stated herein. refers to any such manual or work. in any medium. and a Back-Cover Text may be at most 25 words. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. if the Document is in part a textbook of mathematics. and is addressed as "you". You accept the license if you copy. A "Modified Version" of the Document means any work containing the Document or a portion of it. in the notice that says that the Document is released under this License.org/ . as Front-Cover Texts or Back-Cover Texts. royalty-free license. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. a Secondary Section may not explain any mathematics. modify or distribute the work in a way requiring permission under copyright law. The "Document". Such a notice grants a worldwide. http://www.gurulab. below. unlimited in duration. either copied verbatim. represented in a format whose specification is available to the general public. ethical or political position regarding them. in the notice that says that the Document is released under this License. Gurulab. The "Cover Texts" are certain short passages of text that are listed.org. philosophical. and Página 96/103 Copyright (c) 2007-2008 Cesar Obach-Renner. or of legal.) The relationship could be a matter of historical connection with the subject or with related matters. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.SOAr v1. Any member of the public is a licensee.

XCF and JPG.) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. Gurulab. the title page itself.gurulab. A copy made in an otherwise Transparent file format whose markup. and standard-conforming simple HTML. the material this License requires to appear in the title page. Texinfo input format. PostScript or PDF designed for human modification. or "History". A copy that is not "Transparent" is called "Opaque". The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document.1 that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. For works in formats which do not have any title page as such. "Title Page" means the text near the most prominent appearance of the work's title. "Dedications". Página 97/103 Copyright (c) 2007-2008 Cesar Obach-Renner. LaTeX input format.org/ . http://www. and the machine-generated HTML. plus such following pages as are needed to hold. Examples of transparent image formats include PNG. for a printed book.org info@gurulab. but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License. legibly. Examples of suitable formats for Transparent copies include plain ASCII without markup. The "Title Page" means. "Endorsements". has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. SGML or XML using a publicly available DTD. (Here XYZ stands for a specific section name mentioned below. such as "Acknowledgements". or absence of markup. SGML or XML for which the DTD and/or processing tools are not generally available.org. PostScript or PDF produced by some word processors for output purposes only. preceding the beginning of the body of the text. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors. These Warranty Disclaimers are considered to be included by reference in this License.SOAr v1.

If you distribute a large enough number of copies you must also follow the conditions in section 3. either commercially or noncommercially. can be treated as verbatim copying in other respects.SOAr v1. you may accept compensation in exchange for copies. Both covers must also clearly and legibly identify you as the publisher of these copies. and the license notice saying this License applies to the Document are reproduced in all copies. provided that this License. 3. all these Cover Texts: Front-Cover Texts on the front cover. you must enclose the copies in covers that carry. You may add other material on the covers in addition. Gurulab. free of added material. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. http://www. The front cover must present the full title with all words of the title equally prominent and visible. and that you add no other conditions whatsoever to those of this License. you should put the first ones listed (as many as fit reasonably) on the actual cover. clearly and legibly. you must either include a machine-readable Transparent copy along with each Opaque copy. the copyright notices. and continue the rest onto adjacent pages. However. COPYING IN QUANTITY If you publish printed copies (or copies in media that commonly have printed covers) of the Document. and Back-Cover Texts on the back cover. If you publish or distribute Opaque copies of the Document numbering more than 100. and the Document's license notice requires Cover Texts. If the required texts for either cover are too voluminous to fit legibly. under the same conditions stated above. you must take reasonably prudent steps. You may also lend copies. numbering more than 100. Copying with changes limited to the covers.org/ .1 2. VERBATIM COPYING You may copy and distribute the Document in any medium. If you use the latter option.org info@gurulab. and you may publicly display copies. or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document. when Página 98/103 Copyright (c) 2007-2008 Cesar Obach-Renner. as long as they preserve the title of the Document and satisfy these conditions.gurulab.org.

Preserve the section Entitled "History". if any) a title distinct from that of the Document. but not required.org/ . and add to it an item stating at least the title. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. Use in the Title Page (and on the covers. together with at least five of the principal authors of the Document (all of its principal authors. a license notice giving the public permission to use the Modified Version under the terms of this License. I. Gurulab. H. List on the Title Page. you must do these things in the Modified Version: • A. http://www. as authors. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above. Preserve all the copyright notices of the Document. Include an unaltered copy of this License. F.gurulab.1 you begin distribution of Opaque copies in quantity. as the publisher. and publisher of the Document as given on its • • • • • • • • Página 99/103 Copyright (c) 2007-2008 Cesar Obach-Renner. provided that you release the Modified Version under precisely this License. State on the Title page the name of the publisher of the Modified Version. in the form shown in the Addendum below. new authors. thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. C. create one stating the title. to give them a chance to provide you with an updated version of the Document. Include. with the Modified Version filling the role of the Document. D. authors.org. It is requested. and from those of previous versions (which should. be listed in the History section of the Document). immediately after the copyright notices. If there is no section Entitled "History" in the Document. and publisher of the Modified Version as given on the Title Page. if there were any. one or more persons or entities responsible for authorship of the modifications in the Modified Version. In addition. G. Preserve its Title.org info@gurulab.SOAr v1. B. if it has fewer than five). that you contact the authors of the Document well before redistributing any large number of copies. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. unless they release you from this requirement. You may use the same title as a previous version if the original publisher of that version gives permission. 4. year. to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. E. year.

then add an item describing the Modified Version as stated in the previous sentence. Such a section may not be included in the Modified Version. Delete any section Entitled "Endorsements". unaltered in their text and in their titles. O. If the Document already includes a cover text for the same cover.SOAr v1. Preserve any Warranty Disclaimers. http://www. M. To do this. Página 100/103 Copyright (c) 2007-2008 Cesar Obach-Renner. or if the original publisher of the version it refers to gives permission. previously added by you or by arrangement made by the same entity you are acting on behalf of. You may omit a network location for a work that was published at least four years before the Document itself.org info@gurulab. For any section Entitled "Acknowledgements" or "Dedications". Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. Preserve the network location. You may add a section Entitled "Endorsements". provided it contains nothing but endorsements of your Modified Version by various parties-for example.1 • • • • • • Title Page. These may be placed in the "History" section. You may add a passage of up to five words as a Front-Cover Text. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. K.gurulab. Preserve the Title of the section.org. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document. and likewise the network locations given in the Document for previous versions it was based on. L.org/ . N. Section numbers or the equivalent are not considered part of the section titles. on explicit permission from the previous publisher that added the old one. add their titles to the list of Invariant Sections in the Modified Version's license notice. given in the Document for public access to a Transparent copy of the Document. Preserve all the Invariant Sections of the Document. but you may replace the old one. to the end of the list of Cover Texts in the Modified Version. J. you may at your option designate some or all of these sections as invariant. if any. and preserve in the section all the substance and tone of each of the contributor acknowledgements and/ or dedications given therein. you may not add another. and a passage of up to 25 words as a Back-Cover Text. Gurulab. These titles must be distinct from any other section titles.

You must delete all sections Entitled "Endorsements. and distribute it individually under this License. you must combine any sections Entitled "History" in the various original documents.org. unmodified. provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. and that you preserve all their Warranty Disclaimers. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License. provided you insert a copy of this Página 101/103 Copyright (c) 2007-2008 Cesar Obach-Renner. http://www. In the combination." 6. and any sections Entitled "Dedications".gurulab. under the terms defined in section 4 above for modified versions. The combined work need only contain one copy of this License. the name of the original author or publisher of that section if known. in parentheses. You may extract a single document from such a collection.SOAr v1. 5. and list them all as Invariant Sections of your combined work in its license notice. likewise combine any sections Entitled "Acknowledgements".org info@gurulab. COMBINING DOCUMENTS You may combine the Document with other documents released under this License. forming one section Entitled "History". Gurulab. and replace the individual copies of this License in the various documents with a single copy that is included in the collection. make the title of each such section unique by adding at the end of it. or else a unique number. If there are multiple Invariant Sections with the same name but different contents. and multiple identical Invariant Sections may be replaced with a single copy.org/ . provided that you include in the combination all of the Invariant Sections of all of the original documents. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.1 The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

or the electronic equivalent of covers if the Document is in electronic form. 8. or "History". You may include a translation of this License.1 License into the extracted document. If the Cover Text requirement of section 3 is applicable to these copies of the Document.org. When the Document is included in an aggregate. then if the Document is less than one half of the entire aggregate. Otherwise they must appear on printed covers that bracket the whole aggregate. in or on a volume of a storage or distribution medium. 7. Página 102/103 Copyright (c) 2007-2008 Cesar Obach-Renner. so you may distribute translations of the Document under the terms of section 4. is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works. the original version will prevail. provided that you also include the original English version of this License and the original versions of those notices and disclaimers.org/ .org info@gurulab. and follow this License in all other respects regarding verbatim copying of that document.gurulab. "Dedications". Gurulab.SOAr v1. and all the license notices in the Document. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer. http://www. this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If a section in the Document is Entitled "Acknowledgements". but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. Replacing Invariant Sections with translations requires special permission from their copyright holders. TRANSLATION Translation is considered a kind of modification. the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate. the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title. and any Warranty Disclaimers.

SOAr v1. If the Document specifies that a particular numbered version of this License "or any later version" applies to it. http://www. sublicense. If the Document does not specify a version number of this License.org/ .1 9.org. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new.gnu. 10. and will automatically terminate your rights under this License. Any other attempt to copy. Such new versions will be similar in spirit to the present version. parties who have received copies. See http://www. modify. TERMINATION You may not copy. modify. However. you may choose any version ever published (not as a draft) by the Free Software Foundation.org/copyleft/. or distribute the Document except as expressly provided for under this License. you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation.org info@gurulab. or rights. revised versions of the GNU Free Documentation License from time to time. from you under this License will not have their licenses terminated so long as such parties remain in full compliance. but may differ in detail to address new problems or concerns. Each version of the License is given a distinguishing version number. Página 103/103 Copyright (c) 2007-2008 Cesar Obach-Renner. sublicense or distribute the Document is void.gurulab. Gurulab.