Testing Web Services

What exactly are Web Services? To put it quite simple, they are yet another distributed computing technology (like CORBA, RMI, EJB, etc.). Web services allow us to create client/server applications.

For example, let’s suppose we keep a database with up-to-date information about weather in the United States, and we want to distribute that information to anyone in the world. To do so, we could publish the weather information through a Web Service that, given a ZIP code, will provide the weather information for that ZIP code.

The clients (programs that want to access the weather information) would then contact the Web Service (in the server), and send a service request asking for the weather information.

The server would return the forecast through a service response. Of course, this is a very sketchy example of how a Web Service works.

Web Services are platform-independent and language-independent, since they use standard XML languages. This means that the client program can be programmed in C++ and running under Windows, while the Web Service is programmed in Java and running under Linux.

Most Web Services use HTTP for transmitting messages (such as the service request and response). This is a major advantage if you want to build an Internet-scale application, since most of the Internet’s proxies and firewalls won’t mess with HTTP traffic (unlike CORBA, which usually has trouble with firewalls). Even though Web Services rely heavily on existing Web technologies (such as HTTP), they have no relation to web browsers and HTML.

A Web Service is a URL-addressable software resource that performs discrete function(s). They are web based applications that use open, XML-based standards and transport protocols to exchange data with clients. Web Services communicate using a standard protocol known as SOAP and is located by its listing in a UDDI directory.

SOAP – Simple Object Access Protocol {to transfer the data}

A lightweight XML-based messaging protocol used to encode the information in Web service request and response messages before sending them over a network. SOAP messages are independent of any operating system or protocol and may be transported using a variety of Internet protocols, including SMTP, MIME, and HTTP.

WSDL - Web Services Description Language {it describes the service}

An XML-formatted language used to describe a Web service’s capabilities as collections of communication endpoints capable of exchanging messages. WSDL is an integral part of UDDI, an XML-based worldwide business registry. WSDL is the language that UDDI uses. WSDL was developed jointly by Microsoft and IBM.

UDDI – Universal Description, Discovery and Integration {Lists what services are available}

It is a Web-based distributed directory that enables businesses to list themselves on the Internet and discover each other, similar to a traditional phone book’s yellow and white pages.

Web Services designed to do……..

• To make code re-usable

• To make code/data more accessible

• Simplify multi-party applications by reducing specific point-to-point coding

• To facelift legacy systems

• To reduce development time on new apps

• To leverage the competencies/work of others
 

What is a WSDL made of?
A WSDL has two parts
Abstract (logical) part: Defines the service in implementation neutral terms.
It contains the ‘types’, the ‘message’, and the ‘portType’ elements.
Concrete part: Defines how an endpoint implementing the service is exposed on a network. It contains the ‘binding’ and the ‘service’ elements.
A WSDL document is made up of the following elements:
• definitions — the root element of a WSDL. The attributes of this element specify the name of the WSDL, its target namespace, and the shorthand definitions for the namespaces referenced by the WSDL.
• types — the XML Schema definitions for the data units that form the building blocks of the messages used by a service.
• message — the description of the messages exchanged during invocation of a service’s operations. These elements define the arguments of the operations making up the service.
• portType — a collection of operation elements describing the logical interface of a service.
• operation — the description of an action performed by a service. Operations are defined by the messages passed between two endpoints when the operation is invoked.
• binding — the concrete data format specification for an endpoint. A binding element defines how the abstract messages are mapped into the concrete data format used by an endpoint. This is where specifics such as parameter order and return values are specified.
• service — a collection of related port elements. These elements are repositories for organizing endpoint definitions.
• port — the endpoint defined by a binding and a physical address. These elements bring all of the abstract definitions together, combined with the definition of transport details, and define the physical endpoint on which a service is exposed

I tried lot of free Webservice Tetsing Tools..

I found SOAPUI as an interesting tool ..

I was able to integrate SOAP UI scripts which are checked into VSS to a build management tool LuntBuild to run nightly builds which sends an email with the complete status of the latest code that was checked into VSS..

# Functional Testing

# Load and Stress Testing

# Inspect and Invoke of elements