Curso SOA Español

SOAr
v1.1
Página 1/103
Copyright (c) 2007-2008 Cesar Obach-Renner, Gurulab.org
info@gurulab.org, http://www.gurulab.org/
SOAr
v1.1
SOAr v1.1
(SOA recargada)
Un enfoque pragmático de Arquitectura Orientada a

Servicios (SOA) para Integración de Aplicaciones
Empresariales (EAI)
Autor
César Obach-Renner
Junio 2008
Página 2/103
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”.
Página 3/103
SOAr
v1.1
1 Contenido
1 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
Página 4/103
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
Página 5/103
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
Página 6/103
SOAr
v1.1
2 Prólogo
Página 7/103
SOAr
v1.1
3 Prefacio
Luego de tres años en el proceso de conceptualización, ingeniería básica y
detallada de una Arquitectura de Integración Orientada a Servicios, he
sintetizado una aproximación a la integración de aplicaciones empresariales
(EAI) que se basa en la implementación de una Arquitectura Orientada a
Servicios (SOA).
A lo largo de este documento, el lector tendrá la oportunidad de entender el

valor diferenciador de esta aproximación de SOA la cual llamo “SOA
recargado” (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 Gurulab

Gurulab.org es un laboratorio de innovación tecnológica dirigido por Cesar
Obach-Renner el cual busca el desarrollo de tecnologías de información y
comunicación o usos innovadores de éstos, apalancados en la imaginación y
conocimiento de sus miembros.
Página 8/103
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.
Página 9/103
SOAr
v1.1
3.3 Sitio web de apoyo e información de contacto

Esta publicación es el documento oficial del concepto SOAr perteneciente al
Framework de SOAr (en inglés SOAr Framework), 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 watermark
Minor Earth Mayor Sky @A-Ha
Thought That It Was You @A-Ha
She's Madonna @Robbie Williams
The 80's @Robbie Williams
Página 10/103
SOAr
v1.1
3.6 Dedicatoria y Agradecimientos

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

técnicos del ICE que me han brindado múltiples oportunidades de poner a prueba
estos conceptos logrando sanos e interesantes discusiones sobre Arquitectura.
Página 11/103
SOAr
v1.1
4 Introducción
A nivel mundial, todas las empresas se enfrentan a un reto que con los años
se ha venido intensificando independientemente del sector o industria; esto
es, la reducción de sus costos mientras aumentan su agilidad y velocidad para
innovar respecto a su oferta en el mercado.
La reducción de costos siempre ha sido un elemento clásico en la optimización

del valor de las empresas desde su existencia; sin embargo, ¿cómo es esto
posible esto a la vez que se mejoran las capacidades de innovación de la
organización? Para innovar tradicionalmente se requiere de inversión en
investigación y eso no es precisamente “reducción de costos”. Además, para
apoyar la disminución de costos de la empresa, una de las mejores
herramientas es el uso eficiente de Tecnología, lo cual implica un flujo mayor
en esa área1.
La respuesta que las grandes consultoras y los analistas han encontrado está
en la optimización de los procesos a todo nivel de la empresa y el uso de
plataformas tecnológicas extremadamente flexibles y poderosas sin dejar de
ser simples. Han logrado mediante la mejora de procesos claves del negocio
una respuesta sustancial respecto a la mejora del valor de sus clientes.
Como respuesta a esa necesidad, Gurulab.org ha desarrollado un modelo

referencial que define la Plataforma de Tecnología de Información de Nueva
Generación (en inglés NGITP como siglas de New Generation Information
Technology Platform); tiene como meta una plataforma ideal que provee
todas las características necesarias para lograr que la tecnología esté al
servicio del negocio a través del servicio de sus procesos, y no que el negocio
se adapte a las limitaciones de la plataforma.
Para conocer cuan cercano a ese “ideal” se encuentran las empresas, el

modelo referencial NGITP viene acompañado de un modelo de madurez que
describe 5 etapas o niveles de los cuales el nivel 5 es representa el “ideal”
planteado por NGITP y el nivel 1 es el más básico en el que toda empresa se
encuentra en el peor caso.
Tradicionalmente los procesos de una empresa se encuentran “programados”

(o como dicen los técnicos “cableados”) en las aplicaciones empresariales que
automatizan sus procesos y que utilizan para operar; cuando son varias las
aplicaciones utilizadas, la sincronización de sus procesos ocurre de manera
1
Existen empresas que para optimizar sus flujos de salida utilizan un criterio puramente
económico reduciendo los gastos e inversión en todas sus unidades incluyendo Tecnología, en vez
de un criterio Sistémico de optimización de sus procesos lo cual apalancado en una inversión
mayor en el área de tecnología permite resultados interesantísimos en el costo total de operación
de toda la empresa.
Página 12/103
SOAr
v1.1
más básica de forma manual. Esto último es lo que el modelo de madurez de

NGITP llama el nivel 1 (ver Figura 1).
En dicho nivel 1 de NGITP vemos un conjunto de “n” aplicaciones (App 1, App

2, ..., App n), las cuales dan vida a “j” procesos (p 1, p 2, ..., p j) y cada
interactuando con sus usuarios a través de “n” interfaces hombre-máquina
(GUI App 1, GUI App 2, ..., GUI App n) todas a este nivel a través de un único
canal de acceso Web (c1).
Nivel de Madurez
c1 c1 c1 c1
GUI App 1 GUI App 2 … GUI App n
p1 App 1 p2 App 2 p3 … … pj App n

1 - Silos
NGITP Maturity Model

Figura 1 Nivel 1 del modelo de madurez de NGITP
Se presenta generalmente la disyuntiva respecto a si una empresa debe

“adaptarse” a los procesos que lleva consigo una nueva aplicación, o por el
contrario debe “modificar” dicha aplicación para que ésta implemente los
procesos que la empresa lleva a cabo; cualquiera de ambas decisiones implica
un gran costo y un matrimonio con la nueva “configuración” que implique la
acción tomada.
Por ejemplo, un fabricante de aplicaciones empresariales alemán con sede en

Walldorf (Alemania) provee aplicaciones cuyo principal activo es la sólida
seguridad que provee a sus clientes respecto a los procesos que sus
aplicativos implementan; sus clientes tienden a “adaptarse” más que a
“modificar”, claro está, siempre con la facilidad de “ajustar” los procesos para
que calzar adecuadamente a ambos.
Ahora bien, si imaginamos una plataforma cuyo costo de configuración sea

despreciable, no solo implicaría una fácil decisión respecto a la adopción de
los procesos que la empresa desee (independientemente de que sean actuales
Página 13/103
SOAr
v1.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)
Página 14/103
SOAr
v1.1
Nivel de Madurez
c1 c1 c1 c1
Bus 2 - EAI

1 - Silos

Figura 2 Nivel 2 del modelo de madurez del NGITP
Solo queda válido como respuesta a nuestro planteamiento el escenario en el

que el proceso es controlado por “algo” de nivel superior. Este escenario
implica que las aplicaciones no controlan procesos sino que sirven “tareas” o
“funcionalidades” a ese ente superior que controla los procesos llamaremos
“Gestor de Procesos”.
Esta conclusión a la que estamos llegando es clara para muchos Arquitectos

empresariales y fabricantes de aplicativos en todo el mundo, quienes
convergen en la necesidad de desacoplar la gestión de los procesos de la
musculatura de ejecución de transacciones que representan las aplicaciones
bajo este nuevo enfoque.
La casa de Walldorf lo acepta también no solo sacando al mercado

herramientas para coreografía de procesos, sino generando rutas de
evolución de sus aplicaciones para sacar los procesos de sus cajas hacia su
coreógrafo de procesos.
Ahora bien, ¿cuál es el estado de nuestra solución? Hemos dibujado hasta

ahora una plataforma que consta de una colección heterogénea de
aplicaciones que exponen funcionalidades o tareas que son “orquestadas” por
un gestor de procesos. Como puede verse, ahora lo “súper configurable” no
es una característica a buscar en las aplicaciones, sino en la arquitectura que
se establece entre el Gestor de Procesos y los aplicativos.
Página 15/103
SOAr
v1.1
Para lograr esa característica “súper configurable” basta con proveerle al

Gestor de Procesos tres (3) elementos fundamentales:
1) un mecanismo de desacoplamiento de las funciones que los procesos

