Eclectic Programmer

Authors: Christopher Steel, Ramesh Nagappan, Ray Lai

Publisher: Prentice Hall / Sun Microsystems Press

ISBN: 0131463071 (Click to buy from Amazon)

When the Gang of Four wrote Design Patterns, they could be reasonably assured that most readers would know the basics of object oriented programming, and so they could spend their time on best practices when using objects. Similarly, when the authors of Core J2EE patterns wrote their book, they were able to assume that readers knew the basics of server side java, such as Requests, Sessions, and EJBs. However, the authors of Core Security Patterns made a different choice. They chose, correctly in my view, to assume no prior security knowledge. Consequently, the authors start with an introduction to basic security principals, including such details as the various types of encryption algorithms (symmetric and asymmetric, and for symmetric, block and stream), giving examples of each. They then give examples of how the various types of encryption algorithms are used, and detail how common protocols such as SSL make use of the algorithms. They show common means of attack, and how various security principles can prevent such attacks.

Once these basics of security are laid out, the authors spend several chapters describe how the various java security packages come together to implement the security described in chapter 2. A quick perusal of the topics of these chapters explains why several chapters are necessary–as it turns out, there is quite a bit of security functionality already built into standard J2Se and J2EE. For example, in J2SE 5, there are tools for key generation and management, for looking up revoked certificates, and of course for encryption and decryption, among other things. JAAS is covered here as well. The authors then cover web services and identity management, and how various XML security standards, such as XML Signature, can be used in both cases, and describe the java tools to work with such standards.

Finally, the authors move to the patterns themselves, and here the book finally becomes more like the standard patterns book, giving examples of the different scenarious under which you would use patterns, and providing the pros and cons of each. Since many readers will have taken advantage of the previous sections to learn about all the security technologies in depth for the first time, the patterns then provide a welcome companion, describing the proper use of the various technologies. There is nothing unique about the pattern presentation here, as compared to the other more well know pattern books–patterns are described and the pros and cons of each are given in depth, and so this part of the book may not get as much use. Still, just for the first part of the book alone, this book is worth reading.

Authors: Deepak Alur, Dan Malks, John Crupi

Publisher: Prentice Hall / Sun Microsystems Press

ISBN: 0131422464 (Click to buy from Amazon)

With the advent of lightweight frameworks promoting dependency injection, and now JEE 5, with both dependency injection and pojo based EJBs, one might question the current practical applicability of a four year old book that describes patterns targeted at the JEE 1.4 platform. Indeed, some of the patterns in this book are outdated. However, the majority of the patterns are still applicable. This book review will go through each of the patterns, showing which of them are still relevant. If you decide that one or more of the still relevant patterns applies to the problems you are facing, then you would be well advised to purchase this book. The book divides its patterns into presentation tier, business tier, and integration tier, and I will use that same format.

Presentation patterns:

Intercepting Filter: This pattern is certainly still highly relevant. Indeed, this pattern is often how current frameworks add functionality. For example, in the Spring Framework, Acegi is used as the security manager. Acegi works as an intercepting filter, checking the incoming request to ensure that the user has permissions to access the target of the request.

Front Controller: The most well know front controller may be the one built into Struts. The struts controller takes protocol specific information, such as request parameters, and puts them into a more protocol independent object, such as a Form, and then delegates the rest of the processing to specific other classes. Such behavior is classic for a Front Controller, and can been seen in more modern frameworks as well. For example, in JSF, the request specific parameters are processed and directly applied in the Apply Request Values phase before the rest of the JSF lifecycle continues. If you are bypassing your framework for some set of requests, or not using a framework at all, then you should still write a Front Controller of your own.

Context Object: This is simply the protocol independent object created by the front controller holding the information received by the application, and meant to be passed to the rest of the application. It’s mostly hidden in current frameworks, which directly apply request values to your objects for you.

Application Controller: The most well known example here may be the Struts action subclasses that are written by programmers, but other frameworks also use application controllers. The idea here is to take the Context object, and then act on the information received. In more modern frameworks, this basic idea is still present, but without the context objects. For example, in JSF, a value change event may be used to act on information received from the user.

