Page 1 of 3 next page »
The elegance of Java stems from how the language addresses a number of highly complex software engineering issues in a seemingly consistent and easy-to-use paradigm. While there are a few potholes that you need to be mindful of, most caused by the differences between primitives and objects, the power and reach of standard Java are testaments to the principle of simplicity that is embodied within it. Unfortunately, when it comes to Java's enterprise platform, J2EE strays considerably from J2SE in a number of areas, creating unnecessary additional complexity and ambiguity. To make matters worse, J2EE 1.3 (EJB 2.0) introduced self-inconsistencies.
J2EE's deviations fall into two categories: Structural and Behavioral. Structural deviations concern those areas where the implementation of a J2EE component requires a format that differs significantly from the implementation format of a similar J2SE component. Behavioral deviations concern those areas where substantial inconsistencies exist in the fundamental workings of J2EE, be they self-inconsistencies in J2EE components or inconsistencies with respect to analogous J2SE components.
In the case of J2EE's most high-profile technology, Enterprise JavaBeans (EJBs), these digressions can be mitigated by extending and enhancing EJBs into what I'll term BetterEJBs (see the pullout at the end of this article). Just as application server deployment tools can transparently generate EJB stubs and skeletons, tools can likewise be developed to auto-generate the necessary artifacts that are derivable from the BetterBean. The benefit: a BetterEJB developer needs only implement a single class, cutting down on development time, complexity, and the potential for errors while increasing understandability through the consolidation of information in a single location.
This article discusses a number of issues regarding the disparity between J2EE and J2SE, and spells out practical approaches and techniques that can be used to help return J2EE, specifically EJB, back to its Java roots. Additionally, this article illustrates the derivation of all supporting artifacts from the BetterBean, suggesting toolable functionality that could be realized to auto-generate the boilerplate constituent parts of the BetterEJB.
Structural Deviations
J2EE, and specifically EJB, has complicated the development of reusable functionality. Besides compromising Java's object-oriented nature, the format of the code has been made needlessly complex. When a data value object or utility object can be written in a single Java class, why does J2EE require that four (or possibly even six) files be written to make the enterprise-grade equivalent: an Entity or Session EJB? An EJB requires not only the Bean class, but also a Home Interface, a Remote Interface (optionally, a Local Home Interface and Local Remote Interface), and a deployment descriptor.
Given the distributed nature of EJB deployment, which is realized through application server-generated Stubs and Skeletons, it's reasonable for enterprise-grade functionality to require a client-facing interface in addition to the bean class. But, the necessity of any additional artifacts is overly complex and error prone.
