Services and web resources

2009-01-21T21:12:07Z in web

David Smith and I have been discussing web "services" and web "resources". He'd like to use the terms interchangeably, but I feel that's improper. Not all resources are services. Is the HTML page representing this blog post a service? No. Are the images within it services? No. Is my blog a service? No, although it has ambition sometimes. On the other hand, not all services are web resources (CORBA, DCOM, Ice, Twisted, SOAP), and many of the rest are poor web resources. The situation looks a bit like this:

http://farm4.static.flickr.com/3362/3215405911_cab3667f15_o_d.png

What makes a web resource is explained in http://www.w3.org/TR/webarch/. Consider this classic diagram from that document:

http://www.w3.org/TR/webarch/uri-res-rep.png

That's the architecture of the Web summarized in a single picture. Resources are identified by URIs, and agents interact with resources by sending messages to (for example) retrieve their representations. There is harmony and consistency among the three concepts in the picture above. Now consider a similar picture of an OGC web something service, rendered for effect in the same style:

http://farm4.static.flickr.com/3093/3213872061_2f4270b082_o_d.png

(I'm using the GeoBase service as an example because of its high profile. It's typical of WxS service implementations.)

Does the service's "Online Resource" URL (http://www.geobase.ca/wms-bin/cubeserv.cgi) identify a web service resource? As much as you'd like to think so, it's not immediately clear that this is true. I've put a question mark in the diagram. Dereferencing that URL might provide more information:

seang$ curl -i http://wms.geobase.ca/wms-bin/cubeserv.cgi?
HTTP/1.1 200 OK
Date: Wed, 21 Jan 2009 20:48:08 GMT
Server: Apache/2.0.52 (Red Hat)
Connection: close
Transfer-Encoding: chunked
Content-Type: application/vnd.ogc.se+xml

<?xml version="1.0" encoding="ISO-8859-1"?>
<ServiceExceptionReport version="1.1.3" xmlns="http://www.opengis.net/ows"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/ows ...">
<ServiceException>
CubeSERV-35000: Missing REQUEST parameter
(raised in function handleWmsRequest() of file "main.c" line 422)
</ServiceException>
</ServiceExceptionReport>

The '200 OK' response, in accord with RFC 2616, section 10.2.1, indicates that the response carries the representation of the resource identified by http://www.geobase.ca/wms-bin/cubeserv.cgi. That representation has content type 'application/vnd.ogc.se+xml' and contains a traceback (running in debug mode or what?). Interpretation: http://www.geobase.ca/wms-bin/cubeserv.cgi identifies not a service, but a service exception document. An agent can't stick to HTTP/1.1 and interpret this in another way.

Just to show that this is not just the fault of GeoBase, here's an interaction with another prominent service:

seang$ curl -i http://gisdata.usgs.net/wmsconnector/com.esri.wms.Esrimap?ServiceName=USGS_WMS_NLCD
HTTP/1.1 200 OK
Date: Wed, 21 Jan 2009 20:49:01 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 18:00:00 CST
Content-Type: application/vnd.ogc.se_xml
Content-Length: 294

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<ServiceExceptionReport version="1.1.1">
<ServiceException>
Missing mandatory REQUEST parameter. Possibilities are
{capabilities|GetCapabilities|map|GetMap|feature_info|GetFeatureInfo}
</ServiceException>
</ServiceExceptionReport>

Again, http://gisdata.usgs.net/wmsconnector/com.esri.wms.Esrimap?ServiceName=USGS_WMS_NLCD identifies not a service, but a service exception document.

Are these OGC web services not web resources at all, or just broken ones that might be patched up with appropriate representations and HTTP status codes? The former, I think: the OGC service architecture originated apart from the Web, and although the web is the primary transport (middleware, as Paul Prescod says, or "DCP" in OGC terms) nowadays, the "Online Resource URL" isn't really a universal identifier in the webarch sense. That's the source of the disharmony among entities in the WMS picture above.

Comments

1Re: Services and web resources

Ron, 2009-01-22T12:09:22Z

