The WSO2 Enterprise Service Bus is a lightweight, XML and Web services centric ESB, based on the Apache Synapse (just graduated from incubation at the Apache Software Foundation) and Apache Axis2 projects. It supports connectivity, transformation and mediation, and the management of Web service interactions.
Enhanced the administration console with
the built in registry
- Facilitates the management of Properties, Endpoints, and Sequences
Proxy service creation through a wizard
Single point of configuration for a cluster, based on the concept of making the configuration a registry entry
User interface for registry management
Enhanced componenet based message tracing and statistics reporting through graphs
NIO/HTTP transport implementation for the HTTP transport
Supports WS-Security and WS-Reliable Messaging for Proxy services and Endpoints through WS-Policy.
Load balancing on round robin/ failover mediators and throttling
The WSO2 ESB could be used in a number of scenarios as follows:
Proxy services created on the WSO2 ESB can expose existing services on different transports (e.g. A JMS service over HTTPS) or with WS-Security and WS-Reliable messaging enabled through WS-Policies. The 'Proxy' services thus created can be Web services based on a WSDL and any service level policy, or even POX (Plain Old Xml). For example, a proxy service can be configured to listen for a JMS message over an existing JMS Queue, convert a plain text message into a SOAP payload, and send it to a Web service endpoint using WS-Security. The Proxy services thus created can be started or stopped and monitored through the administration console. Statistics on the defined proxy services are also available from the administration console. The proxy services thus deployed expose themselves as real Web services with a customized WSDL, if applicable, so that dynamic clients can find out the WSDL, Schema, and WS-Policies enabled on these services.
WSO2 ESB also supports message level mediation, where the ESB can be configured to be the destination for all messages flowing in an enterprise. In this mode, the clients must set the WSO2 ESB as a proxy or a gateway, and could optionally use WS-Addressing to specify the endpoint reference for the real destination. The WSO2 ESB can be configured to route the messages based on content, target EPR (end point reference) or any other message property or information.
Mediators available in the WSO2 ESB facilitates logging, schema validation, XSLT transformation, header manipulation, filtering, creating custom fault messages, error handling, scripting using any script language supported by the Bean Scripting Framework (e.g. JavaScript etc) and sending or dropping of messages etc,. It also provides the ability to introduce custom mediators implemented as simple Java classes or Spring beans.
The concept of named sequences allows reusable sequences of mediation rules to be defined and used from within multiple access points. For example, a sequence can be defined to validate and transform a message and send it to an endpoint. This sequence can be used to handle incoming messages for one or more proxy services, or from multiple locations within the message mediation rules.
The WSO2 ESB also allows the definition of endpoints, which captures an endpoint address (EPR) and the associated QoS engagements and policies to be used when sending messages. Endpoints can be named and referenced from within multiple mediation sequences.
The concept of component based tracing allows users of ESB to trace incoming and outgoing messages, and the transformations at each step to be traced in sequences, endpoints, proxy services, and mediators including send and drop, and so on. Users can also inspect the statistics through a graphical representation as well as a quantitative measure for sequences, endpoints, proxy services, and message mediation.
A built-in Registry allows resources to be centrally managed and refreshed as necessary. The registry stores schemas, transformations, policies, etc., and makes them available to run WSO2 ESB instances. If any of these resources change, the instances would be able to refresh and retrieve new content. Similarly, you can define message mediation sequences in the registry, and allow the WSO2 ESB to dynamically pick up the rules for processing messages. You can dynamically update sequences, properties, and endpoint definitions, as well as start up an instance of the WSO2 ESB simply pointing to the root of the Registry, so that it can fetch its configuration and startup.