[
Lists Home |
Date Index |
Thread Index
]
On Thu, 30 Jan 2003 14:50:49 -0800, Paul Prescod <paul@prescod.net> wrote:
> You said that "resource oriented programming" is unproven as a basis for
> the Web-as-we-know-it. I admit I only used the context of the one message
> and not the whole thread (my name floated by...). In my personal opinion,
> whether one thinks of resources as abstract or concrete, resource
> oriented programming is fundamental to the Web-as-we-know it. If by
> "resource oriented programming" you mean something more metaphysical
> about abstract resources then I won't spend much effort arguing about
> it...but woudl prefer you use a different term!
>
> I don't think that there is that much PRACTICAL difference between the
> two views because best practices will lead people to give concrete
> representations to otherwise abstract resources, and to NOT use pre-
> existing concrete URIs to mean something abstract.
OK, I can agree with all that. I somewhat unfairly loaded "ROP" with the
metaphysical baggage that we were debating somewhere up this permathread.
>
> Of course Google doesn't care whether I think that the strings are URLs
> or URIs, but if Google treats them only as locators and not as
> identifiers, then it cannot provide its service. A locator is a thing
> with exactly one operation: "dereference."
I think I'm convinced! Again, I think I was responding from a mindset
colored by a different argument somewhere upthread.
> In the realm of services hard-coded to talk to each other, you are
> entirely right. In the realm of services that are more loosely connected
> (for instance through pipes and filters), I do not think you are.
I think this is a key point. Definitely, the more one has to discover
services on the fly and late-bind to them, the more the principles of the
Web As We Know it (such as hyperlinks, the ability to leverage Google, ...)
will be important for Web services people to use and appreciate. A lot of
the disconnect between the "Web as We Know It" folks and the "Web services"
folks is that "discovered-on-the-fly, loosely-coupled services invoked over
the Web" exist mostly in marketechtures and white papers now. The
SOAP/WSDL/RPC paradigm works pretty well (at least compared to the easily
available alternatives) for application integration on secure, highspeed
LANs, and the people actually doing that stuff resist being lectured to by
RESTifarians.
Some interesting dialogues are going to take place when people start
working in the fuzzy middle where services must be loosely connected to
each other yet tightly integrated with exisiting back-end systems. IMHO,
neither the pure "design everything as a resource and access
representations over the Web" nor the pure "design everything as an object
and pretend the Web isn't there" approaches will suffice, so they'll have
to cross-pollinate each other.
|
