Web Services: Services from Machine to Machine

Making use of services via the web is a daily routine for many people. Online shopping, reading a newspaper, reserving a table in a res­taur­ant, watching films—these are all services that we use more or less every day. Many things happen directly between man and machine here, because the person in front of the screen is nav­ig­at­ing through the Internet and makes decisions. However, the same amount happens between machine and machine. Requests and responses are con­tinu­ally sent back and forth between client and server. Web services make that possible.

A web service provides a service over the Internet. It is therefore an interface through which two machines (or ap­plic­a­tions) can com­mu­nic­ate with each other. Here, two prop­er­ties are crucial—the service must be:

• platform-in­de­pend­ent: Client and server do not need to have the same con­fig­ur­a­tions to com­mu­nic­ate with each other. The web service ensures a common platform.
• dis­trib­uted: A web service is not only available to just one client in most cases. Different clients access the service over the Internet.

When a web service is used, a client sends a request to a server, trig­ger­ing an action on that server. The server then sends a response back to the client.

A web service is contacted via a unique Uniform Resource Iden­ti­fi­er (URI). Similar to a Uniform Resource Locator (URL), which can be used to address websites, the URI is an address for the cor­res­pond­ing web service. The­or­et­ic­ally, the directory service UDDI also plays a role, through which web services can be found. However, this service never prevailed and the biggest backers have withdrawn from the project.

The language Web Service De­scrip­tion Language (WSDL), however, is more important. A web service has a file in WSDL, in which the service is described in further detail. The client can un­der­stand from the in­form­a­tion which functions it can perform on the server through the web service. Finally, the com­mu­nic­a­tion works through various protocols and ar­chi­tec­tures. The network protocol SOAP in com­bin­a­tion with the Internet standard HTTP or also RESTful web services, for example, are very popular. Requests and answers are sent back and forth with these tech­niques.

The com­mu­nic­a­tion often works with Ex­tens­ible Markup Language (XML). The re­l­at­ively simple language can be un­der­stood by humans and computers alike and is ideally suited to connect systems with different pre­con­di­tions. But REST also allows other formats such as JSON.

Here is a web service example for cla­ri­fic­a­tion: Let's start with software written in Visual Basic, running on a Windows computer. The program requires the service of an Apache web server. To enable this, the client sends a SOAP request in the form of an HTTP message to the server. The web service in­ter­prets the content of the request and ensures that the service performs an action. After execution, the web service for­mu­lates a response and sends it back to the client, again using SOAP and HTTP. There, the answer is in­ter­preted again, and the in­form­a­tion reaches the software, where it is further processed.

The main advantage of web services is that com­mu­nic­a­tion is platform-in­de­pend­ent. Client and server do not require common features in order for com­mu­nic­a­tion to work. To do this, web services rely on stand­ard­ised formats, which un­der­stand all systems.

One of the dis­ad­vant­ages, however, lies in these formats. XML is a rather bulky format which leads to large data packets. This can cause problems with slow network con­nec­tions. Another way two systems can connect over the Internet is through Web APIs—in­ter­faces that can also be accessed over the Internet. Although these are generally faster, they have many clearer spe­cific­a­tions for the client and server, which limits in­ter­op­er­ab­il­ity.