This article provides answers to most commonly asked questions regarding WSO2 ESB, its underlying Carbon framework, ESB deployment and configuration.
WSO2 ESB is a fast, lightweight, open source Enterprise Service Bus implementation. It supports message routing, inter-mediation, transformation, logging, load balancing, fail over routing, task scheduling, eventing and much more.
WSO2 ESB is fast and able to handle thousands of concurrent connections with constant memory usage. It comes with a rich set of mediators to support almost any integration scenario out of the box. It is also easily extensible and highly customizable. The feature rich admin console makes it so easy to configure, control and monitor the ESB runtime.
It is released under Apache Software License Version 2.0.
WSO2 ESB is distributed completely free and all the distribution packs can be downloaded from the WSO2 Oxygen Tank. WSO2 ESB can be downloaded as a binary distribution or a source distribution and if required one can even checkout the complete source code from the WSO2 SVN repository.
Yes, several rounds of performance comparison has been carried out and the results are available in WSO2 Oxygen Tank
We are committed to ensuring that your enterprise middleware deployment is completely supported from evaluation to production. Our unique approach ensures that all support leverages our open development methodology and is provided by the very same engineers who build the technology. For more details and to take advantage of this unique opportunity please visit WSO2 Support.
Not only you are allowed, but it is encouraged. You can start by subscribing to carbon-dev@wso2.org and architecture@wso2.org mailing lists. Feel free to provide ideas, feed back and help us make our code better. You can also report bugs on our issue tracker and you can even submit patches. Visit WSO2 Oxygen Tank for more information about our mailig lists.
WSO2 ESB is built on top of WSO2 Carbon, an OSGi based components framework for SOA. It uses Apache Synapse as the underlying mediation engine. Java is the primary programming language used to develop WSO2 ESB.
The mediation core of WSO2 ESB is designed to be completely asynchronous, non-blocking and streaming. It comes with a non-blocking HTTP transport adapter based on Apache HTTP Core-NIO which is capable of handling a large number of concurrent connections. WSO2 ESB also uses Apache AXIOM, a StAX based XML infoset model, to process XML and SOAP. This enables WSO2 ESB to stream messages through the mediation engine without having to invoke slow XML processing routines for each and every message.
Yes, it supports clustered deployment. WSO2 ESB uses the Apache Axis2 clustering framework to support the following two clustering schemes:
You can deploy any third party jar into the repository/components/lib directory. You also need to restart the server for the newly deployed jars to be picked up by the server runtime. WSO2 ESB will convert any jar files copied into the above location into OSGi bundles. These OSGi bundles are placed in the repository/components/dropins directory.
Yes, you can extend the management console easily by writing a custom UI component.
Yes you can. You can connect WSO2 ESB with any external user store implementation. The user store could be LDAP based, JDBC based or a custom developed user store. Please refer user core documentation for more details.
Yes, it does with both. WSO2 ESB can be easily configured to bridge Java services with .NET clients and .NET services with Java clients.
Yes, it does
Yes you can. Login to the ESB management console and browse to the Feature Manager. Open the 'Installed Features' tab. From here you can uninstall any unwanted features.
Yes, WSO2 ESB comes with a UI framework which supports i18n (internationalization) which lets you to use a language of your choice for the management console.
A proxy service is a virtual service hosted on the ESB. It can accept requests from service clients, just like a real Web Service. A proxy service can process requests and forward them to an actual Web Service (back end service) to be further processed. The responses coming back from the back end service can be routed back to the original client. Proxy services are mostly used to expose an existing service over a different transport, format or QoS configuration.
Yes it does. It has support for distributed transaction, local JMS transactions and distributed JMS transactions.
Yes it does. You can use WSO2 ESB in an Access point.
In version 3.0.1 you can place your non-OSGi custom mediators and class mediators in $ESB_HOME/repository/components/mediators and OSGi bundles in $ESB_HOME/repository/components/dropins.
WSO2 ESB reads its mediation configuration from a set of XML files located at repository/conf/synapse-config directory. XML files are written in the Synapse configuration language. Any changes done to the configuration through the UI are saved back to the configuration files. (Configuration is also written to the registry by default)
Yes you can. The necessary steps are given in the ESB administrator guide.
A mediator is the basic message processing unit in the ESB. A mediator can take a message, carry out some predefined actions on it and output the modified message. WSO2 ESB ships with a range of mediators capable of carrying out various tasks on input messages.
A sequence is an ordered list of mediators (a mediator chain). When a sequence is given a message, it will go through all the mediators in the sequence. A sequence can also handover messages to other sequences.
Endpoint is a target or collection of targets that a message can deliver.
Yes. Endpoints can do error handling. User can configure the behavior of an endpoints when it faced to a erroneous situation. You can find detailed article about endpoint error handling here.
Local entries can be used to hold various configuration elements required by sequences and proxy services. Usually they are used to hold WSDLs, XSDs, XSLT files etc. A local entry can contain XML content as well as plain text content. A local entry can be configured to load content from a remote file too.
To refer to a sequence named foo use the sequence mediator as follows:
<sequence key="foo"/>
You can also refer to dynamic sequences saved in the registry by specifying the registry key to the sequence resource as follows:
<sequence key="gov:/dev/sequences/foo"/>
The above sequence mediator will load the sequence configuration from the resource at /dev/sequences/foo in the governance registry.
Dynamic endpoints and sequences are just XML configuration bits saved in the registry. These configurations are loaded to the mediation configuration at runtime. Once loaded they will be cached for a specified duration in the memory. Once the cache is expired it will be loaded again from the registry. Therefore changes done to dynamic sequences and endpoints at runtime will take effect once the ESB reloads them after a cache timeout.
To use dynamic sequences and endpoints the mediation registry must be included in the mediation configuration as follows:
<sequence key="foo"/> <registry xmlns="http://ws.apache.org/ns/synapse" provider="org.wso2.carbon.mediation.registry.WSO2Registry"> <parameter name="cachableDuration">15000</parameter> </registry>
This configuration can be found in a file named registry.xml in the repository/conf/synapse-config directory by default. Note how the cache duration is set to 15000 ms (15s). This duration can be reduced or extended as necessary by editing the registry.xml file or through the configuration source editor in the UI.
If you want to change the endpoint dynamically per each message, you can use a header mediator to calculate the new 'To' address.
<header name="To" expression="XPath to create the address dynamically"/>
WSO2 ESB does not support dynamic proxy services. But a proxy service may use a dynamic endpoint as the target endpoint and dynamic sequences as the in sequence and the out sequence. This effectively makes the entire proxy service dynamic.
You have two options. One option is to use dbreport and dblookup mediators to persist the message into a database and lookup it later from the database. The other option is to use JMS transport in which you can use a JMS broker to persist the message.
If the dynamic sequences are loaded to the memory at least once, the ESB will continue to use the cached version of the sequence, as long as the registry is unreachable. A warning will be logged every time ESB attempts to load the sequence from the registry and fails. As soon as the registry comes back on-line, ESB will load the sequence from the registry.
HTTP, HTTPS, VFS based file transport, FIX, Hessian, HL7,UDP, JMS, Mail, TCP, XMPP
Yes, WSO2 ESB requires an external JMS broker like Apache ActiveMQ.
WSO2 ESB supports AMQP through its JMS transport. The JMS transport can be configured to connect to an AMQP broker as if it was connecting to a JMS broker. This functionality has been tested with Apache Qpid and RabbitMQ.
You can edit parameter bind-address in http/https transport receiver to change the host name of WSO2 ESB. This hostname will be displayed on service endpoints and generated WSDLs.
You can specify the preferred connection factory by adding the following parameter to the proxy service configuration.
<parameter name="transport.jms.ConnectionFactory">MyConnectionFactory</parameter>
Replace 'MyConnectionFactory' with the name of the appropriate connection factory. If the above parameter is not specified, proxy service will bind to the connection factory named 'default'.
Yes, you can refer sample 264 which demonstrates exactly the JMS request/response scenario.
Any JMS broker that provides JNDI support can be integrated with WSO2 ESB. The default configurations are for Apache ActiveMQ. WSO2 ESB has also been tested with IBM Websphere MQ, Swift MQ and JBOSS MQ.
This is the default HTTP transport used by WSO2 ESB. NHTTP stands for non-blocking HTTP. NHTTP transport uses the Java Non-blocking I/O API. This allows the NHTTP transport to scale into handling hundreds of connections without blocking the threads. The server worker threads used by the NHTTP transport do not get blocked on I/O until the ESB receives responses for the already forwarded requests. Therefore WSO2 ESB can accept more concurrent connections and requests than most HTTP server products.
NHTTP transport uses the Apache Http Core NIO library underneath. This library provides low level I/O handling and HTTP level detail handling.
There is a file called nhttp.properties in the webapps/ROOT/WEB-INF/classes directory. User can change various configuration parameters like number of threads, keep alive connections through this file. More information can be found in the ESB Administrator Guide.
The NHTTP transport configuration has two parts and they are transportReceiver and transportSender. Both configuration are located axis2.xml file.
You can keep them as local entries. But it is recommended to keep them in the registry instead, for easier and better management.
When a graceful shut down is initiated ESB will serve the accepted requests but stops processing new requests
Hot deployment/hot update may take the system to inconsistent states if the updates are not properly coordinated. Therefore it is recommended to turn hot deployment and hot update off for production deployments.
WSO2 ESB integrates with WSO2 Governance Registry out of the box. Refer the administrator guide for the necessary steps involved in remote registry configuration.
You just need to put the configuration into the registry and point all ESB instances to that registry instance.
It is tested on JDK 1.5 and JDK 1.6. Sun JDK and IBM JDK are supported.
When deploying you can remove, $ESB_HOME/samples and $ESB_HOME/repository/samples from the standard distribution.
You can uninstall all the UI components using the feature manager which will disable the management console.
Yes it has been tested on the following app servers. JBoss, Weblogic, Websphere and Tomcat.
See the documentation to see how to write a custom task. Put your non-OSGi task jar into $esbhome/repository/components/lib directory. WSO2 ESB will automatically deploy your custom task.
You need to write a class implementing the org.apache.synapse.registry.Registry interface to integrate the third party registry to WSO2 ESB.
WSO2 ESB ships with an embedded H2 database. However any database management system can be plugged into the ESB via JDBC. The relevant database configurations are available in repository/conf/registry.xml and repository/cong/user-mgt.xml files. WSO2 ESB has been tested with MySQL, Oracle, MSSQL and PostgreSQL databases.
The memory allocation setting are in the wso2server.sh. The user can change the memory allocation settings by changing the following configuration.
-Xms256m -Xmx512m -XX:MaxPermSize=128m
Yes it support JMX monitoring. Users can use the JConsole for simple monitoring and use JMX clients for custom monitoring
Users can write and plug their own statistics collection mechanisms to the ESB. This allows users to report statistics to their own statistics collection systems.
WSO2 ESB uses Apache Log4/J over Apache Commons Logging as the logging framework. Logging configuration is loaded from the log4j.properties file in the lib directory. The UI also allows configuring logging at runtime. The generated server logs can be found in the repository/logs directory.
Login to the ESB management console and go to the sequence management page. Enable tracing for the sequence you want to debug. Send a few messages to the sequence and go to the system logs viewer in the UI (or open the wso2-esb.log file in repository/logs). Go through the generated trace logs and locate the problem.
You need to enable statistics on sequences, endpoints, proxy services for the ESB to collect statistics on them. By default WSO2 ESB does not collect statistics on anything to keep the overhead at a minimum. Simply enable statistics for the items you are interested in using the UI and mediation statistics page will start to get updated.
You can use the SOAP tracer in the UI to capture and monitor actual content of the incoming messages. Enable tracing on the appropriate sequences to trace the flow of messages through the ESB. ESB also comes with Apache TCPMon which is a simple but extremely useful too for monitoring message flows.