modelados desean ejecutar, de las aplicaciones que realmente serán las
responsables de ejecutarlas.
De esta manera, el desarrollo de las reglas del negocio basadas en procesos

son independientes de la colección de aplicaciones que la plataforma de
sistemas tenga en cualquier momento. Esto le devuelve al negocio el poder de
sus procesos, delegando únicamente a Tecnología la tarea de proveer los
componentes sobre los cuales viven los procesos.
Esto es logrado a través de la exposición de servicios que muestran una vista

de las funcionalidades y datos de las aplicaciones subyacentes en un formato
canónico simple, idealmente estándar. Esto es lo que el modelo de madurez
de NGITP plantea como nivel 3 (ver Figura 3). A estos servicios les llamamos
“Servicios del Negocio”.
Nivel de Madurez
c1 c1 c1 c1
Servicios
S1 S2 S3 … Sm 3-
Corporativos
Bus 2 - EAI

1 - Silos

2) un gestor de procesos con una interfaz de definición simple y poderosa,

el cual esté basado en la coreografía de los servicios corporativos
expuestos.
Página 16/103
SOAr
v1.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.
Nivel de Madurez
c1 c1 c1 c1
GUI p1 GUI p2 … GUI pj
p1 p2 p3 … pj Process Manager 4 - BPM
Servicios
S1 S2 S3 … Sm 3-
Corporativos
Bus 2 - EAI
App 1 App 2 … App n

