Panorama de produtos ESB Open Source.docx

guitarchanceSoftware and s/w Development

Aug 15, 2012 (5 years and 9 months ago)


Panorama de produtos ESB Open Source

Principais Produtos ESB Open Source atualmente:

Apache Service Mix

Apache ServiceMix

is an open source distributed Enterprise Service Bus (ESB) and SOA toolkit built from
the ground up on the semantics and APIs of the Java Business Integration (JBI) specification JSR 208 and
released under the Apache license. ServiceMix is lightweight and

easily embeddable, has integrated Spring
support and can be run at the edge of the network (inside a client or server), as a standalone ESB provider
or as a service within another ESB. You can use ServiceMix in Java SE or a Java EE application server.
viceMix uses ActiveMQ to provide remoting, clustering, reliability and distributed failover.

Apache ServiceMix é um ESB open
source distribuido e um toolkit SOA construido com base na semantica
e APIs do
Java Business Integration (JBI)
, definido pela especificação JSR 208. O ServiceMix é distribuído
pela licensa Apache.

ServiceMix PE de fail integração (sentido de embeddadle) e leve, possui suporte integrado ao framework
Spring e pode ser executado na fronteira da rede, seja no cliente

ou servidor, como um ESB standalone ou
como um serviço dentro de outro ESB. Pode ser utilizado com Java SE ou um servidor de aplicação Java
EE. ServiceMix utiliza o ActiveMQ para fornecer suporte a clusters, reliability, remoting e distributed

How does ServiceMix compare to Celtix


wad an open source ESB project founded by

Fuse Source
, and hosted at

. Celtix has
morphed into

Apache CXF
. Like ServiceMix, CXF is designed to serve as the foundation for a Service Oriented
Architecture. Although the two project teams are both developing ESB solutions, there is a close level of
collaboration between the

two efforts, due to the complementary nature of the projects.

The ServiceMix development effort has focused on providing an ESB based on a JBI container and component
suite. Celtix is focused on integration components and SOAP stacks. This means that ther
e is actually not as
much overlap between the two projects as one might expect. On the contrary, the two project teams are
collaborating closely to avoid duplicating efforts and to enable reuse of each project's unique capabilities. For
example, ServiceMix

will reuse the SOAP stacks and integration components from Celtix, and Celtix will reuse the
ServiceMix JBI container.

Why is ServiceMix focused on JBI? The ServiceMix

team began work on its ESB solution at the time that the JBI
specification was in discussion, so the team was able to plan on using JBI not only for integration capabilities at
the endpoints, but also for internal APIs, to enable JBI
compliant solutions t
o deliver core functionality to the
integration environment.

For example, because JBI supports a standard deployment unit format, ServiceMix supports hot deployment of
any JBI
compliant BPEL engine (or set of BPEL files into a BPEL engine), rule engine, tr
ansformation engine,
scripting engine or other integration component (such as specific JBI binding components) directly into
ServiceMix. Also, ServiceMix contains a number of WS
* implementations built on JBI, such as WS Notification.

Today's Open Source E
SB solutions are increasingly focused on interoperability. Despite the different approaches
to integration that the ServiceMix and Celtix teams have taken, the advantage they enjoy as open source
projects through close collaboration is the ability to lever
age each other's strengths.

How does ServiceMix compare to Mule

Conceptually, ServiceMix and Mule are quite similar in that they allow services to be integrated through different
APIs and across dif
ferent transport technologies. Service Mix and Mule provide similar features, and both
solutions enable a simple, lightweight POJO
based deployment model that uses the Spring framework to
integrate services.

Both ServiceMix and Mule are designed as integra
tion solutions whose capabilities are independent of the
transport. ServiceMix achieves this through its JBI
based architecture, while Mule is based on a services
container and configuration of message endpoints.

Compared to Mule, the major difference for
ServiceMix is its architectural design, which is fundamentally based
on the Java Business Integration (JBI) standard. Mule provides a JBI binding so that Mule components can
interact with JBI containers, including the ServiceMix JBI container. However, the

internal Mule APIs are not
based on the JBI standard.

While JBI support is a very good thing, ServiceMix provides not only external APIs to support JBI
integration, but also internal APIs based on JBI, to give agility and flexibility not only with r
espect to the
integration capabilities at the endpoints, but also to the functionality of applications executing across the fabric of
the integration environment.

