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 very easy to configure, control and monitor the ESB runtime.
It is released under Apache Software License Version 2.0, one of the most business-friendly licenses available today.
WSO2 ESB is distributed completely free and the distribution packs can be downloaded from the WSO2 Oxygen Tank (http://wso2.org) or http://wso2.com under the "Products" menu. WSO2 BRS can be downloaded as a binary distribution or built from SVN source.
Yes, the results of several rounds of performance comparisons carried out in year 2008 are available in the following article in WSO2 Oxygen Tank: http://wso2.org/library/3740. More recent performance test results will be coming up soon.
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 firstname.lastname@example.org and email@example.com mailing lists. Feel free to provide ideas, feedback and help make our code better. You can also report bugs on and submit patches. For more information on our mailing lists, refer to http://wso2.org/mail.
WSO2 ESB is built on top of WSO2 Carbon, an OSGi based components framework for SOA. It uses Apache Synapse (http://synapse.apache.org) as the underlying mediation engine. Java is the primary programming language used to develop WSO2 ESB.
Refer to ESB system requirements.
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:
When enabling a new transport you will have to deploy the libraries required by the transport implementation (eg: When enabling JMS you need to deploy the client libraries required to connect to your JMS broker)
When adding a custom mediator or a task, you may have to deploy the dependencies required by the custom code.
Copy any third-party jars into $ESB_HOME/repository/components/lib directory and restart the server. WSO2 ESB converts those jars to OSGi bundles and place them in <ESB_HOME>/repository/components/dropins directory.
Yes, you can extend the management console easily by writing a custom UI component and simply deploying the OSGi bundle.
Yes 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. For more information, refer to User Management .
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, WSO2 ESB is lean and allows you to maintain just the right set of features required at the time. Simply login to the ESB management console and uninstall any unwanted features from the list of Installed 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 has support for distributed transaction, local JMS transactions and distributed JMS transactions.
Yes, you can use WSO2 ESB in an Access point.
In the current version, you can place any non-OSGi custom mediators and class mediators in $ESB_HOME/repository/components/libs and OSGi bundles in $ESB_HOME/repository/components/dropins.
WSO2 ESB reads its mediation configuration from a set of XML files located at $ESB_HOME/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 section, Registry .
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 faced to a erroneous situation. You can find detailed article about endpoint error handling in the following article in WSO2 Oxygen Tank: http://wso2.org/library/articles/wso2-enterprise-service-bus-endpoint-error-handling.
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 and configured to load content from a remote file too.
To refer to a sequence named foo use the sequence mediator as follows:
You can also refer to dynamic sequences saved in the registry by specifying the registry key to the sequence resource as follows:
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:
This configuration can be found in a file named registry.xml in $ESB_HOME/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, use a header mediator to calculate the new 'To' address.
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.
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 (http://activemq.apache.org).
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 (http://qpid.apache.org) and RabbitMQ.
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.
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, refer to 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 (http://hc.apache.org/httpcomponents-core-ga/httpcore-nio) underneath. This library provides low-level I/O handling and HTTP-level detail handling.
There is a file called nhttp.properties in $ESB_HOME/repository/conf directory. User can change various configuration parameters like number of threads and maintain 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 in $ESB_HOME\repository\conf\axis2\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, the ESB will continue to serve the accepted requests but stops processing new ones.
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. For steps involved in remote registry configuration, refer to Registry .
Put the configuration into the registry and point all ESB instances to that registry instance.
It is tested on JDK 1.5, JDK 1.6.* and JDK 1.7.*. Sun JDK and IBM JDK are supported.
Refer to Installation Prerequisites .
You can uninstall all the UI components using the feature manager, which will disable the management console.
Yes it has been tested on JBoss, Weblogic, Websphere and Tomcat.
Put your non-OSGi task jar into $ESB_HOME/repository/components/lib directory, which will be deployed automatically. For information on writing a custom task, refer to Writing Tasks.
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. For information, refer to Setting up 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. For more information, refer to Monitoring the ESB .
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 $ESB_HOME\repository\conf directory. The UI also allows configuring logging at runtime. For instructions, refer to Logging . The generated server logs can be found in the $ESB_HOME\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 $ESB_HOME\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 maintain minimum overhead. Simply enable statistics for required items using the management console UI and the 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 tool for monitoring message flows.