Carbon as a foundation

"Carbon isn't a 'product'", emphasized Paul, during his webinar [WSO2 Synergies: The Carbon Story (repeat)] last night....
Once more got the chance of enjoying the introductory presentation on Carbon!!!... :)

Follow Paul's blog to get updated with the Carbon Story...
http://pzf.fremantle.org




ESB http://wso2.org/projects/esb/java
WSAS http://wso2.org/projects/wsas/java
Registry http://wso2.org/projects/registry
Business Process Server http://wso2.org/projects/bps

Nice Experience - WSO2Carbon

So as a user I have had a nice experience with the WSAS of WSO2 Carbon, saving a lot of time…..
1. It’s open source.
2. I was able to figure everything out on my own, during this process.
3. Self-learning is not very difficult for an average user in case of WSO2 Carbon.
4. It is easy to ‘install’ (No configuration, no setup, no… nothing difficult)
5. Easy to transfer (Can I say portable??)
6. A strong structure of issue tracking.
7. Basic functionalities are self-explanatory.


Most of the technical details and the advantages in the advanced user or developer point of view can be found in the relevant blogs. Here, I am just sharing the story about my first impression on Carbon…

WSO2 Carbon ~ Trying it!

I was not very familiar with WSO2 Carbon at that time. I had just started playing with it. WSO2 Web Services Application Server (WSAS) looked more than attractive to me to play with.

In the Admin Console of WSAS, we have Add Axis2 Service option in the left hand side panel. I uploaded our aar using that Add option. A success message appeared as expected. Then I clicked the List Menu for deployed services. There I clicked Try this service option for the MsgBoxService. I was taken to the Try the MsgBoxService service. Wonderful! It has a nice GUI with textboxes to input the values. Getting the output instantly, I was walking through WSAS to see more. Found something under the monitor menu. SOAP Tracer!!! I configured the Configuration Status to ON. A warning says “Tracing will have a performance hit. Use with caution.” Who cares? I will not overuse this functionality however. Then I went back to try the service. After trying all the four operations, I came back to the SOAP Tracer. Wow… It has all! SOAP messages for both the request and the response. Then it took me just minutes to copy-paste those SOAP messages for the four operation requests, into the respective SOAP/XML-RPC Request of Jmeter.

The conclusion of the performance analysis was not much difficult after that. Just adding a variable in place of the input value, a counter to have about 1000 users each user as a thread, timer, Loop Controller to send 10 msg for each user’s msgbox, and finally Graph results to see the performance of each operation visually.

Performance Testing

Finally we were wrapping up the Messagebox program we had created using Apache Axis2. Now comes the final point. Yes, we had to do a performance analysis using Apache Jmeter. Our Messagebox program has four operations: createMessagebox, storeMessages, takeMessages, deleteMessagebox. Being a web service, we have the axis2 archive (.aar) of our program.

Yes. We have developed a client to run our web service. That was not very difficult. We have been blessed with wsdl2java, and given the WSDL, it will auto-generate the Client Stub and the Server Skeleton. Completing server skeleton with the necessary logic obviously has cost a much longer time, when compared with the writing of client code using the client stub. Now during the performance testing, we are going to use the same web service (i.e. the same web service), but we will not use the client we have developed. Rather we will be using our test plan generated using JMeter, as the client to run our server. Now we need SOAP/XML-RPC Request for each operation.

Having that history behind us, now I am in action. This Jmeter performance analysis will be saved as a .jmx file. I have written some SOAP messages on my own, but not yet completed. Here I meet an angel.