Arquitectura orientada a servicios.

Marianela Diaz Rosales.

Resumen.
Este trabajo aborda un estudio de las distintas arquitecturas de
integracin existente. Se pretende profundizar en el anlisis y
estudio de la arquitectura orientada a servicios (Service
Oriented Architecture SOA por sus siglas en ingls) como
estrategia ms eficiente para la lograr una solucin de
integracin exponiendo sus caractersticas fundamentales. Se
realiza el estudio de la categora de software ESB (Enterprise
Service Buses) para la implementacin de la arquitectura
orientada a servicios y su comparacin con la arquitectura
EAI (Enterprise Application Integration por sus siglas en
ingls) a travs de los EAI brokers. Se analiza la relacin
existente entre BPM (Business Process Management por sus
siglas en ingls) y SOA. Y se caracterizan los estndares
BPEL para la orquestacin de servicios y JBI como propuesta
para la estandarizacin de los componentes en un ESB.

I. ARQUITECTURA ACCIDENTAL. EAI BROKERS

La integracin entre aplicaciones inicialmente comenz con la
instalacin de enlaces punto a punto entre las aplicaciones que
queran comunicarse, fenmeno denominado arquitectura
accidental (accidental architecture). Este diseo generaba una
arquitectura rgida donde para establecer los enlaces se hacia
necesario hacer cambios en la implementacin en las
aplicaciones, lo cual hacia ms complicado su mantenimiento.
Por otra parte la gestin y monitorizacin de los enlaces se
hacia imposible pues no exista un repositorio comn desde
donde se pudieran controlar, solo cada aplicacin conoca sus
enlaces. Este diseo no fomentaba la reutilizacin y su rigidez
lo hacia obsoleto para implantar nuevas integraciones. [1]
Figura 1. Arquitectura Accidental [2]
A principios de los 90 surgi la tecnologa EAI bajo la cual
se agrupaban un conjunto de software. EAI ofreca una
solucin para la integracin de aplicaciones y se implementa a
travs de dos topologas hub-and-spoke y bus.
Los EAI brokers son una categora de software basada en
la arquitectura EAI y usan una topologia hub-and-spoke
donde las aplicaciones se comunican con un sistema central
que es el que media en la comunicacin de cada aplicacin
con las dems.

La arquitectura hub-and-spoke usa un broker

centralizado(hub) y un conjunto de adaptadores (Spoke)
productos de software encargados de comunicar las
aplicaciones con el Hub. Estos adaptadores transforman la
informacin que proviene de las aplicaciones en un formato
que el Hub pueda entender y viceversa. El Hub por otra parte
se encarga de recibir los mensajes y aplicarles los cambios
necesarios para transformarlo en el formato de destino y enva
el mensaje al adaptador de la aplicacin destino el cual se
encarga de la comunicacin y el envio del mensaje al punto
final. Este diseo centralizado en un nico Hub facilita las

posibilidades de administracin y manejo de las conexiones
entre aplicaciones, sin embargo genera problemas de
escalabilidad haciendo que dependa del hardware la
capacidad del sistema de crecer en un futuro. [3]
De forma general los EAI brokers ofrecen conectividad con
distintas aplicaciones y tecnologas a travs de adaptadores y
motores de transformacin de mensajes para adecuar el
formato del mensaje a la aplicacin destino.
Figura 2. Arquitectura EAI brokers [2]
La arquitectura Bus es otra solucin para implementar un
EAI. Esta topologa funciona acoplada a un centro de
mensajes para la propagacin de los mensajes. Las
aplicaciones que se suscriben al bus tienen adaptadores para el
envio de mensajes y para la transformacin de los entrantes en
un formato comprensible por la aplicacin
El envio de los mensajes se hace a travs del bus de
mensajes. [3] Aunque mayormente basada en estndares las
arquitecturas EAI utilizan formatos propietarios para su
funcionamiento lo cual eleva sus costes de implantacin.
II. ARQUITECTURA ORIENTADA A SERVICIOS (SOA)
La arquitectura orientada a servicios se refiere a la
capacidad de implementar una arquitectura que est soportada
por la creacin de servicios que satisfagan los requerimientos
del usuario.
SOA es una plataforma que permite construir sistemas
distribuidos que ofrezcan funcionalidades en la forma de
servicios orientados al usuario final de la aplicacin. Puede
estar basado en Web services para implementar las
caractersticas fundamentales de la arquitectura pero puede
construirse a travs de otras tecnologas.
Sin embargo la implementacin ms recomendada es a
CCIA2008 2
travs de Web services. [4]
Un servicio es un pedazo de funcionalidad que ejecuta de
manera aislada e independiente una funcionalidad especfica
dentro del proceso de negocio. Es invocado a travs de una
interfaz y su diseo debe cumplir con el principio de
reusabilidad. [4]
Un servicio es un componente de software y desde el punto
de vista externo es una funcin que se ejecuta y ofrece un
resultado. Sin embargo internamente la implementacin de un
servicio puede contener la ejecucin de varios pasos en
diferentes aplicaciones que tributan al proceso de negocio y
que coordinados dan respuesta al servicio en si. [4]
Se pueden establecer relaciones entre los servicios con el
objetivo de que la ejecucin conjunta de ellos cumpla con una
funcionalidad en el proceso de negocio. La relacin que se
establece entre dos servicios debe ser dbilmente acoplada.
Esto significa que los servicios se comunican a travs de sus
interfaces y no tienen que tener conocimiento de los detalles
de implementacin de su contraparte, como por ejemplo:
lenguaje de programacin o plataforma en la que esta
desplegando el servicio. La comunicacin se establece a
travs de mensajes los cuales estn definidos por un estndar.
Esto permite que los servicios tengan notable independencia y
que puedan hacer cambios en su implementacin llegando a
cambios tan radicales como migracin de la plataforma en que
se implementan por ejemplo de C# a J2EE sin que esto afecte
sus relaciones con el resto de los servicios. [4]
Por tanto los servicios en una arquitectura SOA son
independientes y para su ejecucin no deben depender del
estado de otro servicio para ejecutarse. Por supuesto las
aplicaciones requieren guardar el estado de los objetos pero
esto debe hacerse sin involucrar al servicio. El siguiente
bloque de texto es un ejemplo de una mala forma de definir
una comunicacin entre dos servicios: [4]
Solicitante: Cual es el balance de la cuenta de Bruce?
Proveedor: $x
Solicitante: Y cual es su lmite de crdito?
Proveedor: $y
El servicio proveedor debe recordar el nombre de Bruce
para responder la segunda pregunta, lo cual introduce un
elemento de complejidad en la implementacin del servicio y
lo obliga a depender del otro servicio. La conversacin debe
ser redefinida de la forma siguiente: [4]
Solicitante: Cual es el balance de la cuenta de Bruce?
Proveedor: $x
Solicitante: Y cual es lmite de crdito de la cuenta de
Bruce?
Proveedor: $y
La granularidad de los servicios constituye otro aspecto a la
hora de disear un servicio. Por granularidad se entiende el
nivel de desmembramiento en funcionalidades de un caso de
uso o proceso de negocio que expone un servicio. [5] El uso
 CCIA2008 3

