Web services is an imprecise term used to describe services typically built from technologies such as SOAP and WSDL and grounded in fundamental Web standards such as XML and HTTP. In the latest version of the Web Services Architecture document, the W3C Web Services Architecture Working Group includes the following definition:
"A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."
The software technology for Web services is still rapidly developing. The fundamental and quite ambitious goal for Web services is to provide A2A (application-to-application) integration using message exchanges in a world of heterogeneous computing platforms, network transport protocols, and application programming languages. Some of the basic building blocks are settling into place. SOAP is an XML format for encoding message content. WSDL (Web Services Description Language) is an XML format for describing the invocation interface at the level of individual Web service operations (transport bindings, application-specific messaging requirements and formats, etc.). UDDI (Universal Description, Discovery and Integration) is a less universally accepted framework for encoding directory information about what services are available. Many other technologies that are essential to the full potential of Web services are still in flux. These include:
XML and Web services technologies are highly extensible and in some cases fairly complex (e.g., XML Schema). This can lead to substantial interoperability problems if vendors subset complex specifications or choose incompatible extensions. Interoperability is a prime concern for vendors and users alike. WS-I (the Web Services Interoperability Organization) creates standard usage profiles to guide implementers and developers guidance on interoperability issues. Many interoperability issues will be ameliorated over time by clearer standards and more complete vendor implementations.
For a comprehensive list of organizations, working groups and vendor specifications specifically related to Web services, see web-services-activities.htm. The sections below highlight some of the more important Web services standards efforts and issues.
SOAP is the Web services message format standard. SOAP messages are encoded in XML. SOAP headers can be targeted at different intermediaries in order to support functional layering. SOAP provides semantics for indicating whether those headers must be understood, how to report faults, etc. SOAP technology must be capable of supporting interoperable business quality messaging, the development of features for security, reliability, manageability, business policy, and the transmission of XML and non-XML data.
Status: Most Web services software still utilizes SOAP 1.1, a de facto standard published as a W3C Note. The XML Protocol Working Group at the World Wide Web Consortium (W3C) standardized SOAP 1.2 in June 2003. The specification is published in three parts: a non-normative primer (SOAP Version 1.2 Part 0: Primer); a normative, required specification of the core aspects of SOAP 1.2 (SOAP Version 1.2 Part 1: Messaging Framework); and a normative, optional specification of other SOAP components such as the HTTP binding, SOAP encoding, RPC conventions, etc (SOAP Version 1.2 Part 2: Adjuncts). In addition, the working group provided a collection of specification assertions and tests to further clarify the specification (SOAP Version 1.2 Specification Assertions and Test Collection). The working group has recently been working on a specification to facilitate optimizations in the transmission of SOAP messages such as carrying non-XML (e.g., binary) data with SOAP messages.
WSDL (Web Services Description language) is the most common means for formally describing Web service operations and bindings. WSDL descriptions are encoded in XML. In principle, a WSDL description (in XML) allows a client to determine how to invoke a service – both binding-specific information regarding what underlying protocol to use, what machine and port to access, etc. and also payload-specific information regarding the headers, body and attachments. Although WSDL is technically not required to deploy Web services, it is increasingly a fundamental part of the Web services picture, both for describing a service to clients and for its crucial role in many Web service IDEs (Interactive Development Environments).
Status: Current Web services software utilizes WSDL 1.1, a de facto standard published as a W3C Note. The WSDL Working Group at the W3C is standardizing WSDL 1.2. It is anticipated that WSDL 1.2 will reach final recommendation status sometime in 2004.
In some Web service deployments, informal mechanisms (sales force, web page descriptions, etc.) are sufficient for advertising the existence and description of a new service. In other loosely-coupled situations, however, a formal discovery mechanism can help clients find appropriate services. Discovery technology can employ centralized registries in which services are actively enrolled or decentralized strategies in which services are discovered much like a Web search engine such as Google crawls the Web to discover and index Web pages. The former approach is exemplified by the Universal Description, Discovery and Integration (UDDI) specification; the latter is supported by the Web Services Inspection (WS-Inspection) technology.
The purpose of the UDDI Specification TC is to evolve work on the Web services registry foundations. The UDDI specifications form the necessary technical foundation for publication and discovery of Web services implementations both within and between enterprises. The UDDI specification is being standardized by OASIS. WS-Inspection has been proposed by Microsoft and IBM, but is not yet undergoing standardization.
Status: OASIS is just completing the standardization of UDDI v2. WS-Inspection components are available in Microsoft and IBM platforms and in the Apache Axis project; Java APIs (WSIL4J) is available for the Web Services Inspection Language (WSIL).
WSDL only provides a description of a Web service at the level of individual operations. Virtual every real Web service involves multiple operations which must occur in certain orders and which incur various obligations (state maintenance, external effects, etc.). Sometimes these operations are considered to be a part of an ongoing conversation between the participants. Multiple conversations can be taking place at once; each message exchange must be matched with the correct conversation. Choreography refers to the level of description that is required to capture the relationships and constraints that hold among multiple operations. It is usually conceived as layering over WSDL to provide a complete, functional service description. This is an important area for standardization, but it is still too early to see how things will shake out. In the interim, vendors will offer their own choreographic features in their proprietary IDEs.
Status: Unfortunately, fragmentation is occurring in the choreography standards efforts. The W3C Web Services Choreography Working Group is pursuing a standard that includes ideas drawn from the Web Service Choreography Interface (WSCI) specification. IBM, Microsoft and BEA submitted their Business Process Execution Language for Web Services (BPEL4WS) specification to OASIS for standardization.
There are a large number of Web services capabilities of importance for business quality A2A integration that are still awaiting standardization: asynchrony, reliable messaging, security (authentication, authorization, confidentiality, non-repudiation), policy, routing, transactions, management, etc. In the W3C, the Web Services Architecture Working Group has struggled to understand how the overall Web services architecture should be structured to accommodate these capabilities and to recommend the formation of new standards activities in areas that are ready to be launched.
It will take considerable time for standards to evolve in all of these critical areas. There may be periods of industry fragmentation in certain areas. In the meantime, widely-adopted, open vendor-specific proposals may gain mindshare in some areas. User companies may also adopt their own internal “standards” which seem to align with the best external ideas until standards solidify. The Web Services Architecture Working Group provides some potential leverage for prioritizing and focusing energy on capabilities such as security, reliability, asynchronous messaging, etc.
Status: The W3C Web Services Architecture Working Group is working on several documents, including a Web services reference architecture, a glossary, a collection of usage scenarios. All of these documents are currently working drafts, but the glossary and usage scenarios are already being referenced by other organizations. The status of the individual capabilities mentioned above varies widely. The basic security building blocks for XML digital signatures, encryption and decryption are W3C standards. The WS-Security specification, which specifies how these are to be used in the context of Web services, is being standardized at OASIS. Another OASIS technical committee is working on a WS-Reliability specification, but there are rival conceptions (WS-ReliableMessaging) that are being floated by major industry players.
Interoperability is a widely pronounced goal of Web services technology. It is also historically seen to be a difficult and elusive objective in any complex, distributed enterprise. In Web services, interoperability is dependent upon clear standards and faithful vendor implementations of those standards. In some cases, the complexity of the underlying technologies such as XML Schema (particularly used by WSDL) may lead to subsets in specifications (e.g., JAX-RPC) or incomplete implementations.
WS-I does not create new technology itself, but develops best practice profiles for SOAP/WSDL and for specific features such as security. It should be recognized that while interoperability is an explicit industry goal, portability is not. Development environments and APIs differ significantly from vendor to vendor.
Status: The initial SOAP/WSDL 1.1 specifications were only de facto standards and had a number of features that are incomplete, vague, underspecified or superceded. WS-I has created a Basic Profile that describes a useful subset of SOAP/WSDL 1.1 Web services. The SOAP/WSDL 1.2 specifications should improve the clarity of the standards. Nonetheless, it will take a while for reasonably bug-free and complete vendor implementations to appear. Interoperability for the architectural features listed above (reliable messaging, security, etc.) will lag until those standards solidify. Given the importance of security and the consensus on the WS-Security work at OASIS, WS-I has undertaken a profiling effort for it.
Feedback to
feedback@coolwisdom.com.
Copyright 2003 by Mark Jones.
Last updated
July 01, 2004.