book

Expert One-on-One™ J2EE™ Development without EJB™

Name: Expert One-on-One™ J2EE™ Development without EJB™
ISBN: 9780764558313

by Rod Johnson, Juergen Hoeller

June 2004

Intermediate to advanced

576 pages

18h 22m

English

Wrox

Read now

Unlock full access

Copyright
About the Authors
Credits
Introduction
Who This Book Is ForAims of This BookWhat This Book CoversAssumed KnowledgeRecommended ReadingWhat You Need to Use This BookThe Sample ApplicationConventionsErratap2p.wrox.com
1. Why "J2EE Without EJB"?
1.1. EJB Under the Spotlight1.2. What's Left of J2EE?1.3. J2EE at a Crossroads1.4. The Way Forward1.4.1. Themes1.4.1.1. Simplicity1.4.1.2. Productivity1.4.1.3. OO1.4.1.4. Primacy of Requirements1.4.1.5. Empirical Process1.4.1.6. Testability1.4.2. Lightweight Frameworks and Containers1.4.2.1. The Spring Framework1.5. Should We Ever Use EJB?1.6. Summary
2. Goals
2.1. Productivity2.1.1. The Problem2.1.2. The Traditional J2EE Approach to Productivity Issues2.1.3. Better Solutions for Higher Productivity2.1.3.1. Architecture2.1.3.1.1. Avoid Unnecessary Architectural Complexity2.1.3.1.2. Avoid Unnecessary Use of EJB2.1.3.1.3. Use Abstraction Layers to Hide Low-level API Complexity2.1.3.1.4. O/R Mapping2.1.3.1.5. Use a Good Application Framework2.1.3.2. Focus and Methodology2.1.3.2.1. Know What Problems to Solve2.1.3.2.2. Use Reference Architectures and Templates2.1.3.2.3. Use an Agile Development Process2.1.3.3. Use Appropriate Tools2.2. OO2.3. The Importance of Business Requirements2.4. The Importance of an Empirical Process2.5. Summary
3. Architectures
3.1. Architectural Building Blocks3.1.1. The Business Services Layer3.1.1.1. Stateless or Stateful?3.1.1.2. Popular Service Layers3.1.1.2.1. Session EJBs3.1.1.2.2. Stateless Session Beans with Remote Interfaces3.1.1.2.3. Stateless Session Beans with Local Interfaces3.1.1.2.4. Common Issues with EJB Service Layers3.1.1.2.5. .NET "Serviced Components"3.1.1.2.6. MVC Web Actions3.1.1.2.7. Service Layer Running in a Lightweight Container3.1.1.2.8. Service Layers Compared3.1.2. Exposing Business Objects to the World3.1.2.1. Limitations of What Can Be Exposed3.1.2.2. Web UI3.1.2.2.1. The Benefits of Co-location3.1.2.2.2. The Importance of Logical Separation3.1.2.3. Supporting Remote Clients3.1.3. Data Access Layer, or EIS Tier3.1.3.1. Technology Choices for Accessing Relational Data3.1.3.2. Accessing Legacy Systems3.2. J2EE Architectures3.2.1. EJB Architectures3.2.1.1. "Classic" J2EE Architecture3.2.1.1.1. Strengths3.2.1.1.2. Weaknesses3.2.1.2. Local EJB Architecture3.2.1.2.1. Strengths3.2.1.2.2. Weaknesses3.2.1.3. Variations on EJB Architectures3.2.1.4. Implementation Issues Common to EJB Architectures3.2.2. Non-EJB Architectures3.2.2.1. Ad hoc J2EE Architecture without EJB3.2.2.1.1. Strengths3.2.2.1.2. Weaknesses3.2.2.2. The "Lightweight Container" Architecture3.2.2.2.1. Strengths3.2.2.2.2. Weaknesses3.2.2.3. Implementation Issues3.3. J2EE Architectures in Practice3.3.1. "Classic" J2EE Remote EJB Architectures3.3.1.1. Original Java Pet Store3.3.1.2. OTN J2EE Virtual Shopping Mall3.3.2. Local EJB Architectures3.3.2.1. The Middleware Company mPetStore (February 2003)3.3.2.2. Common Issues with EJB Architectures3.3.3. Ad hoc Non-EJB Architectures3.3.3.1. Sun Adventure Builder v 1.0 EA 3.1 (July 2003)3.3.3.2. iBatis JPetStore v 3.13.3.3.3. Overall Notes3.3.4. "Lightweight Container" Architecture: The Sample Application3.4. Deciding Whether an Application Needs an Application Server3.5. Summary
4. The Simplicity Dividend
4.1. The Cost of Complexity4.2. Causes of Complexity in J2EE Applications4.2.1. Architectural Causes of Complexity4.2.1.1. Use of EJB4.2.1.2. Object Distribution4.2.1.2.1. Why Not to Distribute Your Business Objects4.2.1.2.2. Distribution and Scalability4.2.1.2.3. Faking It: Phony Distributed Objects4.2.1.2.4. Isn't J2EE about Distribution?4.2.1.3. Focusing on Non Goals: "Phantom Requirements"4.2.1.4. Pattern-sickness4.2.2. Cultural Causes of Complexity: The Complexity Industry4.2.2.1. Vendor-driven Architecture4.2.2.2. Tools and Complexity4.2.2.3. Organizational Delusions4.2.2.4. People4.2.2.4.1. Simplicity Is for Dummies4.2.2.4.2. Career-driven Development4.2.2.4.3. The Hands-off Architect4.2.2.4.4. Empire Building and Other Political Challenges4.2.2.4.5. Resistance to Simplification4.3. How Much Complexity Is too Much Complexity?4.3.1. Simple or Naïve?4.3.2. Just Good Enough?4.3.3. The Winds of Change4.4. Summary
5. EJB, Five Years On
5.1. Hype and Experience5.1.1. EJB and the J2EE Industry5.1.2. EJB in Practice5.2. An Aging Component Model5.2.1. Java Language Improvements5.2.2. The .NET Challenge5.2.3. Web Services5.2.4. The Rise of Agile Methodologies5.2.5. Confusion Regarding the Aims of EJB5.2.6. The Component Market That Didn't Eventuate5.2.7. The New Paradigm on the Block: The Emergence of AOP5.3. What Do We Really Want from EJB, or Why Stateless Session Beans Are So Popular5.3.1. Declarative Transaction Management5.3.2. Remoting5.3.3. Clustering5.3.4. Thread Management5.3.5. EJB Instance Pooling5.3.6. Resource Pooling5.3.7. Security5.3.8. Business Object Management5.3.9. EJB Services Summary5.4. What Don't We Want from EJB?5.4.1. The Monolithic, Distinct Container Problem5.4.2. Inelegance and the Proliferation of Classes5.4.3. Deployment Descriptor Hell5.4.4. Class Loader Hell5.4.5. Testing5.4.6. EJB Overdose5.4.7. Complex Programming Model5.4.8. Simple Things Can Be Hard5.4.9. Is the Goal of Enabling Developers to Ignore the Complexity of Enterprise Applications Even Desirable?5.4.10. Loss of Productivity5.4.11. Portability Problems5.5. Can EJB Reinvent Itself?5.5.1. Tool Support5.5.2. EJB 3.05.6. Myths and Fallacies5.6.1. J2EE == EJB5.6.2. Questionable Arguments for Using EJB5.7. Moving Forward5.7.1. Choosing Whether to Use EJB5.7.2. Conventional Wisdom5.7.3. Making a Choice Today5.7.4. The Emerging Post-EJB Consensus5.7.5. Standards, Innovation, and Open Source5.7.5.1. Competition versus Command5.7.5.2. Open Source in Practice5.7.5.3. Avoiding OSS Hell5.8. Summary
6. Lightweight Containers and Inversion of Control
6.1. Lightweight Containers6.1.1. What Is a Lightweight Container?6.1.2. Why Do We Need a Container at All?6.1.3. Lightweight Containers versus EJB6.1.3.1. Benefits of Lightweight Containers6.1.3.2. Benefits of EJB6.2. Managing Business Objects6.2.1. Interface-implementation Separation6.2.2. EJB: Only a Partial Solution6.3. Inversion of Control6.3.1. IoC Implementation Strategies6.3.1.1. Dependency Lookup6.3.1.2. Dependency Injection6.3.1.3. Setter Injection6.3.1.4. Constructor Injection6.3.1.5. Choosing between Setter and Constructor Injection6.3.1.6. When Can't We Use Dependency Injection?6.3.2. IoC Containers6.3.2.1. The Spring Framework6.3.2.2. PicoContainer6.3.3. Portability between IoC Containers6.4. Implications for Coding Style, Testing, and Development Process6.4.1. Coding Style6.4.2. Testability6.4.3. Development Process6.5. Applying Enterprise Services6.6. Summary

