Web services model consists of a set of basic functionalities such as describe, publish, discover, bind, invoke, update, and unpublish. In the meantime, the model also consists of three actors—service provider, service broker, and service requester. Both the functionalities as well as actors are shown in the next figure:
Service provider is the individual (organisation) that provides the service. The service provider's job is to create, publish, maintain, and unpublish their services. From a business point of view, a service provider is the owner of the service. From an architectural view, a service provider is the platform that holds the implementation of the service. Google API, Yahoo! financial services, Amazon services, and weather services are some examples of service providers.
Service broker provides a repository of service descriptions (WSDL). These descriptions are published by the service provider. Service requesters will search the repository to identify the required service and obtain the binding information for these services. Service broker can be either public, where the services are universally accessible, or private, where only a specified set of service requesters are able to access the service.
Service requester is the party that is looking for a service to fulfil its requirements. A requester could be a human accessing the service or an application program (a program could also be a service). From a business view, this is the business that wants to fulfil a particular service. From an architectural view, this is the application that is looking for and invoking a service.
So far we have discussed SOA, standard bodies of web services, and the web service model. In this section, we are going to discuss more about standards, which make web services more usable and flexible. In the past few years, there has been a significant growth in the usage of web services as application integration mechanism. As mentioned earlier, a web service is different from other SOA exposing mechanisms because it consists of various standards to address issues encountered in the other two mechanisms. The growing collection of WS-* (for example, Web Service security, Web Service reliable messaging, Web Service addressing, and others) standards, supervised by the web services governing bodies, define the web service protocol stack shown in the following figure. Here we will be looking at the standards that have been specified in the most basic layers: messaging and description, and discovery.
The messaging standards are intended to give the framework for exchanging information in a distributed environment. These standards have to be reliable so that the message will be sent only once and only the intended receiver will receive it. This is one of the primary areas where research is being conducted, as everything depends on the messaging ability.
Next, we are going to discuss some of these standards in details. Firstly, we will start with XML-RPC, which later evolved into SOAP.
The XML-RPC standard was created by Dave Winer in 1998 with Microsoft. The existing RPC systems were very bulky. Therefore, to create a light-weight system, the developer simplified it by specifying only the essentials and defined only a handful of data types and commands. This protocol uses XML to encode its calls to HTTP as a transport mechanism. The message is sent as a POST request in which the body of the request is in XML. A procedure is executed on the server and the value it returns is also formatted into XML. The parameters can be scalars, numbers, strings, dates, as well as complex record and list structures.
As new functionalities were introduced, XML-RPC evolved into what is now known as SOAP, which is discussed next. Still, some people prefer using XML-RPC because of its simplicity, minimalism, and the ease of use.
Initially, SOAP was defined as Simple Object Access Protocol. However, the latest version (SOAP 1.2) has moved beyond its original definition. The SOAP standard was originally designed by four developers with the backing of Microsoft as an object-access protocol. The protocol specifies exchange of XML-based messages over computer networks in transport independent manner. The developers had chosen XML as the standard message format because of its widespread use by major organizations and open source initiatives. Also, there is a wide variety of freely available tools that ease the transition to a SOAP-based implementation.
The concept of SOAP is a stateless, one-way message exchange. However, applications can create more complex interaction patterns—such as request-response, request-multiple responses, and so on—by combining such one-way exchanges with features provided by an underlying protocol and application-specific information. SOAP is silent on the semantics of any application-specific data it conveys as it is on issues such as routing of SOAP messages, reliable data transfer, firewall traversal, and so on. However, SOAP provides the framework by which application-specific information may be conveyed in an extensible manner.
It would have been quite useful if there was a standard way to express where a message should be delivered in a web services network. This could reduce the work load of the developers when they are able to simplify web services communication and development, and avoid the need to develop costly solutions ad hoc that are often difficult to interoperate across platforms. When interacting with human applications, we enter the address (or URL) in the browser and then navigate the page. We click on the internal links and it takes us to a new page. When it comes to application-application communication, such as web services, there should be a standard way of specifying those addresses. Thus, WS-Addressing enables organizations to build reliable and interoperable web service applications by defining a standard mechanism for identifying and exchanging Web Services messages between multiple end points.
The standard provides transport independent mechanisms to address messages and identifies web services, corresponding to the concepts of address and message correlation described in the web services architecture. The standard defines XML elements to identify web services endpoints and to secure end-to-end endpoint identification in messages. This enables messaging systems to support message transmission through networks that include processing nodes such as endpoint managers, firewalls, and gateways in a transport-neutral manner.
When we buy a product we can find the operational manual for it or when we buy a software application, we should have the manuals or documentation to use it. When it comes to OOP, we have interfaces that describe the public operation and in the same way Java docs provide information about the available methods and how to use them. Hence, it is important to note that the description of a web service is essential for classifying, discovering, and using a service. The description should be understandable to both humans as well as for applications. They further mention that the web service description is required to be at both semantic and syntactic level. Semantic information has to contain details about the service provider, what the service does, and characteristics such as reliability, security, and sequencing of messages. The semantic information enables service requesters to decide whether a service satisfies their needs or not. Also, brokers can use the semantic information to categorize the service. Syntactic information describes how to use the service and may also concern non-functional requirements, such as reliability, security, and transactions. Above all, service description becomes the external documentation to read and understand more about the service.
WSDL, developed by IBM, Ariba, and Microsoft, is an XML-based language that provides a model for describing web services. The standard defines services as network endpoints or ports. WSDL is normally used in combination with SOAP and XML schema to provide web services over networks. A service requester who connects to a web service can read the WSDL to determine what functions are available in the web service. Special data types are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to call functions listed in the WSDL.
The standard enables one to separate the description of the abstract functionality offered by a service from the concrete details of a service description such as how and where that functionality is offered. This specification defines a language for describing the abstract functionality of a service as well as a framework for describing the concrete details of a service description. The abstract definition of ports and messages is separated from their concrete use, allowing the reuse of these definitions. A port is defined by associating a network address with a reusable binding and a collection of ports define a service. Messages are abstract descriptions of the data being exchanged and port types are abstract collections of supported operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding where the messages and operations are then bound to a concrete network protocol and message format.
There are two main WSDL standards—WSDL 1.1 and WSDL 2.0. However, most of the Web Service frameworks available today still use WSDL 1.1, and a framework such as Apache Axis2 has support for both WSDL 1.1 and WSDL 2.0.