View Helper: This pattern is still used anytime a jsp or jsf tag is placed on a page, which is to say that is it highly relevant to today’s programmer. The view helper kicks in after the view is already in the process of being rendered, and helps to format or otherwise process the information in the business tier. The business tier may place objects in the session or request object, which are then processed and rendered by the view helper.

Composite View: This pattern is even more used today than when the book was first written, and consequently, frameworks have made this pattern easier and easier to use. In this pattern, a view is composed of multiple smaller views. For example, you may want to include a navigation bar on each page, but you don’t want to have to code that navigation bar in each page. Earlier composite views were assembled with jsp:include, and later with Struts Tiles. Using Tiles in Struts requires the use of a tiles config file, mapping tile name to jsp. Modern templating libraries such as facelets, which can be used with JSF, have tiling and composite views built in, and no external configuration is required.

Service to worker: This pattern describes how to combine some of the other presentation patterns, so that you can specify business logic to be performed before a view is rendered. Basically, the Front Controller delegates to the Application Controller, which communicates with the business layer (via a Command Object (GOF) or a Business Helper), and then the Application Controller determines which view to show. This model is still how even modern frameworks work.

Dispatcher view: This is simply an alternate to the service to worker, where the dispatcher simply delegates to the view, and the view can use view helpers to construct the view. As such, it is also used today.

Business patterns:

Business Delegate: This pattern is one that is less likely to be used in modern frameworks. The purpose of this pattern is to present a non ejb view of an underlying Session EJB facade, capturing and rethrowing EJB specific exceptions. The Business delegate can also handle lookups. However, with the dependency injection in today’s frameworks and in JEE5, lookups are not really needed, and a Session EJB is more likely to be local. When scaling is needed, the SessionEJB can be clustered, but one instance will still be local to the presentation layer, so again the remote access to a Session EJB is less likely.

Service Locator: This pattern is obsolete with dependency injection, present in most frameworks and JEE5.

Session Facade: Originally, to quote the book, the pattern was to “control client access to business objects” and “limit network traffic between remote clients and fine grained business components and services”. The key change is from when the book was originally written is that the remote clients today are often web services request, and so that generally limits any session facade servicing web services to being a Stateless session bean, as those are those are the only ones (in Jee5) which can expose a web service via a simple annotation. However, the other benefits that derive from controlling client access to business objects remain…in the rich domain model, access to modifications of the model are generally done via a session facade.

Application Service: The purpose of an application service is to hold logic that coordinates multiple business objects, removing such logic from teh session facade. However, with the advent of pojo bases EJBs that can easily communicate among themselves, leading to a rich domain model, the need for an Application Service pattern is diminished.

Business Object: While the importance of the Application Service has diminished, the importance of the business object pattern has increased. This is where the rich domain model, where the object model is patterned after the problem space, is actually implemented.

Composite Entity: This pattern, of tying the lifecycle of related business objects together, is quite useful, and has been standardized in EJB3 through the use of Value Type classes, which explicitly tie a Value Type lifecycle to that of an Entity.

Transfer Object: This pattern is now obsolete, since EJB3 entity beans can be detached from the persistence context and sent over the wire, if need be. Typically, though, these classes are not sent over the wire at all, but merely passed to the presentation layer as is.

Transfer Object Assembler: This pattern is mostly obsolete, for the same reasons as for the Transfer object, but it may still have a role in the use of web services, where you may want to send just a few objects, and not an entire object graph.

Value List Handler: This pattern is also obsolete since the built in query mechanisms of EJB3 does not use the same sort of mechanism as the finders of ejb2, and so is much more lightweight.

Integration Tier Patterns

Data Access Object: While technically, the persistence of objects can be handled through the EJB3 entity manger, it may still be nice to provide type safe DAOs. However, with generics in java 5, there is no need to write more than one such DAO with actual functionality it it–just write that one DAO, and then subclass it for each object type. The subclasses can be very simple and do not have to have any functionality in them–they are just for the strong typing. See this piece of hibernate documentation for examples.

