Web Services

In my previous blog – “Learn Web Services Effortlessly” from Java Course In Pune – we looked back at the evolution of applications and specifically their evolution from monolithic applications into distributed applications, collaborative applications, web applications, and web2.0/digital applications.

This evolution drove applications to collaborate with each other to utilize each other’s application functionality via application programming interfaces (APIs). Initially, for similar technology stacks, these APIs were invoked directly. But with distributed applications and different languages evolving we got protocols like RPC, CORBA, RMI, COM/DCOM assisting us to expose our APIs over the network.

For Free Demo classes Call: 8237077325

Registration Link: Click Here!

With the growth of the internet and the global networks, the enterprises grew beyond the erstwhile boundaries, cross-enterprise collaboration grew and with it, the need to exchange data and services in a standard way grew and with it the requirements of web applications. This led to the evolution of XML markup language for data exchange and XML based standards and protocols like XML-RPC, SOAP and a whole set of web services based on these protocols. Out of these SOAP-based web services became most popular across enterprises for their standardization and feature richness for integration requirements.

Around the same time, the internet allowed a lot of internet applications, community applications and open innovated applications to develop. As they grew popular, they cross-integrated with other such applications. These new scenarios required a lighter web service version than the enterprise-grade SOAP-based web services. Thus, we got RESTFul WebServices that were easier to integrate over HTTP protocol powering the Internet. Also due to the popularity of JSON data format for messaging for internet applications, JSON RESTFul WebServices became the popular integration choice. With Web2.0 applications, this popularity has been ever increasing.

But now enough of the past. What I want to explain in this blog is to get an answer to “What are WebServices”.

What are Web Services

A search of this term on a search engine gives us a mind-blowing set of different definitions. But that in itself provides us a part of the answer to this question. The fact is that looking at a particular aspect of web service gives us one part of the answer.

So, let’s look at a definition provided by World Wide Web Consortium (W3C):

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

https://www.w3.org/TR/ws-arch/#whatis

While there would be a list of other definitions, the essential point is that they are describing the same core thing, in possibly different words and probably covering a specific set of aspects of web services. What we will do is work on the definition above and figure out what is the core of the definition.

For Free Demo classes Call: 8237077325

Registration Link: Click Here!

For e.g., the above definition was made as part of the W3C’s work in building the XML standards. Hence there is a bias towards mentioning WSDL, SOAP, XML, web standards as part of the definition. But if you look closely at the definition, these are provided as ways in which the web service implementation is carried out. Thus if we want to state it in a more generic way the definition would sound like this:

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format. Other systems interact with the Web service in a manner prescribed by its description using messages, typically conveyed using HTTP.

So essentially, it’s a service exposed by a software system with a defined interface towards other systems in a network. These systems can interact with it by sending messages over HTTP protocol and receiving messages in return. The format of the messages is specified by the interface.

We have seen what application services are in my previous blog. Web Services expose these application services towards others via the mechanism mentioned above.

We will see later that adding in the specifics into parts of the definition results in the variations of web services and the seeming multitude of definitions floating around. The key to navigating this is to hang on to the core generic definition and looking at what specifics have been added to it. So,

• A SOAP Service is one variation where we use SOAP messages defined in an interface definition called as WSDL – these interactions are typical as SOAP XML messages over HTTP protocol.
• A RESTful Web Service is one variation where we use HTTP methods (GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS, TRACE) to decide on the service interaction type and the target operation type. Also, the messaging is in a simpler XML or a more popular JSON format.

So, you could have further variations hereof XML RESTful Web Service or JSON RESTful Web Service+

We will deep dive further into SOAP and REST Web Services. Don’t worry if you didn’t understand their details right now. The point to be made was that they might look different at first (which they are, once you get into their implementation), but they have some commonality that we can appreciate to understand them better with the help of Java Classes In Pune.

The other aspect of Web Services is that they are independent of the language used for programming and the operating system of the infrastructure. All the features of web services are standard and hence can be implemented via any programming language and on any operating system. This has been a big reason for the growing popularity of web services as an integrating solution.

In summary, we could list down the features of web services as:

• Available over the network (intranet/internet)
• Supports application-to-application and machine-to-machine interaction
• Standardized messaging format (popular ones are XML, JSON)
• Use standardized network protocols (usually HTTP/HTTPS)
• Independent of programming language and infrastructure’s operating system

For Free Demo classes Call: 8237077325

Registration Link: Click Here!

Before we move ahead into the details of SOAP and REST Web Services, there is another concept that we need to clear – API. It’s something that keeps coming up whenever we look for web services and because of the terms being used loosely, we end up with a mixed-up view of the two.

Let’s look at what APIs are and what differentiates the two.

What are APIs

Application Programming Interfaces, defined simply, are interfaces of software applications. They define the operations of the application, the request and response structure and how the request and response interaction will proceed for that operation. APIs are utilized by other applications to access the application’s functionality.

So other applications call the API and the API then invokes the host application’s function.

If we look around in our computing environment, we will observe a number of APIs.

Some examples of the same are

• APIs to access the database (JDBC/ODBC API)
• Operating System APIs used by the applications executing on the operating system (Linux/Unix systems complying with POSIX APIs, Windows APIs)
• Java RMI API used for remote method invocation
• APIs exposed over the network (Web APIs) like the Twitter/Facebook APIs or the Amazon AWS/Azure APIs to program their Cloud Services

