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.
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 case that requests for action and the various possible responses are also information and have representations.
The key representational requirement of this architecture is that messages exchanged between Web service agents is encoded in XML. This is consistent with the general principles of the World Wide Web.
3.3 Web service agents
This architecture also uses the concept of an agentto identify the computational resource actually involved with Web services. The key properties of agents required to model Web services are that:
It is a computational activity
It has an owner
It engages in message exchanges with other Web service agents,
those messages counting as equivalent messages between the agents'
owners.
It uses standard protocols to:
describe the form and semantics of messages
describe the legal sequences of messages
The distinction between a service requester and service provider is one of the agent's roles; i.e., it is not intrinsic to the concept of agent that it is bound to be solely a provider or requester of services. Of course, in many cases, particular agents will be bound to particular functions that will fix the role of the agent to be a service provider or requester.
However, it is clear that there is a strong correspondence between a Web service agent and a Web agent. Both are computational resources that represent people; our definition requires sufficient detail to be able to account for the greater degree of indirection expected between Web service agents and Web agents.
3.4 Web Service Discovery
Based on Web Services Architectural Roles
Before a requester agent and a provider agent can interact, the corresponding enties that own them must first agree on the service description and semantics that will govern the interaction, as depicted in Figure 1. There are many ways this can be achieved. Some require discovery, others don't.
3.4.1 Scenarios Not Requiring Discovery
If the requester and provider entities are already known to each other, then one common way for them to agree on the service description and semantics is for a requester human and a provider human to communicate directly. For example, the provider human might send the proposed service description and semantics directly to the requester human. Or the parties might develop them collaboratively. In these situations, there is no need for discovery.
If the provider entity is furnishing the service description unilaterally, then a variation on this approach is for the requester entity to retrieve the service description dynamically from the provider agent, at the start of their interaction, as depicted in Figure 4: Parties Known, Dynamically Getting WSD. This allows the requester agent to be assured of using the latest version that the provider agent supports, again without requiring discovery.
[Figure 5: Parties Known, Dynamically Getting WSD]
[dbooth: The label at the top of this diagram needs to be fixed. It should be "Figure 5" instead of "Figure 2".] 
3.4.2 Scenarios Requiring Discovery
On the other hand, if the requester entity does not already know what provider agent it wishes to engage, then it 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." [17] Two common ways to approach this are human discovery, and autonomous selection.
3.4.2.1 Human Discovery
With human discovery, a requester human uses some kind of discovery tool or agent to help locate a suitable service description, i.e., a description representing a service that meets the desired functional criteria, as shown in Figure 6: Human Discovery.
[Figure 6: Human Discovery]
[dbooth: The label at the top of this diagram needs to be fixed. It should be "Figure 6" instead of "Figure 3".] 
There are several points to note about this situation.
Regardless of how the service description is obtained, somehow the requester and provider entities must agree on the semantics of the planned interaction. There are several ways this can be done, and the WSA does not specify or care what way is used. For example, the provider entity may publish both the service description and semantics on a take-it-or-leave-it basis, which the requester must accept unmodified as a condition of engaging the provider agent. Or the parties could negotiate the desired semantics. Or the semantics might be defined by an industry standards body that both parties have chosen to follow.
Somehow the discovery agent must obtain both the service description (or at least a reference to it), and sufficient information (labeled "SemanticsID" in Figure 6) to describe or identify the semantics of the service that the provider entity offers. The SemanticsID is necessary to allow the requester human to find a service having the desired semantics. In practice, the SemanticsID might be as simple as a few words or a URI, or it may be more complex, such as a TModel (in UDDI) or a collection of RDF, DAML-S or OWL statements.
[dbooth: I'm still looking for a better term than "SemanticsID" in this section. Any ideas? "Semantic description"? "Semantic designator"? ...?]
The WSA also does not specify or care how the discovery agent obtains the service description and SemanticsID. For example, if the discovery agent is implemented as a search engine (such as Google), 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 agent is implemented as a registry (such as UDDI), then the provider entity could publish the service description and SemanticsID directly to the discovery agent.
[dbooth: Need to add mention of the trust decision.]
3.4.2.2 Autonomous Selection
With autonomous selection, the requester agent uses a selection agent to select a service description from among
@@ unfinished @@ [dbooth to fill in this section]
, as shown in Figure 7: Autonomous Selection.
[Figure 7: Autonomous Selection]
[dbooth: The label at the top of this diagram needs to be fixed. It should be "Figure 7" instead of "Figure 5".] 
3.5 Web service semantics
A third major distinction between this architecture and the World Wide Webis that,
for computer programs to be able to interact with other in a meaningful way, it is necessary to model the semanticsof the information exchanged.
So long as the primary purpose of an agent is to render information in a way that is immediately meaningful to human eyes, the semantics of the interactions between agents is essentially straightforward — as is ably captured in the generic HTTP protocol.
However, if an agent is expected to be able to act on information it receives, it becomes necessary to be much more precise as to the intended semantics of the information.
The semantics of the information exchanged between Web service agents is derived from the structure of the messages, the message exchange patterns and conversational patterns between agents. In addition, it is necessary to be precise about
the real-world entities referenced by terms in messages
the expected actions to be undertaken by service providers
the relationship between the owners of the agents acting as
service provider and service requester
This architecture enables this precision by ensuring that the various aspects of the semantics of the information exchanged between agents can be properly identified. Where appropriate, and possible, it also identifies a number of description languages which can be used to describe different semantic aspects of this exchanged information.
An important technology for realizing the description of the semantics of Web services is the Semantic Web. "The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation." -- Tim Berners-Lee, James Hendler, Ora Lassila, The Semantic Web, Scientific American, May 2001.
| Editorial note | |
| More justice needs to be made to the technologies coming out of the Semantic Web effort. |
In summary, Web services can be considered to be a specialization of World Wide Webin general; a specialization that reflects the intended purpose of the exchanged information — to be about services. Similarly, this architecture can be viewed as an elaboration of the general WWW architecture; albeit with a significant number of additional concepts.
3.6 Web services security
3.8 Modularity
The critical success factor AC002focuses on the
modularity of the architecture; with appropriate
granularity. This is reduced to an overall conceptual integrity
with appropriate decomposition and easy comprehension.
Our architecture is laid out using the simple style of
conceptsand relationships. This modeling technique is
simple, and yet allows us to expose the critical properties of
Web services. A major design goal of the architecture has been
the appropriate separation of concerns. In general,
this is achieved by rigorous minimalism associated with each
concept: only associating those properties of a concept that are
truly necessary to meet the requirements.
The overall themes in this architecture can be summarized
as:
Web services are used and presented by agentsinteracting on behalf of real-world actors.
Message structures,
service interfaces, conversationsare first of all explicitly
identified and potentially describedusing using a variety of description
languages. This has the effect of documenting the various aspects
involved in two or more interacting Web services.
Minimal assumptions about required components. For example,
although Web services may be documented, it is not required.
Similarly, although descriptions may be published, that is also not
required.
3.10 Peer to peer interaction
To support Web services interacting in a peer to peer style, the
architecture must support peer to peer message exchange patterns,
must permit Web services to have persistent identity, must permit
descriptions of the capabilities of peers and must support
flexibility in the discovery of peers by each other.
In the message exchange
patternconcept we allow for Web services to communicate with
each other using a very general concept of message exchange.
Furthermore, we allow for the fact that a message exchange pattern
can itself be identified -- this permits interacting Web service
agents to explicitly reference a particular message pattern in
their interactions.
A Web service wishing to use a peer-to-peer style interaction
may use, for example, a publish-subscribe form of message exchange
pattern. This kind of message exchange is just one of the possible
message exchange patterns possible when the pattern is explicitly
identifiable.
In the agentconcept we note that agents
have identifiers. The primary role of an
agent identifier is to permit long running interactions spanning
multiple messages. Much like correlation, an agent's identifier can
be used to link messages together. For example, in a publish and
subscribe scenario, a publishing Web service may include references
to the Web service that requested the subscription, separately from
and additionaly to, the actual recipient of the service.
The agentconcept also clarifies that a
given agent may adopt the role of a service providerand/or a service requester. I.e., these are
roles of an agent, not necessarily intrinsic to the agent
itself. Such flexibility is a key part of the peer to peer mode of
interaction between Web services.
In the serviceconcept we state that
services havea semanticsthat may be identified in a
service descriptionand that may
be expressedin a service description language.
This identification of the semantics of a service, and for more advanced agents the description of the service contract itself, permits agents implementing Web services to determine the capabilities of other peer agents. This is turn, is a critical success factor in the architecture supporting peer-to-peer interaction of Web services.
Finally, the fact that serviceshave
descriptionsmeans that these
descriptions may be published in discovery agencies and also retrieved from
such agencies. In effect, the availability of explicit descriptions
enables Web services and agents to discover each other
automatically as well as having these hard-coded.
3.11 Long running transactions
In CSF
AC017are identified two requirements that support applications
in a similar manner to traditional EDI systems: reliable messaging
and support for long-running stateful choreographed interactions.
This architecture supports transactions by allowing messages to be
part of message exchanges and extended choreographies. It also
permits support for message reliability.
3.12 Conversations
Conversations are supported in this architecture at two levels:
the single use of a Web service and the combination of Web
services.
A message exchange
patternis defined to be the set of messages that makes a single
use of a service. Typical examples of message exchange pattern are
request-response, publish-subscribe and event notification.
The details of the message exchange pattern may be documented in
a service description
expressed in a service
description languagesuch as WSDL.
In addition, the architecture supports the correlationof messages by permitting messages to
have identifiers.
Web services may be combined into larger scale conversations by
means of choreographies. A choreography
is the documentation of the combination of Web services, leaving
out the details of the actual messages involved in each service
invokation and focusing on the dependencies between the Web
services.
Of particular importance, both to individual message exchange
patterns and combined services, is the handling of
exceptions.
3.13 Message reliability
Critical Success Factor AC017 of the requirements notes that the architecture must satisfy the requirements of enterprises wishing to transition from traditional EDI and more specifically AR017.1 requires that the architecture must support reliable messaging.
The goal of reliability 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 service.
In the context of Web services, we can address the issues of reliability at three distinct levels: of reliable and predictable interactions between services, of the reliable and predictable delivery of infrastructure services and of the reliable and predictable behavior of individual service providers and requesters. This analysis is generally separate from concerns of fault tolerance, availability or security, but there may of course be overlapping issues.
The architecture addresses the requirements for the highest level of reliability identified here by accomodating the descriptions of the choreographies of the interactions between Web service requesters, providers. In effect, reliability at this level becomes a measurable property of the descriptions of choreographies: in effect, assuming that the infrastracture is reliable, and assuming that the services are reliable, do the descriptions of the choreographies describe situations which will behave in predictable ways?
The reliability of the individual service providers and requesters is out of scope of this architecture as we do not comment on the realization of Web services. However, reliability at this level is often enhanced by service providers adopting deployment platforms that have strong management capabilities.
The reliability of the infrastracture services refers to the reliability of the messaging infrastructure and the discovery infrastructure; the former is often referred to as reliable messaging. In general, this refers to a predictable quality of service related to the delivery of the messages involved with the Web service.
In more detail, we identify two properties of message sending that are important: the sender of the message would like to be able to determine whether a given message has been received by its intended receiver and that the message has been received exactly once.
Knowing if a message has been received correctly allows the sender to take compensating action in the event the message has not been received. At the very least, the sender may attempt to resend a message that has not been received.
The general goal of reliable messaging is to define mechanisms that make it possible to achieve these objectives with a high probability of success in the face of inevitable but unpredictable network, system and software failures.
The goals of reliable messaging can be made more explicit by considering the issues related to multiple receptions of a message and message intermediaries. If there is an intermediary, does the sender want to know whether the message got to the intermediary or to the intended end recipient? Does the receiver care whether it receives a message more than once? The following classification of reliable messaging expectations is taken from the ebXML Messaging Services.
| Duplicate-Elimination | Ack Requested From End Receiver | Ack Requested from Next Receiver | Comment |
|---|
| 1 | Y | Y | Y | Once-And-Only-Once End-To-End, At Least Once to Intermediate |
| 2 | Y | Y | N | Once-and-only-Once End-to-End based on end-to-end
retransmission |
| 3 | Y | N | Y | At-Least-Once at the intermediate level, Once-and-only-once
end-to-end if all the intermediaries are reliable, no end-to-end
notification |
| 4 | Y | N | N | At-Most-Once end-to-end, no retries at the intermediate
level |
| 5 | N | Y | Y | At-Least-Once with duplicates possible both end-to-end and
at intermediate level |
| 6 | N | Y | N | At-Least-Once with duplicates possible both end-to-end and
at intermediate level |
| 7 | N | N | Y | At-Least-Once to the intermediaries and the end. No
end-to-end notification |
| 8 | N | N | N | Best Effort |
The goals of reliable messaging may also be examined with respect to whether one wishes to confirm only the receipt of a message, or perhaps also to confirm the validity of that message. Three questions may be asked about message validity:
Was the message received the same as the one sent? This may be determined by such techniques as byte counts, check sums, digital signatures.
Does the message conform to the formats specified by the agreed upon protocol for the message? Typically determined by automatic systems using syntax constraints (eg xml well formed) and structural constraints (validate against one or more xml schemas or WSDL message definitions).
Does the message conform to the business rules expected by the receiver? For this purpose additional constraints and validity checks related to the business process are typically checked by application logic and/or human process managers.
Of these, first and second are considered to be part of reliable messaging, the last is partly addressed by Web service choreography.
Message reliability is most often achieved via an acknoweldgement infrastructure, which is a set of rules defining how the parties to a message should communicate with each other concerning the receipt of that message and its validity. WS-Reliability and WS-ReliableMessaging are examples of specifications for an acknowledgement infrastructure that leverage the SOAP Extensibility Model. In cases where the underlying transport layer already provides reliable messaging support (e.g. a queue-based infrastructure), the same reliability Feature can be achieved in SOAP by defining a binding that relies on the underlying properties of the transport.
3.14 Web service manageability
Goal AG007 of the requirements
identifies that manageability of Web services is an important goal
of this architecture. Since the architecture defines how to define information, operations and discovery of Web services, it is consistent to use Web services to provide access to and manageability of Web services also.
Management in this case is defined as a set of capabilities for
discovering the existence, availability, health, and usage, as well
the control and configuration of manageable elements, where these are
defined as Web services, descriptions, agents of the Web services architecture,
and roles undertaken in the architecture.
This architecture does not attempt to specify completely how Web services are managed; that is be the role of a separate specification. The architecture does, however, identify the key concepts and relationships involved in modeling manageability. These key concepts include the manageable element, its management capabilities, the manageability interface and the manager.
For example, an executing Web services agent is a potentially managable element that may require management, as is an actually deployed Web service and the Web service's
service description.
The manager is an agent that has the responsiblity for managing on behalf of its owner and the owners of the resources that it is managing. The manager uses the manageability interface to aquire metrics of managed elements and to manage the configuration, the life cycle, and to monitor the status of those elements. The manager is also a prime recipient of management events.
The key relationship that ensures that the architecture models management appropriately is the realizes relationship. The entities under management — the manageable elements — have a realizes relationship with other elements of the architecture. For example, a Web service is provided by an agent. Both the Web service itself and the agent are realized in some fashion; as are any descriptions of the service; as physically deployed resources, and those deployed resources are themselves potentially manageable.
As with Web services themselves, it may be important for scalability reasons for managers to be able to automatically discover both the manageable elements it may be responsible for and their manageability interfaces.
| Editorial note | |
| Discovery has a management aspect as well as a service aspect. This needs to be made clearer. |
Of course, managers that are deployed in order to help the management of Web services are also potentially subject to management; however, to the extent that such managers are already modeled as Web services, their management will be
handled as any other Web service.
