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:
Centralized policy enforcement for authentication, authorization, and throttling.
Centralized auditing and monitoring.
Message screening and schema validation.
Expose legacy systems through standard interfaces.
Expose business functionalities through service orchestration.
Act as a reliable message store for persistence and rate limit matching.
Setting up WSO2 ESB is not a huge/tedious task. In simple steps this is what you need to do:
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.
Start WSO2 ESB. In Windows you can simply run
ESB_HOME/bin/wso2server.batand under Linux you can run
ESB_HOMEpoints 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.
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.
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.jksis the primary key store and
client-truststore.jksis 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:
Use Secure Vault to encrypt all the passwords in the following configuration files:
ESB_HOME/ repository /conf/carbon.xml
ESB_HOME/ repository /conf/axis2/axis2.xml
Change the default ports. By default, WSO2 ESB runs on HTTPS port
9443and HTTP port
9763. Also, WSO2 ESB exposes services over
8280. To change the ports you can update the value of
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.
Kernel level parameters can be fine tuned for optimal performance via the
/etc/sysctl.conffile in Linux. Open
/etc/sysctl.confwith your favorite editor and add the following parameters to it:
net.ipv4.tcp_fin_timeout = 30
fs.file-max = 2097152
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.core.rmem_default = 524288
net.core.wmem_default = 524288
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
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
Under Linux, to change the maximum number of open files allowed for system users, go to
/etc/security/limits.confand configure the following parameters:
soft nofile 4096 hard nofile 65535
The maximum heap size and the maximum perm gen size allocated for WSO2 ESB can be changed by modifying the
ESB_HOME/bin/wso2server.shfile in Linux and the
ESB_HOME/bin/wso2server.batfile 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.
XPathparser optimizes the way
XPathexpressions are being parsed. To enable
XPathin WSO2 ESB, configure the following two parameters in the
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.
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
log4j.logger.org.apache.synapse.transport.nhttp.access=WARN log4j.logger.org.apache.synapse.transport.passthru.access= WARN
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.xmlfile. 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
To optimize the performance of PTT, set the following parameters in the
http.socket.timeout=120000 worker_pool_size_core=400 worker_pool_size_max=500 io_buffer_size=16384
The HTTP-NIO transport performance can be fine tuned by creating an
nhhtp.propertiesfile under the
ESB_HOME/repository/confdirectory, and adding the following configuration parameters:
http.socket.timeout=120000 http.socket.buffer-size=8192 http.tcp.nodelay=1 http.connection.stalecheck=0 # HTTP Sender thread pool parameters snd_t_core=200 snd_t_max=250 snd_alive_sec=5 snd_qlen=-1 snd_io_threads=16 # HTTP Listener thread pool parameters lst_t_core=200 lst_t_max=250 lst_alive_sec=5 lst_qlen=-1 lst_io_threads=16