Free Enterprise Service Bus

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

Transcript of Free Enterprise Service Bus

Page 1: Free Enterprise Service Bus

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.

Page 2: Free Enterprise Service Bus

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,

Japex, Data Integrator IDE, Ant, Maven

Consola web para desarrollo de

componentes JBI

Herramienta propia (Eclipse)

Gestión de procesos de

negocio

JBPM, BPEL BPEL (Apache ODE), BpmScript Sopera BPM (basado en Intalio

BPM), Apache ODE, SAG, webMeth-

ods BPMS

Monitorización Gestión y monitorización, gestión de

parches, herramientas de migración

JMX, Ant Tasks Toolkit (Eclipse), Gestión de inter-

faces para Service Registry, JMX,

Sopera HQ

Disponibilidad Alta disponibilidad y tolerancia a fallos,

políticas de reintento para autoreparar

conexiones

Alta disponibilidad y clusters de

contenedores

Arquitectura distribuida

Persistencia de los men-

sajes

Colas VM persistentes (colas internas de

SEDA para la persistencia)

JMS, JDBC JMS

Transacciones Independientes del transporte (p.e., JDBC,

XA, JMS, reconocimiento de mensajes,

transacciones multirecursos [EE])

JMS, JCA JMS, JDBC

Page 3: Free Enterprise Service Bus

Apache ServiceMixApache ServiceMix es una solución ESB

software que ya se está utilizando en

multitud de aplicaciones y en empresas

de TI. ServiceMix está basado en la espe-

cificación Java Business Integration (JBI)

[12], que define una arquitectura están-

dar que es útil tanto para las herramien-

tas Java como para ESB. La arquitectura

prevé una colección de componentes

proveedores o de servicios consumidores

y los puntos de integración se encuen-

tran implementados como complemen-

tos.

Apache ServiceMix implementa la ver-

sión 1.0 (JSR 208) de la especificación JBI

e incluye diversos componentes, los más

importantes de los cuales son:

• servicemix-bean: Uti-

liza POJO (Plain Old

Java Objects).

• servicemix-eip: Un

motor de servicios,

incluye la implementa-

ción de un router en

línea junto con EIP

(Enterprise Integration

Patterns).

• servicemix-file: Acceso

al sistema de ficheros.

• servicemix-http: Acceso

a servicios SOAP y

HTTP.

• servicemix-jms: Acceso a implementa-

ciones JMS tales como Apache Active

MQ.

Un ejemplo sencillo de una herramienta

de copiado de ficheros automática nos va

a mostrar como los administradores pue-

den trabajar con Apache ServiceMix. Si

se desea que la copiadora tome los fiche-

ros de un directorio

(/home/servicemix/input) y los deje en

otro (/home/servicemix/output), habrá

que crear primero un directorio para el

proyecto y luego editar el fichero

pom.xml para configurar Maven [13],

una herramienta de administración del

proyecto Apache. El siguiente comando

crea la unidad de servicio:

mvn archetype:create U

-DarchetypeArtifactIdU

muestra el nombre que se le haya propor-

cionado. Mule Studio visualiza el flujo

(Figura 3).

Los usuarios de la edición empresarial

comercial pueden acceder a herramientas

adicionales, tales como a Native WebS-

phere MQ y a Premium JDBC. Además,

también soporta la gestión del rendi-

miento y del control desde la consola de

gestión. A partir de la versión 3.2, tam-

bién soporta los clusters y el despliegue.

Los usuarios normalmente despliegan su

propio Service Flow Analyzer para poder

analizar los posibles conflictos.

Además está disponible un soporte adi-

cional bajo petición, como mecanismos

de seguridad extendidos, tales como

SAML y control de acceso basado en roles.

ADMINISTRACIÓN • Free Interprise Service Bus

54 Número 85 W W W . L I N U X - M A G A Z I N E . E S

Figura 3: Un ejemplo sencillo de aplicación en Mule Studio.

01 <?xml version=”1.0” encoding=”UTF-8”?>

02 <mule

xmlns=”http://www.mulesoft.org/schema/mule/core”

03 xmlns:cxf=”http://www.mulesoft.org/schema/mule/cxf”

04 xmlns:doc=”http://www.mulesoft.org/schema/mule/doc-

umentation”

05 xmlns:spring=

”http://www.springframework.org/schema/beans”

06

xmlns:core=”http://www.mulesoft.org/schema/mule/core

07

xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance

08 xsi:schemaLocation=”

09 http://www.mulesoft.org/schema/mule/cxf

http://www.mulesoft.org/schema/mule/cxf/3.1/mule-cxf

.xsd

