Code Sample 7 : the Value Object Class For a Service
Now for the rest of the code: The iterator pattern will be the same as in Code Sample 4, without any change. The Data Access Object will also be the same as in Code Sample 5.
The data access object will set the iterator’s collection as a set of value objects and the servlet will retrieve the attribute information from value objects and use it for display. The code of the servlet client that gets the value objects and displays the values would look like:
// All required imports
public class DisplayServices extends HttpServlet {
private CatalogDataAccessObject dao;
// other declarations
public void init() {
CatalogDataAccessObject dao = new CatalogDataAccessObject();
// all other inits required
}
public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
// other processing, if any
Integer startIndex = new Integer(request.getParameter(“StartIndex”));
Integer listSize = new Integer(request.getParameter(“ListSize”));
PageByPageIteratorImpl list =
dao.getServiceNames(startIndex.intValue(),
listSize.intValue());
Collection objs = list.getCollection();
// The collection is a collection of the value objects
// Now the list received is of requested size only
// extract the service names and the attributes from the value
// objects
// display everything and do other processing as required
}
// other method definitions
}
Code Sample 8
Now the Servlet uses the Fast Lane Reader pattern along with data access objects to get read-only data; It also uses the Page-By Page Iterator pattern. And the Value Objects are used to transfer coarse grained data. In this sample, it is assumed that an HTML page set embedded parameters “StartIndex”, “ListSize” and then invoked this servlet on user action
Points To Note
* Use of this pattern reduces network traffic and improves response time for coarse-grained, read-only data
* To further improve perfomance, the value objects can be cached
* Use of this pattern also reduces the hits on server as the number of remote calls made by clients is reduced
* The extra classes that represent various objects and attributes as Value Objects may add to complexity but this is a small price to pay when we consider the advantages of using this pattern
* The Value objects must be serializable and immutable. If clients have the capability to modify the Value Objects, then the state of the objects with the client and that with the server differ leading to inaccurate states. But the consequence of making the Value Objects immutable is that, if the data changes rapidly, the values in the Value Object might be stale
* Although, in the sample code above, we saw the Value Objects being used for transferring information from server to client(s), this pattern can be used for data transfer in the reverse direction also.
Conclusion
In this article we saw three different patterns that we can use effectively to improve the efficiency, performance and user experience of a J2EE application. The samples we saw to exemplify the use of the patterns seems to combine use of all three patterns. But we must understand that there is no need to use all these three patterns together. For example,
* we can use Value Object pattern for sending a single coarse-grained object (like contact information of a customer) from server to the client(s)
* we can use Page-By-Page Iterator for sending lists of simple objects from EJBs to clients
* we can use the Fast Lane Reader to read data from server and display all of them in one shot
The sample code we saw was also not complete. The intention was just to give an idea of what we are talking about. The Java Pet Store sample application and the patterns catalog of the J2EE Blueprints program gives formal definitions of the patterns we saw along with full blown, working sample code, UML diagrams etc. Interested readers may find more detailed information there.The next version of the EJBs (EJB 2.0) removes some of the overheads associated with remote calls by introducing the concept of “local interfaces”. Probably in a future article, we can discuss the effect of such a feature on these patterns.
References
1. Design Patterns section of the J2EE Blueprints Program at http://java.sun.com/j2ee/blueprints
2. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons Ltd., 1996.
3. M. Fowler’s Information System Architecture at http://martinfowler.com/isa/index.html
4. E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
5. “Gang of Four” Patterns Template at http://hillside.net/patterns/Writing/GOFtempl.html
Vijay Ramachandran is the technical lead of the J2EE BluePrints team (http://java.sun.com/blueprints) of Sun Microsystems. His major contributions include best practices and guidelines when developing business solutions using enterprise beans. He is currently focusing on the Web services features of forthcoming J2EE releases.
John Mark Kennedy is currently a Senior at the University of Kentucky pursuing a degree in Descision Sciences and Information Systems. His e commerce interests include eCRM and supply chain management infrastructure.
