A Road Most Traveled
The Technology Decision
Today, applications taking a server-centric approach to their design must consider their alternatives. If the transaction volume will be quite small and is not anticipated to grow over time, the solution presented in Chapter 11 is viable. The major downside of this approach is the extra coding necessary for managing your own transaction scope. If, however, the application volume will grow over time and the need for clustering services arises to provide very high throughput, then a commercial application server product is absolutely essential. This is where the need for an EJB solution becomes even more apparent.
Enterprise JavaBeans have really caught on in the marketplace. I feel we will also continue to see a shift away from bean-managed persistence and toward container-managed persistence. Prior to the EJB 2.0 specification, the message from Sun on CMP wasn't very clear, bordering on ambiguous; too much was left to vendors to implement how they saw fit. With EJB 2.0, very little is left to the imagination of EJB vendors, and that's a good thing. Now CMP entity beans will be truly transportable across EJB vendor products. But by far the biggest saving from CMP is the complete removal of SQL coding. On many projects I have seen an increase of up to 25 percent in the productivity of the team going the CMP route—nothing to scoff at.
In considering design strategies for a project, keep in mind some of the basic lessons put forward in this book:
Employ the Model 2 strategy for your front components—that is, have a servlet that acts as a user interface controller that brokers the requests from the client. It may benefit the design to have a user interface controller for each use-case. It may be beneficial to use the command pattern in the servlet that allows the dynamic invocation of beans that implement each unique action the servlet must implement. Use JavaServer Pages to present the view to the client.
Every use-case should have a use-case control class. Each use-case controller should have operations that map to the happy and alternate pathways through the use-cases. These pathway operations are completely documented in the form of the sequence or collaboration diagrams.
Use value objects wherever possible. Network chatter must be kept to a minimum or performance will suffer. Value objects contain only attributes and accessors, no business logic.
The use of data access objects can go a long way toward further separating the layers of the application. BMP solutions and non-EJB solutions can benefit from the same design strategy.
The Process of Getting There
I still contend that the technology is the easy part. Identifying all the requirements and having the backing of your user are key. Confirming for users that you understand what they want is the true challenge. Use-case analysis, coupled with two other key UML constructs—class and sequence/collaboration diagrams—comes closer to meeting that challenge than anything I have seen in the 25 years I have been in the software industry.
Too often we on the technology side lose sight of the fact that most of us are in this business to satisfy a paying client. If we can't find a way to communicate the needs of the client better and manage the ensuing project with some level of predictability that it will be a success, we are not doing our job.
So pick a process, any process, and stick to it. Make it a lean process, one that produces artifacts that are absolutely necessary and that have a traceable thread both forward and backward. The days are gone when we were judged by the thickness of the analysis and design deliverables we produced. Users pay for software, not paper documents. Give it a try; it really isn't as hard as it sounds.
I hope you have enjoyed this book as much as I enjoyed writing it. Again, remember to download the code from my Web site (www.jacksonreed.com), where the entire Remulak application is available for inspection. Happy learning!