Tuesday, December 15, 2015

Getting Started With WSO2 ESB

Need of Integration:

Today's business applications rarely live in isolation. Users expect instant access to all business functions an enterprise can offer, regardless of which system the functionality may reside in. This requires disparate applications to be connected into a larger, integrated solution, which is generally achieved through some form of "middleware". Middleware provides the "plumbing" such as data transport, data transformation, and routing.

What is ESB?

An enterprise service bus (ESB) is a "software architecture" model used for designing and implementing communication between mutually interacting software applications in a service-oriented architecture(SOA). There are two major uses of the ESB.
  • For enterprise integration - the connection of disparate resources to fulfill customer and business scenarios.
  • As an infrastructure backbone for service-oriented architecture (SOA)


WSO2 ESB is a fast and lightweight, enterprise service bus. It is based on Apache Synapse, the lightweight ESB from the ASF and WSO2 Carbon, the OSGi based components framework for SOA. WSO2 Carbon makes it possible to easily install and configure additional features into the ESB runtime.

  • Full XML and Web Services Support with major protocol/standard support.
    • Transport - HTTP/S, POP/IMAP, SMTP, JMS, AMQP, FIX, Raw TCP, Raw UDP, SAP, File transports (FTP/SFTP/CIFS)
    • Content Interchange Formats - SOAP 1.1, SOAP 1.2, POX, HTML, Plain text, binary, JSON, Hessian
    • WS-* Standards -   WS-Addressing, WS-Security, WS-Reliable Messaging, WS-Policy, WS-Discovery, MTOM/SwA
  • Has built in support for many common requirements
    • Content based routing
    • Service virtualization
    • Load balancing
    • Fail-over sending
    • Protocol switching
    • Message transformation
    • Logging & monitoring
    • Message splitting and aggregation
    • Enterprise integration patterns
  • Internationalized Graphical Console - WSO2 ESB provides a set of management services and a graphical user interface to configure/manage/monitor the running ESB server.    
  • Server Management and System Monitoring 
Modes of Operations:

WSO2 ESB supports 4 modes of operation

  • Message mediation (ESB as a message router. It can filter, transform, drop messages or forward them to remote endpoints for further processing when operating in this mode.)
  • Service mediation (Expose service endpoints on ESB. It acts as a proxy to a real Web Service hosted in a Web Services container like Apache Axis2 or WSO2 WSAS.)
  • Task scheduling (Run periodic tasks on ESB)
  • Eventing (ESB as an event broker)
Most real world scenarios require the ESB to operate in multiple modes at the same time.

ESB Functional Components:
Each functional component serves a specific purpose and functional components can be mixed and matched to implement various integration scenarios and patterns. Configuring WSO2 ESB for a given scenario requires:
  • Identifying the right set of components
  • Putting them together in the optimal manner
The basic functional components of WSO2 ESB are as follows.
  • Mediators: This is the fundamental component of any message flow implementation of WSO2 ESB. A mediator has an input message, an output message and some associated configuration. This configuration is a pure XML based configuration that can be use to transfrom, alter or manipulate the incoming message of a Mediator to form the out going message.
  • Sequence: A sequence is a sequential arrangement of a set of mediators. It resembles an industrial pipeline. A given sequence may have an arbitrary number of mediators and message flows through them in sequential manner.
  • End Points: a logical representation of an actual back-end service or a group of back-end services (i.e LoadBalancing and FailOver)
  • Proxy Services:  a 'virtual service', that provides the required business functionality by seamless integration of backend services. It is a combination of three sequences and a target endpoint.
    • In-sequence: All the incoming requests to the proxy service are dispatched to the in-sequence.
    • Out-sequence: All the responses coming back from the backend service implementation are dispatched to this sequence. 
    • Fault sequence: If an error occurs during service mediation the faulty message is handed to the fault sequence for error handling work.
  • REST API: The REST API allows to expose RESTful interfaces and mediate RESTful invocations by mapping REST concepts to SOAP via proxy services.
  • Message Stores/Processors: A message store is used to temporarily store messages before they are delivered to their destination by a message processor. This approach is useful for serving traffic to back-end services that can only accept messages at a given rate, whereas incoming traffic to the ESB arrives at different rates.A message processor is used to deliver messages that have been temporarily stored in a message store.
  • Templates: Very large amount of configuration files in the form of sequences, endpoints, proxies and transformations can be required to satisfy all the mediation requirements of the system.In such cases a number of configuration files will be scattered all over and would be extremely hard to manage. ESB templates try to minimize this redundancy by creating prototypes that users can reuse and utilize as and when needed. 
  • Tasks: A task in WSO2 ESB allows you to run a piece of code triggered by a timer.
  • Local Entires: The local registry acts as a memory registry where you can store text strings, XML strings, and URLs. These entries can be retrieved from a mediator.These entries are top level entries which are globally visible within the entire system.
  • Priority Executors: Priority executors can be used to execute sequences with a given priority. This allows the user to control the resources allocated to executing sequences and prevent high priority messages from getting delayed and dropped.
  • Registry: WSO2 ESB makes use of a registry to store various configurations and artifacts such as sequences and endpoints. Simply put, a registry is a content store and a metadata repository.