RE: Issues, trout ponds and other dangerous regions

BTW, here's a definition of Resource from Roy's thesis, section 5.2.  I
don't know how this relates to the RDF definition and the definition in the
URI spec..

The key abstraction of information in REST is a resource. Any information
that can be named can be a resource: a document or image, a temporal service
(e.g. "today's weather in Los Angeles"), a collection of other resources, a
non-virtual object (e.g. a person), and so on. In other words, any concept
that might be the target of an author's hypertext reference must fit within
the definition of a resource. A resource is a conceptual mapping to a set of
entities, not the entity that corresponds to the mapping at any particular
point in time.

More precisely, a resource R is a temporally varying membership function
MR(t), which for time t maps to a set of entities, or values, which are
equivalent. The values in the set may be resource representations and/or
resource identifiers. A resource can map to the empty set, which allows
references to be made to a concept before any realization of that concept
exists -- a notion that was foreign to most hypertext systems prior to the
Web [61]. Some resources are static in the sense that, when examined at any
time after their creation, they always correspond to the same value set.
Others have a high degree of variance in their value over time. The only
thing that is required to be static for a resource is the semantics of the
mapping, since the semantics is what distinguishes one resource from
another.

For example, the "authors' preferred version" of an academic paper is a
mapping whose value changes over time, whereas a mapping to "the paper
published in the proceedings of conference X" is static. These are two
distinct resources, even if they both map to the same value at some point in
time. The distinction is necessary so that both resources can be identified
and referenced independently. A similar example from software engineering is
the separate identification of a version-controlled source code file when
referring to the "latest revision", "revision number 1.2.7", or "revision
included with the Orange release."

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]
> Sent: Tuesday, February 18, 2003 12:59 PM
> To: 'Cutler, Roger (RogerCutler)'; www-ws-arch@w3.org
> Subject: 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.]
> > >
> > >
> > 
> > 
> > 
> > 
>