Project complexity in Java

Creator Data Matrix in Java Project complexity

Figure 1.3 The EJB complexity graph shows that EJB starts complex, but ramps up more slowly with project size. Other simpler technologies tend to start simple, but break down as project complexity grows. The break-even point with EJB tends to be with larger, more complex projects. This chart does not reflect a formal study.

Table 1.1 EJB projects are more successful when you apply EJB appropriately. In this table, you can see a few factors surrounding an EJB decision. On the technical side, you should consider specialized needs, your application design, and the value you re likely to generate. Your choice is dependent on technical issues and the skills of your development staff. Decision criteria Complexity

EJB fit better when: Higher complexity Large projects Massive integration concerns Staff has EJB skills Budget allows for mentors Developers are well compensated, making it easier to retain key personnel Enterprise understands EJB deployment and tuning issues, and staffs accordingly Staff understands distributed object development

EJB fit worse when: Lower complexity Small projects Minor integration concerns Staff has little EJB skill Budget does not allow for mentors Developers are not compensated well Enterprise has little EJB deployment experience Staff experience is limited to development centered on one tier

Application has classic J2EE tiered structure Classic EJB clustering works Required third-party components integrate with EJB well

Clustering is problematic with this design Third-party components require massive integration or duplicate many services Legacy components require different transactional or security model

Single-threaded transactions Traditional resources like relational databases and legacy transactions EJB servers available on required hardware

Highly specialized needs don t match EJB Multithreaded transactions Rigid hardware requirements make EJB unfavorable

EJB and J2EE development skills In our experience, the top reason for J2EE project failure is the lack of sufficient skills. EJB can insulate you from a few technical complexities, but will introduce many others. You ll still need specialized skills to develop and tune complex, distributed applications. Experience with the J2EE tool set is preferred; experience with EJB is a must. A good understanding of design patterns, best practices, and antipatterns will help you choose designs that work and avoid those that don t.

set up and administer an automated J2EE build environment with effective source control build automated tests for EJB applications design multitier applications with low communications overhead work efficiently in your development environment, whether with an IDE or a collection of OpenSource tools like EMACS, Ant, and XDoclet avoid J2EE services that are problematic or poor matches for your application deploy J2EE applications

True, your team can learn some of this stuff on the fly, but if you try to force a staff which is not ready into this environment, you ll be courting disaster. Luckily, EJB is mature enough that you should not have any problems finding good skills in the work force. In fact, as we write this in early 2003, the technology economy remains soft, and the market favors the employer. EJB services and components and value Perhaps the key to choosing the right platform is to make your decisions based on the value that you ll get from employing EJB, and offset that value with EJB s added costs, including the complexity of the platform. At each step, you ll want to justify the value and the fit of each EJB service you plan to use. If the service doesn t provide enough value, don t use it. In chapters 7 and 8, we ll see that the EJB entity model is frequently not the best choice for EJB persistence. Don t be afraid to walk away from parts or all of EJB if it s not meeting your needs. Usually, to be a good fit for EJB, applications should be one or more of the following:

Distributed If your application is not distributed, it will rarely be a good fit for EJB. The core problems for many EJB services revolve around distributed name lookup, distributed transaction management, messaging, and connection services. Conversely, with highly distributed applications, EJB can easily make sense. Transactional Integration of a single global transaction context can significantly simplify enterprise development. Secure Not all EJB applications have a strong security requirement, and some applications have needs that don t fit the structure of the EJB security