1 - Silos

En dicha Figura note cómo la interfaz gráfica ya no corresponde a interfaces

de aplicaciones sino de procesos, es decir, en lugar de que los usuarios
interactúen con las funcionalidades de las aplicaciones a través de ellas, lo
harán en el contexto de los procesos orquestados por el Gestor de Procesos y
a través de él.
3) Una interfaz de usuario para ejecución de procesos que se construya

automáticamente a partir de la definición del proceso.
Como elemento final del modelo de madurez, tal como se muestra en la

Figura 5, el nivel 5 incorpora tecnología que adapta de manera automática las
interfaces de interacción hombre-máquina para permitir la interacción de los
usuarios con los procesos modelados en el Gestor de Procesos.
Página 17/103
SOAr
v1.1
Nivel de Madurez
c1 c2 … ci
SmartInterface 5 - SmartInterface
Servicios
S1 S2 S3 … Sm 3-
Corporativos
Bus 2 - EAI

1 - Silos

En la figura del nivel 5, se puede observar que existe una sola lógica de
interfaz que se adapta a todos los procesos por cada canal. En particular, el
primer canal ejemplificado es el canal Web.
Este nivel provee no solo la ventaja de bajo costo en el mantenimiento de las

interfaces para soportar nuevos canales, sino que al final del día para poder
cambiar los procesos que se ejecutan en la empresa, basta con cambiar su
definición e instantáneamente el sistema se adapta a la nueva definición. El
modelo de interfaz adaptable es llamado SmartInterface como un concepto
incorporado por NGITP.
Página 18/103
SOAr
v1.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)
Página 19/103
SOAr
v1.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.
Página 20/103
SOAr
v1.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.
Página 21/103
SOAr
v1.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.
Página 22/103
SOAr
v1.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 Punto
ii) Broker
iii) SOA
iv) 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
2
C n=

n
=
n!
2 2 !−  n−2  !
2
EAI por sus siglas en inglés de Enterprise Application Integration.
Página 23/103
SOAr
v1.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.
Página 24/103
SOAr
v1.1
5.1.3 Tercera generación: SOA

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

incluir en su producto un conjunto de servicios web que exponen las
funcionalidades de su aplicativo, están proveyendo una aplicación “Compatible
con SOA”.
Si bien esto no es equivocado, lo que ha ocurrido en el mercado es que las

empresas han entendido que al integrar sus aplicaciones al hacer uso de estos
servicios expuestos por los aplicativos, están implementando una Arquitectura
Orientada a Servicios.
Sin generar ningún juicio de valor, Gurulab ha catalogado esta práctica como
tercera generación de EAI, mejor conocido como integración SOA, una
colección de servicios que colaboran entre si.
Dado que el planteamiento de arquitectura tradicional se ha basado en un

modelo de “colección de aplicaciones” que encapsula completamente todas
sus funcionalidades detrás de sus interfaces gráficas, SOA provee la gran
ventaja de permitir y fomentar el reuso de funcionalidades ya implementadas
por los aplicativos existentes al estar éstas expuestas completamente a través
de servicios disponibles para cualquiera que los requiera.
Para los fanáticos del modelo de arquitectura de n-capas, SOA representa la

colección de funcionalidades de la capa de “lógica de negocio” que toda
aplicación tiene en dicho modelo. En este contexto SOA plantea que toda
aplicación expone todas sus funcionalidades a través de servicios.
En el modelo de EAI de 3ra generación, la comunicación que existe entre

aplicaciones no se basa en el enrutamiento de mensajes de un lado a otro
(como ocurre con la del broker de la segunda generación), sino en el consumo
de servicios que cada aplicación expone con su respectivo Contrato, en una
forma punto a punto.
Página 25/103
SOAr
v1.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
3
CORBA, 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/
Página 26/103
SOAr
v1.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 XML
6
WSDL (siglas de Web Services Description Language): formato XML que se utiliza para
describir servicios Web.
7
UDDI (siglas de Universal Description, Discovery, and Integration) : es un Directorio en línea
que las aplicaciones utilizan para descubrir de forma dinámica otros servicios en línea.
8
DNS (siglas de Domain Name System): Sistema de nombre de dominios, provee una taxonomía
de etiquetas alfanuméricas que permiten asociar un servicio en Internet sin la necesidad de utilizar
la dirección física.
Página 27/103
SOAr
v1.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.
Página 28/103
SOAr
v1.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.
Página 29/103
SOAr
v1.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.
Página 30/103
SOAr
v1.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.
Nivel de Madurez
c1 c2 … ci
SmartInterface 5 - SmartInterface
SOAr Servicios
S1 S2 S3 … Sm 3-
Corporativos
Bus 2 - EAI

