Charitha's Web Log

When we call a secure web service, the most common way of invocation is to use a policy which is compliant with the service policy at the client side. Usually, the client side policy is placed at the client file system. We have observed how this is done in few posts which published earlier. However, there is a major drawback in this method, user has to change the client policy whenever the service policy is changed. In order to overcome this limitation, we can use Axis2 DynamicClient to derive client policy by referring to the service WSDL which essentially keeps the service policy. Lets see how this can be done using WSO2 WSAS-3.1.* Pre-requisite: Download and install WSO2 WSAS-3.1.* Step 1 We are going to secure the default HelloService shipped with WSAS. We configure HelloService with "Sign and Encrypt - X509 Authentication" policy. In order to do that, first start WSO2 WSAS server by running wso2server.sh which is located at WSO2WSAS_HOME/bin directory. Then, log in to ...

WSO2 QA Test framework has been developed to replace repetitive manual test procedures followed during the release cycles. We identified the tests which provide much ROI with automation and used them for phase1 of the test framework development project. With the introduction of WSO2 Carbon product platform in late 2008, all java based products are implemented using the base carbon platform. All products (9 all together) are released at the same day which is a very different experience specially for a QA team. All products are supposed to go through a set of common tests and a set of product specific tests. All are supposed to work on multiple application servers, multiple JVMs, multiple browsers, multiple operating systems, multiple DBMSs etc.. hell a lot of test combinations! The product count exceeded the number of people in test team. More products are expected to be introduced in near future. Therefore, the only viable solution to manage the QA process is to automating as more te...

The latest product versions of WSO2 SOA platform are available for download now. This release addresses various bug fixes and enhancements. In addition to the usual binary, source and document distributions, WSO2 products are now available as cloud virtual machines . WSO2 cloud virtual machines provides you with the ability to implement your SOA infrastructure in private or public cloud. In this post, we will look at how AMIs of WSO2 Carbon family of products can be used. I will use WSO2 ESB AMI for the demonstration, however you can follow the same steps to start any of the WSO2 Carbon AMI. Pre-requisite: You should have the necessary Amazon EC2 account ready for AMI administration. AMI EC2 API tools should be installed in your computer. You may refer to this tutorial in order to set up the infrastructure. Step 1 Go to WSO2 ESB home page in Oxygen Tank. Click on WSO2 Cloud Service under the Download icon. You will find WSO2 ESB cloud virtual machines in that page. Take a note of ...