de interfaces de granularidad gruesa (coarse-grained) para

disear servicios que sern usados en un marco fuera de
nuestro entorno empresarial es recomendable como lo es el
uso de interfaces de granularidad fina (fine-grained) para el
diseo de servicios que sern usados dentro de la empresa [4];
por ejemplo un servicio GestionarOrden contendra toda la
informacin del negocio necesaria para gestionar una orden.
Un diseo de granularidad fina debera disear los servicios
de CrearOrden, DefinirTipodeOrden e incluirOrdenenLista.
Un diseo de granularidad fina como estrategia para
publicar servicios externos da una mayor flexibilidad a los
usuarios para poder utilizar las funcionalidades sin embargo
los entes externos deben conocer la lgica de negocio interna
para poder utilizar los servicios de forma correcta, elemento
que aade complejidad al proceso y expone los procesos de
negocio de la empresa. Un diseo de granularidad gruesa
permite que las aplicaciones externas puedan utilizar los
servicios de manera consistente. SOA no requiere el uso de
interfaces de granularidad gruesa pero se recomienda su uso
para la integracin externa con otras aplicaciones. [4]
La esencia de SOA es la creacin de servicios. SOA define
un conjunto de lineamientos que deben cumplir estos servicios
para que se enfoquen hacia la interoperabilidad y su gran
popularidad consiste en su implementacin a travs de web
services los cuales al estar basados en estndares sobre la Web
han hecho extensivo su uso en un entorno donde cada vez las
empresas hacen uso de la web para la gestin empresarial.
De forma general las caractersticas principales de la una
arquitectura SOA son [2]:
7. Los servicios pueden reorganizarse en una
orquestacin de servicios para representar
funcionalidades ms complejas o integraciones de los
procesos de negocio.
El Bus de Servicios Empresariales (Enterprise Service
Buses) constituye una solucin para gestionar e integrar
servicios. En el caso de que nuestra arquitectura requiera la
creacin de gran cantidad de servicios, los ESB nos ofrecen la
posibilidad de tener una visin global de todo el conjunto de
servicios que existen as como las posibilidades de
reutilizacin e integracin de los mismos.
III. BUS DE SERVICIOS EMPRESARIALES (ESB)
La arquitectura orientada a servicios constituye un nuevo
paradigma que fija nuevos lineamientos en el camino de la
integracin de aplicaciones. Para asegurar el cumplimiento de
los principios que fija SOA se hace necesario implantar una
tecnologa que cumpla con estos lineamientos. ESB es una
tecnologa que ha surgido con el objetivo de llevar adelante la
implantacin de este tipo de arquitectura.
Los ESB constituyen un elemento de integracin que
combina mensajera, servicios web, transformacin de datos,
enrutamiento, polticas de seguridad y que permite la
interaccin entre diversas aplicaciones o sistemas de una
Arquitectura Empresarial. [6]

1. Los servicios deben estar definidos a travs de

protocolos y lenguajes estndar de forma que su uso
sea independiente de la plataforma.

2. Los servicios deben estar accesibles y publicados en

un repositorio de servicios con el objetivo de poder
monitorizar el estado de los mismos.

3. Los servicios definidos deben cumplir el requisito de

reutilizacin. Se debe fomentar el uso de estndares
para reutilizar servicios ya existentes con el objetivo
de aumentar las posibilidades de integracin con
sistemas legados.

4. Los servicios encapsulan los detalles de

implementacin y exponen sus funcionalidades a
travs de una interfaz basada en estndares.

5. Un servicio debe ser independiente y no debe Figura 3. Arquitectura ESB [7]

depender del estado de otro servicio y por tanto su
relacin con el resto de los servicios es dbilmente
acoplada.
6. Un servicio debe tener un nivel de granularidad
(grado de complejidad en el funcionamiento)
adecuado al mbito donde se expondr el mismo.
Los ESB constituyen un bus de comunicacin o mensajera
entre servicios y ofrecen una solucin para los entornos
empresariales dbilmente acoplados o con baja integracin
tecnolgica entre sus aplicaciones. Permiten la definicin de
servicios independientes de la plataforma en que estn
implementados, la creacin de una interfaz estndar para la

