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 01:43:31 UTC