Glassfish Version 2 is out. And what a release it is.
The first release was focused on single instance deployments and developers. This release throws in the works. It has the features you need to run this puppy in an enterprise environment: clustering and HA (including a new in-memory replication feature using JXTA), serious administration and console, record-setting performance, all in a single all-in-one 50+MB bundle rather than confusing users with three separate versions.
I think it's worth looking at how far this team has come and what they have accomplished by looking at a little history (from the biased perspective of yours truly :)).
When I first joined Sun, I was part of Clustra, which became the Database Technology Group here at Sun. We came with a modest little 5-9s highly available, highly scalable RDBMS that was named HADB (Highly Available Database).
I was asked to architect a clustered version of the app server that used HADB as the session store, so I was working very closely with the app server team.
At this time the team was in the middle of completely redoing the app server to move away from the basically overwhelmed and broken C/C++-based codebase inherited from, if I recall, three different app server acquisitions: Netscape, Kivasoft, and NetDynamics.
They were redoing everything by taking a copy of the Reference Implemention, built in 100% Java, and making it "production grade" in terms of features and performance.
It was a difficult and ugly time. The two teams (RI from old Javasoft and the Netscape/Kiva/AOL/you-name-it team) were not getting along very well, and emotions were high. We used to call the Java team "Church" because they were such sticklers for compliance and elegance and we called the production team "State" because they just wanted to get something that customers wanted, that performed, and that was delivered on time.
The processes in place at the time were, well, shocking. They regularly could not get a build to work, and the performance was getting regularly worse instead of better. The product was months late and we had nightly pow-wows with executives to track a dashboard where most of the line-items were red.
I remember trying to get a copy of the codeline and build it. But things were so non-open-source that you had to be on a machine within the Sun network that could auto-mount the necessary drives that contained supporting binaries and infrastructure. In other words, given that I worked from home, I couldn't build it on my machine, and I couldn't find a machine that anybody would give me access to that had these mounts. Pulling down the cvs tree took hours, and then my attempts to build got regular failures. I finally gave up.
After a year, I moved on, and started working on Apache Derby. I have to admit it was a relief...
Since then, I have watched with joy and amazement what the app server team has done.
I have watched them go through the painful process of merging the two codelines (RI and Sun Java Application Server based on the RI) and merging the two teams.
I remember them making the bold decision to take this massive code base and open source it, even though there was already a market-leading open source implementation (JBoss).
I saw them use their blood, sweat and tears to deliver an implementation of Java EE 5 immediately after the release of the spec.
And I started noticing incredible improvements. Getting and using Glassfish has become easier and easier. Today I can just download the bits, put it in a directory, run a simple install script, and voila, everything works. I started hearing users and reading blogs saying, basically, "hey, this ain't half bad. As a matter of fact, it's pretty cool!"
I started feeling proud of our app server.
Then I saw a demo last year of their new modular architecture (coming in version 3), with a sub-second startup time and intelligent auto-loading of modules, and I was just astonished. This was the same app server that I had worked with four years ago? That day over lunch, a Glassfish competitor sharing with me when he saw that demo, he knew that they were in serious trouble.
So, many, many kudos to the Glassfish team. You have done an incredible job, and I am proud of you.
4 comments:
hi there,
good to know the history bits.
The question for Sun and the community to ask is :
"Good to know that Glassfish v2 works and has good functionality.
BUT...... Since I'm already using a) Tomcat OR b)JBoss, what does Glassfish have that will make me replace the current appserver ?
I know that Glassfish has many features that the mentioned appservers don't have. It will take a lot of effort from Sun to convince the community that a ONE-SIZE-FITS-ALL will work for them.
I'm thinking that Glassfish v3.x should come up with a Glassfish Lite version which is only a servlet/JSP container PLUS the HA/Cluster feature.
Without the Lite version, many customers will sneer at the 50MB download size.
It'll be interesting to see how soon SUN can get ISPs to offer hosting services based on Glassfish. That will be the crucial step that Sun needs to do : make it easy to deploy/host java apps! That has been the BIGGEST FAILURE from sun all along.
BR,
~A
Hi, Anjan. Great feedback!
Convincing someone to switch is a personal experience -- it depends upon your requirements. I would say you should identify the key requirements of your system - be it a particular feature, performance, support costs, long-term viabaility of the company behind the product, and so on. Then do side-by-side comparisons and testing and decide if it's worth the effort to switch.
Also, there is a migration tool, guides and people ready to help with your migration if you choose to do it :)
In terms of a "Glasffish-lite" - it's not exactly what you're looking for, but you might take a look at the incredibly light-weight (152K footprint), super-high-performance (uses NIO networking) HTTP server from the Grizzly project, which also acts as the HTTP kernel for Glassfish. No, it doesn't include clustering - I know what you're looking for -- please rip out all the Java EE stuff -- and I don't know if there's something there.
I do know that v3 is based on a very modular architecture, and one could potentially create a configuration like the one you speak of. Have you asked the glassfish user alias about this?
Very interesting comment about ISPs. Not being on the team, I really don't know what they're doing around that.
David
ISP deployment without some kind of JVM support I think would be spectacularly difficult.
For casual applications, it may not be such a big issue. Basically for WARs of minimal to medium complexity.
Perhaps even with the future Java Module API, there's some hope.
But when applications get complicated, when they start fighting over XML implementations, then the app servers become the bastion of "Classloader Hell". In some applications its difficult enough to get it running alone within a container that you have full control over.
Then you have general QOS and SLA functionality. The major app servers are more designed "friendly" applications. But throw in some poor souls latest alpha release laced with endless loops and memory leaks, and any other application deployed within that container is going to be having a bad day.
Heck, in theory, you can't even kill a thread that's in an endless loop in a JVM. So, any badly behaved application can potentially force a container restart.
I think that modern hardware specs and VM services (Zones, zen, VMWare) are going to outpace any work done at the JVM level to give the kind of control a public host provider would most likely enjoy.
GF v3 and JEE6 are just going to blur the lines that we know today of what an app server is.
When you have a system that you can toss a generic WAR with a bundled Session Bean, and can load services on the fly, we'll have a very nice lightweight option over what we have now with GF. No EAR, no descriptors, just some annotated bean soup.
That'll be nice.
David, nice post. You prompted me to do my own brain dump on the history of Applications Servers at Sun.
http://blogs.sun.com/page/sharps?anchor=fish_genealogy
Post a Comment