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 /
http://www.sys-con.com/webservices/article.cfm?id=754
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 following
properties:

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

Received on Friday, 9 January 2004 14:13:09 UTC