comunicacin de un servicio con el resto y la mediacin entre
esta interfaz y el proveedor real del servicio. Consta de cuatro
aspectos: MOM (Message Oriented Middleware por sus siglas
en ingls), Servicios Web (Web Services por sus siglas en
ingls), enrutamiento inteligente basado en contenido y
transformacin de datos XML(eXtensible Markup Language
por sus siglas en ingls).[8]
La tecnologa MOM es una parte clave de la arquitectura
ESB pues provee el soporte que el ESB necesita para enrutar
los mensajes dentro y fuera del entorno empresarial. MOM es
una tecnologa que consiste en la transmisin de datos entre
aplicaciones usando un canal de comunicacin que lleva
unidades de informacin autocontenidas (mensajes). En un
ambiente de comunicacin basado en la tecnologa MOM los
mensajes pueden ser enviados y recibidos asincrnicamente o
sincrnicamente. Esta tecnologa proporciona un mtodo
fiable de almacenamiento y reenvo de manera que se
garantiza la calidad de la entrega en caso de fallos en la red.
[9]
El enrutamiento inteligente basado en contenido es una
funcin que cumple el ESB para hacer llegar el mensaje
enviado hacia su destino. En un ESB los datos son enviados
entre los puntos finales (endpoints) a travs del uso de
mensajes. Como endpoints se puede entender cualquier
componente de software que est en el lado de una
comunicacin ya sea un servicio o una aplicacin. Existen
dos tipos de enrutamiento. En el primer caso el mensaje con
una peticin de servicio llega al Bus y este lo hace llegar a su
destino. En el segundo caso el mensaje que llega al Bus puede
poseer informacin en su contenido que haga que el Bus deba
intervenir para ejecutar reglas de negocio o informacin
acerca del itinerario que debe seguir el mensaje a travs del
ESB para llegar a su destino. [7]
Los servicios Web constituyen un producto de software que
rene un conjunto de protocolos y estndares que se utilizan
para lograr la comunicacin entre aplicaciones sobre una red
con independencia de la plataforma. Los estndares utilizados
son los siguientes: XML, SOAP (Simple Object Access
Protocol por sus siglas en ingls), WSDL (Web Services
Description Languages por sus siglas en ingls), UDDI
(Universal Description, Discovery and Integration por sus
siglas en ingls). Ms adelante se explicar el funcionamiento
y el papel que cada estndar juega en la tecnologa. Debido a
que los estndares utilizados son abiertos, o sea Open Source,
las diferentes plataformas pueden acceder a sus
especificaciones de forma gratuita y desarrollar productos que
se basen en ellos. Varias compaas han desarrollado
componentes de software basados en estos estndares como
por ejemplo Microsoft Corp. con su .Net y Sun Microsystem
con J2EE. Este hecho fomenta la interoperabilidad, pues las
aplicaciones comienzan a incorporar un lenguaje comn para
comunicarse.
CCIA2008 4
La transformacin XML es una funcionalidad del ESB que
incorpora motores de transformacin y parseadores de
mensajes que permiten la transformacin de los mensajes. En
muchas ocasiones el formato de salida de un servicio no
corresponde con el formato de entrada del siguiente servicio y
se hace necesaria la incorporacin de un mecanismo que
transforme el mensaje de acuerdo al formato deseado. De
forma general esta transformacin se hace a travs de un
XSLT (Extensible Stylesheet Language Transformations por
sus siglas en ingls) que se le aplica al mensaje para obtener el
formato de salida deseado. [10]. El ESB contiene servicios de
transformacin para ejecutar estas funciones.
El ESB permite la definicin de servicios independientes de
la plataforma. Se encarga de definir una interfaz para el
servicio y de la comunicacin de esta interfaz con la
plataforma de implementacin del servicio. Incorpora
capacidades de registro de servicios con el objetivo de
controlar los servicios disponibles lo cual fomenta la
reutilizacin. Posee alta extensibilidad, o sea puede soportar
servicios implementados en diferentes mbitos como J2EE,
C++ y .Net. Permite la definicin de coreografas de servicios
con los disponibles en el bus con el objetivo de dar repuesta a
funcionalidades complejas del proceso de negocio. Posee
mecanismos de monitorizacin de la calidad y disponibilidad
de los servicios registrados, as como integridad transaccional
cuando una funcionalidad involucra la ejecucin de varios
servicios. [7]
Muchos ESB se basan en un patrn de intercambio de
mensajes (MEP por sus siglas en ingls) sncrono, el usuario
lanza una peticin y espera por una respuesta del cliente,
como es el caso de SOAP sobre HTTP, sin embargo para la
integracin de aplicaciones empresariales con un determinado
nivel de complejidad en sus procesos de negocio en muchos
casos se hace necesario esperar tiempos prolongados por la
respuesta del servicio lo que introduce la comunicacin
asncrona, MEP asncrono, este patrn asncrono se puede
implementar a travs de SOA con JMS(Java Message
System por sus siglas en ingls).[7]
El mayor beneficio que aporta la implantacin de un ESB
es la racionalizacin que hace de los activos tecnolgicos en la
empresa. Luego de resolver los problemas de compatibilidad
entre el ESB y el sistema que lo proporciona, los servicios son
expuestos una vez y pueden ser reutilizados todas las veces
necesarias para satisfacer las funcionalidades de los procesos
de negocio.
IV. TOPOLOGAS ESB
El uso de los ESB para la implementacin de una
arquitectura SOA ofrece dos posibilidades de diseo desde el
punto de vista de la distribucin de los nodos [11]:

