To build a J2EE system that's both extensible and maintainable it's important to take a functional approach. By separating the system into tiers, you ensure that your Web tier is built to handle the presentation layer, the EJB layer can manage business logic, and the database is built to store data persistently and take care of most of the complex data concurrency issues. While this functional model is accepted practice, the problem is that it neglects what makes an e-business system successful: fast transactions.

The reality is that well-designed J2EE systems aren't necessarily high-performance systems. This reality usually hits home in production as operations teams struggle to meet service-level commitments on transaction times. The costs can soar alarmingly quickly. One response may be to add to your application server cluster, or invest in more hardware. But a proactive approach to performance in preproduction can mitigate risk and protect your IT group from these later costs. You'll need to balance the functional approach with a performance-centric approach, supported by appropriate tools.

Adopting a performance-centric approach involves analyzing transaction execution paths through the entire system, and tuning your system to accelerate throughput and response time. Focus your tuning on the transactions that are genuinely taxing system resources and failing to meet response time requirements. With a transaction-centric focus, you also run less risk of optimizing areas that aren't negatively impacting your customer experience.

One important way to improve performance is via caching. Intelligent use of caching is arguably the single most important factor in delivering fast transaction processing. But to implement caching effectively you must understand the transaction path. Otherwise, you may implement caching on a process that is already inherently fast or that is infrequently used Ð a poor use of development resources.

To improve transactional efficiency, reduce the time spent in expensive data computation and lookup by caching data forward in the presentation or business logic layer. Completed results of business logic can be kept forward in the presentation layer to save on the cost of recomputing the same piece of data for multiple requests. Session handling should also be kept as far forward as possible in the presentation layer. This ensures that the business logic can be implemented using high-performance stateless logic (typically, stateless session EJBs). Use caching to lower costs, especially on your most expensive infrastructure investments: databases and clustered application server machines.

Let's revisit the limitations of accepted practice. In large-scale systems, you may incur significant performance degradation if you take the golden principles of object-oriented programming too literally. Fine-grained and tightly coupled design patterns can be communication-heavy, slowing down transaction response time. Try experimenting with newer, performance-centric patterns such as a more loosely coupled, coarse-grained design for component interactions. Remember to focus on the transaction path so you can target enhancements where you'll reap a worthwhile performance gain.

Finally, let's talk tools. Many tool vendors are making noise about transaction response times. But a closer look reveals that the analysis some tools provide is in fact highly tier-specific, leaving you with only a partial view of transaction throughput. Production- monitoring tools, for example, provide response-time metrics without any data to identify where in the transaction execution path the performance is degrading.

Applying these monitors to preproduction analysis work is going to leave you with more questions than answers about your transaction processing. So build your diagnostic arsenal carefully, with tools that can give you both broad visibility through your assembled system as well as deep performance intelligence within the J2EE application itself.

With a more flexible approach to J2EE design patterns, the right tools, and a healthy obsession with the transaction execution path, you'll be well on your way to delivering a high-performance, not just well-designed, system. Operations folks will thank you for it. And your customers will be getting what they need, when they need it.