W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2004

RE: Proposed replacement text for Section 1.6

From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
Date: Fri, 9 Jan 2004 13:45:40 -0600
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E026F00E5@bocnte2k3.boc.chevrontexaco.net>
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org

I think this is pretty good.  I might personally replace the term
"hardware/software protocal stacks" in the second paragraph with
"messages", but perhaps there is some nuance or distinction here that I
don't get.

FWIW I think the SOAP expansion is fine.

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Champion, Mike
Sent: Friday, January 09, 2004 1:13 PM
To: www-ws-arch@w3.org
Subject: Proposed replacement text for Section 1.6

[Please suggest improvements; I've tried to use our terminology about
agents, tasks, etc. consistently but probably didn't fully succeed.
Also, I recognize that this stuff is horribly abstract and like
everything else, no one will fully agree with my distinctions here.  I
do think they are useful, and have gotten reasonably good feedback from
presentations of them.

One source for this that I found particularly useful is
http://www.sys-con.com/webservices/article.cfm?id=706 /
The authors were WG members at one time, before my time I think (I never
met either of them).  I've also read a bazillion analyst reports, weblog
postings, and email threads on this stuff, and I'm fairly sure this is a
reasonably mainstream perspective.

You can whack out my little "two expansions of SOAP" thing at the end,
but I think its kinda cute :-)]

1.6 Service Oriented Architecture

There is considerable confusion in the computing industry about the
relationships among the terms "distributed system", "service oriented
architecture," and "web service", as well as to related technologies
such as CORBA. The definitions proposed here will not please everyone,
but attempt to add some clarity. 

A distributed system consists of discrete software agents that must work
together to perform some task. Furthermore, the agents in a distributed
system do not operate in the same processing environment, so they must
communicate by hardware/software protocol stacks over a network.  This
means that communications with a distributed system are intrinsically
less fast and reliable than those using 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"].

Distributed OBJECT systems are distributed systems in which the
semantics of object initialization and method invocation are exposed to
remote systems, by means of a proprietary or standardized mechanism to
broker requests across system boundaries, marshall and unmarshall method
argument data, etc. Distributed objects systems typically (albeit not
necessarily) are characterized by objects maintaining a fairly complex
internal state required to support their methods, a fine grained or
"chatty" interaction between an object and a program using it, and a
focus on a shared type system and interface hierarchy between the object
and the program that uses it.

For our purposes, a Service Oriented Architecture is a form of
distributed systems architecture that is typically characterized by the

Service definition: The service is an abstracted, *logical* view of
actual programs, databases, business processes, etc., defined in terms
of what it *does*, typically carry out a business-level operation.  

Message orientation: The service is formally defined in terms of the
messages exchanged between provider agents and requester agents, and not
the properties of the agents themselves. The internal structure of an
agent, including features such as its implementation language, process
structure and even database structure, are deliberately abstracted away
in the SOA: Using the SOA discipline one does not and should not need to
know how an agent implementing a service is constructed. A key benefit
of this concerns so-called legacy systems. By avoiding  any knowledge of
the internal structure of an agent, one can incorporate any software
component or application that can be "wrapped" in message handling code
that allows it to adhere to the formal service definition.

Services in SOA systems typically (albeit not necessarily) are
relatively stateless in the information required to support their
methods is contained in or referred to in the invocation message,
relatively coarse grained and the interaction between a service and a
agent using it is generally very straightforward,, and there is no
assumption of a shared interface hierarchy or type system between the
service and the agents which request it.

The World Wide Web is an instance of a SOA.  It provides services
associated with transferring resource representations between agents,
using the interface definition described by the URI specification and
the HTTP protocol (and other protocols that understand URIs and can
transfer resource representations). It adheres to SOA best practice in
that it encourages stateless interaction between a requesting agent and
a Web server, uses a simple service definition that encourages
coarse-grained resource representation transfers rather than "chatty"
interaction, and makes no assumption about implementation languages or
type systems on either side.

Web services refer to a set of <em>technologies</em> that may be used to
implement service oriented architectures *or* distributed object
systems, and perhaps other architectural styles as well.

It might be illustrative to note in this context that while "SOAP" is no
longer an acronym, there are two expansions of the term that reflect
these different ways in which the technology can be employed:

- Simple Object Access Protocol: A  SOAP message represents a method
invocation on a remote object, and the serialization of in the argument
list of that method that must be moved from the local environment to the
remote environment.

- Service Oriented Architecture Protocol: A SOAP message represents the
information needed to invoke a service or reflect the results of a
service invocation, and contains the information specified in the
service interface definition.  

In short, while Web services technologies are well-suited for
implementing SOAs, they are not intrinsically connected to SOAs (despite
the impression one might get from current analyst and marketing
presentations).  Likewise Web services technologies can be well-suited
(in the proper environments) for implementing distributed object systems
in a platform-neutral and vendor neutral manner, and this is widely
supported by tool vendors and frequently employed in enterprise
integration projects.

Figure 2, Generic Service Oriented Architecture Diagram  
[I suggest removing it; I don't have a better one available or even in
Received on Friday, 9 January 2004 14:46:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:10 UTC