Affiliated sites

Other sites

Business best practice - design patterns and OOD

J2EE patterns originally accompanied the now legendary Java Petstore Sample application. Showing best practices in J2EE design, they provided an illustrative catalog of solutions. Started out with the blueprint patterns, which have not been expanded for a considerably time - but carried over into the J2EE core patterns, which are updated with intervals.

Benefits of Design Patterns

Teaches good design
Proven best practice
Define set of concepts to use in communication between designers, architects and developers
Systematicly captures reusable experience, solving re-occurring types of problem

J2EE Design Patterns

Sun blueprint J2EE patterns (blueprint-13)
J2EE core patterns - PRESENTATION tier
J2EE core patterns - BUSINESS tier
J2EE core patterns - INTEGRATION tier

1. Sun blueprint J2EE patterns (blueprint-13)

Blueprint: originally intended to explain best practices for the Java Petstore Sample application.

1. 1. Business Delegate

Defines an intermediate class called a "business delegate", which decouples business components from the code that uses them. The Business Delegate pattern manages the complexity of distributed component lookup and exception handling, and may adapt the business component interface to a simpler interface for use by views. .

1.2. Composite Entity

Defines a solution of modeling a networks of interrelated business entities. The composite entity's interface is coarse-grained, and it manages interactions between fine-grained objects internally. This design pattern is especially useful for efficiently managing relationships to dependent objects

1.3. Composite View

Defines a view built using other reusable sub-views. A single change to a sub-view is automatically reflected in every composite view that uses it. Furthermore, the composite view manages the layout of its sub-views and can provide a template, making consistent look and feel feel easier to achieve and modify across the entire application.

1.4. Data Access Object (DAO)

Defines a separation of a data resource's client interface from its data access mechanisms by adapting a specific data resource's access API to a generic client interface.

1.5. Fast Lane Reader

Defines an efficient way to access tabular, read-only data. A fast lane reader component directly accesses persistent data using JDBCTM components, instead of using entity beans. The result is improved performance and less coding, because the component represents data in a form that is closer to how the data are used.

1.6. Front Controller

Defines a single component that is responsible for processing application requests. A front controller centralizes functions such as view selection, security, and templating, and applies them consistently across all pages or views. Consequently, when the behavior of these functions need to change, only a small part of the application needs to be changed: the controller and its helper classes.

1.7. Intercepting Filter

Defines an encapsulation of existing application resources with a filter that intercepts the reception of a request and the transmission of a response. An intercepting filter can pre-process or redirect application requests, and can post-process or replace the content of application responses. Intercepting filters can also be stacked one on top of the other to add a chain of separate, declaratively-deployable services to existing Web resources with no changes to source code. Figure 2 below shows a chain of two intercepting filters intercepting requests to two Web resources that they wrap.

1.8. Model-View-Controller

Defines decoupling of data access, business logic, and data presentation/user interaction.

1.9. Service Locator

Defines centralized point for distributed service object lookups, provides a centralized point of control, and may act as a cache that eliminates redundant lookups. It also encapsulates any vendor-specific features of the lookup process.

1.10. Session Facade

Defines a high-level business component which contains and centralizes complex interactions between lower-level business components. A Session Facade is implemented as a session enterprise bean. It provides clients with a single interface for the functionality of an application or application subset. It also decouples lower-level business components from one another, making designs more flexible and comprehensible.

1.11. Transfer Object (TO)

Defines a serializable class that groups a set of attributes, forming a composite value. This class is used as the return type of a remote business method. Clients receive instances of this class by calling coarse-grained business methods, and then locally access the fine-grained values within the transfer object. Fetching multiple values in one server roundtrip decreases network traffic and minimizes latency and server resource usage. Where DAO collects a set of data(base) related attributes, TO collects application related attributes.

1.12. Value List Handler

Defines a handler object used to iterate over a large, read-only list across tiers. A value list handler provides a client with an iterator for a virtual list that resides in another application tier. The iterator typically accesses a local ordered collection of Transfer Objects, representing a subrange of the large list. A Data Access Object (DAO) usually manages access to the list data, and may provide caching.

1.13. View Helper

Defines a class that does data retrieval for the view. It adapts a data resource to a simple API usable by application views. The View Helper pattern decouples business and application classes from one another and allows them to vary at their own rates. Decoupling also promotes reuse, because each business or presentation component has fewer dependencies. So the view can focus on formatting and presentation logic, and let the View Helper handle the processing and retrieval of data.

2. J2EE core patterns - PRESENTATION tier

J2EE core patterns defined a more broad approach to generic design patterns - not just only illustrated by the Java Petstore Sample application.

2.1 Intercepting filter

Defines substitutional filters to process common services in a standard manner without requiring changes to core request processing code. The filters intercept incoming requests and outgoing responses, allowing preprocessing and post-processing. We are able to add and remove these filters unobtrusively, without requiring changes to our existing code.

