Feeds:
Posts
Comments

Archive for the ‘WSO2 ESB’ Category

WSO2 ESB Performance

I uploaded  an  article [1] with the latest performance numbers of WSO2 Enterprise Service Bus. It is quite a long time since WSO2 last published it’s ESB performance numbers. During that time it released performance numbers on customer request on various instances.

WSO2 ESB has undergone various feature additions during that time. It is now based on WSO2 Carbon (with ESB 2.x family of products). WSO2 Carbon[2] provides the development framework and the runtime environment for the WSO2 products including the ESB. I am not going to talk all the new features here. WSO2 Oxygen Tank library is full of articles/tutorial written on WSO2 ESB. So decided it is time again to publish some performance numbers.

In Previous articles the performance was compared with different open source and commercial competitors.That is a time WSO2 was desperately searching for a niche in the middleware market. Now WSO2 ESB has established it’s ground firmly in the middleware ESB market, it has changed it’s approach on publishing performance numbers. No comparison with other vendors. We just publish our numbers and provide a performance test framework freely for our customers(or any interested user) to download and verify the results and, also do perform their own comparison with the products of their choice. This performance testing framework will be available soon on WSO2 Oxygen Tank.

This article has taken a different approach from previous performance test articles of WSO2 ESB in various aspects. I would like to discuss some of them here

First, the way performance presented is different. To quote from the article

“For each scenario each message size load is generated with concurrency varying from 20 to 300(increasing by 40 at each stage). Then the maximum transactions per second(TPS) achieved during this concurrency range is recorded as the Transactions per second(TPS) for the corresponding scenarios message size.”

What does that mean?.  From the experience of the previous performance tests I could see that  WSO2 ESB performs best at the concurrency range from 20 to 300. So I decided that the best performance number for a particular message size within that range would be the best choice to present to the reader. My original plan was to break several ranges like

20-300, 300-900 and 900-1800. But that could overly make the results complex. So I omitted the higher concurrency results from the article to avoid unnecessary cluttering.

Besides I wanted to capture results for a wider message size range. I thought that the concurrency range mentioned in the article best suited for that purpose.

Also my approach this time is to present the numbers in best possible way, so that one could easily grasp the results in easy to read graphs. When you compare the graphs from round3 this could be easily understood.

Note that I have done the performance test without keep alive enabled. HTTP keep-alive is great to improve performance. But it is not the best way to say that your product has good performance. My understanding
is that, to emulate how the server react to real world scenario of concurrent users, the best way is to assume that each tcp connection represent a user. So my decision was to ignore how many requests each user do on a particular connection.

In the article I have provided enough information to reproduce the performance test scenarios. . I have not done any special tweaks to gain extra bit of performance, other than the things I have mentioned in the article. Providing the exact scripts, messages in files etc for somebody to immediately reproduce the results is a bonus. Yet WSO2 have planned a something more than a bonus. It will soon upload into Oxygen tank a great open source performance test framework which I sincerely hope will serve as a good platform for benchmark tests for many open source projects. It is a fun to reproduce the performance numbers provided in the article  using that tool.

[1] http://wso2.org/library/articles/2010/08/wso2-esb-performancenew

[2] http://wso2.com/products/carbon/

Read Full Post »

I have a proxy service deployed in my esb server. This service will verify the signature of the incoming messages and decrypt them before sending it to the target service. I send the messges to ESB using WSO2 wsclient which is bundled with WSO2 WSF/C. To sign the messages I use Alice’s private key. To encrypt the messages I use the public key received from ESB ( You can find Alice’s samples keys bundled with WSF/C samples. More on ESB keys during this article).

To deploy that service I followed the following procedure. I first created a simple pass through service using the Add/Proxy Service menu. I gave the target server as my WSAS instance running on a separate server. After that I selected the created proxy service and added security using the Sign and Encrypt option. I also gave the private and trusted key store as wso2carbon.jks. I also added Alice’s public key to the wso2carbon.jks key store using WSO2 ESB admin console facilities.

