1. Java EE Patterns Dan Bugariu

2.  What is Java EE ?  What is a Pattern ?

3. Historical References  1970 Christopher Alexander A Pattern Language  1994 GoF Design Patterns: Elements of Reusable Object- Oriented Software  2003 Alur, Crupi, Malks Core J2EE Patterns

4. Software Pattern types  design patterns  architectural patterns  analysis patterns  creational patterns  structural patterns  behavioral patterns

5. Java EE Patterns categories  presentation tier patterns  business tier patterns  integration tier patterns

10. Intercepting Filter  Context  Problem  Solution  Consequences  Centralizes Control with Loosely Coupled Handlers  Improves Reusability  Declarative and Flexible Configuration  Information Sharing is Inefficient

11. Front Controller  Context  Problem  Solution  Consequences  Centralizes Control  Improves Manageability of Security  Improves Reusability

12. Application Controller  Context  Problem  Solution  Consequences  Improves modularity  Improves reusability  Improves extensibility

13. Business Delegate  Context  Problem  Solution  Consequences  Reduces coupling, improves maintainability  Translates business service exceptions  Improves availability  Exposes a simpler, uniform interface to the business tier  Improves performance  Introduces an additional layer  Hides remoteness

14. Service Locator  Context  Problem  Solution  Consequences  Abstracts complexity  Provides uniform service access to clients  Facilitates adding EJB business components  Improves network performance  Improves client performance by caching

15. Session Façade  Context  Problem  Solution  Consequences  Introduces a layer that provides services to remote clients  Exposes a uniform coarse-grained interface  Reduces coupling between the tiers  Promotes layering, increases flexibility and maintainability  Reduces complexity  Improves performance, reduces fine-grained remote methods  Centralizes security management  Centralizes transaction control  Exposes fewer remote interfaces to clients

16. Application Service  Context  Problem  Solution  Consequences  Centralizes reusable business and workflow logic  Improves reusability of business logic  Avoids duplication of code  Simplifies facade implementations  Introduces additional layer in the business tier

17. Data Model Object  Context  Problem  Solution  Consequences  Promotes object-oriented approach to the business model implementation  Separates persistence logic from data model and business logic

18. Transfer Object  Context  Problem  Solution  Consequences  Reduces network traffic  Simplifies remote object and remote interface  Transfers more data in fewer remote calls  Reduces code duplication  Increases complexity due to synchronization and version control

19. Domain Store  Context  Problem  Solution  Consequences  Creating a custom persistence framework is a complex task  Multi-layer object tree loading and storing requires optimization techniques  Improves understanding of persistence frameworks  Improves testability of your persistent object model  Separates business object model from persistence logic

20. Q&A

21. Gata