WSO2 Enterprise Service Bus

Service Virtualization with Security

As a system administrator, Shane is responsible for managing a set of Web Services. His organization makes a strategic decision to expose some of these services directly to the public. As a result, Shane is asked by his CTO to look for a way to open up selected services to the Internet without compromising security. Unfortunately for Shane, the services are hosted in a legacy system which cannot be easily secured using the accepted modern security standards for Web Services. Shane creates proxy services with the WSO2 ESB and configures them to route public requests to the actual Web Services deployed in his organization. He configures the proxy services to accept requests only over the secure HTTPS protocol. He also engages WS-Security on the proxy services so that only a secured client can invoke the proxy services. Shane uses the security policy files provided by the organization’s IT administrators, written in the standard WS-Policy language, to document the precise security requirements for using the services. Many of these policies use the WSO2 Identity Server in concert with the WSO2 ESB to manage the authentication and authorization to the services.

Integrating a Trading partner

Marshall manages his organization’s business messaging systems which are primarily based on the AMQP protocol. His company signs a new partnership deal with a finance company and Marshall’s boss asks him to link up some of their internal systems with the new partner’s systems for quick sharing of data and easy on-line collaboration. The new partner has a business messaging infrastructure which is almost entirely based on the FIX (Financial Information eXchange) protocol. Marshall faces the challenge of connecting their own AMQP applications with a set of FIX applications. While the differences between the two protocols pose a first level of challenge, differences between the actual message formats make it even more complex. Marshall uses the WSO2 ESB to deploy a set of proxy services and expose them over the AMQP protocol. He configures the relevant AMQP applications within his organization to send AMQP messages to the proxy services. Then he configures the FIX transport of the ESB to forward the AMQP traffic to the FIX endpoints of the partner organization. Thanks to the transformation mediators in the ESB, Marshall is able to take advantage of his existing knowledge of widely accepted standard technologies like XSLT and XQuery to efficiently convert between message formats as the messages flow through the ESB.

Adding High Availability to your services

Andrew, a network administrator, has just received the green light from his management to replace their old Web Services container with a group of application servers to achieve better levels of high availability. Lately their Web Services container has been receiving a large number of requests and the old server is hardly able to cope up with the load. Andrew proposed that the single server instance should be replaced with a cluster of three active server instances and a cluster of three backup server instances. The active cluster will receive the requests by default and whenever something goes wrong in the active cluster the backup cluster can be brought into action. Having set up the two clusters, Andrew decides to use WSO2 ESB as the load balancer and the fail over router. WSO2 ESB is configured to load balance the requests among the members of the active cluster, and whenever the active cluster goes down, the ESB automatically switches over to the backup cluster and starts load balancing among the backup servers. Andrew is also able to configure the conditions which should be treated as communication errors by WSO2 ESB.

Initiate transactions to pull data with Task Scheduling

Sally is an ESB administrator with responsibility for managing one of the WSO2 ESB instances for her company. She’s asked by her management to implement a message flow which queries one of their partner’s applications once every 6 hours and log the results in an internal database. And when certain critical conditions are found send an E-mail to the board of directors of the organization, along with writing a separate incident log file. Sally starts by defining a simple periodic task in the WSO2 ESB which injects a request into the service bus once every six hours. Sally is already familiar with the widely accepted cron syntax, so specifying the schedule is a snap. Then she creates a sequence which forwards the injected requests to the partner application over HTTP. The returned messages continue through the sequence, with an XPath expression evaluated on the response XML messages. Sally uses the DBReport mediator of WSO2 ESB to add an entry to the internal database regarding the outcome of the query. Finally depending on the outcome of the XPath evaluation, VFS transport is used to write the local incident log file, and the Mail transport generates the requested E-Mails to the board of directors.

Rule based mediation and Dynamic Configuration

Jim serves as lead architect of an integration project which has adopted WSO2 ESB as the mediation engine. Over time Jim has come to realize that some of the decision making logic for the project can be expressed as a few simple rules. Jim investigates the Rule based decision making capabilities of the WSO2 ESB and develops the decision logic to configure the Rule mediator. This succeeds brilliantly, but over time he realizes that the configurations of message flows, the endpoints and even the Business Rules are changing frequently. While it is easy to change the ESB configuration using the WSO2 ESB management console, Jim prefers an approach that guarantees transactional behavior throughout configuration changes (if the incoming message is using a particular configuration it has to be the same for the outgoing message as well). So he decides to store all the sequence and endpoint configurations and business rules in the embedded WSO2 Governance Registry instance that comes with the ESB. He sets the ESB to obtain its configuration from the registry using a set of registry keys. Now Jim and his team can change the configurations in the registry without touching the ESB configuration. The WSO2 ESB loads the changes dynamically and reconfigures itself at runtime, without getting confused about which messages in flight belong to each configuration. Jim can also set a caching duration for the ESB so that configurations loaded from the registry will be cached for sometime to reduce the number of registry lookups.

Powered by the asynchronous “Apache Synapse” core, the WSO2 ESB is optimized for the highest levels of performance with very low latency, while remaining incredibly lightweight. A combination of non-blocking I/O and a streaming XML parsing design means that the WSO2 ESB can scale almost limitlessly. Overlying the Synapse core is a powerful web-based management, monitoring and configuration console. Underlying it is a built-in registry/repository to store the configuration and metadata. The ESB can be configured instead to use a remote repository to simplify management in clusters and advanced scenarios.

Transports

The WSO2 ESB supports all the widely used transports, though almost all of them are built into the ESB new transports can also be easily added, using the nicely abstracted, pluggable transport framework.

Clustering

Enterprise ready clustering implementation built into the WSO2 ESB manages the state replication with absolute minimum overhead, via the underlying tribes group communication framework.

Message Builders/Formatters

New content types can be associated with “message builders,” which parse the text or binary content of the message as needed by the ESB. If the message format needs to be changed, a different “message formatter” will be used to convert the normalized message to the required format for transmission, where the builders and formatters are also easily pluggable.

QoS

Quality of Service (QoS) components support reliable messaging and security for the proxy services and for message mediation, of which the behavior is configured via WS-Policy standards. It also supports response caching and request throttling at this layer as well as at the mediation layer.

Endpoints

Endpoints represent an external EPR which is a logical component against the transports. An endpoint can use any available transport to dispatch the messages. Endpoint framework is defined in a manner that it could be used for load balancing and fail over sending, while it logically represents an address URI or a service WSDL with a set of properties specifying the meta data about the endpoint invocation.

Mediators, Sequences

The power of the WSO2 ESB is extended with the comprehensive mediator catalog that provides a rich library of message mediation capabilities such as transformation, filtering, throttling, enrich, clone/aggregate and routing. Building a sequence of mediators from this library allows users to implement widely used Message Exchange Patterns (MEP) and Enterprise Integration Patterns (EIP). Once again, there is a comprehensive set of extension points to write your own mediation logic, in scripting languages & Java.

Proxy Services

Proxy services are virtual services hosted by the WSO2 ESB, most of the time acting on behalf of real back-end services possibly with some changes in parameters of those services. A proxy has it’s own inflow and outflow mediation sequences, an endpoint while it can publish it’s own WSDL interface.

Event Sources

The WSO2 ESB includes support for eventing-style message handling models, such as pub-sub. Event Sources are also a set of virtual services with support for WS-Eventing standards, which can either use a persisted registry based subscription store or a volatile in-memory subscription store.

Scheduled Tasks

Tasks kick off pre-scheduled or periodic jobs in the WSO2 ESB, which can initiate internal and external mediation events. This supports polling patterns, periodic maintenance or monitoring tasks, and more.