Charitha's Web Log

I have discussed about the mock services which simulate SOAP back-ends in chapter 6 of Web Services Testing with soapUI book . For the past few years, service orientation has been shifting towards RESTful web services from SOAP which demands the necessity of mocking various types of RESTful services. Being the one-stop tool kit of SOA developers/testers, soapUI provides users with different options to simulate RESTful services. In this post, I will discuss one of such a simple mechanisms to create RESTful mock services in soapUI. Pre-requisites: soapUI-4.5.2 or later Simulating POX (Plain-Old-XML) with soapUI Suppose you have a web service which returns XML response. Usually, the HTTP Content-Type of such a message is application/xml or text/xml. Create a new MOCK Service in soapUI. You can either create a Mock service from a new WSDL (ouch! we are dealing with RESTful services. Why do we need WSDL?? Does not matter. We just want to have a mock service regardless of where i...

When a request/response is received by ESB, the message will initially be converted into XML infoset. This process is known as message building and the builders are responsible to do this transformation based on the HTTP Content-Type of the incoming message. The default JSONBuilder (org.apache.axis2.json.JSONBuilder) converts the JSON into corresponding XML representation. If I explain this through an example, suppose your incoming JSON response/request is similar to the following. {   "getQuote": {     "request": { "symbol": "charitha" }   } } If you log this message inside inSequence of your message flow (using log mediator), you will observe an output similar to the following. LogMediator To: http://www.w3.org/2005/08/addressing/anonymous,  WSAction: , SOAPAction: , MessageID: urn:uuid:f37b8466-7cb3-41d6-9187-b5a0a7648f16,  Direction: response, Envelope: <?xml version='1.0' encoding='utf-8'?><soapenv:Enve...

In the agile world of software development, quality assurance function is embedded into the main stream development process and it is not considered as an activity managed by a separate QA team. Even with following many agile testing principles, why do some teams still fail to deliver products/projects with acceptable quality? According to my experience, I believe the issues with adopting the QA mindset  can be considered as the primary reason for many software quality concerns. So, what is QA mindset and why is it a critical factor in software testing? If you are a software developer, your primary objective is to complete the implementation of the feature/module which you have been assigned to do without schedule slippages. But, you are obliged to deliver it with best quality. So, you follow good agile testing principles, may be follow TDD (Test driven development),  code reviews, write automation tests, do manual tests ...

You can use HTTP request test step in soapUI to submit messages with various Content-Types.  In this post, we will have a quick look into the multipart/form-data requests in soapUI. multipart/form-data requests usually come into action when you do HTML form submissions with file attachments. For example, have a look at the following HTML form post. <form action="http://localhost:8090/CKFileUploadApp/UploadServlet" method="post" enctype="multipart/form-data"> <input type="file" name="file"> <input type="text" name="paramName"> <input type="submit" name="Submit" value="Upload File"> </form> In the forms like above, we have file upload option as a form input where we can upload a file along with the form submission. In that case, the request's HTTP content type will be multipart/form-data. How can we simulate such a request using soapUI...

This is the second of a series of posts related to OAuth-2.0 grant types in WSO2 API Manager (WSO2 Carbon platform). Therfore, I strongly suggest you to read and work on the examples described in the first post before proceeding with this. In this post, we will go through Implicit grant type which is the recommended practice if your application (client) is a mobile application or a browser based app such as a JavaScript client.  The key difference of implicit grant when comparing to the Authorization Code is, the client receives access token as the result of the authorization request. In our previous post, which was about Authorization Code grant, client had to make separate requests for authorization and access token. Also note that, the implicit grant does not include client authentication because it does not make use of client secret. Before attempting to work on the sample, let's have a look at the steps involved in implicit grant type. 1.   Application (cli...

WSO2 API Manager is a complete open source solution to manage APIs. It provides authorization and authentication for APIs using OAuth 2.0 standard. According to the OAuth specification, the client needs to get authorization from the resource owner when requesting an access token . The authorization is expressed in the form of an authorization grant , which the client uses to request the access token. There are 4 grant types defined in the OAuth spec. Authorization code Implicit Resource owner password credentials Client credentials Almost all scenarios explained in the online documentations written on WSO2 API Manager, make use of the Resource owner password credentials grant type. In there, we exchanges access token for user credentials and client_id and client_secret. I'm going to explain the use of all 4 OAuth grant types using WSO2 API Manager through a serious of blog posts. In this post, I will explain how we can use Authorization Code grant type with WSO2 API...

WS-Trust can be considered as an extension to WS-Security specification which primarily provides methods for managing security tokens and ways to broker the trust relationships. The web services trust model explained under the WS-trust specification defines three key participants. Security token service Service Consumer Service provider (Relying party) Security token service (STS) is a web service that issues security tokens based on requesters needs. The consumer sends token requests to the STS as well as append tokens into the actual service request and submits them to the provider. The service provider makes the authentication decison on the service based on the token provided by STS. The service provider may also request token validations from the STS. This post is not yet another detailed explanation about WS-trust and the associated frameworks. You can find many references just by googling the term, ws-trust . Instead, I'm going to take you through a set ...

Recently, I got an opportunity to work on a domain which is bit different from my subject matter specialization, software testing and quality assurance. I started to work as a lead of technical support team at WSO2 since November 2012. I thought to put together some key observations I made in technical support career in general and how I position it in terms of my beliefs. Willingness to help - the most important characteristic of a support engineer Are you really a helping hand regardless of your profession? How can I understand my willingness in helping others. I would simply list down some questions to evaluate your likelihood to help others. Do you get frustrated when someone requests your help? If someone asks a question, what is your initial reaction? In our life, we have seen people who do not even look at the person who requested help. Some people just route the request to some other party without even understanding what kind of help is required. If you are really a ...

The management aspects of WSO2 Carbon platform are primarily achieved through SOAP web services interface known as admin services. All Carbon products ship with a management console (front-end user interface) which communicates with these web services and provides users with various administration capabilities. In some situations, we need to by-pass the management UI and call the backend web services directly. Specially, in test automation, it is important to minimize the risk of frequent UI changes hence focusing on admin service interactions can be considered as a viable solution. WSO2 test automation framework is built upon this approach which programatically calls the backend web services to manage deployment, configuration and various other tasks. These backend web services are secured to prevent anonymous invocations. WSO2 Carbon server secures these services through multiple methodologies. For example; HTTP Basic Authentication over SSL WS-Security user...