February 19, 2008
Andrew Walkingshaw came back from semantic camp brimming with enthusiasm and bearing gifts; stickers bearing a likeness of Roy Fielding and the slogan “Fielding has a posse” and “RFC 2616″ (the HTTP 1.1 spec of course!). I could stick it on my trusty powerbook, apparently all the cool semantic/web/2.0 kids have stickers all over their macs these days. My instinct to preserve the pure clean lines is evidently old hat, and as we know, old hat don’t dance.
From Andy’s original post: -
Finally, that the ‘service oriented’ approaches that we have tended to adopt in standards like the OAI-PMH, SRW/SRU and OpenURL sit uncomfortably with the ‘resource oriented’ approach of the Web architecture and the Semantic Web. We need to recognise the importance of REST as an architectural style and adopt a ‘resource oriented’ approach at the technical level when building services.
In the comments there’s the fashionable spat over whether the word “repository” should be pejorative, but I’m surprised nobody’s trodden on the “service-oriented” banana skin. Andy does clarify with “at the technical level” at the end of the point, but care is needed since SOA is a historically infamous weasel phrase: -
“… that’s a service oriented approach for you.”
“I don’t know what you mean by service oriented approach” said Alice
Humpty Dumpty smiled contemptuously “Of course you don’t, until I tell you.”
Repositories Thru the Looking Glass, missing chapter, with apologies to A. Powell and L. Carroll
There are (at least) three distinct meanings of “service oriented” in the repositories context.
- The Good
- Services as in “a set of services that a university offers to the members of its community for the management and dissemination of digital materials” (Cliff Lynch).
- The Bad
- Protocols such as those Andy mentions (OAI-PMH, SRW/SRU, OpenURL). These are also sometimes referred to as STREST interfaces (Service Trampled REST) as they work using the same URL and HTTP mechanisms as REST, but do so in a way that doesn’t take advantage of the web architecture (or rather, that doesn’t observe the constraints of the web architecture).
- The Ugly
- Snake Oil Architecture. SOAP, WSDL, WS-*, standards documentation as thick as your arm. Bleuch.
At a certain level, thinking about services makes sense. The mistake is to be too literal and carry it through to implementation. The JISC e-Framework animation describing SOA looks like they were thinking about resource oriented services – it’s all about common formats, GET and PUT. From a techie’s point of view, your manager can take a Service Oriented Approach and you can implement it RESTfully.
November 16, 2007
A post by Jon Udell on tiny URLs for web citations, with a good comment from Peter Murray. A persistent redirecting service that automatically caches and preserves content? Throw in some access management and that sounds like a good part of an institutional repository.
September 18, 2007
In an interesting post, Karen Coombs shares some of her issues in relating their library web site redevelopment to the need to provide web services to the rest of the university: -
If faculty could do their searches without coming to the library site would they? I think the answer is yes.
Long term I’d like a site which has a series of web services that can be exploited by my developers but also my the university web developers and who knows who else. Focusing on content rather than look and feel will allow us to provide these different types of services. It will also allow different types of users to potentially selectively access content.
I don’t think I’ve read anything like this outside a REST advocacy presentation!
Ultimately, I feel like it is these kinds of services that will make of break a library’s virtual presence not the library website. And with a limited staff, this means I like to choose carefully how much time I have my small staff spend on the tradition site. Otherwise, we could spend all our time caught up in look and not enough time working to make the library meet users where they are and be a seamless part of their work processes.
This doesn’t have to be a choice. Because Karen is concentrating on content, she is in a superb position to deliver the services she describes through the website, using good semantic markup, linked resources and well tempered feeds or sitemaps, using The REST book as a manual. This is an advantage of REST I hadn’t fully grokked; it’s cheaper. If you already have a website and need to provide service to your users, it’s quicker and easier to develop the website further RESTfully than to start an entirely separate service delivery development.