Usually, APIs are accompanied by specification and documentation that informs the users of the APIs about their functions or operations, request and response linked data structures, variables, configuration parameters.

In most modern implementations, APIs are also accompanied by Software Development Kits for most popular languages to allow developers to invoke the APIs easily from their consuming applications. But this is at the discretion of the API owner. In most cases, the API is exposed as a web service towards the consumer (also known as Web API) which is the most maintainable way as most languages support web service invocation.

For Free Demo classes Call: 8237077325

Registration Link: Click Here!

APIs have been the most common way in which applications have been sharing and accessing their functionality with each other. Check out some Web APIs listed at ProgrammableWeb:

https://www.programmableweb.com/category/all/apis

What is the difference between APIs and Web Services

After going through both APIs and Web Services, it’s clear that both expose an application’s functionality to other applications. Both eventually call the application’s function that processes the request, they receive a response from it and perform the mapping and conversion of the request/response to the structure defined by their interface.

But it is also clear that while APIs can be exposed as web services, they can also be interfaces to an application that are exposed internally within a system like Operating System API or as interfaces like JDBC that are consumed by Java clients directly via the JDBC API.

Thus, all web services may be APIs but not all APIs are web services.

Some other differences are:

• Web Services require an application server to expose their web interface towards the network. But APIs can be within an application if it’s just meant to be consumed by its local components.
• APIs are light-weighted as they are a more natural extension of the application’s function. Web Services are heavy in comparison as they have got a web interface so would have to implement standards like SOAP/REST.
• APIs provide greater flexibility to implement many cross-cutting aspects like different communication forms, caching, transaction, versioning. Web Services require greater effort in comparison to implement them, and in some cases requiring a particular type of standard to support the aspect (like SOAP-based standards WS-Transactions to support transactions). Also, web services have to conform to the HTTP/S communication protocol and the statelessness of the standard, while API (excluding Web API) have a more free hand in this area.
• APIs can use any communication form. Web Services typically use SOAP, REST and XML based messaging standard like XML-RPC as the communication medium.

 

Hopefully, this discussion about Web Services and APIs would have cleared some cobwebs around the differences of APIs and Web Services.

So let’s continue our journey deeper into SOAP and RESTful Web Services.

SOAP Web Service

SOAP is an abbreviation for Simple Object Access Protocol. It’s a messaging protocol that specifies request and response message/document exchanges based on XML usually over application layer protocol like HTTP (most used) or SMTP.

Web Service that is based on SOAP use WSDL (Web Services Description Language) document to describe the web service interface – the operations provided by the web service, request and response message structures provided by these operations and the binding to the protocol used and endpoint of the web service.

The consumers or client-side send request SOAP XMLs (usually over HTTP/S) and the server-side receives the request, passes the request parameters to the underlying application function. This function processes the request and generates the response. The response is marshaled into a SOAP XML response and sent back to the client.

SOAP Web Services also have standards for aspects like security, addressing and transactions. These can be added on to the SOAP Web Services if required.

For Free Demo classes Call: 8237077325

Registration Link: Click Here!

Due to the use of standard networking protocols like HTTP, its easier to get the web service to be accessible across any network as the exchanges can easily pass through existing network elements as well as firewalls and proxies. Also, the use of XML allows complex data structures to be easily represented as well as allow internationalized data exchange.

One of the bigger disadvantages of SOAP Web Services is that the interface description tends to be complex and the messages too verbose. Also, the XML parsing, marshaling/unmarshalling process makes the interaction slow and requires parsers on both client and server sides. This makes the SOAP client and SOAP Server-side implementations heavier.

RESTful Web Service

REST is an abbreviation for Representational State Transfer. Instead of a protocol like SOAP, it’s more an architectural style. So, each unique URL represents a server-side object in away. And REST Web Service uses HTTP networking protocol and utilizes the HTTP methods – GET, POST, PUT, DELETE, PATCH – to define what type of operation is done on the object. Creating an object is a POST method, Retrieving the object is GET method, replacing an existing object is PUT method, updating an existing object is PATCH method and deleting the object is represented by DELETE method.

Thus, Rest Web Services are most popular for CRUD services (Create, Retrieve, Update, Delete). The message exchange is mostly using JSON format due to its more lightweight nature, but XML is also an alternative here.

Rest Web Service is more lightweight as they don’t require heavy parsers and protocol implementations. They run directly over the HTTP protocol. Also, they are more readable and easier to build. This is one of the reasons why they have become popular in Web2.0 applications.

But the trade-off of messaging standards and standards to address other aspects like transactions and addressing limits some complex scenarios where these are a need.

For example, the use of HTTP directly and not having addressing standard leads to point-to-point client-server interactions. Though in this case, we have additional solutions like API Gateways that could allow breaking these interaction patterns.

Nevertheless, Rest Web Services are still very popular as CRUD scenarios are what applications usually expose to the outside world.

 

In Conclusion

We would continue our journey further into SOAP and Rest Web Service implementation details. But that would be in my next blogs on Java Training In Pune.

Author: Kiran Tiwari

Designation: Software Trainer

Company:  Seven Mentor Pvt. Ltd.

Call the Trainer and Book your free demo Class for JAVA now!!!

© Copyright 2019 | Sevenmentor Pvt Ltd.