curso SOA español

SOAr v1.1

Página 1/103Copyright (c) 2007-2008 Cesar Obach-Renner, [email protected], 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)

AutorCésar Obach-Renner

Junio 2008


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 Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License”.


SOAr v1.1

1 Contenido1 CONTENIDO .............................................................................................................................. 4

2 PRÓLOGO .................................................................................................................................. 7

3 PREFACIO ................................................................................................................................. 8

3.1 SOBRE GURULAB .......................................................................................................................... 8 3.2 ¿QUIÉN DEBE LEER ESTE LIBRO? ..................................................................................................... 9 3.3 SITIO WEB DE APOYO E INFORMACIÓN DE CONTACTO ......................................................................... 10 3.4 SOBRE LOS TÉRMINOS EN INGLÉS. .................................................................................................. 10 3.5 WATERMARK .............................................................................................................................. 10 3.6 DEDICATORIA Y AGRADECIMIENTOS ............................................................................................... 11

4 INTRODUCCIÓN .................................................................................................................... 12

5 ¿QUÉ ES SOAR? ...................................................................................................................... 19

5.1 SOAR COMO 4TA GENERACIÓN DE EAI ........................................................................................ 23 5.1.1 Primera generación: Integración punto a punto .......................................................... 23 5.1.2 Segunda generación: Integración por Broker .............................................................. 24 5.1.3 Tercera generación: SOA ............................................................................................ 25 5.1.4 Cuarta generación: SOAr ............................................................................................ 27

5.2 BENEFICIOS DE SOAR ................................................................................................................ 30 5.3 SOAR Y BPM .......................................................................................................................... 32 5.4 ELEMENTOS CLAVES DE UNA IMPLEMENTACIÓN EXITOSA DE SOAR ..................................................... 33

6 ESPECIFICACIÓN DE SERVICIOS DEL NEGOCIO (BSI) .............................................. 34

6.1 CALIDAD DE LA BSI ................................................................................................................... 34 6.1.1 Fenómeno del Cernido ................................................................................................. 35 6.1.2 Criterios para generar una BSI de buena calidad ........................................................ 37

6.2 HERENCIA FUNCIONAL ................................................................................................................. 38 6.2.1 Agregación de funcionalidades ortogonales ................................................................ 39 6.2.2 Agregación de funcionalidades no ortogonales ........................................................... 39

6.3 ESPECIFICACIONES ESTÁNDARES DE INDUSTRIA ................................................................................. 40 6.3.1 Telecomunicaciones ..................................................................................................... 40

6.3.1.1 eTOM .................................................................................................................... 41 6.3.1.2 TAM ..................................................................................................................... 42 6.3.1.3 SID ........................................................................................................................ 43 6.3.1.4 MTOSI .................................................................................................................. 44 6.3.1.5 OSS/J .................................................................................................................... 45

6.4 OTRAS INDUSTRIAS ..................................................................................................................... 48

7 ASPECTOS TÉCNICOS .......................................................................................................... 50

7.1 ANATOMÍA DE LA PLATAFORMA DE INTEGRACIÓN ............................................................................ 50 7.1.1 Nivel 1 .......................................................................................................................... 51 7.1.2 Nivel 2 .......................................................................................................................... 53 7.1.3 Plataforma ideal .......................................................................................................... 54

7.2 DESARROLLO DE CONECTORES ....................................................................................................... 55 7.2.1 Características técnicas .............................................................................................. 55 7.2.2 Características funcionales .......................................................................................... 57

7.3 IMPLEMENTACIÓN DE SERVICIOS DEL NEGOCIO .................................................................................. 58


SOAr v1.1

8 CONSIDERACIONES ESTRATÉGICAS .............................................................................. 59

8.1 SISTEMA NERVIOSO EMPRESARIAL ................................................................................................ 59 8.2 ESTRATEGIA DE IMPLEMENTACIÓN .................................................................................................. 60

8.2.1 Ejemplo de una Iteración ............................................................................................. 60 8.3 ENFOQUE PRAGMÁTICO ................................................................................................................ 64 8.4 MODELO DE SERVICIO .................................................................................................................. 67

9 RECOMENDACIONES DE IMPLEMENTACIÓN .............................................................. 69

9.1 MODELAJE DE PROCESOS .............................................................................................................. 69 9.1.1 Definición .................................................................................................................... 69 9.1.2 Componentes básicos ................................................................................................... 69 9.1.3 Consideraciones ........................................................................................................... 70 9.1.4 Actores ......................................................................................................................... 70 9.1.5 ¿Cómo identificar un proceso? .................................................................................... 71 9.1.6 Aspectos relevantes ...................................................................................................... 71 9.1.7 Representación gráfica ............................................................................................... 72

9.1.7.1 El diagrama ........................................................................................................... 72 9.1.7.2 Características ....................................................................................................... 72 9.1.7.3 Ventajas ................................................................................................................ 72

9.1.8 Recomendaciones ......................................................................................................... 73 9.2 NOMENCLATURA ......................................................................................................................... 73

9.2.1 Flujos de Servicios ....................................................................................................... 74 9.2.2 Nodos (N** ) ................................................................................................................ 75 9.2.3 Nodos de Entrada/Salida (NIN_ / NOU_ ) ................................................................... 76 9.2.4 Nodos de Mapeo (NMP_) ............................................................................................. 76 9.2.5 Nodos de Transformación (NT*_) ................................................................................ 76 9.2.6 Servicios Genéricos & Servicios Específicos ............................................................... 77

10 METODOLOGÍA ................................................................................................................... 78

10.1 PREMISAS ................................................................................................................................ 78 10.2 COMPARACIÓN CON OTROS MODELOS ............................................................................................ 79

10.2.1 IBM ............................................................................................................................ 80 10.2.2 RUP ........................................................................................................................... 80 10.2.3 Sun Microsystems ....................................................................................................... 80 10.2.4 SOA Institute .............................................................................................................. 81 10.2.5 SAP ............................................................................................................................ 82

10.3 CICLO DE VIDA DE UN SERVICIO .................................................................................................. 82 10.4 GOBERNABILIDAD ..................................................................................................................... 84

10.4.1 Roles .......................................................................................................................... 84 10.4.2 Funciograma .............................................................................................................. 84

10.5 PROCESO ................................................................................................................................. 85 10.5.1 Documentación del requerimiento ............................................................................. 88 10.5.2 Análisis ...................................................................................................................... 88

10.5.2.1 Criterios de Alcance de Integración .................................................................... 89 10.5.3 Arquitectura ............................................................................................................... 89 10.5.4 Diseño ........................................................................................................................ 90 10.5.5 Construcción y pruebas .............................................................................................. 90 10.5.6 Pase a producción ...................................................................................................... 90 10.5.7 Herramientas de Software Libre ................................................................................ 91

11 GLOSARIO ............................................................................................................................. 92

11.1 PROCESO ................................................................................................................................. 92


SOAr v1.1

11.2 PROCEDIMIENTO ....................................................................................................................... 92 11.3 DIAGRAMA DE FLUJO ................................................................................................................. 92 11.4 INTERCAMBIOS VS SERVICIOS VS INTERACCIÓN .............................................................................. 92 11.5 WEBSERVICES .......................................................................................................................... 94

12 GNU FREE DOCUMENTATION LICENSE ....................................................................... 95


SOAr v1.1

2 Prólogo


SOAr v1.1

3 PrefacioLuego de tres años en el proceso de conceptualización, ingeniería básica y detallada de una Arquitectura de Integración Orientada a Servicios, he sintetizado una aproximación a la integración de aplicaciones empresariales (EAI) que se basa en la implementación de una Arquitectura Orientada a Servicios (SOA).

A lo largo de este documento, el lector tendrá la oportunidad de entender el valor diferenciador de esta aproximación de SOA la cual llamo “SOA recargado” (SOAr), respecto a cualquier otro enfoque de integración de aplicaciones. Aprenderá las razones que justificarán, tanto del punto de vista técnico como económico y de negocio implementar esta aproximación y adicionalmente tendrá a la mano una metodología probada que le ayudará a implementar un proyecto por muy grande o ambicioso que éste sea.

A finales del año 2005 luego de la fase de concepción de SOAr y construcción de los elementos fundamentales de la arquitectura, llegó el momento de ponerlo en práctica en el primer proyecto con alcances, fechas y presupuesto reales.

Para enfrentar dicho proyecto se realizó una importante búsqueda de metodologías para implantar SOA a través de las principales compañías de consultoría e integración de TI internacionales, la cual resultó en la conclusión de que no había a la mano ni una metodología ni la experiencia necesaria para implementar una arquitectura de integración basada en servicios. Ante esta situación, creé una metodología que fue utilizada durante las fases de análisis, diseño y construcción de las integraciones que el proyecto requería, la cual ha sido documentada en este libro.

Dicha metodología es parte del framework de integración SOAr (http://www.soarframework.org/) y siendo uno de sus componentes es llamada “Metodología SOAr”. El framework se encuentra en un proceso de mejora continua gracias a la colaboración de Gurulab.org y de su comunidad de usuarios que aportan sus experiencias y oportunidades de mejora.

Adicionalmente a la la conceptualización y metodología, el framework SOAr contiene herramientas que facilitan la implementación de un proyecto de integración basada en SOA.

3.1 Sobre GurulabGurulab.org es un laboratorio de innovación tecnológica dirigido por Cesar Obach-Renner el cual busca el desarrollo de tecnologías de información y comunicación o usos innovadores de éstos, apalancados en la imaginación y conocimiento de sus miembros.


SOAr v1.1

Adicionalmente a las innovaciones que ha incursionado en los últimos 10 años, Gurulab.org ha logrado una buena experiencia en la ejecución de hazañas tecnológicas para varios de sus clientes.

El laboratorio opera de manera distribuida a nivel mundial y sus miembros se reúnen varias veces al año en convención para presentar sus trabajos. En su plan estratégico se plantea construir una base de operaciones que le permita con un presupuesto base desarrollar iniciativas de investigación, desarrollo y formación de especialistas técnicos en temas de Arquitectura, Tecnología e Innovación.

El vehículo que Gurulab.org utiliza para entregar sus innovaciones son las licencias del proyecto GNU (http://www.gnu.org/) GPL para el software, y FDL para las practicas y documentaciones como SOAr.

Entre sus iniciativas, además del framework SOAr, se encuentra un ESB software libre para implementación de integración SOA y SOAr llamado Mula, y un framework de desarrollo rápido de aplicaciones llamado Jasolina.

Gurulab, adicionalmente a sus procesos de investigación y desarrollo, provee servicios de educación y asesoría para asegurar la adecuada adopción de las tecnologías que domina.

3.2 ¿Quién debe leer este libro?Este libro está dirigido a quienes buscan una forma pragmática de implementar SOA, a quienes luchan por lograr una plataforma de sistemas estable y que le permita proveer mayor valor al negocio.

Si bien este libro está orientado a Gerentes de Sistemas, Arquitectos de Tecnologías de Información y especialistas de integración; cubre el tópico de 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). Esto significa que todo profesional del área de sistemas y/o tecnologías de información entenderá perfectamente los conceptos y planteamientos hechos aquí.

El propósito es transmitir claramente el concepto de SOAr, cuáles son sus beneficios, cómo debe observarse la plataforma tecnológica a ser utilizada y una orientación inicial de cómo debe realizarse un proyecto de implementación con esta práctica.

Por ser introductorio, este documento puede ser una referencia para todo aquel que quiera extender sus conocimientos en los temas de SOA e integración de aplicaciones empresariales.


http://www.gnu.org/

SOAr v1.1

3.3 Sitio web de apoyo e información de contactoEsta publicación es el documento oficial del concepto SOAr perteneciente al Framework de SOAr (en inglés SOAr Framework), ambos disponibles bajo licenciamiento de documentación Libre de GNU (http://www.gnu.org/).

El URL oficial del Framework de SOAr es http://www.gurulab.org/ y en dicho lugar se encuentra descrito claramente su valor y cada uno de sus componentes.

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, los componentes del Framework de SOAr son:

● El libro "SOAr - El concepto" (Cookbook)● Especificación de Servicios del Negocio (BSI)● Cursos y Talleres● Casos exitosos● Integradores experimentados● Plataformas de Integración (ESBs)

3.4 Sobre los términos en Inglés.La versión en español de este documento utiliza los acrónimos de los términos en inglés de manera estándar. Esto debido a mantener las referencias de los conceptos en su idioma de origen y no generar una traducción que pueda crear confusión en el lector.

Seguramente a medida que estos conceptos vayan adoptándose de manera general en regiones de habla hispana, sus traducciones al español serán mejor conocidas y entonces tendrá sentido generar una revisión de este documento incluyendo dichas traducciones “de facto”.

3.5 watermarkMinor Earth Mayor Sky @A-HaThought That It Was You @A-HaShe's Madonna @Robbie WilliamsThe 80's @Robbie Williams


http://www.gurulab.org/

http://www.gnu.org/

SOAr v1.1

3.6 Dedicatoria y AgradecimientosLe 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.


mailto:[email protected]


SOArv1.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.



mailto:[email protected]

SOArv1.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).

App 1 App 2 … App np1 p2 p3 … pj

c1 c1 c1 c1

GUI App 1 GUI App 2 … GUI App n

NGITP Maturity Model

1 - Silos

Nivel de Madurez

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


SOArv1.1

o deseados, o sean buenos o malos, estén en la caja o fuera de ella), sino que le proveería de una gran flexibilidad en la modificación de sus procesos como respuesta a ambientes y mercados cambiantes y dinámicos.