Now my services are ready, I wanted to use WSO2 wsclient (A command line web services client tool) to access the service through ESB. To learn more about how to use wsclient and how to secure your messages using it please refer to [1] and [2]. To encrypt and sign messages wsclient use server certificate in PEM format. We give the server certificate using –recipient-certificate option.  Usually I use my wsclient command line tool to access web services deployed in Apache2 server. So I knew how to generate my server certificates in PEM format from  PKCS key stores. But did not know how to generate PEM certificates from JKS key stores. Howerver I could not find a direct way to do this. Following is how I did this using java keytool and openssh x509 commands.

keytool -export -file wso2carbon.cer -keystore /wso2carbon.jks -alias wso2carbon

In this step we create a wso2carbon.cer file using wso2carbon.jks server keystore. Here you will be asked the password for the keystore entry alias.

After that I executed the following command to create the recipient certificate in PEM format.

openssl x509 -out wso2carbon.pem -outform pem -in wso2carbon.cer -inform der

Now I could use the created pem certificate to execute the following command to access the service

./wsclient –log-level error –no-wsa –soap –no-mtom –sign-body –key /alice_key.pem –certificate /alice_cert.cert –recipient-certificate /wso2carbon.pem –encrypt-payload –policy-file ./policy.xml  http://localhost:8280/services/SignEncProxy < ./data/POService.xml

 

[1] https://damithakumarage.wordpress.com/2008/10/04/access-secure-enabled-web-services-from-command-line/

[2] https://damithakumarage.wordpress.com/2010/05/25/using-wso2-wsclient-generate-your-custom-soap-messages-for-you/

 

Read Full Post »

Try Open Source SOA!

Good read, Mike Kavis explains the strength of open source SOA. In this article he also explain the WSO2 SOA stack.

http://www.cio.com/article/440370/Tight_Budgets_Try_Open_Source_SOA_

You can find news release for the case study which is mentioned in Mike’s article here.  You can download the case study here.

Read Full Post »

One of the best way to get you immediately get aware of the concepts

http://video.google.com/videoplay?docid=1710477770315021899&q=type%3Agoogle+engEDU

Read Full Post »

There is this new implementation of Reliable Messaging from WSO2 called Mercury. You can download it from here. There is discussion going on as to whether Mercury should be sequal to Sandesha2 as Sandesha3 or not. Ppl who argue against it has basically following points

1. When adding features to current Mercury it will ultimately become as complex and as ugly as Sandesha2. In other words they have concerns whether Mercury solve existing Sandesha2 problems.

2. Sandesha2 is tested for performance and results are satisfactory and have doubt about Mercury performance.

3. Sandesha2 is feature rich.

4. Mercury still only provides only a very basic feature set and therefore they can’t adopt it at this stage.(RM 1.1 spec is not supported)

What those ppl accept in general is that

Sandeha2 is complex and need lot of improvement and that improving is not easy.

Ppl who argue in favour in Mercury have following points

1. Mercury architecture is based on a state model which is clean.

2. It would not be susceptible for race conditions and dead locks(I heard some ppl worry about that in Sandesha2)

3. Mercury is open for improvements and they beleive that it could be done in a cleanly fasion.

I am these days considering implementing Mercury/C for Axis2/C web services platform. When I had an initial look at the architecture diagrams and Mercury/Java code I understand that it is actually very clean and easy to adopt for writing Mercury/C, although I am not satisfied with the quality of the architecture documents that shipped with the Mercury release. It seems that nobody has reviewed it. For example it mention CSR but nowhere it has defined what is CSR(Of course Create Sequence Response). I must thank Amila Suriarachchi for coming up with this innovative design. I will continue to analyse Mercury architecture and most probably  will implement Mercury/C  which  I beleive could be completed in about 3 months time once started.

Read Full Post »