RE: Proposed text for section 1.6.2 and 1.6.3

This is really becoming quite good, although the nomenclature still seems to me a bit ... labored.

In light of this work, Mike, has the agenda item coming from me that you put early on the F2F become irrelevant?  If it has I will not object to dropping it.

It appears to me, however, that we are moving toward declaring the term "Web service" as being essentially undefined.  I think that this would be a huge disappointment to many and a failure to respond to a fundamental, though perhaps unstated, expectation of most of the stakeholders in the work of this WG.  I believe that we are essentially empowered to define the term, and if we cannot reach a consensus on this we have failed very fundamentally.

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Thursday, May 08, 2003 12:43 AM
To: michael.mahan@nokia.com; Champion, Mike; www-ws-arch@w3.org
Subject: RE: Proposed text for section 1.6.2 and 1.6.3





> -----Original Message-----
> From: michael.mahan@nokia.com [mailto:michael.mahan@nokia.com]
> Sent: Thursday, May 08, 2003 12:12 AM
> To: Mike.Champion@softwareag-usa.com; www-ws-arch@w3.org
> Subject: RE: Proposed text for section 1.6.2 and 1.6.3
> 
> 
>
> The difference I was trying to draw is that REST separates
> the resource 
> REpresentation from the STate change request in the message. 
> API SOA does not. 
> API SOA message markup captures both the representation of 
> the resource/service 
> and the representation of the state change request. 

OK, I follow.   Here's a revised text that incorporates Mike's suggestions
as well as others.


1.6.2 Services 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", http://research.sun.com/techrep/1994/abstract-29.html].

A 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, nonetheless the users of that server need be concerned only with the interface description of the service.  For example, the purchase order processing capability of an enterprise resource planning system might be exposed as a discrete service, and only the interface description would be needed to invoke it. 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 

In essence, the key components of a Service Oriented Architecture are the messages that are exchanges, 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.  The W3C Technical Advisory Group has responsibility for defining the Archnitecutre of the World Wide Web [ http://www.w3.org/TR/webarch/] and the WSA WG uses  their definitions as the authoritative reference.  To summarize briefly: 

- 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.
 
The Web was to a certain extent shaped and parts of it can be described by a theoretical model  known as "Representation State Transfer" or REST, proposed by Roy Fielding. ["Architectural Styles and the Design of Network-based Software Architectures" http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm]. This model presents a more constrained view than the Web as we know it, but  has considerably inspired both the TAG's Architecture document and many people who see it as a model for how to build web services.  The most important difference between "the Web as we know it" and the "REST Web" is that a REST application maintains the processing state on the client, whereas many Web applications maintain stateful objects such as "sessions" on the server or employ "application servers" to maintain application state in a middle tier between the client and server.

Since the Web is a SOA, the "REST Web", is also a kind of SOA, which we shall refer to as a "REST SOA", and is characterized by the following
principles:

1. Applications operate by changing the state of  Web "resources" (identified by their URI) by means of a  transfer of "representations" of those resources between agents.

2. A limited, uniform set of operations (corresponding to the principal HTTP
verbs) are defined to perform these state changes. 
 
3. All resource states are themselves resources, and thus uniquely identified/reachable by their URI.

4. The state of an application is maintained only in client code or explicitly in addressable resources, but not in the server itself.

5. Resource representations may contain other resource identifiers  useful for the client to explore the application search space. 

A somewhat different style of SOA is usually associated with the term "Web services," but since that term is so overloaded we shall call this approach the "application specific interface SOA" style or API SOA  as a shorthand. [Ed note:  This terminology is being continually reconsidered!]. The API SOA style is characterized by:

1. Applications operate by exchanging messages that capture both the representation of the resource/service and the representation of the state change request.  [Contrast with #1 in the REST SOA discussion; REST SOA separates the resource representation from the state change request in the message. API SOA does not. ]

2. Not all resource states are addressable/reachable, services can hide/encapsulate them. [Contrast with #3 above] 

3. the server may maintain state. [Contrast with #4 above]


Both SOA styles use URIs to identify resources and use Web protocols and XML data formats for messaging. Where they fundamentally differ is that API SOA style is more oriented toward invoking arbitrary operations and software code to make an application work, whereas the REST SOA style uses a unform set of basic operations to manipulate information directly. 

Also, they achieve some of their benefits in a somewhat different way. Both styles of SOA have good "visibility": trusted third parties may inspect the flow of messages and determine  what services are being invoked by which agents. This, in turn, means that intermediaries, such as fire-walls, can operate effectively on just the information in the message: A fire-wall can look at the message traffic, and at the structure of the message, and make predictable and reasonable decisions about security, or performance optimizations, etc.

In REST 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 API SOA services that use XML, 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.  It is quite true that HTTP-aware firewalls are a a more practical solution in the predominantly HTTP-based environment as of this writing.  XML-aware firewalls and other "edge appliance" products, however,  are now coming to market and offer the benefits of "visibility" even in a heterogenous network environment.

Received on Thursday, 8 May 2003 13:37:38 UTC