WEB SERVICES and SOAP

WEB APPLICATIONS AND WEB SERVICES

A web application is a software application that a user runs in the web browser. It have the following features. A web service is an Application Program Interface (API) that runs on the server, which provide data to the client over http through a standardized messaging system. (XML, JSON, etc...)

Web applications are defined by being interactive. You're 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 your actions is probably going to be getting more information or learning more information, but the web application helped you perform that action. You 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 you 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 SERVICE DESCRIPTION LANGUAGE (WSDL)

The Web Services Description Language (WSDL) is an XML-based interface description language that is used for describing the functionality offered by a web service.

The WSDL describes services as collections of network endpoints, or ports. The WSDL specification provides an XML format for documents for this purpose. The abstract definitions of ports and messages are separated from their concrete use or instance, allowing the reuse of these definitions. A port is defined by associating a network address with a reusable binding, and a collection of ports defines a service. Messages are abstract descriptions of the data being exchanged, and port types are abstract collections of supported operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding, where the operations and messages are then bound to a concrete network protocol and message format. In this way, WSDL describes the public interface to the Web service.

WSDL is often used in combination with SOAP and an XML Schema to provide Web services over the Internet. A client program connecting to a Web service can read the WSDL file to determine what operations are available on the server. Any special data types 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 operations listed in the WSDL file using for example XML over HTTP.

FUNDAMENTAL PROPERTIES OF A WSDL USE OF WSDL DOCUMENT IN WEB SERVICES/CLIENT DEVELOPMENT

The web services description language (WSDL) describes the message syntax associated with the invocation and response of a web service. A WSDL file is an XML document that defines the web service operations and associated input/output parameters. In a way, the WSDL can be considered a contract between the web services client and the web services server.

Basically, a WSDL document describes three fundamental properties of a web service:

·            The operations (methods) that the service provides including input arguments needed to invoke            them and the response.

·             Details of the data formats and protocols required to access the service’s operations.

·             Service location details such as a URL.

STRUCTURE OF A WSDL DOCUMENT

Web Services Description Language (WSDL) is an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. The diagram below illustrates the elements that are present in a WSDL document, and indicates their relationships. To see an example of how this is implemented in a WSDL document, see Example of a WSDL Document.

WSDL DOCUMENT ELEMENTS

A WSDL document has a definitions element that contains the other five elements: types, message, Port Type, binding and service.

TYPES: Provides information about any complex data types used in the WSDL document. When simple types are used the document does not need to have a types section.

MESSAGE: An abstract definition of the data being communicated. In the example, the message contains just one part, response, which is of type string, where string is defined by the XML Schema.

OPERATION: An abstract description of the action supported by the service.

PORTTYPE: An abstract set of operations supported by one or more endpoints.

BINDING: Describes how the operation is invoked by specifying concrete protocol and data format specifications for the operations and messages.

PORT: Specifies a single endpoint as an address for the binding, thus defining a single communication endpoint.

SERVICE: Specifies the port address or addresses of the binding. The service is a collection of network endpoints or ports.

PORTTYPE vs OPERATION ELEMENTS IN WSDL

The portType element combines multiple message elements to form a complete one-way or round-trip operation.

For example, a portType can combine one request and one response message into a single request/response operation. This is most commonly used in SOAP services. A portType can define multiple operations.

Ex:

<portType name = "Hello_PortType">

   <operation name = "sayHello">

      <input message = "tns:SayHelloRequest"/>

      <output message = "tns:SayHelloResponse"/>

   </operation>

</portType>                                                                             

·        The portType element defines a single operation, called sayHello.

·        The operation consists of a single input message SayHelloRequest and an

·        output message SayHelloResponse

BINDING vs SERVICE ELEMENTS IN WSDL

The service element defines the ports supported by the web service. For each of the supported protocols, there is one port element. The service element is a collection of ports.

·        Web service clients can learn the following from the service element −

• where to access the service,
• through which port to access the web service, and
• How the communication messages are defined.

·  The service element includes a documentation element to provide human-readable documentation.

·         Ex:

·         <service name = "Hello_Service">

·            <documentation>WSDL File for HelloService</documentation>

·            <port binding = "tns:Hello_Binding" name = "Hello_Port">

·               <soap:address

·                  location = "http://www.examples.com/SayHello/">

·            </port>

·         </service>

The binding attributes of port element associate the address of the service with a binding element defined in the web service. In this example, this is

·         Hello_Binding

·         <binding name =" Hello_Binding" type = "tns:Hello_PortType">

