/var/log/mind

A lot of people are wondering whether Java is under threat from a set of nimble languages - PHP / Ruby / Python / Perl. There is a flurry of activity relating to Whether Java is losing the battle for the modern web lot of which are being driven from the earlier post by Andi Gutman Java is losing the battle for the modern Web. Can the JVM save the vendors?.

My recent activities had me visit the same question and the following is how I would summarise the situation and the mechanisms for Java to better compete with these nimble languages.

Current scenario

Yes, I think there is some threat to the scope of use of Java as a server side web application development language. Given the high acceptance of Java in the corporate environments this threat will take some time to play itself out. The sales pitch of Java has often been supported heavily by the vendors, and this has led to lesser focus on making java compete at the non-corporate-enterprise end. The nimble languages compete quite well in this space and combined with the increasing power of hardware which makes them more and more relevant each day for high performance requirements, there is a clear threat of these languages starting from a lower end pushing java out of even the middle end.

Opinion: Dynamism of syntax is not the real issue

What I am not yet fully on board with is the characterisation that the real issue is that Java is lesser dynamic than say PHP / Ruby / Python. Java has a pretty strong set of capabilities and while some may desire more from a syntax perspective I don’t know that thats the real issue. Lack of Closures, Dynamic Types, Duck Typing may make it difficult for java to compete in some contexts only to be at least partially offset in others.

Issue : Shared hosting of java applications

The first real issue is the overhead to develop and then start hosting java applications. It is difficult for host providers to support allowing each user the ability to run their own JVM processes in a sustained fashion. I remember the days when using PostgresSQL required you to have a dedicated server whereas you could use mysql easily by just setting up yourself for a small multi-tenant plan on a web server out there. Today Java is like PostgreSQL of those days. There is no easy way to simply set yourself up to run a small Java application in a shared tenant environment. Even if you did set yourself up chances are that you would be far less than satisfied with the performance in a multi tenant situation even though Java is actually a really really fast language. Java has endeared itself to the corporate environments with their funding for creating large infrastructure stacks and simply hasn’t offered enough opportunities for small enterprises / individuals to create and host their web applications on a shared infrastructure. This takes away an entire community of supporters who when they grew up would’ve carried java along into the larger of their applications.

Issue: Compile cycle

The second issue is the nastily long compile-build cycle. This leads to a scenario where developers need to twiddle their thumbs for half their development times waiting for ant / maven / javac to do their work. It destroys their rhythm and hurts their productivity. The traditional argument of the speed / scale and enterprise-ness of Java over the nimble languages just seems lesser and lesser relevant as these languages start having a nice stack of their own enterprise frameworks and hardware developments whittle away the performance disadvantage. When someone very recently asked me why I was less likely to choose Java for my next project I just said Java is not agile enough. The agility of the nimble languages (no compile-build cycle) coupled with their having adequate performance profiles do lead Java to become lesser capable of competing in the space. By the way one of the real strengths of eclipse is its incremental compilation, but I cannot unfortunately use it with making code changes remotely the way I would be able to change say PHP.

So how can java compete ?

Assuming that java needs to compete with these languages on a better footing, some changes will be required (and some of them quite painful). These will be :

Make java easy to host on multi-tenant application servers

This would definitely require some changes to JVM to reduce the startup / shutdown overheads to make each processes really lightweight. It would also require some attention to how much memory gets utilised. Scenarios such as those I have used in the past to really make applications run faster by caching big time in the RAM are a no-no for multi-tenant hosting. We will thus need a version of JEE which loses the ApplicationContext. We will also need to be able to creatively work with other pools such as connection pools. Finally JEE application servers may need to be restructured to support rapidly dying processes (ie. process per web request). I am no JVM writer so wouldn’t know if some changes might be required to the language but cant think of any major changes that might be required.

Lose the compile cycle

Why can’t “javac” be conditionally executed implicitly at the beginning of “java” process. JSPs generate java on the fly. Similarly python creates the .pyc compiled files on the fly. If the deployment can be done using .java files instead of .class, it would eliminate the compile cycle and allow a developer to change the code in one window, save it, do an alt-tab and go press the reload button on the browser. Compared to all the attention that is being paid to language features like closures and duck typing, I think this is a really really big deal.

How will this help ?