Bastaría con conseguir una aplicación que tuviese esa capacidad “súper configurable” y lograríamos el objetivo; sin embargo nos topamos con una realidad inevitable: en ambientes empresariales de mediana complejidad en adelante, nos conseguimos con el hecho ineludible de que no existe un solo fabricante que provea todos los componentes de la plataforma de TI cumpliendo con todos los requerimientos del negocio que van más allá de los técnicos como por ejemplo, seguridad, calidad, precios, soporte, relación, etc.

Desarrollando solo algunos de los puntos indicados, respecto a “seguridad”, el hecho de que una empresa posea un solo proveedor de todos sus componentes de TI, implica un riesgo importante que tiende a desaparecer cuando se tienen a varios proveedores. Respecto al costo, el mercado puede ofrecer sin duda alguna más de un proveedor que ofrece una solución con las mismas prestaciones pudiendo ser el “proveedor alternativo” quien provea un mejor precio, resultando una mejor oferta de negocio.

Esto implica un problema, ya que al tener aplicativos de distintos fabricantes, aún asumiendo que todos sean “súper configurables”, los procesos vivirán de manera aislada a menos que sean sincronizados a través de la integración entre dichas aplicaciones o exista “algo” de nivel superior, extra-aplicación que controle los procesos.

En el caso de la “sincronización”, sin un elemento superior que controle los procesos, las aplicaciones perderían flexibilidad dado que la “sincronización” establecería una restricción a los procesos que “sincroniza” la cual debería ser administrada de manera independiente; en este escenario, las aplicaciones súper-configurables pierden su flexibilidad.

La mayoría de las empresas que hoy en día tienen una práctica madura de integración se encuentran en este estadio, la cual corresponde independientemente de que las aplicaciones sean “súper configurables” o no, al nivel 2 del modelo de madurez del NGITP (ver Figura 2)


SOArv1.1

App 1 App 2 … App n

Bus

p1 p2 p3 … pj

c1 c1 c1 c1



1 - Silos

2 - EAI

Nivel de Madurez

Figura 2 Nivel 2 del modelo de madurez del NGITP

Solo queda válido como respuesta a nuestro planteamiento el escenario en el que el proceso es controlado por “algo” de nivel superior. Este escenario implica que las aplicaciones no controlan procesos sino que sirven “tareas” o “funcionalidades” a ese ente superior que controla los procesos llamaremos “Gestor de Procesos”.

Esta conclusión a la que estamos llegando es clara para muchos Arquitectos empresariales y fabricantes de aplicativos en todo el mundo, quienes convergen en la necesidad de desacoplar la gestión de los procesos de la musculatura de ejecución de transacciones que representan las aplicaciones bajo este nuevo enfoque.

La casa de Walldorf lo acepta también no solo sacando al mercado herramientas para coreografía de procesos, sino generando rutas de evolución de sus aplicaciones para sacar los procesos de sus cajas hacia su coreógrafo de procesos.

Ahora bien, ¿cuál es el estado de nuestra solución? Hemos dibujado hasta ahora una plataforma que consta de una colección heterogénea de aplicaciones que exponen funcionalidades o tareas que son “orquestadas” por un gestor de procesos. Como puede verse, ahora lo “súper configurable” no es una característica a buscar en las aplicaciones, sino en la arquitectura que se establece entre el Gestor de Procesos y los aplicativos.


SOArv1.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, de las aplicaciones que realmente serán las responsables de ejecutarlas.

De esta manera, el desarrollo de las reglas del negocio basadas en procesos son independientes de la colección de aplicaciones que la plataforma de sistemas tenga en cualquier momento. Esto le devuelve al negocio el poder de sus procesos, delegando únicamente a Tecnología la tarea de proveer los componentes sobre los cuales viven los procesos.

Esto es logrado a través de la exposición de servicios que muestran una vista de las funcionalidades y datos de las aplicaciones subyacentes en un formato canónico simple, idealmente estándar. Esto es lo que el modelo de madurez de NGITP plantea como nivel 3 (ver Figura 3). A estos servicios les llamamos “Servicios del Negocio”.


Bus

S1 S2 S3 … Sm

p1 p2 p3 … pj

c1 c1 c1 c1



1 - Silos

2 - EAI

3 -ServiciosCorporativos

Nivel de Madurez


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.


SOArv1.1

Basado en los servicios corporativos, el gestor de procesos permite modelar procesos y ejecutarlos a lo largo y ancho de la plataforma de tecnología, permitiéndole al negocio evolucionarlo con la rapidez que sea requerido por lo dinámico del entorno, sin necesidad de depender de modificaciones a nivel de sistemas.

En Figura 4 se muestra el nivel 4 del modelo de madurez del NGITP, el cual muestra cómo a diferencia del nivel anterior, los procesos viven en el Gestor de Procesos y no en las aplicaciones.


Bus

S1 S2 S3 … Sm

Process Managerp1 p2 p3 … pj

c1 c1 c1 c1

GUI p1 GUI p2 … GUI pj


1 - Silos

2 - EAI

3 -

4 - BPM

ServiciosCorporativos

Nivel de Madurez


En dicha Figura note cómo la interfaz gráfica ya no corresponde a interfaces de aplicaciones sino de procesos, es decir, en lugar de que los usuarios interactúen con las funcionalidades de las aplicaciones a través de ellas, lo harán en el contexto de los procesos orquestados por el Gestor de Procesos y a través de él. 3) Una interfaz de usuario para ejecución de procesos que se construya automáticamente a partir de la definición del proceso.

Como elemento final del modelo de madurez, tal como se muestra en la Figura 5, el nivel 5 incorpora tecnología que adapta de manera automática las interfaces de interacción hombre-máquina para permitir la interacción de los usuarios con los procesos modelados en el Gestor de Procesos.


SOArv1.1


Bus

S1 S2 S3 … Sm


SmartInterface

c1 c2 … ci


1 - Silos

2 - EAI

3 -

4 - BPM

5 - SmartInterface


Nivel de Madurez


En la figura del nivel 5, se puede observar que existe una sola lógica de interfaz que se adapta a todos los procesos por cada canal. En particular, el primer canal ejemplificado es el canal Web.

Este nivel provee no solo la ventaja de bajo costo en el mantenimiento de las interfaces para soportar nuevos canales, sino que al final del día para poder cambiar los procesos que se ejecutan en la empresa, basta con cambiar su definición e instantáneamente el sistema se adapta a la nueva definición. El modelo de interfaz adaptable es llamado SmartInterface como un concepto incorporado por NGITP.


SOArv1.1

5 ¿Qué es SOAr?

SOAr es una forma de integrar aplicaciones y procesos basado en una Arquitectura Orientada a Servicios (SOA), la cual tiene como objetivo principal aislar toda aplicación de la plataforma de tecnología o proceso del negocio, del resto de la arquitectura; SOAr logra esto simplificando de manera importante cualquier esfuerzo de integración empresarial, logrando:

Desacoplar la plataforma de TI de los procesos del negocio. Desacoplar las aplicaciones unas de otras, escondiendo la complejidad

del conjunto de aplicaciones existente a cualquier nueva aplicación que se desea integrar.

Controlar reduciendo los riesgos derivados de los cambios de aplicaciones de la plataforma de sistemas.

Aprovechar al máximo las capacidades de las herramientas tecnológicas existentes actualmente.

Para entender bien como funciona SOAr, imaginemos el caso (ver Figura X) de integrar los procesos de una empresa (por ejemplo, a través de una plataforma de gestión de procesos -BPM-) o una nueva aplicación, a su plataforma de Tecnologías de Información (TI).

Figura 6: Caso de uso: Integración de procesos del negocio o nueva aplicación con plataforma de TI

La plataforma de TI del caso de uso que estamos estudiando, independientemente de la industria a la que pertenece, tiene una gran cantidad de funcionalidades las cuales de manera ideal, estarían implementadas por un grupo ordenado y concreto de “Aplicaciones Ideales” las cuales llamamos Componentes Funcionales. (ver figura X)


SOArv1.1

Los componentes funcionales tienen nombres “comunes” a diferencia de las aplicaciones que tienen nombres “propios”; por ejemplo podríamos decir que la aplicación “GNU/Linux” (nombre propio) es un “Sistema de Operación” (nombre común); como otros ejemplos tenemos “Sistema de Contabilidad”, “Sistema de Recursos Humanos”, “Facturador”, etc.

Si una empresa tuviese una aplicación para cada Componente Funcional requerido, su Plataforma de TI luciría como la figura antes mostrada, la cual muestra un grupo ordenado y simple de aplicaciones con las cuales los procesos o nueva aplicación han de integrarse.

Sin embargo, la realidad de la mayoría de las empresas es que tienen más de una aplicación cumpliendo el mismo Componente Funcional. (ver figura X)

Adicionalmente, todas esas aplicaciones no solo generan una gran redundancia funcional que representa grandes complejidades de administración y mantenimiento, sino que la naturaleza de las integraciones entre las aplicaciones que tradicionalmente han sido utilizadas (fundamentalmente punto a punto), nos presentan una plataforma de TI más compleja como la mostrada en la figura X.


SOArv1.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”, los cuales son la fachada que la plataforma de TI expone a los procesos y nuevas aplicaciones que han de integrarse.

Los Servicios del Negocio expuestos simplifican la Plataforma de TI expuesta dado que encapsula los solapamientos funcionales y complejidades técnicas propias de la heterogeneidad de los componentes de un ambiente de sistemas. En otras palabras, en vez de que los procesos y nuevas aplicaciones se integren a múltiples aplicaciones a través de múltiples tecnologías con múltiples consideraciones respecto a en qué circunstancias que patrón de interacción aplica y en qué otro, simplemente se integran con un único y simple componente funcional a través de una única tecnología.


SOArv1.1

De esta manera, la estrategia de integración de aplicaciones SOAr provee: Simplicidad, porque esconde la complejidad resultante de la redundancia y solapamientos funcionales de las aplicaciones existentes. Por ejemplo, en vez de tener tres sistemas de facturación, SOAr expone uno solo; en vez de tener dos sistemas contables, SOAr expone uno solo.

Estabilidad, porque para todo cliente de las aplicaciones expuestas por SOAr, estas últimas nunca cambian; esto es debido a que aún cuando en realidad las aplicaciones en realidad si cambian, SOAr lo hace transparente a los clientes de manera que estos últimos no se dan cuenta.

Por ejemplo, al instalar un nuevo CRM, SOAr le expone los servicios estándares del Gestor de Ordenes de Servicio. Tras bastidores SOAr orquesta y resuelve la complejidad de tener cinco Gestores de Ordenes de Servicio. Cuando otro proyecto en la búsqueda de la racionalización de las aplicaciones de Gestión de Ordenes de Servicio sustituye tres de los cinco existentes por uno nuevo, el CRM no se entera de tal sustitución gracias a SOAr.

Conveniencia, porque en el contexto del modelo referencial NGITP de Gurulab, SOAr representa un mecanismo para lograr el establecimiento de una Plataforma de Tecnología de Información de Nueva Generación nivel 3.

Eficiencia, porque aprovecha al máximo las características de las plataformas tecnológicas actuales al definir claramente cómo utilizar cada componente de la plataforma de la empresa, independientemente de quien sea el proveedor de cada uno.


SOArv1.1

Como veremos en la siguiente sección, SOAr representa la 4ta generación de la práctica de EAI2, y corresponde a una forma particular de SOA con características resaltantes que lo apuntalan como una práctica diferente y con beneficios concretos.

5.1 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.

A continuación veremos cada una de estas generaciones a saber:

i) Punto a Puntoii) Brokeriii) SOAiv) SOAr

5.1.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; tal como se muestra en la Figura 7, cada aplicación tiene tantas conexiones como el resto de las aplicaciones existentes.

Figura 7 Primera generación de EAI: Punto a punto

El orden de complejidad de las conexiones existentes en este modelo es

Cn2=n2 =

n !2 !− n−2 !

2 EAI por sus siglas en inglés de Enterprise Application Integration.


SOArv1.1

en donde n es el total de aplicaciones a interconectar.

Por ejemplo, para 30 aplicaciones, la combinatoria da 435 conexiones; para 90 aplicaciones, da 4005 conexiones.

El modelo EAI punto a punto puede considerarse como el modelo primal, el cual es resultante de la resolución de las necesidades de integración sin ningún tipo de planificación y con un crecimiento descontrolado.

5.1.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, se encarga de enrutar los mensajes que vienen de una aplicación “origen”, hacia la aplicación “destino” (Ver Figura 8)

Figura 8 Segunda generación de EAI: Hub o Broker de integración

La presencia del Broker logra una menor complejidad en la comunicación entre las aplicaciones. Se simplifica la cantidad de conexiones entre ellas aún cuando a través de estas puedan pasar múltiples tipos de mensajes que el broker al interpretar debe enrutar a la aplicación destino.

Los mensajes que cada una de las aplicaciones envía al broker, además de contener la información que el Broker interpreta para saber hacia qué aplicación enviarlos, contiene la estructura y mensaje que la aplicación destino espera recibir; es decir, el mensaje que una aplicación envía al Broker cumple con el Contrato establecido por la aplicación destino.

