A slightly different update on the 1.5 text

I had been working on a revision of my proposed text for section 1.6 in  
light of the comments, but Hugo seems to have beaten me to it.  (Sorry  
I was not more prompt!)  In case there is anything worth harvesting,  
here is what I would have proposed.  I don't see any critical  
differences, so let's stick with Hugo's text unless someone finds a  
particular addition or revision below worth moving into the doc.

======================================================================== 
===

One goal of this Web Services Architecture is to clarify the  
relationships among the terms "distributed system", "service oriented  
architecture," and "web service". The definitions proposed here will  
not please everyone, but attempt to add some clarity.

A distributed system consists of discrete software agents that  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 messages over a network.  This means that communications  
within 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.

Distributed object systems face a number of architectural challenges   
These include:
- Problems introduced by latency and unreliability of the underlying  
transport.
- The lack of shared memory between the caller and object makes  
reference to shared data inefficient.
- Numerous problems introduced by partial failure scenarios.
- The challenges of concurrent access to remote resources
- The fragility of distributed systems if incompatible updates are  
introduced to one side or the other.
For our purposes, a Service Oriented Architecture (SOA) is a form of  
distributed systems architecture that is focused on the idea of  
composing systems made up of "services". A 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.

SOA is typically characterized by two key constraints:

2. Two main architectural constraints of SOA: 1) A small set of simple   
interfaces to all participating software agents.

2)  Messages sent in a platform-neutral, standardized format delivered  
through the interfaces.  XML is the most obvious format that meets this  
constraint.


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.  There is no  
assumption of a shared interface hierarchy or type system between the  
implementation of the service and the agents which request it; there is  
an agreement between the requester and provider on the type of the  
*messages*, e.g. that specified in the WSDL description of the service  
interface.

SOA systems can usually overcome the architectural challenges of  
distributed object systems.  For example,
- Problems introduced by latency and unreliability of the underlying  
transport are minimized by  coarse-grained and asynchronous  
interactions  between requester and provider.  A message either gets  
through or it doesn't. Likewise, the requester is generally not blocked  
while waiting for a response, but in a state where it can be notified  
when the service request has completed.

- The lack of shared memory between the requester and provider is less  
of a problem if the invocation message contains all the information  
needed to define the state of the service so that a specific request  
can be invoked.

- Partial failure scenarios are minimized to the extent that the  
service is coarse grained and stateless; it has presumably been  
designed to reinitialize its base state after every service request,  
successfull, partially successful, or unsuccessful.

- The challenges of concurrent access to remote resources are minimized  
by the decoupled, stateless approach to designing services.

- The fragility of distributed systems when updates are introduced to  
one side or the other is minimized if the service leverages the  
*labelled* nature of XML messages to find the information it needs and  
ignore anything extraneous.

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 (as of the SOAP 1.2 W3C Recommendation), 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.

Received on Thursday, 22 January 2004 15:18:10 UTC