A closer look at WSO2 ESB 4.7.0

WSO2 has just release the latest version of Enterprise Service Bus, WSO2 ESB 4.7.0. This is the first major release of WSO2 ESB after the 4.6.0 release which purely contained the major performance enhancements.

As a member of WSO2 ESB team, I would like to discuss some of the key aspect of 4.7.0 release which will be helpful for all the integration geeks and all of the existing users of WSO2 ESB .

Comprehensive RESTful Integration 

With the heavy adaptation of RESTful APIs all over the world any integration platform should offer a solid foundation to integrate RESTful services. WSO2 ESB initially came up with the REST API implementation, which is a robust and a clean way to expose REST APIs via ESB. This feature was extensively used in many integration scenarios and WSO2 API Manager successfully leverage this functionality in its API Gateway.  

  

REST Triangle

There are three main concepts that we need to understand in REST(Representational State Transfer); Nouns, Verbs and Data Types. 

Nouns are used as the identifier for a resource and it is generally a URL(eg: To find a specific type of a Pizza in a Pizza Ordering RESTful service one could use:

 http://localhost:8080/PizzaShopServlet/restapi/PizzaWS/menu?category=pizza&type=pan).

Verbs are generally used as operations generally encompasses everything that can be done to a piece of data, CRUD (Create, Read, Update, Delete). In HTTP scope these are mapped to POST, GET, PUT and DELETE. 

Data Types provide the format for the data that will take part in your RESTful discussion. Most commons data types are XML JSON, or CSV. 

HTTP Endpoint (Nouns and Verbs)

REST APIs in WSO2 ESB is all about exposing the REST APIs, but how about integrating existing RESTful services. Prior to 4.7 release, WSO2 ESB has the support for integrating RESTful services but the users had to do a lot of tweak around various properties defined in the ESB configuration. Therefore, we introduced a new endpoint type called 'HTTP Endpoint', where users can specify an URI Template which can dynamically populate final URI for the RESTful service invocation. Also, users can manipulate HTTP method of the outgoing request. For more info, please refer [1].

Loading ....

HTTP Endpoint for Dynamic Address Resolution 
In fact, HTTP Endpoint can talk to any SOAP based BE as well. With the HTTP Method set to 'POST' and you can create the URI as per your preference. So, this endpoint type will be a prime candidate for the scenarios where you want to have BE addresses which resolved during the run time(i.e: From a System variable etc).

JSON support for Payload Factory Mediator (Data Types)

When dealing with RESTful services, the data formats plays an important role. In particular, many RESTful APIs uses JSOn as the date format and that's what leads us to think about supporting mutiple media types in Payload Factory mediator. Since the Payload Factory mediator was introduced in to ESB, it was increasingly used for implementing many transformation scenarios (where the transformation logic is not that complex). With ESB 4.7 release, the payload factory mediator support multiple media types, xml and json and carter following transformation scenarios. When dealing with multiple media types, we introduce something called an 'evaluator' to distinguish between the xml,  json    or any other evaluator(i.e. xpath for xml and json_path for json). The media type based transformation not using any intermediate data representation format which makes it more efficient. Please refer [2] for more info.

JSON -> JSON
JSON -> XML
XML->JSON
XML->XML

Loading ....

High Performance Multitenant REST APIs with PassThru Transport 

With ESB 4.6 release, we make the high performance Pass-Thru Transport (PTT), the default transport for ESB. However, we didn't support most of the Multitenant(MT) scenarios with PTT during 4.6 release. In particular, REST APIs in MT was not supported in 4.6. 

In WSO2 ESB 4.7, we have added the full support for all Multitenant REST APIs which allows you to create blazing fast REST APIs in Multitenant cloud environments. 

Transport Headers with Header Mediator 

Often we have to deal with various HTTP headers when integrating RESTful backend services. In such cases, manipulating HTTP headers through a mediator will be very handy. We enforce this functionality in to Header Mediator (which was originally support transforming the SOAP headers only), so that users can set what ever the transport headers with the use to Header mediator. (One could do the same with a Property mediator, but using Header mediator make your config more readable and manageable) 

Better Store and Forward Story - Guaranteed Delivery and Rate Matching 

Store and Forward pattern is used in many integration solutions. It is becoming more and more frequent   that we have to deal with guaranteed delivery, in-order delivery or rate matching scenarios with messaging. So, the general approach to solve the store and forward problem is to use a persistent/non-persistent store to store the messages and then have a separate component which can forward/process messages based on predefined strategy. 

Store and Forward 

WSO2 ESB supported these use cases with the introduction of Message Stores and Processors. In 4.7, we have revamped the implementation of message store and processors such that it caters high performance guaranteed delivery and rate matching scenarios.

In most of the integration scenarios, it is required to have a robust and efficient guaranteed delivery infrastructure. So, in such use case it is also required to have a high performance Message Broker solution such as WSO2 Message Broker. So, in 4.7 release we put an extra effort to provide seamless integration of WSO2 ESB and WSO2 MB. The improvements took place in JMS Message Store, Forwarding Message Processor(Guaranteed Delivery) and Sampling Message Processor(Rate Matching). Also, in future ESB releases also we are planning to strengthen Message Store and Processor more and more. For more info on WSO2 ESB/WSO2 MB integration please refer [3].

SSL Tunneling Support

When your ESB connects to a back-end server through a proxy server, you can enable secure socket later (SSL) tunneling through the proxy server, which prevents any intermediary proxy services from interfering with the communication.

WSO2 ESB 4.7.0 supports such scenarios and you can configure either Pass-Thru or NHTTP transports to support SSL tunneling. Please refer [4].

SSL Inbound Profiles with Multi-HTTPS Transport

The Multi-HTTPS transport is similar to the HTTPS-NIO Transport, but it allows you to have different inbound SSL profiles with separate trust stores and key stores for different hosts using the same ESB. The ESB can listen to different host IPs and ports for incoming HTTPS connections, and each IP/Port will have a separate SSL profile configured. [5]

Inbound Connection Throttling Support for PTT and NHTTP 

WSO2 ESB is using non-blocking HTTP transports(PTT,NHTTP) which are based on HTTPCore NIO. When the client keep on sending request to ESB, the ListeningIOReactor which resides at the transport listener side keeps on accepting connections. We have encountered some production scenarios where the ESB should throttle the number of accepted connections. To do so, we introduce a new throttling parameter for both PTT and NHTTP transports.

We can specify it in passthru.properties or nhttp.properties files and throttling the number of inbound connections "max_open_connections = 1000". Internally what happens here is that, if the connection count is above the specified limit, then the ListeningIO Reactor will be periodically paused. By default, the max_open_connections throttling is not applied and can be considered as ESB infinitely accepts the incoming connections. 

OCSP/CRL

OCSP(Online Certificate Status Protocol)/CRL(Certificate Revocation List) are two protocols used to check whether a given X509 Certificate is revoked by its Issuer. At the verification phase of SSL handshake, different verifications procedures are used in order to make sure the connecting party is trusted. OCSP/CRL certificate verification process is mandatory where high computer security is concerned. This feature is implemented for NHTTP transport of ESB 4.7 and can be enabled this in axis2.xml for HTTPS Transport Sender parameter 'CertificateRevocationVerifier' setting to true.

Less Bugs 

In WSO2 ESB 4.7 release, we bring down the issue count drastically by fixing nearly 400 bugs and resolved over 550 public jiras, which in turns bring down the total outstanding issue count to less than 150 issues. 

Performance 

Although ESB 4.6 release was solely a performance enhancement effort, in 4.7 release we didn't impose any transport level performance improvements. However, from 4.6 to 4.7 we have ensured that we have the same performance level as with 4.6, which is capable of out performing all open source ESB vendors. The following performance comparison between 4.6 and 4.7 shows the identical TPS for each scenario.

WSO2 ESB 4.6 vs 4.7 

HL7 

In HL7 space also we did several improvements such that it can support Accept Ack and Application Ack scenarios. [7]  

Invoking Sequence/Proxy Service via Scheduled Tasks

With ESB 4.7, now you can invoke any named sequence or a proxy service with ease. We only have give the name of the sequence or the proxy service name along with the task config. Please refer [8]


images courtesy of : 
http://www.ansoncheunghk.info/article/web-apis-resource-oriented-architecture
http://www.altisinc.com/resources/IE/images/storfor.gif
http://windowsitpro.com/