7. Introducing the Spring Framework
7.1. History and Motivation7.2. A Layered Application Framework7.2.1. Basic Building Blocks7.2.2. Spring on J2EE7.2.3. Spring for Web Applications7.3. The Core Bean Factory7.3.1. Fundamental Interfaces7.3.2. Populating Beans via XML7.3.2.1. Defining Beans7.3.2.2. Accessing Beans7.3.3. Non-XML Bean Definition Formats7.3.4. Wiring up Application Objects7.3.4.1. Defining Beans7.3.4.2. Accessing Beans7.3.5. Autowire and Dependency Checks7.3.6. Constructor Resolution7.3.7. Lifecycle Callbacks7.3.8. Complex Property Values7.4. Resource Setup7.4.1. Classic Java and J2EE ResourceAccess7.4.2. Resource Definitions in a Bean Container7.4.3. Factory Beans7.4.3.1. Making a JNDI Resource Available7.4.3.2. Creating a Local Connection Factory7.5. The Spring Application Context7.5.1. Lifecycle Callbacks7.5.2. Message Source7.5.3. File Resources7.5.4. Bean Factory Post-processing7.6. Summary
8. Declarative Middleware Using AOP Concepts
8.1. AOP 1018.1.1. Motivation8.1.2. AOP in J2EE8.1.3. Definitions8.1.4. History8.2. EJB as a Subset of AOP8.3. AOP Implementation Strategies8.3.1. Dynamic Proxies8.3.2. Dynamic Byte Code Generation8.3.3. Java Code Generation8.3.4. Use of a Custom Class Loader8.3.5. Language Extensions8.4. AOP Implementations8.4.1. AspectJ8.4.1.1. Pros8.4.1.2. Cons8.4.2. AspectWerkz8.4.3. JBoss 48.4.3.1. Pros8.4.3.2. Cons8.4.4. Spring8.4.4.1. Pros8.4.4.2. Cons8.4.4.3. Advice Types and Pointcuts8.4.5. Nanning8.4.6. The AOP Alliance8.5. AOP Design Issues8.5.1. Dangers of AOP8.5.1.1. Should We Intercept Fields?8.5.1.2. Too Many Aspects?8.5.1.3. Orthogonality8.5.1.4. Testing Applications Using AOP8.5.1.5. Debugging8.5.1.6. Won't AOP Seriously Affect Performance?8.5.2. AOP Design Recommendations8.6. J2EE à la carte8.7. AOP in Practice with Spring8.7.1. Using the ProxyFactoryBean8.7.2. Convenience Factory Beans8.7.3. "Autoproxying"8.7.4. Programmatic Usage8.8. Using Source-level Metadata to Provide an Abstraction above AOP8.8.1. .NET Example8.8.2. Aside: Conceptual Versus Implementation-level Metadata8.8.3. Programmatic Access to Context Information8.8.4. Spring Example8.8.5. EJB 3.08.9. Implications for Programming Style8.9.1. Consistent Naming Conventions8.9.2. Avoiding Reliance on the AOP Infrastructure8.9.3. Checked Exceptions and Advice8.10. References8.10.1. Books8.10.2. Papers8.10.3. Articles and Online Resources8.11. Summary
9. Transaction Management
9.1. High-level Transaction Management9.2. Classic J2EE Transaction Management9.2.1. The J2EE Container as Transaction Coordinator9.2.2. Everybody Loves CMT9.2.2.1. Typical Use: Local Stateless Session Beans9.2.3. Direct Use of JTA9.2.4. Interlude: Remote Transaction Propagation9.3. Lightweight Transaction Infrastructure9.4. Transaction Management with the Spring Framework9.4.1. Transaction Definition9.4.2. Programmatic Transaction Demarcation9.4.2.1. Direct PlatformTransactionManager Usage9.4.2.2. TransactionTemplate9.4.3. Declarative Transaction Demarcation9.4.3.1. AOP ProxyFactoryBean and TransactionInterceptor9.4.3.2. AOP ProxyFactoryBean with Interfaces9.4.3.3. Simplified Setup: TransactionProxyFactoryBean9.4.3.4. Source-level Metadata9.4.4. Transaction Management Strategies9.4.4.1. jtatransactionmanager9.4.4.2. DataSourceTransactionManager9.4.4.3. JdoTransactionManager9.4.4.4. HibernateTransactionManager9.4.5. Implications for J2EE Server Choice9.5. Summary
10. Persistence
10.1. Common Persistence Strategies10.1.1. An Overview of Persistence Patterns10.1.2. Popular J2EE Data Access Solutions10.1.3. Choosing a Persistence Strategy10.1.3.1. When to Choose O/R Mapping10.1.3.2. Caching of Persistent Data10.1.4. Transparent Persistence and Behavior in Domain Objects10.2. A Brief History of Java Persistence Technologies10.2.1. The Slow Rise of Java O/R Mapping Solutions10.2.1.1. 1997-1998: TopLink, CocoBase, ODMG10.2.1.2. 1999-2001: Entity Beans, JDO10.2.1.3. 2002-2003: TopLink, Hibernate, iBATIS Database Layer10.2.1.4. 2004: JDO Evolves; Hibernate Flourishes10.2.2. The Failure of Entity Beans10.3. Data Access Technologies in Practice10.3.1. Resource Handling10.3.2. JDBC10.3.2.1. Example Code10.3.3. iBATIS SQL Maps10.3.3.1. Example Code10.3.4. JDO10.3.4.1. Example Code10.3.4.2. State Management10.3.4.3. Identity Management10.3.5. Hibernate10.3.5.1. Example Code10.3.5.2. State Management10.3.5.3. Lazy Loading10.4. The Data Access Object Pattern10.4.1. Business Objects and Data Access Objects10.4.2. DAOs and Transparent Persistence10.4.3. Types of Data Access Objects10.4.4. DAO Design Issues10.4.4.1. Granularity of Data Access Operations10.4.4.2. Transparent Persistence and Object State10.4.4.3. Transaction Scopes and Lazy Loading10.4.5. DAO Infrastructure Issues10.5. Data Access with the Spring Framework10.5.1. Generic Data Access Exceptions10.5.2. Business Objects and Data Access Objects Revisited10.5.2.1. Transactional Objects10.5.3. JDBC10.5.3.1. JDBC Access via a Template10.5.3.2. "RDBMS Operation" Objects10.5.4. iBATIS SQL Maps10.5.4.1. SQL Map Access via a Template10.5.5. JDO10.5.5.1. JDO Access via a Template10.5.5.2. JDO Access with an Interceptor10.5.6. Hibernate10.5.6.1. Hibernate Access via a Template10.5.6.2. HibernateTemplate Convenience Methods10.6. Summary
11. Remoting
11.1. Classic J2SE Remoting: RMI11.1.1. Accessing and Exporting RMI Services11.1.1.1. Setup within a Spring Context11.1.1.2. Business Interfaces for RMI Services11.1.2. RMI Invoker for Transparent Remoting11.2. Classic J2EE Remoting: EJB11.2.1. Wire Protocols11.2.2. State Management11.2.3. Accessing Remote EJBs11.2.3.1. Setup within a Spring Context11.2.3.2. Exposing an EJB Home Object11.2.3.3. Exposing an SLSB with a Business Interface11.2.3.4. Non-RMI Business Interfaces11.2.4. Deploying Remote EJBs11.2.4.1. Exporting Existing Services11.3. WSDL-based Web Services: JAX-RPC11.3.1. Accessing Web Services11.3.1.1. Setup within a Spring Context11.3.1.2. Exposing a JAX-RPC Service11.3.1.3. Exposing a Service Endpoint11.3.1.4. Business Interfaces for Service Endpoints11.3.2. Servlet and EJB Endpoints11.3.2.1. Exporting Existing Services11.4. Lightweight Remoting: Hessian and Burlap11.4.1. Accessing and Exporting Hessian and Burlap Services11.4.1.1. Setup within a Spring Context11.5. Summary
12. Replacing Other EJB Services
12.1. Thread Management12.1.1. Threading Myths12.1.1.1. Do Stateless Service Objects Need to Be Single Threaded?12.1.1.2. The Cost of Instance Creation12.1.1.3. Resource Management12.1.1.4. Should the Solution Totally Reject the Java Threading Model?12.1.1.5. Does the EJB Threading Model Provide a Complete Concurrency Solution?12.1.1.6. The Tradeoffs in the EJB Solution12.1.2. The EJB Threading Model12.1.2.1. Locking12.1.2.2. Thread Pooling12.1.2.3. Resource Pooling12.2. EJB Instance Pooling12.2.1. When Is Pooling Required?12.2.2. The Case Against Instance Pooling12.2.2.1. Memory Management12.2.2.2. Lack of Shared State12.3. Alternatives to EJB Threading and Pooling12.3.1. Threading Models12.3.1.1. Shared Multithreaded Object12.3.1.2. Concurrency Support in Application Code12.3.1.3. What Do We Need to Worry About?12.3.1.3.1. Synchronization12.3.1.3.2. Concurrency Libraries12.3.1.4. A New, Dedicated Object per Client12.3.1.5. Non-EJB Instance Pooling12.3.1.6. ThreadLocal "Pooling"12.3.2. Instance Pooling Summary12.4. Declarative Security12.4.1. The EJB Model12.4.2. Flaws in the EJB Model12.4.3. Declarative Security via AOP12.5. JMS and Message-driven Beans12.6. Summary
13. Web Tier Design
13.1. Goals and Architectural Issues13.1.1. Web Tier Design Goals13.1.2. Ad hoc MVC via Servlets and JSPs13.1.3. Integration into Overall Application Architecture13.1.3.1. Hard-wired Singleton Business Objects13.1.3.2. Stateless Session Beans13.1.3.3. ServletContext Attributes13.1.3.4. IoC-based Middle Tier Backbone13.2. Request-driven Web MVC Frameworks13.2.1. Struts 1.113.2.1.1. Basic Controller Workflow13.2.1.2. Model and View Handling13.2.1.3. Configuration Example13.2.1.4. Integration with a Middle Tier13.2.1.5. Struts Recap13.2.2. WebWork213.2.2.1. Basic Controller Workflow13.2.2.2. Model and View Handling13.2.2.3. Configuration Example13.2.2.4. Integration with a Middle Tier13.2.2.5. Recap13.2.3. Web MVC with the Spring Framework13.2.3.1. Basic Controller Workflow13.2.3.2. Model and View Handling13.2.3.3. Configuration Example13.2.3.4. Command Controllers13.2.3.5. Form Controllers13.2.3.6. Integration with a Middle Tier13.2.3.7. Recap13.2.4. Appropriate View Technologies13.3. Alternative Approaches to Web MVC13.3.1. Portals and Portlets13.3.2. Event-driven Web MVC Frameworks13.3.2.1. Tapestry13.3.2.2. Java Server Faces13.3.3. A Word on ASP.NET13.4. Summary
14. Unit Testing and Testability
14.1. Why Testing Matters14.2. Goals of Unit Testing14.3. Ensuring Testability14.3.1. Programming Style14.3.2. How to Make Your Code Hard to Test14.3.2.1. EJB and the Potential to Create an Untestable Application14.3.2.2. The Singleton Antipattern14.3.2.3. Static Facades14.3.3. Standard Library Challenges14.3.4. Techniques for Improving Testability14.3.4.1. Code to Interfaces Rather than Classes14.3.4.2. Use the Strategy Design Pattern14.3.4.3. Consider the "Law of Demeter"14.3.4.4. Minimize Dependence on Environment-specific APIs14.3.4.5. Ensure That Each Object Has a Consistent Set of Responsibilities14.3.4.6. Hide Implementation Details14.3.4.7. Refactor into Methods to Allow Overriding14.3.5. Inversion of Control14.3.6. AOP14.4. Unit Testing Techniques14.4.1. Stubs14.4.2. Mock Objects14.4.2.1. Concepts14.4.2.2. Dynamic Mock Objects14.4.2.3. Deciding When to Use Mock Objects14.4.3. Writing Effective Tests14.4.3.1. Negative Tests14.4.3.2. Equivalence Partitioning14.4.3.3. Coding Practice14.4.3.3.1. Test Cases Should Be Economical Yet Self-documenting14.4.3.3.2. Don't Rely on External Configuration Unless There's No Alternative14.4.3.3.3. Refactor the Test Suite as Necessary14.4.3.3.4. Avoid Tests with Side-effects14.5. Test-driven Development (TDD)14.5.1. Benefits14.5.2. Arguments against TDD14.5.2.1. "TDD Means That There Won't Be an Overall Theme to the Design"14.5.2.2. "But TDD Goes out the Window When You Have a Deadline"14.5.2.3. "TDD Takes Longer, and the Client Won't Pay for It"14.5.2.4. "We Want Developers to Generate Code from a Model, Not Hack in Their IDE"14.5.2.5. "We Don't Like XP"14.5.3. Practicing TDD14.5.4. Learning TDD14.6. Case Study: The Spring Experience14.7. Testing Spring Applications14.7.1. Testing POJOs14.7.2. Benefiting from Spring Abstractions14.7.3. When You Do Need to Depend on Spring APIs14.7.4. Testing with an Alternate Configuration14.8. Coverage Analysis and Other Test Tools14.8.1. Test Generators14.8.2. Coverage Tools14.8.2.1. Benefits14.8.2.2. Dangers14.8.3. Mutation Testing Tools14.9. Resources14.10. Summary
15. Performance and Scalability
15.1. Definitions15.2. Setting Clear Goals15.3. Architectural Choices: The Key to Performance and Scalability15.3.1. Object Distribution, Clusters, and Farms15.3.1.1. Definitions15.3.1.2. The Trouble with Distributed Objects15.3.1.3. Clustering Challenges15.3.2. Data Access15.3.3. Other Architectural Issues15.3.3.1. XML Usage15.3.3.2. Presentation Tier Technologies15.3.3.3. Portability versus Performance15.4. Implementation Choices15.4.1. The Performance Implications of Dispensing with EJB Service Provision15.4.1.1. Benchmark Methodology15.4.1.2. Declarative and Programmatic Middleware Models15.4.1.3. Remote SLSB with CMT15.4.1.4. Local SLSB with CMT15.4.1.5. AOP Transaction Management15.4.1.6. Programmatic Transaction Management15.4.1.7. Threading Models15.4.1.8. Shared Multithreaded Object15.4.1.9. Spring Instance Pooling15.4.1.10. Result Summary and Conclusions15.4.2. Caching and Code Optimization15.4.2.1. Code Optimization and Why to Avoid it15.4.2.2. Caching15.4.2.3. Potential Code Optimizations15.4.2.4. Start with Algorithms15.4.2.5. Use the Correct Collection Type15.4.2.6. Avoid Unnecessary String Operations15.4.2.7. Unnecessary Logging15.4.2.8. Contentious Optimizations15.4.2.9. Opportunities to Improve Tests15.5. Tuning and Deployment15.5.1. JVM15.5.2. Application Server15.5.3. Framework Configuration15.5.4. Database Configuration15.6. An Evidence-based Approach to Performance15.6.1. Benchmarking15.6.2. Profiling15.6.2.1. Why Use a Profiler?15.6.2.2. Profiling in Practice15.6.3. Diagnostics15.7. Resources15.8. Summary
16. The Sample Application
16.1. Pet Store Requirements16.2. The iBATIS JPetStore 3.116.2.1. Middle Tier16.2.2. Remoting16.2.3. Room for Improvement16.3. Spring JPetStore16.3.1. Middle Tier16.3.1.1. Configuration Using IoC16.3.1.2. Transaction Management: TransactionProxyFactoryBean16.3.1.3. Transaction Management: Source-level Attributes16.3.2. Data Access Tier16.3.2.1. Local Transactions16.3.2.2. Distributed Transactions16.3.2.3. DAO Implementation16.3.3. Web Tier16.3.3.1. Struts 1.116.3.3.2. Simple Controllers16.3.3.3. Form Controllers16.3.3.4. Spring Web MVC16.3.3.5. Simple Controllers16.3.3.6. Form Controllers16.3.3.7. SignonInterceptor16.3.4. Remoting16.3.4.1. Exporting Remote Services16.3.4.2. Hessian and Burlap16.3.4.3. WSDL Web Service via Axis16.3.4.4. RMI Invoker16.3.4.5. Accessing Remote Services16.3.4.6. Hessian and Burlap16.3.4.7. WSDL Web Service via Axis16.3.4.8. RMI Invoker16.4. Build and Deployment16.4.1. WAR Deployment Issues16.4.1.1. Listeners and Startup Servlets16.4.1.2. Resource References16.4.1.3. JSP and JSTL16.4.2. Deploying the Spring JPetStore16.5. Summary
17. Conclusion
17.1. Looking Back17.2. Moving Forward17.2.1. Choosing the Best Architecture for Your Application17.2.2. The Lightweight Container Architecture17.2.3. Standards17.2.4. Is Spring the Only Alternative to EJB?17.2.5. Key Messages17.3. Guidelines17.3.1. Architecture17.3.2. Programming Style17.3.3. Inversion of Control (IoC) and Dependency Injection17.3.4. AOP17.3.5. Testing17.4. Last Words

