Re: Issues, trout ponds and other dangerous regions

Ok, I will try to be clear.


On Monday, February 17, 2003, at 04:12  PM, David Orchard wrote:

>
> 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.

This is not true. I see nothing wrong with SOA. (Well that's a bit 
strong :-) but I definitely see the WSA as being an instance of a SOA.


>  I
> think you are implying that services and resources are separate things,
> therefore can't and shouldn't be compared/constrasted.

Well, yes I am saying that they are distinct; in the sense of being at 
different levels of abstraction.


> Also that the
> generic vs specific interface is a can 'o worms, so we shouldn't talk 
> about
> it.

I have no problem in mixing in on the actual generic interface. Its 
just that I thought that the group as a whole had more or less settled 
on the specific interface approach. Perhaps I'm wrong on that.

If we are going to go for the generic interface, then there are a few 
specific suggestions:

1. base the spanning set on a well founded theory - such as speech act 
theory
2. include/refactor the HTTP verbs of GET/PUT/POST in terms of that 
theory
3. agree on the content language as well as the generic interface

This is not all that hard to do; but it's a can o'worms because people 
are going to disagree on it with a marked sense of passion.

>
> 1. I make the assumption that there is something architecturally to 
> define
> about Web services.

Stipulated; otherwise I wouldn't be here


>  Given that it is technologically neutral, it is
> probably an architectural style that Web services are.

Actually, I'm not sure that we SHOULD be technologically neutral. The 
reality of the marketplace is driving us pretty hard; and if you ask 
the average journalist, or even book author, you will get the equation:

Web services = SOAP+WSDL+UDDI


>  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.

I am NOT trying to bury REST. I have a lot of sympathy for the model; 
especially as it has proved to be pretty successful.

> <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.

Stipulated. Its part of the goals and part of the charter.

>  Saying
> "xml, uris, maybe soap, maybe wsdl won't cut it".

What would be enough?


>
> 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.

I have an issue with this that I tried to raise in the telcon. It is 
fine for us to discuss trade-offs on email lists and in discussions. 
But, our architecture is supposed to be a standard - actual advice for 
building interoperable systems. Only to the extent that we make choices 
are we going to be relevant. A trade-off sounds like `well you can do 
it this way and get X, or you can do it that way and get Y' All very 
true, but what a standard specification is supposed to do is say `do it 
this way to ensure interoperability'. This is different from the 
question of normative vs non-normative, and optional vs mandatory, and 
leaving something unspecified.


>  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. "

There's a deep discussion to be had here. In the field of ontologies, 
this is clearly analogous to the `symbol binding problem' - of 
associating words and concepts with actual things that exist in the 
real world.

The RDF definition of a resource you quote above is completely 
circular. I am not surprised though, its hard to do.

>
> 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.

Like I said earlier, the concepts of resource and service seem to me to 
be at different levels of abstraction. Service is fundamentally about 
action, or rather the possibility of action; or better yet of the 
activity of performing tasks. (Where I mean a task to be the 
combination of action and a goal achieved by the action: I have a task 
to complete my report. The goal is the report, not the writing of it.)

To actually perform actions, to actually perform tasks, you need 
actual, physical entities to do the work. But those entities are not 
the same as the tasks they perform.

>
> 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?

I was giving an example. A service does have a description; whether its 
formally written down or not. The description of a service is 
fundamentally a description of the things you can use it for.


> 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! 
> :-)

Well, we have to be more precise, precisely because its computer 
programs that are going to be making the choices and not people. All 
that a browser has to do is present the link and perform a simple 
operation when the user clicks on the link. What the browser does with 
the link is essentially the same no matter what the link actually 
means. This is not possible for services because (a) a human may not be 
making the direct choices and (b) the operations that the `task 
browser' performs will be significantly different for different links.




> 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!

I can see the point. There are going to be plenty of situations where 
an informal understanding is sufficient: for example, if the same 
developer produces both the provider and the requestor of a service.

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

A service provider is an active computational resource (!) that is 
performing the actions associated with the service. Its inherent to the 
notion of service that someone or something must actually be performing 
the service. (Its hard to avoid circular definitions!)

I am not sure what a resource provider is. I would say that, in terms 
of the Web, a resource provider is an active computational resource 
(infinite regress here) that returns a representation of the resource 
on request (amongst other things). There is a difference: a service 
requestor is not a priori interested in the representation of the 
service but is interested in the actions to be performed.

>
> 7. As for generic vs specific, I don't think it's a can of worms to 
> describe
> it, or the benefits.

Well, the spanning set for services does not look (IMO) like 
GET/PUT/POST. And also, I do not believe that you can define it in 
isolation of the content language. (I am aware that not everyone agrees 
with this assertion.) Even HTTP/HTML go together like strawberries and 
cream. Strictly, you don't need HTML to understand HTTP; but in 
practice the two are very closely intertwined.


> 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.

As it happens, I can see quite a lot of benefits of having a standard 
generic interface. I just happen to think that it needs to be 
significantly richer than GET/PUT/POST or whatever. And I think that it 
must go in tandem with a decent solution for a content language. (I've 
got one in my back pocket if you'd like to see it!)


Frank


> 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 Tuesday, 18 February 2003 14:01:41 UTC