Web Services
In its simplest definition, Web services is an instantiation of a Service-Oriented Architecture (SOA) where all of the following apply.
- Service interfaces are described using Web Services Description Language WSDL).
- Payload is transmitted using Simple Object Access Control over HTTP (Hypertext Transfer Protocol).
- Universal Description Discovery and Integration (UDDI) is optionally used as the directory service.
Other combinations of technologies are possible, but this is the most common instantiation and the reason why the terms SOA and Web services are often used interchangeably.
The growing success of Web services is due to a number of factors, including those below.
- Systems can interact with one another dynamically via standard Internet technologies.
- Services are built once and reused many times.
- Services can be implemented in any programming language.
- Service consumers do not need to worry about firewalls because communication is carried over HTTP.
- Systems can advertise their capabilities for other systems to use. For example, Amazon Web Services allows systems to access catalog data, manage the shopping cart, and initiate the checkout process via Web services.
- Standards such as BPEL4WS (Business Process Execution Language for Web Services), WS-Security, WS-Routing, WS-Transaction, WS-Coordination, and WSCL (Web Services Conversation Language) are working toward the automatic discovery and composition of Web services.
The success of Web Services is based on the technologies that support it, as indicated in Figure 1. Items in bold indicate that these are the more standard and commonly used technologies. The vertical bars indicate that elements of Security, Quality of Service, Transactions, and Management have to be present in all layers of the protocol stack.
The base layers of the protocol stack are HTTP (HyperText Transfer Protocol) and XML (eXtensible Markup Language). HTTP is a ubiquitous protocol, running practically everywhere on the Internet and is used as the transport layer. XML is used to encode the exchanged messages. In essence, XML messages are converted to middleware requests and the results converted back to XML.
SOAP (Simple Object Access Protocol) defines a framework to construct XML-based messages that can be used to exchange information between nodes in a decentralized, networked environment. As shown in Figure 2, a SOAP message consists of header and body information. A SOAP message travels between SOAP nodes on a SOAP message path from an initial sender through one or more intermediate nodes to an ultimate receiver. Each node on the path may process the message in some way based on information in the header blocks. The message body is processed by the ultimate receiver. SOAP does not define how messages are transported between nodes and how they are routed, but in the case of Web Services, relies on HTTP for this.
WSDL (Web Services Description Language) is used to describe what a Web Service can do, where it resides, and how to invoke it. It is XML-based and supports simple and complex transactions defined by message exchange patterns.
UDDI (Universal Description, Discovery and Integration Service) is an XML-based distributed directory that enables businesses to list themselves, as well as dynamically discover each other. Businesses register and categorize the Web services they offer and locate Web services they want to use. UDDI itself is a Web Service. The directory contains three types of information, similar to a phone book:
- White pages: contains basic information such as name, address, business description and type of business
- Yellow pages: follows a categorization based on U.S. government and United Nations standard industry codes
- Green pages: contains technical information about the services that receive exposure through the business directory that will help a client connect to the service
WSFL (Web Services Flow Language) is an XML language for the description of Web Services compositions. WSFL considers two types of Web Services compositions:
- Flow models describe business processes. They basically describe how to choreograph the functionality provided by a collection of Web services to achieve a particular business need.
- Global models describe a set of overall partner interactions. They basically describe how a set of Web services interact with each other.
WSCL (Web Services Conversation Language) provides an XML schema for defining sequences of documents that Web Services can exchange. The difference between WSFL and WSCL is that WSFL describes the internal execution of a sequence of functions that constitute a Web service, while WSCL describes the order in which external users of a Web service will invoke its operations.
State of the Practice
With respect to the maturity of standards used in Web Services
- Both HTTP and XML are very mature and widely used standards
- UDDI was recently ratified as an OASIS standard.
- SOAP, WSDL, and especially WSFL and WSCL, are still emerging standards and therefore there is considerable room for different interpretations of the standards by parties implementing Web services.
- Security, Quality of Service, Transactions, and Management have to be addressed in all layer and the standards in these areas are in very early stages. For example, there are three specifications pertaining to security for Web services: Security Assertion Markup Language (SAML), WS-Security, and Web Services Security (based on WS-Security).
To solve some of these problems, the Web Services Interoperability (WS-I) group is attempting to provide guidance on the usage of Web services standards. Established in early 2002, WS-I is an open industry effort chartered to promote Web services interoperability across platforms, applications, and programming languages. This organization brings together a diverse community of Web services leaders to respond to customer needs by providing guidance, recommended practices, and supporting resources for developing interoperable Web services. WS-I also recently announced the availability of its tools for testing interoperability with the WS-I Basic Profile for use of Web services.
There are groups interested in testing SOAP interoperability because of the available choices in formats, envelopes, and transport protocols that are offered by the standard. SOAPBuilders, for example, is an open group of SOAP developers defining interoperability test suites that check custom data types for compatibility. There are also many vendors that are releasing WSDL interoperability tests against the WS-I Basic Profile.
Impact for Systems of Systems
Interoperability between systems requires the capability for users to exchange information (syntactic interoperability) and a common understanding of its meaning or how to act upon it (semantic interoperability). The reason why many vendors and users associate Web services with interoperability is because interoperability is simply defined as the capability to implement a service in multiple programming languages and to communicate using well-known and platform-independent protocols and standards. This definition of interoperability is purely syntactic and will not be enough to support the vision of building systems on-the-fly.
From a syntactic point of view, Web services are very promising and are experiencing tremendous growth because of their reliance on well-known standards and organizations like WS-I. The current challenge, as expressed before, is that these standards are emerging and therefore there is still considerable room for different interpretations of the standards by parties implementing Web services.
From a semantic point of view, there are many limitations because Web services can currently only be discovered based on keywords. This is true for example of UDDI. Therefore, the ability for run-time discovery, a requirement for automatic Web Service composition, is limited. The Semantic Web is a collaborative effort led by W3C with participation from many researchers and industrial partners who wish to tag information on the Web in such a way that it can be interpreted by software agents looking for specific types of information. The combination of Web services with the Semantic Web is called Semantic Web Services. A Semantic Web Service is a Web Service whose description is in a machine-understandable language with formal semantics. The idea is to be able to describe Web services in such a way that applications can automatically coordinate information exchanges and hence improve interoperability. The Semantic Web Services arm of the DAML (DARPA Agent Markup Language) program is developing a Web Service Ontology based on OWL (Web Ontology Language) called OWL-S (formerly DAML-S), as well as supporting tools and agent technology to enable automation of services on the Semantic Web. With ontologies such as OWL-S, or others described using OWL, there is a much greater chance of semantic interoperability, but these ontologies are still emerging and primarily being used in research environments.
Open Issues
Current programs and projects are relying on Web Services for automatic discovery and composition of services to form systems "on-the-fly". Web Service technologies, although promising, are not there yet. To give an example, having a centralized registry of services, whether public or private, is necessary for dynamic composition of systems. A problem that applies to public registries, for example, is deciding who is responsible for the quality of the information.
Another problem that applies to both public and private registries is the need for a common taxonomy or ontology to describe services so that they can be discovered. Dynamic composition of systems will be challenging until these two problems are addressed. And this is only the beginning.
Being able to build systems on the fly requires the following:
- The ability to discover services on-the-fly
- The ability to to link to services on-the-fly
- The ability to execute services on the fly
- The ability to do all the above within performance, reliability, and security constraints (quality of service)
With current technologies, developers are able to perform these tasks at design time, but not at run time. Therefore, building systems on the fly is not possible with current Web Service technologies. It is not the fault of Web Services though because that is really not what Web Services were initially built for. Nonetheless, if this is the direction in which Web Services want to go to, there needs to be more research and development in the layers above Description, as well as the vertical layers indicated in Figure 1.
This situation is best described by two apparently contradictory articles. One is called Web Services Are Not Distributed Objects by Werner Vogels from Cornell University, and the other is Like It Or Not, Web Services Are Distributed Objects by Kenneth Birman from Cornell University as well. [Vogels 03, Birman 04].
At first, the articles seem totally contradictory, but they actually both come to the same conclusion. The essence of the problem is that people fail to understand that Web Services is no more than a document exchange using standard Internet protocols, as opposed to a distributed object model where an object is referenced and instantiated, and then methods are called upon this object, which is then released. In Vogel's words: "interoperable document-centric computing as opposed to distributed objects." They both blame vendors for this misconception. Birman's argument is that the problem is that vendors have been selling Web Services technology as if they were distributed objects, that is, that they offer the same stability, reliability, and trustworthiness that distributed objects offer. And the truth as has been address above is that Web Services technology cannot currently offer all this.
References
[Birman 04] Birman, K. "Like It or Not, Web Services Are Distributed Objects." Communications of the ACM. Vol. 47, No. 12, December 2004, 60-62.
[Vogels 03] Vogels, W. "Web Services Are Not Distributed Objects." IEEE Internet Computing. 7, 6 (Nov.& Dec. 2003), 59–66.