RE: Issues, trout ponds and other dangerous regions

I agree completely.  And the way that I think this should go is as follows:

1. The W3C TAG should darned well write up what a resource is from a web
architecture perspective.
2. The WS-Arch group ought to relate a service to a resource *somehow*
3. Both groups get feedback on their definitions.

I don't think it makes a great deal of sense for the ws-arch group to worry
about defining what a resource is, that ought to be part of the TAG's job.
Maybe ws-arch should make a comment on the Web arch document saying "hey,
we're trying to figure out how services relate to resources, and you guys
need to provide a definition."

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Cutler, Roger (RogerCutler)
> Sent: Tuesday, February 18, 2003 9:52 AM
> To: www-ws-arch@w3.org
> Subject: RE: Issues, trout ponds and other dangerous regions
> 
> 
> 
> I don't entirely understand this discussion, but it sounds to me like
> David and Frank have rather different conceptions of what the words
> "service" and "resource" mean.  If so, it seems to me that it 
> would be a
> good idea to get on the same page somehow.
> 
> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com] 
> Sent: Monday, February 17, 2003 6:12 PM
> To: www-ws-arch@w3.org
> Subject: 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.]
> >
> >
> 
> 
> 
>