Service Activator: The original reasons for this pattern (which is basically JMS) were for asynchronous methods, publish and subscribe, and splitting a business task into several parts. While publish and subscribe are still valid reasons for using messaging, there are now other options for the asynchronous part. For example, in the Seam framework, annotating a method with @Asychronous turns the method call into an asynchronous one. Behind the scenes, Seam uses the EJB Timer service (default) or Quartz to schedule a job that will run and actually perform the method. The main reason for choosing @Asynchronous would be ease of use. However, if your framework of choice does not support similar functionality, then JMS is still a useful option.

Domain Store: This pattern describes a way to persist and object model without changing the object model, and has thus been supplanted by EJB3.

As you can see from the above listing, many of the patterns described in the book are still in use today, and an understanding of the patterns will help you to understand and get the most use out of whatever modern framework you happen to choose.

<Authors: Grady Booch, Robert A Maksimchuk, Michael W. Engle, Bobbi J. Young, Jim Conallen, Kelli A. Houston

Publisher: Addison-Wesley. Part of the Addison-Wesley Object Technology Series

ISBN: 978-0201895513 (Click to buy from Amazon)

This book covers how one should go about designing object oriented software, assuming no prior object oriented experience. It takes as its mission not only the purely technical aspects of that task, but also delves into requirements gathering, to ensure that the object oriented software delivered at the end is actually something the customer wants.

Some time ago, our company started work on a new software product. We had just begun designing the object model when I was given this book to review. This circumstance presented a great opportunity to not only read about object oriented design, but also to immediately apply the concepts, and see if those concepts actually worked in practice. I found that this book had three primary strengths.

The first strength is that when presenting a particular concept, the history of both that concept and the alternatives to that concept are presented. This allows the user to see why a particular concept is recommended over others, so that the user does not need to repeat the mistakes of past object oriented practitioners. For example, they trace the development of programming languages as they became more and more object oriented, showing why certain features were added to languages and the functionality that such features enabled, and how such features should be used.

The second strength is the advice the authors give in helping the user develop an object model. The authors quickly disabuse one of the notion that it easy to come up with a great object model on the first try. Instead, the authors state that developing a great object model is hard work, and the model will undergo transitions and become better as a project progresses. Specifically, they say “The best software designs look simple, but as experience shows, it takes a lot of hard work to design a simple architecture”. They continue by comparing the correct classification of logic and state into proper classes as part of a broader problem of classification in general that has been with us since Aristotle first classified plants and animals, and was continued through Aquinas, Descartes, and Locke. While this history of classification didn’t help me design an object model any faster, it at least made me feel better to know that it’s a problem that is known to be hard.

Even though object design is a hard problem, the authors do provide ways to help, by giving heuristics for development. They advocate an iterative approach to design, by gathering requirements and then gradually adding the requirements into the project. Doing so allows quick feedback as to the suitability of the model, allowing it to be easily changed.

The third strength is that in the latter half of the book, the authors attempt to apply the ideas given in the first part of the book to real projects. The value of this part of the book is not in looking at the resulting project, but rather in their explanations of how they attempt to correctly apply the ideas to the projects. For example, when building a web application, they use EJB 2.x, complete with the EJB interfaces, Facades, DTOs, and so on. While a new project started today would probably not make that technology choice, most of the time spent by the authors in this web application is not spent on these technology details, but rather on how the requirements were gathered, and how those requirements translated into the object model. Such information is useful no matter what the underlying technology.

One of the questions to be answered when reviewing a book for the Austin Java Users Group is “Is there an existing, canonical book that already covers the same ground.” This struck me as interesting, because this book itself is the canonical book for object oriented analysis and design. Its constant references to current literature (the bibliography is 73 pages long) help to assure the reader that he or she is actually using research proven methods to properly construct object models that will be useful, flexible, and correct. Recommended.