While Sun is quite diligently planning, coordinating, and building infrastructure for building cathedrals around J2EE, Microsoft's .NET is poised to steal the marketplace and own the bazaar, as they did with VB and the component market in the client-server wars. We have some parallels to go by. While CORBA focused on rearing thoroughbreds, COM stole the market with a mule called VB.
The only way out of this quandary is to wake up and invite the J2EE cathedral to the bazaar. (Both words are used in a positive sense in this article.) I believe there is a lot at stake; not only for Sun and Java, but also for regular programmers like you and me. The potential of enabling programmers of all kinds to this work in this wonderful world of the Web is a prize worth contending for.
Web programming flourished even before Java entered the market space. CGI, Perl, PHP, and ColdFusion have dominated this space. Programmers are eager to build systems that are driven by relational databases. There are millions of programmers who understand the Web space very well and are looking for scalable and robust architectures. Here is a list of the kinds of APIs, tools, and facilities used in the Web bazaar on a daily basis, and a general description of the kind of developers who use these tools.
J2EE is an enterprise-level framework that can do a stellar job of providing solutions to the IT market space. The increasing levels of complexity of J2EE with each release meant that only IT departments with large budgets could make the most of J2EE. J2EE, without the right tools, is not approachable by a common programmer. Let us take a look at the series of things that a programmer has to know to effectively utilize J2EE:
As a Java programming community, we are at best disingenuous when we propose: "Come on in, it is a piece of cake. Let us do Servlets, JDBC, JSP, and J2EE." To design good J2EE systems (with the existing J2EE infrastructure) you not only need good designers but good Java programmers. And good Java programmers don't come cheap. Companies end up spending lots of money to produce systems. It is not difficult to prove a 5x increase in cost from failure to realize this.
The question at hand is, how can you make J2EE accessible to your everyday programmer who is not steeped in Java experience? And "everyday programmer" is not a homogenous group. It includes database programmers, Unix system administrators, fresh college grads (both computer science majors and otherwise), and legacy programmers (transitioning from mainframe disciplines to Web-centric programming).
How can we take the J2EE infrastructure and make it palatable to this varied set of communities? The key is to distill the minimum they need know so that it can be taught in a matter of weeks as opposed to months and years. We should start out with teaching the bazaar skills first. The only complex skill set among the bazaar skills is database programming. If you already know database programming, you are already way ahead of the game. A database programmer knows the following important skills:
Similarly, Unix system admins have an inherent advantage as well. They usually know how to set up Web servers and are fully aware of URLs and CGI. The only skills they need to learn are a set of database skills.
For the other two categories, you have to teach both the Web programming skills and the database skills. This could be easily done in a couple of weeks. The next question is, how can we take J2EE and allow these programmers to be effective immediately?
A good tool should stay out of the way when it is being used. J2EE is no exception. J2EE middle tier should be completely hidden behind a declarative middle tier that allows programmers to directly work with their presentations, data, and business logic. This should be done in an architecturally controlled environment where the following properties are preserved:
The tool that brings the Cathedral to the Bazaar should be able work with a set of abstractions that are familiar in the Bazaar. For example, if you are able to make a SQL call and see its result in the confines of your database, it should be no more difficult to see the same results on a Web page. Moreover, you should be able to see that data as XML, HTML, or some other format. The mechanics of how this could be done are not that hard. The question is one of focus with the tool builders. What are they focusing on? Are they focusing on EJB-enabled IT or are they focusing on the mallable Web-based Bazaar? I believe the following tiers will help bringing J2EE closer to the masses.
Under such a tool you can expect the following:
One important question that we can quantitatively answer is this: if I were an experienced Bazaar programmer, what skills would I need to run my programs on a J2EE framework?
Here is the list of skill sets I foresee you would need:
Once a programmer is taught these basic skills, the declarative nature of the tool could allow these programmers to immediately integrate their skills to create a fairly complex database-driven Web application. As the business logic is allowed both in Java and non-Java paradigms, such a tool will allow the programmers to learn Java in a gradual fashion. The framework is responsible for the stability, transactions, and modifiability.
One can see a demo of some of these concepts explored at http://126.96.36.199/aspire/ This demo is running using Tomcat 3.2.1 and a very low-powered PC. So, with a little patience, you should be able to see how a table worth of data is collected and presented as part of an HTML page. This should demonstrate the following basic facts:
Let me raise the bar a little bit. One might say, "Well, this is too simple." Let me show you another demonstration where the collected data is in fact presented as a set of graphs (pie, bar, etc.). Again, all of the charts you are seeing here are done declaratively and using no Java. And even where Java is used, it is only used as a transformational language (as JSP). Here is the Web link for it: http://188.8.131.52/aspireCharts/demo.html
This article is born out of multiple questions from programmers that are new to Java server-side programming on how they can become effective J2EE programmers. The urgency of an answer became imminent as .NET is getting released to enthusiasm that it makes it extremely easy to write Web programs.
It can be extremely easy (fewer lines of code, less bugs, etc.), and cheap, in the J2EE realm as well. One doesn't have to abandon J2EE when simplicity and productivity is at stake. J2EE can be as productive, if not more, as .NET. But focus has to shift to the Bazaar commerce and not necessarily how to build better cathedrals.
Satya Komatineni is the CTO at Indent, Inc. and the author of Aspire, an open source web development RAD tool for J2EE/XML.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.