Popular Posts

Thursday, February 19, 2009

Performing QA with last minute code changes

Changes are inevitable at the last moments of most projects. There are urgent requirements to do such changes and there will be situations where you
must do some critical fixes before shipping the product. In any case, both development and QA teams must be in a common understanding on how such changes affect the stability of the AUT (Application under test).
Sometimes, it will be required to repeat a complete functional test cycle after a significant change. In such cases, sufficient time must be allocated to do a full round of functional testing.
Or else, everyone (both development and QA) should take the responsibility if something goes wrong.
It is a common practice in most organizations to transfer responsibility to QA teams when clients find issues in a product after a release, which is not always valid in agile processes where everyone test and contribute to quality assurance regardless of their title/role playing in the project.
After doing a significant change at the last moment without providing enough time to complete the testing on affected areas, there is no point to blame QA. Everyone should take the responsibility.
This is one of the weird situations most QA teams come across regardless of the process being followed. With better understanding about the tasks and responsibilities of each other, project teams can avoid these concerns. Otherwise, rigid hard core processes must be followed although they are not always realistic.
After all, each team member should understand that QA is not a trivial activity. It takes time and effort to setup and configure test environments, uncover bugs, reproduce them in different platforms, report through defect tracking systems, verify the reported bugs in new builds, ensure the issues are not regressed.
A few months back, Krishantha posted a nice blog entry about how last minute changes affect software QA testing which is a good reference for anyone interested in this.

Switching wso2 carbon server to maintenance mode

When wso2 carbon server (WSO2 WSAS, ESB, Registry and BPS) is running in production environments, it may be required to perform some essential upgrades without shutting down the server.
[WSO2 Carbon is the base platform for all WSO2 Java products. wso2 carbon server refers to any of WSAS, ESB, Registry or BPS server]

WSO2 Carbon based products are equipped with JMX based monitoring and management facilities, through which you can switch to maintenance mode.

Step 1
In order to enable JMX management, you must uncomment the JMX port element in CARBON_HOME/conf/carbon.xml

<Ports> <!-- The JMX Port --> <JMX>9999</JMX> </Ports>

CARBON_HOME is the directory where you extracted wso2wsas-3.0, wso2esb-2.0, wso2-registry-2.0 or wso2-bps-1.0 binary distributions.

Step 2

Start your WSO2 carbon server (WSAS, ESB, Registry or BPS).
You will notice that the JMX service URL will be printed in the startup console as follows.

Step 3