10 http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-b

eans-3.0.xsd

11 http://www.mulesoft.org/schema/mule/core

http://www.mulesoft.org/schema/mule/core/3.1/mule.xs

d “>

12 <description> Esta configuración compila un servicio

JAX-WS con CXF. Se usa un “serviceClass” que es un inter-

faz JAX-WS que se ha definido. Permite asegurarse que el

WSDL se ha generado sólo por el método “echo” (a diferen-

cia del resto de métodos de EchoComponent). Esto

mantiene al WSDL limpio -- aunque no es necesario.

13 Para invocar el servicio Echo siga la URL --

http://localhost:65082/services/EchoUMO/echo/text

/hello

14 Para ver el WSDL del servicio Echo vaya a --

http://localhost:65082/services/EchoUMO?wsdl<

/description>

15 <flow name=”EchoFlow”>

16 <core:inbound-endpoint address=”http://local-

host:65082/services/EchoUMO”

17 exchange-pattern=”request-response”

doc:name=”Generic”

18 doc:description=”Generic endpoint specified by

address URI”/>

19 <cxf:jaxws-service

serviceClass=”org.mule.example.echo.Echo”

20 doc:name=”SOAP”

21 doc:description=”Make a web service available via

CXF”/>

22 <component doc:name=”Component”

doc:description=”Invoke a Java component”>

23 <singleton-object

class=”org.mule.example.echo.Echo”/>

24 </component>

25 </flow>

26 </mule>

Listado 1: Configuración de Mule

01 @WebService

02 public class Echo

03 {

04 @WebResult(name=”text”)

05 public String

echo(@WebParam(name=”text”)

String string)

06 {

07 return string;

08 }

09 }

Listado 2: ComponenteEcho

Page 4: Free Enterprise Service Bus

=servicemix-service-unit U

-DarchetypeGroupIdU

=org.apache.servicemix.tooling U

-DartifactId=tutorial-file-su

Después hay que añadir las dependencias de Apache Service-

Mix al fichero pom.xml (Listado 3). Ahora sólo falta la

configuración de los extremos para los ficheros. Hace falta un

enviador de ficheros y un receptor. El Listado 4 proporciona

el fichero xbean.xml necesario. Lo único que hay que hacer

ahora es agrupar los resultados en un ensamblador de servi-

cios:

mvn archetype:create U

-DarchetypeArtifactId=U

servicemix-service-assembly U

-DarchetypeGroupId=U

org.apache.servicemix.tooling U

-DartifactId=tutorial-sa

A continuación, hay que cambiar el nombre del proyecto en

pom.xml y añadir las dependencias en la unidad de servicio

(Listado 5). Para un despliegue en caliente, hay que entrar en

el directorio del proyecto de ejemplo, tutorial-sa y ejecutar

mvn install para compilar el proyecto. Así se obtendrá un

fichero ZIP, que se podrá copiar al directorio $SERVICE-

MIX_HOME/hotdeploy. Para más detalles acerca de Apache

ServiceMix, véase la documentación de ServiceMix [14].

La variante Enterprise de Apache ServiceMix la encontra-

mos bajo el nombre Fuse ESB y la comercializa FuseSource

[15]. La edición Enterprise proporciona funcionalidades adi-

cionales y también incluye el Fuse Message Broker (basado

en Apache Active MQ), el Fuse Mediation Router (que utiliza

Apache Camel [16]) y el Fuse Service Framework (con Apa-

che CXF).

01 <dependencies>

02 <dependency>

03 <groupId>org.apache.servicemix</groupId>

04 <artifactId>servicemix-file</artifactId>

05 <version>${servicemix-version}</version>

06 </dependency>

07 </dependencies>

Listado 3: pom.xml

01 <beans

xmlns:file=”http://servicemix.apache.org/file

/1.0”

02 xmlns:tut=”urn:servicemix:tutorial”>

03 <!-- add the sender endpoint here -->

04 <!-- add the poller endpoint here -->

05 </beans>

06 <file:sender service=”tut:file”

07 endpoint=”sender”

08 directory=”file:/home/servicemix/output” />

09 <file:poller service=”tut:file”

10 endpoint=”poller”

11 file=”file:/home/servicemix/input”

12 targetService=”tut:file”

13 targetEndpoint=”sender”/>

Listado 4: xbean.xml

Page 5: Free Enterprise Service Bus

cial. Por el contrario, las funciones se eje-

cutan en librerías de servicios troncales.

El siguiente ejemplo muestra como se

diseña una aplicación SOA con Talend

ESB. Este ejemplo utiliza un servicio web

para simplemente mostrar cualquier

