SERVER-SIDE DEVELOPMENT— SOAP
Web Application,Web Services and the needs of them.
Web applications are defined by being interactive. Most of the people supposed to use a web application in order to perform a function and use some of the web applications features. Lots of web applications don’t even have real informative content or data exactly. People are just supposed to use them in order to perform additional tasks, using their features to accomplish something. You use a web application to check your incoming messages, for instance, or play a game.
The browser capabilities involved with web applications are significantly more high-tech, which is one reason why it’s usually harder for people to design a web application than a website. Websites are all about getting more data, and web applications are all about doing things. One of our actions is probably going to be getting more information or learning more information, but the web application helped you perform that action. We got the information from a website.
The user interface of a web application is also usually much more complicated than the user interface of a website. Websites might have tags and categories that you need to understand, but we don’t have to go through and learn any potentially complicated tasks in order to use websites. Web applications often require step-by-step guides, or you’re not going to be able to complete them.
The setup of websites are completely different from web applications in most cases. The rhythm of typing in the address, loading websites, and going back and forth between websites is often absent with web applications.
Web applications, unsurprisingly, are usually harder to design and create than websites. Lots of people have their own websites today, and this was the case even ten years ago. The people who are able to create their own web applications can more easily make money off of them because it takes more work to learn how to code and create a web application.
Web service is a technology by which two or more remote web applications interact with each other over network/internet. It can be implemented using Java, .net, PHP etc. Web pages allow people to communicate and collaborate with each other while web services allow programs to communicate and collaborate with each other.
A web service is essentially a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer. This interoperability (e.g., between Java and Python, or Windows and Linux applications) is due to the use of open standards (XML, SOAP, HTTP).
All the standard Web Services works using following components:
- SOAP (Simple Object Access Protocol)
- UDDI (Universal Description, Discovery and Integration)
- WSDL (Web Services Description Language)
It works somewhat like this:
- The client program bundles the account registration information into a SOAP message.
- This SOAP message is sent to the Web Service as the body of an HTTP POST request.
- The Web Service unpacks the SOAP request and converts it into a command that the application can understand.
- The application processes the information as required and responds with a new unique account number for that customer.
- Next, the Web Service packages up the response into another SOAP message, which it sends back to the client program in response to its HTTP request.
- The client program unpacks the SOAP message to obtain the results of the account registration process.
Web Services Description Language (WDSL)
WSDL stands for Web Services Description Language. It is the standard format for describing a web service. WSDL was developed jointly by Microsoft and IBM.
Features of WSDL
- WSDL is an XML-based protocol for information exchange in decentralized and distributed environments.
- WSDL definitions describe how to access a web service and what operations it will perform.
- WSDL is a language for describing how to interface with XML-based services.
- WSDL is an integral part of Universal Description, Discovery, and Integration (UDDI), an XML-based worldwide business registry.
- WSDL is the language that UDDI uses.
- WSDL is pronounced as ‘wiz-dull’ and spelled out as ‘W-S-D-L’.
WSDL is often used in combination with SOAP and XML Schema to provide web services over the Internet. A client program connecting to a web service can read the WSDL to determine what functions are available on the server. Any special datatypes used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the functions listed in the WSDL.
Web Services Description Language (WSDL) is an XML language for describing Web services in a platform-independent way. A WSDL document describes a Web service’s methods by specifying the locations of the resources they use and defining the methods’ inputs and outputs. (A WSDL document for a Web service generated by the ATG platform always describes one method, because each Web service can expose only one Nucleus method.)
There must be a separate WSDL document for each Web service. The WSDL document is generated by the
/atg/webservice/WSDLGenerator component, which is of class
atg.webservice.WSDLGeneratorImpl. This document is used for two key purposes:
- It is used by the JAX-RPC API to generate run time classes.
- At run time, it is used by Web service clients to look up the semantics of the SOAP messages to send to invoke the service.
When the Web service’s input and output values are primitive types, they are defined in the primary WSDL document. For example:
<part name="in0" type="xsd:string">
Each non-primitive input or output requires its own WSDL document that is imported by the primary WSDL document. Import statements similar to the following are included in the primary WSDL document when the Web service is created using the Dynamo Administration UI:
location specified is relative to the primary WSDL document. Some Web service clients are able to interpret relative locations, but others require fully qualified URLs. To work with these clients, when the ATG platform receives a request for a WSDL document, it uses the servlet class
atg.webservice.WSDLFinderServlet and the filter class
atg.webservice.WSDLImportFilter to translate the
location value into a fully qualified URL:
- At runtime,
JAXRPCServletupdates the SOAP address in the WSDL document to include the domain host name and port number.
WSDLFinderServletdetects a WSDL request,
WSDLImportFilterappends the domain name and port number (from the SOAP address provided by
JAXRPCServlet) and the context path (by calling
request.getContextPath() on the Dynamo request) to the
locationvalue in the
importstatement. The resulting
importstatement looks similar to this:
How SOAP is used with HTTP
What is SIMPLE OBJECT ACCESS PROTOCOL (SOAP)?
SOAP is an XML-based protocol for accessing web services over HTTP. It has some specification which could be used across all applications.
SOAP is known as the Simple Object Access Protocol, but in later times was just shortened to SOAP v1.2. SOAP is a protocol or in other words is a definition of how web services talk to each other or talk to client applications that invoke them.
SOAP was developed as an intermediate language so that applications built on various programming languages could talk easily to each other and avoid the extreme development effort.
In today’s world, there is huge number of applications which are built on different programming languages. For example, there could be a web application designed in Java, another in .Net and another in PHP.
Exchanging data between applications is crucial in today’s networked world. But data exchange between these heterogeneous applications would be complex. So will be the complexity of the code to accomplish this data exchange.
One of the methods used to combat this complexity is to use XML (Extensible Markup Language) as the intermediate language for exchanging data between applications.
Every programming language can understand the XML markup language. Hence, XML was used as the underlying medium for data exchange.
But there are no standard specifications on use of XML across all programming languages for data exchange. That is where SOAP comes in.
SOAP was designed to work with XML over HTTP and have some sort of specification which could be used across all applications. We will look into further details on the SOAP protocol in the subsequent chapters.
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.
How SOAP can be used for functional oriented communication
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.
The structure of SOAP message in message oriented communication, indicating the elements used
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)
How a web service can be tested using different approaches
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:
- Postman, etc.
As mentioned in my previous posts related to web services or API testing, among above mentioned tools, We can consider Testingwhiz and SoupUI as the most user-friendly tools for API testing. Automating API testing, as a part of automated web services testing solution that helps you to test whether your application communicates and accesses functions correctly from the Web by effectively verifying the behavior of web services connected to them.
References Websites :
IBM Knowledge Center