RE: SOA proposed text - harvesting previous threads

My thoughts:

I'm somewhat encouraged that we are actually trying to define the realm of
these architectures in a layered manner.  This makes sense.

In general, I found the definition to be too broad.  I can't think of a set
of technologies that don't fall under this rubric, from distributed objects
to the web.  Maybe that's the point, that SOA is simply distributed
computing.  If so, let's make it clearer that SOA is a totally generic term
and d-o etc are instances of it.

In the past, people have typically differentiated SOAs from d-o based upon
best practices, such as "soas have a well published address" - this
differentiates from d-o factory pattners, and "soa interactions are coarse
grained" - this differentiates from the "setter/getter" style of d-o.  But
these are simply best practices and not constraints.  Another way to
differentiate is the format.

I think these, and other facets of architecture/markitecture, might be
useful to list.

I must admit, it seems that a Web service with a ws-addressing replyTo that
contains reference properties and is encoded in some binary format is as
good a SOA as corba at a purely technical level.  Remember, a Web service
applies WSDL and SOAP and use of URIs to SOA, which provides a
differentiation at the right level.  But they both seem like SOAs to me...

The definition of SOA needs to further talk about the difference between
"clasess" of services and instances of services.  For example, is it that
the "web service class" AND the "web service instance" must have unique
identity in the first constraint?

I don't understand the point of the 2nd constraint.  It seems redundant to
say that service must allow clients to talk to them.  I suggest removing.

I'm not sure about the 3rd constraint.  If I create a web service with WSDL,
but then do a really crappy job of defining the semantics is it not a SOA?
If I provide a WSDL for a stateful service, and then don't show the complex
message exchange patterns, is it not a SOA?

I disagree that having all the state management info be in messages, ie
stateless, is a good practice for SOAs.  It is a design choice, not a good
practice.  It should be listed as such.

If we are going to list good practices, I'd also add asynchronous as a good
practice.

cheers,
dave



> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Champion, Mike
> Sent: Thursday, September 11, 2003 8: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 Friday, 12 September 2003 16:49:58 UTC