There's little question that J2EE is a dominant force in software architecture, but does it live up to the hype? If not, where does it fall short?

Sun Microsystems touts the Java 2 Enterprise Edition (J2EE) as "the standard for developing multitier enterprise applications." That's a bold statement considering that J2EE as it exists today is less than five years old.

J2EE says: Keep it simple
One of the claims made by proponents of J2EE concerns simplification of the development process. J2EE simplifies the control and management of system resources by providing methods to manage transactions and resource pooling. Thanks to pooling, developers now worry less about gaining a Java Database Connectivity (JDBC) connection to a database. If the database transaction using the connection fails, J2EE can roll back any changes that occurred. By not allowing developers to drown in arcane details, enterprise developers can roll out at a faster pace.

J2EE uses XML deployment descriptors to manage the behind-the-scenes details of server operation. The syntax of the descriptors is straightforward, but problems may occur when a valueââ,¬"say, the number of available connections in a database poolââ,¬"changes. This requires rebooting the J2EE server to make it aware of the change. Although this isn't an issue on a development machine, try telling your company's business units that the production server will be off line "for a little while" because you underestimated the number of clients that would connect to the application.

Another issue interwoven with the J2EE simplification principle is that development, configuration, and deployment are too simple. For example, in the case of Entity Enterprise JavaBeans (EJB) using container-managed persistence, data members of the EJB must map one-to-one with columns in a table. This means the User EJB maps to the USER table exactly. A complex EJB using multiple columns from disparate tables simply does not work with container-managed persistence. Developers must instead code the transaction within the bean itself. If you develop an enterprise application with any degree of complexity, be prepared to eschew simple configurations.

Trial separation
One advertised benefit of J2EE development comes from separation of functionality and presentation. Presentation intelligence is located in the Java Server Pages (JSP) and servlet layer; business logic resides in the EJB layer. In theory, this separation works well. Developers create application functionality with EJB, passing the computation results to a JSP created by a Web designer. The application's code and front end are built and maintained in modular fashion, with the programmers not concerned with graphic design, and the designers not concerned with algorithms.

Another benefit of dividing application responsibilities comes with the numerous clients a J2EE application may serve. Web clients, mobile devices, and legacy information systems all receive the same information provided by a single EJB, directed through a controller servlet that determines which output format to provide.

This method of application development, however, presupposes Web development staff made up of at least one programmer and one designer. If the development staff is less heterogeneous, as most are these days, it becomes difficult to separate business logic and presentation. The temptation exists for even well disciplined teams to sneak application logic into a JSP or to allow a servlet to provide HTML formatting. This mixing may not cause problems with smaller teams, but confusion can occur if more members are involved. Attempting to provide various output formats has its pitfalls as well, as accommodating each type of format requires a wider knowledge base.

EJB and reuse
J2EE also focuses on code reuse and how enterprise applications built from off-the-shelf EJB combined with custom-built components idealise J2EE development. The concept of developers reusing their own componentsââ,¬"like a Client EJB for both a CRM application and an e-commerce applicationââ,¬"adds to the appeal of reuse in J2EE. According to J2EE tenets, reuse helps development, since programmers are not recreating or duplicating functionality.

Of course, the idea of code reuse is nothing new in development circles, and it's certainly not unique to J2EE. As developers, we seek things that make our jobs easier. The nature of EJB with their different classificationsââ,¬"session, entity, and message-drivenââ,¬"already implies certain behaviors based on the type of bean used. It's an easy leap of faith to adapt this general reuse into more specific instances.

But this mode of thought has several problems. For one thing, we again have a case of overvalued simplicity. Indeed, if the application consists of simple functionality surrounding simple objects, using ready-made EJB leads to drag-and-drop development: enterprise applications built in the morning, deployed after lunch. While noble in intent, using this ideal as promotion for J2EE is laughable. Enterprise applications are rarely (if ever) that simple, needing a healthy degree of customisation to provide any useful functionality.

Then comes the whole issue of EJB development. With the quirks residing in individual J2EE implementations, moving an EJB from one server to another is rarely a trouble-free process. Even focusing on a particular J2EE means involved development cyclesââ,¬"writing code, compiling, packaging, deploying, and testing. The packaging and deployment stages vary from server to server, and can become monotonous. Add to the equation the difficulties of debugging an errant EJB, and the swearing of developers drowns out the voiced benefits.

Weighing the pros and cons
So does the J2EE live up to its promises? Maybe. If you develop applications that incorporate simply crafted business objects with uncomplicated database schema, the concepts underlying J2EE work perfectly. The same goes if you work on a team that can devote time to intertwining simple objects into complex systems during design phase. An application development crew with clearly defined programmer and designer roles will also benefit from the J2EE. But if none of these examples reflects your circumstances, the hailed merits of J2EE may pass you by.

This doesn't mean you should scrap J2EE altogether. A number of J2EE advantagesââ,¬"such as thread safety, incorporation of other Java libraries, dominant market share, use of design patterns, and awareness of the different technologies involvedââ,¬"can provide you with valuable functionality, even if the more highly publicised benefits don't deliver what you need.

Is J2EE for me?
Do you agree that the benefits of J2EE live up to the hype? Send us an e-mail with your thoughts.

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.