You can use JConsole as the client for JMX monitoring and management. Start command prompt (or shell in linux), type Jconsole and hit enter. JConsole:Connect to Agent window will be popped up.
Enter JMX url (service:jmx:rmi:///jndi/rmi://YourHost:9999/server)
Enter admin as user name and password. Note that, any user with admin privileges can log in to JMX.
Click on Connect.

Select MBeans-->org.wso2.carbon-->ServerAdmin-->Operations
You will see the following server admin operations.

Step 4

Suppose you have a web service which is in the process of responding to a client. Now, you may want to do some upgrades in the server without shutting it down.
Click on startMaintenance() button in the jconsole.
Now server is being running on maintenance mode. It does not accepts service requests in this mode. Your client application may get "org.apache.axis2.AxisFault: Connection refused" error.

After server upgrade is done, click on endMaintenance() button. Server will be switching back to normal mode. You will notice that the message transmission of your client will be resumed.

Tuesday, February 17, 2009

How to deploy WSO2 BPS on Apache Tomcat


WSO2 Business Process Server (BPS) -1.0 is the latest member of WSO2 SOA platform. I have demonstrated a basic scenario using WSO2 BPS standalone distribution in a previous blog post. WSO2 BPS (and all other carbon based products) can be deployed in most of the servlet containers with a few configuration steps. Lets deploy WSO2 BPS on Apache tomcat 6.*.

Step 1
Download WSO2 BPS-1.0 from here. Extract the downloaded zip into a directory. Copy conf, database, repository and resources directories in to a new folder. Say it is carbon-repo (i.e:- C:\bps\carbon-repo)
Also, create a new directory, lib\extensions under carbon-home.

Step 2
Lets refer to your tomcat installation directory, CATALINA_HOME. Go to CATALINA_HOME\webapps directory and create a new folder, bps.
Now, copy wso2bps-1.0\webapps\ROOT\WEB-INF to CATALINA_HOME\webapps\bps

We need to enable https in tomcat. Therefore, edit CATALINA_HOME\conf\server.xml by adding the following entry.

<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true" SSLEnabled="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile = "C:\bps\carbon-repo\resources\security\wso2carbon.jks"

Make sure to give the exact location of wso2carbon.jks as highlighted above.

Step 4
We have done the configurations required in tomcat. Now, we must do the necessary configurations in a set of config files shipped with WSO2 BPS. We will update carbon.xml, axis2.xml, registry.xml and user-mgt.xml which can be found at carbon-repo\conf directory.
First, open carbon.xml and update the ServerURL element as follows.


Note that we have configured tomcat to run on 8443 port.
Save and close carbon.xml.

Open registry.xml and update DB URL as follows.

Now, open user-mgt.xml and update database URL as follows.


Make sure to specify the absolute path of the WSO2CARBON_DB in both of the above elements.

It is required to change the contextRoot in the service path of axis2.xml. Change it to match with the web application directory name we have given in step2. In our case, it is bps.

<parameter name="contextRoot">/bps</parameter>

We must change the http and https ports in In Transports section of axis2.xml as follows.

<transportReceiver name="http"
<parameter name="port">8080</parameter>


<transportReceiver name="https"

<parameter name="port">8443</parameter>

Step 5
We have almost completed the required configurations. Before starting tomcat with those changes, we need to do one more change. Due to a bug in BPS-1.0, we must copy org.wso2.carbon.geronimo.jta.1.1.spec-1.1.jar (which is available at the lib\extensions directory of the WSO2 BPS binary distribution) to carbon-repo\lib\extensions and CATALINA_HOME\webapps\bps\WEB-INF\lib directories.

Step 6
Now, open a new command window and change the directory to CATALINA_HOME/bin.
Define an environment variable called CARBON_HOME and set the path to your carbon-repo directory.

In windows; set CARBON_HOME=C:\bps\carbon-repo
In linux; export CARBON_HOME=\home\user\bps\carbon-repo

Start tomcat from the same command window/shell.
catalina.bat run

WSO2 BPS will be started successfully. You can access the management console using https:\\localhost:8443\bps\carbon

Sunday, February 15, 2009

Visits to this blog

The success of this blog can easily be determined by looking at the above summarized report of visitors who accessed during the last year. I have started this blog to discuss/share my ideas on software quality assurance and my subject domain, SOA/web services. The majority of the posts were written to help users to solve simple issues which were not documented anywhere. I do not use this blog to discuss my personal life, politics etc..
I was able to build a community around my blog during the last year which encouraged me to write more and more useful posts. Sometimes, I could not maintain a consistent blog post publishing rate due to the tight project release deadlines. However, it did not affect the visits of regular user base.
With the releases of WSO2's revolutionary SOA platform, Carbon, there will be a lot of things to be demonstrated. Stay tuned.. This blog will be updated frequently with more and more how-tos..

Friday, February 13, 2009

A quick look at WSO2 Business Process Server (BPS)

WSO2 Business Process Server (BPS) is the newest member of WSO2 SOA product suite. It is developed on top of the revolutionary WSO2 Carbon platform hence the components of WSO2 ESB, WSO2 Web services application server (WSAS) can easily be plugged in.
WSO2 BPS provides the facilities to execute business processes written using the WS-BPEL standard. It uses Apache ODE as process server engine.
I'm going to demonstrate how a simple BPEL package will be deployed in WSO2 BPS and some of the features such as process instance creation and process summary statistics.

Step 1
Download WSO2 BPS-1.0 from here. Extract the downloaded zip into a directory. We will refer to the extracted location as BPS_HOME

Step 2
Start business process server by running wso2server.bat{sh} which can be found at BPS_HOME/bin

Step 3
Access BPS management console using https://localhost:9443/carbon. Log in to management console using the default administrator credentials, admin/admin
BPS Home page will be displayed as follows.

Step 4
We are going to deploy a new BPEL package. BPEL package is a ZIP archive with all the relevant deployment artifacts. BPEL package should contain the deployment descriptor, one or more process definitions(.bpel or .cbp), WSDL and XSDs. You may find more information about these artifacts in Apache ODE user guide.
In this demonstration, I will use a sample BPEL package (HelloWorldNew.zip) used for testing purposes. You can download it from here.
Now, select Business Processes --> Add BPEL in the left navigation menu of WSO2 BPS management console. You will be directed to New BPEL Package page. Browse the downloaded HelloWorldNew.zip file in your file system and click on upload.
You will see the confirmation message if the deployement is successful.

Step 5
We have completed adding a new BPEL package. You can find the deployed package in the Deployed Packages page as follows.

Step 6
When you upload a new BPEL package, the associated business process will be created and will be listed in Deployed Processes page. You can find the process definition and more details of the process by clicking on the process ID.

Step 7
When a new BPEL package is deployed, the services which are defined as partner links in the process definition (services participating in a particular BPEL process) will be listed in the Deployed Services page as shown below. You will notice the HelloWorldNew service at the top of the table.

Step 8
Now we can create process instances by invoking this HelloWorldNew service. The simplest way of invoking the service is using "Try this Service" feature associated with the service. Click on Try this Service link in HelloWorldNewService.
You will be directed to Try the HelloWorldNewService service page where you can give any string value as input. Click on Process button to invoke the service.
With different string inputs, invoke the service few more times.

Step 9
After invoking the service, select Business Processes --> Instances in the left menu.
You will see the generated process instances as shown below.

With WSO2 Business Process Server (BPS), you can secure processes using WS-security and enable reliable messaging with minimum configuration steps. I will demonstrate these QOS (quality of service) features in a future post.

For more information about Business process server, access WSO2 BPS home page at WSO2 Oxygen Tank.

Thursday, February 5, 2009

WSO2 Elevator Pitch

Short introduction to WSO2 from the founders....

Wednesday, February 4, 2009

QA does not exist if at least a lightweight process is not adopted

There are obvious differences between software quality assurance (SQA) and software testing. SQA is a much more systematic and process based approach. You can't expect any engineer to act SQA role any time. That needs experience, QA mind set and a lot more. That is true whether you follow traditional or agile development approach.
Having said that, I want to emphasize the fact that there is no QA if you do not follow at least a simple development process. QA faces a chaotic situation and everything is screwd up.

More on QA practices to follow......