For example, because JBI supports a standard deployment unit format, you can hot deploy any J
BPEL engine (or set of BPEL files into a BPEL engine), rule engine, transformation engine, scripting engine or
other integration component (such as specific JBI binding components) directly into ServiceMix. Also ServiceMix
contains a number of

* implementations built on JBI, such as WS Notification.

Even though the JBI standard and the Mule messaging platform look very different at the API level, conceptually
they are trying to do similar things. Like Mule, JBI is based on the idea of both c
omponent and container based
routing. However, JBI provides a standard for the integration of any commercial or open source component.
Equally important, the JBI standard supports a very high level of integration functionality. A JBI component can
smart routing to endpoints. A JBI component can just communicate with its default service, letting the
container do the routing for it. Or a JBI component can give the JBI container a hint of which endpoint to use
(such as providing a service QName to use
or specifying an operation QName) and then the JBI container can, if
there are many available services to choose from, use some kind of policy negotiation or load balancing algorithm
to choose which physical endpoint to choose. Lastly, JBI is a cleaner abs
traction for working with both logical and
physical web service endpoints, WSDL and the standard WSDL defined message exchange patterns (MEPs).

While ServiceMix supports a lightweight deployment model similar to that of Mule, ServiceMix is also fully
rated into Apache Geronimo, bringing JBI functionality into Apache's J2EE container. This allows Apache
Geronimo to hot
deploy any JBI component or service using its standard deployment tooling (JSR 77/88
compliant). This difference between the two product
s also originates in our focus on agility. Some ServiceMix
implementations will be endpoint
centric, like Mule. Others may leverage the capabilities of an application server.
ServiceMix is designed for either integration scenario, or some combination of th
e two.

Today's Open Source ESB solutions are increasingly focused on interoperability, and despite their differences in
architecture and design philosophy, this principle of interoperability applies to ServiceMix and Mule. The Mule JBI
binding enables Mule

components to interact with the ServiceMix JBI container. Also, Mule transports,
components and transformers can be used inside the ServiceMix JBI container. Likewise, ServiceMix has full
support for Mule; so if you already have an investment in some Mule

configuration or code, you can reuse it
inside ServiceMix along with any other JBI components.

How does ServiceMix compare to Synapse


Apache Synapse

describes the project as " designed to be a simple, lightweight and high performance
Enterprise Service Bus (ESB) from Apache. Based on a small asynchronous core, A
pache Synapse has excellent
support for XML and Web services

as well as binary and text formats."

This naturally leads to two important questions:

Is Apache Synapse an ESB?

How is Apache Synapse different from Apache ServiceMix?

Firstly in the

words of Dave Chappell

one of the founders of Synapse and the author of the book

Service Bus

This project (Synapse) is related to ESB, but it is not in itself an ESB. What Synapse brings to the table is a
mediation framework that allows users to get in the mid
dle between service requesters and providers and
perform various tasks including transformation and routing and that helps to promote loose coupling between

The distinction David makes goes to the heart of both questions. First, Synapse is n
ot a full ESB in the most
common sense of the term. Secondly, because the design of Apache Synapse is different from that of Apache
ServiceMix, the two solutions have different capabilities and limitations.

A number of solutions that broker or mediate Web
services exchanges are described as ESBs, and Synapse can
reasonably be included in that category. However, what most defines an ESB is not its architecture, but its
function, which in general terms is to provide

a manageable system of message
based connec

with a high degree of performance, scalability and reliability

spanning multiple transports and heterogeneous endpoints.

In providing management through WS
* to Apache Axis, the Apache Synapse project provides a very important
and useful capability
to Web services. However, in its current implementation Apache Synapse would be
overextended as an "architectural" solution. Building an SOA on Apache Synapse would presume that all
exchanges in the SOA would be made through SOAP
based Web Services, that t
he management of the
exchanges would be invoked exclusively by means of WS
*, and that the underlying SOAP stack(s) implement
the relevant protocols.

ServiceMix is a full ESB that can work with many different

SOAP Stacks

such as Axis, WSIF, XFire, ActiveSOAP
and JAX
WS. ServiceMix also has full support for



