Popular Posts

Thursday, December 30, 2010

Are you doing software testing or quality assurance?

While going through some of the software QA related stuff, I found a very nice presentation done by Michael Bolton. There, he challenged the traditional way of defining software quality assurance teams. While agreeing with his insight on QA, I thought to highlight the contents included in one slide of his presentation.

If you are involved in software quality assurance (or if you think that you are a software QA person) then the following will be able to help you to get yourself categorized into the correct role that you are playing in your organization.

Do you
  • design the product?
  • hire programmers?
  • decide which bugs to fix?
  • allocate staff?
  • set the schedule?
  • fix problems in code?
  • decide on raises?
  • allocate training budgets?
  • produce manuals?
  • choose the development model?
  • fire some programmers?
  • control the budget?
  • set the company's strategic direction?
If the answer for all of the above questions is , YES, then you assure the quality of the products produced by your organization. So you are doing software QA!

I have never found a QA/testing team who performs all of the above activities in their job. But most of us test the products. We explore the products in order to reveal the issues and provide feedback to the stakeholders of the product under development. Therefore our role is Software testing NOT quality assurance.

James Bach defines software testing as questioning the product in order to evaluate it.

Cem Kaner says software testing is a technical, empirical investigation of a product, done on behalf of stakeholders, with the intention of revealing quality-related information of the kind that they seek.

So, there is no assurance!

Monday, December 27, 2010

Are you testing or checking?

Just found a nice post from Micheal Bolton who expressed his opinions about the difference between Testing and Checking.

Extracted from the post;

Checking Is Confirmation

Checking is something that we do with the motivation of confirming existing beliefs. Checking is a process ofconfirmation, verification, and validation. When we already believe something to be true, we verify our belief bychecking. We check when we’ve made a change to the code and we want to make sure that everything that worked before still works. When we have an assumption that’s important, we check to make sure the assumption holds. Excellent programmers do a lot of checking as they write and modify their code, creating automated routines that they run frequently to check to make sure that the code hasn’t broken. Checking is focused on making sure that the program doesn’t fail.

Testing Is Exploration and Learning

Testing is something that we do with the motivation of finding new information. Testing is a process of exploration, discovery, investigation, and learning. When we configure, operate, and observe a product with the intention of evaluating it, or with the intention of recognizing a problem that we hadn’t anticipated, we’re testing. We’re testing when we’re trying to find out about the extents and limitations of the product and its design, and when we’re largely driven by questions that haven’t been answered or even asked before. As James Bach and I say in our Rapid Software Testing classes, testing is focused on “learning sufficiently everything that matters about how the program works and about how it might not work.”

Tuesday, December 14, 2010

WSO2 Application Server - Run web applications and web services on the same server

Today WSO2 released its newest product (rather a renamed version of WSO2 web services application server - WSAS, with a lot of improvements), WSO2 Application Server - 4.0.0
WSO2 Application server is an unified platform to host web services and web applications together. This completely open-source product is based on world's most popular web application server, Apache Tomcat and No:1 web service engine, Apache Axis2.

WSO2 Application Server is part of WSO2 Carbon platform hence it brings the power of highly flexible component model hence your web applications can utilize the features provided by carbon platform. For example, web applications can be authorized using WSO2 identity and user management components. As the other WSO2 products, WSO2 application server comes with a rich graphical management console which allows you to manage your web applications very easy and effective manner.

Lets have a glance at WSO2 Application Server......

Step 1
Download WSO2 Application Server-4.0.0 binary distribution from wso2 oxygen tank
Extract the downloaded binary. We will refer to the downloaded directory as CARBON_HOME

Step 2

Go to CARBON_HOME/bin directory and run wso2server.sh {bat}
Once the server is started, access management console using https://localhost:9443/carbon
Log in to management console using the admin credentials (username= admin, password=admin)



Step 3

At the main menu, you will find, Manage --> Web Application option. You can upload new web apps or view the existing web applications in there.
Click on Manage --> Web Applications --> Add
You will be directed to web app uploading screen where you can upload any war file.



Browse for a web application archive (war) in your file system and click on upload. You will be prompted with the confirmation message if the deployment is successful.

Step 4

Once the web app deployment is done, it will be listed in Running Web Applications page as shown below.



If you click on web application context in the web app list, you will be directed to web app dashboard as follows. You can carry out multiple operations on the deployed web app within this dashboard. For example, you can reload web app, expire all sessions etc..



Step 5

As I described at the beginning, you can deploy various kind of web services together with web applications using WSO2 Application Server. You will find Manage --> Services menu option at the left navigation pane in management console, there you will see Axis2 Servces, Jar Services, Spring Services and JAX-WS service deployment options as shown below.



Download WSO2 Application Server-4.0.0 today and try this out your self.

Sunday, November 28, 2010

QA testing in agile world - Attitude matters most!

Few short tips about a viable approach for testing in agile world. May be valid for most organizations.

  • Understand your development team first. Study each engineer and adjust your way of acting (communication, management etc..) according to the team you are working on
  • Do not act as a quality police. Everyone is responsible for quality. It is your task to guide the others NOT finding faults and complain
  • Be as flexible as you can in all situations
  • Be quick on everything - learn, design, implement, configure, deploy quickly and test fast
  • Be innovative
  • Identify highly risked features first and start hunting bugs

Finally;
  • CREATE A VALUE as a tester for your organization and BUILD the CONFIDENCE among the team!

Thursday, November 25, 2010

Invoking secure web services using SOAPUI - part1

SOAPUI is a very useful free tool which can be used in SOA testing. Service invocation using SOAPUI is straight forward and you can find a lot of references by surfing web. However, there are limited information about invoking services with various QOS (Quality of Service) features such as WS-Security, WS-Addressing etc.
This post takes you through the simplest QOS scenario, a web service is secured with UserName token policy and how SOAPUI is used to invoke such a service.

I will use the default HelloService hosted in WSO2 WSAS in this demonstration but the service invocation approach is similar with any service provider.

Pre-requisites:
1. Download and install SOAPUI-3.6.1 or later (free version)
2. Download and install WSO2 WSAS-3.*

Step 1

