Web services and SOAP ~ Programming Applications and Frameworks

Web applications Vs Web services

Any piece of software that makes itself available over the internet is called a Web Service. It uses a standardized XML messaging system. Encoding all communications to a web service is done by XML.

For example; a client might send a XML message for a web service, then it waits for the adjacent XML respond.

Since the communication is done using XML, there will be no problems of communication between 2 different operating system and languages.

An application program stored in a remote server and accessed over internet is known as a Web Application. This is also known as the client-server program and in the web browser, the client runs the user interface, logics and etc.

For example; our ITPM project is a web application, it will have a server and a client, where the client requests from the server.

Web services facilitates different applications to communicate with each other. Web services are used to make the platform and technology independent.

Web Service Description Language

Web Service Description Language or WSDL is a standard format for describing the functionality provided by a web service. Functions of the web services are described using XML language.

Protocol used for information exchange in decentralized and distributed environment is WSDL, which is an XML-based protocol.

WSDL describes about on how to access a web service and operations performed by the web service.

Fundamental properties of a WSDL document

WSDL is used for describing the services available. Primarily used for business to communicate with clients.

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.

UDDI uses WSDL as its language that.

The structure of the WSDL document

WSDL is used for describing the services available. Primarily used for business to communicate with clients, so that client applications are able to understand what the web service actually does.

A WSDL file contains:

The location of the web service
The methods given by the web service.

WSDL can be seen as a bit complex, but it has the needed information that any client application would require to use the relevant web service.

The general structure of a WSDL file:

Definition
TargetNamespace
DataTypes
Messages
Porttype
Bindings
service

Definition of messages that is passed by the SOAP protocol is defined in the WSDL document.

WSDL document represents the actual types of SOAP messages that are sent and accepted by the Web service to the client application.

WSDL is just similar to a postcard which contains the address of a location. The address consists of the details of an individual who delivered the postcard. Similarly this contains the address of the web service which can provide all the functionality needed by the client.

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

WSDL Example:

Void - addOperation(Operation operation)

Add an operation to this port type.

---------------------------------------------------------------------------------

org.w3c.dom.Element - getDocumentationElement()

Get the documentation element.

---------------------------------------------------------------------------------

Operation - getOperation(java.lang.String name, java.lang.String inputName,
java.lang.String outputName)

Get the specified operation.

---------------------------------------------------------------------------------

java.util.List - getOperations()

Get all the operations defined here.

----------------------------------------------------------------------------------------

QName - getQName()

Get the name of this port type.

---------------------------------------------------------------------------------

Boolean - isUndefined()

--------------------------------------------------------------------------------

void - setDocumentationElement(org.w3c.dom.Element docEl)

Set the documentation element for this document.

---------------------------------------------------------------------------------

void - setQName(QName name)

Set the name of this port type.
---------------------------------------------------------------------------------
void - setUndefined(boolean isUndefined)

---------------------------------------------------------------------------------

<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"/>

</portType>

PortType and operation elements in WSDL

Public interface portType, extends Java.io.Serialiazable. A portType is represented using this interface, it contains information about operations associated with this portType.

Method summary of the portType interface (which is a java equivalent):

Binding and Service elements in WSDL

The element which defines the ports supported by the web service is <service> element. There is one port element for each supported protocols. Service element is a collection of ports.

Element which provides specific details on how a portType operation will actually be carried over communication cable is <binding> element.

For example; Binding can be made available via HTTP, GET, POST, and SOAP, which are some multiple transports.

How SOAP is used with HTTP

Simple Object Access Protocol or SOAP is used as the messaging protocol. This is used to exchange data over networks. HTTP is an application protocol and SOAP resides in this HTTP protocol as the HTTP payload.

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.

Structure of SOAP message in message oriented communication

SOAP is encoded as an XML document, these are the elements used in the structure of the SOAP messages.

The SOAP envelope

The root element is the <Envelope> element, which has 2 child elements, an optional <Header> element, and a compulsory <Body> element.

The SOAP header