Debido a que entonces todas las aplicaciones solo requieren conectarse con el Broker, entonces en este modelo la cantidad de conexiones se simplifica a n, donde n es la cantidad de aplicaciones a interconectar.


SOArv1.1

5.1.3 Tercera generación: SOADesde la perspectiva de Arquitectura Empresarial, SOA (del inglés “Service Oriented Architecture”) o Arquitectura Orientada a Servicios es un patrón de Arquitectura que afecta todas los diferentes puntos de vista bajo los cuales cualquier tema o artefacto de TI puede ser discretizado; desde la perspectiva del modelo referencial de Arquitectura Empresarial de Gurulab, los dominios pilares a los que el patrón de SOA afectaría son Datos, Aplicación, Integración, Acceso, Infraestructura, Seguridad y Gestión de Sistemas.

Muchos fabricantes de aplicaciones suelen promocionar la idea de que al incluir en su producto un conjunto de servicios web que exponen las funcionalidades de su aplicativo, están proveyendo una aplicación “Compatible con SOA”.

Si bien esto no es equivocado, lo que ha ocurrido en el mercado es que las empresas han entendido que al integrar sus aplicaciones al hacer uso de estos servicios expuestos por los aplicativos, están implementando una Arquitectura Orientada a Servicios.

Sin generar ningún juicio de valor, Gurulab ha catalogado esta práctica como tercera generación de EAI, mejor conocido como integración SOA, una colección de servicios que colaboran entre si.

Dado que el planteamiento de arquitectura tradicional se ha basado en un modelo de “colección de aplicaciones” que encapsula completamente todas sus funcionalidades detrás de sus interfaces gráficas, SOA provee la gran ventaja de permitir y fomentar el reuso de funcionalidades ya implementadas por los aplicativos existentes al estar éstas expuestas completamente a través de servicios disponibles para cualquiera que los requiera.

Para los fanáticos del modelo de arquitectura de n-capas, SOA representa la colección de funcionalidades de la capa de “lógica de negocio” que toda aplicación tiene en dicho modelo. En este contexto SOA plantea que toda aplicación expone todas sus funcionalidades a través de servicios.

En el modelo de EAI de 3ra generación, la comunicación que existe entre aplicaciones no se basa en el enrutamiento de mensajes de un lado a otro (como ocurre con la del broker de la segunda generación), sino en el consumo de servicios que cada aplicación expone con su respectivo Contrato, en una forma punto a punto.


SOArv1.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”. De aquí se desprende que cualquier aplicación puede cumplir tanto el rol de proveedor de un servicio como el rol de cliente de otro.

En esta generación de EAI la integración empieza a dinamizarse ya que las conexiones dejan de ser configuraciones estáticas y “a la medida” y empiezan a exponerse “servicios” que cualquier otra aplicación pueda “reutilizar” en el momento que lo desee.

Esto provee una gran ventaja en la práctica de EAI ya que esa “reutilización” de servicios representa menos trabajo a llevar a cabo la próxima vez que se requiera integrar una aplicación que desee consumir justamente el mismo servicio ya expuesto.

Originalmente esta Arquitectura Orientada a Servicios era implementada utilizando la tecnología CORBA3 especificada y estandarizada por la OMG4. Si bien las prestaciones que esta especificación proveía para la integración de aplicaciones en el entorno empresarial (proveyendo seguridad, transaccionalidad, alta disponibilidad, etc.) eran completas, resultaban complejas y por ende costosas de implementar.

A finales de los años 90, IBM en conjunto con Microsoft desarrollaron una especificación de distribución de servicios con la simplicidad en mente para resolver los problemas que CORBA enfrentaba; de aquí nació la tecnología de Servicios Web, la cual se apalanca en tres elementos fundamentales: el

3CORBA, del inglés “Common Object Request Broker Architecture”4 OMG, Organización internacional de estandarización de manejo de objetos. Siglas del inglés Object Management Group. http://www.omg.org/


http://www.omg.org/

SOArv1.1

protocolo de comunicación SOAP5, la especificación de Contratos de servicios WSDL6 y el catálogo dinámico de servicios UDDI7.

Si bien la tendencia del mercado es que SOA se implementa con Webservices, dado que SOA es una arquitectura, puede ser implementada utilizando cualquier tecnología incluyendo Webservices; por ejemplo, CORBA, EJBs, RMI, SUN RPC, propietario/Socket, Webservices (SOAP/HTTP), etc.

El papel del UDDI es generalmente menospreciado, si bien es fundamentalmente un catálogo que le permite a cualquier “cliente” de un servicio específico “descubrir” la ubicación física del proveedor de dicho servicio para conectarse en tiempo de ejecución y consumirlo, es quien realmente desacopla el servicio de su proveedor. En la medida que los clientes hagan uso del UDDI siempre que requieran del consumo de un servicio (y no con una referencia física compilada en el cliente), el proveedor estará desacoplado pudiendo cambiar dicho proveedor de la arquitectura con tan solo modificar el registro físico de dicho servicio en el UDDI (similar al funcionamiento del DNS8).

Es importante resaltar que en SOA, los clientes de cualquier servicio deben cumplir con el contrato impuesto por la aplicación proveedora del servicio, por lo que si ésta cambia afectando el “Contrato”, entonces el cliente debe ser modificado para que pueda cumplir con el nuevo contrato.

De aquí se desprende la pregunta: ¿qué ventaja nos daría el contar con una especificación de contratos estándar que no cambie independientemente de que se cambien las aplicaciones proveedoras?

5.1.4 Cuarta generación: SOAr

SOAr es la evolución de SOA en cuanto que al redefinir la forma de implementación, cubre los vacíos que SOA por si sólo deja sin solución. Estos son:

i) Evolución de la especificación de los contratos de los proveedores sin afectar a los clientes: El estado ideal del SOA es contar con una especificación estándar de contratos y con un ecosistema de aplicativos que cumplan con dicha especificación

5 SOAP (siglas de Simple Object Access Protocol): protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML6 WSDL (siglas de Web Services Description Language): formato XML que se utiliza para describir servicios Web.7 UDDI (siglas de Universal Description, Discovery, and Integration) : es un Directorio en línea que las aplicaciones utilizan para descubrir de forma dinámica otros servicios en línea.8 DNS (siglas de Domain Name System): Sistema de nombre de dominios, provee una taxonomía de etiquetas alfanuméricas que permiten asociar un servicio en Internet sin la necesidad de utilizar la dirección física.


SOArv1.1

estándar; de esta manera cuando uno cambie un proveedor por otro los clientes no se ven afectados.

ii) Duplicidad funcional: Cuando un servicio es provisto por dos aplicaciones diferentes, diferenciados por criterios particulares tales como “tipos de cliente” (un tipo de cliente procesado por el proveedor A y para el otro tipo de cliente por el proveedor B), calidad de servicio, ubicación geográfica del cliente o del material, etc.9

iii) Cohesión: Cuando la dinámica de las empresas exige hoy en día un continuo cambio de sus aplicativos para ir evolucionando en la dirección de su plataforma ideal, con cada cambio todas las aplicaciones integradas se ven afectadas.

Como alternativa a una arquitectura que no da respuestas a la realidad empresarial actual se presenta SOAr, una arquitectura en la que se expone un conjunto de proveedores intermedios llamados “Servicios del Negocio” o “Servicios del Negocio”.

Dichos Servicios del Negocio representan en la plataforma de tecnología el mapa ideal de aplicaciones, los cuales se exponen simples y sencillos de utilizar, escondiendo las complejidades de una realidad redundante (por las duplicidades, cambiantes y disímiles (por las evidentes diferencias entre las implementaciones de mismos conceptos por diferentes sistemas/proveedores).

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.

Para muchos especialistas, los servicios expuestos por la plataforma corresponden con servicios “compuestos”, sin embargo en esas aproximaciones, los servicios compuestos se plantean como complementos de los servicios atómicos provistos directamente por los aplicativos.

SOAr, por el contrario, utiliza la capacidad de las plataformas de integración actuales para creación de servicios compuestos para generar nuevos servicios tanto atómicos como compuestos, pero cumpliendo el rol de Servicios del Negocio.

Los elementos principales de una arquitectura SOAr son:

1) Aplicaciones: Conjunto de programas de software diseñados y escritos para realizar operaciones especificas, las cuales van a ser

9 Dicha duplicidad funcional no es necesariamente una consecuencia de una plataforma inmadura; condiciones del negocio pueden implicar que dicha duplicidad funcional represente el estado del arte en cuanto a la solución tecnológica.


SOArv1.1

clientes o proveedores de la plataforma de integración. Es importante resaltar que una misma aplicación puede ser cliente en algunos casos y en otro proveedor.

2) Especificación de Servicios del Negocio (BSI10): Define la sintaxis y semántica de cada uno de los servicios corporativos de la Arquitectura. Idealmente son estándares, sin embargo aún cuando no lo sean provee las características distintivas de SOAr sobre SOA.

3) Plataforma de integración: Es una plataforma que soportada sobre mecanismos de alta disponibilidad, transaccionalidad y seguridad provee funcionalidades poderosas de alto nivel de conectividad, adaptación (mapeo) y coreografía para exponer servicios definidos por la “Especificación de Servicios del Negocio” componiendo aplicaciones “Proveedoras”.

Figura 10 Cuarta generación de EAI: SOAr

Al ver la Figura 10 se puede observar en el centro los servicios corporativos expuestos por la plataforma, los cuales son consumidos por las aplicaciones; adicionalmente las aplicaciones exponen servicios proveedores que son utilizados por la plataforma para exponer los corporativos.

10 BSI (del inglés Corporate Service Interface): Es la especificación o contratos de los servicios corporativos.


SOArv1.1

5.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.

Si bien a continuación se presentan con precisión los beneficios de implantar el modelo SOAr, en general todo converge en una verdadera agilidad en la provisión de servicios para nuevos desarrollos que permitan a la organización de Tecnología responder a la dinámica demanda del negocio.

1. Desacopla los procesos del negocio de la plataforma de tecnologías de información; de esta manera ambos, tanto los procesos como la plataforma evolucionan de manera independiente, pudiendo el negocio evolucionar sus procesos con menos dependencia de las unidades de TI, y las unidades de TI evolucionar sus plataformas con un menor impacto en los procesos del negocio.

2. Expone de manera simple todos los datos y lógica del negocio presentes a lo largo de toda la infraestructura de tecnología. Esto lo hace SOAr exponiendo los servicios corporativos con las siguientes características:

a. Especificaciones conocidas, sin necesidad de aprender semántica y sintaxis específicas de las aplicaciones existentes o por llegar.

b. Ausencia de complejidad por solapamientos o duplicidad funcional; en otras palabras, SOAr expone una plataforma en la que para una función nunca hay dos aplicaciones que hagan lo mismo.

c. Sin la heterogeneidad tecnológica típica de los ambientes empresariales, debido a que esto también es escondido por SOAr. En otras palabras, todos los servicios y datos accesibles a través de la misma tecnología.

3. Reduce de manera importante los costos en riesgo, tiempo y dinero de integración de nuevas aplicaciones debido a la sencillez que SOAr expone la plataforma a las nuevas aplicaciones.

4. Elimina la duplicidad de esfuerzos para lograr el mismo resultado al tener disponible de manera muy sencilla la lógica y datos existentes en la plataforma tecnológica.


SOArv1.1

5. Elimina los impactos de un cambio de aplicación en las otras aplicaciones. Al estar las aplicaciones encapsuladas, cuando una es cambiada ninguna de las aplicaciones que son “clientes” de ella requieren ser tocadas.

6. Simplifica los procesos de migración de aplicaciones “por partes”. La migración del uso de una aplicación “vieja” por una “nueva” es controlada por la plataforma por lo que los procesos de “Pase a producción” gradual pueden ser llevados a cabo de manera transparente al resto de las aplicaciones respecto a la que es sustituida y la que sustituye.

7. Provee a la empresa de la infraestructura modelada como Nivel 3 del modelo de madurez NGITP de Gurulab.

En el contexto del modelo referencial NGITP de Gurulab, SOAr representa un mecanismo para lograr el establecimiento de una Plataforma de Tecnología de Información de Nueva Generación nivel 3.


Bus

S1 S2 S3 … Sm


SmartInterface

c1 c2 …

1 - Silos

2 - EAI

3 -

4 - BPM

5 - SmartInterface


ci

SOAr

Nivel de Madurez


Figura 11 SOAr en NGITP

8. Maximiza el uso de manera eficiente de la plataforma tecnológica de integración a nivel corporativo, debido a que provee un “Modelo Tecnológico” que indica claramente como utilizar cada componente para tal fin.


SOArv1.1

9. Provee un control de la evolución tecnológica de la arquitectura que tradicionalmente las unidades de Tecnología no tienen. La plataforma de integración puede “controlar” todos los procesos de pase a producción alineándose perfectamente con las prácticas de ITIL11.

5.3 SOAr y BPM

Como ya se ha dicho anteriormente, SOAr desacopla los procesos del negocio de la plataforma de tecnologías de información; esto exponiendo un conjunto de servicios corporativos que están disponibles tanto a las herramientas de modelaje y análisis de procesos, como al motor de ejecución.

De la misma manera como SOAr “Protege” las integraciones con aplicaciones cuando una de ellas es cambiada, protege los procesos de los cambios de aplicaciones.

11 ITIL (del inglés IT Infrastructure Library): es un modelo de referencia operacional para servicios de TI.