These steps are not targeted towards attracting the developers working in building the corporate enterprise applications (though I am certainly they will break out into three cheers if the compile cycle was done away with - especially in an optional way - ie. the production deployment would still require a war consisting of .class and not .java files). More and more development going forward is going to be characterised by a larger number of smaller applications rather than the old 60s-70s days of small number of large applications. Average applications will get smaller and these will communicate with each other more frequently using web service (REST?) calls. The trend will definitely be towards more in-place remote application reuse by remote invocation rather than through using class libraries. The nimble languages are well positioned to compete in this space. Java isn’t. This will help Java attract and retain developers in a space where currently it is only likely to lose them increasingly. Moreover as application hosting infrastructure starts getting more outsourced and cloud computing gets more prevalent (eg. Amazon Web Services / Google App Engine) Java can at least compete in that space which is otherwise likely to be locked out for it.

Acknowledgement

There are a couple of helpful posts that set me off on the path to blog this so here’s the acknowledgement :

• Facebook vs. OpenSocial
• OpenSocial and Facebook Platform side by side comparison

Introduction

I have been spending some time on the Facebook and OpenSocial platforms, and while these both attempt to solve the same need, they end up doing so quite differently. For anyone interested in web based software design, the differences are both curious and interesting, and serve an interesting contrast of how different means can get used to attempt to reach similar ends.

The Facebook platform

The facebook platform primarily allows the hosted applications to access facebook data through a variety of APIs. The hosted application can primarily draw itself onto a “Canvas” which is the primary channel of interaction, and can also render its own part of the profile, and plug into the messaging infrastructure (news feeds, mails etc.). When a user is working with the canvas, the canvas occupies a large share of the screen and thus dominates the interaction with the user.

The OpenSocial platform

The Open Social platform does not really require the applications to be hosted (they can be purely client side applications using HTML, XML and Javascript). The application presents itself as a gadget and can get information about the network graphs fed into it at runtime. When I refer to a client side application I shall be referring to the gadgets with type=html whereas when I refer to an application as a server side application, I am referring to those applications which are hosted with type=url.

Now for some of the important differences.

1. Application Structure

OpenSocial applications can be both client side and server side. Most of the specification and almost all the examples are those of client side applications. These typically require a high competence in HTML, XML and especially in Javascript. The applications can also be server side but this does not seem to be a predominant mechanism of application serving as yet.

Facebook applications are all hosted on a web site. These typically require a reasonable amount of server side development using a variety of languages. PHP and Java client libraries are provided and supported by Facebook. However client libraries in other languages are also available.

2. Application predominance

In facebook one application is predominant at a time since the canvas it is provided occupies a majority of the rendered screen space. It is not yet clear how most OpenSocial applications will get presented, though it is quite likely that many of these will coexist on one screen with different independent spaces assigned to them

3. Control

In facebook, the facebook site itself acts as a reverse proxy between the browser and the application with some substantial mod_rewrite functionality. It thus intercepts the traffic and actually changes the data stream on the fly (eg. by changing all the javascript variable names). The facebook site is always firmly in control.

In case of OpenSocial, the application is provided a space for its gadget to be hosted, and after that the application is firmly in control ie. the browser communicates directly with the application.

4. Development Skills

Facebook application development skill requirements are likely to be more similar to those required by the conventional server side application development. However the developers will need to learn the facebook platform apis and technologies (eg. rest apis, FBML, FQL etc.).

With OpenSocial if the application is a server side application, the development skill sets are likely to be similar to those of typical server side application development with a lesser requirement to learn newer APIs. However if the application is a client side application and you don’t have serious javascript capabilities, be ready to invest in that quite a bit if you want to create a slick app.

In a scenario where one is using a client side Open Social app, it just seems like the entire controller is getting moved over to the client, and it takes some substantial skills and effort to work through all the interactions in Javascript. I like HTML+Javascript, but dont particularly look forward to writing any more than what is necessary. I generally found that it was relatively faster to work with creating Facebook apps especially in scenarios where a reasonable amount of server side processing was required (FBML is quite helpful).

5. Application or applet

While one can potentially build both applications or applets with both the platforms, seems like the focus of Facebook is to build applications while that of Open Social is to build applets (small focused functionality) which primarily seems to stem from the fact that OpenSocial borrows heavily from the Google Gadget infrastructure which itself was not focused on heavy duty application development.

6. Usage of IFRAMES

OpenSocial is likely to depend a lot more on the usage of IFRAMEs. While older facebook applications used IFRAMEs, many contemporary applications do not. Combined with the fact that due to Facebook acting as a reverse proxy, which ensures that the data stream is coming from a single domain, some of the difficulties associated with IFRAMEs especially for passing information across domains and usage of SSL with IE (where I’ve in the past faced some difficulties) can be avoided easily in Facebook.

7. Security

