FREE AND OPEN SOURCE SOFTWARE CONFERENCE 2007 1 Enterprise Service Bus Falko Menge Abstract— This paper is a comprehensive introduction to the custom built, acquired from a third party or parts of legacyEnterprise Service Bus (ESB), which is a new type of integration systems, e.g. a company may have three installations of SAP,infrastructure. Therefore it gives a detailed introduction into 30 different websites and countless individual solutions inthe background of Enterprise Application Integration (EAI) andexplains Message-Oriented Middleware (MOM) and Service- different departments. These applications should be able toOriented Architecture (SOA) which are the technologies the communicate and exchange data with each other in order toEnterprise Service Bus evolved out of. After discussing core ESB work together for the business of the company. The problem isconcepts and typical features, the open source ESB solution Mule not the number of applications itself. There are good reasonswill be presented. An example application will demonstrate how for having combinations of many different applications. First,different features of an ESB are used. it is nearly impossible to develop one huge application which Index Terms— Enterprise Service Bus (ESB), Service-Oriented performs all business functions of a typical enterprise becauseArchitecture (SOA), Web Services, Enterprise Application Inte- there are far too many requirements. The second reason is thatgration (EAI), Message-Oriented Middleware (MOM). running multiple applications gives IT managers ﬂexibility to select solutions which are the best for their particular purpose. I. I NTRODUCTION That means that integration is not a temporary problem which currently has to be solved. It is a fundamental requirement thatT HE Enterprise Service Bus (ESB) is a relatively young term in the software industry. It is an exciting topicbecause the most interesting question is the ﬁrst, one would enterprises will also have in the future. The task, commonly called Enterprise Application Integration (EAI), becomes evenask: What is an Enterprise Service Bus? more interesting if applications of external business partners The question is hard to answer since there is no general are to be integrated. Furthermore the selection of applicationsconsensus about a common deﬁnition of the term. There are is not ﬁxed. Applications may be exchanged or new applica-many discussions on which features have to be included or tions may be deployed so that the integration infrastructurewhich technologies should be used when realizing an Enter- has to be able to handle new scenarios.prise Service Bus. In contrast to that there are many vendors inthe market who state that their solutions are Enterprise Service A. Message-Oriented MiddlewareBuses or base on Enterprise Service Bus principles. There are The traditional solution for Enterprise Application Integra-vendors who are specialized in developing Enterprise Service tion is to use Message-Oriented Middleware (MOM). ThatBus products like Cape Clear Software, Fiorano Software or means that asynchronous messaging is used to decouple theSonic Software and most of the big vendors of integration applications from each other. MOM products are typically builtmiddleware products like Oracle, BEA Systems, IONA Tech- around a central message queue system often called messagenologies, Sun Microsystems or IBM have Enterprise Service broker. All applications are connected to the message brokerBus solutions in their product portfolios. using a uniﬁed interface for sending and receiving messages. This uncommon situation originates from the term Enter-prise Service Bus being originally coined by analysts fromGartner in 2002. The need for a new form of infrastructurewhich combines Message-Oriented Middleware (MOM), webservices, transformation and routing intelligence as a backbonefor Service-Oriented Architecture (SOA) was identiﬁed anddifferent approaches have been tried to realize that idea. Someproducts evolved from web services infrastructure solutionsor lightweight messaging products, while others evolved fromEAI suites having added support for SOA. Fig. 1. Simpliﬁed architecture of a Message-Oriented Middleware. Although there are multiple deﬁnitions and approaches, thecentral ideas are similar to each other and will be explainedand demonstrated in this paper. The message broker is able to store the messages so that sender and receiver do not need to be connected at the same time. Within this middleware layer messages can be routed II. BACKGROUND AND D OMAIN which makes it possible to deliver a single message to more In order to understand the beneﬁts of an Enterprise Service than one recipient. Furthermore messages cold be transformedBus one has to examine the infrastructure requirements that by the message broker to ﬁt the requirements of the receivinglarge enterprises have. A typical scenario is that an enterprise application. The transformation facilities allow the connectedruns hundreds or thousands of applications, which could be applications to use their own native message formats.
2 FREE AND OPEN SOURCE SOFTWARE CONFERENCE 2007 A big problem of MOM solutions is that they often use is due to be a slow process. That implies that an integrationproprietary protocols and platform speciﬁc interfaces and de- infrastructure can not be purely service-based.ployments. This leads to a total dependency of the applications Today enterprises need powerful integration solutions buton the infrastructure and causes interoperability problems with they want them to be based on open standards and to supportMOM products of alternative vendors. As a result islands of Service-Oriented Architecture. Exactly those requirements ledMOM based infrastructures can often be found. to the idea of an Enterprise Service Bus. III. W HAT IS AN E NTERPRISE S ERVICE B US ?B. Service-Oriented Architecture An Enterprise Service Bus is an open standards, message- Service-Oriented Architecture (SOA) is an architecture con- based, distributed integration infrastructure that provides rout-cept which deﬁnes that applications provide their business ing, invocation and mediation services to facilitate the inter-functionality in the form of reusable services. A service in actions of disparate distributed applications and services in athat context is a self-contained and stateless business function secure and reliable manner.which is accessible through a standardized, implementation- ESBs are usually realized through service containers dis-neutral interface. Services are used by other applications which tributed across a networked environment. These containerscould also be implementations of services. With this approach host integration services like routers, transformers, applicationcomplex business processes are implemented through combi- adapters or MOM bridges and provide them with a broadnation of several services. This is called service orchestration. range of communication facilities. In today’s ESB solutionsFigure 2 shows the typical scenario of a SOA application. the messaging infrastructure is typically built on top of JMS-Service providers register their services to a central naming based1 middleware systems which guarantee message deliv-service. A consumer application can use this naming service ery. Applications are connected to the bus using applicationto discover available services and retrieve information on how adapters or one of the supported messaging mechanisms. Into connect to a particular service provider. Then the consumer order to support SOA the ESB service containers have to in-application is able to obtain a service description which deﬁnes clude all important web service technologies. The componentshow the service can be used. of the ESB as well as the mechanisms for connecting resources must be based on open standards to ensure interoperability and protection of investment.Fig. 2. A typical Service-Oriented Architecture. SOA can be implemented using any service-based technol-ogy. Typically web service technologies like SOAP or RESTare used. Fig. 3. A simple ESB scenario. Although not depicted here, a container can SOA allows complex enterprise applications and end-to-end host multiple services and components.business processes to be composed from these services, evenwhen the providers of those services are applications hosted The ESB must coordinate the interactions of the variouson disparate operating system platforms, written in different resources and provide transactional support. A general goal isprogramming languages or based on separate data models. to provide messaging and integration without writing code.This ﬂexible composition supports the fundamental goals of Therefore generic components are provided which can bebusiness integration, which are linking business systems across conﬁgured to realize a desired scenario.the enterprise and extending business services to customers An ESB is an ideal backbone for implementing serviceand trading partners. oriented architectures because it provides universal mechanism The adoption of SOA in business-critical applications is oc- 1 Java Messaging Service (JMS) speciﬁes a standardized API for reliablecurring only incrementally. Refactoring, wrappering or replac- messaging. JMS is widely supported in messaging middleware systems anding legacy applications with new standards-aware equivalents is developed as JSR 914 
FALKO MENGE: ENTERPRISE SERVICE BUS 3to interconnect all the services required in the composed distilled from the individual messages to the conﬁgured des-business solution without compromising security, reliability, tination. A resequencer is a router which collects related butperformance and scalability. out-of-sequence messages and forwards them in the correct order. For the resequencer to function, each message needs a IV. T YPICAL ESB FEATURES unique sequence number.A. Invocation The different routers can be combined to create complex message ﬂows. All routers can be implemented as so called Invocation is the ability of an ESB to send requests and dynamic routers. That means the router is able to reconﬁgurereceive responses from integration services and integrated its routing rules based on special conﬁguration messagesresources. That means that an ESB has to support the standards which can be sent by participating destinations.for web service communication including SOAP , theWeb Services Description Language (WSDL) , UniversalDescription, Discovery and Integration (UDDI)  and the C. MediationWS-* family of standards. Furthermore the Java MessageService (JMS) API  and the J2EE Connector Architecture Mediation refers to all transformations or translations be-(JCA)  should be implemented for integration with MOM tween disparate resources including transport protocol, mes-systems and application servers. Of course an ESB must also sage format and message content. These transformations arebe able to handle the underlying protocols like TCP, UDP, very important for integration because applications rarelyHTTP or SSL. Additional communication mechanisms could agree on a common data format. Again XSL and XPathbe JBI, RMI, JDBC, SMTP, POP3, FTP or XMPP. are powerful tools for working with XML messages. Those standards allow an ESB to provide generic XML transformer components which are conﬁgured through an XSL stylesheet.B. Routing More complex transformers may invoke other resources which Routing is the ability to decide the destination of a message are connected to the bus e.g. a database in order to augmentduring its transport. Routing services are an essential feature additional information to a message. Special forms of trans-of an ESB because they allow to decouple the source of a formation services are normalizers, content enrichers, contentmessage from the ultimate destination. ﬁlters or envelope wrappers. To enable routing and other communication features dis-parate messaging endpoints have to be referenced. The com-mon standard for addressing is to use Uniform Resource D. AdaptersIdentiﬁers (URIs). Additionally WS-Addressing  may be Many ESB solutions provide a whole range of applicationimplemented in ESB solutions to describe web service end- adapters. This can be adapters for popular application packagespoints in a transport-neutral manner. such as Enterprise Resource Planning (ERP), Supply Chain The decision to which destination a message is sent can Management (SCM) and Customer Relationship Managementbe made based on several conditions which leads to different (CRM). Those adapters connect to the native transaction inter-types of routers. faces, APIs and data structures that these business applications A content-based router inspects the content of messages expose and present a standard interface, which makes it easyand forwards them to different channels depending on the to reuse business logic and data. Typically most adapters ofcontent of the message. This allows a sender to send messages a particular vendor operate the same way which minimizeswithout specifying an exact destination. For XML messages the skills required to use each connected system. Usingcontent-based routing can be implemented using the XML prefabricated adapters reduces the work required to integratePath Language (XPath)  for addressing parts of a message applications into a Service-Oriented Architecture.which are needed for the routing decision. A special form of acontent-based router is a message ﬁlter. It forwards a messageonly if the content matches a certain criterion. Otherwise, the E. Securitymessage will be deleted. Of course there are integration scenarios where one message An enterprise class integration infrastructure has to provideis to be sent to multiple recipients. This could be achieved by secure messaging. That means for an ESB to be able to encryptusing a recipient list router which either computes a list of and decrypt the content of messages, handle authenticationdestinations or has a static conﬁguration for multiple receivers. and access control for messaging endpoints and to use secureIf messages are composed of multiple parts, a splitter may persistence mechanisms.be used to split a single message into a series of individualmessages. A splitter for XML messages may utilize XPath F. Managementfor addressing the parts and transformations based on theExtensible Stylesheet Language (XSL)  for generating An ESB has to provide audit and logging facilities forseparate messages. monitoring infrastructure and integration scenario and possibly The opposite of a splitter is an aggregator which collects also for controlling process execution. There must be a centraland stores individual messages. If it receives a complete set mechanism for conﬁguration and administration of the bus.of related messages, the aggregator sends a single message Additionally tools for usage metering may be included.
4 FREE AND OPEN SOURCE SOFTWARE CONFERENCE 2007G. Process Orchestration A typical Mule application consists of multiple Mule in- An Enterprise Service Bus may include an engine to execute stances distributed across the network which can be intercon-business processes described with the Web Services Business nected using any of the supported communication mechanismsProcess Execution Language (WS-BPEL) . This engine or even a combination of them. Several UMOs can workcontrolled by the process description then coordinates the together in oder to realize a complex message ﬂow amongcollaboration of the services connected to the bus. different external applications.H. Complex Event Processing An asynchronous message can be seen as an event especiallywhen using a publish-subscribe channel. Thus an ESB mayinclude mechanisms for event interpretation, event correlationand event pattern matching which enable event-driven archi-tectures.I. Integration Tooling For professional development with an ESB graphicaldesign-time tooling as well as deployment and testing tool Fig. 5. A typical Mule application. [source: ]should be available. The Mule container provides all integration services which V. M ULE : AN OPEN SOURCE ESB are essential to an ESB. That includes support for transactions, Mule is a lightweight open source messaging platform based transformations, routing, logging, auditing, management, se-on ESB concepts. The central component of Mule is a service curity, event processing and even process orchestration usingcontainer for so called Universal Message Objects (UMOs). WS-BPEL. Mule can run standalone or integrated with anotherThis container which is a highly distributable object broker is containers, e.g. Spring, PicoContainer or Plexus. Therefore itable to handle a rich variety of communication mechanisms separates object construction from management so that serviceincluding JMS, SOAP, REST, HTTP, FTP, TCP, UDP, SSL, objects can be constructed by other containers. Mule avoidsXMPP, SMTP, POP3, IMAP, JDBC, RMI and others to come. to reimplement communication technologies and instead uses stable and widely-accepted implementations, e.g. the Axis and Glue SOAP stacks. The simple integration scenario in ﬁgure 6 shows the message ﬂow between two applications through a UMO com- ponent. A message receiver listens on the incoming endpoint for a message from the sending application. The connector handles the particular transport mechanism and after that a transformer may transform the message, e.g. into a Java object. The so called inbound router of the involved UMO may be a message ﬁlter, aggregator or resequencer. The UMO may perform some business logic on the message and then the outbound router which could be a content-based router, message ﬁlter, splitter or recipient list forwards the message to one or more transport providers which again consist of a transformer, connector and in the outgoing case a message dispatcher. The message dispatcher sends the message to the receiving application. Mule is designed for fast development of distributed service networks. Therefore it is an ESB server which is highlyFig. 4. Simpliﬁed view of a Mule instance. [source: ] scalable, lightweight, fast and simple to adopt. Mule allows smaller projects to leverage enterprise level service architec- The Universal Message Objects are plain old Java objects tures, especially when resources, development cost and TTMwhich can transparently use the communication facilities of need to be kept to a minimum.the container trough a generic message endpoint interface. Asshown in ﬁgure 4 they are able to connect to external applica-tions, other UMOs or other Mule instances. This uniﬁed and VI. A N ESB E XAMPLE A PPLICATION WITH M ULEtechnology independent method for interacting with disparate An important principle of an ESB is to use as muchresources makes it very easy to use UMOs for integrating declaration and conﬁguration as possible and avoid writingapplications with each other or implementing own application code. Thus the most important artifact of a mule applicationadapters. is its XML conﬁguration ﬁle in which the connectors, routers,
FALKO MENGE: ENTERPRISE SERVICE BUS 5Fig. 6. Integration of two applications with Mule. [source: ]transformers, message endpoints and UMOs are declared. The <connector name="jmsConnector"communication mechanisms actually used by and application className="org.mule.providers.jms.JmsConnector"> <properties>are simply conﬁgured through the endpoint URIs. In addition <property name="connectionFactoryJndiName"to that only UMOs and maybe own object transformers or value="ConnectionFactory"/>routers have to be programmed. <property name="jndiInitialFactory" value= The sample application which will be discussed in this "org.activemq.jndi.ActiveMQInitialContextFactory"section is a very popular example taken from the Enterprise />Integration Patterns book . The example is often used to <property name="specification" value="1.1"/> <map name="jndiProviderProperties">demonstrate features of messaging systems and so Ross Mason <property name="brokerURL"implemented the application in different ﬂavors for Mule. The value="tcp://localhost:61616"/>version shown here uses an ESB architecture and can be </map> </properties>obtained from the mule website . </connector> At the beginning the Client application makes a request sending a CustomerQuoteRequest message to the LoanBroker via a RESTful web service. The LoanBroker which is a UMO creates a LoanQuoteRequest message which is the common message format on the bus. The following part of the conﬁguration shows how different message endpoints are attached to the LoanBroaker UMO: <mule-descriptor name="LoanBroker" implementation= "org.mule.samples.loanbroker.esb.LoanBroker "> <inbound-router> <endpointFig. 7. Mule example application: A loan broker acting as intermediary for address="LoanBrokerRequestsREST"a consumer talking to banks in order to get a loan quote. [source: ] transformers="RestRequestToCustomerRequest"/> <endpoint The usage scenario is a customer who wants to obtain a loan address="LoanBrokerRequests"/> </inbound-router>quote. Therefore he wants to compare offers from differentbanks. A loan broker is used to communicate with the banks <outbound-router>and send the best offer back to the customer. <router className= "org.mule.routing.outbound.OutboundPassThroughRouter"> <endpoint address="CreditAgencyGateway"/> </router> </outbound-router> <response-router timeout="1000000"> <endpoint address="LoanQuotes"/> <router className= "org.mule.samples.loanbroker.esb .routers.BankQuotesResponseAggregator" /> </response-router> </mule-descriptor> Mule sends the message to the so called Credit AgencyFig. 8. Mule example application: Design of the application. [source: ] Gateway via JMS. The Gateway is an envelope wrapper which marshals the request and invokes a CreditAgency EJB. A As seen in ﬁgure 9 the sample application uses a JMS prefabricated message enricher component called Reﬂection-message broker to connect the different components on the MessageBuilder automatically attaches a CreditProﬁle to thebus, which is coﬁgured through the following connector LoanQuoteRequest message. Then Mule sends the Messagedeklaration: to the Lender Gateway via JMS. This Gateway uses the VM transport to invoke the Lender Application which is a simple
6 FREE AND OPEN SOURCE SOFTWARE CONFERENCE 2007Fig. 9. Mule example application: LoanBroker ESB. [source: ]Java Bean. Again Mule forwards the message via JMS - now  Cape Clear’s Enterprise Service Bus (ESB), Whitepaper Cape Clearto the Banking Gateway. The Banking Gateway realizes the Software, May 2005.  Principles of BPEL, Orchestration, and the ESB, Whitepaper CapeScatter-Gather integration pattern . Based on a recipient Clear Software, 2004.list a router forwards a request via SOAP to several bank  Bruce Silver Enterprise Service Bus Technology for Real-World Solutionsweb services. The response messages are collected by an Bruce Silver Associates, August 2004.  Ofﬁcial website of the Mule project.aggregator speciﬁed in the ReplyTo address provided by the http://mule.codehaus.orgBanking Gateway. The ResponseRouter on the LoanBroker  Web Services Business Process Execution Language (WS-BPEL) VersionUMO receives the responses. Finally the LoanBroker selects 2.0 OASIS, Decmber 21, 2005. http://www.oasis-open.org/committees/uddi-spec/doc/spec/v3/uddi-the lowest quote received for the request and returns it to the v3.0.2-20041019.htmclient.  JSR 914: Java Message Service (JMS) API http://www.jcp.org/en/jsr/detail?id=914  JSR 112: J2EE Connector Architecture 1.5 VII. C ONCLUSION http://www.jcp.org/en/jsr/detail?id=112  SOAP Version 1.2 speciﬁcation, W3C Recommendation World Wide An Enterprise Service Bus (ESB) is a message based, Web Consortium (W3C), June 24, 2003.distributed integration solution which provides integration http://www.w3.org/TR/soap/services. Basic integration services are routing, invocation,  Web Services Description Language (WSDL) 1.1, W3C Note World Wide Web Consortium (W3C), March 15, 2001.mediation, support for transactions, logging, auditing, man- http://www.w3.org/TR/wsdl/agement and security services. Furthermore event processing  Universal Description, Discovery and Integration v3.0.2 (UDDI)and process orchestration may be supported by an ESB. OASIS, Oktober 19, 2004. http://www.oasis-open.org/committees/uddi-spec/doc/spec/v3/uddi- Today an Enterprise Service Bus is the most popular infras- v3.0.2-20041019.htmtructure for implementing Service-Oriented Architectures.  Web Services Addressing (WS-Addressing), W3C Member Submission Mule as a light-weight open source ESB includes the World Wide Web Consortium (W3C), August 10, 2004. http://www.w3.org/Submission/ws-addressing/most important features and is an ideal entry point for ESB  Extensible Stylesheet Language (XSL) Version 1.1, W3C Candidateadoption. Recommendation World Wide Web Consortium (W3C), February 20, 2006. http://www.w3.org/TR/xsl11/ R EFERENCES  XML Path Language (XPath), W3C Recommendation World Wide Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns: Design- Web Consortium (W3C), November 16, 1999. ing, Building and Deploying Messaging Solutions Pearson Education, http://www.w3.org/Submission/ws-addressing/ Inc., 2004. Architectural Overview for Enterprise Integration, Version 1.0 Cape Clear Software, March 2003. Dirk Krafzig, Karl Banke and Dirk Slama, Enterprise SOA: Service- Oriented Architecture Best Practices Prentice Hall PTR, 2004. Tony Baer, The road to SOA CBR Research, 2006. David A. Chappell, Enterprise Service Bus O’Reilly, 2004. Mike Gilpin and Ken Vollmer, The Forrester Wave: Enterprise Service Bus, Q4 2005 Forrester Research, Inc., November 15, 2005.