SOArv1.1

Dado que los procesos “consumen” servicios corporativos, y éstos no cambian sino las aplicaciones que SOAr encapsula, ningún cambio de aplicaciones de la pataforma de TI afecta la ejecución de procesos implementada sobre la capa de BPM.

5.4 Elementos claves de una implementación exitosa de 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), para su exitosa implementación es necesario contar con cuatro (4) elementos muy importantes:

1. Buena “Especificación de Servicios del Negocio” (BSI)2. Plataforma flexible3. Metodología pragmática de implementación4. Equipo de integración

En los siguientes capítulos se verán en detalle cada uno de estos temas con el fin de proveer al lector de los criterios suficientes para proveerse de dichos componentes y asegurar un exitoso proyecto.

La aproximación que este libro tiene a cada uno de estos elementos claves es de manera estructural, es decir, independiente de estándar, tecnología o proveedor. En el sitio web www.soarframework.org además estar disponible este documento están disponibles registros de experiencias que se han tenido con tecnologías, estándares y proveedores específicos; de esta manera usted posee tanto los criterios como las referencias para tomar sus propias decisiones respecto a cómo considera más conveniente llevar a cabo una implementación de un EAI basado en SOA.


http://www.soarframework.org/

SOArv1.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, flexibilidad, etc.) la implementación podrá realmente lograr la promesa respecto a que un cambio en un aplicativo de la arquitectura no impacte en ningún otro aplicativo o en los procesos del negocio soportados por SOAr.

En la medida que la BSI sea de mayor calidad, menor impacto tendrá el cambio de un elemento de la plataforma de TI en otros y los procesos del negocio; es por esto que es importante conocer las características que se deben asegurar a la hora de generar una especificación de este tipo.

Este capítulo le presentará los criterios que le permitirán asegurar que la BSI que usted utilice tenga la mejor calidad posible y por ende garantizar el éxito de la promesa de su Plataforma de Integración basada en una Arquitectura Orientada a Servicios.

Adicionalmente, también se presentarán los estándares de industria conocidos por Gurulab que presentan especificaciones que pueden ser utilizados como BSI. Estos estándares aseguran de manera razonable que el BSI basado en ellos es de muy buena calidad.

La calidad de su BSI es fundamental para asegurar las premisas que usted puede utilizar en la justificación del caso de negocio que sustente su proyecto de implantación de SOAr. En la medida que su BSI tenga mayor calidad, menor riesgo tendrá la cuotaparte de su caso de negocio relacionado con los ahorros por eliminación de impactos por evolución de la plataforma tecnológica.

6.1 Calidad de la BSIPara poder definir claramente qué es la Calidad de una BSI y cómo se consigue, es necesario definir previamente los siguientes conceptos:


SOArv1.1

Composición de FuncionalidadesSe dice que una funcionalidad es “Compuesta” cuando ésta puede expresarse en función de la ejecución de otras funcionalidades diferentes a ella.

Derivación FuncionalSe dice que una función F es derivable cuando existe un conjunto de funciones Fi diferentes de F tales que F es la composición de las Fi.

Funcionalidad AtómicaSe dice que una funcionalidad F0 es atómica si y sólo si no existen otras n funcionalidades F1, F2, ..., Fn diferentes a partir de las cuales se puede derivar F1.

Subconjunto FuncionalSe dice que una funcionalidad F1 es subconjunto funcional de una funcionalidad F2 sí y sólo si la F2 es derivable a partir de un conjunto de funcionalidades entre las cuales se encuentra F1.

Toda funcionalidad es subconjunto funcional de si misma.

Funcionalidades Ortogonales

Se dice que dos funcionalidades F1 y F2 son ortogonales si y sólo si no existe una funcionalidad F3 tal que F3 es subconjunto de F1 y F3 es subconjunto de F2.

CorolarioDos funcionalidades son “no ortogonales” si alguna de ellas es subconjunto funcional de la otra.

Calidad de una BSI

La calidad de una BSI es directamente proporcional a su capacidad de absorber, sin modificación en su API, nuevas funcionalidades “no ortogonales” respecto a las existentes, o nuevos rasgos en los datos del negocio.

6.1.1 Fenómeno del Cernido

Entendiéndose por especificación de grano fino a una basada en funcionalidades atómicas, y por una de grano grueso a una basada en funcionalidades compuestas (no atómicas), se define como el fenómeno del


SOArv1.1

cernido a la situación que se presenta cuando a un proceso del negocio o aplicativo de la plataforma de TI, teniendo la expectativa de consumir servicios grano grueso, se le presenta un conjunto de servicios del negocio basado en una especificación de grano fino.

Para entender este fenómeno, es posible hacer referencia a una metáfora diferente a la de las especificaciones de servicios del negocio como por ejemplo la complejidad lexicográfica de los idiomas Inglés (o Español) y Japonés.

Para expresar una idea en idioma Inglés (o Español), es necesario muchas menos construcciones lexicográficas (palabras) que las necesarias en el idioma Japonés. Esto es claramente evidenciado por la gran dificultar que tiene la industria cinematográfica para sincronizar las traducciones de una película Japonesa en el Inglés (o Español).

La cineasta Sofía Coppola atrapó de manera graciosa esta situación en su película “Lost in Translation” en las primeras escenas cuando el personaje principal (interpretado por Bill Murray) se encuentra en Japón para grabar un comercial para un Whiskey; en la escena el director japonés le indica en japonés al personaje “actor” una serie de instrucciones durante 26 segundos (contados por reloj) para luego escuchar a la traductora el significado en inglés con unas instrucciones que le tomó 2 segundos.

En la foto, el “actor” escucha atentamente a la traductora mientras observa al director quien espera que finalice la traducción; luego de escuchar la traducción de 2 segundos repondió: “Eso es todo? Me pareció que él dijo algo más que eso!” (En inglés “Is that everything? It seemed like he said quite a bit more than that.”).


SOArv1.1

Entre el Inglés y el Japonés existe el fenómeno del cernido, en donde el Inglés es de “grano grueso” y el Japonés de “grano fino”. De aquí se desprende fácilmente que el tamaño del grano habla de la expresividad de sus palabras, y en el caso de las especificaciones de servicios del negocio el grano corresponde a la expresividad de su API12.

6.1.2 Criterios para generar una BSI de buena calidadCon el fin de lograr una especificación de servicios del negocio de buena calidad, es importante que el arquitecto de la especificación tome en cuenta una serie de consideraciones las cuales se resumen en los siguientes preceptos:

1. La BSI debe diseñarse pensando en un sistema ideal de referencia. Dicho sistema de referencia puede estar expresando en términos de documentación formal, o en función de la visión de un experto o especialista. En la medida que el experto o especialista es representado por el arquitecto de la BSI, mejor será la expresión de dicha visión en la BSI.

2. Las especificaciones de los servicios del negocio deben ser de grano fino, aún cuando los procesos o aplicaciones que requieren consumirlos requieran de una especificación de grano grueso, es decir, deben expresarse en función de funcionalidades atómicas independientemente de que esto implique el fenómeno del cernido.

3. Uso de excepciones para manejo de errores4. Basado fundamentalmente en los siguientes patrones de diseño:

● Session Façade Pattern● Value Object Pattern, Data Transfer Object● Factory Pattern, Data Transfer Object Factory● Generic Attribute Access● Version Number● Iterators for Bulk Transfer (Value List Handler)● Template-based Queries● Generic Named Queries● Bulk Operation with Best effort and Atomic Semantics● Meta-Data Discovery

Los patrones son referencias generales las cuales pueden estar expresadas en términos de lenguajes específicos como Java, o pueden estar expresados en términos agnósticos como UML. Como referencia a continuación se presentan fuentes de información de patrones de diseño orientado a objetos:

● http://java.sun.com/developer/technicalArticles/J2EE/patterns/ ● http://www.research.ibm.com/designpatterns/

12API; del inglés Application Program Interface.


http://www.research.ibm.com/designpatterns/

http://java.sun.com/developer/technicalArticles/J2EE/patterns/

SOArv1.1

El desarrollo de una especificación de servicios del negocio, incluyendo la especificación de datos, es una tarea muy extensa la cual se aconseja ser llevada a cabo por etapas en amplitud y por iteraciones para cubrir profundidad (detalles).

A la fecha, junto con mi equipo he tenido ya dos experiencias grandes y contundentes, una entre los años 1997 y 1999, y la segunda entre los años 2003 y 2005; con ambas experiencias hemos aprendido a crear especificaciones de servicios de negocio de muy alta calidad.

Los criterios indicados en esta sección corresponden a la documentación de las lecciones aprendidas a lo largo de los proyectos de ejecución de SOAr. Detalle de estos criterios, o estrategias prácticas respecto a cómo llevarlo a cabo se encontrarán documentados en próximas entregas de este libro, o en el talleres especializados dictados por Gurulab.

6.2 Herencia funcionalDebido a la dinámica de la integración de aplicaciones empresariales, la plataforma de servicios del negocio se verá afectada para cumplir con los constantes cambios y nuevas necesidades.

Los cambios que puede sufrir la BSI pueden clasificarse de dos tipo: ● Agregación de funcionalidades ortogonales.● Agregación de funcionalidades no ortogonales.

Es de esperar en un ambiente ideal que los sistemas y procesos que consumen servicios del negocio “hereden” las nuevas funcionalidades de la plataforma sin necesidad de ser modificados. Esta expectativa es alcanzable a través de una BSI de alta calidad ante modificaciones de la plataforma que agreguen nuevas funcionalidades no ortogonales.

Para que la plataforma provea esa “herencia” ante agregaciones de funcionalidades ortogonales, la BSI debe ser definida basado en un conocimiento de expectativas funcionales a futuro, más que de una práctica de especificación con “calidad”.

En otras palabras, en RUNTIME, si uno agrega nuevas funcionalidades no-ortogonales, y la BSI es de buena calidad, los procesos y sistemas que consuman de la BSI heredarán las nuevas funcionalidades sin necesitar de cambiar código en los “consumidores”.

Por ejemplo, en un momento dado un CRM basado en el hecho de que el sistema de Gestión de Ordenes no permite la selección de una característica particular del producto o servicio a vender, simplemente asume la característica “default”. Si el CRM está integrado al Servicio de Negocio de Gestión de Ordenes a través de una BSI de alta calidad, en el momento que el Gestor de Ordenes provea la funcionalidad de “elección” de la característica particular a la que hacemos referencia en este ejemplo, el CRM heredaría la


SOArv1.1

nueva funcionalidad y en el acto, sin la necesidad de ser modificado, empieza a ofrecer la opción de selección de la característica particular.

A continuación veremos cada una de estos dos tipos:

6.2.1 Agregación de funcionalidades ortogonales

En el escenario de agregación de nuevas funcionalidades ortogonales respecto a las existentes en la BSI, los procesos y aplicativos que consuman de la BSI serán afectados en la medida que se requiera que éstos los aprovechen.

La agregación podrá ser implementada a través de la incorporación de nuevos servicios o incluso con la evolución de los servicios existentes en nuevas versiones; si bien el último caso es poco probable en el escenario de nuevas funcionalidades ortogonales, si ocurre y afecta servicios que están siendo utilizados, pueden ser expuestos ambas versiones simultáneamente.

La publicación de dos versiones de un mismo servicio es una práctica que debe llevarse a cabo de manera cuidadosa. Si bien permite en las circunstancias indicadas en esta sección evitar el impacto de la evolución de la BSI en los sistemas y procesos que consumen servicios del negocio, es un foco de redundancia y complejidad de mantenimiento.

La convivencia de varias versiones de un mismo servicio debe ser manejada a través de la ejecución de una adecuada gestión del ciclo de vida de los servicios. Adicionalmente, deben considerarse políticas de mantenimiento de la plataforma que permitan desincorporar versiones viejas de servicios generando proyectos de actualización tecnológica a nivel de los “consumidores” de esos servicios a desincorporar.

Es importante entender que si bien ante el proceso de “actualización tecnológica” indicado en el párrafo anterior hay un impacto a nivel de las aplicaciones y procesos “usuarios” de los servicios del negocio, éste impacto no ocurre por cambios en la plataforma, sino por procesos de mantenimiento que pueden ser implementados en periodicidades bianuales y sin ningún tipo de restricciones respecto a otros proyectos.

6.2.2 Agregación de funcionalidades no ortogonalesCuando la BSI es afectada por la incorporación de nuevas funcionalidades no ortogonales a las existentes en la BSI, el impacto dependerá de la calidad de la BSI. En la medida que la BSI sea de mayor calidad, menor la cantidad de cambios en los procesos o sistemas “consumidores”, aun disfrutando de las nuevas funcionalidades incorporadas en la plataforma a través de la “Herencia” que SOAr les confiere.


SOArv1.1

6.3 Especificaciones estándares de industria

A continuación se presentan los casos particulares para los cuales SOAr cuenta con valores agregados. El que una industria no esté enunciada en este capítulo no implica que no pueda utilizar SOAr, sino que para el momento de la publicación de este documento, Gurulab no poseía información de artefactos estándares que faciliten el trabajo de implementación.

6.3.1 Telecomunicaciones