I am going to go on a limb here and make a conjecture here - Given facebook’s reverse proxy structure and given the fact that its platform had some reasonable time to develop (unlike OpenSocial which just seems like a lets make Google Gadgets into a platform API as fast as we can approach), its “probably” going to be tougher to build more secure applications under OpenSocial

8. Platform data is being pulled or pushed ?

In case of Server side OpenSocial applications, the relationship graph and user preferences are pushed into the application as a part of the URL itself (reminds me a little bit about dependency injections - except that it is being done for data). Additionally the application can communicate with OpenSocial platform through REST based APIs but these specifications are currently still in progress. In case of client side applications, this data is pulled from the OpenSocial platform and mashed up with the application data on the client side.

Facebook also supports the pull and push models but a little differently. While it has a well defined REST interface along with the corresponding language bindings into PHP and java, it allows the application to pull data from facebook as well as push it to facebook (eg. to write to feeds). However given the reverse proxy structure, in a way Facebook is really pulling the entire application content from the application before it mashes it up on its site (eg. processing FBML tags or changing javascript variable names) before sending it to the browser.

9. Standards compliance

Clearly OpenSocial could be “considered” to be more standards compliant. However that is a rather mixed blessing - All the proprietary facebook additions eg. FBML tags actually help reduce a fair amount of development effort with no equivalent capability in OpenSocial yet. There still are many things that Facebook platform supports which are as yet unaddressed by OpenSocial, so I am not so sure if the issue is so important yet. But as OpenSocial starts offering more capabilities in future versions this could start becoming an issue.

Summary

Clearly there exist quite a few dissimilarities between OpenSocial and Facebook platforms. These differences are sufficiently large enough to tempt me to call them apples and oranges (though their end goal is to feed me). It would be wise to avoid the question “which one is better ?” However I can indeed state that as a developer having spent a large time on building server side enterprise applications, facebook just seems to be a lot more enjoyable to work with along with it likely to be more stable and more secure. But remember YMMW (some people like apples more and others oranges).

In my earlier post OpenID or OpenAvataar ? UserID or AvataarID ? , I referred to the fact that a user may have multiple OpenIDs (my hypothesis being that these will reflect his various avataars). The question I attempt to answer here is how will usage of OpenID impact the design of the software itself.

Case of a site with OpenID integration

Here’s where things get interesting. One of the sites I went to dzone which is supposed to be for developers. It supports OpenIDs, but when I try to go to the registration page, here’s what I get.

Notice that the site seems to be supporting an OpenID login (bottom right) but yet goes on to add the following : “You will need to set your password using the one-time link you received in your email before you can login.”. I could not find any way of using my openID without the site creating a new user id and a password for me that it would send me to my email address. (And this is a rather geeky set of sites which seems to implement a single user id across JavaLobby, EclipseZone, dzone and JavaBlackBelt.). Clearly this was not how I believe OpenIDs were intended to be used (remember they are supposed to reduce userids and passwords) since the site expects me to create one more userid and one more password.

I shall assume that these sites are in the middle of a incremental transformation towards an OpenID oriented site and hopefully at a future date, I can simply register myself using my OpenID without creating any new userid or password.

Design considerations when using OpenID

I submit the following as requirements for any OpenID based account registration

• My OpenID should be my userID / accountID (i.e. I am my OpenID)
• I should not be required to provide any new userid / password
• I may be required to provide additional information required by the site which is not published within my OpenID

But wait a minute we just went past the hypothesis that multiple OpenIDs could map to one Identity (UserID?). If that has to hold true, I need a new user id to be created so that I could map multiple OpenIDs onto it. But that seems to only exacerbate the problem that OpenID originally tried to solve. ie. the runaway number of userids that I seem to be having. Clearly something does not line up well here.

The one reasonable way I can imagine this working out fine is if the site itself focuses on the Avataar / Persona / OpenID and not necessarily the user’s unique Identity. ie. The site just keeps track of Avataars and does not attempt to link it into one single user id, and does not create a password for the same. Now me as an independent professional in my individual capacity and myself as the agent of an organisation could log in into the site independently as different avataars, and the site could treat each of my avataars as simply equivalent to what would’ve otherwise been two different userids. Thus the site no longer needs to keep track of my userid or my unique identity. It simply keeps track of Avataars or Personas, and in general does not focus on specific person’s identity.

However there are some sites which require user identity specific information (e.g. Online Drivers License Renewal assuming thats allowed in your region). Clearly in such situations, additional attributes would need to get attached to the avataar which reflect the specific user identity (actually more likely - the OpenID would need to get attached to the specific user identity). Whether one should require a unique constraint around such additional attributes (eg. two avataars cannot have the same drivers license number) is probably an site / application specific decision.

