Welcome!

Bill Roth, Ulitzer Editor-at-Large

Bill Roth

Subscribe to Bill Roth: eMailAlertsEmail Alerts
Get Bill Roth via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal

J2EE Journal: Article

The Theory of Innovation

Turning J2EE into J2EE-easy with better tools and JSRs

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
When the team at Sun was planning the original J2EE platform, it was clear that there were several stages in the process of developing a J2EE market, and that the industry had to be successful in order for J2EE to be successful. Furthermore, all the stages had to be complete in order for a fully functioning market.

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.

Fragmentation
This is further compounded by the fact that the major tool vendors seem to be heading in divergent directions. Both IBM and BEA are doing creditable jobs of improving the development process. However, they appear to be doing it in radically different fashions. IBM, for its part, has developed a popular open framework with Eclipse. Their commercial product, euphoniously named WebSphere Application Developer (WSAD), has extended Eclipse in many interesting ways, and seems for the most part to be hewing closely to standards. WSAD is a powerful, flexible tool, though all this power and the conceptual baggage that comes with it can be overwhelming.

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
There are other issues with developing J2EE applications. Most of these problems stem from the gap between the various J2EE components and the actual problems an application developer is trying to solve. Many components of J2EE are low-level APIs that, although they provide a great framework for building applications, still lack the high-level nature and ease of use needed to free application developers from building infrastructure. Tools can bridge this gap and make J2EE easier to use. A good tool should make it easy for you to do simple things and still have the flexibility to accomplish difficult tasks. Two areas that continue to exemplify some of these difficulties are building Web-based UI and system management.

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
From the current discussion, it's clear that several things can be done to make it possible to build better tools for J2EE. Given the current maturity of J2EE, it's important for new JSRs to try to move up and provide higher-level value-add features instead of the current trend of moving horizontally into new areas. We don't need new low-level APIs that try to tackle new problems as much as we need to simplify J2EE, to better integrate its components (e.g., the JMS/JMX example above), and to ultimately provide a higher level of abstraction and standards to enable vendors to develop consistent and application server-neutral tools that are easy to use. The new EJB 3.0 JSR, for example, is mainly focused on these goals. Though the specification will not define an actual tool, the expert group is focused on ease-of-use features that will ultimately allow better tools to be developed in order to improve the current experience of EJB developers.

Conclusion
J2EE development is now at a crucial juncture. For J2EE to truly live up to its potential and reach a broader audience, it must become easier to use. While the feature set of core J2EE is now evolving slowly, the pace of innovation around the tools needs to speed up in order to effectively compete with .NET.

More Stories By Bill Roth

Bill Roth is a Silicon Valley veteran with over 20 years in the industry. He has played numerous product marketing, product management and engineering roles at companies like BEA, Sun, Morgan Stanley, and EBay Enterprise. He was recently named one of the World's 30 Most Influential Cloud Bloggers.

More Stories By Reza Behforooz

Reza Behforooz is an engineering manager at E.piphany and also serves on the Expert Group for EJB 3.0. He has over seven years of server engineering experience, mostly in J2EE. He holds a BSCS from Cornell University and a MSCS from Stanford University.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.