TeleManagement Forum (http://www.tmforum.org/) es para las TI de la industria de Telecomunicaciones, los que la ITU es para las redes de la misma industria, o la ISO para cualquier industria.; agrupa un conjunto de artefactos estándares y mejores prácticas que permiten lograr una plataforma tecnológica de operaciones de nueva generación.

El planteamiento fundamental de TMForum es el logro de la plataforma de operación de nueva generación de una Telco; dicho planteamiento se encuentra en la forma de una colección de especificaciones llamada NGOSS y la especificación de interfaces estándares en las tecnologías Webservices, XML y Java llamada OSS/J.

En el contexto de SOAr, 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, SID, TAM, MTOSI, OSS/J) en la tecnología requerida por la plataforma (Webservices, Java, CORBA, etc.). En particular, OSS/J provee las especificaciones requeridas para Servicios Web, tecnología utilizada ampliamente en la actualidad.


http://www.tmforum.org/

SOArv1.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.

6.3.1.1 eTOMeTOM, componente del marco de referencia NGOSS del TMForum, es un marco referencial de procesos de una empresa de telecomunicaciones. Este marco referencial clasifica todos los procesos hasta un nivel de detalle casi de la especificación de tareas específicas.

Sirve inicialmente como referencia estándar a la hora de nombrar los procesos o partes de ellos (subprocesos). Para ello enumera una cantidad de procesos clasificados en varias dimensiones según se muestra en la Figura 13.


SOArv1.1

Figura 13 Representación gráfica de eTOM; componente de NGOSS del TMForum

El modelo eTOM brinda un catálogo completo de los procesos de una telco y puede ser utilizado como modelo referencial a partir del cual se realiza el modelaje de los procesos a implementar.

6.3.1.2 TAMEl Telecom Operations Map representa un catálogo que identifica y clasifica el conjunto de Componentes Funcionales de una empresa de Telecomunicaciones. A continuación se presenta la figura que muestra la clasificación actual.


SOArv1.1

Este estándar presenta lo que SOAr llama las ”aplicaciones ideales” o ”plicaciones virtuales”; es por esto que sus elementos representan componentes de agrupación de los servicios de negocio implementados en su ESB.

6.3.1.3 SID

Siendo también elemento de NGOSS del TMForum, SID es un modelo canónico de datos, agnóstico de tecnología, representado en modelos UML. La Figura 14 muestra los dominios de SID que clasifican todas las clases (modelo orientado a objetos) que representan el estándar.


SOArv1.1

Figura 14 Representación gráfica de SID; elemento de NGOSS del TMForum

El grupo técnico encargado de la evolución de este modelo está constantemente extendiéndolo para cubrir los dominios en donde hay brechas en la especificación. En la medida que una empresa desea utilizar este modelo puede hacerlo utilizando los lineamientos de extensión para asegurar que todas las consideraciones arquitecturales del modelo sean preservadas.

Este modelo es la mejor referencia inicial a partir de la cual se puede trabajar para desarrollar los datos de la especificación de servicios corporativos de una arquitectura de integración SOAr.

La mejor manera de implementar SID en su modelo de Servicios del Negocio es implementando OSS/J y extendiendo OSS/J (ver más adelante).

Basado en la experiencia adquirida en el proyecto de integración en CANTV, recomiendo de manera enfática que de trabajar con este modelo y requerir su extensión, hágalo trabajando de manera muy cercana al equipo de desarrollo; de esta manera usted asegura que el producto resultante de su trabajo se convierta en el estándar y así evitar que el SID evolucione en una dirección diferente quedando usted con su versión específica desactualizados.

6.3.1.4 MTOSIAl igual que eTOM y el SID, MTOSI es una especificación agnóstica de tecnología que define las interfaces entre elementos de la plataforma operativa de una telco. En particular representa la especificación que SOAr


SOArv1.1

requiere de manera concreta y específicamente en la tecnología que sea utilizada para su implementación.

Dado que MTOSI es un artefacto relativamente nuevo no cubre de manera relevante los componentes de la arquitectura que se requiere especificar.

6.3.1.5 OSS/JOriginalmente una iniciativa independiente del TMForum, fue desarrollando a lo lardo del tiempo una implementación concreta del SID y de interfaces de servicios (lo que MTOSI busca lograr) para aplicaciones concretas como Gestor de Problemas (Trouble Ticket), Inventario, Gestor de Ordenes de Servicio, Facturador, etc. Desde el 1 de Julio del 2006 es un capítulo oficial del TMForum y además de ser accesible a través de la página oficial del TMForum (http://www.tmforum.org/) es accesible a través de su URL propio http://www.ossj.org/.

Hoy en día mantiene las especificaciones en Weservices, XML y Java de los APIs que se listan a continuación:

JSR #

OSS/J API Status Spec Lead & Company

Java.net

89OSS Service Activation

Maintenance Release (v1.1)

Andreas EbbertNokia Corporation

90OSS Quality of Service

Final Release (v1.0)

Srinivasa SamudralaMotorola

91 OSS Trouble TicketFinal Release (v1.0)

Axel TerflothIP Value

130 OSS Billing MediationMaintenance Release (v1.1)

Tulika Pradhan InfozechSoftware Limited

public

142 OSS Inventory Final Release (v1.0)

Pierre GauthierMetaSolv Software

public

144 OSS CommonMaintenance Release 3 (v1.3)

Vincent PerrotSun Microsystems

public

210OSS Service QualityManagement

Early Draft ReviewThierry SupplissonVallent

251 Pricing Early Draft ReviewJohn WilmesCeon Corporation

public

254 OSS Discovery Public Draft ReviewAndrew PatersonNakina Systems

public


https://jsr-254-public.dev.java.net/

http://java.sun.com/products/oss/start_download.html

http://jcp.org/jsr/detail/254.jsp

https://jsr251-public.dev.java.net/























http://www.ossj.org/downloads/api.shtml







http://www.ossj.org/

http://www.tmforum.org/

SOArv1.1

JSR #

OSS/J API StatusSpec Lead &

CompanyJava.net

263 Fault Management Early Draft ReviewDavid RaymerMotorola

public

264 Order Management Public Draft ReviewAndreas EbbertNokia Corporation

public

285Performance Management

Expert GroupDavid RaymerMotorola

Las especificaciones generadas por OSS/J son gestionadas a través de la Java Community Process (http://www.jcp.org/) aún cuando incorpora especificaciones de Webservices y XML. Igualmente son publicadas a través de la comunidad java.net (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


http://www.java.net/

http://www.jcp.org/










SOArv1.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.

Figura 16 Mapeo de las especificaciones de OSS/J con SID de TMForum


SOArv1.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.ossj.org/downloads/docs/wp_ossj_api_roadmap.pdf

Las especificaciones de OSS/J además de incluir las especificaciones de API, incluyen una implementación del SID, por lo que la adopción de OSS/J como especificación de Servicios del Negocio implica el uso del SID, es decir, adopción de mejores prácticas de la industria de Telecomunicaciones y el uso de una BSI de alta calidad, probada por varios operadores a nivel mundial.

6.4 Otras industrias

Para el momento de la publicación de este documento no se tiene conocimiento de frameworks o propuestas de estandarización de especificaciones de interfaces entre aplicaciones para otras industrias además de las indicadas en esta sección 6 “Especificación de Servicios del Negocio(BSI)”.

Sin embargo, así como hemos evaluado que la propuesta de TMForum para la industria de Telecomunicaciones puede ser aplicada para la industria de Banca con unas pequeñas modificaciones, podría evaluarse para resolver otras ; es previsible que dicha extrapolación funcione muy bien al menos en los dominios independiente de industria como Contabilidad, RRHH, Facturación, CRM, etc.


http://www.ossj.org/downloads/docs/wp_ossj_api_roadmap.pdf

SOArv1.1


SOArv1.1

7 Aspectos técnicos

7.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. Ya sea que utilice herramientas de alto nivel como productos especializados para integración basado en SOA, o utilice un simple compilador de su lenguaje de preferencia y un editor del código fuente.

Independientemente de la herramienta que utilice, y de su esquema de licenciamiento (sea software propietario, software abierto o software libre), a continuación se presenta una descripción anatómica de los elementos que la plataforma que usted va a utilizar para implementar SOAr debe tener.

Es importante resaltar que esta descripción es lo suficientemente abierta para que cualquier plataforma pueda ser descrita, lo importante es que usted pueda detectar claramente cuál componente de la plataforma corresponde a cuál elemento de este modelo tecnológico de referencia.

Teniendo en mente el modelo de referencia tecnológica de SOAr en vez del modelo arquitectural de la plataforma provista por el fabricante, usted tendrá los siguientes beneficios:

Desacoplamiento del proyecto de implementación de la plataforma utilizada. De esta manera, si en algún momento usted se topa con alguna limitación de la plataforma de integración, fácilmente podrá incorporar nuevos elementos que completen su arquitectura referencial y así lograr los objetivos fundamentales de la implementación SOAr aquí descrita.

Aseguramiento de un lenguaje común independiente de un fabricante específico de tecnología de integración. De esta manera le será mucho más fácil comunicarse con cualquier especialista, además del propio proveedor de la tecnología que usted utilice.

Le provee el esqueleto a armar en caso de decidir implementar su proyecto utilizando elementos de Software Libre o Software abierto seleccionando las mejores implementaciones que cubran mejor las funcionalidades que usted necesite y valore más.

A continuación se presenta la radiografía de la arquitectura referencial de la tecnología a utilizar en dos niveles de detalle diferentes. El primer nivel muestra la menor cantidad de elementos para entender la plataforma. El nivel


SOArv1.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.

Aclaratoria Importante

Es muy importante resaltar que a lo largo de este documento nunca se utiliza la expresión “Adaptador” como sustantivo (si es utilizado como verbo: “adaptación”); esto es debido a que se quiere evitar la confusión que se genera con los proveedores de conectores en el mercado. En general los proveedores de conectores resaltan la gran cantidad de atributos de sus conectores como por ejemplo la capacidad de hacer Adaptaciones, por lo que les llaman Adaptadores y no Conectores.

En este documento les llamamos Conectores y no Adaptadores para hacer énfasis en que a ese nivel NO DEBE OCURRIR ADAPTACIÓN ALGUNA. Le recomiendo que usted siga esta práctica y nunca llame Adaptador a los Conectores, aún cuando la pieza de software sea un Adaptador; en otras palabras, llámelo por su nombre común “Conector” y no por su nombre propio “Adaptador”.

De esta manera asegura que nunca su gente confundirá sus palabras y asumirá que tiene la intención de realizar funciones de Adaptación a nivel de los Conectores.

Algunos autores/proveedores hacen énfasis en este modo de uso de los conectores llamándolos redundantemente “Conectores livianos”.

7.1.1 Nivel 1

Tal como se muestra en la Figura 18, la arquitectura de la plataforma de integración tiene dos elementos fundamentales: i) la plataforma (mostrado en el centro de la figura) y ii) las aplicaciones (satélites a la plataforma).


SOArv1.1

Figura 18 Nivel 1 - Arquitectura de la plataforma tecnológica de integración SOAr

Los aplicativos son los elementos de Software tal como lo conocemos, sin embargo, destacamos de ellos los que denominaremos el Canal. El Canal es la colección de recursos de una aplicación específica que se encuentran disponible para los objetivos de integración. Como ejemplo de estos recursos se encuentran:

Transacciones CICS Procedimientos Almacenados en un DBMS Dataschema e instancia de un DBMS Archivo plano Procedimientos disponibles en librerías Agentes de RPC estándares (SunRPC según RFC 1057, DCOM de

Microsoft, CORBA, Servicios Web, etc.) o propietarios (SAP RFC, SAP BAPIS, etc.)

La plataforma es un agente que está compuesta a nivel macro por tres capas: capa de conexión, capa de adaptación y núcleo.

La primera de las capas es la de Conexión, en la cual se encuentran los elementos necesarios para vincular las aplicaciones con la plataforma, en particular contiene a los Conectores y los Proxy. Los Conectores son los responsables de resolver cualquier dificultad tecnológica para acceder al Canal


SOArv1.1

de las aplicaciones; éstos exponen dentro de la plataforma tantos Proxys como Canales se quiera integrar, siendo los Proxys representaciones en la plataforma de los Canales de las aplicaciones.

A esta altura, gracias a los Conectores hacer uso de los servicios representados en los Proxy implica hacer uso de los servicios implícitos en los canales de la aplicaciones.

En el centro de la plataforma se encuentra el Núcleo; en dicha capa viven los Servicios del Negocio, los cuales son construidos como una secuencia de llamadas a los Proxys. Dichas “llamadas” atraviesan la capa de Adaptación, sufriendo las transformaciones requeridas para que los objetos que son manejados a nivel de la interfaz de los Servicios del Negocio sean transformados a los objetos manejados a nivel de la interfaz de los Proxys; esto último es llamado también “mapeo”.

Adicionalmente en la capa de Adaptación viven los “Servicios Específicos de Aplicación”, los cuales al ser opcionales, pueden proveer la adaptación que pudiese requerir una aplicación “Cliente” para poder hacer uso de un Servicio Corporativo. También se dice que estos “Servicios específicos” implementan la adaptación de la lógica.

En los Servicios del Negocio que viven en el núcleo de la plataforma es donde ocurre la abstracción de las aplicaciones subyacentes; aquí es donde se implementa la lógica y criterios que son utilizados para exponer el servicios de una aplicación ideal basada en la cruda y compleja realidad subyacente.