entrada (echo). Un consumidor alimenta

el servicio con datos y un proveedor

ofrece el servicio. En [17] se puede encon-

trar un tutorial detallado de la

configuración.

Para crear un consumidor, primero hace

falta un trabajo nuevo. Luego se podrá

proceder a definir una entrada simulada

por medio del componente FixedFlowIn-

put y transformarlo en un mensaje XML

por medio de tXMLMap. Luego el men-

saje se utiliza para alimentar al tESBCon-

sumer, que dispara la llamada al servicio

web para el proveedor ESB. De nuevo, se

podrá configurar el fichero de

configuración WSDL (Web Service Defini-

tion Language) para ello.

Ahora sólo hace falta un proveedor con

dos componentes ESB proveedores: uno

que acepte las peticiones y otro que

devuelva las respuestas. De nuevo, hace

falta un trabajo nuevo para el proveedor.

Los dos componentes se encuentran com-

binados por tLogRow de modo que el flujo

de datos entre ellos se muestra por la línea

de comandos.

La tESBProviderRequest tiene que confi-

gurarse usando el mismo fichero WSDL

que el consumidor creó. Luego podrá ini-

ciarse el proveedor para el servicio reque-

rido. Para ello, hay que ir a la solapa Start

en la parte inferior del espacio de trabajo.

Al consumidor también se le proporciona

luego el comando para que se inicie

usando el mismo mecanismo.

La edición Enterprise de Talend ESB

también soporta la integración de compo-

nentes comerciales adicionales. Los

paquetes opcionales permiten que los

usuarios puedan desplegar Sopera ESB

.NET, Sopera BPM,

Sopera Applica-

tion, Data Integra-

tion y Sopera HQ

(gestión de servi-

cios y sistemas). El

fabricante también

ofrece entornos

comerciales de

tiempo de ejecu-

ción y soporte. La

versión empresa-

rial está sujeta a

una licencia independiente de Sopera

(EPL para la Community Edition).

Lo que hace que sea interesante la edi-

ción Enterprise de Talend ESB es la coope-

ración mejorada entre los equipos admi-

nistrativos por medio del repositorio de

Talend y la consola administrativa para la

gestión centralizada de las actividades de

servicio y localización.

Comunidades, Soporte eIDELos tres sistemas ESB que se han comen-

tado cuentan con comunidades muy acti-

vas, aunque la mayor de todas es sin duda

la de Mule, donde los miembros de la

comunidad ofrecen un soporte muy útil

además de proporcionar extensiones e I-

Beans que ellos mismos han programado.

El repositorio Git de Mule contiene nume-

rosos componentes.

Tras la adquisición de Sopera por parte

de Talend, los usuarios cuentan ahora con

el beneficio de una comunidad de usua-

rios muy fuerte. Alrededor de Talend

Open Studio ha ido creciendo una comu-

nidad muy activa, con comunicación por

medio de foros y además se les ofrece a

sus usuarios numerosos desarrollos.

Aunque existe una comunidad tanto

para Apache ServiceMix como para Fuse

ESB, no son tan activas como las comuni-

dades de Mule y Talend.

Los tres fabricantes ofrecen soporte

para sus ediciones empresariales. Los

clientes pueden escoger entre varios

modelos con diversas funcionalidades.

Las empresas tenderán por optar por la

edición Enterprise con garantías de

soporte, especialmente para aplicaciones

críticas. En este caso, los servicios TI de

las diferentes empresas no tendrán que

basarse en el soporte ofertado por las

comunidades en caso de que surja algún

desastre.

Los tres fabricantes también ofrecen

soporte de desarrollo para sus aplicacio-

nes. Además del IDE de Mule, que está

basado en Eclipse, MuleSoft ahora posee

su nuevo Mule Studio. Mule Studio per-

mite a los programadores modelar flujos

de forma gráfica y configurar los compo-

nentes, tales como las conexiones JDBC.

Este componente gráfico hace posible la

definición de flujos genéricos en un

periodo de tiempo relativamente corto.

Mientras tanto, los desarrolladores podrán

concentrarse en montar los componentes

requeridos.

Los desarrolladores también utilizan el

Fuse IDE como un entorno de desarrollo

integrado y la interfaz de usuario gráfica

Fuse HQ para gestionar y monitorizar el

ESB. Si se encuentra interesado, Fuse Soft

también ofrece soporte y formación.

Talend ESBSopera ASF es una plataforma de integra-

ción orientada al servicio desarrollada

para la integración de proyectos para la

Deutsche Post AG. Desde 2008 el fabri-

cante ofrece el software como una solu-