First, we need to secure a web service hosted in WSAS. We will configure HelloService so that only the users in admin group will be allowed to invoke the service. In order to do that, start WSO2 WSAS and log in to management console. Then, select HelloService from Deployed Services page.
You will be directed to the service dashboard of HelloService as follows.



Click on Security link and Select "Enable Security" option. Then select, UserNameToken security scenario.



In the next screen, select admin user group and click on finish to apply the security policy for HelloService.

Step 2
We have configured server side security policy. If you look at the WSDL of HelloService (http://localhost:9763/services/HelloService?wsdl), you will notice that UserNameToken security policy is added to the service.
Now, we need to configure SOAPUI project to talk to HelloService with the required user credentials.

First, start SOAPUI and create a new project. Specify https://localhost:9443/services/HelloService?wsdl as the initial WSDL. Keep the other default settings.
You will see the following project structure.



Replace ? with an input value in the request editor and run the test. You will encounter a SOAPFault, Missing wsse:Security header in request, since we did not send security headers with the request.
Lets configure client side security now. In the Request Properties pane of SOAPUI project, you will find the following properties.

Username
Password
WSS-Password Type
WSS TimeToLive

Specify the following values for the above properties.

Username = admin
Password = admin
WSS-Password Type = PasswordText
WSS TimeToLive = 2000

Run the test. Have a look at the raw request view. You will see security header is added to the request.
Thats all! We will look at more advanced scenarios such as signing and encrypting messages with SOAPUI in future posts.



Saturday, November 13, 2010

Java bench - Simple and lightweight service load testing tool

At WSO2, we use various types of tools and programmatic approaches to load, stress and performance test SOA middleware products. Out of them, one particular tool is part of almost all engineers workspaces. It is Java bench (or java-ab).
Java bench is the java clone of the popular ApacheBench load generator customized for better HTTP1.1 support.

Java bench is a very simple and easy to use utility. One of the greatest advantages of using it for performance testing is, its lesser overhead on load generation machines. Most of the load generators consist of rich UIs and reporting utilities hence the load generator it self consumes considerable amount of CPU and memory when you run performance testing in single server. It is always not practical to run load generators in separate machines. Sometimes we need to run load/performance tests against a server running on a local machine in order to provide quick feedback about the product under test or reproduce perf/memory issues. In these situations, Java-bench is the ideal solution.

Lets see how we can run a basic performance test using java bench.

Pre-requisites:
Linux or windows OS
jdk1.5 or higher

Step 1
Download Java bench from here and extract the downloaded zip file.

Step 2
Go to the root of the extracted directory and run 'java -jar benchmark.jar' to see the available options.

usage: HttpBenchmark [options] [http://]hostname[:port]/path
-v Set verbosity level - 4 and above prints response
content, 3 and above prints information on headers, 2 and above prints
response codes (404, 200, etc.), 1 and above prints warnings and info.
-H
Add arbitrary header line, eg. 'Accept-Encoding:
gzip' inserted after all normal header lines. (repeatable)
-n Number of requests to perform for the benchmarking
session. The default is to just perform a single request which usually
leads to non-representative benchmarking results.
-T Content-type header to use for POST data.
-c Concurrency while performing the benchmarking
session. The default is to just use a single thread/client.
-h Display usage information.
-i Do HEAD requests instead of GET.
-k Enable the HTTP KeepAlive feature, i.e., perform
multiple requests within one HTTP session. Default is no KeepAlive
-p File containing data to POST.

Step 3

We will run a load test against one of the publicly available web services. I use a simple web service hosted in xmethods which generates a list of prime numbers that are less than a specified max value.
First you need to invoke this service using SOAPUI or some other client and capture the SOAP request message. Then save it as a xml in your file system.

Sample request:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://microsoft.com/webservices/">
<soapenv:Header/>
<soapenv:Body>
<web:GetPrimeNumbers>
<web:max>56 </web:max>
</web:GetPrimeNumbers>
</soapenv:Body>
</soapenv:Envelope>

Step 4

Now, we can use java bench to send series of requests to the above web service as follows.

java -jar benchmark.jar -p SoapRequest.xml -n 100 -c 10 -k -H "SOAPAction: http://microsoft.com/webservices/GetPrimeNumbers" -T "text/xml; charset=UTF-8" http://www50.brinkster.com/vbfacileinpt/np.asmx

As you can see, we specify the soap request xml with -p parameter. -c specifies the no.of concurrent threads/clients used in the test. -n is used to specify the no.of requests transmitted per a keep-alive connection. In our example, each client carries 100 requests therefore 1000 total requests will be sent to the service. -k enables HTTP keep-alive so that multiple requests share the same HTTP session. -H is used to specify the HTTP headers. In our example, SOAPAction HTTP header is appended to the message. You can find the relevant SOAPAction from the WSDL of the service. -T is used to specify the Content-Type header of the request. The last parameter is the endpoint of target service.

After the test is completed, you will see the result as shown below.

Server Software: Microsoft-IIS/6.0
Server Hostname: www50.brinkster.com
Server Port: 80

Document Path: http://www50.brinkster.com/vbfacileinpt/np.asmx
Document Length: 429 bytes

Concurrency Level: 10
Time taken for tests: 59.378401 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 756000 bytes
Requests per second: 16.84 [#/sec] (mean)
Time per request: 593.784 [ms] (mean)
Time per request: 59.378 [ms] (mean, across all concurrent requests)
Transfer rate: 7.22 [Kbytes/sec] received
5.51 kb/s sent
12.73 kb/s total

Simple. Isn't it? We will look in to more interesting tests with java-bench in future posts.

Friday, September 24, 2010

How to call Oracle Stored Procedures from data services

An Oracle stored procedure is a program stored in an Oracle database which allows business logic to be embedded inside database as an API. You can expose the stored procedures as web services using wso2 data services server. This example takes you through creating a simple stored procedure in an Oracle DB and expose it as a data service using WSO2 Data Services Server.

Pre-requisites:

Download wso2 data services server from here
Oracle 10g or later

Step 1: Create and Populate sample database

First, open sqlplus shell and log in to DB as follows.

sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Sep 23 22:52:01 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.

SQL> connect sys as sysdba;
Enter password:
Connected.

We should create a user and grant him the necessary privileges as follows.

SQL> create user sample identified by sample account unlock;

User created.

SQL> grant connect to sample;

Grant succeeded.

SQL> grant create session, dba to sample;

Grant succeeded.

SQL> exit;

Now logged in as the new schema user as follows.

sqlplus sample/sample@orcl

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Sep 23 22:52:01 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.

SQL> connect sys as sysdba;
Enter password:
Connected.
SQL>

Create a table and insert data as follows.

SQL> create table employee (id number primary key, name varchar(100), address varchar(100));

SQL> insert into employee(id, name, address) values (1, 'charitha', 'colombo');
SQL> insert into employee(id, name, address) values (2, 'john', 'galle');
SQL> insert into employee(id, name, address) values (3, 'michel', 'otawa');
SQL> insert into employee(id, name, address) values (4, 'carl', 'dallas');
SQL> insert into employee(id, name, address) values (5, 'chanmira', 'colombo');
SQL> commit;

Now we are ready with oracle database and schema.
Lets write a simple stored procedure to insert more data to employee table.

Step 2: Writing a simple stored procedure

SQL> create or replace procedure addEmployeeSP(id number, name varchar, address varchar) is
2 begin
3 insert into employee (id, name, address) values (id, name, address);
4 end;
5 /

Step 3: Copy oracle jdbc driver

In order for wso2 data services server to communicate to oracle DB, we should download oracle jdbc driver (ojdbc14.jar) and copy in to DS_HOME/repository/components/lib directory.

Step 4: Create the data service through UI wizard

First, start wso2 data services server by running wso2server.sh {bat} which can be found at DS_HOME/bin
Then access management console through https://localhost:9443/carbon and log in using default admin credentials (admin/admin)

Click on Data Service --> Create in the left menu which will bring up data service creation wizard.

Enter a name for the data service and click on next. (For this example, I have specified "BlogExampleDataService" as the service name)



In Data Sources screen, click on Add new data source link and specify a data source ID and select RDBMS as the data source type. Then select Oracle as the Database engine and enter the db info as follows.

Driver Class = oracle.jdbc.driver.OracleDriver
JDBC URL = jdbc:oracle:thin:sample/sample@10.100.1.10:1521/orcl
User Name = sample
Password = sample



Click on "Test Connection" to see whether you can connect to oracle server correctly. Then click on save. Now we have created a data source hence we can proceed through the wizard.

Click on Next to move to query definition page. Select Add New Query to create a new query for our data service.

Enter a query ID (ex:- employees) and select the data source we just created from the Data Source drop down.

We can specify our SQL statement in the SQL text area. We need to call the oracle stored procedure which has been created earlier. You can enter "call addEmployeeSP(?,?,?)" as the query to call oracle stored procedure. ? denotes the input parameters which should be passed to the stored procedure.



Next, click on Add new input mapping and add three new input parameters since our query accepts 3 different parameters.



After adding all 3 input parameters, the query will be looked as follows.



We can save the query now. Our stored procedure inserts employee records in to the table therefore it does not return anything.
Because of that, the output mappings are not required for the query.

In order to check whether the records are correctly added to the database, lets create another query, selectEmployees as shown in the following screen.



Now, we have created both queries. Lets add operations which are necessary to run these queries.

Click Next in the Queries screen to proceed through the wizard which will bring up Operations page. Click on Add New Operation link. Specify operation name, addEmployee and select Query ID, employees.



Similarly, add an operation for selectEmployee query and name it as selectAllEmployees.

Click on Finish to deploy the data service. Once it is deployed, the service will be shown in the service list. Click on Try this service link to test the service.
In there, you will find two operations, addEmployee and selectAllEmployees. First invoke addEmployee operation by specifying id, name and address.
id=6
name=bloguser
address=notown

Now, if you invoke selectAllEmployees operation, you will see that the employee table has been updated with a new record.



Thats all! Drop me a mail or post your question at wso2.org forum if you have any questions about WSO2 Data Services Server.





Wednesday, September 22, 2010

Input validation of data services

Input validation is a new feature included in the latest version of WSO2 Data Services Server (WSO2 DSS). With this, the further processing of a data service request message can be stopped at the service layer without reaching the backend data source based on a pre-defined input validation logic.
This is achieved either using a set of built in validators or custom validator implemented by the service author.

There are four different built-in validators.

1. Long range validator
This can be used to validate an integer input parameter value as follows.

<param name="id" paramType="SCALAR" sqlType="INTEGER" type="IN" ordinal="1">
<validateLongRange minimum="1" maximum="40" />
</param>

2. Double range validator
This is useful when a validity of a float value has to be checked.

<param name="distance" paramType="SCALAR" sqlType="DOUBLE" type="IN" ordinal="2">
<validateDoubleRange minimum="1.5" maximum="850.45" />
</param>

3. Length validator
This can be used to check whether the input parameter value conform to the speficied string length.

<param name="name" paramType="SCALAR" sqlType="STRING" type="IN" ordinal="3">
<validateLength minimum="2" maximum="20" />
</param>

4. Pattern validator
This validates the string value of the input parameter against a given regular expression.

<param name="indexno" paramType="SCALAR" sqlType="STRING" type="IN" ordinal="4">
<validatePattern pattern="(?:[a-z0-9]" />
</param>

Finally, you can write your own validator based on your requirements and use it in the data service query definition. In order to do that, you must implement org.wso2.carbon.dataservices.core.validation.Validator interface in your custom validator class as follows.


import org.wso2.carbon.dataservices.core.validation.Validator;
import org.wso2.carbon.dataservices.core.validation.ValidationContext;
import org.wso2.carbon.dataservices.core.validation.ValidationException;
import org.wso2.carbon.dataservices.core.engine.ParamValue;

public class MyCustomValidator implements Validator {
public void validate(ValidationContext validationContext, String s, ParamValue paramValue)
throws ValidationException {
if (!paramValue.getScalarValue().startsWith("2")) {
throw new ValidationException("Not starting with 2!!",s,paramValue);
}


}
}

Then, you can build a jar with the custom validator class and place it in CARBON_HOME/repository/components/lib directory. After restarting the server, you can use it inside query definition as follows.

<param name="id" paramType="SCALAR" sqlType="STRING" type="IN" ordinal="1">
<validateCustom class="org.test.MyCustomValidator" />
</param>

Monday, September 13, 2010

Creating value with testing

Jonathan Kohl discusses about creating value with software testing. You will find very important set of points which we must follow in daily QA/testing activities.

Is my testing work defensible? (Cem Kaner talks a lot about this.) Think of a court case. What would a jury think if you testified and described what you did as a tester and why. How did you determine priority? Why did you test some things and not test others? (100% complete testing is impossible, so you have to make decisions to optimize your work. Are those decisions well thought out, or more subconscious? What sorts of things might you be missing that you haven't thought of?)

Read the full article from here


Sunday, September 12, 2010

How to start multiple WSO2 Carbon server instances as windows services

We can start more than one WSO2 Carbon (WSO2 ESB, WSAS, G-reg, GS, Mashup, IS, BPS, BRS, BAM, DS) instance by updating the transport configuration given in mgt-transport.xml (or transports.xml in 2.X series) as explained in here.
Suppose, you need to start multiple carbon server instances as windows services instead of regular wso2server.sh executable.
Then, there is an additional setting which has to be configured.

  • Find wrapper.conf file inside CARBON_HOME/repository/conf

  • Locate "Wrapper Windows NT/2000/XP Service Properties" section

  • Update the Name of the service and Display name of the service in each instance as follows

# Name of the service
wrapper.ntservice.name=WSO2Carbon

# Display name of the service
wrapper.ntservice.displayname=WSO2 Carbon

Wednesday, August 18, 2010

Process vs Tools and Technologies - What should Sri lankan QA community be concerned with?

I have been thinking about discussing the matters related to local QA community in Sri lanka but never got a chance. Recently I was able to meet a lot of folks who are engaged in software quality assurance in various sri lankan organizations in one place at a quality summit. By listening to the presentations and talking with people, I came out with a few basic questions.

Some of them were;
what the biggest concern of software quality assurance in our country? are those processes or tools/technologies? Do we have the necessary trainings or knowledge sharing mechanism to overcome the issues which we face during daily QA tasks?

In my view, the biggest concern of QA in our country is, not having people with enough technical skills. By interviewing a lot of QA folks for the past few years, I personally have a good experience about the way people are approaching QA. Most fresh graduates believe that QA as a first step towards entering in to software industry! Some people joins QA merely to get some understanding about the product/project then move in to business analysis or sales.
Why is this? IMO, it is totally due to the perception of software QA in sri lanka. We, sri lankan QA community, must be responsible for drawing that image on people's minds about QA.
For the past few years, I never noticed any training (were there any?) for educating QA community about the usage of tools in daily QA tasks to be more productive or technical aspects such as performance/automation testing tools. Instead, whenever there is something about QA, it is about CMMI or process frameworks.
I'm not going to say that those are not important. BUT those are not what our teams need at the moment.
People struggle with configuring application server X on operating system Z. QA folks face in to difficulties when automating AJAX based UIs. How QA should be dealt with the frequent UI changes during UI based test automation? How can we be more productive using linux? Do we use any scripting language for automate repetitive configuration tasks? Are we doing continuous integration? Are QA people familiar with build tools such as Maven or Ant? Do we know about exploratory testing? Do we know how to use test coverage tools? Do we report bugs with the adequate logs and find the root cause of them?

I think these are the questions that most of the QA teams have. We should try to be more productive and be experts as a community. We should try to change the perceptive about QA by empowering everyone with the right set of skills.

If people are comfortable with the tools and technology they are handling in daily work life, educating them about processes and process improvements is not a big thing!

Saturday, August 14, 2010

How to deploy WSO2 ESB-3.X on Apache Tomcat

WSO2 DOES NOT ENCOURAGE INSTALLING WSO2 ESB ON TOP OF OTHER APPLICATION SERVERS. WSO2 HAS DECIDED TO DROP SUPPORT FOR WEBAPP DEPLOYMENT MODE OF THE WSO2 PLATFORM AND PRODUCTS.





I have noticed a lot of different articles, blog posts with instructions on deploying WSO2 ESB on Apache tomcat. But I observed that most of them are obsolete and the guidelines are not applicable for the latest ESB versions. Therefore, I thought to put together the steps of setting up WSO2 ESB-3.X versions on Apache Tomcat-6.X

Step 1:
Download WSO2 ESB-3.X. Extract the downloaded zip and copy repository and resources directories in to a new folder. Say it is esb-repo (i.e:- /home/user/esb-repo)

Step 2:
Lets refer to your tomcat installation directory, CATALINA_HOME. Go to CATALINA_HOME\webapps directory and create a new directory, esb.
Now, copy wso2esb-3.0.0\webapps\ROOT\WEB-INF to CATALINA_HOME\webapps\esb
Also, copy wso2esb-3.0.0\lib\log4.properties file to CATALINA_HOME\webapps\esb\WEB-INF\classes

Step 3:
Next, 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 = "/home/user/esb-repo/resources/security/wso2carbon.jks"
keystorePass="wso2carbon"/>

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 ESB. We will update carbon.xml, axis2.xml, registry.xml and user-mgt.xml which can be found at esb-repo/repository/conf directory.

First, open carbon.xml and update the ServerURL element as follows.

<ServerURL>https://localhost:8443/esb/services/</ServerURL>

Note that we have configured tomcat to run on 8443 port.

When we deploy ESB on an application server, it uses the http/https transport provided by the servlet container when communicating with registry. Therefore, we must update the registry HTTP port in carbon.xml. In order to do that, uncomment and update the following element in carbon.xml.

<RegistryHttpPort>8080</RegistryHttpPort>

Thats all we need to update in carbon.xml, save and close the file.

Next, open registry.xml and update DB URL as follows.

<url>jdbc:h2:/home/user/esb-repo/repository/database/WSO2CARBON_DB</url>

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

<Property name='url'>jdbc:h2:/home/user/esb-repo/repository/database/WSO2CARBON_DB</Property>

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

Next, we need to configure a few elements in esb-repo/repository/conf/axis2.xml file.

Locate NIO HTTPS transport listener (HttpCoreNIOSSLListener) element and specify the absolute path of keystore and truststore locations as follows.

<KeyStore>
<Location>/home/user/esb-repo/resources/security/wso2carbon.jks</Location>

<TrustStore>
<Location>/home/user/esb-repo/resources/security/client-truststore.jks</Location>

Similarly update the keystore and trustore paths of NIO HTTPS transport sender (HttpCoreNIOSSLSender)

We should also specify the absolute path of synapse-config directory as follows.

<parameter name='SynapseConfig.ConfigurationFile' locked='false'>/home/charitha/products/esb/esb-repo/repository/conf/synapse-config</parameter>

Step 5
We have almost completed the required configurations. Now, open a new shell and change the directory to CATALINA_HOME/bin.
Define an environment variable called CARBON_HOME and set the path to your esb-repo directory.

In windows; set CARBON_HOME=C:\esbs\esb-repo
In linux; export CARBON_HOME=\home\user\esb-repo

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

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

Thats all! You could follow the above steps and deploy WSO2 ESB-3.X on Tomcat successfully. If you do not like to follow each of the above steps manually, I have written a ruby script to automate the above procedure and install ESB on tomcat. You can download it from here
You just need to specify three directory paths there in esb3.X_tomcat_install_linux.rb and rest of the installation steps will be done automatically by the script.
esb_repo = Any directory in the local file system
CARBON_BIN_HOME= Home directory of ESB binary distribution
CATALINA_HOME= Home directory of the tomcat binary

Wednesday, July 28, 2010

Message format transformations with WSO2 ESB

With WSO2 ESB, you can easily convert the format of the messages which passes through. There are situations in which you get SOAP requests but the back end server accepts XML. In these situations, you should convert the SOAP request to XML (POX) before forwarding to the endpoint. This post explains how you can change the format of a SOAP request goes through WSO2 ESB.

Pre-requisites:
Download and install WSO2 ESB-3.X

Step 1
I use WSO2 WSAS as the backend, but you could use any server as you preferred. Start WSO2 WSAS and deploy Axis2Service

Step 2
Start WSO2 ESB and add the following configuration. Here, we specify the message format as POX in the endpoint configuration since we need to convert SOAP message to XML when forwarding it to the endpoint.

<sequence xmlns="http://ws.apache.org/ns/synapse" name="main">
<in>
<send>
<endpoint name="axis2service-epr">
<address uri="http://localhost:9763/services/Axis2Service" format="pox" />
</endpoint>
</send>
<</in>
<out>
<send />
</out>
</sequence>

Step 3
Send a SOAP1.1 message using a tool (SOAPUI, Jmeter, AB etc). If you look at the message transmission between ESB and the endpoint, you will notice the following messages

Request SOAP message:

POST / HTTP/1.1
SOAPAction: urn:echoString
Content-Length: 307
Content-Type: text/xml; charset=UTF-8
Host: 127.0.0.1:8281
Connection: Keep-Alive
User-Agent: Jakarta-HttpComponents-Bench/1.1

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org">
<soapenv:Body>
<ser:echoString>
<ser:s>test</ser:s>
</ser:echoString>
</soapenv:Body> </soapenv:Envelope>


Message delivered to the endpoint:

POST /services/Axis2Service HTTP/1.1
Content-Type: application/xml; charset=UTF-8
SOAPAction: urn:echoString
Transfer-Encoding: chunked
Host: 127.0.0.1:9765
Connection: Keep-Alive
User-Agent: Synapse-HttpComponents-NIO

86
<ser:echoString xmlns:ser="http://service.carbon.wso2.org">
<ser:s>test</ser:s> </ser:echoString>0

Similarly, you can convert the message to SOAP1.2 or HTTP GET just by specifying the endpoint format.

Monday, July 19, 2010

How to use POST_TO_URI property in WSO2 ESB

Until recently I had some doubts about using POST_TO_URI property within WSO2 ESB configuration. Finally, I think I understood the true purpose of it and used it correctly.

According to WSO2 ESB parameters catelog, POST_TO_URI property makes the outgoing URL of the ESB a complete URL and it is important when sending the messages through a proxy server.
Lets see how this property can be used in message mediation when a HTTP proxy server is used.

Step 1

As I explained in a previous post, you are supposed to configure WSO2 ESB to forward messages through a HTTP proxy server.

Step 2

Now, add the following sequence (or any message pass through sequence). (I used a service called "Axis2Sesrvice" which is deployed on WSO2 WSAS as the endpoint and I used Apache server as the proxy)

<sequence xmlns="http://ws.apache.org/ns/synapse" name="main">
<in>
<send>
<endpoint name="endpoint_urn_uuid_1286CEB97BC8A170468445150995919829308689">
<address uri="http://localhost:9764/services/Axis2Service/" />
</endpoint>
</send>
</in>
<out>
<send />
</out>
</sequence>

Step 3

Send a message to ESB using a client. You will notice that the message transmission is failed. If you look at the apache server log, you will notice something similar to the below.

127.0.0.1 - - [19/Jul/2010:14:19:30 +0530] "POST /services/Axis2Service/ HTTP/1.1" 404 220

Here, you can see that, POST message does not contain the full service URL hence the proxy server is unable to forward the message to the endpoint.

Step 4

Now update the above sequence with including POST_TO_URI property as follows.

<sequence xmlns="http://ws.apache.org/ns/synapse" name="main">
<in>
<property name="POST_TO_URI" value="true" scope="axis2" type="STRING" />
<send>
<endpoint name="endpoint_urn_uuid_1286CEB97BC8A170468445150995919829308689">
<address uri="http://localhost:9764/services/Axis2Service/" />
</endpoint>
</send>
</in>
<out>
<send />
</out>
</sequence>

Send a message again. This time, the message transmission will be successful. You will find the following entry in apache log. This proves that the message is correctly forwarded to the endpoint through the proxy server.

127.0.0.1 - - [19/Jul/2010:14:57:25 +0530] "POST http://localhost:9764/services/Axis2Service/ HTTP/1.1" 200 278

Sunday, July 11, 2010

How to configure WSO2 ESB to route messages through a proxy server

When using WSO2 ESB, there are situations in which you need to talk to an endpoint which sits behind a proxy. In such cases, you should configure the ESB transport sender to forward the messages to the proxy server.
In order to do so, you just need to add the following two parameters as child elements of <transportSender name="http" class="org.apache.synapse.transport.nhttp.HttpCoreNIOSender">

<parameter name="http.proxyHost" locked="false">localhost</parameter>
<parameter name="http.proxyPort" locked="false">8090</parameter>

Note:- Change the proxy port and host according to your environment

Tuesday, June 1, 2010

WSO2 Stratos - Introducing WSO2 middleware Platform as a Service (PaaS)

Yesterday we released our newest integrated cloud middleware platform, WSO2 Stratos. It is now online and ready for use!

For the past few years, WSO2 has been doing many releases based on revolutionary Carbon platform, which helped to consistently improve the platform with introducing latest state-of-art technologies. The initial releases of Carbon product platform intended to improve the features of the individual products. For example, a lot of core features were introduced to WSO2 ESB, WSAS, Governance Registry etc.. Then we focused on ease of integration and more component based model. We introduced Equinox based provisioning model to build your SOA platform by picking and choosing the components as and when you need.
Then, the core product platform has been enhanced to support multi-tenancy. With the multi-tenant supported architecture at hand, our brilliant development team was able to introduce the first ever comprehensive middleware PaaS. Why is this so important?
Now, WSO2 Carbon middleware platform is available on Cloud. Anybody can try out it online by accessing http://cloud.wso2.com
Not only that, the code is 100% opensource! As far as I know, this is the first ever opensource cloud PaaS offering.

Without digging in to more details, lets try WSO2 Stratos out.

Step 1

As most of you are familiar with Google Apps, without any guidance you will be able to start using WSO2 Stratos. However, I will start from the scratch. Access http://cloud.wso2.com. This will bring up WSO2 Stratos Manager, which is the is the point of entry for all WSO2 Cloud Services such as Application Server, Business Activity Monitor, Gadget Server, Governance, Identity and Mashup Server. Click on "Register" in order to create an account for you (your organization).



This will direct you to "Select a domain for your organization" page. Specify the domain for your organization and check its availability by clicking on "Check Availability". Select "Next" to sign up your organization.



Enter the required information in "sign up your organization" page. If your registration is successful, you will see a confirmation message. With this, you just created the administration account for your organization. You will receive an email to validate Email instructions specified by you. Click on the link given in the email to access the Stratos Manager login page.
Now, you can log in to the Stratos Manager, by giving the admin credentials you have just specified during the registration process.

Step 2

After log in to Stratos Manager, you will see the cloud services list offered by WSO2 Cloud service platform.



In addition to the cloud services, you can configure a new theme for your account or you can manage new user accounts (add new users, grant necessary permissions to them etc..) through the Stratos Manager.

Suppose, you need to use cloud application server out of the seven cloud services enabled by default. Click on "Cloud Application Server" link. This will bring up "WSO2 Stratos Application Server" login page as follows.



Log in to app server by providing the same admin credentials given above. (You may question why a separate login is required. We have not provided Single Sign On support between Stratos Manager and Cloud services in the alpha1 version. This will be available soon)
The Cloud application server Home page will be shown as follows after you log in to the application server.



If you are already familiar with WSO2 WSAS, this will not make you feel strange. You could either deploy services, secure them, monitor and do a lot of tasks. In addition to that, WSO2 Cloud Application Server, is now provides with web application deployment support. You could use this as your servlet container!

Similarly, you can try out the rest of the cloud services.

Saturday, May 8, 2010

How to specify a custom scope for WS-Discovery target service

As I explained in a previous blog post, WS-Discovery support is included in the latest WSO2 carbon release (3.0.0).
WSO2 WSAS can be considered as a target service hosting provider. A default scope is assigned to all the target services discovered by a Discovery Proxy.
If a discovery client looks for a service based on the service type, or some scopes, the client sends probe message to the DiscoveryProxy. Then the proxy responds back to the client with the appropriate service metadata.
Suppose we need to specify a scope for the services deployed on WSAS (target services). How can we do that?

You can specify the service scope(s), by adding a parameter in the services.xml of the Axis2 Service archive (*.aar) as follows.

<parameter name="wsDiscoveryParams">
<Scopes>http://wso2.org/engineering</Scopes>
</parameter>

Then, you can probe the services either through WS-Discovery Control Panel in WSO2 ESB management console as shown here or using WS-Discovery Client API as follows.

DiscoveryClient client = new DiscoveryClient(cfgCtx, discoveryProxyURL);
TargetService[] services = client.probe(types, scopes, matchingCriteria);

Hierarchical service deployment support in WSO2 WSAS-3.2.0

WSO2 WSAS-3.2.0 is the latest version of WSO2 Web Services Application Server which consists of some new features as well as a lot of bug fixes. Hierarchical service deployment is one of the new features included in the latest WSAS.
Hierarchical service deployment model allows you to deploy two (or more) different versions of the same service in a very easy manner.
Lets see how multiple versions of the same services can be deployed on WSAS-3.2.0

Pre-requisites:
Download WSO2 WSAS-3.2.0 from here

Step 1

Start WSO2 WSAS by running wso2server.sh{bat} from WSAS_HOME/bin
Access management console using https://localhost:9443/carbon and log in with the default credentials(admin/admin)

Select Axis2 Service from the left navigation menu.



You will notice there is an input text box, Service Hierarchy. Here you can specify a service path. eg:- /marketing/test
Browse a service archive (eg:- Axis2Service.aar) in your local file system and click on Upload.
The service will be deployed successfully, go to the service list page and you will the service is listed there as follows. The service name is prefixed with the hierarchy path you have given when deploying the service (marketing/test/Axis2Service)



Step 2

Now, we are going to deploy a different version of the same Axis2Service. Access the Manage --> Services --> Add --> Axis2 Service page and specify a new service hierarchy (eg:- /sales/test)
Browse the same service archive which have deployed in the previous step (Axis2Service.aar) and click on upload.

Now, you will notice a different version of the same service, sales/test/Axis2Service listed in the service management page.

Likewise, you can deploy many versions of the same service and make use them in your SOA infrastructure. Hierarchical service deployment facility can be used in Spring, Jax-WS and Jar services as well.

Wednesday, April 28, 2010

WS-Discovery with WSO2 Carbon

WS-Discovery defines a protocol to locate web services on a network, more specifically in a SOA.
The newest release of WSO2 Carbon platform (version 3.0.0) provides a complete implementation of the WS-Discovery managed mode.
This post demonstrates an end-to-end workflow of WS-Discovery support in WSO2 Carbon. With WS-Discovery components for WSO2 Carbon, any Carbon server can act as a WS-Discovery client, a WS-Discovery proxy or a WS-Discovery target service. We will use three products from WSO2 Carbon product suite, namely WSO2 Governance Registry (G-reg), WSO2 ESB and WSO2 WSAS.
WSO2 G-reg acts as the central repository in which the discovered services and the related meta data are stored. WSO2 WSAS is used to host the target services. WSO2 ESB participates in the scenario as a discovery client which looks for services and endpoints.

Lets start with setting up the environment.

Pre-requistes:

Install and run each product. In this demonstration, I will run G-reg in http port 9763 and https port 9443. WSAS on http port 9764 and https port 9444. ESB on http port 9765 and https port 9445. In this way, I can run all three products in single machine.

Step 1

As I explained initially, WSO2 Governance Registry acts as the discovery proxy. If you access the https://localhost:9443/services/DiscoveryProxy?wsdl, you will find out the wsdl of the discovery proxy service. Make a note of the DiscoveryProxy service endpoint (https://localhost:9443/services/DiscoveryProxy)

Step 2

Now, we need to configure WSAS instance, so that it takes part in service discovery scenario. WSAS is used to host target services. Therefore, it sends a unicast Hello messages to a Discovery Proxy when the services join a network. So, we must configure the Discovey Proxy service endpoint in WSAS.

Open WSAS_HOME/repository/conf/axis2.xml and add the following parameter.

<parameter name="DiscoveryProxy">https://localhost:9443/services/DiscoveryProxy</parameter>

Save the file and restart WSAS. This will enable WSAS to send unicast hello messages when the services are deployed.
Now, access the management console of WSO2 Governance Registry instance and go to Metadata-->List-->Services page. You will see that 3 discovered services are listed there.
These are the three default services included in WSAS. When starting WSAS, those three services have sent the hello messages to the discovery proxy and register them in G-reg.



Image:- Discovered services in G-reg

Now, log in to WSAS management console and deploy a new service. If you refresh the above service list page, you will see a new service is discovered by G-reg and it is assigned a unique service name.

Step 3

The third member participates in our scenario is WSO2 ESB, which acts as a discovery client. WSO2 ESB provides you with a user interface to mange the client aspects of WS-Discovery. Using that, you can connect to remote WS-Discovery proxies and probe them for any services and service endpoints which have been already discovered.

Log in to ESB management console and select Configure > WS-Discovery from the left navigation menu to access WS-Discovery Control panel.



Image:- WS-Discovery Control Panel in ESB

In order to connect to the remote DiscoveryProxy (in G-reg) and make use of the discovered services, we should configure a discovery proxy in ESB. Click on "Add Discovery Proxy" link to add a new proxy. You will be directed to discovery proxy settings screen in which you can give a name for the proxy and the remote DiscoveryProxy URL (In our case https://localhost:9443/services/DiscoveryProxy). You will be redirected to the home page of WS-Discovey Control Panel once the proxy is created. The created proxy will be listed in the control panel home page. Click on "View" to find the target services and endpoints discovered by the proxy. You will be directed to a page as shown below.



Here, you will see that 4 service are discovered and shown with a UUID and associated endpoints of each discovered service.
Click on a discovered service UUID. You will be directed to a new page with more information about the service. Using this page, either you can create an ESB endpoint or directly create an ESB proxy service referring to the discovered service.

We have seen the basic workflow of WS-Discovey implementation of WSO2 Carbon platform. If you have any issues with the above steps, drop me a mail or contact WSO2 ESB forum at www.wso2.org

Sunday, April 25, 2010

How to setup binary relay in WSO2 ESB-3.0.0

The latest version of WSO2 ESB will be out by few days and the final set of release candidate builds are currently going through the test process. WSO2 ESB-3.0.0 consists of a set of new features as well as enhancements to the existing features. Binary relay feature has been included since the previous ESB release (WSO2 ESB-2.1.3) however many bug fixes and enhancements are included in the new release.
Binary relay allow users to send messages to a different party efficiently at byte level while making decisions using transport headers. It enables ESB to pass through SOAP messages without performing heavy XML parsing. You can find more information about the architectural details of binary relay in this article written by Dr. Srinath Perera.

I'm going to demonstrate the steps to configure binary relay in WSO2 ESB-3.0

Pre-requisites:
Download WSO2 ESB-3.0.0 from here (I'm using the latest release candidate which can be downloaded from here)

Step 1

First we must enable the relay module in the ESB management console so that it unwraps the messages received by the admin services.
Log in to management console and go to Manage --> Modules --> List and click on engage icon associated with relay module to engage the module globally.

Step 2

Now, we should configure the necessary message formatters and builders in axis2.xml configuration file.
Go to ESB_HOME/repository/conf/axis2.xml and locate the messageFormatters and messageBuilders section.
Uncomment the relay message formatters and builders as follows. Also, comment out the other (default) formatters and builders.

<messageFormatters>
<!--<messageFormatter contentType="application/x-www-form-urlencoded"
class="org.apache.axis2.transport.http.XFormURLEncodedFormatter"/>
<messageFormatter contentType="multipart/form-data"
class="org.apache.axis2.transport.http.MultipartFormDataFormatter"/>
<messageFormatter contentType="application/xml"
class="org.apache.axis2.transport.http.ApplicationXMLFormatter"/>
<messageFormatter contentType="text/xml"
class="org.apache.axis2.transport.http.SOAPMessageFormatter"/>
<messageFormatter contentType="application/soap+xml"
class="org.apache.axis2.transport.http.SOAPMessageFormatter"/>-->
<messageFormatter contentType="application/x-www-form-urlencoded"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<messageFormatter contentType="multipart/form-data"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<messageFormatter contentType="application/xml"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<messageFormatter contentType="text/html"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<messageFormatter contentType="application/soap+xml"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<messageFormatter contentType="text/xml"
class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>
<!--messageFormatter contentType="x-application/hessian"
class="org.apache.synapse.format.hessian.HessianMessageFormatter"/-->
<!--messageFormatter contentType=""
class="org.apache.synapse.format.hessian.HessianMessageFormatter"/-->
<!--
class="org.apache.axis2.format.PlainTextFormatter"/>-->
</messageFormatters>


<messageBuilders>
<!-- <messageBuilder contentType="application/xml"
class="org.apache.axis2.builder.ApplicationXMLBuilder"/>
<messageBuilder contentType="application/x-www-form-urlencoded"
class="org.apache.axis2.builder.XFormURLEncodedBuilder"/>
<messageBuilder contentType="multipart/form-data"
class="org.apache.axis2.builder.MultipartFormDataBuilder"/>-->
<messageBuilder contentType="application/xml"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<messageBuilder contentType="application/x-www-form-urlencoded"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<messageBuilder contentType="multipart/form-data"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<messageBuilder contentType="application/soap+xml"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<messageBuilder contentType="text/plain"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<messageBuilder contentType="text/xml"
class="org.wso2.carbon.relay.BinaryRelayBuilder"/>
<!--messageBuilder contentType="x-application/hessian"
class="org.apache.synapse.format.hessian.HessianMessageBuilder"/-->
<!--messageBuilder contentType=""
class="org.apache.synapse.format.hessian.HessianMessageBuilder"/-->
<!-- <messageBuilder contentType="text/plain"
class="org.apache.axis2.format.PlainTextBuilder"/>-->
</messageBuilders>
Save axis2.xml file and restart the server. Now, the server will be running with binary relay enabled.

Step 3

In order to verify how message mediation happens with binary relay, create a simple pass through sequence and send few SOAP requests. If you enable DEBUG level logging for org.apache.synapse, you will notice the message with binary content as follows.
<ns:binary xmlns:ns="http://ws.apache.org/commons/ns/payload">PD94bWwgdmVyc2lvbj0nMS4wJyB
lbmNvZGluZz0nVVRGLTgnPz48c29hc</ns:binary>





Sunday, February 14, 2010

How to invoke a secured web service without maintaining a policy at the client side

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 the management console by accessing https://localhost:9443/carbon

Select the default HelloService and navigate to the service dashboard. Click on Security and configure Sign and Encrypt - X509 Authentication security scenario as shown below. Make sure to use wso2carbon.jks as trusted key store and private key store.



Thats all we have to do at the server side. Lets write a client to invoke the service.

Step 2

Here we are going to use Axis2 Dynamic Client which is an extension of the ServiceClient class.
First, instantiate a dynamicClient object using RPCServiceClient by passing ConfigurationContext, WSDL Url of the service, the QName of the service and the port name as parameters.

RPCServiceClient dynamicClient = new RPCServiceClient(null, new URL("http://localhost:9763/services/HelloService?wsdl"),
new QName("http://www.wso2.org/types", "HelloService"), "HelloServiceHttpSoap12Endpoint");

Then, we can engage rampart module as follows.
dynamicClient.engageModule("rampart");
Now we should update the client side policy with the rampart-config programatically.


RampartConfig rc = new RampartConfig();

rc.setUserCertAlias("wso2carbon");
rc.setEncryptionUser("wso2carbon");
rc.setPwCbClass(SecureClient.class.getName());

CryptoConfig sigCryptoConfig = new CryptoConfig();

sigCryptoConfig.setProvider("org.apache.ws.security.components.crypto.Merlin");

Properties prop1 = new Properties();
prop1.put("org.apache.ws.security.crypto.merlin.keystore.type", "JKS");
prop1.put("org.apache.ws.security.crypto.merlin.file", "/home/charitha/products/wsas/wso2wsas-3.1.3/resources/security/wso2carbon.jks");
prop1.put("org.apache.ws.security.crypto.merlin.keystore.password", "wso2carbon");
sigCryptoConfig.setProp(prop1);

CryptoConfig encrCryptoConfig = new CryptoConfig();
encrCryptoConfig.setProvider("org.apache.ws.security.components.crypto.Merlin");

Properties prop2 = new Properties();

prop2.put("org.apache.ws.security.crypto.merlin.keystore.type", "JKS");
prop2.put("org.apache.ws.security.crypto.merlin.file", "/home/charitha/products/wsas/wso2wsas-3.1.3/resources/security/wso2carbon.jks");
prop2.put("org.apache.ws.security.crypto.merlin.keystore.password", "wso2carbon");
encrCryptoConfig.setProp(prop2);

rc.setSigCryptoConfig(sigCryptoConfig);
rc.setEncrCryptoConfig(encrCryptoConfig);

Next, we can add the above rampartConfig to the service policy derived from the wsdl as follows.


Map endPoints = dynamicClient.getAxisService().getEndpoints();
AxisBinding axisBinding = ((AxisEndpoint) endPoints.values().iterator().next()).getBinding();
Policy policy = axisBinding.getEffectivePolicy();
policy.addAssertion(rc);
axisBinding.applyPolicy(policy);
Now, we can invoke the service using dynamicClient by passing the parameters as an object array and return types as an class array.


Object[] returnArray = dynamicClient.invokeBlocking(new QName("http://www.wso2.org/types", "greet"),
new Object[]{"hello"}, new Class[]{String.class});

System.out.println(returnArray[0]);


Thats all! To complete our scenario, make sure to have callback handler method similar to the one below.



public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {

WSPasswordCallback pwcb = (WSPasswordCallback) callbacks[0];
String id = pwcb.getIdentifer();
if ("wso2carbon".equals(id)) {
pwcb.setPassword("wso2carbon");
}

Sunday, February 7, 2010

Visits to this blog - 2009 (significant increase of visitors)

I published a stat report about this blog in February 2009, which showed 30037 unique visitors during 2008-2009. Here is the StatCounter report for 2009-2010.




There were 55,839 unique visitors, 25000 increase compared to last year. I could not write much blog posts during the last year due to frequent project releases. However which did not seem to affect my user community. This blog was started to help novice users in SOA/Web Service space and Software Quality Assurance community to share my ideas, tips and specially How-Tos. I always refrained from posting any non-technical subject matter in here. I was able to reply most of the questions raised in blog posts, however there were situations that I could not follow the comments and reply. I will try my best to continue writing much more useful blog posts and help users.