Additionally defined at the J2EE core pattern website.

2.2 Front controller

Defines a controller as the initial contact point for handling all requests in the system - providing the initial point of contact for handling a request. The controller manages the handling of the request, including invoking security services such as authentication and authorization, delegating business processing, managing the choice of an appropriate view, handling errors, and managing the selection of content creation strategies.

Additionally defined at the J2EE core pattern website.

2.3 View helper

Defines a view with formatting code, delegating its processing responsibilities to its helper classes, implemented as JavaBeans or custom tags. Helpers also store the view's intermediate data model and serve as business data adapters.

Additionally defined at the J2EE core pattern website.

2.4 Composite view

Defines views that are composed (aggregate) of multiple atomic subviews. Each component of the template may be included dynamically into the whole and the layout of the page may be managed independently of the content.

Additionally defined at the J2EE core pattern website.

2.5 Dispatcher view

Defines a combined controller and dispatcher with views and helpers (see "Front Controller" and "View Helper") to handle client requests and prepare a dynamic presentation as the response. Controllers do not delegate content retrieval to helpers, because these activities are deferred to the time of view processing. A dispatcher is responsible for view management and navigation and can be encapsulated either within a controller, a view, or a separate component

Additionally defined at the J2EE core pattern website.

2.6 Service to worker

Defines a common combination of other patterns from the catalog ("Front Controller" and "View Helper"). Both of these macro patterns describe the combination of a controller and dispatcher with views and helpers. While describing this common structure, they emphasize related but different usage patterns. Controllers delegate content retrieval to helpers, which manage the population of the intermediate model for the view. A dispatcher is responsible for view management and navigation and can be encapsulated either within a controller or a separate component.

Additionally defined at the J2EE core pattern website.

2.7 Context Object

Defines (at the J2EE core pattern website) an object to encapsulate state in a protocol-independent way to be shared throughout your application.

2.8 Application controller

Defines (at the J2EE core pattern website) a controlling class to centralize retrieval and invocation of request-processing components, such as commands and views.

3. J2EE core patterns - BUSINESS tier

3.1 Business delegate

Defines a delegate layer with the purpose to reduce coupling between presentation-tier clients and business services. The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture.

Additionally defined at the J2EE core pattern website.

3.2 Service locator

Defines object to abstract all JNDI usage and to hide the complexities of initial context creation, EJB home object lookup, and EJB object re-creation. Multiple clients can reuse the Service Locator object to reduce code complexity, provide a single point of control, and improve performance by providing a caching facility.

Additionally defined at the J2EE core pattern website.

3.3 Session facade

Defines an uniform coarse-grained service layer (such as a session bean) as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients.

Additionally defined at the J2EE core pattern website.

3.4 Composite entity

Defines a Composite Entity to model, represent, and manage a set of interrelated persistent objects rather than representing them as individual fine-grained entity beans. A Composite Entity bean represents a graph of objects.

Additionally defined at the J2EE core pattern website.

3.5 Transfer object

Defines a business data carrier object (Transfer Object) to encapsulate inter-process data exchange. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.

Additionally defined at the J2EE core pattern website.

3.6 Transfer object Assembler

Defines a single accesspoint for retrieving data composed from multiple objects. Transfer Object Assembler builds the required model or submodel. The Transfer Object Assembler uses Transfer Objects to retrieve data from various business objects and other objects that define the model or part of the model.

Additionally defined at the J2EE core pattern website.

3.7 Value List handler

Defines a provider for controlling search, caching results, and providing results to the client in a result set whose size and traversal meets the client's requirements.

Additionally defined at the J2EE core pattern website.

3.8 Application service

Defines (at the J2EE core pattern website) a service to centralize and aggregate behavior to provide a uniform service layer.

4. J2EE core patterns - INTEGRATION tier

4.1 Data Access Object (DAO)

Defines a centralized accesspoint Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.

Additionally defined at the J2EE core pattern website.

4.2 Service activator

Defines a service to receive asynchronous client requests and messages. On receiving a message, the Service Activator locates and invokes the necessary business methods on the business service components to fulfill the request asynchronously.

Additionally defined at the J2EE core pattern website.

4.3 Domain store

Defines (at the J2EE core pattern website) a way to separate persistance from your object model. Unlike J2EE's container-managed persistence and bean-managed persistence, which include persistence support code in the object model, Domain Store's persistence mechanism is separate from the object model.

4.4 Web service broker

Defines (at the J2EE core pattern website) a procedure for providing access to one or more services using XML and web protocols - to expose and broker services using XML and web protocols.

J2EE Patterns

There are a number of patterns used in developing J2EE applications. They may be found on some of the pages referred to in the links section below.

Contents