Web Services is a relatively new technology for developing loosely-coupled distributed applications. It is based on the Service-Oriented Architecture (SOA) and enables the composition of components that can bind to each other at run-time and can run on various platforms. Software applications written in different programming languages can use Web Services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer.
Web Services are described by Web Service Definition Language (WSDL) in XML format. The Web Service description hides the implementation details but at the same time gives enough information that is necessary for the service interaction (such as endpoint, location, methods, their input and output parameters, and data types). The XML messaging is realized via Simple Object Access Protocol (SOAP). The standard allows exchanging data among applications in a decentralized, distributed, and heterogeneous environment using HTTP. Each SOAP message is presented as an envelope with two sections - a header and a body. The header contains information about the message itself, and the body consists of data that has to be transferred to the recipient. These standards make the Web Services independent of any programming language, hardware and software platform.
A client invokes a Web Service by sending a SOAP message in XML format and receives as a result the corresponding XML response. Since all communication is in XML format, Web Services are not tied to any operating system or programming language - Java can talk to Perl; Windows applications can interact with Unix applications.
Web Services can encapsulate a specific task or can be designed as a composition of other services representing a complex aggregation. The Web Services conceptual model describes the process of publishing, finding, and binding as well as introduces three participants - service provider, service registry, and service requestor. The provider advertises the Web Service and sends its WSDL description to the UDDI directory. The registry offers APIs for publishing and searching of Web Services as well as contains information about all advertised ones. A potential consumer, that could be even another Web Service, queries the registry in order to find a provider that meets its needs and preferences. The directory returns as a result a list of services to the client who selects a server and starts the interaction. The whole process is shown on the following figure:
By nature, the domain of Web Services contains redundant services with particular functionality. The following questions arise:
- Who should be responsible for the selection of Web Services - the client or the server?
- How can the consistency of the redundant Web Services be managed?
- How can the selection process be done at run-time?
- What criteria, models, and policy techniques should be used during the service selection?