·            <soap:binding style = "rpc"

·               transport = "http://schemas.xmlsoap.org/soap/http"/>

·            <operation name = "sayHello">

·               <soap:operation soapAction = "sayHello"/>

·                   

·               <input>

·                  <soap:body

·                     encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"

·                     namespace = "urn:examples:helloservice" use = "encoded"/>

·               </input>

·                           

·               <output>

·                  <soap:body

·                     encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"

·                     namespace = "urn:examples:helloservice" use = "encoded"/>

·               </output>

·            </operation>

·         </binding>

·          

USE OF SOAP WITH HTTP

SOAP defines a data encapsulation format and that's that.
Now the majority of traffic in the web is via HTTP. HTTP is literary EVERYWHERE and supported by a well-established infrastructure of servers and clients (namely browsers). Additionally it is a very well understood protocol.

The people who created SOAP wanted to use this ready infrastructure and

1.       SOAP messages were designed so that they can be tunneled over HTTP

2.       In the specs they do not refer to any other non-HTTP binding but specifically refer to HTTP as an example for transfer.

The tunneling over HTTP would and did help in its rapid adoption. Because the infrastructure of HTTP is already in-place, companies would not have to spend extra money for another kind of implementation. Instead they can expose and access web services using technology already deployed.

Specifically in Java a web service can be deployed either as a servlet endpoint or as an EJB endpoint. So all the underlying network sockets, threads, streams, HTTP transactions etc. are handled by the container and the developer focuses only on the XML payload.
So a company has Tomcat or JBoss running in port 80 and the web service is deployed and accessible as well. There is no effort to do programming at the transport layer and the robust container handles everything else.
Finally the fact that firewalls are configured not to restrict HTTP traffic is a third reason to prefer HTTP.

Since HTTP traffic is usually allowed, the communication of clients/servers is much easier and web services can function without network security blockers issues as a result of the HTTP tunneling.

SOAP is XML=plain text so firewalls could inspect the content of HTTP body and block accordingly. But in this case they could also be enhanced to reject or accept SOAP depending on the contents. This part which seems to trouble you is not related to web services or SOAP, and perhaps you should start a new thread concerning how firewalls work.

Having said that, the fact that HTTP traffic is unrestricted often causes security issues since firewalls are essentially by-passed, and that is why application-gateways come in.

FUNCTIONAL ORIENTED COMMUNICATION USE OF SOAP

Devices are categorized as either controlling devices or controlled devices, but a given device may play both roles, thus enabling peer-to-peer interactions. The interaction patterns of a device-level SOAP can be categorized according to five levels of functionality:

This is the foundation for device networking. In the case of IP-based networking, the addressing capacity is provided by the IP protocol, either IPv4 or IPv6.

Once a controlling device has discovered a controlled device, to learn more about the latter and its capabilities, the controlling device must retrieve the controlled device's description ("metadata"), including information like manufacturer name, version, serial number, etc. For each service exposed by a device, the device description defines the command messages, or actions, that the service responds to, as well as the associated message formats. 

Once it knows a controlled device, a controlling device can exert control over it. To invoke an action on a device's service, a controlling device sends a control message to the network endpoint for that service. Resultantly, the service may or may not return a response message providing any command specific information.

SOAP MESSAGE IN MESSAGE ORIENTED COMMUNICATION

SOAP is an XML message format (of an envelope, message headers, and a message body) and a standard encoding mechanism that allows messages to be sent over a variety of transports, including HTTP and JMS. SOAP-over-HTTP has been the most popular choice for Web services messaging, as it is a well-understood messaging model that is easy to implement and maintain. Due to the frequent use of SOAP-over-HTTP, SOAP is often understood to be a request-response (RPC-like) protocol. However, the synchronous flavor of SOAPover-HTTP results more from HTTP than from SOAP. If JMS is used as a transport, for example, SOAP can be used to implement asynchronous messaging. SOAP messaging can take different forms of reliability depending on the underlying transport chosen. While SOAP-over-HTTP is not reliable, SOAP-overHTTPR ensures that messages are delivered to their specified destination. Similar reliability guarantees can be made for SOAP-over-JMS and SOAP-over-Websphere MQ. On the other hand, a SOAP message itself can be extended to include reliability properties, using the recently proposed WS-Reliability or WS-Reliable Messaging standards. These “extended SOAP” messages then carry relevant reliability information that must be understood and supported by a messaging infrastructure (that Using Message-oriented Middleware for Reliable Web Services Messaging may or may not employ other reliable messaging technology such as Websphere MQ).

