Enterprise Integration with WSO2 ESB

4.5 (2 reviews total)
By Prabath Siriwardena
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies

About this book

The Enterprise Service Bus (ESB) serves as a key component in most of the enterprise grade deployments. In most cases, the ESB removes point-to-point dependencies in your system to build a highly-scalable, loosely-coupled solution. ESB is a key ingredient to build an SOA infrastructure, but it's not a must. Even with an ESB, if industry best practices and patterns are not followed, users will end up in a mess. This book will teach you the essentials to get started with WSO2 ESB and solve the most commonly-faced integration problems.

The book starts by explaining the need for an ESB and the problems it solves. It will cover the most widely-used enterprise integration patterns, including Content Based Router, Dynamic Router, Splitter, Aggregator, Scatter & Gather, Publish & Subscribe, Detour, Service Chaining, Content Enricher and Message Broker. Learn how WSO2 ESB can bring third-party business messaging systems such as SAP, FIX, and HL7 into the SOA world, as well as how to integrate the Twitter connector into your business messaging flow.

Publication date:
October 2013


Chapter 1. Getting Started

The first part of this chapter will focus on giving a brief introduction to the Enterprise Service Bus (ESB) in general, when to use it and when not to. Next, we will see how to deploy WSO2 ESB in a production environment with optimal settings.

The Enterprise Service Bus (ESB) today serves as a key component in most of the enterprise grade deployments.

An ESB is a middleware solution that enables interoperability among heterogeneous environments using a service-oriented model. An ESB models an application endpoint as a service. The ESB may host the service agent locally, or the service may execute remotely. In both cases, the ESB provides an abstraction layer that virtualizes the service and separates it from infrastructure concerns. The ESB makes the service accessible to other applications via one or more middleware protocols. As a general rule, one of the protocols that an ESB supports is Simple Object Access Protocol (SOAP), but it doesn't require all services to communicate via SOAP. The ESB mediates interactions between service endpoints and enables dissimilar systems to interoperate.

That's how Gartner defines the Enterprise Service Bus, as explained in depth at http://www.gartner.com/id=1405237.

In most cases the ESB removes point-to-point dependencies in your system to build a highly-scalable and loosely coupled solution. But that does not necessarily mean that ESB means SOA. ESB is a key ingredient to build an SOA infrastructure, but it's not a must. Even with an ESB, if not followed in industry's best practices and patterns, you will end up with a mess. Take ESB just as a tool to build an SOA in your enterprise and do not try to design an SOA around an ESB. Let your needs ask for an ESB, but do not start from it.

WSO2 ESB is an open source Enterprise Service Bus released under the business friendly Apache 2.0 license. It has support for most of the Enterprise Integration Patterns (EIP) highlighted by Gregor Hohpe and Bobby Woolf in their famous book, which laid the cornerstone for many of the ESBs out there today. You can read more about EIPs from http://www.eaipatterns.com. The complete catalogue of enterprise integration patterns supported by WSO2 ESB can be found at http://docs.wso2.org/wiki/display/IntegrationPatterns/Enterprise+Integration+Patterns+with+WSO2+ESB.

In most of the enterprise grade production deployments, ESB acts as a Service Gateway. The Service Gateway is a centralized access point where heterogeneous service providers meet heterogeneous service clients.

We would expect the following functionalities from a Service Gateway but not limited. In the sections to follow, we'll find out how capable WSO2 ESB is to cater for these requirements:

  • Protocol switching.

  • Message transformations.

  • Centralized policy enforcement for authentication, authorization, and throttling.

  • Centralized auditing and monitoring.

  • Message screening and schema validation.

  • Message routing.

  • Expose legacy systems through standard interfaces.

  • Expose business functionalities through service orchestration.

  • Handle versioning.

  • Act as a reliable message store for persistence and rate limit matching.


Setting up WSO2 ESB for production use (Simple)

This recipe will guide you through the process to setup WSO2 ESB from scratch in your production deployment and fine-tune it for optimal performance.

Getting ready

