SOA proposed text - harvesting previous threads

Looking over the threads at [1] and [2],  I propose (wearing my 'member' hat
not my 'chair' or 'editor' hat) the following text (which would go at
various places in the document, at the editors' discretion) for your
consideration and improvement. Anything in [square brackets] is a reference,
an editorial note, or rough idea, not suggested wording for the document.

One thing I would appreciate (wearing my chair hat) is that comments take
the form of explicit suggested text to be inserted / deleted / updated.

Service Oriented Architecture

MOTIVATION

"Service Oriented Architectures" have received much attention in the past
several months.  The term has been in use for some time, but has been widely
promoted in the last year or so by a number of industry analysts.  SOA is
clearly a broader concept that "Web services" -- it encompasses
implementations using technologies such as DCOM, CORBA, and J2EE, and
arguably the Web itself is built on SOA principles.  One might distinguish
RESTful SOA, where the service is modeled with the
representations exchanged through direct manipulation of the resource
identifier, and [Ednote: "the opposite of REST" is a trout pond, adopting
Dave Orchard's long-ago suggestion] from Gateway SOA, in which the service
is modeled with operations invoked through an gateway identified by a
service identifier. 

Thus, SOAs can be built with procedures that are called remotely, objects or
components that can be distributed around a network, resources with state
representations that are transferred, or as some combination of these more
specific architectural styles.  There are, however, certain characteristics
and considerations that apply across SOAs irrespective of these details, and
we attempt to summarize them below.


CONCEPTS AND RELATIONSHIPS

Like the term "web services," "SOA" has been given a wide variety of
definitions, each generally tailored to the purposes of the organization
offering the definition!   Many definitions are infinitely recursive, along
the lines of "a service oriented architecture is a software architecture  in
which the fundamental components are services," and a "service" is "an
architectural component offering a service."  Writers have a tendency to
define SOA concepts with a string of buzzwords, e.g. a "new emerging
paradigm for distributed computing and e-business processing enabling agile
development of collaborating business applications."  

The WSA WG has attempted to distill down what appears to be the essence of
many definitions of SOA.   While we can't completely avoid the vagueness and
recursiveness, we might put it as:

SOA -  a style of software architecture centered on the notion of "service"
[as opposed to objects, components, data, procedures, etc.].  In an SOA,
there is a set of service providers and a set of service consumers, and
applications consist of coordinated service invocations.  The results of one
service may be consumed by another service either by exchange of data or
references to shared state describing the result.  

Service --  A set of processing operations that a service provider offers in
order to perform a specific function on behalf of a service consumer. [Ed
note: The point has been made that we can't say much in general about what a
service does, but it clearly does SOMETHING other than simply pass messages
back and forth]  Services may be carried out by software objects or
components, but the actual work of a service may be performed by legacy
procedural software, orchestrated web service invocations, trained monkeys,
or whatever -- the definition says nothing about implementations, only
interfaces.  "Web service" as WSA defines the term is a special type of
"service" in the SOA sense.

CONSTRAINTS

Services MUST have a unique identity  from the perspective of the consumer;
the provider can physically use as many instances of a "class"  [broadly
defined, not necessariliy in the OO sense] of services as needed to operate
efficiently, but the consumer communicates with them all via some common
identifer. 

Services MUST allow for interaction between service providers and consumers
via messages [and/or "documents"] that MAY cross system, network, and
platform boundaries.  [Not happy with this verbiage -- trying to say that
the essence of an SOA "service" is that is invoked by messages, not
platform-specific code-invocation mechanisms.]

Services MUST clearly define the format, exchange pattern, and assumed
semantics of the message(s) requesting the service and the messages(s)
describing the results of performing the service.  [ed. Note -- "service
contract" is a shorter and possibly more understandable way of saying this,
but "contract" has business and legal implications that we do not wish to
invoke.]


BEST PRACTICES

 SOA is clearly asserted to be a best practice by most of its advocates.
For example, "service-oriented architecture (SOA), a long-standing
best-practice architecture for design and implementation of large enterprise
systems." [3]


Coarse granularity -- "Good" services do a significant amount of "work" in
one invocation; this tends to minimize problems in the presence of network
unreliability, unpredictable latency, etc. The appropriate granularity
depends very much on the processing power of the consumer and provider
systems and the bandwidth of the network connecting them, as well as
business-level constraints on the timeframe in which a result is needed.  In
general, the slower the systems and networks, and the longer the business
timeframe, the larger the granularity one should define.  

Loose coupling / Extensiblity / evolveability  [Probably we should wait to
see what the TAG has to say on this subject for the Webarch; I suspect that
general SOA best practice will be a generalization]

State management  -- The service interface SHOULD require all information
the service needs to carry out its duties in the invocation message.  [or
maybe MUST incorporate all information the service needs to carry out its
duties by value in the invocation message or by reference to an external
resource that maintains the state of an ongoing service relationship ????]

Safe / idempotent  SHOULD [MAY?? Might want to think seriously about???]
define services in which information retrieval operations incur no
additional obligations on the consumer, and create/update/delete operations
have the same effect if invoked multiple times as they do if invoked only
once. 



[1] http://lists.w3.org/Archives/Public/www-ws-arch/2003Sep/0001.html 
[2] http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0055.html
[3] http://www4.gartner.com/pages/story.php.id.2450.s.8.jsp

Received on Thursday, 11 September 2003 11:59:32 UTC