WEB SERVICES

Web Application 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 Services

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.

The Web Services Description Language (WSDL) is an XML-based interface description language that is used for describing the functionality offered by a web services. The acronym is also used for any specific WSDL description of a web service (also referred to as a WSDL file), which provides a machine-readable description of how the service can be called, what parameters it expects, and what data structures it returns. Therefore, its purpose is roughly similar to that of a type signature in a programming language.

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

portType (Analogs to Java interface)

• PortType is an abstraction part of WSDL.
• An abstract set of operations supported by one or more endpoints.

binding

• Binding is an concrete part of WSDL.
• Describes how the operation is invoked by specifying concrete protocol and data format specifications for the operations and messages.
• bindings are three types
1. SOAP Binding:
   SOAP binding allows either document or rpc style with either encoding or literal. Encoding indicates how a data value should be encoded in an XML format (These rules specify how "something" is encoded/serialized to XML and then later decoded/de-serialized from XML back to "something"). Literal means that the data is serialized according to a schema (this is just plain XML data). With transportation type http, jms, smtp...
2. HTTP GET & POST binding:
   WSDL includes a binding for HTTP 1.1's GET and POST verbs in order to describe the interaction between a Web Browser and a web site.
3. MIME binding: WSDL includes a way to bind abstract types to concrete messages in some MIME format.

In WSDL:

• PortTypes renamed to interfaces
• Ports renamed to endpoints
• Removed message constructs

SOAP (Simple Object Access Protocol)

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 headder 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 micro service-centric development environments

SOAP is an integral part of the service-oriented architecture (SOA) and the Web services specifications associated with SOA. Because it allows the sender to create a message route based on the logical services that have to be applied to the message on the way to its destination, it lends itself to providing secure and compliant connections, controlling access, offering reliable delivery and failure recovery, and supporting dynamic service discovery. SOA without SOAP is difficult to imagine.
SOAP’s messages are defined at a high level in XML, but most SOAP applications use Web Services Definition Language (WSDL), which is authored in XML.  The XML structure of SOAP makes it handy for applications that expect their information to be provided in XML form, and the fact that SOAP can ride on a variety of network protocols, including HTTP, means it’s easily passed through firewalls, where other protocols might require special accommodation.
The data structure of SOAP is based on XML, which is similar in many ways to the HTML used to define web pages. Like HTML, XLM is largely human-readable, which makes it fairly easy to understand a SOAP message, but also makes the messages relatively large in comparison to the Common Object Request Broker Architecture (CORBA) and its Remote Procedure Call (RPC) protocol that will accommodate binary data.
The biggest disadvantage of SOAP (and SOA overall) is that it’s a heavyweight protocol for a heavyweight architecture.  The notion of a message passing through a string of nodes to be processed by each seems to mix protocols and service bus architectural models for software, and neither of those two are considered optimal for micro service-based development as popularly used today.
SOAP is a protocol that’s almost always used in the context of a Web Services/SOA framework.  As such, its application programming interface (API) is typically hidden by the higher-level interface for SOA. There are SOA API middleware tools available for nearly all modern programming languages, and Microsoft offers a variety of .NET SOAP/SOA tools.
SOAP is designed to break traditional monolithic applications down into a multi-component, distributed form without losing security and control. In contrast, REST is a model of distributed computing interaction based on the HTTP protocol and the way that web servers support clients. REST over HTTP is almost always the basis for modern microservices development and communications. RESTful APIs uses HTTP requests to GET, PUT, POST and DELETE data.
REST/HTTP is simple, flexible, lightweight, and offers little beyond a way of exchanging information. SOAP can ride on HTTP as well, but it connects the elements of a complex set of distributed computing tools (the Web Services and SOA framework) as well as application components, and this forms a part of a total service-oriented framework

JAX-WS annotations

@WebService

This JAX-WS annotation can be used in 2 ways. If we are annotating this over a class, it means that we are trying to mark the class as the implementing the Web Service, in other words Service Implementation Bean (SIB). Or we are marking this over an interface, it means that we are defining a Web Service Interface (SEI), in other words Service Endpoint Interface.
Now let’s see the java program demonstrating both of the mentioned ways:
WSAnnotationWebServiceI.java

package com.javacodegeeks.examples.jaxWsAnnotations.webservice; import javax.jws.WebMethod; import javax.jws.WebService; import javax.jws.soap.SOAPBinding; import javax.jws.soap.SOAPBinding.Style; @WebService @SOAPBinding(style=Style.RPC) public interface WSAnnotationWebServiceI {     @WebMethod     float celsiusToFarhenheit(float celsius); }

In the above program we can see that we haven’t provided any optional element along with the @WebService annotation. And here it is used to define SEI. Regarding the other annotations used in the above program, we shall see their description a little ahead.
WsAnnotationsWebServiceImpl.java

package com.javacodegeeks.examples.jaxWsAnnotations.webservice; import javax.jws.WebService; @WebService(endpointInterface="com.javacodegeeks.examples.jaxWsAnnotations.webservice.WSAnnotationWebServiceI") public class WsAnnotationsWebServiceImpl implements WSAnnotationWebServiceI {     @Override     public float celsiusToFarhenheit(float celsius) {         return ((celsius - 32)*5)/9;     } }

In the above program we can see that we have provided an optional element endpointInterface along with the @WebService annotation. And here it is used to define SIB. endpointInterface optional element describes the SEI that the said SIB is implementing.
While implementing a web service as in above example, it is not mandatory for WsAnnotationsWebServiceImpl to implement WSAnnotationWebServiceI, this just serves as a check. Also, it is not mandatory to use an SEI, however, as a basic design principle “We should program to interface”, hence we have adapted this methodology in above program.
Other optional elements to @WebService can be like wsdlLocation that defines location of pre-defined wsdl defining the web service, name that defines name of the web service etc.