1 - Silos

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.
Página 31/103
SOAr
v1.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.
Página 32/103
SOAr
v1.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 flexible
3. Metodología pragmática de implementación
4. 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.
Página 33/103
SOAr
v1.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 BSI

Para poder definir claramente qué es la Calidad de una BSI y cómo se
consigue, es necesario definir previamente los siguientes conceptos:
Página 34/103
SOAr
v1.1
Composición de Funcionalidades
Se dice que una funcionalidad es “Compuesta” cuando ésta puede
expresarse en función de la ejecución de otras funcionalidades diferentes a
ella.
Derivación Funcional
Se dice que una función F es derivable cuando existe un conjunto de
funciones Fi diferentes de F tales que F es la composición de las Fi.
Funcionalidad Atómica
Se dice que una funcionalidad F0 es atómica si y sólo si no existen otras n
funcionalidades F1, F2, ..., Fn diferentes a partir de las cuales se puede
derivar F1.
Subconjunto Funcional
Se dice que una funcionalidad F1 es subconjunto funcional de una
funcionalidad F2 sí y sólo si la F2 es derivable a partir de un conjunto de
funcionalidades entre las cuales se encuentra F1.
Toda funcionalidad es subconjunto funcional de si misma.
Funcionalidades Ortogonales
Se dice que dos funcionalidades F1 y F2 son ortogonales si y sólo si no existe

una funcionalidad F3 tal que F3 es subconjunto de F1 y F3 es subconjunto de
F2.
Corolario
Dos funcionalidades son “no ortogonales” si alguna de ellas es subconjunto
funcional de la otra.
Calidad de una BSI
La calidad de una BSI es directamente proporcional a su capacidad de

absorber, sin modificación en su API, nuevas funcionalidades “no ortogonales”
respecto a las existentes, o nuevos rasgos en los datos del negocio.
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
Página 35/103
SOAr
v1.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.”).
Página 36/103
SOAr
v1.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 calidad

Con el fin de lograr una especificación de servicios del negocio de buena
calidad, es importante que el arquitecto de la especificación tome en cuenta
una serie de consideraciones las cuales se resumen en los siguientes
preceptos:
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 errores
4. 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/
12
API; del inglés Application Program Interface.
Página 37/103
SOAr
v1.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 funcional

Debido a la dinámica de la integración de aplicaciones empresariales, la
plataforma de servicios del negocio se verá afectada para cumplir con los
constantes cambios y nuevas necesidades.
Los cambios que puede sufrir la BSI pueden clasificarse de dos tipo:
● Agregación de funcionalidades ortogonales.
● Agregación de funcionalidades no ortogonales.
Es de esperar en un ambiente ideal que los sistemas y procesos que

consumen servicios del negocio “hereden” las nuevas funcionalidades de la
plataforma sin necesidad de ser modificados. Esta expectativa es alcanzable a
través de una BSI de alta calidad ante modificaciones de la plataforma que
agreguen nuevas funcionalidades no ortogonales.
Para que la plataforma provea esa “herencia” ante agregaciones de

funcionalidades ortogonales, la BSI debe ser definida basado en un
conocimiento de expectativas funcionales a futuro, más que de una práctica
de especificación con “calidad”.
En otras palabras, en RUNTIME, si uno agrega nuevas funcionalidades 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
Página 38/103
SOAr
v1.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 ortogonales

Cuando la BSI es afectada por la incorporación de nuevas funcionalidades no
ortogonales a las existentes en la BSI, el impacto dependerá de la calidad de
la BSI. En la medida que la BSI sea de mayor calidad, menor la cantidad de
cambios en los procesos o sistemas “consumidores”, aun disfrutando de las
nuevas funcionalidades incorporadas en la plataforma a través de la
“Herencia” que SOAr les confiere.
Página 39/103
SOAr
v1.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.
Página 40/103
SOAr
v1.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 eTOM
eTOM, componente del marco de referencia NGOSS del TMForum, es un
marco referencial de procesos de una empresa de telecomunicaciones. Este
marco referencial clasifica todos los procesos hasta un nivel de detalle casi de
la especificación de tareas específicas.
Sirve inicialmente como referencia estándar a la hora de nombrar los

