1 Introduction
[dbooth editing this section. The previous "Contract with the Reader" has been merged into this section.]
1.1 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.
The Web service architecture (WSA) is intended to provide a common definition of a Web service, and define its place within a larger Web services framework to guide Web services product implementers, Web services specification authors, Web services application developers, and Web services students.
The WSA provides a model and a context for understanding Web services, and a context for placing Web services specifications and technologies into relationships with each other and with other technologies outside the WSA. The WSA promotes interoperability through the definition of compatible protocols. The architecture does not impose any requirements on the implementation of services, and imposes no restriction on how 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.
1.2 Intended Audience
This document is intended for a large and diverse audience. Expected readers include users and creators of individual Web Services, Web Service specification authors, and others.
1.3 Document Organization
This document provides introductory overview material followed by normative material.
The body of the architecture is presented as a set of core concepts and key relationships between them. A core concept is usually a noun, but does not have to be, and the relationships between conncepts are usually predicates, i.e., verbs. Both noun-style and verb-style concepts are present in the architecture, the latter playing a prominent role in the relationships between concepts.
A primary goal of the concepts section is to provide a basis for measuring conformance to the architecture. For example, the resource concept states that resources have identifiers (in fact they have URIs). Using this assertion as a basis, we can measure conformance to the architecture of a particular resource by looking for its identifier. If, in a given instance of this architecture, a resource has no identifier, then it is not a valid instance of the architecture.
While the concepts and relationships represent an enumeration of the architecture, the stakeholders' viewpoints approaches from a different perspective: how the architecture meets the goals and requirements. In this section we elucidate the more global properties of the architecture and demonstrate how the concepts actually achieve important objectives.
A primary goal of the Stakeholder's Perspectives section is to relate the actual architecture with the requirements of the architecture, especially as outlined in the Web services requirements document.
For example, in the 3.14 Web service manageability section we show how the management of Web services is modeled within the architecture. The aim here is to demonstrate that Web services are manageable and which key concepts and features of the architecture achieve that goal. In this case, manageability is realized by showing a link between the concept of a physically deployed resource and the abstract concept it realizes (such as a Web service). Management of such deployed resources then leads to management of Web services themselves.
The key stakeholder's viewpoints supported in this document reflect the major goals of the architecture itself: interopability, extensibility, security, Web integration, implementation and manageability.
Where appropriate, the WSA also identifies candidate technologies that have been determined to meet the functionality requirements defined within the architecture.
1.4 Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in RFC 2119.
1.5 What Is a Web Service?
Although there are a number of varied and often seemingly inconsistent motivations for, and uses of, the term "Web service", at its core, the following definition captures what we believe to be the shared essence of the term:
[Definition: A Web service is a software system identified by a URI, whose public
interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These
systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by
internet protocols.]
[dbooth: Two problems with this definition: (1) What are "bindings"? (We haven't defined them.) Why are they relevant to the definition of a Web service? I think we could just omit "and bindings" from the definition. (2) Does a WS really need to have a "discoverable" WSD in order to be a WS? A WS certainly could have a private WSD or a WSD that is developed collaboratively rather than being "discovered". Also, it seems odd to define something X based on the existence of something else Y that is not a part of X. I suggest instead: "A Web service is a software system identified by a URI, whose public
interfaces are defined and described using XML. Other
systems may interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by
internet protocols."]
This definition serves as the basis for the architecture described in this document.
1.5.1 Agents and Services
A Web service is viewed as an abstract notion that must be implemented by a concrete agent. (See Figure 1.) The agent is the physical entity (a piece of software) that sends and receives messages, while the service is 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). Although the agent may have changed, the Web service remains the same.
1.5.2 Requester and Provider
The purpose of a Web service is to provide some functionality on behalf of its owner -- a legal entity, such as a business or an individual. The provider entity is the legal entity that provides an appropriate agent to implement a particular service. (See Figure 1: Basic Architectural Roles.)
A requester entity is a legal entity that wishes to make use of a provider entity's Web service. It will use a requester agent to exchange messages with the provider entity's provider agent. In order for this message exchange to be successful, the requester entity and the provider entity must first agree on both the semantics and the mechanics of the message exchange.
1.5.3 Service Description
The mechanics of the message exchange are (partially) documented in a Web service description (WSD). (See Figure 1.) The service description is a machine processable specification of the message formats, datatypes and protocols that should be used between the requester agent and the provider agent. It also specifies the network location of the provider agent, and may provide some information about the message exchange pattern that is expected.
1.5.4 Semantics
The semantics ("Sem" in Figure 1) of the message exchange represents the "contract" between the requester entity and the provider entity regarding the purpose and consequences of the interaction. It also includes any additional details on the mechanics of the message exchange that are not specified in the service description. Although this "contract" represents the overall agreement between the requester entity and the provider entity on how and why their respective agents will interact, it is not necessarily written or explicitly negotiated. It may be explicit or implicit, oral or written, machine processable or human oriented.
While the service description represents a "contract" governing the mechanics of interacting with a particular service, the semantics represents a "contract" governing the meaning and purpose of that interaction.
1.5.5 The Role of Humans
Although one of the main purposes of Web services is to automate processes that might otherwise be performed manually, humans still play a role in their architecture and use, notably in two ways:
Humans need to agree on the semantics and the service description. Since a human (or organization) ultimately is the legal owner of any Web service, people must either implicitly or explicitly agree on the semantics and the service description that will govern the interaction.
Often this agreement will be accomplished by the provider entitity publicizing and offering both the semantics and the service description as take-it-or-leave-it "contracts" that the requester entity must accept unmodified as conditions of use. However, nothing in this architecture prevents them from reaching agreement by other means. For example, in some situations, the service description (excepting the network address of the service) may be defined by an industry organization, and shared by many requester and provider entities. In other situations, it may originate from the requester entity (even if it is written from provider entity's perspective).
Humans create the requester and provider agents (either directly or indirectly). Ultimately, humans must ensure that these agents implement the terms of the agreed-upon service description and semantics. There are many ways this can be achieved, and this architecture does not specify or care what means are used. For example:
an agent could be hard coded to implement a particular, fixed service description and semantics;
an agent could be coded in a more general way, and the desired service description and/or semantics could be input dynamically; or
an agent could be created first, and the service description and/or semantics could be produced from the agent code.
Regardless of the approach used, from an information perspective both the semantics and the service description must be somehow be input to, or embodied in, both the requester agent and the provider agent before the two agents can interact.
Figure 1: Basic Architectural Roles.
[dbooth: Not sure how we should label the figures. Also, Figure 1 may need to be resized.]
1.6 Architectural Style
1.6.1 Interoperability Architecture
The Web services architecture is an interoperability architecture — it identifies those global elements of the global Web services network that are required in order to ensure interoperability between Web services. It is not intended to be an architecture for individual Web services; the structure and implementation of these is inherently private and is left to the discretion of the developers of these. However, in order to ensure interoperability, certain concepts, relationships and constraints are important; and this architecture identifies those.
The major goals of the architecture are outlined in the Web Services Architecture Requirements document. These goals are to promote
interoperability between Web services,
integration with the World Wide Web,
reliability of Web services,
security of Web services,
Scalability and extensibility of Web services, and
Manageability of Web services.
The role of this architecture is to provide a global perspective on the networked service architecture. Other specifications, such as SOAP 1.2 and WSDL give detailed recommendations for specific requirements. This architecture is intended to show how these, and other related, technologies fit together to deliver the benefits of Web services.
Some non-goals of the architecture include:
to prescribe a specific programming model or programming technology
to constrain the internal architecture and implementation of specific Web services
to demonstrate how Web services are constructed
to be specific about how messages or other descriptions are formatted
to determine specific technologies for messaging, discovery, choreography etc.
1.6.2 Service Oriented Architecture
The Web architecture and the Web services Architecture (WSA) are instances of a Service Oriented Architecture (SOA). To understand how they relate to each other and to closely related technologies such as CORBA, it may be useful to look up yet another level and note that SOA is in turn a type of Distributed System. A distributed system, consists of discrete software agents that must work together to implement some intended functionality. Furthermore, the agents in a distibuted system do not operate in the same processing environment, so they must communicate by hardware/software protocol stacks that are intrinsically less reliable than direct code invocation and shared memory. This has important architectural implications because distributed systems require that developers (of infrastructure and applications) consider the unpredictable latency of remote access, and take into account issues of concurrency and the possibility of partial failure. [Samuel C. Kendall, Jim Waldo, Ann Wollrath and Geoff Wyant, "A Note On Distributed Computing"].
An SOA is a specific type of distributed system in which the agents are "services" For the purposes of this document, a service is a software agent that performs some well-defined operation (i.e., "provides a service") and can be invoked outside of the context of a larger application. That is, while a service might be implemented by exposing a feature of a larger application (e.g., the purchase order processing capability of an enterprise resource planning system might be exposed as a discrete service), the users of that server need be concerned only with the interface description of the service. Furthermore, most definitions of SOA stress that "services" have a network-addressable interface and communicate via standard protocols and data formats.
Figure 2, Generic Service Oriented Architecture Diagram 
The description of a service in a SOA is essentially a description of the messages that are exchanged. This architecture adds the constraint of stateless connections, that is where the all the data for a given request must be in the request.
| Editorial note | |
| Put in a good word about the Semantic web and semantics in general here |
In essence, the key components of a Service Oriented Architecture are the messages that are exchanged, agents that act as service requesters and service providers, and shared transport mechanisms that allow the flow of messages. In addition, in public SOAs, we include the public descriptions of these components: descriptions of the messages, descriptions of the services and so on. These descriptions may be machine processable, in which case they become potential messages themselves: for use in service discovery systems and in service management systems.
1.6.3 SOA and REST archictures
The World Wide Web is a SOA that operates as a networked information system that imposes some additional constraints: Agents identify objects in the system, called "resources," with Uniform Resource Identifiers (URIs).
Agents represent, describe, and communicate resource state via "representations" of the resource in a variety of widely-understood data formats (e.g. XML, HTML, CSS, JPEG, PDF ). Agents exchange representations via protocols that use URIs to identify and directly or indirectly address the agents and resources. [W3C Technical Architecture Group, "Architecture of the World Wide Web"]
An even more constrained architectural style for reliable Web applications known as "Representation State Transfer" or REST has been proposed by Roy Fielding and has inspired both the TAG's Architecture document and many who see it as a model for how to build web services ["Architectural Styles and the Design of Network-based Software Architectures" ]. The REST Web is the subset of the WWW in which agents are constrained to, amongst other things, expose and use services via uniform interface semantics, manipulate resources only by the exchange of "representations", and thus use "hypermedia as the engine of application state."
The scope of "Web services" as that term is used by this working group is somewhat different. It encompasses not only the Web and REST Web services whose purpose is to create, retrieve, update, and delete information resources but extends the scope to consider services that perform an arbitrarily complex set of operations on resources that may not be "on the Web." Although the distrinctions here are murky and controversial, a "Web service" invocation may lead to services being performed by people, physical objects being moved around (e.g. books delivered).
We can identify two major classes of "Web services": REST-compliant or "direct resource manipulation" services in which in which the primary purpose of the service is to manipulate XML representations of Web resources using
the a minimal, uniform set of operations operations, and "distributed object" or "Web-mediated operation" services in which the primary purpose of the service is to perform an arbitrarily complex set of operations on resources that may not be "on the Web", and the XML messages contain the data needed to invoke those operations. In other words, "direct" services are implemented by web servers that manipulate data directly, and "mediated" services are external code resources that are invoked via messages to web servers.
| Editorial note | |
| Lots of open terminology issues here, such as what we call these two types of services, and whether the "web service" is the interface to the external code or the external code itself. |
Both classes of "Web services" use URIs to identify resources and use Web protocols and XML data formats for messaging. Where they fundamentally differ is that "distributed object" (editors' note: or "mediated services") use
application specific vocabularies as the engine of application state, rather than hypermedia. Also, they achieve some of their benefits in a somewhat different way. The emphasis on messages, rather than on the actions that are caused by messages, means that SOAs have good "visibility": trusted third parties may inspect the flow of messages and have a good assurance as to the services being invoked and the roles of the various parties. This, in turn, means that intermediaries, such as fire- walls, are in a better situation for performing their functions. A fire- wall can look at the message traffic, and at the structure of the message, and make predictable and reasonable decisions about security.
In REST-compliant SOAs, the visibility comes from the uniform interface semantics, essentially those of the HTTP protocol: an intermediary can inspect the URI of the resource being manipulated, the TCP/IP address of the requester, and the interface operation requested (e.g. GET, PUT, DELETE) and determine whether the requested operation should be performed. The TCP/IP and HTTP protocols have a widely supported set of conventions (e.g. known ports) to support intermediaries, and firewalls, proxies, caches, etc. are almost universal today. In non-REST [Ed. note: or "distributed object" or "mediated" ] but XML-based services, the visibility comes from the fact that XML is the universal meta-format for the data. Intermediaries can be programmed or configured to use the specifics of the SOAP XML format, standardized SOAP headers (e.g. for encryption, digital signature exchange, access control, etc.), or even generic XPath expressions to make routing, filtering, and cacheing decisions. XML-aware firewall and other "edge appliance" products are just coming to market as of this writing.
1.7 Web Service 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 provides one illustration of some of these technology families.
Figure 3: Stack Diagram.
Marketing documents from Web services vendors often contain a three-part diagram to show how the different Web services "standards" relate to one another: WSDL describes the format SOAP messages, and UDDI serves as a discovery service for the WSDL descriptions. The problem with such diagrams is that they don't convey the multiple dimensions of the Web services standards "space" and can't easily be extended to handle new standards, e.g. for security, management, choreography, and so on. In order to show the big picture of the Web services architecture as we envision it, the picture needs to be somewhat more complex.
First and foremost, XML is the "backplane" of the WSA. One can imagine Web services that don't depend on the SOAP envelope framework or processing model, or that don't employ WSDL to describe the interaction between a service and its consumers, but XML is much more fundamental. It provides the extensibility and vendor, platform, and language neutrality that is the key to loosely-coupled, standards-based interoperability that are the essence of the Web services value proposition. Furthermore, XML helps blur the distinction between "payload" data and "protocol" data, allowing easier mapping and bridging across different communications protocols, which is necessary in many enterprise IT infrastructures that are built on industrial-strength but proprietary components. Thus, the "base technology" of the WSA consists of some key XML specifications, including XML 1.x, XML Schema Description Language and the xml:base specification. Note that we do not rely on all XML technologies; for example, we do not rely on XML DTDs, in the architecture.
This leads to the next key concept in the WSA: services are invoked and provide results via messages that must be exchanged over some communications medium. The WSA encompasses a wide, almost infinite variety of communications mechanisms: HTTP (the dominant protocol of "the Web"), other internet protocols such as SMTP and FTP, generic interface APIs such as JMS, earlier distributed object protocols such as IIOP, and so on. In principle, Web services invocation and result messages could be passed around by "sneakernet", RFC 1149-compliant carrier pigeons, or mechanisms that have not yet been invented. WSA says almost nothing about this communication layer other than it exists -- it does not specificy that it be at any particular level of the OSI reference architecture protocol stack, and allows Web services messages to be "tunnelled" over protocols designed for another purpose.
WSA does have quite a bit to say about the messages themselves, if not about the mechanism by which they are communicated. SOAP is the key messaging technology in the WSA: While very simple information transfer services can be implemented without SOAP, secure, reliable, multi-part, multi-party and/or multi-network applications are much easier to build if there is a standard way of packaging the messaging information in a protocol neutral way. This also allows the messaging infrastructure (which may be specialized hardware, SOAP intermediaries, or code libraries called by the ultimate recipient of a SOAP message) to provide authentication, encryption, access control, transaction processing, routing, delivery confirmation, etc. services. SOAP's envelope (and attachment) structure and header / processing model have proven to be a very robust and powerful framework within which to do this.
Interoperability across heterogenous systems requires a mechanism to allow the precise structure and data types of the messages to be commonly understood by Web services producers and consumers. WSDL is an obvious choice today as the means by which the precise description of Web services messages can be exchanged.
| Editorial note | |
|
Obviously we have open issues with respect to whether description mechanisms such as shared code "qualify" here.
|
In the future, more sophisticated description languages that handle more of the *semantic* content of the messages are likely to become technologically viable, and such languages (perhaps based on RDF and OWL) will fit well in the WSA framework.
Beyond the description of individual messages such as WSDL provides, the WSA envisions a variety process descriptions: the process of discovering service descriptions that meet specified criteria, the process of describing multi-part and stateful sequences of messages, the aggregation of processes into higher-level processes, and so on. This area is much much clearly defined than other parts of the WSA, but there is much work going on and the WSA incorporates them at an abstract level.
In addition to specific messaging and description technologies, the architecture also provides for security and management. These are complex areas that touch on many of the different levels and technologies deployed in the service of Web services.
2 Core Concepts and Relationships
2.1 Introduction
The formal core of the architecture is this enumeration of the core concepts and relationships that are central to Web services' interoperability.
Each concept is presented in a stylized regular way: consisting of a short summary, an enumeration of the relationships with other concepts, and a slightly longer description. For example, the concept for agent includes as relating concepts the fact that an agent is a computational resource, has an identifier and an owner. The description part of the agent explains in more detail why agents are important to the archicture.
The ordering of the concepts in this section is alphabetical; this should not be understood to imply any relative importance. For a more focused viewpoint the reader is directed to the Stakeholder's perspectives section which examines the architecture from the perspective of key stakeholders of the architecture.
The reason for choosing an alphabetical ordering is that, inevitably, there is a large amount of cross-referencing between the concepts. As a result, it is very difficult, if not misleading, to choose a non-alphabetic ordering that reflects some sense of priority between the concepts. Furthermore, the `optimal ordering' depends very much on the point of view of the reader. Hence, we devote the Stakeholders perspectives section to a number of prioriterized readings of the architecture.
A primary function of this section is to give guidance as to conformance to the architecture. For example, the architecture notes that a message is a unit of interaction between software agents. This means that the architecture is not concerned about messages between objects that are within an implementation of a Web service. We also state that messages have a message sender; any realization of this architecture that does not permit a message to be associated with its sender is not in conformance with the architecture.
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 absence of such a concrete feature may not prevent interoperability; but it will certainly make such interoperability more difficult.
Figure 4, below, illustrates graphically many of the concepts and relationships enumerated below. This diagram will hopefully aid the reader in traversing the concepts and relationships' enumeration.
[Figure 4: Core Concepts and Relationships] 
2.2 Alphabetical List of Core Concepts
The architecture is enumerated as a set of conceptsand their relationships.
The core concepts that form the architecture are laid out in
this section.
2.2.1 Agent
2.2.1.1 Summary
An agent is a
program acting on behalf of another person, entity, or process [Web
Arch].
2.2.1.3 Description
Agents are programs that engage in some set of actions as representatives of other entities. On the Web, for example, agents can seek information. Agents implement services.
Agents are the computational representatives of legal entities. This architecture specifically eschews any attempt to govern the implementation of agents; it is only concerned with ensuring interopability between systems.
2.2.2 Authentication
2.2.2.1 Summary
Authentication is the process of verifying that a potential partner in a conversation is capable of representing a principal or legal entity
2.2.2.2 Relationships to other elements
- Authentication is
a feature of the architecture
- Authentication may be realized
using a security authority
2.2.3 Choreography
2.2.3.1 Summary
Choreographies define how multiple web services are used together, specifying the linkages and usage patterns involved. The linkages between Web Services consist of interactions between those services implemented by sending messages between those Web Services, for example by invoking operations as defined in WSDL [15].
2.2.3.3 Description
A single web service is limited to accepting a request for information or the execution of a process and providing the information or process results in return. Richer functionality can be provided when multiple web services are used together.
A choreography definition describes the sequence and conditions which control how the interactions occur. Successful execution of a choreography should result in the completion of some useful function, for example: the placement of an order, information about its delivery and eventual payment.
Defining the possible patterns of interactions between services does not itself construe a composite service; however, a composite service requires a definition in terms of the choreography of a set of services.
A choreography is not to be confused with orchestration. Orchestration is a technique for realizing choreographies, but is not the only such method.
2.2.4 Choreography Description Language
2.2.4.1 Summary
A Choreography Description Language is a notation for describing the higher levels of interaction between a group of services. It may also permit the specification of a composite service in terms of component services.
2.2.4.2 Relationships to other elements
- A choreography Description Language describes
the pattern of possible interactions between a set of services
- A choreography Description Language may describe
the life cycle of a service invocation
- A choreography Description Language describes
the conversations possible between service requesters and service providers.
2.2.4.3 Description
A Choreography description language is focussed on enabling the description of how to interact with services at a larger scale than the individual message exchange pattern. It permits the description of how Web services can be composed, how roles and associations in Web services can be established, and how the state, if any, of composed services is to be managed.
2.2.5 Correlation
2.2.5.1 Summary
Correlation [n.] is the association of matching messages. Correlation ensures that the agent requesting a service execution can match the reply with the request, especially when multiple replies may be possible.
A message identifier is a piece of information that is used to establish a relationship between one or more messages. A conversation identifier is used to establish a relationship between one or more parties that may exchange multiple messages.
2.2.5.2 Relationships to other elements
- Correlation is
a feature
- Correlation is
a means of associating a message in a specific conversational context.
- Message correlation may be realized
by including message identifiers to enable messagesto be identified.
2.2.5.3 Description
Correlation, specifically message correlation, refers to the ability to identify a given message as being the message for a particular purpose. In a conversation, it is important to be able to determine that an actual message that has been received is the expected message. Often this is implicit when conversations are relayed over stream-oriented message transports; but not all transports allow correlation to be established so implicitly.
For situations where correlation must be handled explicitly, one technique is to associate a message identifier with messages. The message identifier is an identifier that allows a received message to be
correlated with the originating request. The sender may also add an identifier for a service, not necessarily the originating sender, who will be the recipient of the message (see asynchronous messaging).
Correlation may be realized by the underlying protocol; it may be realized by an intermediary between the protocol and the application, ie specification of a conversation ID header; or it may be realized by the application. Application uses the identifier directly and it must be passed through and available to the application. The need for the application to do that depends on how much infrastructure intermediary software is present or not present.
2.2.6 Deployed element
2.2.6.1 Summary
A deployed resource is a resource that exists in the physical world. There are many kinds of deployed elements, including agents, services and descriptions.
2.2.6.2 Relationships to other elements
- A deployed element is
a physically existing resource
- A deployed element has
an owner
- A deployed element has
a physical location, such as a file in a computer or a process executing on a computer.
- A deployed element may realize
a service
- A deployed element may be
a service description
- A deployed element may be
a managed element
2.2.6.3 Description
Deployed elements are resources that exist physically and are potentially manageable. They are the realization of other elements of this architecture — the services, the agents and the descriptions that form the logical aspect of this architecture.
Deployed elements have locations and a physical presence in the real world — for example, as a set of files on a disk, or an executing process on a computer.
Deployed elements are the unit of manageability; they have owners and may have other properties that are subject to management.
2.2.7 Discovery
[dbooth should edit this one]
[EN: The diagram does not include this concept, maybe point to David Booth's text, instead of defining it here? Do we really need to define the act of discovery as a core concept, when we are defining registry and description as core concepts?]
2.2.7.1 Summary
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. [17]
2.2.7.2 Relationships to other elements
discovery
is an abstract process
discovery
may be initiated by an end user or an
agent
discovery
may
be realizedas a discovery
service
discovery
may
be realizedas a direct
interaction between service requesterand service provider
discovery
has inputs a set of functional
criteria
discovery
has outputs a set of service
descriptions that match the inputs
2.2.7.3 Description
There are varius means by which discovery can be performed.
Various entities, e.g. human end users or agents may initiate
discovery. Service requesters may find services and obtain binding
information (in the service descriptions) during development for
static binding, or during execution for dynamic binding. For
statically bound service requesters, using service discovery is
optional, as a service provider can send the description directly
to service requesters. Likewise, service requesters can obtain a
service description from other sources besides a service registry,
such as a local file system, FTP site, URL, or WSIL document.
2.2.8 Discovery Service
2.2.8.1 Summary
A discovery service is a service that performs discovery; of particular interest are discovery services that permit the discovery of Web services.
2.2.8.2 Relationships to other elements
- A discovery service is
a service
- A discovery service is used to
publish service descriptions
- A discovery service is used to
search for service descriptions
- A discovery service may be accessed
automatically or under human guidance
2.2.8.3 Description
A discovery service is used by agents and service owners to publish and search for service descriptions.
The discovery of a service takes place at different times in the overall life-cycle of a service. At one extreme, discovery is vestigial as a new service may be built directly in terms of an existing service; at the other extreme, a service requester dynamically searches for a service provider that may fulfil its requirements immediately prior to the actual service initiation.
2.2.9 Feature
2.2.9.1 Summary
A feature is a subset of the architecture that relates to a particular requirement or larger scale property. A key aspect of features is that they may have realizations, possibly within the architecture itself.
2.2.9.3 Description
A feature is a subset of the architecture that relates to a particular requirement of the architecture. It may be realizedthrough a number of mechanisms, such as bindings, message exchange patternsor modules.
For example, message correlation is a feature of the architecture. The requirement is to be able to associate a message with a particular context. Message correlation may be realized in one of several ways:
2.2.10 Identifier
2.2.10.1 Summary
An identifier is a preferably opaque string of
bits that may be used to associate with a resource
2.2.10.2 Relationships to other elements
- an identifier is
an opaque string of bits
- an identifier may be realized
a URI
- an identifier identifies
a resource that is relevant to the architecture
2.2.10.3 Description
Identifiers are used to identify resources. In the architecture we use Uniform Resource Identifiers [1] to identify resources.
We have a strong preference that any concrete realization of identifiers does not exhibit any structure. The reason is that an identifier's primary role is to permit multiple references to a resource to be viewed as equivalent.
An opaque string means, in this context, that identifies do not have a structure that is discernible to an outside observer. However, identifiers MAY have internal structure that is relevant to the originator of the identifier; for example, an identifier in a challenge-response interchange may be opaque to the responder but not to the challenger.
2.2.11 Intermediary
2.2.11.1 Summary
An intermediary is a message processing node that does not necessarily represent the message's intended recipient; but which, none-the-less processes some aspect of the message.
2.2.11.2 Relationships to other elements
- an intermediary is
a agent
2.2.11.3 Description
Intermediaries process messages that are intended for other recipients. An intermediary may act as a gateway to bridge transport services, or may process specific aspects of messages (such as security information).
2.2.12 Legal Entity
2.2.12.1 Summary
A legal entity such as a person or a corporation may be the owner of agents that provide or request Web services.
2.2.12.2 Relationships to other elements
- a legal entity may be
the owner of an agent
- a legal entity has
a presence in the physical domain
- a legal entity has
a physical address
- a legal entity may agree to
to a legally binding contract
- a legal entity has
a name
2.2.12.3 Description
Legal entities are represented by agents and Web services.
Legal entities are individuals (i.e., humans) and organizations. Both are legal entities in that they have the right to enter into contracts -- which is the critical property from the perspective of this architecture.
From a architectural perspective, the key difference between an individual and an organization is that the former has no owner or shareholders, and that all actions are ultimately rooted in the actions of humans.
2.2.13 Life cycle
2.2.13.1 Summary
A life cycle is a set of states and transition paths for an element.
2.2.13.2 Relationship to other elements
- a life cycle is
the set of externally observable states that an entity can be in, together with the transitions between them.
- a Web service may have
an explicit description of its life cycle
- a life cycle of a service may be managed
by a manager
- a life cycle of a service may be described
in a manageability interface
2.2.13.3 Description
The life cycle of a Web service is a key target for Web service management capabilities.
2.2.14 Management capability
2.2.14.1 Summary
Management capabilities are the capabilities required by a manager to be able to effectively manage.
2.2.14.3 Description
The key managability capabilities include the ability to identify a manageable element, the ability to acquire status information about a manageable element, the ability to configure it and the ability to control its life-cycle.
2.2.15 Management configuration
2.2.15.1 Summary
A management configuration is a collection of properties of a manageable elements which may be changed.
2.2.15.2 Relationship to other elements
- a management configurationis
a set of property values that denotes a particular state of a manageable element
2.2.15.3 Description
Setting a property may influence the behavior of a manageable element. Configuration mechanisms that are common for each type of manageable element [e.g. Web service endpoint] should conform to the Web services architecture [e.g. description and interaction]. Configuration for a manageable element, beyond the common configuration, should be defined by an administrative interface.
2.2.16 Management event
2.2.16.1 Summary
Events are changes in the state of a manageable element that are relevant to the element's manager.
2.2.16.2 Relationship to other elements
- a management event is
an event that denotes an event associated with a manageable element that is relevant to a manager.
- a problem event is
a management event
- a life-cycle event is
a management event
- a state change event is
a management event
- a request processing event is
a management event
2.2.16.3 Description
Event descriptions are messages that indicate a problem, a lifecycle state change, or a state change. For a manageable element there are two classes of events: State Changed and Request Processing events. State change events occur whenever lifecycle state transitions happen. A request processing event description indicates that the state of a request has been changed and should include the previous state and the transition time. The event may also include any context associated with the request, reply, or failure message and any part or the complete content of these messages. Event descriptions provide valuable information for managers and can be used to calculate many of the metrics.
2.2.17 Manager
2.2.17.1 Summary
A manager is an entity that is capable of and has an interest in managing manageable elements.
2.2.17.3 Description
A manager is an agent that is able to manage a set of manageable elements and has the interest and authority in so doing. Managers use the manageability capabilities and interfaces to control the life cycle and other properties of manageable elements on behalf of the owners of those elements.
A manager may have additional capabilities than those within the scope of this architecture; for example, a manager may be able to directly control the computational resources that are used to offer Web services. This architecture focuses on those aspects of management that are central to Web services.
2.2.18 Manageable Element
2.2.18.1 Summary
A manageable element is a deployed element that is manageable. I.e., a physically existing resource that is capable of being managed. A key attribute of manageable elements is that they provide an interface to allow their management.
2.2.18.3 Description
Manageable elements expose an interface that permits their state — especially their life cycle state to be monitored and potentially modified. The simplest such modification being to delete the element.
There are many potentially manageable elements in this architecture, including services, agents and descriptions as well as discovery providers and service requesters and providers.
As with Web services themselves, manageable elements may also be discovered using similar mechanisms. It is expected that discovery of manageable elements would permit managers to determine if an element is manageable.
2.2.19 Manageability Interface
2.2.19.1 Summary
A manageability interface is a description of the means by which a management system can manage a manageable element.
2.2.19.2 Relationships to other elements
- a manageability interface has
controls
- a manageability interface has
identification information
- a manageability interface has
events that correspond to the life cycle of a manageable element
- a manageability interface has
metrics
- a manageability interface has
status
- a manageability interface has
configuration controls
2.2.20 Management metric
2.2.20.1 Summary
Management metrics are raw atomic unambiguous information. For manageability metrics, the information is for managmement purposes.
2.2.20.2 Relationship to other elements
- a manageability metricis
a raw atomic point of data
2.2.20.3 Description
The value of the metric captures the information at a point in time. Generally these values are numeric, but may be strings as well. This can be contrasted with Measurements that are calculated with a formula based on metrics, e.g. Average response time during the last hour of execution. The metrics requirements do not enforce any implementation pattern. A managed element should allow any available metrics and measurements to be reported according to configurable time intervals, such as cumulative, sliding window, and interval. A managed element must declare which interval types are supported.
2.2.21 Message
2.2.21.1 Summary
A message is the basic unit of interaction with Web services. The architecture defines an interaction between software agents as an exchange of messages.
2.2.21.3 Description
A message is defined as a construct that can include zero or more headers, an envelope, data within the envelope and data external to the envelope. The header part of a message can include information pertinent to extended Web services functionality, such as security, transaction context, orchestration information, or message routing information. The data part of a message contains the message content or data.
A message represents the data structure passed to a service during its request, and received from a service during its response (if any). The structure of messages are defined in service descriptions.
2.2.22 Message Exchange Pattern (MEP)
2.2.22.1 Summary
A message exchange pattern is a minimal set of messages, together with their sender and receivers, that constitutes a single use of a service.
2.2.22.3 Description
A Message Exchange Pattern (MEP) is a template that establishes a pattern for the exchange of messages between agents
Requesters and providers interact using one or more message exchange patterns (MEPs) that define the sequence of one or more messages exchanged between them. A service descriptionincludes a description; such as the form of the message, data types of elements of the message and message structure information.
The architecture describes Web services support for MEPs that group basic messages into higher-level interactions.
2.2.23 Message Header
2.2.23.1 Summary
A message header is the part of the message that is available to any potential intermediaries and contains information about the message, such as its structure and the identity of the service provider.
2.2.23.3 Description
The header part of a message can include information pertinent to extended Web services functionality, such as security, transaction context, orchestration information, or message routing information.
2.2.24 Message description language
2.2.24.1 Summary
A message description language allows the structure of messages to be described.
2.2.24.2 Relationships to other elements
- a message description language describes
the structure of a message
2.2.24.3 Description
A message description language allows the formal structure of messages to be described, including the types of elements of the message, how recipients and senders are identified and which headers are associated with messages.
2.2.25 Message Identifier
2.2.25.1 Summary
A message identifier is an identifierthat uniquely identifies a message.
2.2.25.2 Relationships to other elements
- a message identifier is
a unique identifier
- a message identifier identifies
a message
2.2.25.3 Description
A message may have an identifier. In the context of Web services we use URIs to represent message identifiers. Message identifiers allow messages to be correlatedwithin an extended transaction; for example, an event message may reference the
original subscription request message.
Message identifiers also support message reliabilityand management and accountabilityof services:
by providing the means to uniquely identify messages in an audit
trail.
2.2.26 Message recipient
2.2.26.1 Summary
A message recipient is an agent that is intended — by the message's sender — to consume the message.
2.2.26.2 Relationships to other elements
- a message recipient is
a agent
2.2.26.3 Description
The message recipient is the agent that the sender intends the message to be consumed by. The message recipient of an agent may be represented as the agent's identifier in a message envelope; however, in the case of anonymous or broadcast-style interactions, the recipient of a message may not be available to the sender.
In general, a message may be intended for more than more than one recipient. Furthermore, in some cases, the sending agent may not have direct knowledge of the identity of the message recipient (for example, in multi-case situations or in the case anonymous interactions with a service provider.)
Messages may also be passed through intermediaries that process aspects of the message; typically by examining the message headers. The sending agent may or may not be aware of such intermediaries.
2.2.27 Message sender
2.2.27.1 Summary
A message sender is the agent that originates a message.
2.2.27.2 Relationships to other elements
- a message sender is
a agent
2.2.27.3 Description
A message sender is the agent that originally caused a new message to be created and sent to an agent. The message sender of an agent may be represented as the agent's identifier in a message envelope; however, in the case of anonymous interactions the originator of a message may not be available.
2.2.28 Reliable messaging
2.2.28.1 Summary
Reliable messaging is a feature that represents a key infrastructure-level notion of reliability.
2.2.28.2 Relationships to other elements
- reliable messaging is
a feature
- reliable messaging may be realized by
a combination of message acknowledgement and correlation.
2.2.28.3 Description
Reliable messaging is an important contributory factor to the overall reliability of Web services. The goal of reliable messaging is to both reduce the the error frequency for interactions and, where errors occur, to provide a greater amount of information about either successful or unsuccessful attempts at message delivery.
Reliable messaging may be realized with a combination of message receipt acknowlegment and correlation. In the event that a message has not been properly received, the sender may attempt a resend, or some other compensating action. Note that in a distributed system, it theoretically not possible to guarantee correct notification of delivery; however, in practice, simple techniques can greatly increase the overall confidence in the message delivery.
Message correlation may be used by the receivers of messages to ensure that messages are only acted on once - with duplicate messages being ignored or treated as errors.
2.2.29 Representation
2.2.29.1 Summary
A representationis
a data object that denotes a resource state, and is the vehicle for conveying the meaning of a resource. A resource is an abstraction for which there is a conceptual mapping to a (possibly empty) set of representations.
2.2.29.2 Relationships to other elements
- a representation is
a data object
- a representation denotes
the state of a resource
2.2.29.3 Description
Representations are data objects that denote the state of a resource. A resource has a unique identifier, whereas a representation is a data object that represents the resource itself. Note, that a representation of a resource need not be the same as the resource itself; for example the resource asociated with the booking state of a restaurant will have different representations depending on when the representation is retrieved.
Resources have identifiers but cannot be retrieved — representations of resources may be retrieved but are typically not themselves resources.
2.2.30 Resource
2.2.30.1 Summary
A resource is defined by [RFC2396] to be
anything that has an identifier.
2.2.30.3 Description
Resources form the heart of the Web architecture itself — the Web is a universe of resources that have URIs as identifiers, as defined in [RFC2396].
2.2.31 Service
2.2.31.3 Description
A service is a collection of related tasks that form a coherent whole, from the point of view of service providers and requesters. Critically, services have descriptions that may be formally expressed in one or more service description languages.
The concept of a service is distinct from the software agent that provides the service (and the software agent that requests it). A service refers to the actions performed by the agents rather than the agents themselves.
In the case of atomic or simple services, a service is provided through the actions of a single (possibly federated) software agent. In the case of a composite service, the service is provided through the collaboration of a collection of agents. In this latter case, it may not be obvious which software agent is providing the service — either to the requester of a service or even to the agents providing the service.
A service has an identifier, which in this architecture is a URI. However, the service's identifier should not be construed as identifying any of the agents that perform the tasks offered by the service.
The service description defines the functionality of a service, the service semantics and
the interface of the service, i.e how to interact with the service.
The semantics of a service is expressed in terms of the tasks that are performed by the service.
In a Service Oriented Architecture, the description of a service's interface is expressed in terms of the messages that may be exchanged between service providers and requesters.
Issue (service_uri):
What is identified with a service identifier?
Source:
The Web services architecture builds directly upon the Web
Architecture [7]. As such, the Web services architecture directly leverages the definition of, and architectural constraints placed on, identifiers from the Architecture Principles of the Web[7].
URIs MUST be used to identify all conceptual elements of the system (see Web Services Architecture Requirements: AR009.3).
However, it is not clear what is referenced by a service identifier; is it the service end-points, the service description, the agent?. None of these seems definitive.
Resolution:
None recorded.
2.2.32 Service description
2.2.32.1 Summary
A service description is a set of documents that describe the interface to and semantics of a service.
2.2.32.3 Description
A service description contains the details of the interface and implementation of the service. This includes its data types, operations, binding information, and network location. It could also include categorization and other meta data to facilitate discovery and utilization by requesters. The complete description may be realized as a set of XML description documents.
There are many potential uses of service descriptions, they may be used to facilitate the construction and deployment of services, they may be used by people to locate appropriate services and they may be used by service requesters to automatically discover appropriate providers in those case where requesters are able to may suitable choices.
2.2.33 Service provider
2.2.33.3 Description
The service provider is the agent, i.e., computational entity, that provides a service.
A given service may be offered by more than one agent, especially in the case of composite services, and a given service provider may offer more than one service.
2.2.34 Service requester
2.2.34.1 Summary
A service requester is the entity that is responsible for
requesting a service from a service
provider.
2.2.34.3 Description
The service requester is the entity that requires a certain function to be satisfied. From an architectural perspective, this is the agentthat is looking for and invoking or initiating an interaction with a service.
2.2.35 Service semantics
2.2.35.1 Summary
The semantics of a service is the contract between the service providerand the service requesterthat expresses the effect of invoking the service. A service semantics may be formally described in a machine readable form, identified but not formally defined or informally defined via an `out of band' agreement between the provider and the requester.
2.2.35.3 Description
Knowing the type of a data structure is not enough to understand the intent and meaning behind its use. For example, methods to deposit and withdraw from an account typically have the same type signature, but with a different effect. Semantics in web services provide formal documentation of meaning. Contracts describing semantics may be used in other web service features such as choreography.
The semantics of a service is fundamentally about the tasks that are encapsulated in the service. A given service may encapsulate a number of different tasks, each task consists of a goal and a process or action for achieving the goal.
2.2.36 Service Task
2.2.36.1 Summary
A service task is a unit of activity associated with a service. It is denoted by a pair: a goal and an action; the goal denotes the intended effect of the task and the action denotes the process by which the goal is achieved.
2.2.36.2 Relationships to other elements
- a service task has
a goal that represents the intended effect of the task
- a service task has
one or more actions that should result in the goal being achieved.
2.2.36.3 Description
A task is an abstraction that encapsulates the intended effect of invoking a service.
A task is associated with a goal — a predicate that should be satisfied on successful completion of the task
A task is associated with a procedure (or action) that is used to achieve the task.
The actions associated with a task may be public, as in the exchange of messages between service providers and requesters; or it may be private, as in the calculation of a formula or in the update of a shared resource. In the case of a service oriented architecture only the public aspects of a task are important, and these are expressed entirely in terms of the messages exchanged.
2.2.37 SOAP
2.2.37.1 Summary
SOAPis a simple
and lightweight XML-based mechanism for creating structured data packages that can exchanged between network applications.
2.2.37.2 Relationships to other elements
- SOAP is
An example of implementation technology for expressingthe structure of messages
- a SOAP package has
an envelope
- a SOAP package has
a set of encoding rules for expressinginstances of application-defined data types.
- a SOAP package has
an envelope
- a SOAP package has
a convention for representing the exchange of messagesand responses.
- SOAP has
a set of rules for using SOAP with HTTP.
- SOAP may be used with
other message delivery protocols.
2.2.37.3 Description
SOAP consists of four fundamental components: an envelope that
defines a framework for describing message structure, 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. SOAP
can be used in combination with a variety of network protocols;
such as HTTP, SMTP, FTP, RMI/IIOP, or a proprietary messaging
protocol.
SOAP is currently the de facto standard for XML messaging for a
number of reasons. First, SOAP is relatively simple, defining a
thin layer that builds on top of existing network technologies such
as HTTP that are already broadly implemented. Second, SOAP is
flexible and extensible in that rather than trying to solve all of
the various issues developers may face when constructing Web
services, it provides an extensible, composable framework that
allows solutions to be incrementally applied as needed. Thirdly,
SOAP is based on XML. Finally, SOAP enjoys broad industry and
developer community support.
The format of a SOAP message is formally defined in the SOAP1.2 Part 1: Messaging Framework specification. However, SOAP is much more than simply a message format; it also provides a simple framework for extensible messages and message processing.
One special type of SOAP Feature is the Message Exchange
Pattern (MEP). A SOAP MEP is a template that establishes a pattern for the exchange of messages between SOAP nodes. Examples of MEPs include: request/response, oneway, peer-to-peer conversation, etc. A MEP MAY be supported by one or more underlying protocol binding instances either directly, or indirectly with support from software that implements the required processing to support the SOAP Feature as expressed as a SOAP Module.
2.2.38 WSDL
2.2.38.3 Description
WSDLis an XML
document format for describing Web services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented (RPC) messages.
WSDL describes Web services starting with the messages that are
exchanged between the service provider and requester. The messages themselves are described abstractly and then bound to a concrete network protocol and message format.
WSDL is sufficiently extensible to allow description of
endpoints and their messages regardless of what message formats or
network protocols are used to communicate. WSDL1.1 describes
bindings for SOAP1.1, HTTP POST, and MIME. WSDL1.2 will add binding
support for SOAP1.2.
Web service definitions can be mapped to any language, 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.
Both the sender and receiver of a Web services message must have access to the same service description. The sender needs the service description to know how to format the message correctly and the receiver needs the service description to understand how to receive the message correctly.
As long as both the sender and receiver have the same service description, (e.g. WSDL file), the implementations behind the Web services can be anything. Web services typically are implemented using programming languages designed for interaction with the web, such as Java Servlets or Application Server Pages (ASPs) that call a back-end program or object. These Web service implementations are also typically represented using a Web services description language.
2.3 Relationships
The relationships between concepts in the architecture are laid out in this section. These relationships represent the core modeling concepts used in the architecture itself.
2.3.1 The is a relationship
2.3.1.1 Summary
The X is a Y relationship denotes the relationship between concepts X and Y, such that every X is also a Y.
2.3.1.2 Relationships to other elements
Assuming that X is a Y, then:
- true of
if P is true of Y then P is true of X
- contains
if Y has a P then X has a Q such that Qis a P.
- transitive
if P is true of Y then P is true of X
2.3.1.3 Description
Essentially, when we say that concept X is a Y we mean that every feature of Y is also a feature of X. Note, however, that since X is presumably a more specific concept than Y, the features of X may also be more specific variants of the features of Y.
For example, in the service concept, we state that every service has an identifier. In the more specific Web service concept, we note that a Web service has an identifier in the form of a URI identifier.
2.3.2 The describes relationship
2.3.2.1 Summary
The concept X is described by Y relationship denotes that Y is an expression of some language L and that the value of Y is an instances of X.
2.3.2.2 Relationships to other elements
Assuming that X is described by Y, then:
- valid
if Y a valid expression of L, then the value of Y is an instance of concept X
2.3.2.3 Description
Essentially, when we say that concept X is described by Y we are saying that the expression Y denotes instances of X.
For example, in the service description concept, we state that service descriptions are expressed in a service description language. That means that we can expect legal expressions of the service description language to be instances of the service description concept.
2.3.3 The is expressed in relationship
2.3.3.1 Summary
The concept X is expressed in L relationship denotes that instances of X are values of the language L.
2.3.3.2 Relationships to other elements
Assuming that X is expressed in L, then:
- valid
if E a valid expression in L then E is an instance of concept X
2.3.3.3 Description
When we say that concept X is expressed in L we use the language L to express instances of X.
For example, in the service description concept, we state that service descriptions are expressed in a service description language. That means that we can expect legal expressions of the service description language to be instances of the service description concept.
2.3.4 The has a relationship
2.3.4.1 Summary
The concept X has a Y relationship denotes that every instance of X is associated with an instance of Y.
2.3.4.2 Relationships to other elements
Assuming that X has a Y, then:
- valid
if E is an instance of X then Y is valid for E.
2.3.4.3 Description
When we say that concept X has a Y we mean that whenever we see an X we should also see a Y
For example, in the Web service concept, we state that Web services have URI identifiers. So, whenever we the Web service concept is found, we can assume that the Web service referenced has an identifier. This, in turn, allows implementations to use identifiers to reliably refer to Web services. If a given Web service does not have an identifier associated with it, then the architecture has been violated.
2.3.5 The realized relationship
2.3.5.1 Summary
The concept X is realized as Y relationship denotes that the concept X is an abstraction of the concept Y. An equivalent view is that the concept X is implemented using Y.
2.3.5.2 Relationships to other elements
Assuming that X is realized as Y, then:
- implemented
if Y is present, or true of a system, then the concept X applies to the system
- reified
Y is a reification of the concept X.
2.3.5.3 Description
When we say that the concept or feature X is realized as Y, we mean that Y is an implementation or reification of the concept X. I.e., if Y is a valid concept of a system then we have also ensured that the concept X is valid of the same system.
For example, in the correlation feature, we state that message correlation requires that we associate identifiers with messages. This can be realized in a number of ways — including the identifier in the message header, message body, in a service binding and so on. The message identifier is a key to the realization of message correlation.
3 Stakeholder's perspectives
In this section we examine how the architecture meets the Web
services requirements. We present this as a series of stakeholders' viewpoints; the objective being that, for example, security represents a major stakeholder's viewpoint of the architecture itself.
| Editorial note | |
| When developing a particular stakeholder's viewpoint, one should
make sure that the concepts discussed are properly documented in
the architecture. |
3.1 Web integration
Goal AG003 of the requirements identifies
Web services must be consistent with the current and evolving
nature of the World Wide Web.
This goal can be divided into two sub-goals — relating to
the architectural
principles of the Weband, more pragmatically, relating the
architecture to the various technologies in use.
Critical Success Factor AC011notes that the
architecture should be consistent with the architectural principles
and design goals of the Web. For our purposes we use the
Architecture of the
World Wide Webas our reference for the architecture of the
Web.
This identifies the
architecture of the Web to be founded on a few basic concepts:
agents that are programs that represent people, identification of
resources using URIs representations of resources as data objects
and interaction via standard protocols — most notably of
course HTTP.
3.2 Information and service
Unlike the World Wide Web in general, it is of the essence that Web services, like service oriented architectures in general, are essentially about the provision of action. I.e., whereas the World Wide Web is a networked information system, the Web service World Wide Web is a networked service system: information is exchanged between Web service agents for the purpose of requesting and provisioning service, not simply information.
This is a key specialization of the World Wide Webin general; and it drives a number of the specific features of this architecture. However, it is also the ca