RE: Proposed text for section 1.6.2 and 1.6.3

Hi Mike,

In general, I like the text. Recognizing WSA is a distributed architecture
with latency
in communications is a good step forward.

However, I would like to make couple of observations.
Please take these observations into consideration when you make further
edits.
I have used some phrases loosely for simplicity, and please excuse me for
that.

1. Historically, REST style *is* more or less the architectural style of the
WWW 
(whether we like it or not!). Not saying it as such would be rewriting
history.
Of course, adopting Roy's thesis as WSA is not what I am suggesting. We
should
possibly generalize some of the (http) specific notions within REST and use
it in WSA
(we are doing it somewhat, but may be need to make that an important
activity)

[Rationale: Once upon a time, we used to send paper mails. Then we
substituted it by
emails. It certainly increased the spped of our interactions. 
Did it change the "style" of our interactions or ways of getting
information? I would argue no - somebody has to send information, and others
have receive it. Then came the web,
and the freedom to "click" wherever you please. Did it change the style of
our interaction?
Most certainly. A web page presented an "information model" with embedded
links. Before
the web, information was presented to us "completely," whereas, with web
some information is presented to us but the rest of information is for us
to "click and get." REST style, I would argue,
in essence, an architectural style that has this new way of exchanging
information in its core. Interestingly enough, people seem to send URLs in
emails now, combining the new style
with the old.

Taking business: We are used to sending EDI/EDIFACT/CII documents in
business. By changing the format to XML did we change the architecture
"style?" - not any more than we did with replacing paper by mail. It
certainly got a bit faster because batch processing
was not mandated. Does SOAP change the style? I would argue no. We could see
the equivalent
of "embedded URLs in email" in business messages. This would be an important
WWW compliant
future step for business messages. You may ask where is an example for WWW
compliant business information exchange? Left as an exercise for the
curious:-)
]

2. WSA must be semantic web ready (at least not inhibit)

[Rationale: Though WWW and REST style provides for the use of
constraints.However, the techniques for creating and applying constraints
that are domain specific, industry specific, and trading partner specific is
still an art form (look at myriads of implementation guidelines for
"standards"). The guideline to "click" where on a web page (access
information based on an "information model") is embedded in our subjective
brains. It should be objective, for machine to process. Semantic web, I
think is a promising approach that can fill gaps in this area. I am unsure
the semantic web requirements are sufficiently expressed in WSA for us to
take this into consideration]


Regards, 
-Suresh 
Sterling Commerce (on loan to RosettaNet) 
469 524 2676 (O), 469 323 0234 (Cell) 



-----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 10:41:32 UTC