Setting up WSO2 ESB is not a huge/tedious task. In simple steps this is what you need to do:

  1. Download the latest version of WSO2 ESB from http://wso2.com/products/enterprise-service-bus/. As of this writing the latest is 4.8.0 and all the samples presented throughout the book are tested with that. In case version 4.8.0 is not yet available at the above provided link, you can download the milestone 4 build from https://svn.wso2.org/repos/wso2/people/prabath/esb/packtbook/wso2esb-4.8.0.zip.


    You can run WSO2 ESB on Microsoft Windows, Linux (Ubuntu, Fedora, Gentoo, SUSE, and Debian, and so on), Oracle Solaris and Mac OS X with a JDK 1.6.x runtime. The recommended JDK is Oracle JDK 1.6_26+.

  2. Set JAVA_HOME environment variable. You need to point JAVA_HOME to the root directory where you have installed JDK in your local machine.

  3. Start WSO2 ESB. In Windows you can simply run ESB_HOME/bin/wso2server.bat and under Linux you can run ESB_HOME/bin/wso2server.sh. ESB_HOME points here to the local directory that you unzipped, the WSO2 ESB distribution.


    Step-by-step instructions to set up WSO2 ESB on Windows can be found at http://docs.wso2.org/wiki/display/ESB480/Installing+on+Windows.

    Step-by-step instructions to set up WSO2 ESB on Linux can be found at http://docs.wso2.org/wiki/display/ESB480/Installing+on+Linux.

How to do it...

Once we have the initial setup completed we can start tightening the security of the WSO2 ESB. The following steps list some of the recommendations for a secured deployment. If you are not worried about production deployment guidelines yet, then you can skip the rest and move to the next section.

  1. Change the key stores. You can find two key stores (.jks) that ship with WSO2 ESB at ESB_HOME/repository/resources/security/. Out of those two, wso2carbon.jks is the primary key store and client-truststore.jks is the trust store, where you will have the public certificates of trusted Certificate Authorities (CAs). Once you change the key stores, you need to update the corresponding entries in the following configuration files:

    • ESB_HOME/repository/conf/tomcat/catalina-server.xml

    • ESB_HOME/repository/conf/carbon.xml

    • ESB_HOME/repository/conf/axis2/axis2.xml

  2. Use Secure Vault to encrypt all the passwords in the following configuration files:

    • ESB_HOME/repository/conf/user-mgt.xml

    • ESB_HOME/ repository /conf/carbon.xml

    • ESB_HOME/ repository /conf/axis2/axis2.xml

    • ESB_HOME/repository/conf/datasources/master-datasources.xml

    • ESB_HOME/repository/conf/tomcat/catalina-server.xml

  3. Change the default ports. By default, WSO2 ESB runs on HTTPS port 9443 and HTTP port 9763. Also, WSO2 ESB exposes services over 8243 and 8280. To change the ports you can update the value of <Offset> at ESB_HOME/repository/conf/carbon.xml

  4. If you are deploying WSO2 ESB in a Demilitarized Zone (DMZ) make sure you remove all the UI components from it. You can remove all the UI features by logging in to the WSO2 ESB and then go to Configure | Features. If you still prefer to configure ESB through a UI, then you can deploy another ESB instance inside the LAN and connect the UI of that ESB to the ESB runtime deployed inside DMZ.

