ADMINISTRACIÓN • Free Interprise Service Bus 52 Número 85 WWW.LINUX - MAGAZINE.ES S i una empresa necesita un tipo de configuración en la cual múltiples sistemas tienen que comunicarse con múltiples servicios, la red tendrá que enfrentarse al peligro de convertirse en una arquitectura tipo espagueti (Figura 1), en la que cada servicio se comunica con cada uno de los otros por medio de un intrincado sistema de interfaces dife- rentes. Cuando se llega a este estado, es conve- niente pensar en introducir una arquitec- tura orientada al servicio (SOA) [1] e inte- grar un bus de servicio empresarial (ESB) [2]. Las técnicas basadas en SOA propor- cionan un modelo para implementar pro- cesos de negocio complejos como una colección de aplicaciones software inter- activas las cuales se pasan la información las unas a las otras. Las aplicaciones Con- sumidoras y las aplicaciones Productoras comparten datos en la forma de mensajes SOAP. Esta arquitectura permite que una empresa añada e integre fácilmente com- ponentes nuevos de la infraestructura software con mínimos cambios en los componentes existentes. El modelo SOA también ofrece un estándar de desarrollo para asegurar la interoperabilidad de los servicios compatibles con SOA. La tecnología SOA se usa ampliamente en la integración de los diversos servicios clientes en el escenario de negocio empre- sarial que pasan y traducen los mensajes entre diversos entornos SOA. ESB es un componente esencial de lo que típica- mente se conoce como middleware empresarial. Los sistemas ESB sofisticados de hoy en día no sólo pasan los mensajes, sino que registran los eventos de los mensajes y, en algunos casos, proporcionan sistemas de traducción extendidos para los diversos formatos de mensajes para poder comuni- carse de forma transparente. Un ESB puede actuar como una instancia central (Figura 2) y eliminar la necesidad de tener múltiples interfaces independientes entre los servicios. Cada vez más y más empresas se están dando cuenta de la relevancia de integrar servicios distribuidos en aplicaciones empresariales heterogéneas, lo que implica que el negocio de los ESB se encuentra en auge. Los fabricantes de pro- ductos propietarios tales como IBM WebS- phere [3], Microsoft BizTalk [4], Oracle Integration Adapters [5] o Red Hat Jboss Enterprise SOA Platform [6] compiten en este mercado con productos libres tales como Mule ESB [7], Apache Service Mix [8] y Talend ESB [9] (anteriormente Sopera [10]). Lisog, que ahora forma parte de Open Source Business Alliance, le dio a ESB un papel importante en su arquitectura de nube [11]. A nivel de producto, Sopera y Mule son alternativas equivalentes y libres. La puesta en marcha de ESB puede ser cara y es una decisión con consecuencias a largo alcance. Incluso en configuracio- nes pequeñas se requiere una inversión en una escala de cinco cifras, con gastos por igual tanto en programación como en consultoría. Todos los fabricantes de ESB proclaman que la inversión vale la pena, ya que hace que el sistema sea más simple de mante- ner y extender. Sin embargo, un director de IT o un administrador tienen que ser conscientes de que la elección de un ESB significa un compromiso a largo plazo con el producto porque es difícil y caro para la Alexey Zarodov, 123Rf El Bus Gratuito Un Bus de Servicio Empresarial (ESB) es una autopista centralizada para los datos en entornos con arquitecturas orientadas al servicio. Un buen ESB se encarga de la orquestación, del enrutamiento de los men- sajes y del análisis de los eventos. Vamos a presentar tres opciones libres de ESB. POR ARNE ROSSMANN, CHRISTINE KÖNIG Y MARKUS FEILNER. Figura 1: Si cinco servicios necesitan comu- nicarse los unos con los otros, el resultado es una clase de arquitectura con forma de espagueti. En el peor de los casos, el depar- tamento TI de la empresa tendrá que progra- mar y mantener cada conector. Construyendo un entorno con arquitectura orientada al servicio con un Bus de Servicio Empresarial.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ADMINISTRACIÓN • Free Interprise Service Bus
52 Número 85 W W W . L I N U X - M A G A Z I N E . E S
Si una empresa necesita un tipo de
configuración en la cual múltiples
sistemas tienen que comunicarse
con múltiples servicios, la red tendrá que
enfrentarse al peligro de convertirse en
una arquitectura tipo espagueti (Figura 1),
en la que cada servicio se comunica con
cada uno de los otros por medio de un
intrincado sistema de interfaces dife-
rentes.
Cuando se llega a este estado, es conve-
niente pensar en introducir una arquitec-
tura orientada al servicio (SOA) [1] e inte-
grar un bus de servicio empresarial (ESB)
[2]. Las técnicas basadas en SOA propor-
cionan un modelo para implementar pro-
cesos de negocio complejos como una
colección de aplicaciones software inter-
activas las cuales se pasan la información
las unas a las otras. Las aplicaciones Con-
sumidoras y las aplicaciones Productoras
comparten datos en la forma de mensajes
SOAP. Esta arquitectura permite que una
empresa añada e integre fácilmente com-
ponentes nuevos de la infraestructura
software con mínimos cambios en los
componentes existentes. El modelo SOA
también ofrece un estándar de desarrollo
para asegurar la interoperabilidad de los
servicios compatibles con SOA.
La tecnología SOA se usa ampliamente
en la integración de los diversos servicios
clientes en el escenario de negocio empre-
sarial que pasan y traducen los mensajes
entre diversos entornos SOA. ESB es un
componente esencial de lo que típica-
mente se conoce como middleware
empresarial.
Los sistemas ESB sofisticados de hoy en
día no sólo pasan los mensajes, sino que
registran los eventos de los mensajes y, en
algunos casos, proporcionan sistemas de
traducción extendidos para los diversos
formatos de mensajes para poder comuni-
carse de forma transparente. Un ESB
puede actuar como una instancia central
(Figura 2) y eliminar la necesidad de tener
múltiples interfaces independientes entre
los servicios.
Cada vez más y más empresas se están
dando cuenta de la relevancia de integrar
servicios distribuidos en aplicaciones
empresariales heterogéneas, lo que
implica que el negocio de los ESB se
encuentra en auge. Los fabricantes de pro-
ductos propietarios tales como IBM WebS-
phere [3], Microsoft BizTalk [4], Oracle
Integration Adapters [5] o Red Hat Jboss
Enterprise SOA Platform [6] compiten en
este mercado con productos libres tales
como Mule ESB [7], Apache Service Mix
[8] y Talend ESB [9] (anteriormente
Sopera [10]).
Lisog, que ahora forma parte de Open
Source Business Alliance, le dio a ESB un
papel importante en su arquitectura de
nube [11]. A nivel de producto, Sopera y
Mule son alternativas equivalentes y
libres.
La puesta en marcha de ESB puede ser
cara y es una decisión con consecuencias
a largo alcance. Incluso en configuracio-
nes pequeñas se requiere una inversión
en una escala de cinco cifras, con gastos
por igual tanto en programación como en
consultoría.
Todos los fabricantes de ESB proclaman
que la inversión vale la pena, ya que hace
que el sistema sea más simple de mante-
ner y extender. Sin embargo, un director
de IT o un administrador tienen que ser
conscientes de que la elección de un ESB
significa un compromiso a largo plazo con
el producto porque es difícil y caro para la
Ale
xey Z
aro
do
v, 1
23R
f
El Bus GratuitoUn Bus de Servicio Empresarial (ESB) es una autopista centralizada
para los datos en entornos con arquitecturas orientadas al servicio. Un
buen ESB se encarga de la orquestación, del enrutamiento de los men-
sajes y del análisis de los eventos. Vamos a presentar tres opciones
libres de ESB. POR ARNE ROSSMANN, CHRISTINE KÖNIG Y
MARKUS FEILNER.
Figura 1: Si cinco servicios necesitan comu-
nicarse los unos con los otros, el resultado
es una clase de arquitectura con forma de
espagueti. En el peor de los casos, el depar-
tamento TI de la empresa tendrá que progra-
mar y mantener cada conector.
Construyendo un entorno con arquitectura orientada alservicio con un Bus de Servicio Empresarial.
empresa volverse atrás una vez que se
haya realizado el cambio.
Los consultores están de acuerdo al
menos en una cosa: es imposible dar una
recomendación genérica del producto ESB
ideal. Los escenarios individuales, las
capacidades de los servicios y los requeri-
mientos de los entornos de los servicios
afectan a la elección.
La Tabla 1 muestra algunas característi-
cas asociadas con los tres sistemas ESB
más populares de código abierto (Mule
ESB, Apache Service Mix y Talend ESB).
En este artículo, vamos a repasar con más
detalle estas alternativas ESB.
Mule ESBEl sistema ESB de MuleSoft es el más
popular de entre las aplicaciones ESB de
código abierto, con más de 1.5 millones
de descargas y 2.500 usuarios empresaria-
les. Mule ESB está programado en Java y
los sistemas existentes con componentes
JMS, servicios web y HTTP se pueden
integrar fácilmente. Al mismo tiempo,
MuleSoft indica que posee un alto nivel de
escalabilidad, lo que permite a los usua-
rios la posibilidad de combinar un gran
número de aplicaciones.
Mule ESB, que es apropiado tanto para
escenarios SOA como para aplicaciones
incrustadas de plataformas centralizadas,
utiliza su propio dialecto XML para propó-
sitos de configuración. En el ejemplo del
Listado 1, se muestra la configuración
para una aplicación simple de Mule ESB.
La aplicación recibe un nombre en una
URL y luego, muestra la cadena.
El primer código establece el espacio de
nombres para el componente. Luego, tras
un breve comentario en description (línea
12), la aplicación abre el flujo. Mule deno-
mina flujo a una secuencia en la que los
módulos tales como los componentes, se
despliegan. En este flujo, ESB acepta la
entrada proveniente de la URL, definida
por la etiqueta bound-endpoint (línea 19).
La entrada es proporcionada por un
servicio web JAX-WS (Java API para
XML Web Services), Mule se la pasa al
componente hecho programado interna-
mente org.mule.example.echo.Echo del
Listado 2 y el componente simplemente
Free Interprise Service Bus • ADMINISTRACIÓN
53Número 85W W W . L I N U X - M A G A Z I N E . E S
Figura 2: Un ESB actúa como sistema de
comunicación central para el paso de men-
sajes entre los servicios.
Tabla 1: Tres sistemas ESB de código abiertoMule ESB Apache ServiceMix Talend (Sopera)
Versión Actual 3.12 4.30 4.21
Licencia Community Edition (CPAL)/ Enterprise Edi-
tion con soporte comercial
Apache License 2.0 Eclipse public license (Community
edition); anteriormente Sopera
License (Enterprise Edition)
Arquitectura Java, centralizada Java, centralizada Java, bajo demanda, también dis-
tribuida
Comunidad Comunidad Muleforge activa, Mule exten-
sions, I-Beans, foros, varias listas de correo
Foros activos, listas de correo Foro, blog, seminarios en línea
Soporte Persona de contacto, actualizaciones soft-
ware, soporte 8/ 5 o 24/ 7, service packs
Foros de discusión, soporte 8/ 5
o 24/ 7, service packs
Línea caliente, ayuda de escritorio,
actualizaciones libres, service packs
Sistemas operativos sopor-
tados
Linux, Windows, Solaris, AIX, HP-UX, Mac
OS X
Linux, Windows XP y 2000,
Solaris, HP-UX, Mac OS X
Linux, Windows XP, Vista y Server
2003, Solaris
Independiente Sí Sí Sí
Servidor de aplicaciones
soportado
Geronimo, JBoss, WebLogic, WebSphere,
Oracle, Sun One, Tcat, Tomcat, Resin, Jetty,
Spring Framework
Geronimo, JBoss, Jonas Geronimo, JBoss, WebLogic, Web-
Sphere, SAP NetWeaver, Tomcat,
Jetty
Lenguaje soportado para
servicios/ componentes
Groovy, Java, Javascript, Jaxen, Jython
(Python), JRyby, JXPath
Java, Groovy, JRuby, Rhino,
JavaScript
Java, .NET
Soporte para el desarrollo Eclipse Mule IDE, Mule Studio, Profiler,