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

RE: Proposed replacement text for Section 1.6

From: He, Hao <Hao.He@thomson.com.au>
Date: Sat, 10 Jan 2004 08:19:50 +1100
Message-ID: <686B9E7C8AA57A45AE8DDCC5A81596AB0922DEFC@sydthqems01.int.tisa.com.au>
To: "'Champion, Mike '" <Mike.Champion@SoftwareAG-USA.com>, "'www-ws-arch@w3.org '" <www-ws-arch@w3.org>
 hi, Mike,

I still think we need to define/explain SOA by formally listing the
architectural constraints.  You sort of did it but I am strongly in favor of
explicitly listing them as constraints. 

Can we also replace "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 ..." with something more positive?

BTW, I predicted in my article
(http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html) that someone would
soon replace the original meaning of SOAP with Service Oriented Architecture
Protocol. Now, you did it. :)


-----Original Message-----
From: Champion, Mike
To: www-ws-arch@w3.org
Sent: 1/10/2004 6:13 AM
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,
one will fully agree with my distinctions here.  I do think they are
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
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
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
that communications with a distributed system are intrinsically less
and reliable than those using direct code invocation and shared memory.
has important architectural implications because distributed systems
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,
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
by means of a proprietary or standardized mechanism to broker requests
across system boundaries, marshall and unmarshall method argument data,
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"
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

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

Service definition: The service is an abstracted, *logical* view of
programs, databases, business processes, etc., defined in terms of what
*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
properties of the agents themselves. The internal structure of an agent,
including features such as its implementation language, process
and even database structure, are deliberately abstracted away in the
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
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
stateless in the information required to support their methods is
in or referred to in the invocation message,  relatively coarse grained
the interaction between a service and a agent using it is generally very
straightforward,, and there is no assumption of a shared interface
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
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
representations). It adheres to SOA best practice in that it encourages
stateless interaction between a requesting agent and a Web server, uses
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

Web services refer to a set of <em>technologies</em> that may be used to
implement service oriented architectures *or* distributed object
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
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
of that method that must be moved from the local environment to the

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

In short, while Web services technologies are well-suited for
SOAs, they are not intrinsically connected to SOAs (despite the
one might get from current analyst and marketing presentations).
Web services technologies can be well-suited (in the proper
for implementing distributed object systems in a platform-neutral and
neutral manner, and this is widely supported by tool vendors and
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 16:19:52 UTC

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