Web Services

The Internet, as most people use it, consists out of texts. These might be enriched by multimedia content, but web pages are generally nothing else but texts written in HTML so that they can be rendered by Web Browsers like the Internet Explorer. HTML texts differ from written texts in their hypertext functionality. By clicking on a link I can browse through web pages and content from different web sites all around the world. Texts are written for humans and do not support very well software interaction. Web services try to correct this by providing the information in a format that can be understood by software applications. They are about machine-to-machine interaction. With Web Services, texts get a structure and thus become data. In their current form, VREs generally align along existing organizational and sub-organizational, lines. A VRE can serve a university, a faculty, a department, or (most commonly), an individual research enterprise, which may have a strong interdisciplinary or interinstitutional focus. Such organizational distinctions, however, are likely to fade as the technologies involved gain wider acceptance. VREs are scalable applications: the major distinction between a VRE and other grid-based applications lies in the former's academic, technological and organizational specificity. A VREs users, clients, tools and applications will be selected (or scripted) and embedded in the architecture to meet a specific research objective, or to address specific research questions, at the system design stage. A VRE can however, and indeed must (see below), interoperate with local and (inter)national infrastructures. For example, the Access Grid (AG) and National Grid Service (NGS) are not VREs in this sense, because they are distributed services with no common subject or community focus at a meaningful level, yet a VRE that does have such a focus may well exploit the AG, or subscribe to the NGS, for server space or processing power. This is a broad distinction, although a more nuanced and granular differentiation will surely become discernible as the technology, and its adoption, develops.

Web Services are based on XML technologies. The eXtensible Markup Language (XML) is a standard that allows to encode self-describing data. With XML, documents can include descriptions of what is written in them. Web Services are all about exchanging XML messages between applications. A request to a remote service encoded in XML triggers a response also in XML. The XML that is exchanged can either be simple documents or requests to trigger a remote procedure and do calculations. The XML standard abstracts on all implementation details of the applications that interact with each other. A program written in the programming language JAVA can request the execution of a remote PERL module without the need to rewrite or recompile the remote code. This intense interoperability makes Web Services such a current hype and very attractive to the industry, which is in high need for an easy possibility to communicate across system boundaries. Contrary to older distributed programming infrastructures, the back-end implementation does not matter anymore as long as the messages are exchanged in the right XML descriptions. Web services are what is called virtual in information technology.

The immanent virtuality of Web Services also prompts their use in the E-Science infrastructure of Grid technologies. Here, the challenge is exactly to overcome system boundaries without the need to rewrite the systems. Web Services enhance the Globus Toolkit de facto standard for Grids to become the Open Grid Service Architecture, in which the Grid in total is regarded as a collection of services. Such architectures are called service-oriented architectures (SOA) and are recent innovations in order to use distributed, discovery-based software potentials. Each SOA is a collection of capabilities that can be used by other partners in the same network. SOAs do not need to be based on Web services, but often they are.

Each SOA needs a service registry, service requesters and service providers (Taylor 2005). Service providers register their service at the central registry. A requestor locates the service provider from the registry, contacts the service provider and negotiates the service details. Just as on a market place providers and consumers meet via mediators. In the yellow pages the requestor will find the next ATM, a service provider. She will go to the ATM. To find the ATM in the yellow pages, she will have to know the bank name, where she can take out money, and the bank address. All these information can be found by using the yellow pages alphabetic index as an interface to the registry information in them. By using her bank card and her pin the service requestor will comply with the interface of the ATM, the service provider, to receive the service. Where the cash has come from or how the machine sends it out, is of no interest.

The Web Service technology stack

Machine-readable data structure needs standards just like texts need to be in the right language in order to be understood by a particular reader. The core Web Service technologies to achieve these standards are: SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language) and UDDI (Universal description, discovery and integration). These complicated names disguise the partial simplicity behind Web Service. If one imagines the Web Service world as a market place, in which goods and services are exchanged, then those core Web Service technologies offer the chance for a user application to find their way in that market and get delivered what it asks for. UDDI are the yellow pages, which allow to find the address of service. SOAP wraps the needs encoded in WSDL into an envelope. SOAP will also guide the service back to the calling user application after it has been executed on a remote service provider.
Figure 1 gives the example of the web services steps and technologies involved to receive the temperature on the moon. With UDDI, a provider publishes that it can provide the moon temperature. A requestor will receive that data with SOAP and WSDL. UDDI can be best compared to the Yellow Pages. SOAP and WSDL are explained in more detail below.

Figure 1: Web service example

SOAP

The Simple Object Access Protocol (SOAP) delivers a technology allowing the exchange of structured information. It is lightweight, meaning that it is requires a limited amount of overhead. Often a SOAP message is compared to a letter. As you write a letter, put it in an envelope and mail it to a receiver, in SOAP, you will write an XML document and enclose it in a SOAP envelope, which is sent to a SOAP server to be picked up. In the language of SOAP the sender of the message is called client. Just like the envelope of a letter the SOAP message will contain to address of the SOAP server it is sent to and might contain the address of the sender if an answer is expected.
In Figure 1 the SOAP client is a piece of code that would like to know the weather on the moon. It would have to address a SOAP envelope to a SOAP server on the moon, which can deliver a temperature service. To complicate things further, let us assume that the SOAP client is written in the programming language PERL, while the server only understands JAVA. For almost all programming languages interfaces exist, that translate its local representation into SOAP. First an XML message is created to be afterwards put into a SOAP envelope and sent to the SOAP server. On the moon, the SOAP server opens the envelopes, translates the XML into JAVA and sends back the temperature in another XML/SOAP document. The message from the SOAP client could look like:

Figure 2: SOAP example
This format might not seem to be very obvious, but all it tells the message is to request on the moon a method to receive the temperature in Celsius. What makes every XML document look very unobvious are the so-called name spaces (here xmlns) that differentiate e.g. the temperature method on the moon from the one on the mars. Back on earth the PERL program will understand this SOAP format and output the temperature on the moon.

WSDL

The Web Service Description Language (WSDL) gives an abstract interface to Web Services and specifies by which transport means this service can be invoked. In the words of computing: WSDL defines services and binds them to a certain transport protocol such as the Internets HyperText Transfer Protocol (HTTP) or SOAP. As computing people like to confuse the rest of the world, those abstract interfaces are called port types in WSDL. They consist of a selection of offered procedures. Other XML standards help with overcoming different names for the same types. One programming language would define 37 as an int, while another one would call it an Integer[32]. A language called XML schema (XSD) gives both a way to communicate by simply defining the value as an integer for the exchange. WSDL puts this data into so-called message elements. WSDL in general is a language solely for the purpose of communication.

Bibliography

Taylor, I. J. (2005). From P2P to Web Services and Grids. Peers in a Client/Server World. London, Springer.

This briefing paper was written for AHeSSC, the Arts and Humanities e-Science Support Centre. It is published here with permission from AHeSSC.