[Cache from http://www.w3.org/2001/03/WSWS-popa/paper51; please use this canonical URL/source if possible.]
© 2001 International Business Machines Corporation, Microsoft Corporation. All rights reserved.
The beginning of the charter for the W3C XML Protocol Activity states
“Today, the principal use of the World Wide Web is for interactive access to documents and applications. In almost all cases, such access is by human users, typically working through Web browsers, audio players, or other interactive front-end systems. The Web can grow significantly in power and scope if it is extended to support communication between applications, from one program to another.”
The XML Protocol work is the foundation for a Web Service framework within which automated, decentralized services can be defined, deployed, manipulated and evolved in an automated fashion. The purpose of this document is to outline a framework for evolving XML Protocol’s functions. This framework provides a structure for integration and a foundation for protocols that will support the needs of such service-oriented applications. The goal is a scalable, layered architecture, one that can appropriately meet the needs of both simple and extremely robust high-volume deployments. As with other Web technologies, the focus is on enabling ubiquitous interconnectivity of entities and organizations dispersed throughout the world.
While most descriptions of Web based solutions emphasize their distributed characteristics, their decentralized nature – they have distinct management and control environments and communicate across trust domains – has much more impact on architecture of this framework and the requirements of the underlying protocols. So, we focus our framework first on supporting application-to-application integration between enterprises having disjoint management, infrastructure and trust domains.
The focus of this document and the framework it defines is a model for describing, discovering and exchanging information that is independent of application implementations and the platforms on which applications are developed and deployed.
We note that other organizations such as the IETF and ebXML are tackling a related set of problems, and we are pleased there are already formal liaisons between the W3C XML Protocol Working group and its counterparts in both ebXML and IETF. We hope and expect that the realization of this framework will embody the best ideas from all of these sources, and yield a common framework and supporting components. This integration and convergence is essential for realizing the benefits of cross-enterprise, global application integration.
A common framework identifies specific functions that need to be addressed in order to achieve decentralized interoperability. It does not determine the particular technologies used to fulfill the functions but rather divides the problem space into sub-problems with specified relationships. This functional decomposition allows differing solutions to sub-problems without overlaps, conflicts or omitted functionality. This is not to say that all applications must offer the same facilities, rather that when a feature is offered it should fit into a common framework and preferably have a standard expression.
Conversely, without a common framework and coordinated development of each component, one almost certainly produces overlaps, which are likely to make implementations more complex and decrease the probability of achieving interoperability. Lacking a common framework also forces developers to guess how various components work in concert. This guessing leads to poor interoperability and fragility. The framework also allows the development and adoption of the individual components to happen in parallel and asynchronously, which has the added benefit of enabling critical pieces to be completed sooner than others, thereby allowing implementations to proceed. As new components or modules are completed, they can be applied later, as desired. It is crucial that these mechanisms remain orthogonal so they can evolve without having to change the whole system. Finally, a framework supports selections of subsets of components to provide specific levels of service that scenarios require.
Second, our primary goal is to connect applications on a worldwide basis. Such applications will necessarily be built in a variety of programming languages, using a range of operating systems, database, and middleware technologies. The interoperability we seek can only be achieved when based on standard data formats and protocols, not APIs. By focusing "on the wire", we define just the specifications needed for interconnection. We believe this approach provides the greatest benefit in the shortest time, and does not impinge of software vendors’ flexibility and enterprise autonomy.
Alice wants to rent some linen for her restaurant. So, she goes to an online catalog of a restaurant supplier. Its catalog lists the products sold and rented.
Though the website looks like a single application, it is actually composed of several distinct and interacting web services. One application handles display of the catalog and form based selection of products. When Alice selects an item, the catalog app communicates with a generic web service that manages the catalog, shopper groups and handles the shopping basket. In this scenario, the catalog display and browsing web front-end uses an on-line commerce solution for its catalog and shopping functions.
Two different service providers may be supporting the restaurant supplier’s web site. One hosts and develops the person facing front-end. The second hosts the on-line commerce application, supporting many different front-ends and enterprises. This service is not specific to restaurant suppliers, but can manage online commerce, catalogs and shopping carts for many different types of customers.
The commerce application accumulates a list of items with their prices, shipping costs and other details, collects credit card information, shipping addresses and supports checkout. This service charges a small fee to its catalog based retail customers per transaction
Actually, this shopping cart service itself depends on yet another web service, the credit card handling web service, which takes in credit card information and purchase amounts and either denies the charge or approves it and returns an approval code. Again, it charges a small fee to its user, in this case the commerce service.
The credit card service, wanting to create an enforceable legal record of the approval, does not send approval messages directly back to the commerce service. Instead, it routes the message via an intermediary such as the US Post Office, which adds a proof-of-transmission certification and then forwards the message to the commerce service.
The commerce web service serves many different customers at once, each with a distinct cart. So do the other services. Some of the messages are encrypted. Many are digitally signed, in part to prove that the message originates from an acceptable application and has not been tampered with. Additionally, the messages contain reliability information and are used in a protocol that allows either party to detect duplicate messages, retry in the case of apparently lost messages and detect when communication has failed.
How did the developer of the catalog front-end application know which messages to send to the shopping cart web service? He read the documentation, of course, a large element of which was formalized as a WSDL file. This listed all the messages sent and received by the catalog service. He also read the process flow description file, learning the sequence of messages (such as that one message creates a cart, after which a different message adds items to it, after which a different message causes checkout, etc.).
Similarly, the developer of the shopping cart service read the documentation, WSDL and process flow descriptions for the credit card validation service and the proof-of-transmission services.
How did the developer of the catalog service discover the shopping cart web service? He searched for it in a directory of useful services. Similarly, Alice, wanting to find a restaurant supplier, found it in the directory.
The purpose of the above scenario is to show how an application can be built out of several communicating web services, allowing large-granularity, implementation-independent building blocks for application construction. These distinct web services could be co-located or widely distributed over the web. Application construction is facilitated by standardized mechanisms for signature, encryption, guaranteed delivery as well as standardized forms of machine-readable definitions and contracts.
A key assumption of our framework is that application integration and assembly occurs over services in different enterprises or domains of control. We view the standard, defined mechanisms for guaranteed delivery, security and other qualities of service as providing the glue that supports applications spanning different domains and infrastructures. We believe that interface aspects of the framework, like WSDL, will support a common programming model for assembly applications within an infrastructure and over different enterprises and domains. Within an infrastructure or domain, the underlying service implementation may rely on other protocols and services that plug into the framework. For example, within a domain of control, reliable messaging may rely on the enterprises existing choice of products, and use a gateway to map the internal service to remote web services. Similar models may apply to transactions, security, etc.
In more detail, these functional components are:
Function: Message envelope and controlled extensibility
Specific technology: XML Protocol (under development)
Description: Messages need a facility to delimit the message, drawing a boundary around the contents of the message and establishing ground-rules for interpretation of the contents in the context of a message exchange between parties. Controlled extensibility, of which versioning is a specific application, must be in the base protocol. Messages suitable for Internet scale need extensibility in two dimensions: First, because the sender of a message may have dynamically composed the message from separate parts, some of which might be unfamiliar to the receiver, the sender must be able to tag the parts to distinguish those whose processing by the receiver is mandatory versus optional. Second, because a sender may create a final message by routing a starting message through one or more intermediate processors (actors) that modify it, the sender must be able to distinguish those parts that are intended for the final receiver from those parts intended for an intermediate processor.
Used: Base for all XML messaging
Function: Binary Attachments
Specific Technology: TBD.
A message may have binary components that are expensive to convert to and from valid XML forms such as Bin.Base64. A binary attachments specification describes how to associate such or other resources with a message, possibly in the same transmission unit. This model may also support passing binary attachments by URL reference. This enables only the services of a multi-step flow that need to attachment to receive it, using a service interface.
Used: Large binary objects (no example in the scenario).
Function: Message Exchange aka Routing
Specific Technology: TBD.
A message sent from party A to party B, possibly through intermediary parties I1, I2, I3 etc., possibly requiring a response, must have some means of designating the parties and providing an identifier to the message to enable the sender to correlate the reply to the sent message. The model for intermediaries may support direct identification of the intermediaries, or a description of the type of service that a selected intermediary may perform.
Used: All messages, potentially.
Function: Message Correlation
Specific Technology: TBD
Description: Messages may be related to each other by being elements of a single application-level protocol instance and need a mechanism for correlation. This requires identification beyond just the individual message, but also the larger protocol instance and possibly the protocol type.
Used: All shopping cart messages related to the same cart instance are correlated. The approval or denial of a credit card charge is correlated to the request.
Function: Guaranteed Message Exchange
Specific Technology: TBD
Description: In the exchange of messages, individually or as part of a long-running process, the communicating parties benefit from certain delivery guarantees. The receiver of a message would like to detect duplicate copies of the same message, preferably allowing some bounds on the storage that may be required for this function without compromising the effectiveness of the detection. The sender would like to determine when a message has definitely been received by the destination party. The combinatorics of error handling, and hence, application complexity, are reduced to the degree that (a) ambiguity over the receipt status of a message is eliminated and (b) both parties to a message are guaranteed the same view of the status of the communication.
There may be several levels of message guarantees. For example, some of these might include 1) At-Least Once for queries, 2 ) At Most Once, for some update modes, and 3) Exactly Once.
Used: The catalog application uses guaranteed message exchange when it communicates with the shopping cart web service, ensuring that no items or steps are lost or duplicated. Similarly, the shopping cart web service uses guaranteed communication to the credit card service.
Function: Digital Signature
Specific Technology: XML Dsig
Description: Digital signatures, applied to whole messages or distinct parts, allow the receiver of a message to authenticate the identity or other specific characteristics of the sender as well as to verify that the message has not been altered after composition. The mechanism to apply a digital signature should be independent of specific signature technology and is separate from any protocols or techniques used to verify signatures, manage keys or determine authorizations.
Used: Messages to the credit card service prove that they originate from the shopping cart service and have not been tampered with.
Function: Encryption
Specific Technology: XML Encryption (in process)
Description: Encryption allows the sender of a message to make whole messages or parts unreadable except by selected, privileged parties. The mechanism to apply encryption should be independent of specific encryption technology and is separate from any protocols or techniques used to manage keys.
Used: Communication with the credit card service is encrypted. Perhaps communication between the catalog application and the shopping cart service is also.
Function: Transactions and Activities
Specific Technology: TBD
Description: Transactions allow parties to a control the execution, completion and visibility of sequences of operations. The “Two Phase” model of traditional transaction processing provides a useful metaphor. We believe that the realization in multi-party web services may support this metaphor, but the underlying implementation will be significantly different due to the fact that web service transactions span transaction infrastructure and models, domains of control and have duration far longer than tradition models support. We also expect that more flexible process, compensation and version based transaction schemes will be needed for web services.
Used: Not used in the example scenario.
Function: Service Description
Specific Technology: WSDL
Description: A Service Description names and lists the messages that may be sent and received by a web service, both abstractly and by concrete syntax, identifies the protocols by which they may be exchanged, lists one or more logical ports associated with the service and binds those ports to one or more addresses. Preferably, the service description notation is independent of any particular implementation technology, message protocol and encoding. In addition, these parts should be separable, allowing for incomplete service descriptions and for a more complete description to be created by reference to a less complete one, plus specifying details.
Used: The shopping cart, credit card and proof-of-transmission services are all formally described using this.
Function: Process Flow Contract Description
Specific Technology: TBD
Description: Enriching a Service Description, the external contract of a web service may describe the valid sequences of messages, that is, which messages initiate specific business processes, which may follow which in each direction, and which are terminal. Preferably, a flow orchestration language allows composition of a contract by reference to several other contracts.
Used: The shopping cart, credit card and proof-of-transmission services are all formally described using this.
Function: Inspection.
Specific Technology: TBD
Description: Inspection is a process or protocol allowing one to, given an identifier of a resource such as a web service, to obtain metadata about that resource, metadata such as its service description and process flow orchestration contracts.
Used: Not used in the example scenario, but one could inspect any of the services and locate their descriptions by this mechanism. Additionally, a web crawler might assemble a directory of services by using inspection.
Function: Discovery
Specific Technology: UDDI
Description: Discovery is a protocol by which one can obtain identifiers (and perhaps other data) about web services based on characteristics of the services.
Used: Finding the services, finding the restaurant supplier.
These components of course are not unrelated. In fact, they can be organized into three stacks: wire format (or exchange format), description and discovery. It is also the case that some stacks depend on others. For example, the wire stack will provide the basis for the discovery and description stacks. Thus, the “discovery” function may itself be a web service accessed through the wire stack.
Wire – those pieces that represent what is sent during a given exchange, the combination of the data, the envelope and all other metadata necessary for the successful transmission of a message.
Description – the collection of specifications that provide the formal definition of the format, use, or application, of the specs in the “Wire” stack.
Note that the description framework is modular: the offerings are both layered and ordered. Each technology is built on the ones above, and simpler ones provide useful function by themselves. Therefore, we anticipate that schemas and WSDL will be deployed first to provide descriptions for individual messages and message pairs. Over time, tools will become available to support the increasingly rich descriptions enabled by the other standards.
Discovery – those specs that provide a means for manual or automated searching and discovery of the components in the other two stacks.