- The Basics of Web Services
- A Simple Example: Searching for Information
- The Next Generation of the Web
- Interacting with Web Services
- The Technology of Web Services
- XML for Business Collaboration: ebXML
- Web Services versus Other Technologies
- Additional Technologies
- Vendor Approaches to Web Services
Core Web services technologies, such as SOAP, WSDL, and UDDI, are useful for bridging disparate technology domains and submitting documents to business process flows. However, to become useful for more types of applications and to fulfill the complete vision of Web services as enabling the use of application building blocks over the Internet, Web services technologies have to be extended to encompass additional features, functions, and qualities of service.
The ongoing work of evolving Web services toward a more useful technology substrate is very similar to the evolution of the common object request broker architecture, undertaken by the Object Management Group (OMG) during the 1990s. The OMG work defined a comprehensive software architecture that guided an open, collaborative effort that produced a rich set of specifications for transactions, asynchronous messaging, security, failover, fault tolerance, and so on. The same type of effort is being initiated at W3C for Web services, and a similar architecture is evolving.
In the world of Web services, the major industry software vendors have already agreed on the core standards, which is the true test of standardization. Microsoft, IBM, Sun Microsystems, BEA Systems, Oracle, IONA, and others have agreed on implementing SOAP, WSDL, and UDDI, although some difference of opinion remains on the role of the ebXML registry. However, other than for the fundamental standards, proposals often compete, such as the difference of opinion between Microsoft and IBM on business process flow definition, that is, XLANG versus WSFL (Web Services Flow Language), and competing proposals for handling security context.
Additional technologies are focused primarily in the following key areas:
- Process flow
Some of the most important additional technologies for Web services involve security technologies.
Security is important to ensure the confidentiality and integrity of Web services data. No one other than the intended recipient of the data should be allowed to examine or to tamper with message contents. Security also is necessary to control access to Web services, especially when multiple Web services are used together, so that only those for whom they are intended use them.
Proposed standards exist for authentication and authorization (SAML, or Security Authorization Markup Language) and for public key management for encryption (XKMS, or XML Key Management Specification). Of course, fundamental to all Internet security is Secure Socket Layer (SSL) and, for HTTP-based protocols, HTTPS (secure HTTP) for basic encryption-level security.
In addition to HTTPS, firewalls, SAML, XKMS, the use of digital signatures, and XML encryption, Microsoft has proposed WS-License for credential management and WS-Security for propagating security credentials associated with Web service interactions.
Process flow is critical to automating business process interactions over the Web and inside an enterprise. Process flow is also often called orchestration because it defines the relationship among a series of interactions necessary to accomplish a given purpose, such as completing a purchase order, processing a travel reservation, or executing a manufacturing plan. A flow is modeled as a sequence of steps defined for a given business process. The series of steps creates an aggregation of functions for which a Web service interface can be defined.
In the world of automated business operations, transactions have long played the part of enforcer, ensuring that the execution platforms produced consistent results from a series of related operations on data, despite software or hardware failures. These traditional protocols and techniques are not directly applicable to the Web, however, as they are designed for a tightly coupled environment in which it's possible to hold database locks pending notification of the transaction result and in which a connection-oriented protocol is available to detect communication failures automatically. The Business Transaction Protocol (BTP) proposal from OASIS is designed to resolve this problem for Web services by defining a loosely coupled protocol that ensures that the results of multiple Web service interactions are correctly propagated and shared.
Messaging protocols execute the communication patterns defined for Web service interactions, such as asynchronous one-way, request/response, broadcast, and conversational, or peer-to-peer. Additional Web services technologies also may depend on the messaging layer for certain qualities of service, such as reliable or guaranteed delivery, propagation of security and transaction contexts, and correctly routing messages along a defined path that includes one or more intermediaries. IBM has proposed reliable HTTP (HTTPR) to address requirements in this area.
IBM and Microsoft have collaborated on the WS-Inspection proposal for discovering information about Web services available at a particular message target. Microsoft has also proposed WS-Referral and WS-Routing to define a specific message path for a Web service, including any number of intermediaries, and how to route messages forward and backward along the specified route.
The Blocks Extensible Exchange Protocol (BEEP) from IETF defines a connection-oriented Internet protocol. A SOAP mapping for BEEP has been defined, and in this case, SOAP messages inherit the additional qualities of service from BEEP for maintaining session context at the sender and the receiver nodes. The context can be used to relate multiple messages into a larger unit of transfer and to relate multiple messages as coming from the same source or intended for the same target. Security and transaction context can also be associated with a connection.
Other relevant standards and technologies include many of those defined by the following organizations:
OASIS, hosting ongoing ebXML and other related XML proposals, such as BTP and SAML
RosettaNet, influencer of Web services concepts, developed by a group of electronics vendors for B2B business process flow interaction over the Internet
UserLand, developer of XML RPC, a precursor of SOAP
OAGI (Open Applications Group, Inc.), defining canonical XML document formats for business and industry
The work of these and other groups often focuses on promoting the adoption of XML for specific business purposes, such as building on the base standards to define document formats and protocols for the electronics, financial, health care, and other industries. Because Web services are based on XML, the work of almost any standards body or consortium promoting the use of XML-related technologies for Internet business is relevant. Some of the other work, such as BTP and SAML, emerges as
The Long Road Ahead
Additional technologies, such as security, transactions, and reliable messaging, currently found in existing distributed computing environments, have to be defined again for Web services because of the fundamental shift involved in the infrastructureXML and HTTPon which they now need to be built. The World Wide Web Consortium will undertake the effort to define Web services architecture, just as OMG defined architecture for CORBA, although this is likely to be a very difficult and daunting task. The W3C is not set up to resolve major differences of opinion among its members, especially when those differences are motivated by commercial interests. This is the downfall of many standards efforts, in fact. candidate technology for adoption by W3C within its Web services architecture activity.