Web services and SOAP
Applications that are accessed through browsers are web applications and it is the collection of multiple web pages. These are basically dependent on client server architecture where browser acts as a client which sends the request to server. Afterwards, web pages are rendered as per responses from the server. Purpose of web services is communications between various programs and applications.
During building any web application, order of focus is on:
- UI portion[Front end implementation]
- Functional portion[Back end implementation]
Web services
Web services are mainly used to communicate the information between two systems ignoring UI interaction. Messages are transferred from one application to another application via JSONS and XMLs etc.
Web services are mainly dependent on back end implementation, UI doesn't have any space. Clients can access only exposed methods of any functionality. Majority of the qa testing services are focusing on automating the web services to speed up the testing for integrated applications.
Web services are constructed basically to hide the implementation of any product and APIs are exposed to perform specific functions. Web services leads to many advantages for various software testing companies mentioned below:
- Re-usability of any code
- Reduced the Complexity
- Enhanced the features of any product
- Impact on cost
- Speed
As communications protocols and message formats are standardized in the web community, it becomes increasingly possible and important to be able to describe the communications in some structured way. WSDL addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication.
A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:
- Types– a container for data type definitions using some type system (such as XSD).
- Message– an abstract, typed definition of the data being communicated.
- Operation– an abstract description of an action supported by the service.
- Port Type–an abstract set of operations supported by one or more endpoints.
- Binding– a concrete protocol and data format specification for a particular port type.
- Port– a single endpoint defined as a combination of a binding and a network address.
- Service– a collection of related endpoints.
It is important to observe that WSDL does not introduce a new type definition language. WSDL recognizes the need for rich type systems for describing message formats, and supports the XML Schemas specification (XSD) as its canonical type system. However, since it is unreasonable to expect a single type system grammar to be used to describe all message formats present and future, WSDL allows using other type definition languages via extensibility.
In addition, WSDL defines a common binding mechanism. This is used to attach a specific protocol or data format or structure to an abstract message, operation, or endpoint. It allows the reuse of abstract definitions.
In addition to the core service definition framework, this specification introduces specific binding extensions for the following protocols and message formats:
- SOAP
- HTTP GET / POST
- MIME
Although defined within this document, the above language extensions are layered on top of the core service definition framework. Nothing precludes the use of other binding extensions with WSDL.
WSDL Documents
An WSDL document describes a web service. It specifies the location of the service, and the methods of the service, using these major elements:
| Element | Description |
|---|---|
| <types> | Defines the (XML Schema) data types used by the web service |
| <message> | Defines the data elements for each operation |
| <portType> | Describes the operations that can be performed and the messages involved. |
| <binding> | Defines the protocol and data format for each port type |
The main structure of a WSDL document looks like this:
<definitions>
<types>
data type definitions........
</types>
<message>
definition of the data being communicated....
</message>
<portType>
set of operations......
</portType>
<binding>
protocol and data format specification....
</binding>
</definitions>
WSDL Example
This is a simplified fraction of a WSDL document:
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
In this example the <portType> element defines "glossaryTerms" as the name of a port, and "getTerm" as the name of an operation.
The "getTerm" operation has an input message called "getTermRequest" and an output message called "getTermResponse".
The <message> elements define the parts of each message and the associated data types.
The <portType> Element
The <portType> element defines a web service, the operations that can be performed, and the messages that are involved.
The request-response type is the most common operation type, but WSDL defines four types:
| Type | Definition |
|---|---|
| One-way | The operation can receive a message but will not return a response |
| Request-response | The operation can receive a request and will return a response |
| Solicit-response | The operation can send a request and will wait for a response |
| Notification | The operation can send a message but will not wait for a response |
WSDL One-Way Operation
A one-way operation example:
<message name="newTermValues">
<part name="term" type="xs:string"/>
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="setTerm">
<input name="newTerm" message="newTermValues"/>
</operation>
</portType >
In the example above, the portType "glossaryTerms" defines a one-way operation called "setTerm".
The "setTerm" operation allows input of new glossary terms messages using a "newTermValues" message with the input parameters "term" and "value". However, no output is defined for the operation.
WSDL Request-Response Operation
A request-response operation example:
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
In the example above, the portType "glossaryTerms" defines a request-response operation called "getTerm".
The "getTerm" operation requires an input message called "getTermRequest" with a parameter called "term", and will return an output message called "getTermResponse" with a parameter called "value".
WSDL Binding to SOAP
WSDL bindings defines the message format and protocol details for a web service.
A request-response operation example:
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
<binding type="glossaryTerms" name="b1">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<operation>
<soap:operation soapAction="http://example.com/getTerm"/>
<input><soap:body use="literal"/></input>
<output><soap:body use="literal"/></output>
</operation>
</binding>
The binding element has two attributes - name and type.
The name attribute (you can use any name you want) defines the name of the binding, and the type attribute points to the port for the binding, in this case the "glossaryTerms" port.
The soap:binding element has two attributes - style and transport.
The style attribute can be "rpc" or "document". In this case we use document. The transport attribute defines the SOAP protocol to use. In this case we use HTTP.
The operation element defines each operation that the portType exposes.
For each operation the corresponding SOAP action has to be defined. You must also specify how the input and output are encoded. In this case we use "literal".
SOAP ( Simple Object Access Protocol) is a message protocol that allows distributed elements of an application to communicate. SOAP can be carried over a variety of lower-level protocols, including the web-related Hypertext Transfer Protocol (HTTP). SOAP defines a header structure that identifies the actions that various SOAP nodes are expected to take on the message, in addition to a payload structure for carrying information. The concept of routing a message through a string of nodes that perform different functions is how SOAP supports things like addressing, security and format-independence. Essentially, the headers identify roles, which in turn provide the SOA features which SOAP then routes to. Stringing messages through a sequence of steps is uncommon in today’s microservice-centric development environments.
Advantages of SOAP
SOAP is the protocol used for data interchange between applications. Below are some of the reasons as to why SOAP is used.
- When developing Web services, you need to have some of language which can be used for web services to talk with client applications. SOAP is the perfect medium which was developed in order to achieve this purpose. This protocol is also recommended by the W3C consortium which is the governing body for all web standards.
- SOAP is a light-weight protocol that is used for data interchange between applications. Note the keyword 'light.' Since SOAP is based on the XML language, which itself is a light weight data interchange language, hence SOAP as a protocol that also falls in the same category.
- SOAP is designed to be platform independent and is also designed to be operating system independent. So the SOAP protocol can work any programming language based applications on both Windows and Linux platform.
- It works on the HTTP protocol –SOAP works on the HTTP protocol, which is the default protocol used by all web applications. Hence, there is no sort of customization which is required to run the web services built on the SOAP protocol to work on the World Wide Web.
SOAP Building blocks
The SOAP specification defines something known as a "SOAP message" which is what is sent to the web service and the client application.
The diagram below shows the various building blocks of a SOAP Message.
The SOAP message is nothing but a mere XML document which has the below components.
- An Envelope element that identifies the XML document as a SOAP message – This is the containing part of the SOAP message and is used to encapsulate all the details in the SOAP message. This is the root element in the SOAP message.
- A Header element that contains header information – The header element can contain information such as authentication credentials which can be used by the calling application. It can also contain the definition of complex types which could be used in the SOAP message. By default, the SOAP message can contain parameters which could be of simple types such as strings and numbers, but can also be a complex object type.
A simple example of a complex type is shown below.
Suppose we wanted to send a structured data type which had a combination of a "Tutorial Name" and a "Tutorial Description," then we would define the complex type as shown below.
The complex type is defined by the element tag <xsd:complexType>. All of the required elements of the structure along with their respective data types are then defined in the complex type collection.
<xsd:complexType><xsd:sequence><xsd:element name="Tutorial Name" type="string"/><xsd:element name="Tutorial Description" type="string"/> </xsd:sequence></xsd:complexType>
- A Body element that contains call and response information – This element is what contains the actual data which needs to be sent between the web service and the calling application. Below is an example of the SOAP body which actually works on the complex type defined in the header section. Here is the response of the Tutorial Name and Tutorial Description that is sent to the calling application which calls this web service.
<soap:Body><GetTutorialInfo><TutorialName>Web Services</TutorialName><TutorialDescription>All about web services</TutorialDescription></GetTutorialInfo></soap:Body>
SOAP Message Structure
One thing to note is that SOAP messages are normally auto-generated by the web service when it is called.
Whenever a client application calls a method in the web service, the web service will automatically generate a SOAP message which will have the necessary details of the data which will be sent from the web service to the client application.
As discussed in the previous topic, a simple SOAP Message has the following elements –
- The Envelope element
- The header element and
- The body element
- The Fault element (Optional)
Let's look at an example below of a simple SOAP message and see what element actually does.
- As seen from the above SOAP message, the first part of the SOAP message is the envelope element which is used to encapsulate the entire SOAP message.
- The next element is the SOAP body which contains the details of the actual message.
- Our message contains a web service which has the name of "Guru99WebService".
- The "Guru99Webservice" accepts a parameter of the type 'int' and has the name of TutorialID.
Now, the above SOAP message will be passed between the web service and the client application.
You can see how useful the above information is to the client application. The SOAP message tells the client application what is the name of the Web service, and also what parameters it expects and also what is the type of each parameter which is taken by the web service.
SOAP Envelope Element
The first bit of the building block is the SOAP Envelope.
The SOAP Envelope is used to encapsulate all of the necessary details of the SOAP messages, which are exchanged between the web service and the client application.
The SOAP envelope element is used to indicate the beginning and end of a SOAP message. This enables the client application which calls the web service to know when the SOAP message ends.
The following points can be noted on the SOAP envelope element.
- Every SOAP message needs to have a root Envelope element. It is absolutely mandatory for SOAP message to have an envelope element.
- Every Envelope element needs to have at least one soap body element.
- If an Envelope element contains a header element, it must contain no more than one, and it must appear as the first child of the Envelope, before the body element.
- The envelope changes when SOAP versions change.
- A v1.1-compliant SOAP processor generates a fault upon receiving a message containing the v1.2 envelope namespace.
- A v1.2-compliant SOAP processor generates a Version Mismatch fault if it receives a message that does not include the v1.2 envelope namespace.
Below is an example of version 1.2 of the SOAP envelope element.
<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle=" http://www.w3.org/2001/12/soap-encoding"><soap:Body> <Guru99WebService xmlns="http://tempuri.org/"> <TutorialID>int</TutorialID></SOAP-ENV:Envelope></Guru99WebService></soap:Body>
The Fault message
When a request is made to a SOAP web service, the response returned can be of either 2 forms which are a successful response or an error response. When a success is generated, the response from the server will always be a SOAP message. But if SOAP faults are generated, they are returned as "HTTP 500" errors.
The SOAP Fault message consists of the following elements.
- <faultCode>- This is the code that designates the code of the error. The fault code can be either of any below values
- SOAP-ENV:VersionMismatch – This is when an invalid namespace for the SOAP Envelope element is encountered.
- SOAP-ENV:MustUnderstand - An immediate child element of the Header element, with the mustUnderstand attribute set to "1", was not understood.
- SOAP-ENV:Client - The message was incorrectly formed or contained incorrect information.
- SOAP-ENV:Server - There was a problem with the server, so the message could not proceed.
- <faultString> - This is the text message which gives a detailed description of the error.
- <faultActor> (Optional)- This is a text string which indicates who caused the fault.
- <detail>(Optional) - This is the element for application-specific error messages. So the application could have a specific error message for different business logic scenarios.
Example for Fault Message
An example of a fault message is given below. The error is generated if the scenario wherein the client tries to use a method called TutorialID in the class GetTutorial.
The below fault message gets generated in the event that the method does not exist in the defined class.
<?xml version='1.0' encoding='UTF-8'?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"><SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode> <faultstring xsi:type="xsd:string"></SOAP-ENV:Envelope>Failed to locate method (GetTutorialID) in class (GetTutorial) </faultstring> </SOAP-ENV:Fault></SOAP-ENV:Body>
Output:
When you execute the above code, it will show the error like "Failed to locate method (GetTutorialID) in class (GetTutorial)"
SOAP Communication Model.
All communication by SOAP is done via the HTTP protocol. Prior to SOAP, a lot of web services used the standard RPC (Remote Procedure Call) style for communication. This was the simplest type of communication, but it had a lot of limitations.
Let's consider the below diagram to see how this communication works. In this example, let's assume the server hosts a web service which provided 2 methods as
- GetEmployee - This would get all Employee details
- SetEmployee – This would set the value of the details like employees dept, salary, etc. accordingly.
In the normal RPC style communication, the client would just call the methods in its request and send the required parameters to the server, and the server would then send the desired response.
The above communication model has the below serious limitations
- Not Language Independent – The server hosting the methods would be in a particular programming language and normally the calls to the server would be in that programming language only.
- Not the standard protocol – When a call is made to the remote procedure, the call is not carried out via the standard protocol. This was an issue since mostly all communication over the web had to be done via the HTTP protocol.
- Firewalls – Since RPC calls do not go via the normal protocol, separate ports need to be open on the server to allow the client to communicate with the server. Normally all firewalls would block this sort of traffic, and a lot of configuration was generally required to ensure that this sort of communication between the client and the server would work.
To overcome all of the limitations cited above, SOAP would then use the below communication model
- The client would format the information regarding the procedure call and any arguments into a SOAP message and sends it to the server as part of an HTTP request. This process of encapsulating the data into a SOAP message was known as Marshalling.
- The server would then unwrap the message sent by the client, see what the client requested for and then send the appropriate response back to the client as a SOAP message. The practice of unwrapping a request sent by the client is known as Demarshalling.
Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of email to support:
- Text in character sets other than ASCII
- Non-text attachments: audio, video, images, application programs etc.
- Message bodies with multiple parts
- Header information in non-ASCII character sets
Virtually all human-written Internet email and a fairly large proportion of automated email is transmitted via SMTP in MIME format.[citation needed]
MIME is specified in six linked RFC memoranda: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 and RFC 2049; with the integration with SMTP email specified in detail in RFC 1521 and RFC 1522.
Although MIME was designed mainly for SMTP, the content types defined by MIME standards are also of importance in communication protocols outside of email, such as HTTP for the World Wide Web. Servers insert the MIME header at the beginning of any Web transmission. Clients use this content type or media typeheader to select an appropriate viewer application for the type of data the header indicates. Some of these viewers are built into the Web client or browser (for example, almost all browsers come with GIF and JPEG image viewers as well as the ability to handle HTML files).
| Property Name | Property Description |
|---|---|
SOAPMessage | An abstract structure that represents the primary SOAP message part of the compound SOAP structure. |
SecondaryPartBag | An abstract structure that represents the compound SOAP structure's secondary part(s). This structure is a bag that contains representations of each of the compound SOAP structure's secondary part(s). A secondary part representation can be a URI referencing this secondary part, an abstract structure representing the secondary part itself, or both. |
For example, the Request-Response Message Exchange Pattern in the specification defines a reqres:OutboundMessage property that represents the current outbound message in the message exchange. If the Request-Response Message Exchange Pattern is used in conjunction with this feature, then the reqres:OutboundMessage property is initialized to represent the compound SOAP Structure (see diagram below).
JAX-WS
JAX-WS is an abbreviation of “Java API for XML-Based Web Services” and is a Java standard API for handling Web service using SOAP etc.
Using JAX-WS, Java object can be sent by converting the same to XML in conformance with SOAP specifications.
Therefore, although information is exchanged in SOAP Web Service using XML, the user can handle the data without being aware of XML structure.
Main Java EE servers like Oracle WebLogic Server or JBoss Enterprise Application Platform use JAX-WS implementation on server side and can easily publish Web service by using the function without adding a specific library.
However, since Tomcat does not implement JAX-WS, a separate JAX-WS implementation library must be added while using Tomcat.
For details, refer “Web service development on Tomcat”.
JAX-WS linkage function of Spring Framework
Spring Framework supports JAX-WS linkage function and implementation can be easily done for both SOAP server and client using this function.
Overview of the recommended access flow using this function is given below. Here, it is assumed that the Web application acting as a SOAP client (Fig. on the left) access SOAP server (fig. on the right).
Testing of web services is one of the important type of software testing approach, which is mainly used to determine the expectations for reliability, functionality, performance, etc.
As these days Automated testing is considered as one of the most trending methodology in the field of software testing, hence testing web apps based on RESTful APIs through automation will provide effective test results. Some of the best & popular tools for web services testing are:
- SoapUI,
- TestingWhiz,
- SOATest
- TestMaker,
- Postman, etc.
Below three frameworks are widely used in the Web Service testing.
i) SoapUI tool/framework is a popular open source Web Services Testing tool in use since 2005. SoapUI is one of the initial testing tools for WS and has an active and vibrant community. This framework supports cross platform as it is written in Java. SoapUI is a simple and easy to use GUI based tool to develop test suites across the SOAP and RESTful Web Services. It also supports command line (CLI) to execute the tests. SoapUI does support other languages such as Groovy and Javascript.
ii) Jersey client API is an open source implementation of JAX-RS (Java API for XML REST Services) that is used for developing RESTful Web Services. It is created by Oracle (earlier Sun Microsystems). This framework is not a test framework but instead a simple WS client Java APIs to consume in TestNG/JUnit frameworks while developing the tests. A wrapper test framework with common functionality can be created on top of Jersey.
iii) REST Assured framework is a free and open source Java library to work with REST APIs. This framework specialty is that it is very easy to send requests and parse the JSON responses.
Comments
Post a Comment