ción de código abierto. En noviembre de

2010, Talend adquirió Sopera y ahora está

continuando el proyecto bajo el nombre

Talend ESB.

Talend ESB posee una estructura modu-

lar, integra aplicaciones de terceros, proce-

sos, datos y soluciones SOA en su propio

SOA, soportando tanto estándares básicos

tales como SOAP, WDSL y XML, como

estándares extendidos tales como UDDI,

WS Policy y BPEL.

Otra variante SOA asociada con Talend

ESB es Apache Camel. El marco de trabajo

de intregración Camel, de código abierto,

soporta EIP para negociar las reglas de

mediación. Como el marco de trabajo está

basado en URL simples, los administrado-

res pueden trabajar con modelos de trans-

porte virtualmente arbitrarios, tales como

HTTP, JMS (Active MQ y otras implemen-

taciones JMS) o JBI.

Los usuarios pueden utilizar Talend ESB

en Java y en entornos Microsoft y combi-

nar los dos por medio de un marco de tra-

bajo SOA estandarizado. Para este fin,

Talend ESB soporta los estándares Java

J2SE, J2EE y la API Windows Communi-

cation Foundation (WCF) de .NET 3.0.

Talend ESB utiliza una arquitectura dis-

tribuida y puede desplegarse en entornos

distribuidos separados geográficamente.

En este contexto, distribuido también, sig-

nifica que un bus centralizado no es esen-

ADMINISTRACIÓN • Free Interprise Service Bus

56 Número 85 W W W . L I N U X - M A G A Z I N E . E S

01 <project>

02 [...]

03 <dependencies>

04 <dependency>

05

<groupId>org.apache.servicemix.tutorial</groupId>

06 <artifactId>tutorial-file-su</artifactId>

07 <version>1.0-SNAPSHOT</version>

08 </dependency>

09 </dependencies>

10 [...]

11 </project>

Listado 5: pom.xml

Page 6: Free Enterprise Service Bus

Tras la adquisición de Sopera por

Talend, la versión actual es la 4.2 que

viene ahora con una herramienta gráfica

que permite a los administradores montar

sus SOA. Con ello, los usuarios tendrán

una interfaz gráfica, como las herramien-

tas Talend Open Studio y Data Profiler,

con la que los usuarios podrán arrastrar

los componentes en una ventana de

desarrollo donde podrán combinarlos y

configurarlos. Los programadores podrán

concentrarse completamente en el

desarrollo de componentes Java.

Fuse también ofrece una herramienta

que permite que los usuarios tengan un

espacio de trabajo gráfico en el que

podrán arrastrar, enlazar y configurar sus

componentes en el Fuse IDE. Las tres

soluciones están basadas en Eclipse.

Competidores: IBM, RedHat y MicrosoftLos competidores de pago tienen como

objetivo a grupos muy diferentes de usua-

rios. Los usuarios pueden siempre encon-

trar ayuda en los foros, en los grupos de

usuarios, blogs, webcasts y wikis. El sis-

tema propietario de Microsoft, BizTalk

está especialmente indicado para los

clientes que ya despliegan soluciones

completas de Redmond y sólo se encuen-

tra disponible para la plataforma Win-

dows.

La plataforma SOA JBoss de Red Hat

crea una API propietaria y se vende como

una solución independiente sin Tomcat ni

sistemas middleware adicionales. Su

fuerza radica en el sector de la mensajería

y WebSphere de IBM es una de las solu-

ciones más caras, pero ofrece a sus clien-

tes de pago una respuesta a casi cualquier

problema.

ESB de Código Abierto:Algo para TodosCada una de las soluciones ESB posee sus

beneficios y poseen ediciones empresaria-

les. Los clientes pueden escoger normal-

mente entre modelos con diferentes nive-

les de disponibilidad. Los fabricantes no

ofrecen soporte para las ediciones gratui-

tas pero recomiendan a los usuarios que

utilicen las comunidades de usuarios.

Mule ESB proporciona la ventaja de

una gran comunidad. Además, Mule ESB

3 ofrece muchos conectores para servi-

cios basados en la nube – tales como

Salesforce, Amazon Web Services o Twit-

ter – por sí mismo. Esto facilita la tarea

de desarrollar soluciones ESB que acce-

dan a los servicios de la nube; algo inte-

resante considerando la integración de

los servicios basados en la nube con las

aplicaciones tradicionales que probable-

mente se vuelvan más importantes en el

futuro.

Por otro lado, Talend ofrece un IDE muy

intuitivo para poder programar aplicacio-

nes basadas en ESB. Talend ha extendido

su oferta para incluir una solución ESB y