<Header> is a sub element which is an optional of the SOAP envelope, and is used to transfer application-related information which is to be processed by SOAP nodes throughout the message path.

The SOAP body

<Body> is a compulsory sub element of the SOAP envelope that has the information intended for the ultimate recipient of the message.

The SOAP fault

Another sub element of the SOAP body is <Fault>, which is used for stating errors.

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.

Example of a SOAP message which contains the header block (the <m:reservation> and <n:passenger>elements) and a body (containing the <p:itinterary> element).

SOAP is a protocol which is used to interchange data between applications which are built on different programming languages.
SOAP is built upon the XML specification and works with the HTTP protocol. This makes it a perfect for usage within web applications.
The SOAP building blocks consist of a SOAP Message. Each SOAP message consists of an envelope element, a header, and a body element.
The envelope element is the mandatory element in the SOAP message and is used to encapsulate all of the data in the SOAP message.
The header element can be used to contain information such as authentication information or the definition of complex data types.
The body element is the main element which contains the definition of the web methods along with any parameter information if required.

Importance of the SOAP attachments

SOAP with Attachments or SWA, also known as MIME for Web Services – A MIME-based attachment mechanism for SOAP/HTTP.

A SOAP message might have to be transmitted with attachments of various sorts, ranging from facsimile images of legal documents to engineering drawings. These data are mostly in some binary format. For example, either GIF or JPEG data formats are mostly used to transmit images on the Internet. The native format of the attachment is multipart MIME structure for transport.

Different set of frameworks/libraries for SOAP web service development

Different frameworks for .NET, PHP, JAVA:

· Rubymine (RM) is a framework developed by the jetBrains for java applications.

· Apache Axis2 is another framework for java applications.

· Codegniter is a framework used for PHP.

Windows communication Foundation is a framework used for .NET

Annotations in JAX-WS

The @ApplicationPath Annotation

Example:

@ApplicationPath("/api")

public class RESTConfig extends Application {}

This is the start of defining a URI to our resources. Here we are saying that all our resources can be found at the root/api.

The @Path Annotation

Example:

@Path("/books")

public class BookResource {}

Now, the URI to the book resource is /api/books and the URL would be http://localhost:8080/webcontext/api/books. It is the convention to name the resource as a noun and in the plural.

The @GET HTTP Method Annotation

Example:

@GET

@Produces(MediaType.APPLICATION_JSON)

public Response getAllBooks() {

    List<Book> books = BookRepository.getAllBooks(); // queries database for all books

    GenericEntity<List<Book>> list = new GenericEntity<List<Book>>(books) {};

    return Response.ok(list).build();

Note that the Generic Entity wrapper is used to maintain the generic type of the List as Book.

The @POST HTTP Method Annotation

Example:

@POST

@Consumes(MediaType.APPLICATION_JSON)

@Produces(MediaType.APPLICATION_JSON)

public Response saveBook(Book book) {

    book = bookRepository.saveBook(book);

    return Response.ok(book).build();

The POST HTTP method is commonly used to create a resource. This example code persists the new book object in the database.

How a web service can be tested using different approaches

To check that all of the Application Programming Interfaces (APIs) presented by our application operate as expected we need to test the Web Services. They are similar to unit tests in that they test particular pieces of code rather than user interface objects.

Unlike unit tests, web services are being called across a network using the HTTP/HTTPS protocol rather than simply calling code that is resident on the same system as the test script. In that sense, they are similar to testing web sites.

Finally, in situations where you have an AJAX web application, as well as testing the front-end user interface using the appropriate UI library, you may need to test the web service that is providing the data to the user interface at the same time. In these situations you have a hybrid, web user interface and web service test.

References:

https://en.wikipedia.org/wiki/Web_application

https://www.tutorialspoint.com/webservices/what_are_web_services.htm

https://www.tutorialspoint.com/wsdl/wsdl_introduction.htm

https://www.w3schools.com/xml/xml_wsdl.asp

https://www.tutorialspoint.com/wsdl/wsdl_binding.htm

https://www.guru99.com/soap-simple-object-access-protocol.html