. Like Apache
Synapse, Apache ServiceMix provides mediation for web services exchanges

and is designed to support
transformation, management and routing through WS
* standards. However, this capability is provided without
dependency on the SOAP stack, and most importantly, is provided through the same services architecture used
for all mess
age formats and transports, including, but certainly not limited to, Web services.

Lastly, it is also worth noting that the ServiceMix


are working with the Synapse community to add JBI
upport to Synapse, so ServiceMix and Synapse could work together and integrate nicely with each other using
JBI; deploying Synase as a JBI component within ServiceMix's JBI container allowing it to integrate with other JBI
components such as smart routers
or BPEL engines etc.

Apache Synapse

Apache Synapse is an ESB that has been designed to be simple to configure, very fast, and effective at
solving many integration and gatewaying

problems. Synapse has support for HTTP, SOAP, SMTP, JMS, FTP
and file system transports, Financial Information eXchange (FIX) and Hessian protocols for message
exchange as well as first class support for standards such as WS
Addressing, Web Services Secur
(WSS), Web Services Reliable Messaging (WSRM), efficient binary attachments (MTOM/XOP). Synapse can
transform messages using key standards such as XSLT, XPath and XQuery, or simply using Java. Synapse
supports a number of useful functions out
x without programming, but it also can be extended
using popular programming languages such as Java, JavaScript, Ruby, Groovy, etc..

Synapse has a completely asynchronous core, and supports non
blocking HTTP and HTTPS using the
Apache HttpCore

NIO module. In addition, Synapse supports JMS v1.0 and higher, Apache VFS File
Systems (FTP, SFTP, File (including zip/jar/tar/gz), Webdav, CIFS), POP3/IMAP/SMTP transports. Apache
Synapse ca
n process SOAP 1.1/1.2, pure XML/REST, Text and Binary messages with support for any
any conversion and transformation.

Key Features

The latest release of Synapse is

. Its key
features are

Proxy services

facilitating transport, interface (WSDL/Schema/Policy), message format (SOAP
1.1/1.2, POX/REST, Text, Binary), QoS (WS
RM) and optimization
switching (MTOM/SwA)

blocking HTTP/S transports based on



for ultrafast execution and support for
thousands of connections at high concurreny with constant memory usage

Built in Registry/Repository, facilitating dynamic updating
and reloading of the configuration and
associated resources (e.g. XSLTs, XSD, JS, ..)

Easily extended via custom Java class (mediator and command)/Spring mediators, or BSF Scripting
languages (Javascript, Ruby, Groovy, etc.)

Built in support for scheduling

tasks using the



balancing (with or without sticky sessions) /Fail
over, and clustered Throttling and Caching

Security, WS
Reliable Messaging & Throttling configurable via
level) WS

JMS (v1.x upwards) message support for binary, plain text and XML and SOAP payloads

Support for

Hessian binary web service protocol

Industry driven

Financial Information eXchange (FIX)


Enhanced support for Apache VFS transports (s/ftp, file, zip/tar/gz, webdav, cifs..)

Support for message splitting & aggregation using the EIP

Database lookup & store support with DBMed
iators with reusable database connection pools

Enhanced Mail transport with POP3/SMTP/IMAP protocols

GZip encoding over the HTTP/S transport

Channel message exchange with WS

Ability to pin a proxy service or a task to server instances on a

Mandatory sequence if required before mediation

Lightweight, XML and Web services centric messaging model

Configurations serialized into a file system for versioning/backup & restoration with built
Registry support

Support for Error handling and timeouts, recovery with http/s maintainance mode & gracefull

JMX monitoring support

Many samples and a built
in Axis2 server to try out and experiment with samples (Samples
includes WS
Security, JMS POX/Text messages
, Script mediation and many more samples which
can be run out of the box)

Enhanced documentation for samples and getting started


Mule is a light
weight messaging framework. It is a highly distributable object broker that can seamlessly
handle interactions with other applications using disparate technologies, transports and protocols. The Mule
framework provides a highly scalable environment in whi
ch you can deploy your business components.
Mule manages all the interactions between components transparently whether they exist in the same VM
or over the internet and regardless of the underlying transport used. Mule was designed around the
Enterprise S
ervice Bus architecture, which stipulates that different components or applications
communicate through a common messaging bus, usually implemented using Jms or some other messaging
server. Mule goes a lot further by abstracting Jms and any other transport

