Web Services Architecture:
Direction and Position Paper

 

Donald F. Ferguson, dff@us.ibm.com
IBM Corporation
Paper for W3C Web Services Workshop, April 11-12, 2001
© 2001 International Business Machines Corporation. All rights reserved.

 

 

1                 Introduction

The term “web services” describes the concepts and technology that are an evolution of several existing industry functions. These include:

·          HTML forms are a dominant mode of client-server computing over the Internet. Many applications have evolved from HTML and forms into a model in which a thicker client function runs in the browser and interacts with the site through POST/GET of XML documents.

·          Business-to-business interaction has evolved from paper mail to phone calls and faxes, and then again into HTML form based interactions and simple, symmetric POST/GET of XML documents between “programs” running in different enterprises.

·          Traditional business-to-business has focused on systematic, standardized message formats and protocols like EDI, RosettaNet, cXML, etc. These standard protocols support well defined main stream interactions, which often need to be augmented by more ad hoc and enterprise pair-wise business to business interactions.

·          Messaging, message driven processing and message brokering are a core element of many intra-enterprise, application-to-application solutions. Intra-enterprise application integration needs to spread out to encompass external, partner applications.

·          Industry groups have defined vocabularies, message dictionaries and interaction flows to standardize commerce in their segments. In many cases, these groups have defined network and service protocols to support their dictionaries. The web services initiative will provide a common base set of protocols. Domain and vertical groups will build their semantic information using the service model on top of the base functions that enable web services. This allows better interoperability between enterprises that use many vertical and domain definitions.

So, what’s new about web services? This is an important question because the answer defines the requirements, and thus the solution.  We think that the new concepts are:

·          More traditional distributed programming models focus on locating instances of “services” by name. Some examples are symbolic queue names in message middleware and JNDI look up in distributed Java™. The web service model introduces the concepts of By-what and By-how publication and discovery of instances. We can view this like the “crawler” and “search engine” approaches to finding interesting web sites.

·          More traditional approaches to programming rely on pre-defined interfaces. The code that uses the service understands the message/command formats of the target service. Web service models will increasingly rely on brokers that convert from requested interfaces to published interfaces. In fact, initial “service brokers” are a natural evolution of existing approaches to message brokering. For example, if there are two or three common standards for services and message formats in a specific industry, a broker allows an enterprise to implement and use one vocabulary and still interoperate with companies using other dialects.

General solutions to the interface and service brokering appear intractable, and are not well understood. This is an area that will undergo much research and pilot development over the next few web years.

·          Since web services are an evolution of many existing models, it must support a broad set of underlying implementation technology. The same conceptual model will cover both simple XML posting of forms and robust, reliable message oriented middleware.

·          Most previous approaches to application integration are systematic. Web services focus more on ad hoc, shorter-term partnerships and collaborations. Moreover, the interfaces between the partners may be newly defined, specifically for the duration of the collaboration.

In the remainder of this paper, we discuss the functions and technology that should support web services.

2                Protocol and Architecture Elements

2.1     Overview

We view web services having several complimentary “layers.” Web service users need the flexibility to use the minimal subset of layers that meets their requirements.

2.2     Base Element: Message Exchange and Function Call

The most basic requirement is the ability to send a message to a web service, or call a web service with a message and receive a response. The web service/XML Protocol work needs to provide support for both one-way messages and a request/response model. .

The SOAP 1.1 input to XML Protocol in W3C and the ebXML/SOAP convergence meets the base requirements for web services. We feel that web service standards need to additionally support the following protocols:

·          E-Mail provides support for disconnected interactions with services.

·          FTP provides support for batch style processing of requests and passing large parameters on operations.

The main element that XML Protocol must add is simple, reliable messaging. We feel that there should be the following levels of function, through the simplest possible implementation:

1.        Best-Effort: The client sends the message, and the client and infrastructure do not attempt retransmissions.

2.        At-Least-Once: The client makes a request and retries the request until it receives an acknowledgment. Duplicate message processing by the receiver is not a problem, for example simple query processing.

3.        At-Most-Once: This builds on the At-Least-Once scenario. The client retries the request until it gets a reply. A mechanism like message UUIDs allows the server to suppresses any duplicate requests, insuring the request is not executed multiple times. (For example, a request to take an item from a number the inventory).

4.        Exactly-Once: The client makes a request and is guaranteed by the reply that the request has been executed. The exactly-once mode of interchange eliminates the need to retransmit requests and accommodates failure scenarios.