Now, we can start fine tuning WSO2 ESB for the highest performance. It performs at its best with Linux, so the underlying parameters related to that are as follows:

  1. Kernel level parameters can be fine tuned for optimal performance via the /etc/sysctl.conf file in Linux. Open /etc/sysctl.conf with your favorite editor and add the following parameters to it:

    • net.ipv4.tcp_fin_timeout = 30

      Specifies the time in seconds TCP takes to wait for the final FIN, before the socket is closed.

    • fs.file-max = 2097152

      Specifies the maximum number of concurrently open file descriptors in the system.

    • net.ipv4.tcp_tw_reuse = 1

      By default, the value of this parameter is 0. When set to 1, the TIME-WAIT sockets for new connections can be reused across the system.

    • net.ipv4.tcp_tw_recycle = 1

      Once net.ipv4.tcp_tw_reuse is set to 1, to enable fast recycling of TIME-WAIT socket status, we need to set the above to 1.

    • net.core.rmem_default = 524288

      Specifies the default operating system receive buffer size for all types of connections.

    • net.core.wmem_default = 524288

      Specifies the default operating system send buffer size for all types of connections.

    • net.core.rmem_max = 67108864

      Specifies the maximum operating system receive buffer size for all types of connections.

    • net.core.wmem_max = 67108864

      Specifies the maximum operating system send buffer size for all types of connections.

    • net.ipv4.tcp_rmem = 4096 87380 16777216

      The first value specifies the minimum receive buffer for each TCP connection. The second value is the default receive buffer allocated for each TCP socket. The third specifies the maximum receive buffer that can be allocated for a TCP socket.

    • net.ipv4.tcp_wmem = 4096 65536 16777216

      The first value specifies the minimum send buffer for each TCP connection. The second value is the default send buffer allocated for each TCP socket. The third specifies the maximum send buffer that can be allocated for a TCP socket.

    • net.ipv4.ip_local_port_range = 1024 65535

      Once specified, it will increase the IP port limit of the system.

  2. Under Linux, to change the maximum number of open files allowed for system users, go to /etc/security/limits.conf and configure the following parameters:

    soft nofile 4096
    hard nofile 65535
  3. The maximum heap size and the maximum perm gen size allocated for WSO2 ESB can be changed by modifying the ESB_HOME/bin/wso2server.sh file in Linux and the ESB_HOME/bin/wso2server.bat file in Windows.

    The default setting for WSO2 ESB 4.8.0 is: -Xms256m -Xmx512m -XX:MaxPermSize=256m

    • -Xms: Minimum heap size

    • -Xmx: Maximum heap size

    • -XX:MaxPermSize: Maximum perm gen size.

  4. The streaming XPath parser optimizes the way XPath expressions are being parsed. To enable XPath in WSO2 ESB, configure the following two parameters in the ESB_HOME/repository/conf/synapse.properties file.



    To learn more about the streaming XPath parser for WSO2 ESB, go to http://wso2.com/library/articles/2013/01/streaming-xpath-parser-wso2-esb.

  5. The access logs can be used to log requests and responses passing through WSO2 ESB. For optimal performance, we can disable access logs by setting the following values in the ESB_HOME/repository/conf/log4j.properties file:

    log4j.logger.org.apache.synapse.transport.nhttp.access=WARN log4j.logger.org.apache.synapse.transport.passthru.access= WARN
  6. WSO2 ESB uses Pass Thru Transport (PTT) as the default transport. If we want to use the HTTP-NIO transport, comment out PTT and un-comment the HTTP-NIO transport in the ESB_HOME/repository/conf/axis2/axis2.xml file. Also, a preconfigured file for HTTP-NIO transport ships with the product, available at ESB_HOME/repository/conf/axis2/axis2_nhttp.xml. You can simply rename it to axis2.xml.

  7. To optimize the performance of PTT, set the following parameters in the ESB_HOME/repository/conf/passthru-http.properties file:

  8. The HTTP-NIO transport performance can be fine tuned by creating an nhhtp.properties file under the ESB_HOME/repository/conf directory, and adding the following configuration parameters:

    # HTTP Sender thread pool parameters
    # HTTP Listener thread pool parameters	


Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

About the Author

  • Prabath Siriwardena

    Prabath Siriwardena is the director of Security Architecture at WSO2 Inc., a company that produces a wide variety of open source software from data to screen. He is a member of OASIS Identity Metasystem Interoperability (IMI) TC, OASIS eXtensible Access Control Markup Language (XACML) TC, OASIS Security Services (SAML) TC, OASIS Identity in the Cloud TC, and OASIS Cloud Authorization (CloudAuthZ) TC. Prabath is also a member of PMC Apache Axis and has spoken at numerous international conferences, including OSCON, ApacheCon, WSO2Con, EIC, IDentity Next, and OSDC. He has more than 10 years of industry experience and has worked with many Fortune 100 companies.

    Browse publications by this author

Latest Reviews

(2 reviews total)
compra y descarga inmediata. siempre claros en el proceso y también cuando se quiere enviar al dispositivo kindle te indican que depende de la conversión de amazon :)
Book Title
Access this book and the full library for FREE
Access now