General Principles

The following is a summary of some of the most important general principles we've discussed:

• Use J2EE: don't let it use you
  Successful software projects treat technologies as tools. J2EE should be used as a means to an end. Each of the many technologies within J2EE should only be used where it delivers demonstrable benefit. Avoid the temptation to use features of J2EE just because (like Everest) they are there; this is likely to add unnecessary complexity, and ongoing expense.

• Don't use EJB unless it delivers real value
  This is perhaps the most important case of the above principle. I feel that far too many J2EE developers assume that EJB is the core of J2EE, and that all enterprise-class applications should use EJB. This is incorrect. EJB is a complex technology that solves some problems well, but adds unnecessary complexity if used inappropriately. When EJBs are used appropriately, they should simplify application code by concealing the handling of concurrency issues, transaction management, security management, and remote access. When EJBs don't deliver a simplicity dividend, the decision to use them may be incorrect. The benefits should be obvious, not merely a vague promise of greater scalability.

• Don't use a distributed architecture unless it is necessary to meet business requirements
  Distributed applications, in which application components are distributed amongst multiple servers, are far more complex than collocated applications, in which all application components run in the same JVM. Thus the difficulty and cost of developing and maintaining distributed applications is much greater than that of developing and maintaining collocated applications. We should avoid incurring this cost unless it is necessary. In Chapter 1 and Chapter 6 we discussed how to choose when a distributed architecture is appropriate. Note that collocated applications can still be clustered if necessary, with each server in the cluster running all application components. When we use EJB in a collocated application, we should use local interfaces, rather than remote interfaces.

• Don't take an unduly J2EE-centric view of enterprise software development
  Java is a fine language and J2EE is a fine platform for enterprise development. However, enterprise applications involve more than any one language and the technologies around it. A good J2EE developer is literate in the enterprise technologies that J2EE applications interact with, and prepared to seek help from specialist experts when required. A professional developer should also be aware of and open to ideas from alternative platforms such as .NET.

• J2EE isn't merely about specifications
  While it's a great bonus that public specifications describe the functionality of J2EE application servers, it's important to draw lessons from the implementations of them in leading J2EE application servers. For example, we must be aware of the limitations of leading implementations in areas such as stateful session beans and entity beans. We must base our decisions on evidence and evidence can only be drawn from real implementations, not specifications.

• Think carefully about database portability
  Don't try to achieve database portability if it increases complexity or reduces performance, unless there's a real likelihood that you'll require it. There is usually a cost in achieving abstraction between different types of persistent store, such as RDBMSs and ODBMSs. This cost shouldn't be incurred lightly, as data tends to stick where it lands. An RDBMS schema may well outlast a J2EE application.

• JDBC (and SQL) are powerful tools
  Don't be afraid to use them, and learn to use them well. Be skeptical of claims, such as those of the EJB specification, that J2EE can deliver developers from the details of working with relational databases or other enterprise resources. Often this is neither realistic nor desirable. Don't hope to solve the so-called "object-relational impedance mismatch" simply by ignoring how RDBMSs work; try to build OO applications that can use RDBMSs efficiently. Used correctly, JDBC can be highly efficient and easy to work with. In Chapter 9 we saw a simple abstraction framework that can be used to simplify working with JDBC and help to prevent common errors.

• Don't ignore the capabilities of your target database
  Not only have you already paid for these capabilities: they're the fruits of decades of research and development and should work very well. For example, some tasks can be accomplished much more efficiently in stored procedures than in Java code, and it's frequently possible to harness the performance gain without abandoning good design principles. Don't view an RDBMS as a dumb storage device and also don't ignore the input of DBAs in a fervent quest for a "pure" J2EE solution. The results are likely to be disappointing.

• Try to achieve portability between J2EE application servers if possible
  Regularly use the verifier included with Sun's J2EE Reference Implementation to check your applications' compliance to the J2EE specifications. Sometimes it is necessary to use proprietary features of an application server: for example, to maximize the performance of a particularly performance-sensitive operation. However, violations of the J2EE specifications through ignorance or laziness produce no benefit and will be very costly if there is ever a need to port the application to another application server.

