HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Design patterns are a familiar resource and using them is a routine matter. Here are other ways to make them work better, especially in large-scale applications.

The Java Value Types (JVTs) design pattern targets the use of "managed entities." To see just how useful this can be, let's look at some examples of JVTs and how they can be fully leveraged in today's enterprise solutions. In this role, JVTs are essentially "helper" classes; that is, they're primarily useful for representing a snapshot of an entity's state. These JVTs are very similar to value objects, but the distinction between the two is well worth noting.

Classically, objects have been categorized as both reference and value objects. One regarded authority, Martin Fowler, in his book Refactoring (Addison-Wesley, 2000), identifies a distinction between reference and value objects. Reference objects describe entities such as customers or accounts that represent things that would logically be single objects in the real world. In contrast, value objects are objects defined entirely in terms of their values, such as dates or numbers. Yet there is a third type of object with characteristics of both reference and value objects that becomes valuable in large-scale applications. These objects are Java Value Types.

These JVT objects are not really entities in their own right, like reference objects; they're not defined entirely by their value like value objects. They're used to transport and adapt an entity's state between components of a system or to and from other formats, such as XML. To get an idea of their usefulness, consider the following example of the Java Value Type pattern. Our example is a common J2EE design that contains a persistence layer of entity EJBs and a business logic layer of stateless session EJBs, and uses JVTs to move information between the layers.

Our example is a stock brokerage firm Web site (see Figure 1). It has three entity EJBs for persisting stocks, bonds, and customers that make up the persistence framework. We also have stateless session EJBs in the business logic framework called SecManager, StockLocator, BondLocator, and CustomerLocator. The Web application, Web service, and JMS subsystems all access the business framework to obtain JVTs that represent the state of entities in the persistence framework.

Figure 1

The stateless session EJBs can also perform caching of the JVTs. For example, if each SecurityJVT has a timestamp of the quote (in the SecurityJVT), then the SecManager can cache these for a configurable period of time to reduce access load on the entity EJBs in the persistence framework.

JVT's Role in Designs: Loose Coupling
JVTs are extremely useful within enterprise applications for decoupling systems or technological layers. In our brokerage example we want to create a routine that purchases stock. In the classic style, you would call the purchaseStock(String symbol) method on the Customer entity. This method would then use some hard-coded mechanism to look up the entity that corresponds to the symbol and then query it for a stock price, time of quote, exchange ID, etc. Using a JVT approach, we would create a stateless session EJB on which we call the purchaseStock(String symbol, int shares, int customerID) method. This EJB would retrieve the StockJVT and the CustomerJVT from service locators. In this case the locators would retrieve the JVTs from CMP entity EJBs, but you can see how the use of JVTs and the locator would allow you to replace the source without having to change any of the logic.

It's incredibly useful to use common base classes with JVTs. Whereas the example entity EJBs don't use inheritance, the JVTs enable the use of inheritance to process the JVTs. Subsystems using JVTs need only access objects as the most generic subclass needed to perform their processing tasks. For example, the purchaseSecurity method in our example can operate on the generic SecurityJVT level since it just needs to know the price of the security. Then the purchaseStock and purchaseBond methods can use the appropriate locator to retrieve the StockJVT or BondJVT for their invocation, and then pass that object to the purchaseSecurity method for processing.

Versioning and Transactions with JVTs
JVTs can also benefit transaction handling and state management. Adding an attribute to a JVT object to represent the object's version and altering this as the state changes provides a mechanism that can indicate if an object has changed. If this attribute is a Date, then a developer can check at any time, when comparing to another instance of the same entity, which JVT has newer or older data and take appropriate actions.

This same approach can assist in better handling transactions. For instance, if another Date attribute is added to contain a timestamp of the last entity change (usually persisted along with the entity), then the code that's processing any JVT can determine if the entity it represents has changed since the JVT's state was set. This enables identifying "dirty" JVTs before getting into a possible transaction rollback situation. Of course, JVTs also enable the grouping of state changes on an entity, just as with value objects, which results in better performing applications. Keep in mind that one of the largest performance issues with any distributed application is the number of remote accesses to entities in the model. This can impact both the network efficiency and database locking bottlenecks. JVTs can be a very useful strategy in producing efficient, large-scale distributed applications.