The XML Protocol model should support these qualities of service over non-reliable infrastructures, but default to a null implementation when the underlying message machinery meets the quality of service.

This section described the base level of message functions. We expect future extension into functions like publish/subscribe, message ordering, delivery time constraints, priorities, multi-cast, etc.

2.3     Security

Security is a complex discipline, with many sub-disciplines. For authentication, we believe that XML Protocol/SOAP must extend to support

·          A BASIC-AUTH mechanism in which a user ID and password flows in a header. The sender encrypts UID/PW pair with the recipient’s public key. If communication does not have intermediate hops, the sender may rely on SSL or HTTPS for UID/PW privacy.

·          A standard header and algorithms for producing a message digest and signing the message with the sender’s private key. Thus, a recipient can verify the identity of the originator of the message. This requires pervasive adoption of certificates for individuals as private citizens, and as employees of an enterprise.

·          Support for in-network, third party authentication services. In this model, B publishes that it accepts authentication “tokens” from a site C. Site’s using B interact with site C to obtain a security credential that can flow to B. In this model, the site C may maintain the User Name/Profile/Password information or perform the certificate validation. B has a simple mechanism for validating credentials that C generates.

Privacy has two meanings in security. The first is preventing third party examination of messages. HTTPS and SSL provide hop-by-hop privacy and integrity. We believe that the XML Protocol model should also support end-to-end sealing of the message and its sub-elements. So, there should be a way to define a multi-segment message and to seal the segments with the public keys of the intended recipients. There is an interaction between sealing of messages in a multi-hop flow, and the process/flow capability we discuss below.

The second definition of privacy is respecting policies on shared data. Person-Business web service interactions and business-business interactions inevitably result in both ends obtaining information about each other. This can be purchasing history and preferences, financial account numbers, etc. P3P has done some initial work in this area, and we feel that supporting the definition of privacy policies is critical to the success of web services.

In our view, an endpoint is responsible for implementing Authorization. There should be support in Agreements (see below) for exchanging information between enterprises to define which employees may use which services. We also discuss a vague concept, Intermediaries below, and feel that this will provide the approach for Audit and Non-Repudiation.

2.4     Conversations and Activities

In the loose sense, "transactions" are one of the most fundamental concepts in application processing. For many reasons, specifically the asynchronous and multi-span of control nature of the web and the duration of request processing, web services require a more flexible mechanism for controlling requests and outcomes than typically offered by traditional distributed and database transaction models.

Instead, we recommend an incremental approach to transactional quality of service.

1.        Offer a core Activity Service, which includes a generalized capability for specifying the operational context of a request (or series of requests), controlling the duration of the activity and defining the participants engaged in an outcome decision. An example of such a service is typified in the OMG Extended Structuring Mechanism, which is also be adopted within Java under the Activity Service JSR.

2.       To introduce a Conversation Service that a provides the fundamental conversation styles or behaviors that need to be constructed for the web services using the activity service. These fundamental styles are:

·          Under Request Atomicity a single operation on a web service occurs completely or not at all. This is a capability that the end-point publishes to users. The end-point may implement this by an internal transaction on its infrastructure, or some other mechanism.

·          Conversations allow a pair of collaborating services to correlate sequences of requests within a loose unit of work. The pair of services uses architected conversation messages and headers to begin the conversation and end the conversation. They determine if the conversation ended successfully or if one or both participants want the conversation to rollback. The semantics of rollback is that each participant will undo the operations it has performed within the conversation.

These styles or behaviors mechanisms are by no means complete. We feel, however, that they allow sites participating in web services to supplement their existing implementations to support more complex processing and compensation models. The sites can build on their internal transaction and business logic environments to provide the increased flexibility. Additionally the activity service would allow for additional operational patterns beyond the traditional transactional model.

The sole requirement we currently place on web services is the ability for two endpoints to agree on the outcome. Multiparty "transaction" processing occurs within enterprises that use their own internal transaction and workflow models to manage operations and conversations with multiple participants.

2.5     Business Processes and Agreements

We see three levels of functions supporting complex, multi-party business processes and “workflows.”

1.        The most basic level is the service description, in WSDL. This specifies which operations the endpoint supports and what operations it will call on a service that binds to it.

2.        The end-point description (Web Services End-Point Language) builds on the service description by specifying what “behavior” the service supports in addition to the “application interface.” This would include specifying the Quality of Service (QoS) that the endpoint provides as well as information on correct usage of the interface. Some examples of QoS might be transaction and conversation semantics, auditing and reporting to third parties, etc. Some examples of correct usage information might be constraints on parameter values and valid sequences for invoking operations.

