Web Service

A key interoperability feature is that web services are platform- and technology-independent. This means they can be written in a variety of programming languages while maintaining the ability to communicate – regardless of operating system or type of device – by exchanging data between clients and servers. For example, a web service can allow a .NET application to exchange data with a Java application, and vice versa.

Modern web services are an implementation of service-oriented architecture (SOA). In SOA, there are two software components that communicate with each other: the consumer software and the provider software. The consumer sends a request to the provider and the provider sends a response back to the consumer.

Here are some common examples of how organizations use web services:

• Online retailers use web services to calculate shipping costs in real-time. They are able to pull information on item weights and customer locations to calculate correct shipping rates.
• Travel sites use web services to pull data from a variety of other travel-related sites, such as airline and hotel websites, to find and rank the best travel deals.
• SaaS vendors use web services to integrate with other software applications. For instance, email service providers offer web services that integrate with an organization’s existing CRM tools.

How do Web Services work?

Asynchronous JavaScript and XML – also known as AJAX – is one of the technologies used to create web services. It is a compilation of languages that can be used to express complex messages between different platforms and programming languages, which includes a mix of JavaScript, XML, and HTTP server technology. As web services have evolved, JSON is frequently used in addition to, or in lieu of, XML XML messages are exchanged using the HTTP protocol, which is the most commonly used protocol across the Internet. Web services can support communication across apps with a number of open standards, such as HTML, XML, WSDL, SOAP, REST, and more.

When using an application, a user makes a selection or request from an application, which then returns data to the user to complete the interaction. Web services streamline this process by pulling data from multiple sources, including databases, websites, and other applications across the Web, and then returning it to the user. 

A unique aspect of web services, as compared to other models of client and server communication technology, is that they do not typically provide a graphical user interface (GUI). Rather, they use a programmatic interface that shares business logic, data, and processes. 

Essentially, applications interact with other applications instead of with users. This is why web services are sometimes also referred to as application services. However, web services can be added to a separate GUI to be operated by users, namely developers.

Benefits of web services

The essential functions of a web service include the following:

• Web services are available both over the internet or intranet networks
• They use a standardized JSON or XML messaging and tagging system
• Because all communication is in XML, they’re not bound by a single operating system (OS) or programming language
• Web services are discoverable through a simple location method

Limited system integration and interoperability have long been an issue that hampered the exchange of data across different technologies, formats, vendors, and B2B (business-to-business) operations. Web services have made system integration and interoperability commonplace in the modern digital landscape. 

Their reduced complexity allows IT professionals to streamline connectivity and they provide efficient technology distribution throughout an entire network that leads to a higher return on investment (ROI).

The major benefits of using web services can be broken down into three categories:

• Improved development productivity: Because they let different systems share data and functions, web services simplify the development process. Instead of building every feature into a new application, developers can call web services to pull data and functionality from other applications and deliver it to the end user.
• Extend the life of legacy systems: Web services allow new applications to communicate with legacy systems. Instead of replacing an entire system or network infrastructure, web services can bring modern features to old systems.  
• Cloud adoption: Increasingly, more organizations are adopting SaaS solutions and moving applications to cloud hosts. This is greatly growing the need for integration. Web services make it possible to connect cloud, on-premises and SaaS applications. They allow apps to communicate and share data regardless of physical location.

Explore web services in depth at Developer.com

History of web services

Before web services, organizations had no way to exchange information between different systems. Development was time-consuming and intensive as every single feature of a software tool had to be built from scratch. 

The Object Model

In the late ’90s, multiple technologies allowing remote procedure calls (RPC) from one system to another were developed. 

The Common Object Request Broker Architecture (CORBA) uses a distributed architecture to enable interaction between different OS’s, programming languages, and hardware components. 

The Remote Method Invocation (RMI) is similar to CORBA but entirely Java-based. It was a great option for Java programmers but was limited in scope in its operability. 

