My Little Take on Backend Development

Update 29-10-2012:
I found this blog post more comprehensively in defense of Java EE 6.
Original post:
This comes from someone who only just recently read about JTA and JTS. Take this with a grain of salt, so to speak.

I have some experience using the Spring Framework, mainly the Spring MVC sometime about 2years ago, and some again just recently (as indicated in my previous post).  Back then, it was first a multifinancing application, second a message broadcasting engine, sort of.  Neither of which I created from the ground up.  I was merely adding features and so on.  I couldn't compare it against the Java EE 6 at that time, lack of understanding of their internals and so on.

The message broadcasting engine had to be improved so that it could support more load.  There were topics such as clustering, high availability, parallelism, concurrency, etc.  I think it was then that I came across the JMS and some asynchronous processing features provided by the EJB 3.  That was to be my gateway to Java EE 6.   Afterwards it was a haphazard series of choice to learn the actor model, CSP, Scala, Erlang, Haskell, NoSQL, etc.

So I wonder what was it again, Spring Framework's winning points.  Their documentation is among the best.  Their framework itself is rock solid, for what it is.  What it is, really, is a little confusing, though.  It appears to be sort of an alternative to the Java EE stack, but heavily relies on it.  It manages the object lifecycles.  Java EE does that as well, manage object lifecycles.  Two things manage your object lifecycles.  Obviously you can run Spring Framework on a standard servlet container, but I see everywhere that it is recommended that you use, say, the JTA provided by the container when available.  It would be unavoidable that both containers will manage the object lifecycles if you used CMT alongside Spring.  And how is it that one could share a bean across deployments in Spring?  Even if you could, I think using Spring remoting, your object lifecycles management would be more complicated because it would be a communication between two unrelated containers.  It looks to me that the EJB specification is superior in this regard, with its local and remote beans concept and tighter integration with JTA and the rest of the Java EE specification.

Anyway, honestly I'm not a big fan of dependency injection, Spring or CDI.  It's a little too much magic for me.  Language level singleton object construction available in Scala and programmatic lookup and vending are easier to work with.

Here you don't know what's there

Quite some shift having worked mainly at companies that were open source-centric before, now at one that endorses proprietary enterprise platforms.

I have found that latter such companies don't recognize open source efforts and startup solutions.  It is a mystery (to them, at least) how Twitter has managed so far with obscure languages like Ruby and Scala.  It must be a joke to claim Google used commodity hardware for their servers.  When you have a USD 30K DBMS you have no reason to consider NoSQL toys.

Whereas at my previous workplaces we would probably be rolling our eyes, thinking why we would ever need it, when offered, say, a USD 30K DBMS when we ran everything on PostgreSQL just fine.  Yahoo! did it with PostgreSQL, why couldn't we, right?  We could implement Hadoop and Cassandra for specific tasks if they fit better than they would on PostgreSQL.  If everything were still slow, it would be the development team's fault, of course.  Couldn't have it any other way because, otherwise, why hire us at all.

But of course, experience will vary depending on how one makes use of either technology.  Many proprietary products do excel at what they do.  And it is only natural that people spend money on these works.   I'd think the distinction is that at one (extreme) end you see lots of money and at the other (extreme) end you feel a great deal of passion (and both are perhaps equally reliable catalysts of creativity).  This isn't a rant on merits of either practice--not that I have authority on that topic to begin with!

What this is about is how easily we turn a blind eye to the other side when we've been delving in just one side of the equation for long.