Re: SOA proposed text - harvesting previous threads

When I have been pushing the SOA idea internally I have taken a 
different tack. For what it is worth, I think that the 
statefullness/statelessness and the idempotent stuff is kind off-target 
to the main issues; but I am not going to be roadkill for that.

So, for what it is worth, in presentations I approach it thus:

The SOA is founded on three key ideas:

1. Conversation oriented interactions as opposed to object-oriented 
interactions. I.e., the focus in on what goes on the wire, and not what 
happens at either end.

2. The agent abstraction - services are provided and requested by 
computing entities called agents. The central constraint being that we 
are *not* allowed to know anything about how the agent is built, the 
only thing that we can see are the messages it emits and consumes.

3. Copious quantities of meta-data (or otherwise known as 'death by 
description') permits human and automatic agents to figure out how to 
interoperate.

I guess that this is a constraint-oriented view!

The benefits that this gives are:

1. Respect for ownership boundaries. Because we are not allowed to know 
how agents are built, and because it is 'wire-based', the architecture 
works in an environment where the agents are owned by different people.

2. Ease of integration with legacy systems: because of aggressive 
minimization of knowledge of the internals, it makes it easier to add a 
WS interface to legacy systems.

3. Ease of automation: the large amount of descriptions (SOAP, WSDL, 
WS-CDL, etc.) mean that tools can be used to automate a large part of 
the details involved in inter-application interactions.

Missing from SOA's:

1. Object references in messages - there are no addresses of 
agent-internal objects in messages. This is the stateless constraint 
expressed differently. This in turn frees the service provider (and 
requester) from the requirement of keeping track of object identifiers 
that it has `published'.

On the other hand, business-level entities - such as account numbers - 
may still be exposed in messages. The difference is that an account 
number is essentially a shared abstraction - shared between the service 
provider and the requester - representing part of the business (or 
application) relationship.

=========
As Hao pointed out, SOA's do seem to denote a more abstract 
architecture than the Web architecture, it is at a similar level to 
that of REST. (REST adds more: the concept of a resource, and that 
conversations are about resources.)

Frank





On Thursday, September 11, 2003, at 08:59  AM, Champion, Mike wrote:

>
>
> 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 18:31:45 UTC