1. ESB unificado
2. ESB distribuido
El ESB unificado es la implementacin de diseo que se
muestra en la figura 3. En esta implementacin todas las reas
de negocio registran servicios en un ESB nico. En este tipo
de topologa los diferentes departamentos o reas de negocio
se integran de forma central, elemento que les quita un poco
de flexibilidad; sin embargo con este tipo de diseo se lleva
un control de todos los servicios existentes lo cual permite
aplicar las estrategias de reutilizacin. Tambin la
monitorizacin y administracin del servidor se simplifica
pues todos los servicios estn registrados en un nico punto.
En el caso de la topologa de ESB distribuido este diseo le
ofrece ms flexibilidad a los departamentos para que
orquesten sus propios servicios. Se debe tener en cuenta que
en este tipo de diseo contaremos con un conjunto de ESB
funcionando al unsono y registrando servicios. Se hace
necesario contar con un mecanismo que muestre los servicios
actualmente activos con el objetivo de favorecer la
reutilizacin y no caer en redundancias. Si en un servicio se
produce algn cambio este debe ser notificado a todos los
ESB que hagan uso de l. Los mtodos de comunicacin entre
los ESB deben garantizar la fiabilidad de los datos. [11,12]
Este diseo distribuido se utiliza de acuerdo a la
complejidad existente en las reas de negocio. Si los procesos
que se deben automatizar se bifurcan en complejos procesos
en cada departamento se debe pensar en esta solucin
teniendo en cuenta los elementos antes mencionados. La
solucin de un ESB unificado se puede utilizar cuando la
complejidad es menor y se debe tener en cuenta que con esta
solucin la monitorizacin se simplifica y se tiene ms control
sobre la reutilizacin de los servicios; sin embargo con el
diseo distribuido aumentan los aspectos a controlar pero se
explotan todas las posibilidades de este tipo de arquitectura .
[11,12]
V. COMPARACIN ENTRE ESB Y EAI BROKERS
Los ESB, como implementacin mas extensiva de SOA y
los EAI brokers, como categora de software que implementa
la arquitectura EAI , surgieron con el objetivo de fomentar la
integracin y la interoperabilidad entre aplicaciones. La
diferencia fundamental es acerca de los costes de implantacin
debido a que la mayora de las soluciones EAI usan formatos
propietarios para su funcionamiento interno a diferencia del
ESB el cual tiene implementaciones basadas en estndares
abiertos. Esto permite que los costes de implantacin de un
ESB sean ms bajos que los EAI. [3,13]
Las topologas de los brokers EAI tienen una arquitectura
centralizada, los ESB aunque pueden tener una topologa
unificada pueden ser implementados con una arquitectura
distribuida. Por tanto la arquitectura ESB tiene una mayor
CCIA2008 5
escalabilidad que un broker EAI. Esto permite que los ESB
puedan ser usados para modelar aplicaciones en un entorno
distribuido. [3,13]
La arquitectura de un broker EAI es anterior al surgimiento
de SOA por tanto debe adaptarse para ofrecer una
implementacin orientada a servicios a diferencia de los ESB
que son desde su surgimiento orientados a servicios y por
tanto permiten explotar todos los beneficios de esta
tecnologa. [3,13]
Por tanto se considera que para la implementacin de una
arquitectura orientada a servicios un ESB sera la solucin
ms ptima.
VI. IMPLEMENTANDO SOA A TRAVS WEB SERVICES
La solucin de implementar SOA utilizando Web services
es una de las estrategias ms recomendada. El uso de Web
Services tiene como funcin fundamental la de lograr el
intercambio de informacin entre aplicaciones con
independencia de la plataforma y basado en estndares
abiertos (por estndares abiertos se entiende la definicin de
estndares que son publicados bajo licencias gratuitas). Con el
uso de los servicios web las aplicaciones pueden compartir
informacin con otras a travs de Internet de forma que el
servicio se publica una vez y este puede ser accedido tantas
veces sea necesario lo cual fomenta la integracin.
"Un Web Service es un componente de software que se
comunica con otras aplicaciones codificando los mensaje en
XML y enviando estos mensaje a travs de protocolos
estndares de Internet tales como el Hypertext Transfer
Protocol (HTTP) Intuitivamente un Web Service es similar a
un sitio web que no cuenta con un interfaz de usuario y que da
servicio a las aplicaciones en vez de a las personas. Un Web
Service, en vez de obtener solicitudes desde el navegador y
retornar paginas web como respuesta, lo que hace es recibir
solicitudes a travs de un mensaje formateado en XML desde
una aplicacin, realiza una tarea y devuelve un mensaje de
respuesta tambin formateado en XML.[14]
Funcionamiento
El objetivo del uso de los web services es exponer una
funcionalidad a travs de una red con el objetivo de que otras
aplicaciones hagan uso del servicio que se expone. Para que
las aplicaciones puedan conocer los servicios existentes estos
deben publicarse en algn registro desde el cual puedan ser
localizados por las aplicaciones. Este proceso de
descubrimiento se hace a travs del estndar UDDI. Luego de
que la aplicacin ha localizado el servicio debe obtener una
descripcin del mismo para poder utilizarlo. La descripcin se
especifica a travs del estndar WSDL el cual proporciona
informacin acerca de la interfaz del servicio. Una vez que el
cliente se ha informado acerca de la descripcin se dispone a

