RE: WSA architectural concepts and relationsihips related to WS, SOA , and the Web

Seems pretty promising to me.

The "service" entry raises a lot of questions in my mind, however.  Why
did you find it necessary to use the term "course-grained" when you
defined service?  "Course-grained" on what scale?  Well defined
"operation" or "interface"?  Is there a meaningful distinction there and
if so why did you use "operation"?  It seems to me that if there is a
distinction that "interface" is what I would have thought was desired,
because the "operation" might have aspects that are hidden by the
interface.  "Does not depend on the context of a larger application".
Huh?  What larger application?  What context might it be that it doesn't
depend on?  Why did you want to say that?

I think that I sort of get the drift of most of the other parts of this,
and although it's obviously not in finished form it seems promising.  As
for the service part, however, I'm just totally not on the same
wavelength somehow.

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Tuesday, May 06, 2003 2:23 PM
To: www-ws-arch@w3.org
Subject: WSA architectural concepts and relationsihips related to WS,
SOA , and the Web





> -----Original Message-----
> From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
> Sent: Tuesday, May 06, 2003 1:49 PM
> To: Newcomer, Eric; Baker, Mark
> Cc: www-ws-arch@w3.org
> Subject: RE: WS, SOA, and the Web
> 
> 
> 
> Ok, on re-reading this I can see it's getting a bit out there
> into theory.  The only real point I'm trying to make is that 
> at this stage in WSA, we need to concentrate on defining the 
> relationships among architectural elements.

With great trepidation, I take a stab at this, in partial fufillment of
my editors action item to rework section 1.6.3 on SOA and REST
Architectures. Consider this a line cast into the trout pond; if any big
ugly brutes snap at it I'll not bother the list with refinements it
right now, but if we can get some clearer text in the WD along these
lines, that would be good: (terms in all capital letters are "concepts"
that should be in the concepts section and glossary if we were to accept
this).

DISTRIBUTED SYSTEM -- Everthing we talk about IS-A distributed system,
that is one made up of discrete software AGENTS that must work together
to implement some functionality.  Furthermore, the AGENTS in a
DISTRIBUTED SYSTEM do not operate in the same processing environment, so
they must communicate by hardware/software protocol stacks that are
intrinsically less reliable that direct code invocation and shared
memory.

SERVICE -- A SERVICE IS-A  type of software AGENT that is a
coarse-grained module  that performs some well-defined operation and
does not depend on the context of a larger application. 

SERVICE ORIENTED ARCHITECTURE (SOA) -- A DISTRIBUTED SYSTEM HAS-A of a
collection of SERVICES invoked by software AGENTS.

The WORLD WIDE WEB (WWW) IA-A particular SOA that operates as a
networked information system in which AGENTS manipulate "resources"
identified by a UNIFORM RESOURCE IDENTIFIER (URI) via protocols that use
URIs to directly or indirectly communicate over the internet.

The REST WEB (need a better word, or more concepts to build up to this)
IS-A subset of the WWW in which SERVICES implement a mimimal set of
operations (create-read-update-delete or PUT-GET-POST-DELETE) and
resources are manipulated by the exchange of "representations" using
these basic operations.  [I'm sure this could be reworked using the
concepts here).

[trial balloon ]The scope of the WSA (I hesitate to say WEB SERVICES for
obvious reasons!) consists of SOA that communicate via the WWW using
XML. That is, distributed systems in which the services communicate via
protocols that use URIs to directly or indirectly communicate over the
internet, and the definitions of the services and protocols [are | can
be] given in an XML-based language.

We can identify two major classes of [web services | thingies in scope
for the WSA]: [DIRECT SOA | RESTFUL WEB SERVICES] in which the primary
purpose of the service is to manipulate XML representations of Web
resources using the [minimal|CRUD|HTTP] operations, and those {INDIRECT
SOA ?}in which the primary purpose of the service is to perform an
arbitrarily complex set of operations on resources that may not be "on
the Web", and the XML [representations | messages] contain the data
needed to invoke those operations.  In other words, DIRECT SOA services
are implemented by web servers that manipulate data directly, and
INDIRECT SOA services are external code resources that are invoked via
messages to web servers.


So, is the beginning of a resolution or the beginning of a feeding
frenzy at the trout pond?  Obviously there is great room for refinement
and improvement and "friendly amendments" are solicited, but if this
isn't even close to acceptable to you, please just say "Trout" and we
can get on with something for which consensus is more likely.

Received on Tuesday, 6 May 2003 17:14:46 UTC