• A good application is the simplest possible application
  The XP advice to do "the simplest thing that could possibly work" is especially relevant to J2EE, which provides a wealth of complex options, many of which are required infrequently. Question design decisions that seem to lead to excessive complexity. For example, consider a decision to use JMS to achieve asynchronous calling. While JMS and message-driven beans are very useful in some situations, using them will usually add complexity and make an application harder to debug and maintain compared to using ordinary synchronous calling. Unless this additional complexity delivers real benefit, it's best to eschew it.

• Most of the benefits of EJB can be achieved through stateless session beans
  The trade-offs involved in using stateful session beans and entity beans are more complex, and their benefits less clear-cut. The stateless component model has been proven in many middleware systems, not merely EJB. Stateful session beans and entity beans, on the other hand, are not so well proven in practice. Stateful session beans can limit scalability, if this is a key requirement. Using entity beans makes it difficult to perform many operations efficiently when working with relational databases. Remember that O/R mapping, as provided by entity beans, isn't always appropriate. Also, remember that entity beans are just one approach to O/R mapping, which happens to be defined in the EJB specification; JDO and proprietary O/R mapping products such as TopLink are often superior.

• Think about performance from project inception
  Business requirements should contain clear and measurable targets for performance and concurrency. It's advisable to develop a proof of concept, often called a spike solution or vertical slice, early in the project lifecycle, to ensure that performance requirements can be met. This allows us to modify application architecture if necessary, without massive waste of effort. Later in the project lifecycle it may be too late to improve performance significantly without expensive changes; in most J2EE applications, we cannot rely on code optimization to deliver significant performance gains. Performance is a real concern in J2EE, as it's often a key business requirement (for example, in web applications) and because some popular J2EE "patterns" produce particularly bad performance. In Chapter 15 we saw the importance of basing performance-related decisions on hard evidence, obtained from load testing and profiling runs.

• Consider the likelihood and implications of the application running in a cluster of servers, and take this into account in design
  It's possible to design an application that performs well on a single server, but will prove extremely inefficient if it has to run in a cluster - for example, if it holds unnecessarily large amounts of session state, which will need to be replicated between clustered servers. Be wary of such pitfalls if there's a real possibility of the application needing to scale up to a clustered deployment, even if it is initially deployed on a single server.

• When scalability is a crucial priority, as it is in high-volume web applications, try to design using stateless components
  No application server and no technology - J2EE or any other - can prevent the maintenance of server-side state reducing scalability. Consider the example of scalability using geographically dispersed servers. This will prove an enormous problem for replication of server-side state. If server-side state is required, good design should minimize the amount that needs to be held.

• Good J2EE design rests on good OO design
  It's easy to let the details of working with J2EE APIs and components distract us from sound OO practice; this is a costly mistake. The size and complexity of J2EE projects makes it all the more vital to follow good OO practices such as programming to interfaces rather than concrete classes and achieving a consistent level of abstraction within classes. We've also seen how the use of JavaBeans can help us to hold configuration outside Java code, and how interface-based design can help us to ensure portability between application servers.

• Use helper classes to abstract use of low-level APIs such as JDBC, JNDI, and JMS to simplify application code and achieve a consistent level of abstraction
  It's vital that application code concentrates on the problem domain and on implementing business logic. This can only be achieved by ensuring that low-level tasks are concealed by generic infrastructure code, in cases where working with the J2EE APIs directly is too verbose. This doesn't mean that we need to sacrifice efficiency; such an abstraction layer should allow application code to control the use of the underlying APIs. In Chapter 9 and Chapter 11 we looked at generic packages that conceal some of the complexity of J2EE from application code. We saw how using these packages significantly simplified the code of the sample application.

• Use the MVC architectural pattern in web applications
  This is probably the single most important piece of high-level design advice for J2EE web applications. The MVC architectural pattern ensures that presentation is separate from control flow and business logic. Experience has proven this to be an essential goal of all real web applications. Use a generic implementation of the MVC pattern such as the Struts framework or the framework discussed in Chapter 12 of this book. Remember also that the web tier should be as thin as possible, and responsible only for translating user actions into business operations and displaying the results. Business logic should not be web-specific.