procesos o partes de ellos (subprocesos). Para ello enumera una cantidad de
procesos clasificados en varias dimensiones según se muestra en la Figura 13.
Página 41/103
SOAr
v1.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 TAM
El Telecom Operations Map representa un catálogo que identifica y clasifica el
conjunto de Componentes Funcionales de una empresa de
Telecomunicaciones. A continuación se presenta la figura que muestra la
clasificación actual.
Página 42/103
SOAr
v1.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.
Página 43/103
SOAr
v1.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 MTOSI
Al igual que eTOM y el SID, MTOSI es una especificación agnóstica de
tecnología que define las interfaces entre elementos de la plataforma
operativa de una telco. En particular representa la especificación que SOAr
Página 44/103
SOAr
v1.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/J
Originalmente una iniciativa independiente del TMForum, fue desarrollando a
lo lardo del tiempo una implementación concreta del SID y de interfaces de
servicios (lo que MTOSI busca lograr) para aplicaciones concretas como
Gestor de Problemas (Trouble Ticket), Inventario, Gestor de Ordenes de
Servicio, Facturador, etc. Desde el 1 de Julio del 2006 es un capítulo oficial
del TMForum y además de ser accesible a través de la página oficial del
TMForum (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 Spec Lead &

OSS/J API Status Java.net
# Company
Maintenance
OSS Service Andreas Ebbert
89 Release
Activation Nokia Corporation
(v1.1)
OSS Quality of Final Release Srinivasa Samudrala
90
Service (v1.0) Motorola
Final Release Axel Terfloth
91 OSS Trouble Ticket
(v1.0) IP Value
Maintenance Tulika Pradhan
130 OSS Billing Mediation Release Infozech public
(v1.1) Software Limited
Final Release Pierre Gauthier
142 OSS Inventory public
(v1.0) MetaSolv Software
Maintenance
Vincent Perrot
144 OSS Common Release 3 public
Sun Microsystems
(v1.3)
OSS Service Quality Thierry Supplisson
210 Early Draft Review
Management Vallent
John Wilmes
251 Pricing Early Draft Review public
Ceon Corporation
Andrew Paterson
254 OSS Discovery Public Draft Review public
Nakina Systems
Página 45/103
SOAr
v1.1
JSR Spec Lead &

OSS/J API Status Java.net
# Company
David Raymer
263 Fault Management Early Draft Review public
Motorola
Andreas Ebbert
264 Order Management Public Draft Review public
Nokia Corporation
Performance David Raymer
285 Expert Group
Management Motorola
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
Página 46/103
SOAr
v1.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
Página 47/103
SOAr
v1.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.
Página 48/103
SOAr
v1.1
Página 49/103
SOAr
v1.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
Página 50/103
SOAr
v1.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).
Página 51/103
SOAr
v1.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
Página 52/103
SOAr
v1.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 2
Explotando la figura de la plataforma nivel 1, se tiene el nivel 2 el cual se
muestra en la Figura 19. La diferencia fundamental entre los dos niveles está
en la diferenciación de sub-capas.
Página 53/103
SOAr
v1.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 ideal

Idealmente, una plataforma que implemente esta arquitectura referencial
utilizaría dos conceptos que considero clave para tener una plataforma de
integración más ágil:
 La lógica de los servicios, ya sean a nivel de adaptaciones o Servicios

del Negocio, debe ser una herramienta visual o metalenguaje que
abstraiga la noción de la morfología de los datos.
 Los mapeos se definen entre pares de Objetos sin necesidad de hacer
una vinculación explicita en la lógica de los servicios.
Página 54/103
SOAr
v1.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 conectores

Los conectores poseen la funcionalidad de habilitar la comunicación entre dos
ambientes tecnológicos dispares, sin embargo, aquellos provistos por 3ros
(fabricantes) poseen adicionalmente capacidades de adaptación; estas
capacidades de “adaptación” son las de realizar transformaciones semánticas
en las estructuras intercambiadas. Es por esto que los fabricantes llaman
“Adaptadores” a sus conectores.
Para tener un conector funcionando, basta con proveerse de uno ya sea

construido “en casa” o tecnología de 3ros, cumpliendo las características
técnicas del mismo, y luego configurarle las semánticas que se desean
exponer al ESB, o características funcionales.
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:
Página 55/103
SOAr
v1.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.
13
La forma para medir la disponibilidad de un sistema es a través del cálculo del
porcentaje de tiempo activa en un período de un año, este cálculo se hace dividiendo el
número total de minutos de actividad por el total de minutos en el año ( aprox 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 )
Página 56/103
SOAr
v1.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.
Página 57/103
SOAr
v1.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
Página 58/103
SOAr
v1.1
8 Consideraciones estratégicas
A continuación se presentan un conjunto de herramientas estratégicas que le
permitirán planificar y ejecutar un proyecto de implementación de SOAr.
8.1 Sistema Nervioso Empresarial

Si bien usted podría utilizar la aproximación de SOAr para proveer servicios
de integración de 4ta generación a soluciones de negocio concretas como por
ejemplo la implementación de un CRM, 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.
14
Del inglés ENS, Enterprise Nerve System
Página 59/103
SOAr
v1.1
8.2 Estrategia de implementación

Para 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ón

Inicialmente, 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
Página 60/103
SOAr
v1.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.
Página 61/103
SOAr
v1.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.
Página 62/103
SOAr
v1.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”.
Página 63/103
SOAr
v1.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ático