It is also quite likely that I might want to change the OpenID I use for a particular avataar. So there probably needs to be an internal unique identifier for the avataar, with an ability to change the OpenID that is used to login as that avataar (similar to the ability to change the primary email address). This actually is something which the OpenID spec does not address, thus transferring the onus of maintenance of such a mapping between an OpenID and an application / site specific avataar id (which probably just would end up being an internally generated number). As an aside this is something inames does tackle explicitly

This means all global i-names have a corresponding global i-number that represents a permanent identity that will never be reassigned even if a global i-name expires or is sold.

Do I need a password field / column ?

If you are supporting OpenID users only then you no longer need it. But if you are supporting both site specific userIDs and OpenIDs you will still need to conduct authentication for the site specific userIDs. If you are building in support for OpenID in an existing application, you will probably keep the encrypted password or the password hash in the password column for the site specific user ids.

If you are building a new application however, and you still want to support users who do not have an OpenID, consider building your own OpenID provider. Thus generate an OpenID for such users only when required. Have the User Account Maintenance capabilities simply depend upon an OpenID provider (one of which could be your own). Should you want to get started on using some open source OpenID providers here’s a list of OpenID Open Source Libraries .

Summary

1. Design for new user registrations using only their OpenIDs ie. no new externally known userid or password
2. If migrating towards a OpenID based infrastructure, you will need both non OpenID and OpenID users to coexist.
3. Map the OpenID onto an internally generated and externally invisible id.
4. If you want to allow users to link up their multiple OpenIDs, build for associating each such OpenID with the same internal Id. In this case users can freely add / remove other OpenIDs, subject to the constraint that at least one OpenID always remains associated with the account.
5. If you would like to deal only with the user avataars and offer separate view of your site to each of his avataars, the ability to link multiple OpenIDs together may not be required. However do allow the user to change his OpenID (since he may find a good reason to want to change his OpenID provider in the future).
6. If you are interested in supporting only one id per person consider using a different externally known identifier that uniquely identifies the person (could be the social security number or driving license number or something else). That should be the internal handle to the user which is enforced as a unique identifier (you can still choose to have another internally generated id). You can now associate one or more OpenIDs with that user and allow any one of them to be used as the authentication mechanism.
7. If you are building a new application ground up, consider designing your application to work with OpenIDs alone. To cater to users not having OpenIDs, build a separate small application to allow them to create and maintain their OpenIDs

Introduction to OpenID

Lately with the prolific activity around OpenID and especially with a biggies like Yahoo and AOL , I was getting curious about how this will influence identity management both on the public internet and corporate intranets. One of the nice starting points to understand OpenID is OpenID » What is OpenID , and for developers is OpenID » developers

How many OpenIDs per person ?

The OpenID » What is OpenID page says

OpenID eliminates the need for multiple usernames across different websites, simplifying your online experience.

This is a wonderful thing to happen, since we have been sufficiently bothered with trying to keep track of a whole bunch of userids and the passwords. It further goes on to add

For businesses, this means a lower cost of password and account management, while drawing new web traffic. OpenID lowers user frustration by letting users have control of their login.

There is some correlation that is now being drawn between an OpenID id and an “account”. However it is still not yet clear what the OpenID reflects. Further it goes on to add

For geeks, OpenID is an open, decentralized, free framework for user-centric digital identity

Now I start wondering does my OpenID reflect my user-centric digital identity ? Turns out I can have as many OpenIDs as I want. So there seems to be a many to one relationship between my OpenIDs and me.

This then is further reinforced in one of the articles that are referred to from the developer page A Recipe for OpenID-Enabling Your Site . This page contains the following text :

Here’s an overview of what you’re going to add to your site:
1. A new database table to map OpenIDs to your internal user IDs
* It’s a many-to-one relationship (each user can have multiple OpenIDs attached to their account, but a given OpenID can only be claimed by a single user)

The OpenID specification of course provides the most appropriate and insightful definition of OpenID even though it kind of has us wondering - what is the ID in OpenID (and leaves us with the loosely comfortable with the thought that the ID is simply an ID in the web space and has nothing to do with User Identity).

OpenID Authentication provides a way to prove that an end user controls an Identifier.

So it seems sufficiently clear that an OpenID is not meant to reflect my identity the way my Tax Identification Number or Social Security Number or Drivers License Number works (ie. exactly one valid identifier per person at any point in time).