utilizar el servicio y para esto el cliente y el servidor deben
definir un formato de mensaje estndar para establecer la
comunicacin: SOAP(Simple Object Access Protocol) . Este
protocolo define el formato del mensaje y XML es el estndar
escogido para codificar los mensajes. De esta forma para la
comunicacin entre la aplicacin cliente y el servidor ambos
intercambian mensajes XML con un formato de mensaje
especificado por SOAP. Una vez que se han especificado los
mensajes estos deben viajar por algn protocolo de transporte
como por ejemplo http o smtp para llegar a su destino. De esta
forma se puede apreciar que los webservices son una ptima
solucin para la comunicacin entre aplicaciones pues hacen
uso de estndares para su funcionamiento. [15]
VII. BPM (BUSINESS PROCESS MANAGEMENT)
La necesidad de garantizar una interaccin adecuada y
eficiente (en tiempo de diseo) entre los servicios que se
exponen en un ESB introduce el tema de BPM. La adopcin
de una herramienta BPM permite que los analistas de negocio
participen activamente en el diseo de los procesos que luego
sern automatizados a travs de una arquitectura SOA. En la
etapa de diseo los analistas pueden monitorizar y optimizar el
proceso de forma que cuando estos procesos se conviertan en
colaboraciones de servicios representen eficientemente la
funcionalidad que se requiere de ellos. Los productos BPM y
sus conceptos asociados pueden proporcionar la tecnologa
necesaria para que los usuarios de negocio puedan definir,
simular y monitorizar procesos, reduciendo as los problemas
de comunicacin entre las reas de negocio y el rea de
tecnologa () ser el rea de tecnologa quien se encargar casos requiere de un gasto de tiempo en un entorno dinmico
de conectar las actividades del proceso con sistemas y roles
concretos para su automatizacin. Es en esta conexin donde
las arquitecturas orientadas a servicios pueden ser de gran
ayuda, racionalizando los sistemas (y los servicios asociados)
que tendrn que ser utilizados por los procesos, permitiendo
la automatizacin gil de los procesos definidos por las reas
de negocio.[2]
Los productos BPM son una categora de software que
realiza un nfasis en la definicin y diagramacin de los
procesos de negocio con el objetivo de que el desarrollo del
software est orientado hacia la optimizacin de los procesos
de negocio. Estos productos incorporan el uso de estndares lo
cual hace posible la interoperabilidad. Con el uso de
herramientas generadoras de cdigo apoyadas en el diseo
permiten reducir el tiempo de codificacin del software e
incrementan el anlisis, evaluacin y monitorizacin desde el
punto de vista del negocio. [2]
Los productos BPM ofrecen diferentes funcionalidades:
1. Diagramacin de los procesos de negocio,
acompaados con su documentacin. Este diseo no
permite directamente su automatizacin.
2. Simulacin y anlisis de procesos permitiendo definir
para cada actividad aspectos relacionados con el
rendimiento. La informacin para la simulacin debe
CCIA2008 6
ser proporcionada por el usuario.
3. Definicin de los procesos automatizables, con esta
funcionalidad se establecen las conexiones entre las
reas de negocio, los sistemas involucrados y los
actores.
4. Ejecucin de procesos; con esta funcionalidad se
puede llevar a cabo la comunicacin real con los
sistemas que representan los procesos de negocio.
5. Monitorizacin desde el punto de vista del negocio
(Business Activity Monitoring BAM).
Los productos disponibles en el mercado se pueden dividir
en los que proporcionan solo la diagramacin de los procesos
a nivel de negocio; los que permiten la ejecucin y
monitorizacin de los procesos y aquellos que cumplen ambas
funciones. [2]
En general los productos BPM han surgido para centrar la
atencin del desarrollo de software en la gestin de los
procesos de negocio, dndole a esta rea el papel rector de la
elaboracin del software.
Sinergia entre BPM y SOA
Las reas de negocio con el objetivo de automatizar los
procesos deben apoyarse en el rea de TI(Tecnologas de la
Informacin). En muchos casos la solucin es la compra de
algn producto de software, la adaptacin de alguna
herramienta open source o el desarrollo de un software que
satisfaga los objetivos a la medida. Esto en la mayora de los
donde nuevos requerimientos y reajustes pueden surgir
rpidamente. Con el objetivo de adaptarse ofreciendo una
solucin viable y que consuma el menor tiempo posible ha
surgido la unin de estas dos tecnologas BPM y SOA.
Con el empleo de BPM podemos representar nuestros
procesos de negocio. Esta representacin permite la
optimizacin de los procesos y brinda una visibilidad general
del funcionamiento de las reas. Cada proceso de negocio
representado se divide en pequeas partes o actividades
independientes entre si. La implementacin de estas
actividades como servicios independientes usando SOA nos
permite implementar esta sinergia. La adopcin de SOA nos
facilita la comunicacin con sistemas subyacentes. De esta
forma las reas de negocio perfeccionan los procesos a travs
de BPM e implementan las soluciones tecnolgicas a travs de
la creacin de servicios los cuales al contar con una nica
interfaz pueden irse mejorando continuamente. Las
capacidades para la integracin entre aplicaciones y la
reutilizacin que proporciona SOA nos permiten acortar el
tiempo de desarrollo de soluciones tecnolgicas que a la larga
redundarn en mayor eficiencia en la produccin y
mantenimiento de software. [16]

