Give me an R

My rather outspoken outburst against the e-Framework a while back resulted in a mixed response, most of it in private replies for various reasons, largely supportive but some of which suggested that my negative tone was not conducive to encouraging debate.  For what it's worth, I agree with this latter point - I probably shouldn't have used the language that I did - but sometimes you just end up in a situation where you feel like letting off steam.  As a result, I didn't achieve any public debate about the value of the e-Framework and my negativity remains.  I would genuinely like to be set straight on this because I want to understand better what it is for and what its benefits have been (or will be).

Since writing that post I have been thinking, on and off, about why I feel so negative about it. In the main I think it comes down to a fundamental change in architectural thinking over the last few years. The e-Framework emerged at a time when 'service oriented' approaches (notably the WS- stack) were all the rage. The same can also be said to a certain extent about the JISC Information Environment of course (actually the JISC IE predated the rise of 'SOA' terminology but like most digital library initiatives it was certainly 'service oriented' in nature - I can remember people using phrases like, "we don't expose the resource, we expose services on the resource" very clearly) which I think explains some of my discomfort when I look back at that work now.

Perhaps SOA is still all the rage in 'enterprise' thinking, which is where the e-Framework seems to be most heavily focused, I don't know?¹ It's not a world in which I dabble. But in the wider Web world it seems to me that all the interesting architectural thinking (at the technical level) is happening around REST and Linked Data at the moment. In short, the architectural focus has shifted from the 'service' to the 'resource'.

So, it's just about fashion then? No, not really - it's about the way architectural thinking has evolved over the last 10 years or so.  Ultimately, it’s that it seems more useful to think in resource-centric ways than it is to think in service-centric ways. Note that I'm not arguing that service oriented approaches have no role to play in our thinking at a business level, clearly they do - even in a resource oriented world. But I would suggest that if you adopt a technical architectural perspective that the world is service oriented at the outset then it is very hard to think in resource oriented terms later on and ultimately that is harmful to our use of the Web.

I think there are other problems with the e-Framework - the confusing terminology, the amount of effort that has gone into describing the e-Framework itself (as opposed to describing the things that are really of interest), the lack of obvious benefits and impact, and the heavyweight nature of the resulting ‘service’ descriptions – but it is this architectural difference that lies at the heart of my problem with it.

1) For what it's worth, I don't see why a resource oriented approach (at the technical level) shouldn't be adopted inside the enterprise as well as outside.

Comments

[lorcan dempsey]

were you hoping to mobilise some conversation around this topic ;-)

[John Kirriemuir]

Am wondering if you have become an 'Angry Young Man' e.g. the James Dean of the digital library sector :-)

[staplegun]

Maybe the next step is to realise resource-oriented and service-oriented are 2 sides of the same coin, that we need both, working in harmony.

The problem with resource-oriented is when you have two identifiers for the same thing, now they look like two things/resources.

My next plan is to choose an id, make it my pid, give it a REST interface, then if I want to access that resource using another id, it will be via a service that redirects to that static resource.

http://myresource.com/333/get
http://myresolver.com/resolve?id=my:toy