Tuesday, December 20, 2005

Frameworks v. Components

There is a new found enthusiasm surrounding the proliferation of Java frameworks, and there is growing support for these frameworks, including some of the larger Java companies, such as BEA. But this is an old discussion, and one that was presumably solved some time ago, especially with the introduction of Java web services and SOA. But when backed in to a corner, or when you have not figured out EJBs, you may play with the non-componentized frameworks. I am travelling in territory where I am not an expert, and could be corrected by someone like SS or Raible. However, it would seem that through the splintering of frameworks, a splintering of Java is being attempted. This cause is being led by the man who previously worked to spread the image of Java portability - - BR (get a haircut), but who is now pointing out the benefits of non-Java solutions. It makes one wonder if someone in his position can make the switch so seamlessly, or was there some disingenuity to his previous employer. Makes one wonder...

What I need to know from the esteemed Java community is what benefit are the frameworks bringing to customers, because it sure does not seem like it is bringing relief from proprietary extensions, thus lock-in, thus no portability, and thus increased costs. Is it shorter time to market? O.k., welll that is a pretty good argument, but it is also the one espoused by .Net. So what are the Java people doing in the land of frameworks? They are running for cover from the impending implosion of license revenue via proprietary extensions that will come with component services. I will coin the term. It is not web services, that is for Google. It is not SOA, that is for the infrastructure players, of which Sun and JBoss rule JBI, while IBM and BEA work on SCA (ou est, ORCL?). Rather, it is component services that will be the major part of the developer toolkit, that will transform the apps we use from intranet to extranet functionality. Its been 10 years since Netscape started the marketing for extranets, and it is only a decade later that the goal will be fulfilled by the Java Enterprise developer community.

Why are frameworks not going to work? Well, they're not really Java. They're a combination of Java and hooks, and other things you don't want to see if you're a business manager, but you must see if you're are a developer. So when the Java development community must come in to clean up the mess, the original implementer of the framework could be long-gone. Why not just build standard components? It's the best implementation of JEE, and it has longevity because of backwards compatibility and portability, two of the hallmarks of standard Java. I listen to BEA make their claims of development demand toward frameworks, and it reminds me of their claims of the Java web services extension that was built with WebLogic Workshop, which would "soon" become standard, though never did.

What we need is a community process toward componentization, so that companies such as Siebel do not steal the luster that they have been trying to undermine for a decade, due to their definition of proprietary Java. This includes SAP and now Oracle too. The only companies staying true to compatibility are Glassfish and JBoss, with the possible exception of other open source app servers. The rest of the software industry is running for cover from the nuclear bomb that is standard component services. Once it hits, it wipes out all license revenue in its path. That is not to say that these companies will go under, not at all. But they will be playing by the rules set by the Java development community, and it won't be the part of the community following frameworks.

Back to the silence, no more dropping science, e'rybody rhyming about diamonds and violence...

0 Comments:

Post a Comment

<< Home