VIII. BPEL. UN LENGUAJE DE ORQUESTACIN
Lenguaje de Ejecucin de Procesos de Negocio (Business
Process Execution Language BPEL por sus siglas en ingls)
es un lenguaje creado con el objetivo de representar los
servicios web con una lgica de negocio que responda a los
procesos que se desean automatizar. [17]
Es un lenguaje creado por BEA Systems, IBM y Microsoft y
actualmente se encuentra en revisin bajo OASIS
(Organization for the Advancement of Structured Information
Standards por sus siglas en ingls) .Se codifica en XML y se
desarroll a partir de WSDL y XLANG, dos estndar que
estn basados en la descripcin de servicios web.
Es un lenguaje de orquestacin a travs del cual un analista de
negocio puede representar el comportamiento de un flujo de
negocio determinado a travs de elementos que se
relacionan. Los elementos a travs de los cuales se ejecuta el
flujo son los servicios web y la forma en que estn
organizados es la lgica BPEL. En esencia es un documento
XML donde se representa la lgica de un proceso de negocio
a travs de la organizacin de servicios web.
Para la ejecucin de un proceso BPEL este requiere de un
motor BPEL, el cual le proporcione un ptimo control sobre la
ejecucin del proceso. Usualmente los motores proveen el
control sobre las instancias que se estn ejecutando y sobre su
finalizacin. Pueden controlar procesos asncronos o sea que
requieran largos periodos de espera permitiendo su
monitorizacin. De esta forma usando un motor BPEL se
pueden desplegar todos los procesos de forma centralizada
facilitando su administracin. [18]
Algunos de los motores mas populares estn basados en Java
EE, entre los que se incluyen Oracle BPEL Process Manager,
IBM WebSphere Business Integration Server Foundation,
BEA WebLogic Integration y AquaLogic. Tambin hay al
menos cuatro motores de cdigo abierto disponibles:
ActiveBPEL Engine, FiveSight PXE, Bexee y Apache Agila.
[18]
Uno de los usos de BPEL es como lenguaje de exportacin.
En la actualidad existen productos BPM que permiten la
definicin de procesos de negocio y su posterior exportacin
al correspondiente fichero BPEL. Este fichero puede ser
interpretado por productos BPM encargados de ejecucin y
monitorizacin de procesos convirtindose en un lenguaje
portable que permite la comunicacin entre las herramientas
BPM y establece un estndar para la definicin de procesos
ejecutables.[2]
Los ESB tambin hacen uso de este estndar. Los ficheros
BPEL pueden ser generados e interpretados por un ESB a
travs de un motor BPEL incluido en el bus. Esto aumenta las
posibilidades de integracin pues permite que se establezcan
relaciones entre los servicios publicados en un ESB de forma
que tributen a la ejecucin de un flujo de negocio. Cada
relacin establecida constituye un proceso BPEL que se
CCIA2008 7
publica en el bus. Bajo un contenedor BPEL se pueden alojar
tantos procesos como se desee. Esto facilita la reutilizacin de
los servicios as como provee un entorno flexible para el
desarrollo de soluciones tecnolgicas. [19]
Entre las principales caractersticas estn [19]:
1. Permite la representacin de procesos ejecutables a
travs de la descripcin del comportamiento de un
elemento en un flujo de negocio especfico.
2. Permite la representacin de procesos abstractos a
travs de la diagramacin de los mensajes
intercambiados entre los diferentes servicios web
envueltos en la ejecucin del proceso de negocio.
3. Con l se pueden representar expresiones y
consultas (queries) en mltiples lenguajes. Soporta
XPath 1.0
4. Incluye elementos de programacin estructurada
como "if-then-elseif-else", "while", "sequence"
(posibilita la ejecucin de comandos en orden) y
"flow" (posibilita la ejecucin de comandos en
paralelo).
5. Se pueden representar instancias de procesos y
mensajes.
6. Permite la recuperacin del estado del proceso frente
a fallos y condiciones excepcionales.
En la figura siguiente se puede apreciar la integracin entre las
tecnologas BPM, BPEL y ESB. Con BPM los analistas de
negocio modelan, documentan y simulan los procesos a
automatizar, con la ayuda del lenguaje de ejecucin de
procesos BPEL exportan estos modelos a un formato
comprensible para que sea interpretado por el orquestador de
servicios de un ESB el cual permite ejecutar colaboraciones de
servicios que le aportan al ESB mayor capacidad funcional
para ejecutar los procesos de negocio.
 CCIA2008 8

de modelo de procesos de negocio. Esta notacin es un

estndar que provee una representacin grfica para
expresar procesos en una empresa. El objetivo es soportar la
gestin de una forma que sea fcilmente entendida, por todos
los usuarios que participan en el proceso. Esta forma
unificada de representar los procesos, facilita que los
comportamientos y decisiones puedan ser expresados de
manera grfica y simple en una organizacin. [20,21].
Otro ejemplo lo encontramos en la herramienta JBPM
(Jboss Business Process Modeling). Es un framework Open
Source de Jboss (licencia LGPL) basado en java el cual acta
como intermediario entre los analistas de negocio y los
desarrolladores ofreciendo un lenguaje comn de definicin
JPDL (JBoss PDL). PDL es un estndar asociado a
WorkFlows. JBPM en su versin 3.0 permite, a travs de la
incorporacin de un pluguin, el diseo de los procesos de
negocio usando el lenguaje BPEL. [22]

IX. JBI. ESTANDARIZACIN EN UN ESB

JBI (Java Business Integration) es un intento de desarrollar
una estandardizacin en los componentes que se despliegan en
un ESB. Actualmente muchos ESB open Source desarrollan
sus propios componentes para realizar las funciones del ESB y
no hay un consenso o estandarizacin de los mismos, el
estndar JBI trata de unificar los componentes de un ESB de
forma que todos los usuarios de un ESB usen una sola
especificacin la cual pueda irse desarrollando
paulatinamente.

Es un estndar basado en java y su funcionamiento est

orientado hacia el desarrollo de una arquitectura orientada a
servicios. Actualmente se finaliz su versin 1.0 a travs de
la especificacin JSR (Java Specification Request) 208 [23] y
en esencia consiste en un contenedor de servicios que
posibilita la integracin a travs de la tecnologa web services
e intercambio de mensajes basado en XML y WSDL 2.0.

JBI define una arquitectura basada en la tecnologa de plug-

in, donde los servicios pueden conectarse al entorno en
tiempo de ejecucin. Provee un conjunto de interfaces bien
definidas para que los servicios puedan interactuar con el
entorno JBI.
Los servicios publican sus interfaces en el entorno JBI, el
cual se encarga de direccionar los mensajes enviados entre los
servicios actuando como ente mediador. [24]