technology away from the
business objects used to receive messages from the bus.

What Is Mule?

Mule is a lightweight Java
based messaging framework that allows you to quickly and easily connect your
applications and enable them to exchange data. Mule
uses a service
oriented architecture (SOA), enabling
easy integration of your existing systems. Regardless of the different technologies the applications use,
including JMS, Web Services, JDBC, HTTP, and more, Mule seamlessly handles interactions among the

The Mule framework is highly scalable, allowing you to start small and connect more applications over
time. Mule manages all the interactions between applications and components transparently, regardless of
whether they exist in the same
virtual machine or over the Internet, and regardless of the underlying
transport protocol used.

Mule is based on ideas from

Enterprise Service Bus

(ESB) architectures. The key advantage of an ESB is
that it allows different applications to communicate with

each other by acting as a transit system for
carrying data between applications within your intranet or across the Internet. There are currently several
commercial ESB implementations on the market. However, many of these provide limited functionality or
are built on top of an existing application server or messaging server, locking you into that specific vendor.
Mule is vendor
neutral, so different vendor implementations can plug in to it. You are never locked in to a
specific vendor when you use Mule.

Mule provides many advantages over competitors, including:

Mule components can be any type you want. You can easily integrate anything from a "plain old Java
object" (POJO) to a component from another framework.

Mule and the ESB model enable significant
component reuse. Unlike other frameworks, Mule allows you to
use your existing components without any changes. Components do not require any Mule
specific code to
run in Mule, and there is no programmatic API required. The business logic is kept completely

from the messaging logic.

Messages can be in any format from SOAP to binary image files. Mule does not force any design
constraints on the architect, such as XML messaging or WSDL service contracts.

You can deploy Mule in a variety of topologies,

not just ESB. Because it is lightweight and embeddable,
Mule can dramatically decrease time to market and increases productivity for projects to provide secure,
scalable applications that are adaptive to change and can scale up or down as needed.

ce also provides administration tools that allow you to manage your deployments (Mule HQ) and
control your infrastructure (Mule Galaxy). These tools are described in more detail in the Administering
Mule section.



Project Open ESB implements an Enterprise Service Bus (ESB) runtime with sample service engines and
binding components. Open ESB allows you to easily integrate enterprise applicat
ions and web services as
loosely coupled composite applications. This allows you to seamlessly compose and recompose your
composite applications, realizing the benefits of a true Service
Oriented Architecture (SOA).

Open Enterprise Service Bus (OpenESB) ho
sts a set of pluggable component containers, which integrate various types of IT assets.
These pluggable component containers are interconnected with a fast, reliable, in
memory messaging bus called the Normalized
Message Router (NMR) also referred to as t
he JBI Bus. Service containers adapt IT assets to a standard services model, based on XML
message exchange using standardized message exchange patterns (MEP) based on abstract WSDL. This improves interoperability an
allows a mix
match of technologies
from various vendors. When sending and receiving messages outside the JBI environment, the
engine component containers communicate using the in
memory NMR messaging infrastructure and pass messages out to the client
through an appropriate binding component

container. When communication is entirely within the JBI environment, no protocol
conversion, message serialization, or message normalization is necessary because all messages are already normalized and are
standard abstract WSDL format.

Project Goals

and Plans

The overall goal of OpenESB is to create an open
source, world
class set of technologies to enable organizations to create and
participate in global service collaborations. Participating in these collaborations are

a fundamental requirement for businesses across all
markets. In reality, the only reason SOA and its related technologies exist is to enable these global service collaborations.

OpenESB provides an alternative to proprietary, closed
source ESB and SOA pro
ducts. It not only leverages standards, which are
required for global service collaborations, but its architectural approach of separating the variant piece (policy) from the
invariant piece
(business logic) delivers a mandatory separation of concerns to c
reate and participate in global service collaborations. Developers have
the tools and runtime environment to create robust collaborations. Security and network administrators can create and apply p
that allow full participation in service collaborat
ions without sacrificing the organizations security or compliance requirements.

To achieve this overall goal, within Project OpenESB you should see progress toward the following:

