RE: Proposed replacement text for Section 1.6

 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. :)

Hao

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