Figura 4. Integracin de BPM, BPEL y SOA [2]

Entre las herramientas BPM que poseen extensiones para

trabajar o exportar a BPEL se encuentra MagicDraw
herramienta Case para la modelacin de procesos de negocio Figura 5. Entorno JBI [24]
en su versin 10.5 el cual permite a los usuarios exportar a un
formato BPEL1.1 a partir de un diagrama BPMN (Business El ncleo de JBI est compuesto principalmente de los
Process Modeling Notation por sus siglas en ingls) notacion siguientes componentes [24]:

1. Componentes del framework: permite el despliegue
de los distintos tipos de componentes dentro de la
plataforma JBI.
2. Normalized Message Router (NMR): permite un
mecanismo estndar de intercambio de mensajes
entre los servicios
3. Framework de administracin: este framework
basado en JMX (Java Management eXtensions)
permite el despliegue, gestin y seguimiento de los
componentes dentro del entorno JBI.
En JBI se definen dos tipos de servicios [24]:
1. Service Engine (SE): Estos componentes son los
responsables de implementar la lgica de negocio y
otros servicios. Los componentes SE pueden ser
servicios que proporcionen desde la transformacin
de datos y la traduccin o algo ms tortuoso como la
representacin de un proceso BPEL o coreografa de
servicios.
2. Binding (BC) de enlace o ligadura: se utilizan
principalmente para prestar servicios de transporte a
diferentes niveles para los servicios desplegados. Los
componentes BC pueden ser de diversos tipos:
Los que permiten la comunicacin remota con sistemas
externos a travs de protocolos estndar de transporte.
Los que permiten la comunicacin entre dos servicios
desplegados en la misma JVM(Java Virtual Machine).
Los que permiten la comunicacin entre los servicios
utilizando el estndar WS-I (Web Services Interoperability).
La clave de este diseo es la separacin existente entre los
Services Engine y los Binding, de manera que la lgica de
negocio de los servicios definida por los service engine no se
encuentra mezclada con los detalles de la infraestructura
requeridos para la invocacin y consumo de los servicios
definidos por los binding. Esto permite obtener una
arquitectura extensible y ms flexible.
En el pasado un desarrollador de aplicaciones para lograr
que su aplicacin funcionara en un entorno de integracin
deba construir las herramientas necesarias para resolver las
incompatibilidades de comunicacin con el resto de las
aplicaciones, as como deba desarrollar componentes para
que la aplicacin soportara los distintos protocolos de
comunicacin. Sin embargo con JBI los desarrolladores
pueden concentrarse en el mejoramiento y desarrollo de
nuevas funcionalidades dejando que los servicios motores de
transformacin (Transformation Service Engines) y los
componentes binding (o de ligadura) provean el soporte
necesario para la integracin de la misma con otras
aplicaciones.[25]
Entre las implementaciones open Source ESB que soportan
el estndar JBI se encuentran:
1. Open ESB
2. Apache ServiceMix
3. FUSE ESB (enterprise ServiceMix)
CCIA2008 9
4. ChainBuilder ESB
5. Mule
6. JBossESB
X. CONCLUSIONES
La arquitectura orientada a servicios es una solucin
ptima para la implementar la integracin debido a que
SOA propone la creacin de servicios que cumplan con
los principios de dbil acoplamiento, independencia y
reusabilidad. Estos principios aseguran flexibilidad en las
soluciones de integracin. La implementacin de SOA a
travs de web services permite aumentar la
interoperabilidad entre las aplicaciones debido a que la
tecnologa web services se encuentra basada en
estndares.
REFERENCES
[1] Hansen, Dain. Blueprint for Successful SOA Integration. [en lnea] 12
de marzo del 2008.[fecha de consulta: 3 Septiembre 2008] Disponible
en:
<http://www.oracle.com/technology/pub/articles/dev2arch/2008/03/blue
print-soa-integration.html >
[2] Lara, Ruben.Gestin de procesos e integracin de sistemas: EAI, BPM,
SOA y ESB.[en lnea] Marzo 2006.[fecha de consulta: 30 Junio 2008]
Disponible en:
<www.afi.es/infoanalistas/comun/mostrarFichero.asp?idContenido=725
191&idSeccion=156467&usuario=TIF >
[3] Goel,Anurag. Enterprise Integration EAI vs. SOA vs. ESB [en
lnea].[fecha de consulta: 18 Julio 2008] Disponible en:
<http://209.85.215.104/search?q=cache:NQXjebbthEoJ:hosteddocs.ittoo
lbox.com/Enterprise%2520Integration%2520-
%2520SOA%2520vs%2520EAI%2520vs%2520ESB.pdf+EAI+hub+an
d+spoke&hl=en&ct=clnk&cd=2&gl=cu>
[4] Colan, Mark. Service-Oriented Architecture expands the vision of Web
services Part 1.[en lnea] 21 Abril 2004.[fecha de consulta: 30 Junio
2008] Disponible en: <www.ibm.com/developerworks/library/ws-
soaintro.html>
[5] Steghuis, Claudia .Service granularity in SOA-projects : a trade-off
analysis.[en lnea]. 2006. [fecha de consulta: 3 Junio 2008] Disponible
en: <http://essay.utwente.nl/57339/ >
[6] Robinson, Rick. Understand Enterprise Service Bus scenarios and
solutions in Service-Oriented Architecture, Part 1. IBM.[en linea] 15 de
Junio del 2004. [ fecha de consulta: 14 Julio 2008] Disponible en:
<http://www.ibm.com/developerworks/webservices/library/ws-
esbscen/>
[7] TIBCO Software.El papel de un bus de servicios empresariales (ESB)
en una SOA.[en lnea] 2006, TIBCO Software Inc. [fecha de consulta:
18 Julio 2008] Disponible en:
<http://www.willydev.net/InsiteCreation/v1.0/WillyCrawler/2008.06.08.
Articulo.El%20papel%20de%20un%20bus%20de%20servicios%20emp
resariales%20(ESB)%20en%20una%20SOA.pdf>
[8] Chappell, Dave. Enterprise Service Bus. [en lnea] Copyright 2004
O'Reilly Media, Inc. June 2004.[fecha de consulta: 14 Julio 2008]
Chapter 1. Introduction to the Enterprise Service Bus. Disponible en:
<http://safari.oreilly.com/0596006756 > ISBN: 0-596-00675-6
[9] Chappell, Dave Enterprise Service Bus.[en lnea] Copyright 2008
Safari Books Online. 31 de Agosto del 2004. [fecha de consulta: 14 Julio
2008] Chapter 5. Message Oriented Middleware (MOM).Disponible
en:<http://soa.sys-con.com/read/46170.htm>
[10] Chappell, Dave. ESB Integration Patterns. SOA World Magazine [en
lnea] 31 de Agosto del 2004. [fecha de consulta: 14 Julio 2008]
Disponible en: <http://soa.sys-con.com/read/46170.htm>
 CCIA2008 10

