Web Services, The Theories and Concepts of

The blog is migrated to https://thiloshon.wordpress.com    

   
Web Services are the most important elements of service oriented communication over the Internet.  Knowing the underlying concepts of web services and how it has evolved over the time is very much expected from programmers. We might know pure Java or any other languages top to bottom but if we don’t know how it's implemented in an industry or enterprise scenario there is not much use in what we learned. In this blog I cover many concepts and theories behind web services. In the subsequent blog I'll cover how to build one in Java using GlassFish as application server and SOAP as the protocol. Let’s dive in.

What is a web service?

Let’s start with a simple scenario. You go to HSBC in Kollupitiya and deposit 50 000 to your account. And then you go to HSBC in Wellawatta and try to get that 50 000 back. Can you get your money back? Of course you can. But you deposited in a different branch right? How does the Wellawatha branch know you deposited money in some other branch?  They are connected in some way, yeah? How exactly? When you type the amount in the deposit machine, insert the money and press “Okay”, the money is not physically sent anywhere. Just a simple request saying “INCREASE 50000 IN ACCOUNT 100098784” is sent to the server. In the server your balance will be increased by 50 000. You go to another branch, request 50 000. The machine in that branch will connect to the server, request the balance of your account and if its greater than 50 000 it will give you the money. Yeah? See this is exactly what a web service is.

“A web service is a service offered by an electronic device to another electronic device, communicating with each other via the World Wide Web” (Wiki)

Note here that you deposited the money in a machine. There was no involvement of a human in your transaction (The reason why I choose HSBC). This is the base of web service. Web service is for machine to machine communication, a computer connects to another computer and does an operation. If there was a staff typing the queries to increase your balance, then it wouldn't have been a web service. Its utmost important you understand this since everything there is to do with web services are made for machines, not humans.

Even in other banks when a human staff takes your money and deposits in your account it’s a web service too. Because the staff will be using a software (in our terms, a client) in his computer and type 50000 in amount text box and press enter. The software will communicate with server and will request server to increase your balance. So at the end it’s the software (a machine) which does the transaction with another machine. If the staff is a programmer and he types SQL queries and sends the query directly to server then it wouldn't have been a web service.  

What is SOAP, WSDL, XML?

When you learn about web services these are the terms you will come across frequently. Let’s see what each of these are.

XML (Extensible Markup Language)

XML is a tag based markup language which is used to describe page or file contents. What is meant by that? To understand that, I’ll describe myself in XML format.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<human>

      <name>

Thiloshon

      </name>

      <age>

21

</age>

<from>

      Colombo

</from>

</human>

See? this is what tag based language is. I am using tags to describe the attributes of me. The best part of XML is it’s both human readable and machine readable. You can read that and understand right? A machine can read that and maybe create a human object with attributes based on tags too.

class Human{

variable name = thiloshon;

variable age = 21;

variable from = colombo;

}

This is why XML is so popular and used widely. That’s all for XML, it’s just a small thing.

SOAP (Simple Object Access Protocol)

We have the XML description of me. Now what if we need to send it through Internet to the server, maybe to store it in the database. For that we need a protocol specification to exchange data through Internet. That is where SOAP comes to play.

“SOAP is a protocol specification for exchanging structured information in the implementation of web services in computer networks”.

Protocol is just a set of rules or standards we have to follow when using a technology. For example, SOAP protocol has three parts,

•          an envelope, which defines the message structure and how to process it
•          a set of encoding rules for expressing instances of application-defined data types
•          a convention for representing procedure calls and responses

To understand better, let’s see how a SOAP message requesting data about me and its response will look like.

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.example.org/stock/Surya">

  <soap:Header>

  </soap:Header>

  <soap:Body>

    <m:GetHumanDetail>

      <m:Name>Thiloshon</m:Name>

    </m:GetHumanDetail>

  </soap:Body>

</soap:Envelope>

And the XML response to this SOAP request will be something like this.

<m:GetHumanDetailResponse>

      <name>Thiloshon</name>

<age>21</age>

<from>Colombo</from>

</m:GetHumanDetailResponse>

Got it? This is what a SOAP is. Just a protocol for sending data through Internet.

Difference between SOAP and HTTP

Okay, you know SOAP stands for Simple Object Access Protocol. When we hear of protocols the first thing that comes to mind is HTTP, Hypertext Transfer Protocol. So how are these two related?

If you go back and check the SOAP section, I often said SOAP is a protocol for sending data through Internet. That ‘sending over the Internet’ part is the HTTP. See, SOAP is just a protocol that defines how the requests and responses should look like. We need a technology to send the SOAP messages over the Internet. SOAP uses HTTP and few other protocols like SMTP for this purpose. In reality the SOAP message I showed above will be wrapped in HTTP requests. So that same SOAP message will actually look like this.

The POST /InStock HTTP/1.1

Host: www.example.org

Content-Type: application/soap+xml; charset=utf-8

Content-Length: 299

SOAPAction: http://www.w3.org/2003/05/soap-envelope

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.example.org/stock/Surya">

  <soap:Header>

  </soap:Header>

  <soap:Body>

    <m:GetHumanDetail>

      <m:Name>Thiloshon</m:Name>

    </m:GetHumanDetail>

  </soap:Body>

</soap:Envelope>

So SOAP “uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.”

