What is the best practices for WSO2 ESB in perticular XSLT transformations

1
votes

I am working on WSO2 ESB 4.0.3 on MAC OS X Lion (10.7.4)

I would like to know what are the best practices for development for WSO2 ESB 4.0.3.

Currently I am using Data Services Feature in it and existing tomcat application, which we are trying to port to WSO2 ESB, does the SQL query in 2-3 seconds where as WSO2 ESB 4.0.3 with Data Services feature taking around 16-17 secodns.

I would be thankful if some body can let me know best practices for WSO2 and in perticular XSLT transformation.

Hoping for answer.

thanks

Hi Prabath Here is how my environment is I am using WSO2 ESB 4.0.3 with Data Services Feature 3.2.2. Proxy service front ends the DS service. Data sources are defined as carbon data sources in datasources.properties. I tried to run the same service in the WSO2 Data Services Server 2.6.3 and the performance is comparable to what existing tomcat application does but the ESB 4.0.3 with Data Services Feature 3.2.2 takes 8 times more time than tomcat application. Looks like XSLT is not a issue as I thought earlier. I have all the error handling & input validation in the proxy service which calls this DS. Also I tried changing it to local for the transport but still same performance issue. Also I have to make sure the format of the forwarded XML is SOAP 12 in the end point definition otherwise proxy service does not forward with local transport. Can you please suggest so that I can use WSO2 ESB with Data Services Feature 3.2.2 and get comparable performance?

Help really appreciated. thanks Abhijit

Hi Prabath

Thanks for reply.

Proxy service validation and transformation is not a problem. Looking at the logs it looks like Data Service deployed in ESB with Data Services feature is taking 8 times more time than the tomcat application. So it is Data Services Feature which is problem I believe and not the proxy service.

Even if we remove the proxy service where you will do the input validations and error handling?

Please let me know. thanks Abhijit

2
wso2wso2esbwso2carbon
Hi Abhijit, taking the information you've mentioned into account, it's kind of clear that when you call a dataservice fronted by a proxy service with validations and all, drops the response time, etc as it obviously adds an additional layer on top of the dataservice layer. So if you want to compare performance for dataservices when using DSS against when using dataservices features installed in ESB, I believe you have to get rid of the additional proxy service layer and do it. – Prabath Abeysekara
Then you'd realize that the performance of using DSS and dataservices features inside ESB are pretty much the same and the additional proxy service adds the extra over head. – Prabath Abeysekara
However, I believe, if you use local transport to call DSS via the ESB (when using dataservices inside ESB) it's always enhance the performance metrics as it cuts the network overhead which is usually the culprit of some of the performance related issues. – Prabath Abeysekara

2 Answers

0
votes

Abhijit,

I'm not quite clear of whether this problem is related to executing SQL using dbReport/dbLookup mediators against doing the same thing having data services features installed in ESB OR transforming responses using XSLT at the ESB layer against doing it at the DSS layer.

If it's the former, then you should be able to effectively use the db mediator pair (namely dbLookup and dbreport) to execute simple SQL queries such as SELECT, INSERT, UPDATE, DELETE, etc. However, it is not recommended to do use those mediators to do much complex queries such as stored procedures with "OUT and INOUT" parameters etc as WSO2 DSS is specifically designed to serve any sort of complex queries like that. However, this (using data services) comes at the cost of network latency. Because, you're invoking a data service endpoint through the network which obviously adds the network latency to the end-to-end time taken to get your task done. However, if you're using Data Services features installed in the WSO2 ESB, you always have the option of using "local" transport instead of "http/https" which does an in-JVM call and thus would not dispatch the request over the network.

If this is related to the later, meaning, if you refer to the XSLT transformations, I believe there's no such hard and fast rules in doing this and this would completely depend on your requirements and the usecase. For example, if you're only using WSO2 DSS and want to get some request transformed into a particular format that is expected by the client side, it would only be enough for you to get it done at the WSO2 DSS layer. Because, dispatching it into ESB ONLY for the sake of getting the XSLT transformation done, would add an additional unwanted overhead to the end-to-end completion time of your task. On the other hand, if you're doing this as a part of a configuration flow at the ESB side, then it's perfectly okay to use something like XSLT mediator inside the flow itself.

Hope this helps!

Regards. Prabath

0
votes

I hope Prabath already gave the answer to your question.

However, it is not recommended to do use those mediators to do much complex queries such as stored procedures with "OUT and INOUT" parameters etc as WSO2 DSS is specifically designed to serve any sort of complex queries like that. However, this (using data services) comes at the cost of network latency. Because, you're invoking a data service endpoint through the network which obviously adds the network latency to the end-to-end time taken to get your task done. However, if you're using Data Services features installed in the WSO2 ESB, you always have the option of using "local" transport instead of "http/https" which does an in-JVM call and thus would not dispatch the request over the network.