Development of a composite application runtime and tool platform

of related plug
in components that provide functional and connectivity capabilities

Development of governance technologies to enable global collaborations.

Project OpenESB also hopes to accomplish the following:

Creation of a community for OpenESB architec
ture that can:


Improve performance, scaling, reliability and other systemic qualities

Creation of a community for creating new plug
in components that can:


Provide a component development framework


Provide a home for development of individual components

eation of a community for tools development related to plug
in components that can:


Provide a tool interoperability framework (around NetBeans 5 initially), and also provide a service unit and service
assembly manipulation tool that integrates into the too
ls framework


Provide a home for development of individual tools

Creation of a community for users of OpenESB for:


Users of individual plug
in components and their tools

If you are interested in participation in Project OpenESB or to get further information

on the vision of the technology or community

contact us


Application Server


allows you to leverage the reliability, scalability, resiliency, deployment, and management capabilities of a leading open
source Java EE application server, GlassFish. The OpenESB runtime is packaged into GlassFish leverages its transactional and
ing capabilities to provide a robust solution for your deployments. Protect your existing investment by reusing the services
your transactional EJB or Web Applications using the Java EE Service Engine. The Java EE Service Engine transparently registe
your EJB or Web Application web service endpoints with the OpenESB runtime thus allowing new services to communicate
seamlessly to your existing EJB or Web Applications.

Composite Application

A Composite Application is a single self
artifact that contains other sub
artifacts, services that make up business logic in a
global service collaboration. Using the design
time tools that come with OpenESB, the user can create Composite Applications that re
purpose and combine existing ERP or l
egacy services orchestrated with new business logic using service
oriented design patterns and
business events with Web 2.0 presentation services without re
writing or replacing. Leverage the power of Web 2.0 presentation
services with Ajax and Java Server

Faces components to create rich user interfaces. Use BPEL to orchestrate services with
transactional and collaborative behavior, be they legacy services, new services, or existing Java, EJB, or Web Applications.
transformation services to leverage exi
sting functionality and create new services. Leverage the Business Activity Manager component
tools and specify Key Performance Indicators (KPI) and handle complex events using Intelligent Event Processing. Create data
warehouses and enterprise data mash
ps using complex extraction, transformation, and loading patterns. Leverage scripting to enable
capabilities into your enterprise mash
ups. Talk to 'silos' and different applications using HTTP, SOAP, REST, File, FTP, SMTP,
SNMP, JMS, and multiple differen
t protocol connector components. Create service collaborations for different vertical markets such as
health care, telecommunications, financial services, insurance, etc. by leveraging the SWIFT, HL7 binding components and a wh
host of other connector c

Composite Application Editor

The Composite Application Editor that comes with OpenESB helps the user 'wire
together' and create new Composite Applications
from derived functionality. It allows a user to repurpose functionality from differen
t services, orchestrate application logic to control
how the composed services interact with each other to produce the new, derived functionality. The Composite Applications thus

created are a composition of rich elements from individual web services or se
lected functionality from within another application, or
entire legacy systems that are exposed as an aggregation of virtualized services. The editor removes the difficulty of wiring

different services together by providing a rich user interface wher
e the user can 're
wire' the internal connections, or create new ones.
This allows the user to focus his efforts on providing rich business functionality in his services and 'wire
together' and/or 'rewire' his


The JBI Bus hosts a set
of pluggable component, which integrate various types of IT assets. These pluggable components are
interconnected with a fast, reliable, in
memory messaging bus called the Normalized Message Router (NMR). These containers adapt
IT assets to a standard serv
ices model, based on XML message exchange using standardized message exchange patterns (MEP) based
on abstract WSDL. This improves interoperability and allows a mix
match of technologies from various vendors. When sending
and receiving messages outside

the JBI environment, the service engine components communicate using the in
memory NMR
messaging infrastructure and pass messages out to the client through an appropriate binding component. When communication is
entirely within the JBI environment, no pro
tocol conversion, message serialization, or message normalization is necessary because all
messages are already normalized and are in standard abstract WSDL format.

In addition, JBI defines a standard way of plugging in third
party components on
fly in
to OpenESB which provides dynamic
installation and deinstallation of component containers. This takes Java EE to the next level by bringing together new plugga
component containers from different vendors, and creates a market where a user could deploy t
he best
breed implementations which
operate without any vendor lock