La dinámica de los proyectos de implementación de soluciones de negocio
tiende a ser de bastante presión y tiempos de entrega subdimensionados.
Esta situación plantea al equipo técnico responsable de implementar la
plataforma SOAr el reto de proveer la solución de 4ta generación en tiempos
de proyecto a lo más como lo que tomaría implementarlo punto a punto.
Página 64/103
SOAr
v1.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.
Página 65/103
SOAr
v1.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.
Página 66/103
SOAr
v1.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
Página 67/103
SOAr
v1.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.
Página 68/103
SOAr
v1.1
9 Recomendaciones de implementación
9.1 Modelaje de procesos
9.1.1 Definición
Tres definiciones de proceso:
● Actividad que se lleva a cabo en una serie de etapas para producir un

resultado específico o un grupo coherente de resultados específicos, 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)
Página 69/103
SOAr
v1.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
Página 70/103
SOAr
v1.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.
Página 71/103
SOAr
v1.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 trabajo

Identifica con facilidad los aspectos más relevantes del trabajo
Facilita el análisis y mejoramiento de los procesos, propendiendo por la
eliminación de trámites innecesarios, suprimiendo lo que no es esencial y
simplificando lo que sí es.
Muestra la dinámica del trabajo y los responsables del mismo
Facilita la ejecución del trabajo
Impide las improvisaciones y sus consecuencias
Evita el desvío o distorsión de las prácticas de la empresa
Provee elementos que facilitan el control del trabajo
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
Página 72/103
SOAr
v1.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 Nomenclatura
Para todo proyecto de integración es siempre recomendable establecer un
conjunto de convenciones de nombre que ayuden a mantener de forma
ordenada y auto-descriptible los objetos, los nombres escogidos serán
utilizados a lo largo de diversas plataformas por lo cual debe escoger una
convención que sea transparente y desvinculada de la tecnología subyacente.
La mayoría de los ESB permiten los nombres tanto en mayúsculas como

minúsculas, sin embargo son sensitivos a la variación, por lo cual debe tener
cuidado y no ser ambiguo en la descripción. Existen además, ocasiones
especiales en los que la plataforma de sistemas tiene restricciones específicas
Página 73/103
SOAr
v1.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.
Página 74/103
SOAr
v1.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
Página 75/103
SOAr
v1.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.
Página 76/103
SOAr
v1.1
9.2.6 Servicios Genéricos & Servicios Específicos

Los flujos de mensajes representan servicios que permiten a través el ESB
generar una comunicación entre aplicativos disimiles resolviendo sus
necesidades de integración. Estos servicios son distintos entre sí de acuerdo a
su nivel de abstracción ( representando las necesidades del negocio ) o
particularidad ( representando las necesidades de un aplicativo específico ).
Los servicios genéricos representan las funcionalidades del negocio definidas a

partir de las mejores prácticas, provenientes de un análisis de procesos y
mapas de funcionalidades ( i.e. ETOM & TAM ). Los servicios específicos
representan las necesidades de los consumidores y típicamente contienen
alguna adaptación ( de la forma de filtrado o segmentado ) que permite
utilizar lo conceptos propios del aplicativo. Según las urgencias planteadas en
los proyectos estos servicios pueden temporalmente ser construidos para
consumir directamente los servicios de la plataforma de legados, sin embargo
lo recomendable es la utilización de uno o mas servicios genéricos para la
ejecución de sus actividades.
Los servicios generales están asociados a un proceso específico y a una

funcionalidad del mapa derivado de los procesos, son altamente reusables y
su granularidad varía según las necesidades de la empresa siendo permisible
la coexistencia de niveles distintos aparentemente redundantes, las reglas de
nomenclatura para estos flujos indican lo siguiente:
<siglasProceso>_<funcionalidad>_[<funcionalidad nivel
inferior>_]_<nombreObjeto>
donde,
<siglasProceso> indica las siglas del proceso al pertenece

<funcionalidad> indica la funcionalidad que el servicio esta
ejecutando. Estas funcionalidades en cualquiera de sus niveles deben
provenir del mapa derivado de los procesos. Típicamente esta
funcionalidad no tiene una representación directa en la plataforma de
sistemas.
Los servicios específicos están asociados a necesidades de integración de

proyectos o aplicativos, su utilidad esta directamente relacionada con el
proyecto o aplicativo al que sirven y son poco reusables, su construcción esta
basa internamente en el uso de servicios generales a modo de nodos de
subflujos. Las reglas de nomenclatura para estos flujos indican lo siguiente:
<siglasProyecto/aplicativo>_<funcionalidad>_<nombreObjeto>
donde,
<siglasProyecto/aplicativo> indica las siglas del proyecto al que
pertenece el servicio
<funcionalidad> indica la funcionalidad que el servicio esta
ejecutando.
Página 77/103
SOAr
v1.1
10 Metodología
Esta sección presenta la metodología de SOAr, el cual documenta la
metodología de implementación de SOAr que se creó basado en la experiencia
lograda en el proyecto de sustitución del Facturador, Recaudador y Gestor de
Crédito de CANTV.
Aún cuando la experiencia que fundamenta esta metodología está en el

