First we sould start with what are design pattern?
We can say a design pattern is simply a description of a recurring solution to a problem, given a context.The context is the environment, surroundings, situation, or interrelated conditions within which the problem exists.
Second why do need to use design patterns?
Design patterns have a number of advantages like -
1. Once described, any level engineer can use the pattern.
2. They allow for reuse without having to reinvent in every a project.
3. They allow to better define system structure.
4. They provide a design vocabulary.
5. They provide reusable artifacts.
6. Patterns can form frameworks that can then be used for implementations.
In this section we have tried to cover how to use and identify design patterns, in J2EE applications. The interest in design patterns has been around for a number of years in the software industry. However, interest among mainstream software developers is a fairly recent development actually it takes a highly experienced engineer to recognize a pattern, it requires collaboration, and it requires ongoing refinements.
There are a number of patterns that have been identified by the Sun Java Center for the presentation tier. We havve tried to explain them in this section , we are starting with a small explanation and then a complete section on each patterns
J2EE DESIGN PATTERNS - Front Controller
When the user access the view directly without going thought any centralized mechanism each view is required to provide its; own system services, often resulting in duplication of code and view navigations is left to the views, this may result in commingled view content and view navigation.
A centralized point of contact for handling a request may be useful, for example, to control and log a user's progress through the site. .
Introducing a controller as 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.
The controller provides a centralized entry point that controls and manages Web request handling. By centralizing decision points and controls, the controller also helps reduce the amount of Java code, called scriptlets, embedded in the JavaServer Pages (JSP) page.
Centralizing control in the controller and reducing business logic in the view promotes code reuse across requests. It is a preferable approach to the alternative-embedding code in multiple views-because that approach may lead to a more error-prone, reuse-by-copy- and-paste environment.
Typically, a controller coordinates with a dispatcher component. Dispatchers are responsible for view management and navigation. Thus, a dispatcher chooses the next view for the user and vectors control to the resource. Dispatchers may be encapsulated within the controller directly or can be extracted into a separate component.
The responsibilities of the components participating in this patterns are :
Controller : The controller is the initial contact point for handling all requests in the system. The controller may delegate to a helper to complete authentication and authorization of a user or to initiate contact retrieval.
Dispatcher : A dispatcher is responsible for view management and navigation, managing the choice of the next view to present to the user, and providing the mechanism for vectoring control to this resource. A dispatcher can be encapsulated within a controller or can be a separate component working in coordination. The dispatcher provides either a static dispatching to the view or a more sophisticated dynamic dispatching mechanism. The dispatcher uses the RequestDispatcher object (supported in the servlet specification) and encapsulates some additional processing.
Helper : A helper is responsible for helping a view or controller complete its processing. Thus, helpers have numerous responsibilities, including gathering data required by the view and storing this intermediate model, in which case the helper is sometimes referred to as a value bean. Additionally, helpers may adapt this data model for use by the view. Helpers can service requests for data from the view by simply providing access to the raw data or by formatting the data as Web content. A view may work with any number of helpers, which are typically implemented as JavaBeans components (JSP 1.0+) and custom tags (JSP 1.1+). Additionally, a helper may represent a Command object, a delegate, or an XSL Transformer, which is used in combination with a stylesheet to adapt and convert the model into the appropriate form.
View
A view represents and displays information to the client. The view retrieves information from a model. Helpers support views by encapsulating and adapting the underlying data model for use in the display.
Front Controller centralizes control. A controller provides a central place to handle system services and business logic across multiple requests. A controller manages business logic processing and request handling. Centralized access to an application means that requests are easily tracked and logged. Keep in mind, though, that as control centralizes, it is possible to introduce a single point of failure. In practice, this rarely is a problem, though, since multiple controllers typically exist, either within a single server or in a cluster.
Front Controller improves manageability of security. A controller centralizes control, providing a choke point for illicit access attempts into the Web application. In addition, auditing a single entrance into the application requires fewer resources than distributing security checks across all pages.
Front Controller improves reusability. A controller promotes cleaner application partitioning and encourages reuse, as code that is common among components moves into a controller or is managed by a controller.
J2EE DESIGN PATTERNS - Composite view
In real world application web pages present content from numerous data sources, using multiple subviews that comprise a single display page. The web pages are built by embedding formatting code directly with each atomic view. Atomic portion of the view content changes frequently , modification to the layout of multiple view is difficult and error prone when subviews are directly embedded and duplicated in multiple views. Embedding frequently changing portions of template text directly into views also potentially affects the availability and administration of the system. The server may need to be restarted before clients see the modifications or updates to these template components.
The solution to this is to use composite views that are composed 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.
This solution provides for the creation of a composite view based on the inclusion and substitution of modular dynamic and static template fragments. It promotes the reuse of atomic portions of the view by encouraging modular design. It is appropriate to use a composite view to generate pages containing display components that may be combined in a variety of ways. The layout of the page is managed and modified independent of the subview content.
Another benefit of this pattern is that Web designers can prototype the layout of a site, plugging static content into each of the template regions. As site development progresses, the actual content is substituted for these placeholders.
The responsibilities of the components participating in this patterns are :
Composite View : A composite view is a view that is an aggregate of multiple subviews.
View Manager : The View Manager manages the inclusion of portions of template fragments into the composite view. The View Manager may be part of a standard JSP page runtime engine, in the form of the standard JavaServer Pages (JSP page) pages include tag (
certain template fragments may be included only if the user fulfills a particular role or certain system conditions are satisfied. Furthermore, using a helper component as a View Manager allows for more sophisticated control of the page structure as a whole, which is useful for creating reusable page layouts.
Included View
An included view is a subview that is one atomic piece of a larger whole view. This included view could also potentially be a composite, itself including multiple subviews.
Composite view improves modularity and reuse. The pattern promotes modular design. It is possible to reuse atomic portions of a template, such as a table of stock quotes, in numerous views and to decorate these reused portions with different information. This pattern permits the table to be moved into its own module and simply included where necessary. This type of dynamic layout and composition reduces duplication, fosters reuse, and improves maintainability.
Composite view enhances flexibility. A sophisticated implementation may conditionally include view template fragments based on runtime decisions, such as user role or security policy.
Composite view enhances maintainability and manageability. It is much more efficient to manage changes to portions of a template when the template is not hardcoded directly into the view markup. When kept separate from the view, it is possible to modify modular portions of template content independent of the template layout. Additionally, these changes are available to the client immediately, depending on the implementation strategy. Modifications to the layout of a page are more easily managed as well, since changes are centralized.
Composite view reduces manageability. Aggregating atomic pieces of the display together to create a single view introduces the potential for display errors, since subviews are page fragments. This is a limitation that can become a manageability issue. For example, if a JSP page page is generating an HTML page using a main page that includes three subviews, and the subviews each include the HTML open and close tag (that is, and ), then the composed page will be invalid. Thus, it is important when using this pattern to be aware that subviews must not be complete views. Tag usage must be accounted for quite strictly in order to create valid composite views, and this can become a manageability issue.
But Composite view has performance impact. Generating a display that includes numerous subviews may slow performance. Runtime inclusion of subviews will result in a delay each time the page is served to the client. In an environment with strict Service Level Agreements that mandate specific response times, such performance slowdowns, though typically extremely minimal, may not be acceptable. An alternative is to move the subview inclusion to translation time, though this limits the subview to changing when the page is retranslated.
J2EE DESIGN PATTERNS - Business Delegate
When the presentation-tier components access the business services implemented by the business-directly through the exposed API of the services. The clients are exposed to the complexity of dealing with distributed components. The client is tightly coupled to the EJB layer, creating dependencies between client and server that affect both development, run-time and project management concerns. Due to this
1. The presentation-tier components are vulnerable to changes in the implementation of the business services, when ever the implementation of the business services change, the exposed implementation code in the presentation tier must change too.
2. All the client side components have to be aware of the location details of the business services say that each components has to use the JNDI lookup service to locate the required remote interfaces.
3. There may be a detrimental impact on network performance because presentation-tier components that use the business service API make too many invocations over the network. This happens when presentation-tier components use the underlying API directly, with no client-side caching mechanism or aggregating service.
The solution is to create a layer of Business Delegate 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.
Business delegate handle all the code that access the business services in the selected vendor software. When the vendor or the vendor software changes only changes that need to be made is to the company’s allocation software are changes to Business delegate, to access the business services. The presentation layer need not to be modified.
The business delegate object abstracts the business services API and provides standard interface to al the client components. It hides the underlying implementation detail such as lookup mechanism and the API of the business services. This reduces the coupling between the clients and the business services.
Another benefit is that the delegate may cache results and references to remote business services. Caching can significantly improve performance, because it limits unnecessary and potentially costly round trips over the network.
The responsibilities of the components participating in this pattern are:
Client components : The client components which are jsp pages and servlets in the presentation tier, delegate the work of locating the business service providers and the work of invoking the business service API methods to the Business Delegate objects.
Business Delegate : The business Delegate acts as a representative of the clinet components. It knows how to look up and access the business services. It invokes the appropriate business services method in the required order . If the API of the business service component changes, only Business Delegate needs to be modified without affecting the client components.
Business Service : A business service component implements the actual business logic. Some examples of the business service components are stateless session EJB and entity EJB a CORBA object or an RPC server.
J2EE DESIGN PATTERNS - Data Access Object
The client tier in an EJB system needs a way to transfer bulk data with the server, as the J2EE aplications implement server side business component.Some methods exposed by the business components return data to the client. Often, the client invokes a business object's get methods multiple times until it obtains all the attribute values.
If the client needs to display or update a set of attributes that live on the server, these attributes could live in an entity bean or be accessible through a session bean. The client could get or update the data is by loading many parameters into a method call, when updating data on the server, or by making multiple fine-grained calls to the server to retrieve data. Every call between the client and server is a remote method call with substantial network overhead. If the client application calls the individual getter and setter methods that require or update single attribute values, it will require as many remote calls as there are attributes. The individual calls generate a lot of network traffic and affects severely the system performance.
The solution to this problem is to use a plain java classes called Value Objects or Transfer Objects which encapsulate the bulk business data. A single method call is used to send and retrieve the Transfer Object / Value Obects. 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.
When an enterprise bean uses a Transfer Object / Value Obects, the client makes a single remote method invocation to the enterprise bean to request the Transfer Object / Value Obects instead of numerous remote method calls to get individual attribute values. The enterprise bean then constructs a new Transfer Object instance, copies values into the object and returns it to the client. The client receives the Transfer Object / Value Obects and can then invoke accessor or getter methods on the Transfer Object to get the individual attribute values from the Transfer Object. The implementation of the Transfer Object / Value Obectsmay be such that it makes all attributes public. Because the Transfer Object / Value Obects is passed by value to the client, all calls to the Transfer Object / Value Obects instance are local calls instead of remote method invocations.
A Transfer object / value object is a plain serializable Java class that represents a snapshot of some server side data, as in the following code example:
import java.io.Serializable;
public class OneValueObject implements Serializable {
private int attribute1;
private String attribute2;
private String attribute3;
private long attribute4;
…
public int getAttribute1();
public String getAttribute2();
public String getAttribute3();
public long getAttribute4();
…
}//OneValueObject
The responsibilities of the three components participating in this patterns are :
Client
This represents the client of the enterprise bean. The client can be an end-user application, like jsp, servlets or a java applet, as in the case of a rich client application that has been designed to directly access the enterprise beans. The client can be Business Delegates or a different BusinessObject.
Business Object
The Business Object represents a role in this pattern that can be fulfilled by a session bean, an entity bean, or a Data Access Object (DAO). The BusinessObject is responsible for creating the Transfer Object and returning it to the client upon request. The Business Object may also receive data from the client in the form of a Transfer Object / Value Obects and use that data to perform an update.
Transfer Object / Value Objects
The Transfer Object / Value Obects is an arbitrary serializable Java object referred to as a Transfer Object / Value Obects. Transfer Object / Value Obects has all the business values required by the client. A Transfer Object / Value Obects class may provide a constructor that accepts all the required attributes to create the Transfer Object / Value Obects. The constructor may accept all entity bean attribute values that the Transfer Object / Value Obects is designed to hold. Typically, the members in the Transfer Object / Value Obects are defined as public, thus eliminating the need for get and set methods. If some protection is necessary, then the members could be defined as protected or private, and methods are provided to get the values. Transfer Objects / Value Obects can be mutable or immutabel depending on whether the application wants to allow updates to the Transfer Objects / Value Obects
J2EE DESIGN PATTERNS - Transfer Object / Value Object
The client tier in an EJB system needs a way to transfer bulk data with the server, as the J2EE aplications implement server side business component.Some methods exposed by the business components return data to the client. Often, the client invokes a business object's get methods multiple times until it obtains all the attribute values.
If the client needs to display or update a set of attributes that live on the server, these attributes could live in an entity bean or be accessible through a session bean. The client could get or update the data is by loading many parameters into a method call, when updating data on the server, or by making multiple fine-grained calls to the server to retrieve data. Every call between the client and server is a remote method call with substantial network overhead. If the client application calls the individual getter and setter methods that require or update single attribute values, it will require as many remote calls as there are attributes. The individual calls generate a lot of network traffic and affects severely the system performance.
The solution to this problem is to use a plain java classes called Value Objects or Transfer Objects which encapsulate the bulk business data. A single method call is used to send and retrieve the Transfer Object / Value Obects. 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.
When an enterprise bean uses a Transfer Object / Value Obects, the client makes a single remote method invocation to the enterprise bean to request the Transfer Object / Value Obects instead of numerous remote method calls to get individual attribute values. The enterprise bean then constructs a new Transfer Object instance, copies values into the object and returns it to the client. The client receives the Transfer Object / Value Obects and can then invoke accessor or getter methods on the Transfer Object to get the individual attribute values from the Transfer Object. The implementation of the Transfer Object / Value Obectsmay be such that it makes all attributes public. Because the Transfer Object / Value Obects is passed by value to the client, all calls to the Transfer Object / Value Obects instance are local calls instead of remote method invocations.
A Transfer object / value object is a plain serializable Java class that represents a snapshot of some server side data, as in the following code example:
import java.io.Serializable;
public class OneValueObject implements Serializable {
private int attribute1;
private String attribute2;
private String attribute3;
private long attribute4;
…
public int getAttribute1();
public String getAttribute2();
public String getAttribute3();
public long getAttribute4();
…
}//OneValueObject
The responsibilities of the three components participating in this patterns are :
Client
This represents the client of the enterprise bean. The client can be an end-user application, like jsp, servlets or a java applet, as in the case of a rich client application that has been designed to directly access the enterprise beans. The client can be Business Delegates or a different BusinessObject.
Business Object
The Business Object represents a role in this pattern that can be fulfilled by a session bean, an entity bean, or a Data Access Object (DAO). The BusinessObject is responsible for creating the Transfer Object and returning it to the client upon request. The Business Object may also receive data from the client in the form of a Transfer Object / Value Obects and use that data to perform an update.
Transfer Object / Value Objects
The Transfer Object / Value Obects is an arbitrary serializable Java object referred to as a Transfer Object / Value Obects. Transfer Object / Value Obects has all the business values required by the client. A Transfer Object / Value Obects class may provide a constructor that accepts all the required attributes to create the Transfer Object / Value Obects. The constructor may accept all entity bean attribute values that the Transfer Object / Value Obects is designed to hold. Typically, the members in the Transfer Object / Value Obects are defined as public, thus eliminating the need for get and set methods. If some protection is necessary, then the members could be defined as protected or private, and methods are provided to get the values. Transfer Objects / Value Obects can be mutable or immutabel depending on whether the application wants to allow updates to the Transfer Objects / Value Obects
Service Locator
See Core J2EE Patterns, 2nd Edition for full description of this pattern and its strategies.
Problem
You want to transparently locate business components and services in a uniform manner.
Forces
• You want to use the JNDI API to look up and use business components, such as enterprise beans and JMS components, and services such as data sources.
• You want to centralize and reuse the implementation of lookup mechanisms for J2EE application clients.
• You want to encapsulate vendor dependencies for registry implementations, and hide the dependency and complexity from the clients.
• You want to avoid performance overhead related to initial context creation and service lookups.
• You want to reestablish a connection to a previously accessed enterprise bean instance, using its Handle object.
Solution
Use a Service Locator to implement and encapsulate service and component lookup. A Service Locator hides the implementation details of the lookup mechanism and encapsulates related dependencies
Strategies
• EJB Service Locator Strategy
• JDBC DataSource Service Locator Strategy
• JMS Service Locator Strategies
o JMS Queue Service Locator Strategy
o JMS Topic Service Locator Strategy
• Web Service Locator Strategy
Consequences
• Abstracts complexity
• Provides uniform service access to clients
• Facilitates adding EJB business components
• Improves network performance
• Improves client performance by caching
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.