It is important to note that SOAP is both a message format and a transport-flexible messaging protocol. With SOAP messaging, we consequently refer to the use of SOAP as both a format and a protocol. To clarify the use of SOAP as a protocol, we refer "SOAP-over-<X>", where <X> is the chosen transport.  SOAP Messaging implies the use of a SOAP library (such as Apache AXIS [1]) to construct, send, receive, and parse SOAP messages, using the desired transport and encoding rules; an application involved in SOAP messaging interfaces the SOAP library, but does not interface any deployed middleware that implements the SOAP transport. If, on the other hand, a middleware like Websphere MQ is used as the messaging protocol and middleware, and SOAP-formatted XML messages are being exchanged (perhaps with the help of some utilities for manipulating SOAP envelopes), we refer to MQ messaging using SOAP/XML messages. Presently, SOAP as a messaging protocol is not particularly feature rich, making for subtle distinction between SOAP-over-JMS and JMS messaging using SOAP messages (for example.) However, this will change as SOAP matures; the proposed standards for reliable messaging and other specifications addressing.

IMPORTANCE OF THE SOAP ATTACHMENTS

SOAP attachments are described using the notion of a compound document structure consisting of a primary SOAP message part and zero or more related documents parts known as attachments.

The Attachment Feature defines a set of properties described in Property definition for the Attachment FeatureProperty NameProperty 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.

In SoapUI, you can simulate requests that transfer attachments to the tested server. SoapUI supports various technologies:

MTOM (Message Transmission Optimization Mechanism) – A method that W3C recommends to use for transferring binary data in SOAP messages.

SWA (SOAP with Attachments, also known as MIME for Web Services) – A MIME-based attachment mechanism for SOAP/HTTP. SoapUI supports plain SWA as well as swaRef attachments in accordance with the WS-I Attachments Profile.

SoapUI also supports specifying file names inline to insert binary contents from a file into a message body.

SOAP WEB SERVICES

SOAP stands for Simple Object Access Protocol. It is a XML-based protocol for accessing web services.

SOAP is a W3C recommendation for communication between two applications.

SOAP is XML based protocol. It is platform independent and language independent. By using SOAP, you will be able to interact with other programming language applications.

Ex:

AX-WS (SOAP based web services)

·         Apache Axis 2 Reference Implementation

·         Apache CXF – SOAP

·         Metro Reference Implementation

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”.

Ex:

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).

DIFFERENT APPROACHES & METHODS OF WEB SERVICES TESTING

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:

1.       SoapUI,

2.       TestingWhiz,

3.       SOATest

4.       TestMaker,

5.       Postman, etc.

As mentioned in my previous posts related to web services or API testing, among above mentioned tools, I 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.

Unit testing

Just like with testing of ordinary software components, unit testing is an important step to validate that these building blocks are working correctly. Also within web services, each operation must be exercised in isolation within the environment to confirm request and response. In particular, these tests will cover robustness of the operations by using so-called negative test cases (that check edge conditions and empty values etc.).

Functional testing

The goal of this testing is fairly straight forward: to ensure that the server delivers appropriate responses for the given requests. However, due to the complexity of Web services, this task is far from simple. With most Web services, it is impossible to anticipate exactly what types of requests clients will send. Enumerating all possible requests is not feasible because the space of possible inputs is either unbounded or intractably large. As are suit, it is important to verify with realistic business use cases whether the server can handle awide range of request type’s and parameters.

Regression testing

After you have verified the server's functionality, rerun the functional test suite on a regular basis to ensure that modifications do not cause unexpected change so failures. A common technique is to send various requests, manually confirm their spouses, and then save them as a regression control. These regression tests can be incorporated into a regular automated build process. When regression tests are run frequently, regressions are easy to fix because they can be directly attributed to the few changes made since the last time the test was run.

Load testing

The goal of load testing is to verify the performance and functionality of the service under heavy load. It is a vital steps to make sure the services will delivered the required Quality of Service (QoS) for the customers /users of the system.

The best way to start load testing is to have multiple test clients run the complete functional test, including request submissions and response verifications. When load testing ignores the functionality verification process and focuses solely on load-rate metrics, it risks overlooking critical flaws (such as functionality problems that surface only under certain loads).

REFERENCES:

·              www.quora.com

·              stackoverflow.com

·              en.wikipedia.org

·              www.ibm.com

·              www.tutorialspoint.com

·              www.oasis-open.org

·              citeseerx.ist.psu.edu

·              www.soapui.org

·              www.w3.org