dominio de las Telecomunicaciones (Proyecto de CANTV), la aproximación es
completamente agnóstica de industria de manera de que sea 100% útil y
válida para otras industrias como Banca, Finanzas, Petróleos, Manufactura,
Farmacéuticos, etc.
Actualmente dicha metodología documenta su versión 2, la cual incorpora las

lecciones aprendidas de la primera corrida para la creación de más de 200
servicios de negocio, en forma de una actualización metodológica y de
instrumentos.
10.1 Premisas
Página 78/103
SOAr
v1.1
● Es compatible con proyectos de sustitución y migración de

aplicaciones.
● Se compone de un proceso, artefactos de especificación, criterios de
decisión, algoritmos de procesamiento y listas de validación de QA.4
● Considera enfoque pragmático
● Alineado con:
● SAP ASAP
● Fases de Business Blue Print y Gap Analysis.
● RUP y UP
● TMForum
● Basado en Contratos
● Ciclo de cuatro (4) cuadrantes
● Artefactos de NGOSS (TAM, SID, OSS/J)
● Programa Prosspero de TMForum.
10.2 Comparación con otros modelos

Los fabricantes de tecnología (ej. IBM, Sun, SAP, Oracle, etc.) y
organizaciones internacionales de estandarización (ej. Open Group, SOA
Institute, etc.) han desarrollado sus modelos de “Ciclo de vida de SOA”,
asignándole de manera general el concepto presentado aquí como SOAr a las
siglas SOA.
Todos y cada uno de ellos presentan con nombres diferentes lo que de

manera estándar la evolución de la Ingeniería de Software propone como
metodologías de desarrollo de Tecnologías de Información en el siglo XXI.
A continuación se presentan algunos de ellos y su correspondiente mapeo con

el modelo de SOAr, el cual tiende a ser más completo y extensivo.
Página 79/103
SOAr
v1.1
10.2.1IBM
10.2.2RUP
10.2.3Sun Microsystems
Página 80/103
SOAr
v1.1
10.2.4SOA Institute
Página 81/103
SOAr
v1.1
10.2.5SAP
10.3 Ciclo de vida de un servicio

En la medida que se van atendiendo las necesidades del negocio, la
metodología SOAr genera una evolución en los servicios en forma de ciclo de
vida la cual se muestra a continuación.
Página 82/103
SOAr
v1.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.
Página 83/103
SOAr
v1.1
10.4 Gobernabilidad
La ejecución de un proyecto de SOA / BPM requiere la participación de un
equipo de personas con roles variados, teniendo cada rol funciones y
exigencias de conocimientos y competencias diferentes.
A continuación se presentan los roles y el funciograma recomendado.
10.4.1Roles
A continuación se listan los roles principales que deben ser suplidos por el
equipo; las personas pueden ser las mismas para varios roles siempre que
entiendan las distintas necesidades de cada rol que asumen en cada instante
del tiempo.
● Funcionales
● Representantes del “negocio”; dueños de los procesos.
● Analista, de procesos
● Encargado de entender el proceso del negocio, modelarlo en la
herramienta y proponer oportunidades de eficiencia
● Arquitecto, de servicios
● Encargado de llevar a cabo el análisis de brecha,
refactorización e ingeniería de los servicios.
● Especialista, de conexión
● Encargado de disponibilizar el “canal” de las aplicaciones como
proxies del ESB.
● Probador
● Encargado de ejecutar los protocolos de prueba
● Operador, de plataforma
● Encargado de mantener la plataforma de ESB y BPM
funcionando y disponible.
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.
Página 84/103
SOAr
v1.1
10.5 Proceso
Página 85/103
SOAr
v1.1
Plan
● Planificación de tiempo y
recursos
● Personas claves en múltiples
lugares al mismo tiempo!
Página 86/103
SOAr
v1.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
Página 87/103
SOAr
v1.1
10.5.1Documentación del requerimiento

En 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álisis
Para 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.
Página 88/103
SOAr
v1.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.
Página 89/103
SOAr
v1.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 pruebas
El proceso de construcción y ejecución de pruebas es específico de la
plataforma y en la medida que se realice con herramientas de mayor nivel,
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”
Página 90/103
SOAr
v1.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.
Página 91/103
SOAr
v1.1
11 Glosario
11.1 Proceso
Serie 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.2 Procedimiento
Conjunto 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.3 Diagrama de flujo

Representación gráfica de un proceso o de un procedimiento que permite la
observación sistemática de su ejecución, mostrando la dinámica y lógica de la
secuencia del trabajo.
11.4 Intercambios 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.
Página 92/103
SOAr
v1.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.
Página 93/103
SOAr
v1.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.5 Webservices
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 mensaje
3. 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.
Página 94/103
SOAr
v1.1
12 GNU Free Documentation License