gradualmente ganarle terreno a Mule.

Apache ServiceMix y Fuse ESB tienen cur-

vas de aprendizaje mayores comparadas

con el resto y son más adecuadas para

desarrolladores con experiencia.

La principal ventaja de estos programas

es su excelente interoperatibilidad con

otros proyectos relevantes de Apache tales

como Active MQ, Camel o CXF. Además el

OSGi (Open Service Gateway initiative

[18]) creó un sistema base pensando en el

futuro como plataforma de integración

basada en un estándar reconocido �

Free Interprise Service Bus • ADMINISTRACIÓN

57Número 85W W W . L I N U X - M A G A Z I N E . E S

Los investigadores de mercado Forres-

ter y Gartner han investigado repetitiva-

mente los ESB en los últimos años. Los

mejores productos son denominados

líderes y también recomiendan potentes

rendimientos. Los mejores fabricantes

en el lenguaje de Gartner son empresas

que presentan soluciones o tecnologías

innovadoras y cuyo uso tiene algún tipo

de influencia sobre el usuario. Dicho

esto, los candidatos pueden obtener

una puntuación de 0 (muy pobre) a 5.0

(muy alta) para cada característica anali-

zada.

Un resumen de los resultados:

• Apache ServiceMix basado en Fuse

ESB 4.0 fue el líder de 2011 en el estu-

dio ESB de Forrester. Su orquestación

recibió la máxima puntuación (5.0), la

arquitectura 4.88 y las conexiones

4.70.

• Forrester también citó a BizTalk de

Microsoft como líder de 2010. Los

analistas investigaron el BizTalk Ser-

ver 2010 y el ESB Toolkit. BizTalk con-

siguió un buen valor de 5.0 en su dis-

plina de estrategia.

• IBM también fue citada como líder de

2011 en el estudio de ESB por su pro-

ducto WebSphere Enterprise Service

Bus Registry Edition (WESBRE) y

WebSphere Message Broker (WMB).

IBM WebSphere Enterprise Service

Bus (WESB) se aseguró un puesto en

la categoría de mejor rendimiento.

• El estudio de ESB de Forrester de

2011 considera a Mule ESB 3 como un

sistema de gran rendimiento. Su

mayor beneficio fueron las conexio-

nes (5.0), la arquitectura (4.70) y cam-

bio y control (4.47) según el estudio.

• JBoss Enterprise SOA Platform 5.0.2

aparece listado como de alto rendi-

miento por Forrester desde 2011 con

una puntuación de 3.98 para la media-

ción, 3.37 para el cambio y control y

3.33 para las conexiones.

• Gartner citó a Sopera en 2010 como

una buena empresa en middleware

de plataforma e integración.

Análisis ESB

RECURSOS[1] Enterprise Service Bus: http:// en.

wikipedia. org/ wiki/ Enterprise_service_bus

[2] SOA: http:// en. wikipedia. org/ wiki/ Service-oriented_architecture

[3] IBM Webspere: http:// www-01. ibm. com/ software/ integration/ wsesb/

[4] Microsoft Biztalk:

http:// www. microsoft. com/ biztalk/ en/ us/ default. aspx

[5] Oracles Integration Adapters:

http:// www. oracle. com/ technetwork/ middleware/ adapters/ overview/ index. html

[6] Plataforma JBoss Enterprise SOA:

http:// www. Jboss. com/ products/ platform/ soa

[7] Mulesoft: http:// www. mulesoft. org

[8] Apache Servicemix:

http:// servicemix. apache. org

[9] Talend:

http:// de. talend. com/ products-application-integration/ index. php

[10] Sopera: http:// www. sopera. de

[11] Markus Feilner, Virtuos Gestapelt:

Linux-Magazin 04/ 11, S. 48

[12] Forrester Research, The Forrester

Wave: Enterprise Service Bus, Q2

2011:

http:// www. oracle. com/ us/ corporate/ analystreports/ infrastructure/ forrester-wave-esb-q2-2011-395900. pdf

[13] JBI: http:// en. wikipedia. org/ wiki/ Java_Business_Integration

[14] Apache Maven:

http:// maven. apache. org

[15] Guia de iniciación de Apache Ser-

vice Mix:

http:// servicemix. apache. org/ 2-beginner-using-maven-to-develop-jbi-applications. html

[16] Fuse Source: http:// fusesource. com

[17] Apache Camel:

http:// camel. apache. org

[18] Tutorial de Talend ESB: http:// www. talendforge. org/ tutorials/ tutorial. php?language=english&idTuto=94

[19] Open Services Gateway Initiative:

http:// www. osgi. org