Por ejemplo, si en la realidad se tienen tres aplicaciones diferentes para manejar los Recursos Humanos, es en estos Servicios del Negocio donde se expone un (1) solo servicio de Recursos Humanos (como si fuera una sola aplicación); allí se está implementada la lógica y criterios de enrutamiento para que cada llamada al servicio corporativo se convierta en las llamadas que sean necesarias a las tres aplicaciones subyacentes. En particular, suponiendo que las tres aplicaciones de RRHH estén manejando cada una un grupo de Empleados diferente, el servicio se comunica con la aplicación adecuada basada en cuál aplicación maneja el empleado para el cual debe atender los servicios de RRHH.

7.1.2 Nivel 2Explotando la figura de la plataforma nivel 1, se tiene el nivel 2 el cual se muestra en la Figura 19. La diferencia fundamental entre los dos niveles está en la diferenciación de sub-capas.


SOArv1.1

Figura 19 Nivel 2 - Arquitectura de la plataforma tecnológica de integración SOAr

Para el caso de la capa de Conexión, se muestran las dos subcapas Conexión.Proxies y Conexión.Conectores. La Figura 19 muestra una separación física que puede existir entre estas capas, viviendo en este caso los proxys en los límites de la plataforma.

La capa de Adaptación se separa en dos subcapas, aquella donde viven las adaptaciones y aquella donde ocurre el Mapeo.

7.1.3 Plataforma idealIdealmente, una plataforma que implemente esta arquitectura referencial utilizaría dos conceptos que considero clave para tener una plataforma de integración más ágil:

La lógica de los servicios, ya sean a nivel de adaptaciones o Servicios del Negocio, debe ser una herramienta visual o metalenguaje que abstraiga la noción de la morfología de los datos.

Los mapeos se definen entre pares de Objetos sin necesidad de hacer una vinculación explicita en la lógica de los servicios.


SOArv1.1

La ejecución de la lógica de servicios indicada de primero, al pasar por la capa de Adaptación.mapeos, de manera implícita ejecute los mapeos indicados anteriormente de manera automática logrando así la satisfacción de los contratos cuya lógica de integración está encarando.

7.2 Desarrollo de conectoresLos conectores poseen la funcionalidad de habilitar la comunicación entre dos ambientes tecnológicos dispares, sin embargo, aquellos provistos por 3ros (fabricantes) poseen adicionalmente capacidades de adaptación; estas capacidades de “adaptación” son las de realizar transformaciones semánticas en las estructuras intercambiadas. Es por esto que los fabricantes llaman “Adaptadores” a sus conectores.

Para tener un conector funcionando, basta con proveerse de uno ya sea construido “en casa” o tecnología de 3ros, cumpliendo las características técnicas del mismo, y luego configurarle las semánticas que se desean exponer al ESB, o características funcionales.

7.2.1 Características técnicas

El conector es una pieza compleja en si misma, tanto como lo es el ESB, y debido a su naturaleza de uso, de manera general los proveedores de tecnología de integración además de proveer el ESB, también proveen tecnología de conexión.

Como ya hemos visto en este libro, SOAr plantea hacer uso únicamente de las funcionalidades de Conexión de estas tecnologías, delegando al ESB las funciones de Adaptación. Es por esto que en el planteamiento de SOAr, se hace referencia a Conectores (cosas) y a Adaptación (función, que es llevada a cabo en el ESB), y nunca se hace referencia a Adaptadores.

Adicionalmente a las funciones ya mencionadas, los Conectores cumplen con las siguientes características:

● Mecanismos de compensación : el conector debe permitir establecer sesiones y ejecutar transacciones proveyendo un mecanismo para la compensación o rollback según lo que permita el aplicativo que conecta.

● Notificación de eventos como servicio de suscripción en tiempo de ejecución: generando las listas de suscripción como un elemento dinámico y no compilado en el conector o la aplicación

● Implementación completa los cuatro (4) contratos fundamentales : a saber:


SOArv1.1

● Ciclo de vida : todo conector debe implementar mecanismos que permitan las acciones de inicializar, comenzar, detener, recargar, terminar (init, start, stop, reset & finalize)

● Seguridad : Para asegurar la identificación y autenticación del “cliente” y cifrado de la comunicación.

● Transaccionalidad : asegurando la atomicidad de la transacción, capacidad de participación en una transacción distribuida implementando algún esquema de TWO PHASE COMMIT preferiblemente compatible con el estándar XA.

● Funcionalidad : A través del cual se acceden al contrato funcional que ofrece el conector.

● Aseguramiento de las representaciones binarias : el conector es responsable de asegurar las representaciones binarias, utilizando diversas herramientas tales como uso de referencia de codificación como UNICODE, y cambios de representaciones BIG INDIAN y LITTLE INDIAN.

● Alta Disponibilidad : medida en un número de 9's13 que debe ser definido siguiendo los estándares de la empresa, garantizando que el conector tenga al menos el mismo nivel de disponibilidad de la plataforma del ESB. Generalmente se espera que al menos tenga 99,9% de disponibilidad.

● Interfaz de gestión SNMP : el protocolo simple de administración de red ( SNMP por sus siglas en inglés ) permite supervisar el desempeño, identificar y resolver problemas utilizando mensajes a nivel de capa de aplicación, las consolas de administración SNMP son estándares y por medio de este se puede mantener una coordinación centralizada de los mismos y su estado.

● Eficiencia y Gestión : acordes con la plataforma, el uso apropiado de los recursos tanto de memoria, cpu y disco del conector así como su capacidad de administración tanto remota como local debe seguir los mismos principios establecidos para el ESB.

● Integración estándar con el ESB : utilizando el protocolo estándar JCA (o implementación de JCA en WS) o propietarios específicos para el ESB a utilizar. En caso de que no sea posible, al menos utilizar WS/JMS como mecanismo de transporte. El uso de JMS como transporte es para asegurar la persistencia de la transacción.

13La forma para medir la disponibilidad de un sistema es a través del cálculo del porcentaje de tiempo activa en un período de un año, este cálculo se hace dividiendo el número total de minutos de actividad por el total de minutos en el año ( aprox 525.600 ), el resultado se expresa comúnmente por el número de 9's seguidos que la expresión resultante tiene, así por ej.