To enhance the performance of our application, we can obtain a JVT when an EJB in our business layer begins a transaction that involves multiple entities, then make changes to copies of those JVTs. Prior to committing the changes back to the entities, it can query those entities for new state JVTs to see if the state had changed since it first queried the entities. If not, it can go ahead and commit. If the state had changed, it can decide how to handle the changes, thus avoiding rollback situations rather than letting the transaction manager handle the rollback. This is quite a bit more work, but is one way to improve performance for transactional applications with high volume changes.

Using JVTs with XML
JVTs are useful for converting to and from XML. One excellent strategy is to push generic marshaling to and from XML up to a base class of the JVT. This can be accomplished by using reflection for the method access. If JavaBean style property syntax is followed on the JVTs, and the fully qualified classname is stored on the XML as an attribute for the JVT, then a single JVT base class is capable of both reading and writing all subclasses out to XML and reading them from XML.

Using JVTs with Persistence
It's very useful to utilize JVTs with Java Data Objects (JDO). Much of this stems from the fact that JDO is focused upon persisting value objects, or JVTs. The combination of JVTs and JDO can be powerful, resulting in rapid and robust development of persistence frameworks that manage object/relational mapping from JVTs to relational databases. Several JDO products exist from open source products to commercial products. Figure 2 shows the JVTs being used to move entity state between the layers of an application.

Figure 2

This approach also works effectively with CMP EJBs (see Figure 2). The main difference between using CMP EJBs and JDO persistence is that with the former, you have all the advantages of EJBs: remote access, container managed transactions and security, etc. JDOs sometimes have the edge in mapping complex relational models. But that's a topic for another article.

Using JVTs Effectively with Web Services
The introduction of Web services has added yet another way of exposing enterprise systems. It adds to the existing list that includes Web interfaces and thick clients. What's most important in handling the increasing number of ways to expose your system is to have a strong design for adding multiple fašades to one system, and JVTs greatly facilitate this.

Consider stock quoting in our brokerage example. If you had built the system using the JVTs and locators described earlier, the Web interface probably just queried the stock locator for a StockJVT and then used that JVT to populate a quote page. There may have been an RMI fašade that accepted stock quote requests and used that same locator to fulfill the request. Now you can easily add a Web services fašade that similarly exposes the desired functionality by querying the locator for StockJVTs. The locator provides a good abstraction of the source of the JVT, and the JVT provides a common interface for all these systems to use that is robust and well suited to multitiered applications. This design allows you to easily change individual parts of the system without having to modify every system, and it allows for the easy development of new consumers of the systems information.

JVTs Assist in Large Team Development Projects
Systems are increasingly comprised of multiple subsystems collaborating to provide the overall functionality. Such a development strategy helps in large projects because testing the smaller components is easier than testing one mammoth system and those subsystems can be developed in parallel by subteams.

JVTs help to improve this team development paradigm. Using them between components allows for greater decoupling in which one system can be entirely replaced without the other system noticing. During development, test JVT generators can be developed that create JVTs with mock data so that they can be used as simulated input in the development of a subsystem. Similarly, automated tests can easily be developed for a subsystem that use mock input JVTs and compare the JVT output of a system to a predefined JVT with the expected output.

Summary
We've shown the value of the Java Value Type pattern in going beyond value objects to decouple technical layers within a J2EE application. Our JVTs enable us to utilize inheritance with entity EJBs that don't support inheritance. They provide objects that utilize standard JavaBean properties on Java classes to transport and manage state throughout a distributed J2EE application. They even assist in reducing the code needed to interact with Web services and enable communication with non-Java systems.

SIDEBAR

Is Performance Really an Issue?
Using JVTs changes the performance characteristics of your software. It replaces a series of individual get or set method calls with one larger call that, in the get case, has the overhead of object creation. In small applications that object creation overhead would probably slow the overall system down. Yet in enterprise applications, the small individual get and set calls may well be remote calls requiring socket communication. Thus in these cases you avoid significant latency by replacing these smaller method calls with one larger call.

Author Bio
Noah Horton, an R&D engineer for Hewlett-Packard for the last two years, has been programming in Java for five years and specializes in enterprise system design with Java. He most recently worked on an advanced service activation system for HP. [email protected]

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.