3.        The end-point description provides enough information to enable programmers to develop a new service that choreographs existing services to build larger business process.  We envision or more encompassing Web Services Flow Language (WSFL) that defines the structure of global, multiparty business interactions and the semantics for including an end-point in the processes.

The final element of the model is an Agreement. This augments the end-point definition by allowing to sites to document:

·          Which principals in each organization can invoke which services/operations in the other organizations? This provides information to support authorization.

·          The concrete values of parameters in an end-point definition. For example, sites A and B may agree on time-out values for message transmission and a maximum time by which compensation may occur.

2.6     Manageability

Web service infrastructure needs to support very basic management interfaces. We view each site having full autonomy over its infrastructure and management. We feel that on a peer wise basis, each site should provide basic reporting and recovery for the various protocols. For example, a site A that supports conversations should provide an interface that another site B can use to query for active conversations and force rollback. Similar functions apply for reliable messaging, etc.

So, as XML Protocol moves forward adding capability, each function/protocol definition should define the normal channel/protocol as well as a peer-wise management interface for the protocol level.

2.7     Intermediaries

One of the fundamental enhancements that web services will provide is support for Intermediaries. An obvious example is support for an in-network, third party non-repudiation service or archive service. A site that publishes a service would specify which intermediaries or chains of intermediaries it supports/requires, the service they provide and their identity.

The By-What and By-How mechanism provides the metadata necessary for site A to examine the intermediary chain that site B supports for a service.

A site B specifies a WSFL sub-graph that defines the structure of the intermediaries. When site A resolves a service to site B, the WSL graph states that invoking the service on B occurs by invoking the service on an entry node in the flow, which will result in the service eventually occurring at B after the intermediaries process the message. The WSFL also states the flow through intermediaries on messages sent back to A. Finally, the flow definition specifies which data must by sealed for delivery to which intermediaries in the chain.

2.8     Context Awareness

Writers often refer to “intelligent web services.” It is the responsibility of the web service provider to code an intelligent application. Intelligence is not useful without information, however. So, the XML Protocol work needs to define support for propagating context information on calls to web services. Some examples of context information are

·          The type of wireless device on which the application executes and the GPS coordinates.

·          A reference to one or more “user profiles” that define the end-user’s preferences.

·          Current time and “condition” information from the caller’s perspective.

XML Protocol per se is not responsible for defining the details or schema of preferences and contexts. Rather, the model requires an approach for flowing and propagating contexts in an extensible way, which allows specific industries, coalitions, etc. to define their context schema and semantics.

2.9     Directory Binding

The Directory function of web services is the core to enabling By-What and By-How. The services and capabilities discussed in the preceding sections enable a service provider to specify the quality with which it delivers a service, e.g. reliable message support, Conversations, Caller must use BASIC-AUTH, etc.  To complete this, each service layer that augments XML protocol must define an extension to WSDL (in the form of a binding namespace) and corresponding XML Schema to specify how the end-point implements the capability. This allows users of a service to query for services that deliver the capability it requires.

We view the directory look-up mechanism to be based on a query mechanism. Specifically, the query would support:

·          A predicate that selects a service interface using a template model for WSDL.

·          A predicate that selects a service interface using a template for the QoS binding information associated with the registered service. For example, the service supports Conversations.

·          A predicate that selects services that support specific types or instances of intermediaries.

·          A predicate that selects a service based on associations between the service and taxonomies provided by industry and standards bodies.

The service discovery can combine these predicates to select service endpoints that meet is criteria.

3                Discussion and Conclusions

In summary, we see the need for the following standards efforts in the area of web services:

·          Defining support for reliable messaging over core, base protocols. This is critical to broad adoption of interoperable web services.

·          Defining the complete, end-to-end security model. This should initially focus on authentication and multi-hop/end-to-end sealing of messages. Authorization is an end-point function, and the web services standards should define the interfaces and protocols for establishing agreements. Other security functions, like audit and non-repudiation should appear as services in the network.

·          Defining a complete “flow model” including support for complex, multi-party processes, end-point definitions, intermediaries and agreements.

·          Defining support for activities and conversations that allow sites to determine the correct, agreed completion of interactions among services.

·          Extending initial support in areas like UDDI for associating metadata, taxonomies and templates with published services and allowing more flexible query and “look up” of services.

·          Support for propagating application context with service requests and responses.