Showing posts from 2012

TIP: Error handling in WSO2 ESB APIs when the requested API resource does not match with the given URL template or pattern

When you send a HTTP request to an API in WSO2 ESB , if the requested API resource URL does not comply with the API resource definition, ESB returns HTTP 202 accepted response to the user. Due to  this behavior, the client is unable to distinguish if they have made an error. We can use the following procedure to return a fault to the client in case of non-matching API resource is requested by client. Step 1: Suppose, we have an API similar to the following. Note that, the target web service is a JAXRS web application (jaxrs_basic) which is included in WSO2 Application Server by default. <api xmlns="" name="jaxrs" context="/jaxrs"> <resource methods="GET" uri-template="/customers/{id}"> <inSequence> <send> <endpoint> <address uri="http://localhost:9764/jaxrs_basic/services/customers/customerservice"/>

How to enable mail transport for WSO2 data services

We can use mail transport to send and receive messages to and from web services using MIME complaint mail messages. We can configure mail transport for Axis2 services which are deployed in WSO2 Application Server by following the instructions given in the official documentation . In there, you will notice that, a set of mail transport specific parameters need to be configured in the services.xml of Axis2 service in order to enable mail transport in Axis2 services. How can we do the same for data services which are deployed in WSO2 Application Server? This post summarizes the procedure of configuring mail transport for a data service. Step 1: Download and install WSO2 Application Server-5.0.0 or a later version. Configure mail transport sender and receiver in axis2.xml configuration file which can be found at CARBON_HOME/repositiry/conf/axis2/axis2.xml (see WSO2 Application Server official documentation on how to configure mail transport sender and receiver in axis2.xml) Aft

"Web Services Testing with soapUI" book is published!

It is with extreme pleasure that I announce, Web Services Testing with soapUI , the first book authored by me, is now published! This is a remarkable achievement of my life and I'm really happy to make the first announcement about the new book through my blog. On 9th of September 2011, Packt publishers suggested me to write a book on soapUI. By that time, I had published many blog posts about soapUI and SOA/Web services testing. I hesitated to take the challenge at first, because I had been extremely busy with my work at WSO2 and I doubted whether I would find any spare time to work on authoring a book. After taking various facts into consideration, I agreed to start the authoring process in November 2011. Writing a book has been a great experience. I read a lot and gathered a great deal of information. Finally, I was able to complete the book with 332 pages, covering almost all important features of the free version of soapUI. I always loved to read and write since my s

How to secure a SOAP web service in WSO2 Application Server and invoke it using HTTP basic authentication with soapUI

In a previous blog post , I explained the steps to deploy a web service in Apache Axis2 , secure it with HTTP basic authentication and invoke it using Apache Jmeter .  In this post, we will repeat the same using different set of tools and frameworks which are comparatively easy-to-use and user-friendly. We will secure a simple SOAP based web service which is hosted in WSO2 Application Server , configure an authentication security policy and invoke the service using HTTP basic auth through soapUI . Pre-Requisites:  Download and install WSO2 Application Server-5.0.0   Download and install soapUI 4.0.1 or later version Step 1: Start WSO2 Application Server by running startup script. Access the management console url (https://localhost:9443/carbon) and log in with the default administrator credentials (username=admin, password=admin) Step 2: Go to the Deployed Services page and you will find "HelloService" is deployed by default. Click on the servi

Setting up minimum deployment of WSO2 product cluster with management/worker separation

The latest version of WSO2 Carbon (Carbon-4.0.0) platform ( WSO2 ESB-4.5.0 , WSO2 Application Server-5.0.0 , WSO2 Governance Registry - 4.5.0 etc) supports a new deployment model which allows you to setup product clusters with separated worker and management nodes. In a worker/manager separated cluster setup, the management node(s) is used to deploy and configure the deployment artifacts where as the worker nodes are used to serve the requests received by clients. I'm not going to spend much time on a detailed explanation about this new deployment approach since my objective is to take you through the minimum worker/manager deployment setup of WSO2 Application Server cluster as quickly as possible. You can find more about the theoretical aspects of this new deployment model in Afkham Azeez's blog . Deployment diagram We are going to setup the minimum cluster setup in our local machines. Thus, we will use 3 product instances as follows. Load Balan

Consuming a SOAP service using WSO2 API Manager

SO2 API Manager is the new kid in the block, the first fully open source API management platform which can be used to create, manage, consume and monitor APIs. WSO2 API manager is based on the award winning SOA middleware platform, WSO2 Carbon thus it inherits the features provided by the modular Carbon platform. API authors and publishers can publish both REST and SOAP services to external consumers or partners through WSO2 API manager. In this post, we will look in to the steps of publishing and consuming a SOAP based web service using WSO2 API Manager. pre-requisites: Download and install alpha version of WSO2 API Manager from . Similar to the other WSO2 Carbon products, you just need to have JDK-1.6.0 or later to run WSO2 API Manager. Then you can just extract the binary and start the server. Step 1: We will use a simple SOAP based web service hosted in WSO2 StratosLive Application Serve

Managing SOA artifacts in different environments using WSO2 Governance Registry

NOTE: Please note that the instructions given in this blog post are applicable ONLY for ESB-4.0.X and G-reg-4.1.X, G-reg-4.5.0 versions. The deployment approach of the latest ESB versions has been changed and the recommended deployment synchronization approach has been switched to SVN based synchronizer. Because of that the following set of instructions cannot be applied to the latest WSO2 ESB and G-reg product versions. Managing artifacts of a service oriented solution is one of the most important features expected from any SOA middleware platform. In a typical service oriented project, SOA artifacts are subjected to move through multiple phases. Usually, separate environments are maintained for the activities associated with those phases. e.g:- Development environment Service development and system integration tasks are carried out in a separate physical environment. Depending on the requirements, there can be multiple SOA middleware solutions used in development environm