It is when reading news like this that I feel very grateful for being part of the Java community, where openness is the spirit, and where I don’t have to lose sleep over worrying being hauled into a court by an army of corporate lawyers.

“This goes to show that no matter how secure your technology may be, it can be completely circumvented by the simplest (and dumbest) of human actions.” -RyanD

“When I see things like this I get a real urge to contact the responsible autority and get those idiots removed from the IT genepool. This is actually as scarey as it is funny. There could be muppets like this working at your bank!” -voyager

Also known as the “Oscars of the Software Industry” the winners were chosen by more than 17,000 SYS-CON readers.

OK, I knew I was going to bite something even before I started reading the news, but honestly, there are so many baits I don’t even know where to start. I can just skip the obvious ones like how Eclipse was voted Best Java Application, Best Team Development Tool, Most Innovative Java Product, Best Java Debugging Tool, Best Rich Client Platform(Eclipse Platform), Best Java Class Library(SWT), but miraculously lost Best Java IDE to Intellij IDEA. But, “Oscars of the Software Industry”? Since when did “SOA, Web Services, Java, and XML Technologies” amount to the whole “Software Industry”? What about LAMP? What about Microsoft – come on, you might not like them, but you can’t deny them.

And these “Oscars of the Software Industry” were chosen by “more than 17000 SYS-CON readers”? I’m sorry, last time I checked, the Oscars of the Movie Industry are voted by the Academy of Motion Picture Arts and Sciences, not “the 343293 Entertainment Weekly readers”, or “the 39860923 E! viewers”.

So I went on and did a bit research (OK, OK, I really just googled “define: Scalability”), and got these definitions. Let me just quote the first three here:

The ability to scale to support larger or smaller volumes of data and more or less users. The ability to increase or decrease size or capability in cost-effective increments with minimal impact on the unit cost of business and the procurement of additional services. – dmreview.com

The ability and flexibility of an application to meet growth requirements of an organization. – hostqueue.com

The ability to expand a computing solution to support large numbers of users without impacting performance. – primode.com

So scalability is about performance – the capability to handle large volume of traffic, as far as web applications go. It does not have anything to do with “miminal service interruption when one of the servers goes down” – that’s High Availability. It especially does not have anything to do with “no service interruption whatsoever” – that’s Continuous Availability (see the last link). We usually don’t need the expensive state-replicating schemes to achieve Scalability, or even High Availability. A sticky-session load balancer and a server farm without busily replicating sessions among themselves would scale well, and would provide some pretty high availability. It can’t provide Continuous Availability because when a server fails all the users on that server at that point would have lost their sessions. That’s the only case where clustering comes in and support immediate fail-over without any interruption to the service.

Now, the real question for all you architects out there that can’t wait to hop on the “clustering wagon” the second you hear “scalability” is, is your application really “mission-critical” enough, meaning no user can ever lose her session, to justify the cost to implementing clustering? Remember the cost here includes not only the performance penalty (ironic isn’t it), but also the development penalties – you’ll have to make sure that whatever you stick in the session implements the Serializable interface, that whatever you stick in there references does the same, and finally that not too much is stuck in there.

On a separate level, I don’t necessarily agree with Diego’s comment (his main point actually) on Spring being not scalable, either. The fallacy here, IMHO, is the same as what I have seen from a lot of other online discussions. It’s that people keep trying to compare Spring with EJB, forgetting they are different things and meant for different things.

What is Spring? Even though we all refer to Spring as a container, we have to remember that it’s a completely different kind of container from the kind EJB is. Spring is a bean container, or rather more accurately, as the name of one of its core interfaces shows, it is a bean factory. All Spring does is providing us the ability to transparently wire up our applications, and the convenience to easily integrate with lots of third-part tools, but Spring does not reinvent the wheels by reimplementing those tools on itself. E.g., Spring provides easy integration with well-known ORM tools such as Hibernate and iBatis, rather than providing it own ORM package. On the other hand, EJB is a container in the real sense of “All Your Base Are Belong To Us” . It provides a complete solution with a more restrictive programming paradiam. Spring is not mutually exclusive with EJB, nor is it a competitor of the latter one. You can use Spring to wire up an EJB-based service layer just as easy as you do, say, a Hessian-based one. Comparing Spring to EJB is like comparing apple and orange.

A lot of people won’t feel good today, but I think I can name one who would feel particularly bad – Steve Case. Well, although I never liked AOL (remember all the busy signals?), he sure has my sympathy. At a different level, I don’t feel good either, as this was supposed to be an ideal marriage between the classic media and the new Internet power. Moreover, This ending is probably the worst one that could have happened. Even a spinoff of AOL that effectively cancels the merger would have been better – at least that would imply an AOL that could live on it own value, however much that would be.