RE: Proposed text for section 1.6.2 and 1.6.3

In general this seems to be looking quite good.

Thanks for the re-work of the "service" part.  I find it much clearer now.  Incidentally, you removed "coarse-grained" as a constraint of the definition, which seems like a good idea, but I also found your comment in explanation, "A service (any sort) has got to do enough work to justify the overhead of the remote invocation" to be useful.  (As a matter of fact, I intend to steal it for internal use). Perhaps something like that can be put somewhere else or qualified somehow in this section so as not to appear to be a constraint.

Grammatical nit in the "service" part:  "while a service might ..., but the users ..." is not parallel construction.  I think "nonetheless" rather than "but" might work.

Let me suggest, with some trepidation, another thought, based on the recent discussions of the terms "synchronous" and "asynchrous".  This is also based on my increasing feeling that I personally understand how these terms can reasonably be used in this context, and to some extent where the confusion has come from.  You may disbelieve this as you choose, but my understanding is more or less along the lines that Suresh has been developing.  I could expand on that more, but for the moment let's try to agree at least temporarily to pretend like the words have meaning.  In that case, it seems to me that there may be a very useful distinction, particularly in the section where you are discussing REST and the generalization to SOA (that's badly put, I know) between synchronous and asynchronous messaging on the Web.  It seems to me that much of the "traditional" Web involves synchronous interactions, as illustrated by a browser that hangs until it gets a response or gives up.  Or, from an application one can do a ET and either wait for the response or spin off a thread and query it every once in a while to see if it has "baked" yet.  I recall that Mark's response to the reliable messaging thread was something along the lines of, "No problem in REST.  The sender of the message gets back a 404 if the message was not delivered and is then responsible for taking appropriate action".  [Apologies to Mark if I am ascribing to him things he did not say -- my memory can be unreliable sometimes].  This is reasonable, but only if one is talking about synchronous messaging.  If it's asynchronous you have a different problem which leads you to acknowledgement infrastructures (which, under the covers, is the way TCP/IP works, right?).

Now, am I correct that REST, being based on HTTP, is pretty much entirely assuming synchronous messaging as provided by TCP/IP?   If so, I think that we have a pretty clear and useful distinction.  There is a component of Web services which involves synchronous messaging, which probably includes a lot of what people think of as the RPC style of Web service, but there is another component involving asynchronous messaging (which can have all sorts of MEP's).  This appears to me to pretty much beyond the domain of REST and is what the SOA extension to the description of the Web architecture is about.  

-----Original Message-----
From: Mike Champion [mailto:mike.champion@softwareag-usa.com] 
Sent: Wednesday, May 07, 2003 8:54 AM
To: www-ws-arch@w3.org
Cc: w3c-wsa-editors@w3.org
Subject: Proposed text for section 1.6.2 and 1.6.3


In fufillment of my long-standing action item to rework these sections, 
which try to describe how what WSA is doing relates to the concepts of 
"Service Oriented Architectures" and the Web/REST, I propose the following 
text. (HTML version attached if that makes life easier for the editors).  I 
think I have taken the feedback from yesterday into account.  Dave Orchard 
may also have been noodling on revisions to this section, and he may have 
some better ideas on how to word this, and I welcome his or anyone else's 
suggestions or counter-proposals.  This is very tricky stuff to sort out in 
one's head and get down on paper!

I don't have strong feelings about whether this should go into the soon-to- 
be-published WD; opinions solicited as to whether it fillets more trout 
than it spawns!

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].

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), but 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

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: 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"  http://www.w3.org/TR/webarch/]

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" 
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm].  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.  [Ed 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" [Ed 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.


-- 
Mike Champion

Received on Wednesday, 7 May 2003 11:52:54 UTC