RE: Issues, trout ponds and other dangerous regions

0.  In general, I'm not really sure what changes you are suggesting to the
text or approach that I took.  I get the point #1 about GET/POST, perhaps
there's too much.  But on the other ones, it's almost like you are saying
that describing the architectural style of SOA is a bad thing to do.  I
think you are implying that services and resources are separate things,
therefore can't and shouldn't be compared/constrasted.  Also that the
generic vs specific interface is a can 'o worms, so we shouldn't talk about
it.  I must admit I'm astounded by our groups ability to talk about things
that we want to talk about.  eek.  Now I'm talking about us talking about us
talking about something.  I was just hoping to write up something that could
appear in our actual text, rather than debating whether we should do the
text or not.  I'll try to explain in the rest of this note, my motivations.

1. I make the assumption that there is something architecturally to define
about Web services.  Given that it is technologically neutral, it is
probably an architectural style that Web services are.  I "bang on about"
POST/GET for illustrative purposes mostly.  Indeed, I specifically chose the
nefarious getStockQuote to allow the description of the style to "fess up"
about it's constraints, and how they are different and similar to REST.
<hint>I think that TAG will give pretty strong pushback on a ws-arch that
doesn't describe it's architecture in relation to web architecture.  Saying
"xml, uris, maybe soap, maybe wsdl won't cut it".  BTW, I would vote this
way on the TAG if asked - and I'm SURE somebody will ask the TAG.  I just
happen to take enough personal responsibility that I think I should
volunteer to help provide such a description to avoid such pushback.  Of
course, the ws-arch could ignore such TAG feedback.  Maybe the Director will
even let it pass.  But why cause more trouble for ourselves than we need
to</hint>

2. I would like to end up with a description of the architectural style, and
the trade-offs associated with that style.  These trade-offs must be based
upon requirements or properties.  Given that the usual criticism of Web
services has been by "REST" folks, I thought that coming up with a
description and trade-offs in the same vernacular that is used for the only
real definition of REST would be helpful in getting to consensus on
similiarities/differences.  Hence the choice to use the properties from
Roy's thesis as the basis for description of properties for SOA, and hence
the choice of trade-offs in the same style that Roy uses in his sections 4
and 5.  Further, I'm lazy.  So therefore, I chose to re-use Roy's properties
and architectural style descriptions, rather than recreate the description
of REST in some third party methodology.

3. I would like to end up with a harmonized Web architecture and Web
Services architecture, from glossary terms to styles discussions to
properties.  I really do believe that this is possible.  BTW, when I say
"harmonized", I specifically mean that there are references from web
services arch to web arch, and it includes changes/extensions/refinements to
web arch "things".  I HIGHLY doubt that the TAG is going to choose a
vendor-specific architecture methodology.  So we need to find some way of
getting to a common methodology.  Again, I simply don't have the time or
energy to come up with yet another darned methodology.

4. I think that the definition of "Resource" as an entity that has actual
presence is not a widely accepted definition.  I find it somewhat
interesting that the URI spec does not define what Resources are, and leaves
it to something like RDF, which says

"Resources All things being described by RDF expressions are called
resources. A resource may be an entire Web page; such as the HTML document
"http://www.w3.org/Overview.html" for example. A resource may be a part of a
Web page; e.g. a specific HTML or XML element within the document source. A
resource may also be a whole collection of pages; e.g. an entire Web site. A
resource may also be an object that is not directly accessible via the Web;
e.g. a printed book. Resources are always named by URIs plus optional anchor
ids (see [URI]). Anything can have a URI; the extensibility of URIs allows
the introduction of identifiers for any entity imaginable. "

So there doesn't appear to be anything that's not a resource.  It's anything
imaginable.  It's fairly easy for me to see that a Web service is ALWAYS a
resource.  It's a particular type of a resource, as noted in our definition
which says that a Web service is identified by a URI - a Web service is
identified by a URI, URIs are for Resources, therefore a Web services is a
resource.

5. Are you saying that a Service MUST have a description, otherwise it's not
a service?  Do you mean a WSDL realization of that description?  And how is
that *REALLY* different than the web?  Each web page that I look describes
to me how to use it - otherwise I wouldn't know which links to select! :-)
I have been trying to avoid the requirement that a service has a formal
description.  And saying a web service is describable in WSDL is I think
terrible as well - as WSDL can describe anything that the group chooses to
describe!

6. I don't get the distinction between service provider and resource
provider.  See my item #4 on the relationship between resources and
services.

7. As for generic vs specific, I don't think it's a can of worms to describe
it, or the benefits.  Where I expect, and have already gotten, the pushback
is when some of the benefits acrue.  As in, "some kinds of applications are
better styled in a SOA" manner, with the pushback of "oh yeah, I've never
seen one".  BTW, I'm hoping that the comparison of a few different use cases
of app development will flesh out the point that you are making, that is the
the objects and verbs must both be understood.  This shows up in the
visibility property elaboration.  Course, while I spend time justifying what
I'm doing, I can't actually be doing the doing of the scenarios, SOA
references etc.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Francis McCabe
> Sent: Monday, February 17, 2003 2:04 PM
> To: www-ws-arch@w3.org
> Subject: Issues, trout ponds and other dangerous regions
>
>
>
> David gives an eloquent defense of REST in
> [http://www.w3.org/2002/02/mid/
> 007d01c2d325$5c30fc00$c10ba8c0@beasys.com;list=www-ws-arch];
> however it
> appears that he re-opens issues that need resolving.
>
> In the current WSA document, in several places, it is stated
> that Web
> services are NOT tied to specific technologies and protocols
> (such as
> HTTP, SOAP, WSDL etc.) In fact, currently, the ONLY hard nailed-down
> technology choices are URIs and XML.
>
> If the WSA is to be technology neutral, then it is not
> appropriate to
> `bang on about' POST vs GET in the document; although
> constraints such
> as idempotency are definitely `in scope'. On the other hand,
> if the WSA
> is to be technology centered, then we need to make that choice
> explicit, and soon.
>
> The second nettle is more conceptual: the distinction between
> resources
> and services. There is a relationship, but perhaps not one that is
> immediately obvious. In my opinion these concepts are at different
> levels of abstraction: a resource is an entity that has an actual
> presence and a service is a means of achieving tasks.
> Services require
> realizations, and such realizations are resources; but
> resources can be
> `of' anything and are not tied to services. On the other
> hand, services
> have descriptions which are not of the service itself but of how to
> interact with them.
>
> This distinction is important because, if the focus is on
> services as
> opposed to resources, then a large number of concepts need to
> be `put
> into place' that have no relevance to the strict resource
> view. A good
> example is the service provider. It is an important concept for a
> service oriented architecture; but has no special equivalent for
> resource. (Owner, however, is a concept that applies to both.)
>
> Finally, there is the hoary old one concerning generic
> interfaces vs.
> specific interfaces. Again, so far, we have been pretty
> muddled about
> this. [Personal opinion: it is not possible to completely
> capture the
> semantics of a message without grasping both the verb and the
> object of
> the message. Definitely there are different styles of architecture,
> where there is a rich though generic set of verbs that everyone is
> expected to agree on, and where there is an essentially
> infinite set of
> verbs and everyone is expected to come up with their own
> definitions. I
> am somewhat persuaded of the merits of the generic case; but
> its a can
> o'worms defining the spanning set.]
>
>

Received on Monday, 17 February 2003 19:14:48 UTC