[11] Louis, Adrien. ESB Topology Alternatives.InfoQ.com[en lnea] 23 de

Mayo del 2008.[fecha de consulta 31 Julio 2008] Disponible en:
<http://www.infoq.com/articles/louis-esb-topologies >
[12] Topologas de ESB. [en lnea] 26 de mayo del 2008.[fecha de consulta:
31 Julio 2008] Disponible en:
<http://www.espaciosoa.net/2008/05/26/topologias-de-esb/>
[13] Bakker, Loek .Goodbye Hub-and-Spoke, Hello ESB? Integration
Architecture With BizTalk 2004. Net Developers Journal.[en lnea]12 de
Septiembre del 2005.[fecha de consulta: 19 Julio 2008] Disponible en:
<http://dotnet.sys-con.com/node/121831?page=1 >
[14] Gonzlez, Benjamn. XML Web Services.[en lnea]24 de junio del 2004.
[fecha de consulta: 18 Julio 2008] Disponible en:
<http://www.desarrolloweb.com/articulos/1545.php>
[15] Lande, Nakul. What is Web Service?. Codeproject.[en lnea] 7 de Marzo
del 2007.[fecha de consulta: 18 Julio 2008] Disponible en:
<http://www.codeproject.com/KB/XML/Defining_Web_Services.aspx >
[16] Prada Rojas,Carlos Hernan. Beneficios de la sinergia de SOA y BMP.
[en lnea] 18 de enero de 2007.[fecha de consulta: 2 Agosto 2008]
Disponible en:
<http://www.ai2madrid.es/index.php?option=com_content&task=blogse
ction&id=5&Itemid=69>
[17] BPEL: estandarizacin de la gestin de procesos. Iworld.[en linea] 30
de Septiembre del 2005.[fecha de consulta: 18 Agosto 2008] Disponible
en:
<http://www.iworld.com.mx/iw_SpecialReport_read.asp?iwid=4135&ba
ck=2&HistoryParam=B>
[18] Juric, Matjaz B. BPEL: Service composition for SOA. JavaWorld.com
[en lnea] 7 de Octubre del 2006.[ fecha de consulta: 6 Septiembre 2008]
Disponible en : <http://www.javaworld.com/javaworld/jw-07-2006/jw-
0710-bpel.html?page=2 >
[19] Barry & Associates, Inc. Business Process Execution Language
(BPEL)[en lnea]. Copyright 2000-2008. [fecha de consulta: 18
Agosto 2008] Disponible en: <http://www.service-
architecture.com/articles/index.html >
[20] Vanagaite, Kristina. MagicDraw UML 10.5 Extends BP Modeling with
Export to BPEL. DIGG [en lnea] 14 de Diciembre del 2005 [fecha de
consulta: 6 Septiembre 2008] Disponible en:
<http://www.magicdraw.com/ MagicDraw UML 10.5 Extends BP
Modeling with Export to BPEL>
[21] White, Stephen A. Mapping BPMN to BPEL Example. [en lnea]IBM
Corp., United States[fecha de consulta: 5 Septiembre 2008] Disponible
en : <http://www.bpmi.org/Documents/ Mapping BPMN to BPEL
Example.pdf >
[22] Hanson, Jeff Manage your business processes with JBoss jBPM.
JavaWorld.com[en lnea] 22 de Mayo del 2006 [fecha de consulta: 6
Septiembre 2008] Disponible en:
<http://www.javaworld.com/javaworld/jw-05-2006/jw-0522-jbpm.html>
[23] JSR-000208 Java Business Integration 1.0 [en lnea].Sun Microsystems
Copyright 1995-2004.[fecha de consulta: 30 Agosto 2008] Disponible
en: <http://jcp.org/aboutJava/communityprocess/final/jsr208/index.html
>
[24] Kinnumpurath,Meeraj .JBI - A Standard-based approach for SOA.[en
lnea] Diciembre del 2005.[fecha de consulta: 21 Agosto 2008]
Disponible en:
<http://www.theserverside.com/tt/articles/article.tss?l=JBIforSOA >
[25] Sommers ,Frank. Service-Oriented Java Business Integration. [en lnea]
11 de Agosto del 2005.[fecha de consulta: 21 Agosto 2008] Disponible
en: <http://www.artima.com/lejava/articles/jbi.html >