Showing posts with label esb. Show all posts
Showing posts with label esb. Show all posts

Friday, February 21, 2014

WSO2 ESB answers the critics on its performance test results

Few months ago, big fuss was made via a performance blog saying that some of the performance stats published on WSO2 ESB are incorrect and flawed. WSO2 ESB team has carried out some investigations on these and published the latest performance test results based on their latest release WSO2 ESB 4.8.1.

You can find the official article at http://wso2.com/library/articles/2014/02/esb-performance-round-7.5/

There is an interesting blog post which explains why were the accusations made in the aforementioned performance blog post are incorrect and unfair. You can find it at https://shafreenanfar.blogspot.com/2014/02/esb-performance-round-75-other-side-of.html

If you are too curious, following is the latest performance graph. Believe me, its worth reading the above two posts.

Oh.. I forgot to say, WSO2 ESB is the fastest open source ESB on earth :)

Thursday, July 18, 2013

PublishWSDL option in WSO2 ESB explained...

If you are wondering what is the PublishWSDL option of WSO2 ESB, you can have a look at how to create proxy services in WSO2 ESB.

Lets say you are going to expose a web service by creating a proxy service. If you do not publish the WSDL of the web service you are exposing, then if you take the WSDL of the created proxy, it will only show the "mediate" operation. If a client wants to invoke the backend service via the proxy service, it needs to know the expected message format by the web service (parameters, their names etc.).

But, if you decide to publish the WSDL of the web service, then the WSDL of the proxy service will show all the operations which are available in the web service. This makes life easier to the client.
But publishing WSDL also exposes all the operations of the web service. What if you want to expose only a few operation to the clients? In that case, you can publish a WSDL with only the operations which you want to expose.

There is another advantage. Lets say the backend service operation expects three parameters to be sent (lets assume these are name,department and a permission level). We want the client to send only the name and department and we are planning to add the permission level to the request within the proxy service. In such a scenario, we can publish a modified WSDL which is expecting only the name and the department and inject the permission level within the proxy service.

Above are the use cases of PublishWSDL option available in WSO2 ESB. Although this is a simple thing, I couldn't find a place which explains this. So, hope this helps somebody.

Thanks Kasun Indrasiri of WSO2 for explaining this to me... :)

Saturday, September 15, 2012

Now you can send the SoapFaults to the Fault Sequence in WSO2 ESB

WSO2 ESB 4.5.0 was released recently. There are many new features, enhancements and performance gains in this new release. I wanted to highlight one new cool feature which I couldn't wait anymore. That is the title of this post.

In the previous releases of WSO2 ESB fault sequence was hit only when there was a fault during the mediation process taking place inside the WSO2 ESB. If a soap fault was received from a backend service it was sent to the out sequence because the WSO2 ESB considered it as a response from the backend. It was fair from ESB's point of view and unfair from developer's point of view. But with the 4.5.0 release, now you can send the soap faults to the fault sequence and do the fault handling.

To do that, you need to set the FORCE_ERROR_ON_SOAP_FAULT property before you send the message to the backend. This is a newly introduced property and following sample proxy service will show you how to do it.


   
      
         
         
      
      
         
      
      
         
            
         
      
      
         

Hope this property will help many integration developers during their use of WSO2 ESB.

NOTE

Above proxy configuration was taken from a resource which was emailed to me by Kasun Indrasiri who is an ESB expert in WSO2.

Happy Integration.... :)

Sunday, May 20, 2012

Getting ActiveMQ Redelivery to work with WSO2 ESB

Recently I wanted to use the redelivery mechanism available in Apache ActiveMQ while using it with WSO2 ESB. My scenario was like this.
  1. Retrieve a message from a JMS queue
  2. Write the message to a file URI (in your case you may want to send it to a given endpoint)
  3. If writing to the file is not successful due to some failure, I wanted the message to be in the queue and ActiveMQ to try repeatedly writing to the file.
Following are the properties/parameters I had to put in the axis2.xml of WSO2 ESB (under JMS transport receiver). Remember that you need to put the other parameters such as initial context factory, provider url, connection factory and connection factory type etc.
<parameter name="transport.Transactionality" locked="true">jta</parameter>
<parameter name="transport.jms.SessionTransacted" locked="true">true</parameter>
<parameter name="redeliveryPolicy.maximumRedeliveries" locked="true">-1</parameter>
<parameter name="redeliveryPolicy.redeliveryDelay" locked="true">2000</parameter>
<parameter name="transport.jms.CacheLevel" locked="true">consumer</parameter>

I will explain some of the above parameters.

  1. transport.Transactionality - This is the desired mode of transactionality. I was using distributed transactions. Therefore the value was jta. If you are using local transactions you can put it as local.
  2. transport.jms.SessionTransacted - Whether the JMS session should be transacted or not.
  3. redeliveryPolicy.maximumRedeliveries - Maximum number of retries you wish. If set to -1, ActiveMQ will infinitely retry.
  4. redeliveryPolicy.redeliveryDelay - Delay between retries. I have set it to 2 seconds (i.e. 2000 milliseconds).
  5. transport.jms.CacheLevel - This is the most important property to get the redelivery mechanism to work properly. This has to be set to "consumer". Reason for this is ActiveMQ  RedeliveryPolicy is dictated by CONSUMER, not PRODUCER.
With above configurations, you are able to get the redelivery mechanism in ActiveMQ to work when used with WSO2 ESB.

You will also need to set the SET_ROLLBACK_ONLY property in the fault sequence of your proxy service. Otherwise the transaction will not get rollbacked.
<property name="SET_ROLLBACK_ONLY" value="true" scope="axis2"/> 


Following links will provide further help.
1. WSO2 ESB documentation's JMS transport section
2. ActiveMQ redeliverPolicy configuration parameters