W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2003

Re: Issues, trout ponds and other dangerous regions

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Tue, 18 Feb 2003 14:58:47 -0800
Cc: <www-ws-arch@w3.org>
To: "David Orchard" <dorchard@bea.com>
Message-Id: <89C642CF-4394-11D7-93F0-000393A3327C@fla.fujitsu.com>

What this definition leaves out entirely is the possibility of action; 
which is pretty central to the notion of service.

action is not the same as information, even time varying sets of 

To use one of Mark's earlier examples, turning on a light switch. The 
state of the light is a representable resource; no question. The action 
of flipping the switch is not so representable. The arm which is used 
to flip the switch is, however, a resource; although any representation 
of it in terms of bits is merely a symbol and not the real thing.

That English word `is' has a lot to answer for!


On Tuesday, February 18, 2003, at 02:04  PM, David Orchard wrote:

> 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
>>> 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.]
> <winmail.dat>
Received on Tuesday, 18 February 2003 17:59:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:03 UTC