3.

2 Web Services Technologies

Web service architecture involves many layered and interrelated technologies. There are
many ways to visualize these technologies, just as there are many ways to build and use
Web services. Figure 3-1 below provides one illustration of some of these technology
families.

Figure 3-1. Web Services Architecture Stack

In this section we describe some of those technologies that seem critical and the role they
fill in relation to this architecture. This is a necessarily bottom-up perspective, since, in
this section, we are looking at Web services from the perspective of tools which can be
used to design, build and deploy Web serivces.

The technologies that we consider here, in relation to the Architecture, are XML, SOAP,
WSDL. However, there are many other technologies that may be useful. (For example,
see the list of Web services specifications compiled by Roger Cutler and Paul Denning.)
See also B An Overview of Web Services Security Technologies

3.2.2 SOAP

SOAP 1.2 provides a standard, extensible, composable framework for packaging and
exchanging XML messages. In the context of this architecture, SOAP 1.2 also provides a
convenient mechanism for referencing capabilities (typically by use of headers).

[SOAP 1.2 Part 1] defines an XML-based messaging framework: a processing model and
an exensibility model. SOAP messages can be carried by a variety of network protocols;
such as HTTP, SMTP, FTP, RMI/IIOP, or a proprietary messaging protocol.

[SOAP 1.2 Part 2] defines three optional components: a set of encoding rules for
expressing instances of application-defined data types, a convention for representing
remote procedure calls (RPC) and responses, and a set of rules for using SOAP with
HTTP/1.1.

While SOAP Version 1.2 [SOAP 1.2 Part 1] doesn't define "SOAP" as an acronym
anymore, there are two expansions of the term that reflect these different ways in which
the technology can be interpreted:

1. Service Oriented Architecture Protocol: In the general case, a SOAP message

represents the information needed to invoke a service or reflect the results of a
service invocation, and contains the information specified in the service interface
definition.

2. Simple Object Access Protocol: When using the optional SOAP RPC
Representation, a SOAP message represents a method invocation on a remote
object, and the serialization of in the argument list of that method that must be
moved from the local environment to the remote environment.

3.2.3 WSDL

WSDL 2.0[WSDL 2.0 Part 1] is a language for describing Web services.

WSDL describes Web services starting with the messages that are exchanged between the
requester and provider agents. The messages themselves are described abstractly and then
bound to a concrete network protocol and message format.

Web service definitions can be mapped to any implementation language, platform, object
model, or messaging system. Simple extensions to existing Internet infrastructure can
implement Web services for interaction via browsers or directly within an application.
The application could be implemented using COM, JMS, CORBA, COBOL, or any
number of proprietary integration solutions. As long as both the sender and receiver agree
on the service description, (e.g. WSDL file), the implementations behind the Web
services can be anything.

3.4 Web Service Discovery

If the requester entity wishes to initiate an interaction with a provider entity and it does
not already know what provider agent it wishes to engage, then the requester entity may
need to "discover" a suitable candidate. Discovery is "the act of locating a machine-
processable description of a Web service that may have been previously unknown and
that meets certain functional criteria. " [WS Glossary] The goal is to find an appropriate
Web service.

A discovery service is a service that facilitates the process of performing discovery. It is a

logical role, and could be performed by either the requester agent, the provider agent or
some other agent.

Figure 3-2 ("Discovery Process") expands on Figure 1-1 to describe the process of
engaging a Web service when a discovery service is used.

Figure 3-2. Discovery Process

Service engagement using a discovery service proceeds in roughly the following steps.

1. The requester and provider entities "become known to each other":

a. The discovery service somehow obtains both the Web service description
("WSD" in Figure 3-2) and an associated functional description ("FD") of
the service.

The functional description ("FD" in Figure 3-2) is a machine-processable

description of the functionality (or partial semantics) of the service that the
provider entity is offering. It could be as simple as a few words of meta
data or a URI, or it may be more complex, such as a TModel (in UDDI) or
a collection of RDF, DAML-S or OWL-S statements.

This architecture does not specify or care how the discovery service
obtains the service description or functional description. For example, if
the discovery service is implemented as a search engine, then it might
crawl the Web, collecting service descriptions wherever it finds them, with
the provider entity having no knowledge of it. Or, if the discovery service
is implemented as a registry (such as UDDI), then the provider entity may
need to actively publish the service description and functional description
directly to the discovery service.

b. The requester entity supplies criteria to the discovery service to select a

Web service description based on its associated functional description,
capabilities and potentially other characteristics. One might locate a
service having certain desired functionality or semantics; however, it may
be possible to specify "non-functional" criteria related to the provider
agent, such as the name of the provider entity, performance or reliability
criteria, or criteria related to the provider entity, such as the provider
entity's vendor rating.
c. The discovery service returns one or more Web service descriptions (or
references to them) that meet the specified criteria. If multiple service
descriptions are returned, the requester entity selects one, perhaps using
additional criteria.

2. The requester and provider entities agree on the semantics ("Sem" in Figure 3-2)
of the desired interaction. Although this may commonly be achieved by the
provider entity defining the semantics and offering them on a take-it-or-leave-it
basis to the requester entity, it could be achieved in other ways. For example, both
parties may adopt certain standard service semantics that are defined by some
industry standards body. Or in some circumstances the requester could define the
semantics. The important point is that the parties must agree (in the sense
described in 3.3 Using Web Services) on the semantics, regardless of how that is
achieved.
 Step 2 also requires that the parties agree (in the sense described in 3.3 Using
Web Services) on the service description that is to be used. However, since the
requester entity obtained the Web service description in Step 1.c, in effect the
requester and provider entities have already done so.

3. The service description and semantics are input to, or embodied in, both the
requester agent and the provider agent, as appropriate.

4. The requester agent and provider agent exchange SOAP messages on behalf of
their owners.

B.2 Web Services Security

Developed at OASIS, Web Services Security (WSS) defines a SOAP extension providing
quality of protection through message integrity, message confidentiality, and message
authentication. WSS mechanisms can be used to accommodate a wide variety of security
models and encryption technologies.

The work provides a general mechanism for associating security tokens with messages.
The specification does not require a specific type of security token. It is designed to
support multiple security token formats. WSS describes how to encode binary security
tokens. The specification describes how to encode X.509 certificates and Kerberos
tickets. Additionally, it also describes how to include opaque encrypted keys.

The WSS specification defines an end to end security framework that provides support
for intermediary security processing. Message integrity is provided by using XML
Signature in conjunction with security tokens to ensure that messages are transmitted
without modifications. The integrity mechanisms can support multiple signatures,
possibly by multiple actors. The techniques are extensible such that they can support
additional signature formats. Message confidentiality is granted by using XML
Encryption in conjunction with security tokens to keep portions of SOAP messages
confidential. The encryption mechanisms can support operations by multiple actors.