Why SOAP became so famous was, "SOAP allows processes running on many operating systems (such as Windows and Linux) to communicate using XML. Since Web protocols like HTTP are installed and running on all operating systems, SOAP allows clients to invoke web services and receive responses independent of language and platforms." It can be used in any platform, using any language thus it’s so independent. 

WSDL (Web Service Definition Language)

Let’s go back to the bank example. We have the HSBC bank web service and I’m depositing money. Now, the web service should understand what I am (client machine) requesting from the server. It should understand that a request to add money needs couple of parameters, the account number and amount of money. So what web services does is, it creates a kind of list with all the services offered by that web service. In our case, the list will have the services a bank needs. The list will be like,

•          deposit: parameters -  String accountNumber, int amount
•          getBalance: parameters - String accountNumber
•          getMoney: parameters – String accountNumber, int amount

When a client requests a service it first checks this list of services. It processes the request only if the request matches a method in this list. Say a request is sent for depositing without accountNumber. The web service checks if there are any services with the name ‘deposit’ with only one parameter the amount. Since there is no such service, the request won’t go through.

This is what accomplished by WSDL (WSDL is pronounced as 'wiz-dull' and spelled out as 'W-S-D-L'). WSDL is that list I talked of above. It’s the description of the services available by the web service. WSDL definition describes how to access a web service and what operations it will perform.

But in reality a WSDL document will look like this.

<definitions name="HelloService"

   targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl"

   xmlns="http://schemas.xmlsoap.org/wsdl/"

   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

   xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"

   xmlns:xsd="http://www.w3.org/2001/XMLSchema">

   <message name="SayHelloRequest">

      <part name="firstName" type="xsd:string"/>

   </message>

      

   <message name="SayHelloResponse">

      <part name="greeting" type="xsd:string"/>

   </message>

   <portType name="Hello_PortType">

      <operation name="sayHello">

         <input message="tns:SayHelloRequest"/>

         <output message="tns:SayHelloResponse"/>

      </operation>

   </portType>

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

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

</definitions>

(tutorialspoint)

So those are the main terms and concepts behind web services. There is one more, UDDI I'll come to that later. Now we have learned all these, it's a bit clouded as to what exactly happens when a request is sent to the server right? lets take that bank scenario again. 

Steps in a web service communication. 

You are depositing money in bank. You type all the details and press 'Okay'.

1. The client program (Computer Program in Bank ATM machine) bundles the depositing information into a SOAP message.
2. This SOAP message is sent to the web service as the body of an HTTP POST request.
3. The web service unpacks the SOAP request and converts it into a command that the application can understand.
4. The application processes the information as required and responds with a transaction success or failure message.
5. Next, the web service packages the response into another SOAP message, which it sends back to the client program in response to its HTTP request.
6. The client program unpacks the SOAP message to let user know if the deposit went through.

FAQs

A lot of confusions rise when we talk about web services. I will address some of the common ones. 

Where does REST come in?

There are two main specifications for web services. One using SOAP, the other one using REST. I've discussed about SOAP in the blog. But SOAP has become a thing of the past now. Now REST is used widely for number of reasons. it has a simpler style that makes it easier to use than SOAP. It is also less verbose so that less volume is sent when communicating. REST doesn't need any of the WSDL or UDDI. If I am to talk about REST I will need another full blog.

Where do I have to implement all these WSDL and rest?

Nowhere! All these things are underlying concepts. You will never have to implement the WSDL or SOAP messages. It’s all taken care by the servers and IDEs. You will be configuring few of the settings though but in a nice GUI provided by the server and IDEs. So why go through all these hassle to learn all these? It’s important to understand what is happening in low level when you are developing something. When you tweak a configuration, you should know what you are really changing. That differentiates a good programmer from a normal one.

 What is GlassFish?

The web services have to be hosted in server for accepting requests. These servers are called Application Servers (It differs from normal web server). GlassFish is one such Application Server exclusively for the Java EE (Enterprise Edition) platform. What that means is, any web service developed using Java can be hosted with GlassFish server. “But GlassFish is a multi-purpose utility which is very flexible. So it is not really very easy to sum it up in a simple ‘It does X’ statement”. Because it can also be used as a Web Server (Http Server) for handling HTTP requests (usually from browsers).

What is the difference between GlassFish server and Apache server?

This goes back to the previous question. GlassFish is an application server. It is the reference implementation for a Java EE application server. But Apache HTTP server is just a web server for serving HTTP requests. (But Apache has a Servlet and JSP Server serving Java technologies called Tomcat)

What is the future of web services, is it worthy to spend time learning this?

The web services come under the architecture called Service Oriented Architecture (SOA). The SOA has evolved a lot in the past and is continuously evolving. SOAP and XML based communication was the hot topic when it came out first. But once REST was introduced, SOAP lost its importance and REST took over. Now we see Web Oriented Architecture becoming famous in the recent times. Platform-as-a-Service (PAAS), AJAX, Widgets, Web APIs, URIs, OpenID, SSL, OAuth, REST, JSON are all part of WOA. In lines of web services, we see the increasing popularity of Micro Services Architecture.  Micro Service is an architectural style that structures an application as a collection of loosely coupled services.

All these suggest the web services are rapidly evolving. Spending a little time on learning the basic web service concepts and then spending most of the time on the various new implementations will be the ideal. 

That concludes the Theory and Concepts behind Web Services. Don't forget to check the next blog in which I build a web service and deploy it. If you have any doubts or corrections to make please comment below.