It is now clear OpenID reflects what I own (to the exclusion of others) rather than who I am. My OpenID does is not a unique or exclusive reference to me or any of my identifying characteristics as much as it asserts the fact that I control the ID and therefore others don’t. But that still leaves me thinking even harder - how many OpenIDs do I really need ?

Why would I want to have multiple OpenIDs.

Sure having multiple ids is nice since I now have multiple providers, I am not tied to any particular one, I can have redundant ids. etc. etc. The reasons are quite similar to why I might have different email ids. Turns out at least in my case the most dominant reason why I would want to have different open ids is the same why I would want to have different email ids : I have different facets to my identity and I would like each to be reflected differently. Thus I might want to have one OpenID to reflect my persona as a professional consultant, another to reflect me in my personal and individual capacity, and yet another to reflect my persona within the context of a particular of a client / project / organisation. This way I could use my personal openID across all my social networking sites, my professional one across a smaller number of professionally focused sites, and probably my organisation specific ID being used for sites hosted by a particular organisation which really isn’t focused on my global identity but wants to create and independently manage a single ID within that organisation. The number of OpenIDs I would want to reasonably maintain is the number of personas or avataars I want to project on the web. Thus I probably need 3 avataars instead of 1 identity or the hundreds of site specific userid/password combinations I today have. Probably I can better understand the word OpenID if in my mind I was to call it OpenAvataar. My Submission here is that each person may have multiple openIDs and we shall probably be using each one to reflect one avataar. This is likely to be the primary reason why each person may have multiple OpenIDs”.

Summary

• An OpenID does not exclusively identify a particular user. It simply asserts that users control over the OpenID.
• A user may have multiple OpenIDs. My hypothesis is that each of these is likely to reflect one of his avataars

Yesterday this blog post was top of the charts in javablogs.com daily mail to me (Don’t bother clicking on the link since it seems to have been taken offline at least at the point in time I compose this post).

Quitting a job

I immediately got a little curious and looked up the same on google cache. - Quitting a job - from google cache

Here’s my quick learnings from the incident :

1. Group blogs probably need stronger access controls or code of conduct. Not sure (though I could attempt to speculate for myself) why it got taken off - it actually seemed quite innocuous.
2. Title Matters - I think the post was at the tops since the title evoked an emotive response.
3. Emotive issues override focused topics. Javablogs.com readers are supposed to be interested in reading posts on java - right ? Well this post beat the following popular posts by a handsome margin some of which would seem to be rather much more relevant to an audience primarily focused on java blog posts.
   • Which one do you prefer; Liferay or JBoss Portal?
   • Wow: a Java application with 25 megabytes of JAR files
   • Thanks Zed, Java evolution, Ruby and Scala Pimple Pimping
   • Death to Ant
   • James Gosling and MySQL’s Monty Widenius, David Axmark, and Brian Aker on Sun’s MySQL Acquisition

Looking over at Yahoo Pipes! , I had a curious idea. Could I use it to create one composite feed of a variety of rss feeds that I use today ? I created an as yet simple composite feed comprising of On Java, IBM Developerworks - Java , TheServerside.com and Java Blogs Hot Entries . I selected the first 10 items from the first three and 20 from the java blogs.

These are a couple of views on the same pipe.

• Stay Current With Java - RSS
• Stay Current With Java - Yahoo Pipes Page .

The feed has currently 50 items and I would like to roughly stick with that number - just so that thats a feed that I can review once when I start the day and perhaps once when I end it.

Would you have any suggestions in terms of either the content providers or the filters one can use to make the feed more useful ?

Google set off this new term knol (unless it has been around before and I am not aware of it) in this blog post .

First of all the screenshot is both attractive and impressive. While this has more to do with the folks who created it rather than the concept of a knol, it sure seems like a screen design worthy to take on Wikipedia .

As an aside seems to be that four letter words are rather becoming the in thing in the recent contribution to english language : blog, wiki, and now knol.

There’s already some speculation out there whether this will mean a google taking on wikipedia, about , or a whole host of other sites that are being talked about.. I don’t intend to speculate on that here. One of the apparently salient points about a knol is the fact that each knol is authored or primarily edited by one person, whose information is boldly displayed.

There are cases where content needs to be personalised and others when it needs to primarily collaborative. Wikipedia and many community maintained wikis are a great example of collaborative content, whereas blogs under most circumstances offer very personalised (ie. individually authored – not individually tailored) content. This is a reflection of whether the content needs to be a community or an individual view.

Another dimension is the targeted persistence duration of the content. A blog posting like this may be far less relevant a year down the road, than say an article that I write on this blog.

Wiki or Knol

Read the rest of this entry »