Content preview from Expert One-on-One™ J2EE™ Development without EJB™

Chapter 13. Web Tier Design

Web applications are ubiquitous. (X)HTML-based web interfaces are the preferred front-end choice, not only for public Internet applications, but for many Intranet applications. Although the return of the thick (or rich or fat) client has been predicted for some years, most Java enterprise applications continue to adopt web-based user interfaces, and this is unlikely to change in the near future.

Many J2EE applications are dedicated web applications by their very nature. While this is hardly a revelation, classic J2EE architecture guidelines ignore its implications, in that they still proclaim distributed components as the cornerstone of any J2EE application. A typical J2EE web application demands for a clean architecture built on lightweight logical layers rather than (potentially) physically separated layers.

In previous chapters, we've emphasized the importance of reusable business interface layers. In a well-designed J2EE application, the business interface layer should be completely independent of the kinds of clients that will use it. In business-logic-driven applications, the business layer and underlying resource layers can often be developed and tested before the user interface(s), even before the choice of a particular user-interface technology.

Mixing various access technologies within the same application should pose no problem for a well-designed application, as we have already seen in Chapter 11 (Remoting) when we exposed business facades as ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9780764558313Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Expert One-on-One™ J2EE™ Development without EJB™

by Rod Johnson, Juergen Hoeller

Chapter 13. Web Tier Design

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.