A continuación se presenta la licencia de Documentación Libre según la FSF la
cual está publicada en http://www.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 USA
Everyone is permitted to copy and distribute verbatim copies
of 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
Página 95/103
SOAr
v1.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
Página 96/103
SOAr
v1.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.
Página 97/103
SOAr
v1.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
Página 98/103
SOAr
v1.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
Página 99/103
SOAr
v1.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.
Página 100/103
SOAr
v1.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
Página 101/103
SOAr
v1.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.
Página 102/103
SOAr
v1.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.
Página 103/103

Curso SOA Español

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Curso SOA Español

Transféré par

Droits d'auteur :

Formats disponibles

SOAr

Un enfoque pragmático de Arquitectura Orientada a

Copyright (c) 2007-2008 Cesar Obach-Renner

Permission is granted to copy, distribute and/or modify this

A lo largo de este documento, el lector tendrá la oportunidad de entender el

A finales del año 2005 luego de la fase de concepción de SOAr y construcción

Para enfrentar dicho proyecto se realizó una importante búsqueda de

Dicha metodología es parte del framework de integración SOAr

Adicionalmente a la la conceptualización y metodología, el framework SOAr

3.1 Sobre Gurulab

Adicionalmente a las innovaciones que ha incursionado en los últimos 10

El laboratorio opera de manera distribuida a nivel mundial y sus miembros se

Entre sus iniciativas, además del framework SOAr, se encuentra un ESB

Gurulab, adicionalmente a sus procesos de investigación y desarrollo, provee

3.2 ¿Quién debe leer este libro?

Si bien este libro está orientado a Gerentes de Sistemas, Arquitectos de

El propósito es transmitir claramente el concepto de SOAr, cuáles son sus

3.3 Sitio web de apoyo e información de contacto

El URL oficial del Framework de SOAr es http://www.gurulab.org/ y en dicho

El Framework de SOAr es un conjunto de recursos disponibles a la comunidad

● El libro "SOAr - El concepto" (Cookbook)

3.4 Sobre los términos en Inglés.

Seguramente a medida que estos conceptos vayan adoptándose de manera

3.6 Dedicatoria y Agradecimientos

Un especial agradecimiento al equipo de PESSO y en general a los equipos

La reducción de costos siempre ha sido un elemento clásico en la optimización

Como respuesta a esa necesidad, Gurulab.org ha desarrollado un modelo

Para conocer cuan cercano a ese “ideal” se encuentran las empresas, el

Tradicionalmente los procesos de una empresa se encuentran “programados”

más básica de forma manual. Esto último es lo que el modelo de madurez de

En dicho nivel 1 de NGITP vemos un conjunto de “n” aplicaciones (App 1, App

p1 App 1 p2 App 2 p3 … … pj App n

NGITP Maturity Model

Se presenta generalmente la disyuntiva respecto a si una empresa debe

Por ejemplo, un fabricante de aplicaciones empresariales alemán con sede en

Ahora bien, si imaginamos una plataforma cuyo costo de configuración sea

Desarrollando solo algunos de los puntos indicados, respecto a “seguridad”, el

Esto implica un problema, ya que al tener aplicativos de distintos fabricantes,

En el caso de la “sincronización”, sin un elemento superior que controle los

p1 App 1 p2 App 2 p3 … … pj App n

NGITP Maturity Model

Solo queda válido como respuesta a nuestro planteamiento el escenario en el

Esta conclusión a la que estamos llegando es clara para muchos Arquitectos

La casa de Walldorf lo acepta también no solo sacando al mercado

Ahora bien, ¿cuál es el estado de nuestra solución? Hemos dibujado hasta

Para lograr esa característica “súper configurable” basta con proveerle al

1) un mecanismo de desacoplamiento de las funciones que los procesos

De esta manera, el desarrollo de las reglas del negocio basadas en procesos

Esto es logrado a través de la exposición de servicios que muestran una vista

p1 App 1 p2 App 2 p3 … … pj App n

NGITP Maturity Model

2) un gestor de procesos con una interfaz de definición simple y poderosa,

Basado en los servicios corporativos, el gestor de procesos permite modelar

En Figura 4 se muestra el nivel 4 del modelo de madurez del NGITP, el cual

p1 p2 p3 … pj Process Manager 4 - BPM

App 1 App 2 … App n

NGITP Maturity Model

En dicha Figura note cómo la interfaz gráfica ya no corresponde a interfaces

3) Una interfaz de usuario para ejecución de procesos que se construya

Como elemento final del modelo de madurez, tal como se muestra en la

p1 p2 p3 … pj Process Manager 4 - BPM

App 1 App 2 … App n

NGITP Maturity Model