Most Read This Week
The Theory of Innovation
Turning J2EE into J2EE-easy with better tools and JSRs
Jun. 3, 2004 12:00 AM
We know from the theory of relativity that the passage of time is relative to the perceiver. This is true of history as well. Sometimes history moves fast, e.g., during World War II and when communism was crumbling in 1989. Sometimes history moves slowly, as in the Cold War and the period between 1991-2001.
The same can be said of innovation. Sometimes a lot of innovation happens all at once as in the boom years of the Web from 1998-2001, and during the early days of Java - 1994-1995. Sometimes the pace of innovation slows to a crawl and other forces, principally economic, take precedence.
The J2EE platform is in the latter state at the moment. Much of the innovation has already been done, and most of the work being done now is "fit and finish" work. The net effect of this is that the application server vendors are innovating at a furious pace.
History of the Development of the Platform
First, the technology had to be adopted by large enterprise software companies such as IBM, BEA, and Oracle. JavaSoft's unique product development methodology contributed to making this successful. The methodology, the precursor of the Java Community Process, was to include the "customer" - the application server vendors - in the development process. All of the vendors participated equally.
Second, the tools vendors needed to be included. It's not sufficient to have infrastructure available. It must be easy for developers to write code on top of the platform and do it easily, and there must be a vibrant commercial development tools market in order to accomplish this.
Third, there must be a market for software components so that it's possible to assemble applications quickly using commercial development tools. Interestingly, this market did not develop as originally planned. For example, there are less than 30 EJB commercial components found on Component-Source, a major site for selling software componentry.
Fourth, there must be a market for packaged applications, and these software packages could not have been written without the application servers, tools, or components available in the marketplace.
Finally, in order to build a complete ecosystem, a market for systems integrators must exist. In any technology market there must be people that companies can turn to in order to integrate the packaged software mentioned earlier. Once a need for this kind of integration is established, systems integrators become successful and then a complete ecosystem has been established.
The key point of this model is that it is linear. Each stage must reach a certain level of success for any of the next stages to succeed. At this point in history, it's safe to say that J2EE has a fully completed ecosystem, since all stages seem to be relatively successful. But there is one stage that has severely limited the further growth of the J2EE market. While there are successful tools in the marketplace like Eclipse and JBuilder, on the balance it is still very difficult to build, deploy, and manage J2EE applications.
From the vantage point of usability, BEA has done a great job of making WebLogic Workshop into a first class IDE in a mature market. It's important not to underestimate what they have done. Their move in the space is akin to someone creating a new Detroit car company and succeeding. Workshop is essentially the Saturn of the development world.
BEA has always been an innovative company. In the past they have often implemented many Java features before the ink on the specifications was dry. They also have innovations of their own, which they've included in Workshop. Some of these innovations, especially the way they annotate code in the IDE, create code that is project-incompatible with any other tool, something I am sure BEA has considered. This is problematic, since a recent developer survey has shown that developers use on average at least two IDEs. For application developers, this makes our cross-platform and cross-application server development harder and lengthens our development cycles, something we would clearly like to avoid.
Current Application Development Problems
Most applications currently provide a Web-based UI; however, such projects still involve employing J2EE experts who are familiar with several key APIs. Though JSP, Servlet, and Tag libraries, and some of the new JSRs provide a powerful framework, a new J2EE developer is still overwhelmed by the difficulty of building a page that shows some data. This problem is obvious if you compare the difficulty of building a J2EE-based UI page to the ease of building a similar page in Visual Basic or PowerBuilder. There are two main reasons for this difficulty. First, the current APIs are too low level and require all projects to reinvent the wheel and build the most basic elements of a UI framework, for example, component-based widgets or a standard navigation paradigm (Struts is designed to partly solve these problems). The second reason for the difficulty is the lack of tools that hide application developers from all the details of the APIs. For example, nearly all business applications require a UI for listing, searching, viewing, and editing a business entity that is often stored in a relational database. Ideally, building a simple application that performs these tasks should be fully automated with a WYSIWYG tool; in fact, the tool should also generate the necessary artifacts for data access (i.e., an EJB entity bean). Most applications often have at least several business entities, thus exacerbating the problem of building and maintaining such an application. Without the tools, the application developer is either forced to quickly write JSPs for each of these pages, which results in maintenance headaches, or to spend a significant amount of time in building a framework to provide tools and a higher level of abstraction over J2EE. The latter approach is used in most projects in which a few developers are tasked to build an internal framework to ease the application development by various methods such as code generation. These problems are not restricted to UI. As a result, most application vendors have a team of developers who build an infrastructure, often called a platform, and the necessary tools on top of J2EE to enable application developers to do just that - to develop applications.
Another problem area for applications is system management. This situation is analogous to the problems with UI. JMX has been adopted by almost all application servers as the standard for system management. However, there are no standards on the ontology of MBeans that an application server uses. Each vendor defines its MBeans with the desired attributes. As a result, system management across application servers is nearly impossible. Furthermore, there is no integration between each of the core J2EE components and JMX. For example, there is nothing in J2EE on how JMS destinations should be managed at runtime. Without this, JMX and JMS are completely decoupled and thus each application server vendor builds its own set of MBeans and clustering functionality for JMS. Wouldn't it be better to define the common JMX MBeans for JMS destinations to enable standard tools for system management?
Suggestions for Improvement of the Platform
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads