Jakub Korab

Seems the ball has really started rolling on this one. According to O’Reilly (http://radar.oreilly.com/archives/2007/02/aol_supports_op.html) AOL has started supporting OpenID for AIM users. It’s only a matter of time before Google’s on this one.

I had a look at the OpenID specs to get a decent understanding of exactly what the protocol was about. There is nothing there that can really be hijacked and made proprietary. Anyone who has worked on web applications such as portals whose services need to rely on a shared identity will instantly recognize the pattern in a collaboration diagram. I slapped one of these together for myself just as a matter of interest (a picture tells a thousand words). I’ll put up a post this weekend explaining the interaction.

The interesting thing here is going to be how exactly the scheme is going to be promoted/adopted. OpenID requires that every identity corresponds to a URL - at present AOL/MSN/Google accounts all correspond to an email address. Watch this space.

Out of sheer curiosity I checked out the RadRace results for 2006 from Javapolis (is there a running theme here?) to see what toolkits the guys who seriously churn stuff out quickly are using. The toolsets were as diverse as anything you’re likely to see, some proprietary, some big-vendor, some open-source. What I thought was interesting was the conclusion at the end of the keynote presentation - Whatever toolset you choose, get to know it in detail and stick to it. Makes sense. It’ll always be faster if you’re not reaching for the manual every time you need to do achieve something that’s fairly standard.

However, the only way to learn a toolset is to do up a system with it. Maybe in evaluating a new tool, which seems to be a regular thing these days, we need an example project that you have to work out. By coding it up, you learn what the strengths and weaknesses of the toolkit are, and have an objective basis for comparison. If you can exclude the domain knowledge factor, such as by having the database design already done and well understood, it could be a useful learning tool. And far better than the standard handholding projects covered in most framework books, since you have to work out stuff for yourself.

Microsoft today threw their weight behind OpenID (http://openid.net/) a distributed framework that helps users to identify themselves on the net in a uniform way.

http://news.bbc.co.uk/2/hi/technology/6339813.stm

The importance of this cannot be understated. The idea of a single sign-on to the net is The Way Forward. The problem with attempts in the past lay with the issue of who exactly controlled the information and where is was stored. Previous attempts at single identity schemes such as Microsoft’s own Passport relied on a person’s willingness to hand over management of their identity to someone else, leading to suggestions of Big Brother.

The beauty of the OpenID scheme is that a user registers their identity with an OpenID Provider which they can either run themselves or alternatively defer to a 3rd party. The MS move is important because it signals their intent to use this as the basis of future identity services, such as their InfoCard initiative. Not only would this mean that the scheme will become exposed to the mainstream via a large base of applications via the MSN/Passport network, but it may also mean that existing Passport users automatically become members of OpenID. Does this mean that web app developers should abandon their own username databases? I don’t claim to know the answer, but foolhardy is the developer who ignores this one.

Watch this space.

Jason Sankey just posted a list of OSGi tutorials: http://www.alittlemadness.com/?p=80

You have to love RSS…

I checked out the OSGi presentation from the Parleys site http://www.bejug.org/confluenceBeJUG/display/PARLEYS/Spring+OSGi. Wow. I haven’t really spent any time thinking about this stuff in the past, but it seems that yet again the JSR process is trying to formalize something that doesn’t need it. OSGi seems to be a much lighter, more powerful model whereby you can switch bundles, the JSR-277 module equivalents, at runtime via an OSGi console or JMX. Check out http://www.osgi.org and http://en.wikipedia.org/wiki/OSGi for good synopses of the technology and what it can offer.

The huge advantage here is that the technology is stable, mature and available to use right now (there are a number of open-source implementations) rather than needing to wait for something that won’t be around until Java 7. All that and no new language structures.

There’s an interesting post by Peter Kriens from OSGi about how JSR-277 stacks up at
http://www.osgi.org/blog/2006/10/jsr-277-review.html

"The ambition level of JSR 277 is significantly lower than where the OSGi specifications are today, even way lower than we set out in 1998. In a way, for me the JSR 277 proposal feels rather toyish. "

It’s time to kick the tires on this one, and see where it might be useful.

I have been going through some of the presentations from the Javapolis 2006 conference, and I stumbled upon a talk by Stanley Ho from Sun Microsystems about JSR-277 Java Modules - http://www.bejug.org/confluenceBeJUG/display/PARLEYS/JSR-277+Java+Module+System. The spec finally provides Java programmers the ability to programmatically enforce version dependencies within their code. No more classpath hell!! Woohoo! Once you have tried to work out which one of the 1000 xerces.jar files the classloader is loading a few times, it tends to lose its novelty.

One of the really cool things about it is the ability to instruct the classloader to load different versions of the same library (or module as it is now referred to) programmatically at runtime - loading different versions when you need them! Very powerful. Can’t wait to see an implementation.

It’s about time too…