The Distributed Component Object Model (DCOM) is a proprietary Microsoft solution that allowed communication between software components only for native Windows programs. DCOM was the biggest competitor to CORBA at the time.

Early standards had some major limitations. For RMI and DCOM specifically, they were restricted in what platforms they could interoperate with. But all three ran into serious problems when trying to operate over internet firewalls and unknown or insecure machines.

XML-RPC

Soon after, Microsoft wanted to develop a way to interoperate with systems outside of just Windows programs. In 1998, Microsoft pushed XML-RPC as a truly open technology for operating over the web infrastructure. XML-RPC uses XML format to encode its calls and HTTP as a transport mechanism. XML-RPC’s simplicity made it a popular choice.

SOAP

Eventually, organizations required a greater level of structure and support for data types and operations semantics. As a result, XML-RPC evolved into the more elaborate SOAP (Simple Object Access Protocol) communication protocol for accessing web services. The SOAP 1.2 spec became a W3C recommendation in 2003. 

There was also an increased focus on automation at this time to further streamline the use of web services. WSDL (Web Services Description Language) became the standard for automatically defining web services interfaces. It explains how to use the web services of the service provider. In conjunction, UDDI (Universal Description, Discovery, and Integration) became the standard for automatically registering and finding web services on the Web, basically acting as a directory. SOAP, WSDL, and UDDI form what is commonly known now as modern Web Services.

RPC-style to Document-style

When SOAP first became widely adopted, RPC-style was primarily used. With RPC, the client sends a request to a server and the server immediately sends a response back to the client. 

There are two major issues with RPC-style: 

1. Stability: The object model that these interfaces are based on is not completely stable. The attributes and operations of this model would inevitably change over time. As the corresponding web services are re-generated to match these changes, the interface becomes increasingly complex and fragile.
2. Processing requirements: RPC-style inherently requires synchronous processing. The RPC-style mandates the client end-point to be expecting the remote procedure call to return from the server-side.

As Web Services became more popular, Document-style was developed. Document-style Web Services emphasize publishing a schema and exchanging messages instead of defining a rigid set of operations. Document-style is also known as SOA style.

REST

Even with the introduction of Document-style, SOAP-based web services are complex. RESTful web services are now becoming popular as a more simplistic alternative. REST (Representational State Transfer) was introduced in 2000. It was designed to interact with stateful resources instead of messages or operations.

RESTful web services rely on standard operations already defined by the HTTP protocol: GET and POST, but also PUT and DELETE. These operations allow interaction with stateful resources uniquely identified on the network.

A common example of a RESTful Web Service is RSS. It consists of an HTTP GET operation that returns an XML formatted representation of the state of resources exposed by the server.

SOAP vs. REST

SOAP is best suited for supporting complex business operations. This is typically the case for enterprise organizations needing more complexity for legacy services and security.

REST, on the other hand, is best suited for implementing simpler operations. Typically, consumer-focused web services, such as Amazon or Google, benefit from RESTful web services.

Web services vs. APIs

Web services and Application Programming Interfaces (API) are often confused with each other. While all web services can be APIs because they expose an application’s data and functionality, not all APIs can be web services. Most web services actually provide an API.

Web services are a resource available online that can share data between two systems and carry out specific tasks. The client makes a request for data and the server responds to the client request. An API, on the other hand, is an interface used to program software that interacts with an existing application. 

Both web services and APIs are accessed through HTTP/HTTPS to call a function and receive a response. However, web services can only support HTTP/HTTPS requests while APIs can support URL, request/response headers, caching, versioning and various content formats. This also means that web services must be connected to a network in order to function, whereas APIs can also be used offline. 

APIs have a more lightweight architecture and are best for applications on limited bandwidth devices, such as smartphones. Web services have a more complex structure to accommodate the bandwidth required for more robust systems. 

APIs are also protocol-agnostic. They can use any form of communication. Web services are limited to SOAP, REST, and XML-RPC.