Web services and SOAP

Web Service

World Wide Web Consortium describes web service as a system of software allowing different machines to interact with each other through network. Web services achieve this task with the help of XML, SOAP, WSDL and UDDI open standards.

XML:
  The full form of XML is ‘Extensible Markup Language’ which is used to share data on the web and in universal format.

SOAP:
 Standing for ‘Simple Object Access Protocol’ which is an application communication protocol that sends and receives messages through XML format. It is one of the best ways to communicate between applications over HTTP which is supported by all browsers and servers.

WSDL:
 Written in XML, WSDL stands for Web Services Description Language and is used to describe web service. WSDL comprises three parts such as Definitions (usually expressed in XML including both data type definitions), Operations and Service bindings. Operations denote actions for the messages supported by a Web service.
There are three types of operations:
1. One way
2. Request response
3. Notification
 Service bindings is a connecting to the port.

UDDI:
Universal Description, Discovery, and Integration (UDDI) provides the description of a set of services supporting the depiction and discovery of businesses, organizations, and other Web Services providers. It is based on common set of industry standards, including HTTP, XML, XML Schema, and SOAP.

Web Application

An application that the users access over the internet is called a web application. Generally, any software that is accessed through a client web browser could be called a web application.

A ‘client’ can be referred to the program that the person use to run the application in the client-server environment. The client-server environment refers to multiple computers sharing information such as entering info into a database. Here the “client” is the application that is used to enter the info, while the “server” is the application that is used to store the information.

Web Services vs Web Applications

• Web Services can be used to transfer data between Web Applications.
• Web Services can be accessed from any languages or platform.
• A Web Application is meant for humans to read, while a Web Service is meant for computers to read.
• Web Application is a complete Application with a Graphical User Interface (GUI), however, web services do not necessarily have a user interface since it is used as a component in an application.
• Web Application can be access through browsers. 

  WSDL 


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 Usage

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.

 

 
 WSDL Usage. 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.


4.Discuss the structure of the WSDL document, explaining the elements in WSDL?

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.

 

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(es) of the binding. The service is a collection of network endpoints or ports. 

5.Compare the PortType and operation elements in WSDL with the java equivalences?

 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.

6.Compare and contrast the binding and service elements in WSDL?

 Binding − It is the concrete protocol and data formats for the operations and messages defined for a particular port type.

Service − It is a collection of related end-points encompassing the service definitions in the file; the services map the binding to the port and include any extensibility definitions.

 7.Explain how SOAP is used with HTTP?

SOAP is a messaging protocol and in a nutshell is just another XML language.
Its purpose is the data exchange over networks. Its concern is the encapsulation of these data and the rules for transmitting and receiving them.  

First of all 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 it's 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.


8.Discuss 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

1. 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.
2. 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.
3. 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

1. 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.
2. 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. 

9.Explain the structure of SOAP message in message oriented communication, indicating the elements used?

A SOAP message is encoded as an XML document, consisting of an <Envelope> element, which contains an optional <Header> element, and a mandatory <Body> element. The <Fault> element, contained in <Body>, is used for reporting errors.

The SOAP envelope

<Envelope> is the root element in every SOAP message, and contains two child elements, an optional <Header> element, and a mandatory <Body> element.

The SOAP header

<Header> is an optional subelement of the SOAP envelope, and is used to pass application-related information that is to be processed by SOAP nodes along the message path; see The SOAP header.

The SOAP body

<Body> is a mandatory subelement of the SOAP envelope, which contains information intended for the ultimate recipient of the message; see The SOAP body.

The SOAP fault

<Fault> is a subelement of the SOAP body, which is used for reporting errors; see The SOAP fault.

XML elements in <Header> and <Body> are defined by the applications that make use of them, although the SOAP specification imposes some constraints on their structure. The following diagram shows the structure of a SOAP message.

10.Discuss the importance of the SOAP attachments, explaining the MIME header? 

You can send and receive SOAP messages that include binary data (such as PDF files or JPEG images) as attachments. Attachments can be referenced (that is, represented explicitly as message parts in the service interface) or unreferenced (in which arbitrary numbers and types of attachments can be included).

A referenced attachment can be represented in one of the following ways:

• MTOM attachments use the SOAP Message Transmission Optimization Mechanism  ) specified encoding. MTOM attachments are enabled through a configuration option in the import and export bindings and are the recommended way to encode attachments for new applications.
• As a wsi:swaRef-typed element in the message schema
  Attachments defined using the wsi:swaRef type conform to the Web Services Interoperability Organization (WS-I) Attachments Profile Version 1.0  , which defines how message elements are related to MIME parts.
• As a top-level message part, using a binary schema type
  Attachments represented as top-level message parts conform to the SOAP Messages with Attachments  specification.
  Attachments represented as top-level message parts can also be configured to ensure that the WSDL document and messages produced by the binding conform to the WS-I Attachments Profile Version 1.0 and the WS-I Basic Profile Version 1.1 

An unreferenced attachment is carried in a SOAP message without any representation in the message schema.

In all cases, except MTOM attachments, the WSDL SOAP binding should include a MIME binding for attachments to be used, and the maximum size of the attachments should not exceed 20 MB.

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.

  

List of web service frameworks

 JAX-WS annotations

• 1.1 @WebService. This JAX-WS annotation can be used in 2 ways. ...
• 1.2 @SOAPBinding. Demonstration of @SOAPBinding JAX-WS annotation has already been shown in first program in 1.1. ...
• 1.3 @WebMethod. @WebMethod JAX-WS annotation can be applied over a method only. ...
• 1.4 @WebResult. ...
• 1.5 @WebServiceClient.

Web Service Testing

 

Web Services Testing is testing of Web services and its Protocols like SOAP & REST. To test a Webservice you can

1. Test Manually
2. Create your own Automation Code
3. Use an off-the shelf automation tool like SoapUI.

WebService Testing involves following steps -

1. Understand the WSDL file
2. Determine the operations that particular web service provides
3. Determine the XML request format which we need to send
4. Determine the response XML format
5. Using a tool or writing code to send request and validate the response

Suppose we want to test a WebService which provides Currency Conversion Facility. It will the current conversion rates between the different countries currency. This service we can use in our applications to convert the values from one currency to the other currency.