How to choose between SOAP Web Services and RESTful services?

Posted by Mohaideen Jamil in RESTful Services, Soap Web Service, Soap-UI, Web Service | 2 comments

Choose SOAP:

• If you require asynchronous processing
• In your service operations are statefull
• If you need formal contract/Interfaces

Choose RESTful Services:

• If you have limited bandwidth
• If your clients require caching.
• If your operations are stateless

Web Services

Posted by Gokul in Soap-UI, Web technology | 1 comment

‘Web services’ is the name given to a technology for providing loosely coupled and interoperable communications between computer systems over a network. Applications of this technology include enterprise application integration, enabling communications between distributed systems and interoperability with partners or other businesses. The major benefits of using web services are platform independence, flexibility and ease of maintenance, which are the result of the open standards employed and the simplified underlying request-response concept that avoids the complexity of other distributed technologies such as CORBA.

Web services communications are primarily XML-based and essentially provide the ability to make RPC-like function calls between remote systems, regardless of their underlying platform. Specifically, SOAP over HTTP is the most common implementation of a web service. Supporting protocols such as UDDI [OASIS 1] and WSDL [W3C 1] provide discovery and description services that contain enough information for client applications to be built to utilise the service.

The ability to expose functionality through HTTP provides the benefit of minimal firewall configuration but also has the effect of circumventing firewall rules that may restrict unauthorised access to these functions. The addition of UDDI and WSDL allow remote users to easily locate and use the functionality provided. This exposure poses a far greater threat than was present in the previous generation of distributed technologies that typically used proprietary binary encoding schemes and restrictive firewall rule sets to limit access.

Web services communication is based upon the Simple Object Access Protocol (SOAP). SOAP is an XML-based information packaging definition which can be used for exchanging structured and typed information between peers in a distributed environment, relying on Internet transport protocols such as HTTP. Because SOAP is standards based, it also provides interoperability in heterogeneous environments.

The most relevant documents are

“SOAP Version 1.2 Part 0: Primer” [W3C 2]

“SOAP Version 1.2 Part 1: Messaging Framework” [W3C 3]

“SOAP Version 1.2 Part 2: Adjuncts” [W3C 4].

Running functional tests from the command-line

Posted by Gokul in Soap-UI

Running functional tests from the command-line is straightforward and simple using the included testrunner.bat/.sh script, which takes a number of arguments to control which tests to run, output, etc:

 
Launching the TestRunner from within SoapUI
 
Before getting started, with the command line testrunner, SoapUI includes a “Launch TestRunner” action available from Project, TestSuite or TestCase popup menus, which launches the bundled command-line tools from inside SoapUI.

The dialog looks as follows:

 
Here we’ve specified some initial settings to run the current TestCase, in the Report tab we can specify which reports to generate:

 
Now if we run the testrunner we get:

x

Scrolling back up in the opened window we can see the actual command issued at the command-line:

Copy and paste the below highlighted into your favorite automation tool for rerun these tests as configured.

That is all!!! ;)

What is the difference between HTTP and REST and SOAP in web services?

Posted by Gokul in Soap-UI, Web technology

SOAP uses WSDL for communication between consumer and provider, whereas REST just uses XML or JSON to send and receive data
 
WSDL Defines contract between client and service and is static by its nature. In case of REST contract is somewhat complicated and is defined by HTTP, URI, Media Formats and Application Specific Coordination Protocol. It’s highly dynamic unlike WSDL.
 

With links + semantic link relations clients should be able to determine what is next interaction step and follow these links and continue communication with service.

It is not necessary that messages be human readable, it’s possible to use cryptic format and build perfectly valid REST applications. It doesn’t matter whether message is human readable or not.

Thus, plain XML(application/xml) or JSON(application/json) are not sufficient formats for building REST applications. It’s always reasonable to use subset of these generic media types which have strong semantic meaning and offer enough control information(links etc…) to coordinate interactions between client and server.

REST is over only HTTP. HTTP is most widely used and when we talk about REST web services we just assume HTTP. HTTP defines interface with it’s methods(GET, POST, PUT, DELETE, PATCH etc) and various headers which can be used uniformly for interacting with resources. This uniformity can be achieved with other protocols as well.

REST permits many different data formats where as SOAP only permits XML.
While this may seem like it adds complexity to REST because you need to handle multiple formats, in my experience it has actually been quite beneficial. JSON usually is a better fit for data and parses much faster. REST allows better support for browser clients due to it’€™s support for JSON.
 

 
If you are looking for the most significant constraints of REST that distinguish a RESTful application from just any HTTP application, I would say the “self-description” constraint and the hypermedia constraint (aka Hypermedia as the Engine of Application State (HATEOAS)) are the most important.

The self-description constraint requires a RESTful request to be completely self descriptive in the users intent. This allows intermediaries (proxies and caches) to act on the message safely.

The HATEOAS constraint is about turning your application into a web of links where the client’s current state is based on its place in that web. It is a tricky concept and requires more time to explain than I have right now.
 

Establish JDBC connection in SOAPUI PRO

Posted by Gokul in Soap-UI

To establish JDBC connection all you need is 3 simple things,

• OJDBC 14 Jar File
• Database Connection String
• Database details

Now I am gonna tell you how to establish JDBC connection in PRO using Oracle XE (eXpress Edition). Before you start this, you have to download OJDBC 14 Jar file from oracle site and place it in the path specified.
 
** Update – Complete SoapUi Tutorials now available here
 

Now you can proceed with the below steps to work with the connection.

Step 1: Open ur SOAPUI Pro by clicking on SOAPUIPro.exe

Step 2: Now choose a project and double click on it.

Step 3: In the Project editor window we have many tabs. Choose JDBC connections tab.

Step 4: Click on Add a New Data Connection icon.

Step 5: Specify a name for your connection.

Step 6: Now configure your database connection by providing the following details.

The query to find the above details is as follows:

Step 7: Now test your connection by clicking on the run button.

The connection will be established successfully.