|
|
|
Web Services Architecture:
Direction and Position Paper
Donald F. Ferguson, [email protected]
IBM Corporation
Paper for W3C Web Services Workshop, April 11-12, 2001
© 2001 International Business Machines Corporation. All rights reserved.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.