RE: SOA proposed text - harvesting previous threads

Oops, sent without intending to.  I have edited in-line here ...

In general, it seems to me that quite a number of people have
essentially been in agreement here about what needs to be said, and that
it is important not to have bald statements about statelessness which
may be literally correct but which may leave a misimpression for those
interested in stateful interactions.

-----Original Message-----
From: Cutler, Roger (RogerCutler) 
Sent: Thursday, September 11, 2003 11:16 AM
To: 'Champion, Mike'; www-ws-arch@w3.org
Subject: RE: SOA proposed text - harvesting previous threads


I think that this text is generally excellent.  I particularly like the
illustrations of bogus definitions of SOA, and I hope that the stuffier
editors will not turf them.  The one with the agile development is
particularly good.

The only suggestion I have here is that I think the discussion of state
management should be enhanced along the lines discussed in a number of
recent emails.  Here are a few quotes culled from that thread (not in a
very systematic way):

******

I totally agree that a reader should be told that stateful interactions
are very much part of the Web Services Architecture _but_ that this is
achieved through mechanisms sitting on top of services and not because
of those services' semantics. Stateful or contextualised interactions
should be explained and defined at the same level as coordination,
transactions, choreography, security, etc. It is the case that some of
these concepts can be built or require contextualised interactions, as
it is the case, for example, with WS-Coordination, WS-Transaction,
WSBPEL, etc.

*****

I mostly agree about your comment below, but I think there is missing
one piece that allows "statefulness" to be layered on top. In a pure
"stateless model"  I (mostly) don't care which web service process my
request. But a necessry precursor to the stateful 
models is the ability to talk to the "same"  web service over as series
of interactions. Thus an identity model is required.

*****

I would say the equality function for stateless web service, ie same
type of web service, is a combination of the interface and endpoint
address.  The equality function for stateful web service, ie the
instance, adds on service specific parameters (aka ws addressing
reference properties).

I think the best way to differentiate stateful and stateless web
services is what is used to determine equivalence of the service
identifiers.

I also want to make sure that the web services architecture does not
"value" stateless web services higher than stateful web services.  I
personally think that much of the web is built upon stateful retrievals,
where things like cookie variables are used to determine the service
identifier.  Some will claim that stateless services are necessary to be
higher performance than stateful services, but that is simply
architecturally incorrect.  After much discussion and learning about how
my company builds products and looking at the characteristics of the
typical interactions of web vs web services, I will vehemently argue
against any prevailing wisdom that says stateless is by definition
better than stateful.

*******



-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Thursday, September 11, 2003 10:59 AM
To: www-ws-arch@w3.org
Subject: 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 12:21:13 UTC