Service Engines and Binding Components


supports two styles of components. Service Engines provide business logic and transformation services to other components,
as well as consume such services. Binding components provide services external to the OpenESB environment. This can involve
ation protocols (e.g. http) or even services provided by enterprise information systems.

Service Engines and Binding Components can function as service providers, consumers, or both. The distinction between Service

Engines and Binding Components is based o
n sound architectural principals. The separation of business logic from communication
logic reduces implementation complexity and increases flexibility.

Business Logic Units

Business Logical Units are simply the elements that implement certain aspects of the global services collaboration. An exampl
e of a
business logic unit would be a BPEL business process created to implement a eCommerce transaction. That business process may

internal services or an external services (such as an Amazon? S3 service). Business Logic Units can be reused across a number

global service collaborations.

Global Service Collaboration Networks

SOA and ESB vendors offer either a service fabric or a service bus topology for creating applications. These architectural pa
tterns are
adequate enterprise integrations, but break down when producing global service collaborations. Global service collaborat
ions are best
thought of as a network of services. There have been two advances recently that OpenESB leverages or will soon leverage.

Collaboration standards for the Internet and Intranet communication have been established, which is primarily XML over
ttp. Where other ESB vendors ultimately depend on proprietary protocols, to fully implement their solutions, OpenESB
simply leverages widely adopted standards.

High throughput message processing engines allow domains to separate their policy implementation

from their business logic
implementation. We refer to this capability as the Service Gateway. The Service Gateway acts as an agent for all services
within a domain and has the responsibility to protect the domain collaboration risks, represent the domain
to collaborations,
and to enforce domain policy. Though this capability is not available in OpenESB community at this time, we except it to be
available soon.



provides the ability to centrally monitor, manage and administer the distributed runtime system. The administration tools
available both in NetBeans and the Administration Web Console provide the ability to install/uninstall new component containe
rs on
fly and manage their life
cycle. The administration tools also provide the ability to deploy/undeploy Composite Applications and
manage their life
cycle. In addition OpenESB components and Composite Applications allow their runtime
configuration to be
posed and administered dynamically using both NetBeans and the Web Administration Console both in a stand
alone and in a
clustered environment. Message Exchange statistics exposed through these administration tools allow you to get a consolidated

view of
our Enterprise. These administration tools allow the user to query and view metrics, alerts, and errors from the infrastructu
components, composite applications, and the service endpoints and take appropriate action.



Reliable SOA infrastructure

JBossESB is the next generation of EAI

better and without the vendor

characteristics of old. As
such, many of the capabilities mirror those of existing EAI offerings: Business Process Monitoring,
Integrated Development Environment, Human Workflow User Interface, Business Process Management,
Connectors, Transaction Manager,

Security, Application Container, Messaging Service, Metadata
Repository, Naming and Directory Service, Distributed Computing Architecture.

Plus JBossESB is part of an SOI (Service Oriented Infrastructure). However, SOA is not simply a technology
or a prod
uct: it's a style of design, with many aspects (such as architectural, methodological and
organisational) unrelated to the actual technology.

It uses a flexible architecture based on SOA principles such as loose
coupling and asynchronous message

emphasizing an incrementa approach to adopting and deploying an SOI.


support for general notification framework. Transports supported include JMS (JBossMQ, JBoss
Messaging, Oracle AQ and MQSeries), InVm, TCP/IP, email, database or file system.
Messaging 1.4.0GA is now the recommended default JMS implementation.

JMS and SQL transaction integration.

More seamless integration when deployed into JBossAS.

jBPM integration.

BPEL support.

Web Services support.

Improved deployment and
configuration, using a specific ESB server.

Groovy support.

trailblazer example.

many quickstart examples to get you going.

support for data transformations using

Smooks 1.0 or XSLT


and action model to support loose
coupling of interaction steps.

content based routing using


or XPath.

support for registries, using JAX
R and jUDDI out
box. Now supporting the SOA Software
egistry too.

gateways to allow non
ESB aware traffic to flow into the ESB.

graphical configuration editor.

high performance and reliability (in use by a large insurance company for 3 years).