Web Services Architecture


  Web Services.pdf (Size: 536.86 KB / Downloads: 11)


Introduction

Purpose of the Web Service Architecture

Web services provide a standard means of interoperating between different software applications, running
on a variety of platforms and/or frameworks. This document (WSA) is intended to provide a common
definition of a Web service, and define its place within a larger Web services framework to guide the
community. The WSA provides a conceptual model and a context for understanding Web services and the
relationships between the components of this model.
The architecture does not attempt to specify how Web services are implemented, and imposes no
restriction on how Web services might be combined. The WSA describes both the minimal characteristics
that are common to all Web services, and a number of characteristics that are needed by many, but not all,
Web services.

Agents and Services

A Web service [p.37] is an abstract notion that must be implemented by a concrete agent [p.31] . (See
Figure 1-1 [p.9] ) The agent is the concrete piece of software or hardware that sends and receives
messages [p.19] , while the service is the resource characterized by the abstract set of functionality that is
provided. To illustrate this distinction, you might implement a particular Web service using one agent one
day (perhaps written in one programming language), and a different agent the next day (perhaps written in
a different programming language) with the same functionality. Although the agent may have changed, the
Web service remains the same.

Overview of Engaging a Web Service

There are many ways that a requester entity might engage and use a Web service. In general, the following
broad steps are required, as illustrated in Figure 1-1 [p.9] : (1) the requester and provider entities become
known to each other (or at least one becomes know to the other); (2) the requester and provider entities
somehow agree [p.67] on the service description and semantics that will govern the interaction between
the requester and provider agents; (3) the service description and semantics are realized by the requester
and provider agents; and (4) the requester and provider agents exchange messages, thus performing some
task on behalf of the requester and provider entities. (I.e., the exchange of messages with the provider
agent represents the concrete manifestation of interacting with the provider entity’s Web service.) These
steps are explained in more detail in 3.4 Web Service Discovery [p.68] . Some of these steps may be
automated, others may be performed manually.

Conformance

Unlike language specifications, or protocol specifications, conformance to an architecture is necessarily a
somewhat imprecise art. However, the presence of a concept in this enumeration is a strong hint that, in
any realization of the architecture, there should be a corresponding feature in the implementation.
Furthermore, if a relationship is identified here, then there should be corresponding relationships in any
realized architecture. The consequence of non-conformance is likely to be reduced interoperability: The
absence of such a concrete feature may not prevent interoperability, but it is likely to make such
interoperability more difficult.