In speaking, I tend to call data sources "services," and information sources "resources." (I know these aren't rigorous at all.) Let's say I provide a service that returns street addresses in a zip code. It's probably going to return too many lines for any effective representation in human terms. That, I would call a "service." It is basically a data-oriented response. Format is documented so that it is usable (XML or json or RonText or whatever,) but it is not a representation by any human measure. It's just service returning data in a format. Now, a resource (in my mind, anyway) makes some attempt to tune the data for human consumption -- search and sort, paginated html pages, Web 2.0 schnazifications, an adaptation for the tiny screen, or SVG animations -- something to render the data into information for humans. Perhaps, in Bateson's terms, a "service" just reports a difference; in order to provide a "resource," you have represent a difference that difference makes.

2Oops, that was an illustration!

Ron, 2009-01-22T12:13:28Z

Let me try it again with a little structure:

In speaking, I tend to call data sources "services," and information sources "resources." (I know these aren't rigorous at all.)

Let's say I provide a service that returns street addresses in a zip code. It's probably going to return too many lines for any effective representation in human terms. That, I would call a "service."

It is basically a data-oriented response. Format is documented so that it is usable (XML or json or RonText or whatever,) but it is not a representation by any human measure. It's just a service returning data in a format.

Now, a resource (in my mind, anyway) makes some attempt to tune the data for human consumption -- search and sort, paginated html pages, Web 2.0 schnazifications, an adaptation for the tiny screen, or SVG animations -- something to render the data into information for humans.

Perhaps, in Bateson's terms, a "service" just reports a difference; in order to provide a "resource," you have represent a difference that difference makes.

3Re: Services and web resources

Sean, 2009-01-22T19:33:34Z

Resources provide pages for human agents, services provide data for computational agents? The architecture of the Web (not to mention the Semantic Web) does not make this distinction. It's all resources. Text resources, image resources, audio resources, data resources. The audience of a resource (modulo authentication, authorization, and language) is determined by the content types of its representations.

4Re: Services and web resources

Andrew Turner, 2009-01-22T21:50:39Z

The WxS is actually really close to what would be a good operational model here. If you dereference the URI to the 'service', it should return a 200OK and instead of an Exception could return the GetCapabilities document. This way the "resource" is the description of the map (just not in a pretty picture way, but in a we have a map with these layers in this area with this title, etc.) The capabilities really isn't different from an entity/resource from a PNG or KML. The latter merely contain the actual features, but there is no necessity that a resource directly include all subsequent child resources. An Exception should only be returned if the subsequent query parameters are not valid, and then would be an HTTP 400 "Bad Request". Unfortunately, I assume the fault lies in designing the spec around implementation details (servers being written to say 200 if there wasn't a failure raised)

5Re: Services and web resources

Dave Smith, 2009-01-26T15:34:35Z

What's referenced is just a base URI, e.g. http://wms.geobase.ca/wms-bin/cubeserv.cgi? - as such, it's an incomplete URI scheme for the resource, and that's why you get the broken response. Obviously you would then have to ask it for something, http://wms.geobase.ca/wms-bin/cubeserv.cgi?request=getCapabilities or... http://wms.geobase.ca/wms-bin/cubeserv.cgi?SERVICE=WMS&VERSION=1.1.3&REQUEST=GetMap&BBOX=-81.758684,46.435561,-74.056742,50.968655&SRS=EPSG:4326&WIDTH=893&HEIGHT=526&LAYERS=DNEC_250K%3AELEVATION%2FELEVATION&STYLES=&FORMAT=image/png&TRANSPARENT=TRUE Those are the full URI schemes. For a RESTful service (or any other kind of service) you would similarly need to pass in parameters, e.g. ask it for capabilities, ask it for an image, identify a feature, and so on. This yields an immense number of permutations, different image sizes, different layers, different styling requests, and so on - and this is why a base URI is not so unreasonable as it provides the base starting point. Perhaps, though, it would make more sense to point to the Capabilities document as that starting point. The other issue is in connecting to it, "lights-out". This is done via a.) OGC standard and b.) Capabilities statement. These things, capabilities and standards are crucial for interoperability and enterprise-oriented approaches. In a vacuum, one could build the greatest, most wonderful service in the world, yet it would do anyone else no good if they don't know how to discover and access it consistently.

6Re: Services and web resources

Sean, 2009-01-26T16:29:54Z

Dave, I agree with you about discovery and access. Happily, webarch and HTTP/1.1 have this covered, and better than any OGC spec: through URIs, links, and the "follow your nose" discovery that crawlers and search engines can exploit. How is using HTTP not "lights-out" access? It's good enough for your feed reading, your web browsing, your Twitter clients ... even WxS and SOAP use HTTP as transport.

You're misusing the term "URI scheme", which is defined in webarch. Our URI schemes are "http", "ftp", "urn", "info", et al. To assert that the WxS "online resource URL" string is a URI scheme is to create immediate conflict with the architecture of the Web. There would be a profusion of WxS URI schemes, one for each service installation (500 or so), all of them extending the "http" scheme in a non-standard way. Talk about "stovepipes". Remember, too, that WxS services are supposed to support POST requests to the thing at that "online resource URL" for capabilities docs and data. You POST to a resource identified by a URI, you can't meaningfully POST to a URI scheme.

I feel that when you write "URI scheme" you're trying to express concepts related to URI templating. See the IETF URI templating draft for the way to do this right, but understand that even if WxS were to do proper URI templating, its "online resource URLs" would have to identify proper resources for POST's sake.

7Re: Services and web resources

Dave Smith, 2009-01-26T16:51:20Z

With regard to discovery and access, we can discover and access RSS and ATOM feeds only because they have a defined standard - and even that is not without the occasional wrinkle. Similarly, the Twitter API is documented and defined. But you certainly wouldn't be able to immediately figure out how these work without first knowing at least a little bit about the feed/API and its parameters - hence capabilities and standards. What I mean by "lights-out" access is being able to programmatically discover and access with little more than a handful of predefined rules - as opposed to always making a human read docs unique to each API or feed, and write custom code for integration. People want to focus on doing science, analysis and solving business problems, and not writing custom code that might break with each change on the far end. I'd agree that OGC isn't quite there on some of your points, but again, it points up the need for consistency.

8Re: Services and web resources

Sean, 2009-01-26T17:21:38Z

It doesn't follow from my criticism of WxS that I am against standards in general. I'm strongly in favor of good protocol and format standards; "good" to me meaning that something works well with our global information infrastructure (also known as the "Web"). In this sense, WxS is not so good, though its formats are better than its protocols.

Comments are closed after 13 days.