1. 99,9% = 525,6 minutos de inactividad / año, 43.8 minutos de inactividad / mes, es llamado tres nueves ( tres 9's )

2. 99,99% = 52,5 minutos de inactividad / año, 4,38 minutos de inactividad / mes, es llamado cuatro nueves ( cuatro 9's )

3. 99,999% = 5,25 minutos de inactividad / año, 0,44 minutos de inactividad / mes, es llamado cinco nueves ( cinco 9's )


SOArv1.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.

Debido al gran costo y tiempo que representa desarrollar un conector que incorpore todas estas consideraciones, las organizaciones consiguen en la adquisición de tecnologías de conexión provistas por 3ros una alternativa de menor costo y menor tiempo de implementación.

En general, los fabricantes proveen junto con su ESB una lista pequeña de conectores fundamentales; es relevante que a esa lista inicial se le incorporen los conectores adicionales requeridos para integrar todas las plataformas de su ambiente.

A modo de referencia, un fabricante especializado en conectores que provee los conectores a prácticamente todos los ESB del mercado es la empresa iWay (http://www.iwaysoftware.com/).

7.2.2 Características funcionales● Encapsulamiento, ocultando las decisiones de diseño interno de cada

módulo del resto.● Separación de responsabilidades y responsabilidad única, de forma de

que cada módulo del conector tenga una y sólo una responsabilidad y sea claramente distinguible las responsabilidades todos y cada uno de los módulos.

● No duplicidad, el conector debe evitar repetir la duplicidad de código en sus módulos minimizando el riesgo de inconsistencias y aumentando la mantenibilidad de las piezas.


SOArv1.1

● No adaptaciones, a pesar de que muchos fabricantes de software generan conectores con capacidades de adaptación éstas no deben ser utilizadas dejando al ESB las responsabilidades de adaptación.

7.3 Implementación de servicios del negocio


SOArv1.1

8 Consideraciones estratégicasA continuación se presentan un conjunto de herramientas estratégicas que le permitirán planificar y ejecutar un proyecto de implementación de SOAr.

8.1 Sistema Nervioso EmpresarialSi 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, es preferible plantearse la implementación de SOAr desde una perspectiva corporativa.

Al implementar una plataforma “corporativa” de integración basada en Servicios del Negocio SOAr, se está implementando el llamado Sistema Nervioso Empresarial14; esta plataforma provee servicios de integración a todas las iniciativas de integración de la empresa.

Los proyectos que consideran SOAr pueden tenerla como meta a nivel corporativo, o como una solución de integración para una solución de negocio específica. En el primer caso, el objetivo al final del día es la implementación del Sistema Nervioso Empresarial, lo cual es muy adecuado como práctica de Arquitectura Empresarial.

En el segundo caso, si bien el objetivo no es implementar el Sistema Nervioso Empresarial, puede enfocarse de tal manera que represente el primer paso en el plan de implementación corporativa.

Para lograr esto, la consideración que debe realizarse es la de incluir al final del sub-proyecto de implementación de SOAr para la solución de negocio, las actividades de Pase a Producción de la práctica a las unidades operativas de la organización.

El pase a producción debe incorporar las consideraciones estándares de la empresa para esto incluyendo una extensión de capacidad (tiempo y recursos) de la unidad que haya realizado la primera implementación para que acompañe a las unidades operativas por un tiempo prudencial que permita una de dos cosas:

● Establecimiento de una relación contractual entre el proveedor de servicios de integración y la unidad operativa, basada en una fábrica de integración.

● Transferencia de tecnología, de manera que la unidad operativa aprehenda la práctica y lograr así el control total de la práctica de integración empresarial SOAr.

14Del inglés ENS, Enterprise Nerve System


SOArv1.1

8.2 Estrategia de implementaciónPara implementar un Sistema Nervioso Empresarial SOAr, la forma más adecuada de llevarlo a cabo es a través de aproximaciones sucesivas. Cada iteración se basa en la provisión de servicios de negocio a proyectos de Soluciones de Negocio.

Con cada iteración, SOAr va asimilando nuevas aplicaciones de la plataforma de tecnología, hasta llegar a un punto en el cual todas las aplicaciones se encuentran integradas a través de SOAr.

A continuación se presenta una secuencia de pasos correspondiente a una iteración que muestra como se “encapsula” una aplicación que ha de ser sustituida, para luego ser sustituida utilizando los beneficios de SOAr.

8.2.1 Ejemplo de una IteraciónInicialmente, la plataforma de tecnología se encuentra completamente integrada a través de cualquier mecanismo no SOAr. En la figura se muestra un ambiente de aplicaciones integradas todas entre si a través del modelo punto a punto de primera generación.

Cada una de las cuatro aplicaciones implementa una Función particular, la cual está identificada debajo de cada aplicación, desde la Función 1, hasta la Función 4.

Figura 20: Situación inicial


SOArv1.1

Como primer paso, se instala el bus de servicios de integración (ESB), se instalan los conectores para cada una de las tecnologías relacionadas con cada una de las aplicaciones relacionadas con la iteración; finalmente se conectan las aplicaciones en el ESB exponiendo dentro del ESB los proxys cada uno de los canales.

Figura 21: Paso 1 de la Iteración

Como segundo paso, se exponen los Servicios del Negocio (BSI) en la plataforma de servicios, implementando la lógica de integración encapsulando la realidad compleja y exponiendo servicios del negocio simples organizados por Componentes Funcionales.



SOArv1.1

Luego, como paso numero tres (3), se realiza el “Encapsulamiento” de la aplicación o aplicaciones que van a ser sustituidas; el “Encapsulamiento” se basa en asegurar que cualquier interacción que ocurre con la aplicación a “Encapsular” se haga a través de la plataforma de servicios del negocio y nunca directamente. En el ejemplo, será sustituida la aplicación numero tres por lo que todas las demás que interactúan con esta aplicación son modificadas para que consuman los servicios del negocio que proveen las funcionalidades propias de la aplicación numero tres.


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.

En el siguiente paso (numero 4), se instala y se conecta al ESB la nueva aplicación que será la sustituta. En el ejemplo aparece la numero cinco, la cual también implementa la misma Función que la aplicación que va a sustituir; evidentemente la nueva aplicación incorporará nuevas funcionalidades o características que no disponía la aplicación tres.


SOArv1.1


Como siguiente paso (paso 5), la plataforma de integración con cada solicitud de los servicios del negocio relacionados con la Función a sustituir emite una copia de la solicitud a la nueva aplicación, con el fin de generar un paralelo.


Luego de que puede considerarse como culminado la etapa de “paralelo” de la nueva aplicación, es posible configurar el Servicio del Negocio para que solo responda con los resultados de la nueva aplicación, entrando oficialmente “En Producción”.


SOArv1.1


Una vez pasado un tiempo prudencial de estabilidad de la nueva aplicación “en producción”, la aplicación sustituida puede ser desincorporada (ver Paso 7).


8.3 Enfoque pragmáticoLa dinámica de los proyectos de implementación de soluciones de negocio tiende a ser de bastante presión y tiempos de entrega subdimensionados. Esta situación plantea al equipo técnico responsable de implementar la plataforma 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.


SOArv1.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, en el último caso se requiere como paso preliminar (y no para el de punto a punto) la creación de la especificación de servicios del negocio (BSI), lo cual crea un costo adicional en tiempo que puede generar los siguientes inconvenientes:

1. 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.

2. La implementación de los servicios del negocio podría estar en la ruta crítica de los proyectos de solución de negocio, con lo cual usted estaría asumiendo un riesgo importante desde la perspectiva de gestión de proyecto, y consecuentemente del rendimiento como actor en su entorno empresarial.

Con el fin de evitar por completo estas circunstancias, a continuación se presenta el enfoque pragmático de implementación que le permitirá lograr los objetivos de SOAr integrando aplicaciones en tiempos de una integración punto a punto.

Dado que la actividad que “retrasa” el proceso de integración respecto a la referencia de punto a punto es la generación del BSI, el enfoque pragmático plantea sacar esa actividad de la ruta crítica, generando una integración que implementa las adaptaciones para cada “consumidor” en función de los proxy y no en función de los servicios del negocio (core).

En la siguiente lámina se muestra como, desde la perspectiva de la anatomía agnóstica de proveedor de SOAr, las adaptaciones implementan internamente la lógica de integración directamente contra los proxy.


SOArv1.1

Figura 28: Enfoque pragmático de implementación de SOAr - Estado temporal

El estado en el que se encuentra la implementación de la solución de integración mostrado en la lámina anterior es temporal; mientras este estado entra en producción, entregando resultados a sus “clientes”.

En paralelo es definida la BSI y los servicios del negocio expuestos y probados para luego modificar las “adaptaciones” para que hagan uso de los servicios del negocio; entonces, queda la arquitectura interna del ESB como se muestra en la siguiente figura.


SOArv1.1

Figura 29: Enfoque pragmático de implementación de SOAr - Estado final

8.4 Modelo de servicio

Existen dos formas de implementar un servicio corporativo de integración, la primera a través de un modelo Inflexible y el segundo usando un modelo Flexible. Cada forma define el modelo de servicio que una entidad corporativa puede adoptar.

En el primer modelo, llamado Inflexible, las aplicaciones deben adaptarse a los Contratos canónicos que implementan los Servicios del Negocio que viven en la plataforma de integración. Esto implica que el equipo desarrollador, encargado de la realización de cambios en las aplicaciones, debe modificar algunos módulos de las aplicaciones existentes o en su defecto crear módulos nuevos, siempre y cuando existan diferencias entre los contratos de los servicios corporativos y los que cumple la aplicación.

Desde la perspectiva del modelo tecnológico de la plataforma de integración, este modelo inflexible implica las aplicaciones consumen directamente los


SOArv1.1

Servicios del Negocio sin necesidad de que la plataforma exponga servicios específicos de aplicación.

En el segundo modelo, llamado Flexible, la plataforma de integración no sólo expone los servicios corporativos con su Contrato canónico, sino que expone un servicio “a la medida” de cada aplicación cliente llamado “Adaptación”. De esta manera, el aplicativo no debe ser modificado para poder hacer uso de los servicios corporativos.

La decisión de implementar alguno de los modelos propuestos anteriormente va a depender fundamentalmente de la cultura organizacional de la empresa. A continuación se presenta un análisis de las diferencias entre ambos modelos que le permitirán decidir cuál se ajusta más a su realidad y por ende representa la mejor opción de valor y sobre todo mayor probabilidad de éxito.


SOArv1.1

9 Recomendaciones de implementación

9.1 Modelaje de procesos

9.1.1 DefiniciónTres definiciones de proceso:

● Actividad que se lleva a cabo en una serie de etapas para producir un resultado específico o un grupo coherente de resultados específicos, o bien como un grupo de acciones que tienen un propósito común que hace avanzar el negocio en alguna forma.

● Organización racional de personas, materiales, energía, equipos y procedimientos en actividades concebidas para producir un resultado final específico.

● Conjunto de pasos que se realizan de forma sucesiva en distintas dependencias, con el objeto de transformar una serie de entradas específicas en una salidas (bienes o servicios) deseadas, añadiendo valor.

9.1.2 Componentes básicos

● Qué (Actividades)


SOArv1.1

● Quién (Recursos)● Cuándo (Tiempo)● Dónde (Ubicación)● Cómo (Documentos de Entrada, Salida, Métodos manual /

automatizado / combinado)

9.1.3 Consideraciones

● No se concibe un proceso sin un objetivo.● Las actividades de un proceso deben estar escritas en infinitivo y

deben plasmar el fin que se busca. Ejemplo: “Verificar la morosidad del cliente”.

● El documento o insumo inicial se convierte en valor agregado.● Tienen un principio y un fin: inician con determinada acción o evento

y finalizan en otro.● Cada paso se ubica en determinado lugar, por eso es importante la

secuencia dentro del proceso.

Los procesos en la organización se identifican a partir de la norma de constitución de la entidad, quien define sus objetivos, productos o servicios, y funciones.

Estos en conjunto con la definición de la misión de la organización, la cual determina el valor agregado de la entidad, formalizan los procesos y subprocesos que debe adelantar el ente gubernamental o empresa, a fin de cumplir con sus objetivos, productos o servicios que le son demandados.

9.1.4 Actores

Cuando se define un proceso es indispensable identificar los actores que participan en cada una de las actividades del mismo, típicamente son los siguientes:

● Los proveedores: son quienes suministran los materiales y las informaciones requeridas para ejecutar el proceso.

● Los responsables del proceso o productores: son todos aquellos que aportan su trabajo personal en las diferentes etapas del proceso para


SOArv1.1

lograr que el resultado cumpla con todos los requisitos exigidos por el cliente.

● Los clientes: Los destinatarios finales del producto o servicio y los que en definitiva juzgan su calidad, en la medida en que satisface sus necesidades y expectativas.

La relación cliente-proveedor se produce entre las distintas unidades, grupos de trabajo o personas que intervienen en un proceso. Esto quiere decir que cada una es a la vez un cliente para aquella que la precede en la generación de un producto, y un proveedor para quien la sucede.

Cada unidad, grupo de trabajo o persona ha de realizar su labor de forma que cumpla con todos los requisitos que necesita su “cliente”, para que este último pueda continuar eficazmente con su parte en el proceso. Y así sucesivamente.

9.1.5 ¿Cómo identificar un proceso?

Para identificar un proceso bastaría con adoptar la perspectiva de los clientes como punto de partida, identificando en primer lugar todos los productos o servicios puestos a su disposición y, a continuación, todos los pasos que se realizan para proporcionárselos.

9.1.6 Aspectos relevantes

Si nos detenemos un momento a reflexionar sobre la entidad que vive, se transforma y crece, encontramos que los procesos:

● Son mutuamente dependientes, ya que ninguno coexiste sin la ayuda o intervención de otro. No existen procesos autónomos, así se trate del más breve o humilde.

● Se interceptan unos con otros y se retroalimentan en forma permanente.

● Se agregan valor o se desgastan entre sí.

● Tienen cabeza o iniciación que son la finalización o cola de otros.


SOArv1.1

● Bien ejecutados facilitan la ejecución exitosa de otros

● Cruzan líneas fronterizas organizacionales, porque usualmente tienen que ver con más de una dependencia de manera directa o indirecta

9.1.7 Representación gráfica

9.1.7.1 El diagrama

La representación gráfica del proceso, se convierte en un instrumento muy importante para guiar su ejecución en forma ordenada; busca mostrar en forma dinámica y lógica la secuencia del trabajo, permitiendo conocer y comprender el proceso que se describe, a través de los elementos como las actividades, los documentos y las unidades administrativas y cargos que intervienen en él.

9.1.7.2 Características

El flujograma es una herramienta de representación gráfica de gran importancia para el levantamiento, análisis, diseño, mejoramiento y control de los procesos.

Estandariza la representación gráfica de los procesos de trabajoIdentifica con facilidad los aspectos más relevantes del trabajoFacilita el análisis y mejoramiento de los procesos, propendiendo por la eliminación de trámites innecesarios, suprimiendo lo que no es esencial y simplificando lo que sí es.Muestra la dinámica del trabajo y los responsables del mismoFacilita la ejecución del trabajoImpide las improvisaciones y sus consecuenciasEvita el desvío o distorsión de las prácticas de la empresaProvee elementos que facilitan el control del trabajo

9.1.7.3 Ventajas

Describe en forma sencilla el paso a paso de cada proceso y complementa la descripción literal, facilitando su consulta


SOArv1.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, desde el más simple hasta el más complejo

Permite la visualización rápida e integrada de un proceso, facilitando el examen de los pasos, la secuencia y las responsabilidades de los ejecutantes

Identifica rápida y fácilmente los puntos débiles y fuertes del proceso

Propicia la visualización de la distribución del trabajo entre los empleados y entre las dependencias

9.1.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.● Las actividades de un proceso deben estar escritas en infinitivo y

deben plasmar el fin que se busca. ● El lenguaje de actividades del proceso debe ser cónsono con la cultura

organizacional

9.2 NomenclaturaPara todo proyecto de integración es siempre recomendable establecer un conjunto de convenciones de nombre que ayuden a mantener de forma ordenada y auto-descriptible los objetos, los nombres escogidos serán utilizados a lo largo de diversas plataformas por lo cual debe escoger una convención que sea transparente y desvinculada de la tecnología subyacente.

La mayoría de los ESB permiten los nombres tanto en mayúsculas como minúsculas, sin embargo son sensitivos a la variación, por lo cual debe tener cuidado y no ser ambiguo en la descripción. Existen además, ocasiones especiales en los que la plataforma de sistemas tiene restricciones específicas


SOArv1.1

sobre el uso mayúsculas/minúsculas, si este es su caso, por favor adapte estas recomendaciones de acuerdo con esas reglas.

Debido a las restricciones recogidas de los ESB mas populares, los caracteres permitidos para los nombres de los elementos a lo largo de la plataforma son los caracteres del alfabeto inglés, números, el subrayado (_) y el punto (.) exclusivamente; el largo de los nombres esta delimitado en algunas ocasiones.

Las reglas generales para los objetos internos se describen a continuación, adicionalmente más adelante se describen los casos particulares y sus condiciones específicas.

● Los nombres que representan los paquetes deben estar en todo minúscula.

● Los nombres que representan tipos deben ser sustantivos y en minúsculas, la inicial de cada palabra debe ser en mayúscula.

● Los nombres de variables deben estar en minúsculas, en caso de mas de una palabra la inicial de cada palabra luego de la primera debe ser mayúscula.

● Los nombres que representan los constantes (variables finales) deben ser en mayúsculas usando el subrayado (_) para separar palabras.

● Los nombres que representan métodos deben ser verbos, en caso de mas de una palabra la inicial de cada palabra luego de la primera debe ser mayúscula.

● Los subrayados y otros caracteres especiales no se deben utilizar en los nombres de variables, nombres de método.

● Las variables genéricas de los nombres de clase deben tener el mismo nombre que su tipo.

● Los nombres de variables binarias negadas deben ser evitados.

Las reglas generales se aplican a todos los objetos, en particular a la programación interna de ellos, el consumo de servicios o la exposición de los mismos. En adelante se explican los detalles internos de cada tipo de objeto.

9.2.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. Siempre se debe incluir al menos un nodo de entrada para poder construir un servicio.

Según la definición del proceso a crear se configura el flujo del mensaje, se determina qué acciones se realizan en un mensaje cuando se recibe, y la orden en la cual se terminan las acciones. Se pueden utilizar flujos propietarios o del fabricante, subflujos o invocar flujos externos.


SOArv1.1

El esquema general para definir los objetos dentro del ESB sigue la siguiente definición:[Proyecto/Proceso]_<funcionalidad>_<nombreObjeto><TipoObjeto>.<versión>, donde:

[Proyecto/Proceso] reflejando por 3 caracteres las siglas del proceso/proyecto en cuestión. En la sección de Servicios Genéricos y Servicios Específicos se explica cuando usar uno u otro.<funcionalidad> indicando la razón específica del servicio<nombreObjeto> representa al nombre del objeto en cuestión, según las reglas que serán descritas mas adelante en el presente documento.<TipoObjeto> reflejando por 3 caracteres en mayúsculas el tipo de objeto al que se hace referencia. Cada uno de los objetos definido mas adelante indica su abreviación para ser colocada como tipo de objeto.<versión> indicando la versión del objeto. En algunos casos los productos permiten manejar un control interno de la versión facilitando y automatizando su manejo. Aún siendo este el caso es recomendable mantener el número de la misma (aunque sólo represente cambios mayores), de esa forma se obtiene una rápida comprensión del elemento y su evolución.

El esquema presentado es sencillo, directo y concreto, permite en una sola vista del nombre conocer el tipo de objeto en cuestión, la granularidad y generalidad de la funcionalidad a la que corresponde, su direccionalidad, evolución e incluso para los casos que corresponde su Transaccionalidad. De esta forma se coordina el trabajo de los distintos miembros del equipo y el proceso de pase a producción es automatizable en el mejor de los casos ( dependiente de las herramientas utilizadas ) y en cualquiera de ellos procedimentable sin ambigüedades, los equipos de arquitectura, desarrollo, administración y operación conocen exactamente que esperar el uno del otro sin necesidad de frecuentes y largas reuniones de sincronización.

9.2.2 Nodos (N** )Un nodo es un elemento en el flujo de un servicio que recibe un mensaje, realiza un conjunto de acciones sobre el mensaje, y opcionalmente, pasa el mensaje modificado al nodo siguiente en el flujo. Los nodos pueden ser propietarios, del fabricante o sub flujos.

Los nodos personalizados son los que ofrecen la capacidad de generar código específico a una acción determinada no contemplada en los nodos del fabricante, estos nodos deberán contener el prefijo NPR_ en el nombre del objeto. La mayoría de los ESB contemplan esquemas que permiten programar a cualquier nivel los nodos, esta opción debe ser sin embargo tomada con cautela y generar un registro de nodos personalizados creados. Los nodos del fabricante pueden ser de entrada o salida, mapeo o transformaciones, las


SOArv1.1

funcionalidades especiales de los productos específicos de algún fabricante no son objeto del presente documento.

Los subflujos, son flujos de servicios compuestos de nodos y conectores y están diseñado para ser embebido en otro flujo o subflujo, debe componer al menos un nodo de entrada y uno de salida y permite encapsular rutinas o servicios específicos internos. Los subflujos siguen las mismas reglas de nomenclatura de los flujos.

9.2.3 Nodos de Entrada/Salida (NIN_ / NOU_ )Los nodos de entrada / salida representan son los accesos de dato o exposiciones de los flujos, su trabajo es manejar la representación inicial o final de los mensajes. Estos nodos deben ser identificados con NIN_ (nodos de entrada ) y NOU_ ( nodos de salida ) en el nombreObjeto.

9.2.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. Los nuevos mensajes se pueden construir a partir de información nueva, información modificada de un mensaje recibido o información tomada de una fuente de datos externa ( típicamente una base de datos ).

Los componentes del mensaje de salida se pueden definir usando los mapeos que se basan en elementos del mensaje y de los datos de la entrada de una fuente externa. Se pueden modificar las asignaciones hechas por estos mapeos utilizando funciones propietarias definidas por el usuario o de la librería del fabricante.

9.2.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, que será utilizada para generar un mensaje de salida con una representación distinta. Su nomenclatura inicia con una T y un caracter adicional para indicar el tipo de transformación que es utilizada.

Las transformaciones son capaces de obtener una representación distinta de documentos en XML, IDOC, JMS, MIME, BLOB o tipos propietarios, la mayoría de los ESB cuentan con nodos predefinidos que permiten generar estas transformaciones de forma sencilla y automática.


SOArv1.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.


SOArv1.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.1Premisas


SOArv1.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.2Comparación con otros modelosLos 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.


SOArv1.1

10.2.1IBM

10.2.2RUP

10.2.3Sun Microsystems


SOArv1.1

10.2.4SOA Institute


SOArv1.1

10.2.5SAP

10.3Ciclo de vida de un servicioEn la medida que se van atendiendo las necesidades del negocio, la metodología SOAr genera una evolución en los servicios en forma de ciclo de vida la cual se muestra a continuación.


SOArv1.1

En la figura del ciclo de vida de un servicio SOAr, cada paso representa lo indicado a continuación:

● Descubrir● En esta etapa el servicio se ha descubierto del análisis de los

procesos del negocio.● Especificar

● El servicio ha sido especificado desde el punto de vista del requerimiento del proceso.

● Refactorizar● Los arquitectos han generado la refactorización que identifica

el contrato que ha de ser “realizado”.● Realizar (Creación / Evolución)

● Cumplimiento del contrato basado en la evolución de contratos existentes o creación de uno nuevo.

● Disponibilizar● Disponibilidad del servicio que implementa el contrato en la

plataforma de ESB● Desincorporar

● Desincorporación del servicio de la plataforma de ESB

Es importante resaltar que un servicio puede tener múltiples versiones disponibilizados a la vez; se espera que la versiones más “viejas” tiendan a desincorporarse de manera que sean utilizadas las versiones más recientes.


SOArv1.1

10.4Gobernabilidad

La ejecución de un proyecto de SOA / BPM requiere la participación de un equipo de personas con roles variados, teniendo cada rol funciones y exigencias de conocimientos y competencias diferentes.

A continuación se presentan los roles y el funciograma recomendado.

10.4.1RolesA continuación se listan los roles principales que deben ser suplidos por el equipo; las personas pueden ser las mismas para varios roles siempre que entiendan las distintas necesidades de cada rol que asumen en cada instante del tiempo.

● Funcionales● Representantes del “negocio”; dueños de los procesos.

● Analista, de procesos● Encargado de entender el proceso del negocio, modelarlo en la

herramienta y proponer oportunidades de eficiencia● Arquitecto, de servicios

● Encargado de llevar a cabo el análisis de brecha, refactorización e ingeniería de los servicios.

● Especialista, de conexión● Encargado de disponibilizar el “canal” de las aplicaciones como

proxies del ESB.● Probador

● Encargado de ejecutar los protocolos de prueba● Operador, de plataforma

● Encargado de mantener la plataforma de ESB y BPM funcionando y disponible.

10.4.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.


SOArv1.1

10.5Proceso


SOArv1.1

Plan● Planificación de tiempo y

recursos● Personas claves en múltiples

lugares al mismo tiempo!


SOArv1.1

0. Definición funcional● Procesos y funcionalidades To-

Be.● Requerimientos técnicos

previstos

1. Documentación del requerimiento● “intercambios” y “casos de uso”

2. Análisis● Especificaciones basadas en

“interacciones”.● Define secuencia de

interacciones● Defines en detalle cada dato a

ser intercambiado así como protocolo.

3. Arquitectura● Identifica la realización de cada

especificación de interacción.● Eliminación de redundancias

dentro del lote de requerimientos.

● Reuso y extensión de servicios existentes (Ciclo de vida de servicios)

4. Diseño● Contratos físicos● Transformación de datos

5. Construcción y prueba● Transformaciones de datos● Lógica de servicios● Conexiones y adaptaciones


SOArv1.1

10.5.1Documentación del requerimientoEn sesiones de levantamiento de requerimientos, orientadas por “procesos”, 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.● Los procesos y funcionalidades son confirmadas desde el punto de

vista técnico.● El equipo de integración identifica “intercambios” y “casos de uso”● Las sesiones concluyen con una lista de brechas y cambios

funcionales.

10.5.2AnálisisPara cada “Caso de Uso” identificado en la etapa anterior, 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. 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.


SOArv1.1

● Todo proveedor debe atender “en línea”● Los consumidores pueden integrarse basado en su preferencia

(archivo plano, en línea, etc.)● Ejecución de transformación de espacios vectoriales para

simplificación y flexibilidad. Por ejemplo, catálogo de producto.

● Evaluación de las “oportunidades de optimización” con el equipo de proyecto y arquitectos de aplicativos.

● Decisión respecto a las “oportunidades de optimización”.● Documentación de requerimientos especiales, tales como convivencia,

conversión, etc.● Documentación del mapeo de los datos en los “intercambios”.

10.5.2.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.● Transformación de catálogos

● Correlación de referencias cruzadas entre datos entre diferentes sistemas representando el mismo “objeto”.

● Apilamiento, para proveer un servicio en línea basado en un proveedor en lotes (batch).

10.5.3Arquitectura● Identifica la realización de cada spec de interacción.● Eliminación de redundancias dentro del lote de

requerimientos.● Reuso y extensión de servicios existentes (Ciclo de vida de

servicios). Considerar aplicación de refactorización para mantener servicios genéricos y cumplir con los nuevos requerimientos al mismo tiempo.


SOArv1.1

10.5.4Diseño

Para cada servicio debe especificarse la siguiente información:

● “Namespace” y “id scheme” único.● Sincronía: Síncrono o Asíncrono● Naturaleza: En línea, 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.● Retorno de estatus explícito para intercambios asíncronos.● Información no técnica:

● Cantidad (tráfico)● Frecuencia● Tiempo de respuesta requerido

● Protocolos de pruebas unitarias

10.5.5Construcción y pruebasEl 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, menor su tiempo y pruebas del código de integración.

10.5.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”


SOArv1.1

● Fin de Vida

10.5.7Herramientas de Software Libre

Cualquier ESB del mercado hoy en día puede ser utilizado para hacer una implementación de SOAr. 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.

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, y así asegurar que la forma como se implementa sea la adecuada para tener una arquitectura de integración EAI de 4ta generación.

Con el fin de asegurar el concepto en un ambiente Libre, 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.codehaus.org)

Si bien Gurulab.org puede proveer talleres de formación en el uso de Mule, se encuentra desarrollando un software de integración ESB basado en las expectativas de la plataforma ideal planteado en este documento. 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.


SOArv1.1

11 Glosario

11.1ProcesoSerie de actividades secuenciales e interdependientes, orientadas a la consecución de un resultado, en el que se agrega valor a un insumo y se contribuye a satisfacer una necesidad.

11.2ProcedimientoConjunto o sucesión de pasos, ampliamente vinculados y cronológicamente dispuestos, realizados al interior de la entidad por el servidor público y dirigidos a precisar la forma de hacer algo, incluyendo el qué, cómo y a quién corresponde el desarrollo de la tarea.

11.3Diagrama de flujoRepresentación gráfica de un proceso o de un procedimiento que permite la observación sistemática de su ejecución, mostrando la dinámica y lógica de la secuencia del trabajo.

11.4Intercambios vs Servicios vs Interacción

Existen básicamente dos modelos de comunicación entre aplicativos, al primero le hemos llamados “Modelo de Intercambio” y al segundo “Modelo de Interacción”.

En un Modelo de Intercambio las aplicaciones se comunican entre si directamente, es decir no existe intermediario alguno entre ellas, 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, 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.

Para este modelo, la comunicación está constituida por un intercambio15 entre dos aplicaciones, esta comunicación está representada en la siguiente Figura, donde A y B son aplicativos que requieren comunicarse.

15 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.


SOArv1.1

Figura 30: Intercambio

La arquitectura Cliente Servidor podría ser considerado un ejemplo de comunicación de intercambio, pues es una arquitectura que proporciona al usuario final el acceso transparente a las aplicaciones, datos, servicios de cómputo o cualquier otro recurso del grupo de trabajo y/o, a través de la organización, en múltiples plataformas. Esta arquitectura soporta un medio ambiente distribuido en el cual los requerimientos de servicio hechos por estaciones de trabajo inteligentes o clientes16, resultan en un trabajo realizado por otros computadores llamados servidores17. En el segundo modelo llamado Modelo de Interacción, la comunicación entre las aplicaciones no se realiza directamente, es decir existe un intermediario, este intermediario es la plataforma de integración.

De tal forma que es si un aplicativo A desea comunicarse con un aplicativo B, debe solicitar el servicio a la plataforma de integración P y esta gestiona la petición interactuando directamente con B, posteriormente B emite una respuesta la cual viaja hasta P y esta la entrega al aplicativo A. El planteamiento descrito anteriormente se ilustra en la siguiente Figura.

Figura 31: Interacción

16 El cliente (C) es un consumidor de servicios.17 El servidor (S) es un proveedor de servicios.


SOArv1.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.

Esto implica que no necesariamente los servicios manejados por las aplicaciones deben tener un mismo estándar, 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.

11.5Webservices

El servicio web es esencialmente un conjunto de protocolos y estándares que sirven para ejecutar servicios e intercambiar datos entre aplicaciones; 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).

Adicionalmente a las especificaciones de los servicios web, el consorcio de interoperabilidad de webservices (WS-I) ha establecido una serie de extensiones que complementan su utilidad, siendo algunas de estas las siguientes:

1. WS-Security, Define cómo cifrar y firmar ( para su autenticación ) el contenido de un mensaje xml transportado por el servicio web

2. WS-Reliability, Define un protocolo que garantiza la confiabilidad del mensaje3. WS-Transaction, Define un mecanismo para el manejo de transacciones

18 Interacción: Es la acción que se ejecuta entre una aplicación y la capa de integración, que forman parte de un intercambio. Todo intercambio tiene como mínimo 2 interacciones.


SOArv1.1

12 GNU Free Documentation LicenseA continuación se presenta la licencia de Documentación Libre según la FSF la cual está publicada en http://www.gnu.org/copyleft/fdl.html

No se presenta una versión en el Idioma Español por no existir una versión oficial en dicho idioma.

GNU Free Documentation License

Version 1.2, November 2002

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USAEveryone is permitted to copy and distribute verbatim copiesof this license document, but changing it is not allowed.

0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS


http://www.gnu.org/copyleft/fdl.html

SOArv1.1

This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

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. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, 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, and


SOArv1.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 copy made in an otherwise Transparent file format whose markup, or absence of markup, 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. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. 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, preceding the beginning of the body of the text.

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. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) 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.

The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, 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.


SOArv1.1

2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, 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, free of added material. If you use the latter option, you must take reasonably prudent steps, when


SOArv1.1

you begin distribution of Opaque copies in quantity, 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.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

• A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

• B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.

• C. State on the Title page the name of the publisher of the Modified Version, as the publisher.

• D. Preserve all the copyright notices of the Document.• E. Add an appropriate copyright notice for your modifications adjacent

to the other copyright notices.• F. Include, immediately after the copyright notices, a license notice

giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

• G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

• H. Include an unaltered copy of this License.• I. Preserve the section Entitled "History", Preserve its Title, and add

to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its


SOArv1.1

Title Page, then add an item describing the Modified Version as stated in the previous sentence.

• J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

• K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

• L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

• M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.

• N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

• O. Preserve any Warranty Disclaimers.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. 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. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.


SOArv1.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.

5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements."

6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this


SOArv1.1

License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, 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. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.

If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.


SOArv1.1

9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, 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. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.


Documents

curso SOA español