Let us quickly review whatever we learnt about Design Patterns in the previous few chapters
• A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution
• There are 5 design patterns in the SCWCD Exam:
o Value Object Pattern
o Data Access Object Pattern
o Business Delegate Pattern
o Model View Controller Pattern &
o Front Controller Pattern
• The Value Object pattern provides the best way to exchange data across tiers or system boundaries, especially when there is network communication involved. This is a pattern that solves performance issues around network latency
• The DAO pattern provides the connection between the business logic tier and the resource (usually a database) tier. The Data Access Object represents a general interface to the resources layer: It handles all calls to it. JDBC is the most commonly used example of this
• The Business Delegate pattern reduces the dependency between tiers. It is an attempt to make tiers interchangeable so one can access or utilize the services of any other
• The Model-View-Controller architecture compartmentalizes the data and business logic (model) from the presentation (view) from the user action interpreter (controller).
• The Front Controller pattern presents one entry point to a Web site or service. It provides a centralized entry point that controls and manages Web request handling. It eliminates the dependency of the user on a direct resource.
The Key Terms we learnt in the previous few chapters are:
• Design Patterns
• Model-View-Controller
• Value Object
• Data Access Object
• Front Controller
• Business Delegate
Previous Chapter: Chapter 58 - Other Design Patterns
Next Chapter: Self Test - Chapters 51 to 58
Topics Covered in the Blog - Synopsis
Showing posts with label j2ee design pattern. Show all posts
Showing posts with label j2ee design pattern. Show all posts
Friday, April 29, 2011
Chapter 58: Design Patterns Beyond the SCWCD Exam
Design Patterns is a very big subject and we could just go on and on and on about them. The good news is that, the SCWCD exam covers only 5 design patterns which we have already seen. So, if you want you can conveniently ignore this chapter. But, I strongly urge you to read it, not to memorize but to improve your understanding of design patterns.
So, lets get started!!!
Other Design Patterns:
There are numerous other design patterns that are in use in the programming world. They are categorized into various types based on their purpose. Let us take a look at their categories and names.
1. Architectural Patterns
a. Decorator Pattern
b. Front Controller
c. Model View Controller
2. Advanced Architectural Patterns
a. Composite View Pattern
b. Service to Worker Pattern
c. View Helper Pattern
3. Scalability Patterns
a. Asynchronous Page Pattern
b. Caching Filter Pattern
c. Resource Pool Pattern
4. Business Tier Patterns
a. Entity Facade Pattern
5. Data Transfer Patterns
a. Data Transfer Hash Pattern
b. Data Transfer Object (DTO) Pattern
c. Row Set DTO Pattern
6. Database Patterns
a. DAO Factory
b. Data Access Object (DAO) Pattern
c. Lazy Load Pattern
d. Procedure Access Object Pattern
e. Serialized Entity Pattern
f. Table Inheritance Pattern
g. Tuple Table Pattern
7. Business Tier Interface Patterns
a. Business Delegate Pattern
b. Business Delegate Factory
c. Service Adapter Pattern
d. Service Locator Pattern
e. Session Facade Pattern
8. Concurrency Patterns
a. ACID Transaction Pattern
b. Lockable Object Pattern
c. Lock Manager Pattern
d. Optimistic Concurrency Pattern
e. Pessimistic Concurrency Pattern
f. Transactional Context Pattern
g. Version Number Pattern
As you can see, there are numerous other patterns in use and to be honest, this list is not exhaustive. This is purely a FYI kind of chapter. Whatever you need to know about design patterns was already covered in the previous chapters, and this chapter is just to tell you that, those 5 are just a drop in the ocean and not the whole thing.
Previous Chapter: Chapter 57 - Front Controller Pattern
Next Chapter: Quick Recap - Chapters 51 to 58
So, lets get started!!!
Other Design Patterns:
There are numerous other design patterns that are in use in the programming world. They are categorized into various types based on their purpose. Let us take a look at their categories and names.
1. Architectural Patterns
a. Decorator Pattern
b. Front Controller
c. Model View Controller
2. Advanced Architectural Patterns
a. Composite View Pattern
b. Service to Worker Pattern
c. View Helper Pattern
3. Scalability Patterns
a. Asynchronous Page Pattern
b. Caching Filter Pattern
c. Resource Pool Pattern
4. Business Tier Patterns
a. Entity Facade Pattern
5. Data Transfer Patterns
a. Data Transfer Hash Pattern
b. Data Transfer Object (DTO) Pattern
c. Row Set DTO Pattern
6. Database Patterns
a. DAO Factory
b. Data Access Object (DAO) Pattern
c. Lazy Load Pattern
d. Procedure Access Object Pattern
e. Serialized Entity Pattern
f. Table Inheritance Pattern
g. Tuple Table Pattern
7. Business Tier Interface Patterns
a. Business Delegate Pattern
b. Business Delegate Factory
c. Service Adapter Pattern
d. Service Locator Pattern
e. Session Facade Pattern
8. Concurrency Patterns
a. ACID Transaction Pattern
b. Lockable Object Pattern
c. Lock Manager Pattern
d. Optimistic Concurrency Pattern
e. Pessimistic Concurrency Pattern
f. Transactional Context Pattern
g. Version Number Pattern
As you can see, there are numerous other patterns in use and to be honest, this list is not exhaustive. This is purely a FYI kind of chapter. Whatever you need to know about design patterns was already covered in the previous chapters, and this chapter is just to tell you that, those 5 are just a drop in the ocean and not the whole thing.
Previous Chapter: Chapter 57 - Front Controller Pattern
Next Chapter: Quick Recap - Chapters 51 to 58
Chapter 57: Front Controller Pattern
This chapter is going to deal with the last pattern on the SCWCD exam – The Front Controller Pattern.
What is Front Controller Pattern?
The Front Controller pattern presents one entry point to a Web site or service. It provides a centralized entry point that controls and manages Web request handling. It eliminates the dependency of the user on a direct resource. Suppose you wanted to get the latest version of the servlet specification. You would be better off going to a central page that presents options that change over time than bookmarking the servlet specification directly as your bookmark might get outdated if a new version of the specification is hosted in a different page.
Is
This pattern is a presentation controller that allows the resources to change without breaking all the bookmarks to a given resource. Many sites use this. For example, Microsoft often changes the content in its MSDN library. However, there is front end for it that rarely changes. This way, you can bookmark that front-end URL and not worry about what they do behind it.
Is Not
This is not a pattern for a data storage viewer. It isn't a way for you to control data retrieval. Rather, it is a steady interface to the underlying Web resources that behave as the presentation tier.
Analogy
This pattern is like a travel agent. On every trip you start by stopping at the agency. You tell the agent where you want to go and she will take care of the arrangements. The actual flight, train, bus, and hotel details change between trips, but she always helps you get there.
Problem
When the user accesses resources directly without going through a centralized mechanism, the resource may have moved. Also, each view is on its own and required to provide its own system services. Lastly, each view has to provide navigation, but this is a problem as it doesn't know about the context or the global site.
Responsibility
This controller must delegate the request to the proper resource and view.
Aim
This pattern isolates the actual resources from direct access by the user.
Primary Activity
This pattern matches the correct resource to the request.
Context
Simplified Web sites expose all its resources directly. As a site grows, there comes a time when it is better to decouple the navigation from the resources. There needs to be a controller that manages the requests and decides which resource best satisfies the request.
Benefits
• It is better to have a central controller allocate shared resources rather than have individual resources fend for themselves independently.
• The location of resources may change.
• This pattern adds only a little more work to building a Web site at first.
• Multiple resources share common needs such as security (that is, authentication and authorization).
Usage
Large Web sites especially benefit from a front controller.
Consequences
• Caching is always good between parts that exchange a lot of data.
• This pattern changes the interface with the intent of making the API more stable from the presentation tier perspective.
• This pattern will now handle any exceptions, whether from the business tier itself or from the plumbing between it and the requester.
• This pattern isolates the presentation and the business tiers by adding a mediator between the two, making it easier to manage changes on either side.
Uses
• Servlet Front Strategy— This pattern is implemented as a servlet, which manages the aspects of request handling that are related to business processing and control flow. Because this strategy is not specifically related to display formatting, it is a bad idea to implement this component as a JSP page.
• Command and Controller Strategy— This strategy provides a generic interface to the helper components. The controller delegates responsibility to the helper components, which minimizes the coupling among these components.
• Logical Resource Mapping Strategy— In this case users request logical names rather than physical locations. This way the physical location can be mapped to the logical names dynamically, say, in a database or XML document.
Other Related Patterns
• View Helper Pattern— The Front Controller is combined with the View Helper pattern to provide containers for factoring business logic out of the view and to provide a central point of control and dispatch. Logic is factored forward into the front controller and back into the Helpers.
• Service to Worker— The Service to Worker pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
• Dispatcher View— The Dispatcher View pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
Previous Chapter: Chapter 56 - MVC Pattern
Next chapter: Chapter 58 - Other Design Patterns
What is Front Controller Pattern?
The Front Controller pattern presents one entry point to a Web site or service. It provides a centralized entry point that controls and manages Web request handling. It eliminates the dependency of the user on a direct resource. Suppose you wanted to get the latest version of the servlet specification. You would be better off going to a central page that presents options that change over time than bookmarking the servlet specification directly as your bookmark might get outdated if a new version of the specification is hosted in a different page.
Is
This pattern is a presentation controller that allows the resources to change without breaking all the bookmarks to a given resource. Many sites use this. For example, Microsoft often changes the content in its MSDN library. However, there is front end for it that rarely changes. This way, you can bookmark that front-end URL and not worry about what they do behind it.
Is Not
This is not a pattern for a data storage viewer. It isn't a way for you to control data retrieval. Rather, it is a steady interface to the underlying Web resources that behave as the presentation tier.
Analogy
This pattern is like a travel agent. On every trip you start by stopping at the agency. You tell the agent where you want to go and she will take care of the arrangements. The actual flight, train, bus, and hotel details change between trips, but she always helps you get there.
Problem
When the user accesses resources directly without going through a centralized mechanism, the resource may have moved. Also, each view is on its own and required to provide its own system services. Lastly, each view has to provide navigation, but this is a problem as it doesn't know about the context or the global site.
Responsibility
This controller must delegate the request to the proper resource and view.
Aim
This pattern isolates the actual resources from direct access by the user.
Primary Activity
This pattern matches the correct resource to the request.
Context
Simplified Web sites expose all its resources directly. As a site grows, there comes a time when it is better to decouple the navigation from the resources. There needs to be a controller that manages the requests and decides which resource best satisfies the request.
Benefits
• It is better to have a central controller allocate shared resources rather than have individual resources fend for themselves independently.
• The location of resources may change.
• This pattern adds only a little more work to building a Web site at first.
• Multiple resources share common needs such as security (that is, authentication and authorization).
Usage
Large Web sites especially benefit from a front controller.
Consequences
• Caching is always good between parts that exchange a lot of data.
• This pattern changes the interface with the intent of making the API more stable from the presentation tier perspective.
• This pattern will now handle any exceptions, whether from the business tier itself or from the plumbing between it and the requester.
• This pattern isolates the presentation and the business tiers by adding a mediator between the two, making it easier to manage changes on either side.
Uses
• Servlet Front Strategy— This pattern is implemented as a servlet, which manages the aspects of request handling that are related to business processing and control flow. Because this strategy is not specifically related to display formatting, it is a bad idea to implement this component as a JSP page.
• Command and Controller Strategy— This strategy provides a generic interface to the helper components. The controller delegates responsibility to the helper components, which minimizes the coupling among these components.
• Logical Resource Mapping Strategy— In this case users request logical names rather than physical locations. This way the physical location can be mapped to the logical names dynamically, say, in a database or XML document.
Other Related Patterns
• View Helper Pattern— The Front Controller is combined with the View Helper pattern to provide containers for factoring business logic out of the view and to provide a central point of control and dispatch. Logic is factored forward into the front controller and back into the Helpers.
• Service to Worker— The Service to Worker pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
• Dispatcher View— The Dispatcher View pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
Previous Chapter: Chapter 56 - MVC Pattern
Next chapter: Chapter 58 - Other Design Patterns
Chapter 55: Business Delegate Pattern
In this chapter, we are going to take a detailed look at the Business Delegate Pattern.
What is Business Delegate Pattern?
The Business Delegate pattern reduces the dependency between tiers. It is an attempt to make tiers interchangeable so one can access or utilize the services of any other.
Is
This pattern is a proxy that hides the complexity of remote service lookup and error recovery. It makes it easier to communicate requests and results from one layer to another.
Is Not
This is not a pattern for a layer itself. It isn't a way for you to create a business logic component or structure. Rather, it is an interface to a tier so that you can change the underlying components and not disturb the presentation tier.
Analogy
This pattern is like an ambassador. Like all good ambassadors, it can pass on the message from the host country to any other.
Problem
Whenever there is a dependency on a remote service, the probability of change between the caller and the called increases. How can you reduce the chances of the layer depending on the remote service breaking should the remote service change? This pattern helps protect the local layer from changes made to the remote service.
Ex: Lets say, the presentation tier interacts directly with a remote business logic layer. What if the business services change and the old API becomes invalid? If this happens the presentation tier will break.
Responsibility
This delegate is the proxy between the local layer and the remote service layer. It is responsible for reliably allowing the front layer to access the remote service.
Aim
This pattern isolates the presentation layer from changes in the business tier API.
Primary Activity
This pattern matches presentation component calls to the correct business tier methods.
Context
The current approach to multi-tier systems is to couple the presentation tier directly to the entire business service API; sometimes this coupling is made across a network.
Benefits
• Presentation-tier clients (including devices) need access to business services.
• The business tier API may change.
• The industry trend for large systems is to minimize coupling between presentation-tier clients and the business service API. This isolates the two so that a change in either side can be managed by the middle layer.
• There is a need for a cache between tiers.
• This pattern adds more work to building a system.
Usage
Large systems change components often. There is often a change in the business tier that breaks the access portion of clients.
Consequences
• Caching is always good between parts that exchange a lot of data.
• This pattern changes the interface with the intent of making the API more stable from the presentation tier perspective.
• This pattern will now handle any exceptions, whether from the business tier itself or from the plumbing between it and the requester.
• This pattern isolates the presentation and the business tiers from each other by adding a director between the two, making it is easier to manage changes on either side.
Uses
• B2B systems usually employ an XML exchange for communicating between disparate systems.
• Proxy services represent this pattern.
• Look up services usually represent this pattern, too.
• This pattern can be thought of as an underlying design feature of Java's overloading capability such as the System.out.print() group of methods. Using the same method name, you can print almost anything to the console, because the printing service handles the different data types. This pattern is bigger than that, but overloading illustrates the idea.
Other Related Patterns
• Service Locator Pattern— This pattern provides a common API for any business service lookup and access code.
• Proxy Pattern— Provides a stand-in for objects in the business tier.
• Adapter Pattern— You can use the Adapter pattern to provide coupling for disparate systems.
Previous Chapter: Chapter 54 - DAO Pattern
Next Chapter: Chapter 56 - MVC Pattern
What is Business Delegate Pattern?
The Business Delegate pattern reduces the dependency between tiers. It is an attempt to make tiers interchangeable so one can access or utilize the services of any other.
Is
This pattern is a proxy that hides the complexity of remote service lookup and error recovery. It makes it easier to communicate requests and results from one layer to another.
Is Not
This is not a pattern for a layer itself. It isn't a way for you to create a business logic component or structure. Rather, it is an interface to a tier so that you can change the underlying components and not disturb the presentation tier.
Analogy
This pattern is like an ambassador. Like all good ambassadors, it can pass on the message from the host country to any other.
Problem
Whenever there is a dependency on a remote service, the probability of change between the caller and the called increases. How can you reduce the chances of the layer depending on the remote service breaking should the remote service change? This pattern helps protect the local layer from changes made to the remote service.
Ex: Lets say, the presentation tier interacts directly with a remote business logic layer. What if the business services change and the old API becomes invalid? If this happens the presentation tier will break.
Responsibility
This delegate is the proxy between the local layer and the remote service layer. It is responsible for reliably allowing the front layer to access the remote service.
Aim
This pattern isolates the presentation layer from changes in the business tier API.
Primary Activity
This pattern matches presentation component calls to the correct business tier methods.
Context
The current approach to multi-tier systems is to couple the presentation tier directly to the entire business service API; sometimes this coupling is made across a network.
Benefits
• Presentation-tier clients (including devices) need access to business services.
• The business tier API may change.
• The industry trend for large systems is to minimize coupling between presentation-tier clients and the business service API. This isolates the two so that a change in either side can be managed by the middle layer.
• There is a need for a cache between tiers.
• This pattern adds more work to building a system.
Usage
Large systems change components often. There is often a change in the business tier that breaks the access portion of clients.
Consequences
• Caching is always good between parts that exchange a lot of data.
• This pattern changes the interface with the intent of making the API more stable from the presentation tier perspective.
• This pattern will now handle any exceptions, whether from the business tier itself or from the plumbing between it and the requester.
• This pattern isolates the presentation and the business tiers from each other by adding a director between the two, making it is easier to manage changes on either side.
Uses
• B2B systems usually employ an XML exchange for communicating between disparate systems.
• Proxy services represent this pattern.
• Look up services usually represent this pattern, too.
• This pattern can be thought of as an underlying design feature of Java's overloading capability such as the System.out.print() group of methods. Using the same method name, you can print almost anything to the console, because the printing service handles the different data types. This pattern is bigger than that, but overloading illustrates the idea.
Other Related Patterns
• Service Locator Pattern— This pattern provides a common API for any business service lookup and access code.
• Proxy Pattern— Provides a stand-in for objects in the business tier.
• Adapter Pattern— You can use the Adapter pattern to provide coupling for disparate systems.
Previous Chapter: Chapter 54 - DAO Pattern
Next Chapter: Chapter 56 - MVC Pattern
Chapter 54: Data Access Object Pattern
In this chapter, we are going to take a detailed look at the DAO or Data Access Object Design Pattern.
What is Data Access Object Pattern?
The DAO pattern provides the connection between the business logic tier and the resource (usually a database) tier. The Data Access Object represents a general interface to the resources layer: It handles all calls to it. JDBC is the most commonly used example of this. Almost all J2EE Applications that access the database have a direct or indirect implementation of the DAO Pattern.
Is
This pattern is an object that encapsulates a set of behaviors for accessing databases, files, and other resources. This way you have only one API to deal with rather than a different one for every type of resource.
Is Not
This is not a pattern for a resource itself. Frankly speaking, this isn't a way to build a database or file manager.
Analogy
This is like using an ATM machine. The same interface will fetch the information requested from the back end, even though the bank changed database products the previous week.
Problem
Applications often need to use persistent data. This data persists in many forms such as files, relational databases, XML storage, and other types of repositories. All these stores have different APIs. Interfacing with so many APIs presents a problem when designing clients.
Responsibility
This pattern provides a uniform API to any persistent data storage.
Aim
This pattern attempts to consolidate the accessing of data from a complex source or set of sources to one object. This will reduce the network overhead by minimizing the number of network calls to get data, but the reduction of network traffic is not the main intention of this pattern.
Primary Activity
Getting and setting data from and to a permanent data source.
Context
Access methods to data vary between types of storage and vendor.
Benefits
Various parts of an application require access to persistent stores like databases and files. The APIs are inconsistent between types of stores and even between different vendors of the same type of storage. There needs to be a layer that has a uniform API to access these disparate data sources.
Usage
Any application that requires access to several data source types or even an application that accesses only one, but may switch in the future. The SQL is encapsulated in the method. That way if the SQL or datasource change, the layers above won't because the API remains constant.
Consequences
• Clients and components can now access data with the same API, which makes the variety of sources transparent and reduces complexity.
• This makes changing data sources easy and reduces errors.
Uses
At one level, JDBC uses an Abstract Factory technique to provide one API to many databases and types of files; the very essence of this pattern. However, the emphasis Sun places on this pattern is that of encapsulating the SQL so the implementation of actually querying the database is hidden from the next layer.
Other Related Patterns
Abstract Factory: Sun uses this factory for data access object strategy. They base it on the abstract factory method.
Previous Chapter: Chapter 53 - Value Object Pattern
Next Chapter: Chapter 55 - Business Delegate Pattern
What is Data Access Object Pattern?
The DAO pattern provides the connection between the business logic tier and the resource (usually a database) tier. The Data Access Object represents a general interface to the resources layer: It handles all calls to it. JDBC is the most commonly used example of this. Almost all J2EE Applications that access the database have a direct or indirect implementation of the DAO Pattern.
Is
This pattern is an object that encapsulates a set of behaviors for accessing databases, files, and other resources. This way you have only one API to deal with rather than a different one for every type of resource.
Is Not
This is not a pattern for a resource itself. Frankly speaking, this isn't a way to build a database or file manager.
Analogy
This is like using an ATM machine. The same interface will fetch the information requested from the back end, even though the bank changed database products the previous week.
Problem
Applications often need to use persistent data. This data persists in many forms such as files, relational databases, XML storage, and other types of repositories. All these stores have different APIs. Interfacing with so many APIs presents a problem when designing clients.
Responsibility
This pattern provides a uniform API to any persistent data storage.
Aim
This pattern attempts to consolidate the accessing of data from a complex source or set of sources to one object. This will reduce the network overhead by minimizing the number of network calls to get data, but the reduction of network traffic is not the main intention of this pattern.
Primary Activity
Getting and setting data from and to a permanent data source.
Context
Access methods to data vary between types of storage and vendor.
Benefits
Various parts of an application require access to persistent stores like databases and files. The APIs are inconsistent between types of stores and even between different vendors of the same type of storage. There needs to be a layer that has a uniform API to access these disparate data sources.
Usage
Any application that requires access to several data source types or even an application that accesses only one, but may switch in the future. The SQL is encapsulated in the method. That way if the SQL or datasource change, the layers above won't because the API remains constant.
Consequences
• Clients and components can now access data with the same API, which makes the variety of sources transparent and reduces complexity.
• This makes changing data sources easy and reduces errors.
Uses
At one level, JDBC uses an Abstract Factory technique to provide one API to many databases and types of files; the very essence of this pattern. However, the emphasis Sun places on this pattern is that of encapsulating the SQL so the implementation of actually querying the database is hidden from the next layer.
Other Related Patterns
Abstract Factory: Sun uses this factory for data access object strategy. They base it on the abstract factory method.
Previous Chapter: Chapter 53 - Value Object Pattern
Next Chapter: Chapter 55 - Business Delegate Pattern
Chapter 53: Value Object Pattern
Value Object
In this chapter, we are going to take a detailed look at the Value Object Pattern.
What is Value Object Pattern?
The Value Object pattern provides the best way to exchange data across tiers or system boundaries, especially when there is network communication involved. This is a pattern that solves performance issues around network latency. Do I have to tell you that, this is a very useful pattern?
Is
This pattern is an object that encapsulates a set of values that is moved across the boundary so that attempts to get the values of those attributes are local calls.
Is Not
This pattern is not a concrete object. You wouldn't use it to create an object. You could use it to hold values of that object.
Analogy
This would be like placing several letters in a box to be mailed once a week instead of mailing the letters separately and multiple times over the week. The box is mailed once. When the box arrives, the mail carrier can just reach in the box for the next letter; she doesn't have to contact the origin, which would take a long time.
Problem
In J2EE, server-resident business applications often use session beans and entity beans. The session beans are responsible for functionality that is involved in one-to-one transactions with the client. In contrast, the entity beans are used to handle persistent data. So, the client will make many calls to the session bean to get data. That represents a lot of traffic, to and from a remote location because the bean may be at a server at a remote location. Likewise, the session bean may make many calls to the entity bean getting and setting attributes. The Value Object pattern encapsulates the data fields of an entity bean; VO has nothing to do with session beans (except that it is usually a session method call that returns a VO, instead of a remote entity reference).
This activity is inefficient. We need a way to eliminate all these potential network calls reducing overhead and providing a more direct access approach.
Responsibility
This pattern provides a mechanism to exchange many remote calls to local, direct calls.
Aim
This pattern attempts to reduce the network overhead by minimizing the number of network calls to get data from the business tier.
Primary Activity
Used to collect remote data into an object that is sent to the client, so now the client makes local calls to get values rather than remote ones.
Context
Multi-tier applications that need to exchange sets of data between the client and server often.
Benefits
• J2EE applications often use enterprise beans. All calls to these beans are performed via remote interfaces to the bean due to Java's architecture. This introduces overhead.
• The frequency of reads is greater than updates because the client gets the data from the business tier for presentation.
• The client usually needs a set of data, not just one attribute.
• Client calls to enterprise beans accessed over the network affects WebApp performance because of the sum of network latency of multiple attribute access to the entity bean.
• Regardless of Java's bean architecture, it would be better to collect attributes into one object and get them from it rather than make invoking remote methods for the same information.
Usage
This pattern is useful when you need a collection of data from a remote source or, more likely, when a client has to make several calls for data from entity beans.
Consequences
• Simplifies Entity Bean and Remote Interface— Sun suggests using getData() and setData() methods on certain entity beans as a way to get and set a value object containing the set of attribute values. Calling the getData() method once replaces multiple calls to get methods. Likewise, the setData() method replaces many set calls.
• Using this pattern transfers a set of values in one method call improving overall performance, especially over the network. It represents coarse versus fine-grained interfaces.
• The client can update, delete, and read the values that are now local at will. When done, it can update the data source in one call. However, there may be a problem with synchronization as the other clients won't know about the changes until the update call. In the case of updates, there can be two conflicting update calls by two clients, so this must be synchronized somehow.
Uses
The ResultSet of JDBC is a collection of data returned from the data source resulting from a query. The data is now local in the ResultSet object so all calls to it are local rather than many calls to the data source directly.
Other Related Patterns
• Aggregate Entity that uses Value Object to get data across tiers.
• Session Façade, which is the business interface for clients of J2EE applications. This pattern often uses value objects as an exchange mechanism with participating entity beans.
• Value List Handler is another pattern that provides lists of value objects constructed dynamically by accessing the persistent store at request time.
• Value Object Assembler builds composite value objects from different data sources. The data sources are usually session beans or entity beans that may be requested to provide their data as value objects.
Previous Chapter: Chapter 52 - Design Pattern Elements
Next Chapter: Chapter 54 - Data Access Object Pattern
In this chapter, we are going to take a detailed look at the Value Object Pattern.
What is Value Object Pattern?
The Value Object pattern provides the best way to exchange data across tiers or system boundaries, especially when there is network communication involved. This is a pattern that solves performance issues around network latency. Do I have to tell you that, this is a very useful pattern?
Is
This pattern is an object that encapsulates a set of values that is moved across the boundary so that attempts to get the values of those attributes are local calls.
Is Not
This pattern is not a concrete object. You wouldn't use it to create an object. You could use it to hold values of that object.
Analogy
This would be like placing several letters in a box to be mailed once a week instead of mailing the letters separately and multiple times over the week. The box is mailed once. When the box arrives, the mail carrier can just reach in the box for the next letter; she doesn't have to contact the origin, which would take a long time.
Problem
In J2EE, server-resident business applications often use session beans and entity beans. The session beans are responsible for functionality that is involved in one-to-one transactions with the client. In contrast, the entity beans are used to handle persistent data. So, the client will make many calls to the session bean to get data. That represents a lot of traffic, to and from a remote location because the bean may be at a server at a remote location. Likewise, the session bean may make many calls to the entity bean getting and setting attributes. The Value Object pattern encapsulates the data fields of an entity bean; VO has nothing to do with session beans (except that it is usually a session method call that returns a VO, instead of a remote entity reference).
This activity is inefficient. We need a way to eliminate all these potential network calls reducing overhead and providing a more direct access approach.
Responsibility
This pattern provides a mechanism to exchange many remote calls to local, direct calls.
Aim
This pattern attempts to reduce the network overhead by minimizing the number of network calls to get data from the business tier.
Primary Activity
Used to collect remote data into an object that is sent to the client, so now the client makes local calls to get values rather than remote ones.
Context
Multi-tier applications that need to exchange sets of data between the client and server often.
Benefits
• J2EE applications often use enterprise beans. All calls to these beans are performed via remote interfaces to the bean due to Java's architecture. This introduces overhead.
• The frequency of reads is greater than updates because the client gets the data from the business tier for presentation.
• The client usually needs a set of data, not just one attribute.
• Client calls to enterprise beans accessed over the network affects WebApp performance because of the sum of network latency of multiple attribute access to the entity bean.
• Regardless of Java's bean architecture, it would be better to collect attributes into one object and get them from it rather than make invoking remote methods for the same information.
Usage
This pattern is useful when you need a collection of data from a remote source or, more likely, when a client has to make several calls for data from entity beans.
Consequences
• Simplifies Entity Bean and Remote Interface— Sun suggests using getData() and setData() methods on certain entity beans as a way to get and set a value object containing the set of attribute values. Calling the getData() method once replaces multiple calls to get methods. Likewise, the setData() method replaces many set calls.
• Using this pattern transfers a set of values in one method call improving overall performance, especially over the network. It represents coarse versus fine-grained interfaces.
• The client can update, delete, and read the values that are now local at will. When done, it can update the data source in one call. However, there may be a problem with synchronization as the other clients won't know about the changes until the update call. In the case of updates, there can be two conflicting update calls by two clients, so this must be synchronized somehow.
Uses
The ResultSet of JDBC is a collection of data returned from the data source resulting from a query. The data is now local in the ResultSet object so all calls to it are local rather than many calls to the data source directly.
Other Related Patterns
• Aggregate Entity that uses Value Object to get data across tiers.
• Session Façade, which is the business interface for clients of J2EE applications. This pattern often uses value objects as an exchange mechanism with participating entity beans.
• Value List Handler is another pattern that provides lists of value objects constructed dynamically by accessing the persistent store at request time.
• Value Object Assembler builds composite value objects from different data sources. The data sources are usually session beans or entity beans that may be requested to provide their data as value objects.
Previous Chapter: Chapter 52 - Design Pattern Elements
Next Chapter: Chapter 54 - Data Access Object Pattern
Chapter 52: Design Pattern Elements
Before we dig into the specifics of the Design Patterns that are part of the SCWCD Exam, we need to know one important thing. “The Elements of a Design Pattern”. This is what you are going to learn in this chapter.
So, lets get started!!!
Elements of a Design Pattern:
There are many ways to define a pattern, but the classical way is to describe its elements, or the aspects of a pattern.
The 3 main elements in any Design pattern are:
• Context
• Problem and
• Solution
The following are their definitions:
• Context is the recurring situation in which a problem to be solved is found.
• Problems are the so-called forces, such as marketing and technological forces, that occur in this context.
• Solution is the defined design that reorganizes or manipulates, some say resolves, the problem forces into a desired outcome within that context.
The design pattern is not only these three, but the relationship between the three and the formal language that describes the whole business.
For the sake of easy understanding & explanation, the following are the elements that would be used while explaining each of the design patterns that are covered in this series:
• Is — A direct explanation of what the pattern is.
• Is Not — An attempt at contrasting the concept because it is often helpful to understand what something is by looking at what it isn't.
• Analogy — This provides a comparison based on general aspects. Analogies, hopefully, give you a way to connect what you already know to these patterns which may be new to you.
• Problem — A statement of the problem that describes the patterns reason/purpose and intent.
• Responsibility — This describes what the pattern is accountable for; the primary things it accomplishes.
• Aim — These are the goals and objectives the pattern should reach within the given context.
• Primary Activity — What the main activities done by the pattern are.
• Context — The conditions and environment in which the problem and its solution recur. In other words, where should you consider and apply this pattern?
• Benefits — Why use a particular pattern, its benefits or advantages.
• Usage — Which kinds of situations are good candidates for this pattern.
• Consequences — This describes the result of using the pattern, the final state of the system. There are good and bad consequences of applying the pattern. It may solve one problem, but give rise to a new one.
• Uses — This tells you one or more examples of how this pattern is being used.
• Other Related Patterns — This names other patterns that are related by context, solution, or consequences. The related pattern may solve the same problem in another way or share the same context, but resolve different forces.
Patterns on the Exam
From the SCWCD Exam perspective, you need to worry about only 5 patters and we will be covering all of them, one by one. As a precursor, the 5 patters are:
1. Value Object
2. Data Access Object
3. Business Delegate
4. Front Controller &
5. Model View Controller (MVC)
Previous Chapter: Chapter 51 - Introduction to Design Patterns
Next chapter: Chapter 53 - Value Object Pattern
So, lets get started!!!
Elements of a Design Pattern:
There are many ways to define a pattern, but the classical way is to describe its elements, or the aspects of a pattern.
The 3 main elements in any Design pattern are:
• Context
• Problem and
• Solution
The following are their definitions:
• Context is the recurring situation in which a problem to be solved is found.
• Problems are the so-called forces, such as marketing and technological forces, that occur in this context.
• Solution is the defined design that reorganizes or manipulates, some say resolves, the problem forces into a desired outcome within that context.
The design pattern is not only these three, but the relationship between the three and the formal language that describes the whole business.
For the sake of easy understanding & explanation, the following are the elements that would be used while explaining each of the design patterns that are covered in this series:
• Is — A direct explanation of what the pattern is.
• Is Not — An attempt at contrasting the concept because it is often helpful to understand what something is by looking at what it isn't.
• Analogy — This provides a comparison based on general aspects. Analogies, hopefully, give you a way to connect what you already know to these patterns which may be new to you.
• Problem — A statement of the problem that describes the patterns reason/purpose and intent.
• Responsibility — This describes what the pattern is accountable for; the primary things it accomplishes.
• Aim — These are the goals and objectives the pattern should reach within the given context.
• Primary Activity — What the main activities done by the pattern are.
• Context — The conditions and environment in which the problem and its solution recur. In other words, where should you consider and apply this pattern?
• Benefits — Why use a particular pattern, its benefits or advantages.
• Usage — Which kinds of situations are good candidates for this pattern.
• Consequences — This describes the result of using the pattern, the final state of the system. There are good and bad consequences of applying the pattern. It may solve one problem, but give rise to a new one.
• Uses — This tells you one or more examples of how this pattern is being used.
• Other Related Patterns — This names other patterns that are related by context, solution, or consequences. The related pattern may solve the same problem in another way or share the same context, but resolve different forces.
Patterns on the Exam
From the SCWCD Exam perspective, you need to worry about only 5 patters and we will be covering all of them, one by one. As a precursor, the 5 patters are:
1. Value Object
2. Data Access Object
3. Business Delegate
4. Front Controller &
5. Model View Controller (MVC)
Exam Trivia:
If you see any other pattern name, ignore it unless the question is one of those about which one is not a pattern.
Previous Chapter: Chapter 51 - Introduction to Design Patterns
Next chapter: Chapter 53 - Value Object Pattern
Chapter 51: Introduction to Design Patterns
Design Patterns are a very important topic from the SCWCD Exam perspective as well as from being a J2EE Programmer perspective. Any experienced J2EE programmer is expected to know about a few of the J2EE Design Patterns. These patterns are used extensively and are very useful to create enterprise class J2EE Web Applications. In this next few chapters, we are going to look in detail, some of the most commonly used Design Patters (Of Course, only the ones that are part of the SCWCD Exam)
This chapter, is going to be a short and sweet introduction to the J2EE Design Patterns.
So, lets get started!!!
A word of Caution: This chapter assumes you've read the previous chapters (well, obviously) and that you are familiar with object-oriented programming concepts, including the popular UML diagramming notation.
History of Design Patterns
The term “pattern” comes from the architect Christopher Alexander who wrote several books on Construction and Building. Although he was interested in urban planning and building architecture, his notions were clearly useful in many areas. Alexander, a building architect, was the first to “codify” patterns for architecture. Alexander didn't invent the idea of patterns nor was he the first to see them in designs. Of course, they were there before him, but his work on urban planning and building architecture isolated the idea better than anyone before him. Alexander was an architect extraordinaire. He is one of those rare people who take a step back and question why people do things the way they do. He gave the result of his inquiry the name Pattern Language and defined it at length in his seminal book by the same name.
While Alexander was thinking buildings and foundations, it became clear to many that his design patterns were abstract enough to be useful elsewhere. That is when the Gang of Four (GoF as we will refer to them henceforth), as Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides are now known, applied his patterns to software in their classic Design Patterns: Elements of Reusable Object-Oriented Software (1995, Addison-Wesley). It took a while, but the GoF have started a ground swell. There are now dozens of books, and numerous websites in the internet, about design patterns.
What is a Design Pattern?
Design patterns are often defined as “a solution to a problem in a context.” This falls short of the abstract definition that experts prefer.
Sun defines them in the following way: “A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution.”
Design Patterns are everywhere and are used (knowingly or unknowingly) by almost all J2EE Developers. Don’t worry my friend, you will be using them too and by the time you are done reading the next few chapters, you will be a Design Pattern Expert.
Previous Chapter: Self Test - Chapters 47 to 50
Next Chapter: Chapter 52 - Design Pattern Elements
This chapter, is going to be a short and sweet introduction to the J2EE Design Patterns.
So, lets get started!!!
A word of Caution: This chapter assumes you've read the previous chapters (well, obviously) and that you are familiar with object-oriented programming concepts, including the popular UML diagramming notation.
History of Design Patterns
The term “pattern” comes from the architect Christopher Alexander who wrote several books on Construction and Building. Although he was interested in urban planning and building architecture, his notions were clearly useful in many areas. Alexander, a building architect, was the first to “codify” patterns for architecture. Alexander didn't invent the idea of patterns nor was he the first to see them in designs. Of course, they were there before him, but his work on urban planning and building architecture isolated the idea better than anyone before him. Alexander was an architect extraordinaire. He is one of those rare people who take a step back and question why people do things the way they do. He gave the result of his inquiry the name Pattern Language and defined it at length in his seminal book by the same name.
While Alexander was thinking buildings and foundations, it became clear to many that his design patterns were abstract enough to be useful elsewhere. That is when the Gang of Four (GoF as we will refer to them henceforth), as Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides are now known, applied his patterns to software in their classic Design Patterns: Elements of Reusable Object-Oriented Software (1995, Addison-Wesley). It took a while, but the GoF have started a ground swell. There are now dozens of books, and numerous websites in the internet, about design patterns.
What is a Design Pattern?
Design patterns are often defined as “a solution to a problem in a context.” This falls short of the abstract definition that experts prefer.
Sun defines them in the following way: “A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution.”
Design Patterns are everywhere and are used (knowingly or unknowingly) by almost all J2EE Developers. Don’t worry my friend, you will be using them too and by the time you are done reading the next few chapters, you will be a Design Pattern Expert.
Previous Chapter: Self Test - Chapters 47 to 50
Next Chapter: Chapter 52 - Design Pattern Elements
Subscribe to:
Posts (Atom)
ShareThis
Followers