Tech Life of Recht

As you probably know, I’m involved in the OIOREST work for NITA. The work is progressing slowly, but recently I’ve had some thoughts on REST which I thought were sharable.

First of all, REST invites to a completely new kind of architecture. Nothing new here, it’s been known as mashups for a while, but I don’t think the relevance of this has been very obvious. Mashups are often taken to be something non-enterprisey about combining data in new ways, preferably in the browser by using some sort of Javascript. One thing is the possibility of combining data in new ways, but equally interesting is the fact that a lot of data manipulation is moved from a central service to distributed clients. In the good old WS-* world, mashups are known as ESBs. An enterprise service bus, whatever that is, is orchestrated into making web service calls to different services, transforming the results, combining them, and returning a complete document to the caller. The net effect is more or less the same: You get a page with the data you wanted to see (hopefully), but the ways it’s done are just about as different as they can get.
I’ve been on quite a number of projects where one service had to call another service in order to return a complete result. This gives long chains of service calls, and lead to highly coupled systems which are not very fault tolerant. With REST, it’s suddenly much easier to just return a document with references to other documents, and if it’s necessary, the client can fetch the other documents, and in the process utilize HTTP caching and other well-known mechanisms. This way, a client can fetch a root document, and immediately show the page and then fetch the rest of the data – what Martin Fowler calls Segmentation By Freshness.
Unfortunately, I’ve not seen any “enterprise systems” use REST like this, but I can’t see why it should not be possible, and even better than the WS-approach.

The second point about REST is about privacy. This is a hot topic in Denmark at the moment – a new national digital signature is on the way, and we’re helping NITA implement Single Signon using SAML 2.0. SSO makes it easier to acccess protected resources, but it also makes it harder to maintain privacy as a citizen. Most people look at SSO and the government pragmatically and trust that the government will do no harm. I guess I belong to that group to some degree, but other people, like Stephan Engberg maintains that the government should not be trusted, and that data should forever be owned by the person behind it, and nobody but the person should be able to combine it with data from other systems. Typically, this is accomplished by using pseudonyms – the person essentially gets a new identity for each system, and nobody knows all the identities (unless the person revals some or all of them).
I quit agree with this, I just can’t see how it can be implemented just now. However, REST looks like a good technology to use here. REST is relevant because, as mentioned above, it moves the responsibility for combining data from a closed system to an open client. With REST, a client can retrieve data from different sources, using different identities, and combine it locally, and the person behind the computer will be the only one to ever know. The same principles apply when
Of course there are details like XSS, trusting the client code not to do something wrong, and so on, but again: it’s all based on an open platform, and if you’re worried, you can make your own client.

I doubt anything like this will happen anytime soon – the tax office probably won’t like not being able to combine data automatically to prevent fraud, so we’ll probably just work on REST services which are not people related for now.

Usually, I’m not the kind of person who gets stressed about all kinds of stuff, but there is one place where it hurts a little: when I can see there’s something new which I ought to look at, but there is no time. Just about now, I would like very much to take a deeper look at GWT 1.5, but that won’t happen for a while because my backlog is stuffed with all sorts of projects which must be completed first.

Of course it doesn’t matter if only nothing else comes up – but what are the chances of that? More worryingly, this could also be the beginning of the end. Most junior developers are familiar with old dinosaur developers who for some reason don’t want to learn all the new and cool stuff, and often it’s somewhat hard to understand. After all, who would not want to learn new technologies, languages, features, and so on? Especially when it seems like so much fun.

When the backlog gets too large, it seems that there are a couple of ways out: a) devote more time to learning. Usually, this is not really an option because things like children, garden, and other responsibilities tend to pop up. Then you can go for b) where you just stop learning new stuff and settle with what you already know – what you already know will probably be improved as time goes by, but no new languages or technologies unless absolutely necessary. Or the last option, c) find a path and follow it, always learning something new, but also forgetting some of the old.

I would like to think that I’m going for c), as it seems like the best way forward (for me, personally). I might be missing some options here, but no matter what it’s probably a good idea to think about how your career is moving along. I’ve read quite a number of blog posts from bitter programmers who apparently hadn’t taken the time to reflect. In the meanwhile, GWT 1.5 will stay on my backlog for a while, so I’ll probably have to find something else to take off… Erlang, perhaps?