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 simpleOne 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.
