Sun Java Center J2EE Patterns

Print-friendly Version

Value Object Assembler

Context

In a J2EE application, the server side business components are implemented using session beans, entity beans, data access objects, and so forth. Application clients frequently need to data, which is composed from multiple objects.

Problem

Application clients typically require the model or parts of the model to either present to the user or as an intermediate-processing step before providing some service. The application model is an abstraction of the business data and business logic implemented on the server side as business components. A model may be expressed as a collection of objects put together in a structured manner (tree or graph). In a J2EE application, the model is a distributed collection of objects such as session beans, or entity beans, or data access objects and other objects. For a client to obtain the data for the model, such as to display to the user or to perform some processing, it must access individually each distributed object that defines the model. This approach has several drawbacks:

• Because the client must individually access each distributed component, there is a tight coupling between the client and the distributed components of the model over the network
• The client accesses the distributed components via the network layer, and this can lead to performance degradation if the model is complex with numerous distributed components. Network and client performance degradation occur when a number of distributed business components implement the application model and the client directly interacts with these components to obtain model data from that component. Each such access results in a remote method call that introduces network overhead and increases the chattiness between the client and the business tier.
• The client must reconstruct the model after obtaining the model's parts from the distributed components. The client therefore needs to have the necessary business logic to construct the model. If the model construction is complex and numerous objects are involved in its definition, then there may be an additional performance overhead on the client due to the construction process. In addition, the client must contain the business logic to manage the relationships between the components, which results in a more complex, larger client. When the client constructs the application model, the construction happens on the client side. Complex model construction can result in a performance overhead on the client side for clients with limited resources.
• Because the client is tightly coupled to the model, changes to the model require changes to the client. Further, if there are different types of clients, it is more difficult to manage the changes across all client types. When there is tight coupling between the client and model implementation, which occurs when the client has direct knowledge of the model and manages the business component relationships, then changes to the model necessitate changes to the client. There is the further problem of code duplication for model access, which occurs when an application has many types of clients. This duplication makes client (code) management difficult when the model changes.

Forces

• Separation of business logic is required between the client and the server side components.
• Because the model consists of distributed components, access to each component is associated with a network overhead. It is desirable to minimize the number of remote method calls over the network.
• The client typically needs only to obtain the model to present it to the user. If the client must interact with multiple components to construct the model on the fly, the chattiness between the client and the application increases. Such chattiness may reduce the network performance.
• Even if the client wants to perform an update, it usually updates only certain part of the model and not the entire model.
• Clients do not need to be aware of the intricacies and dependencies in the model implementation. It is desirable to have loose coupling between the clients and the business components that implement the application model.
• Clients do not need to have the additional business logic required to construct the model from various business components.

Solution

Use a Value Object Assembler to build the required model or sub-model. The Value Object Assembler uses value objects to retrieve data from various business objects and other objects that define the model or part of the model.

The ValueObject represents data from different business components. The intention of this ValueObject is to carry the data for the model to the client in a single method call. Since the model data can be complex, it is recommended that this value object be immutable. That is, the client purely obtains such value objects for presentation and processing purposes (that is, read-only). Clients are not allowed to make changes to the value objects.

When the client needs the model data, and if the model is represented by a single coarse-grained component (such as an Aggregate Entity), then the process of obtaining the model data is simple. The client simply requests the coarse-grained components for its value object. However, most real world applications have a model comprised of a combination of many coarse-grained and fine-grained components. In this case, the client must interact with numerous such business components to obtain all the data necessary to represent the model. The immediate drawbacks of this approach can be seen in that the clients become tightly coupled with the model implementation (model elements) and that the clients tend to make numerous remote method invocations to obtain the data from each individual component.

In some cases, a single coarse-grained component (see Aggregate Entity pattern) provides the model or parts of the model as a single value object (simple or composite). However, when multiple components represent the model, a single value object (simple or composite) may not specify the entire model. To represent the model, it is necessary to obtain value objects from various components and assemble them into a new, composite value object. The server, not the client, should perform such "on the fly" construction of the model.

Structure

The following class diagram represents the relationships for the Value Object Assembler pattern.

Participants & Responsibilities

The following sequence diagram shows the interaction between the various participants in this pattern.

ValueObjectAssembler

The ValueObjectAssembler is the main class of this pattern. The ValueObjectAssembler constructs a new value object based on the requirements of the application when the client requests a composite value object. The ValueObjectAssembler then locates the required BusinessObject instances to retrieve data to build the composite value object. BusinessObjects are business tier components such as entity beans and session beans, data access objects, and so forth.

If the ValueObjectAssembler is implemented as an arbitrary Java object, then the client is typically a Session Façade that provides the boundary controller layer to the business tier. If the ValueObjectAssembler is implemented as a session bean, then the client can be a Session Façade or a Business Delegate.

The BusinessObject participates in the construction of the new value object by providing the required data to the ValueObjectAssembler. Therefore, the BusinessObject is a role that can be fulfilled by a session bean, an entity bean, a data access object, or a regular Java object.

ValueObject

The value object constructed by the ValueObjectAssembler and returned to the client .

BusinessSession

BusinessObject is a role that can be fulfilled by a session bean. It is shown as the BusinessSession in the sequence diagram.

BusinessEntity

BusinessObject is a role that can be fulfilled by an entity bean. It is shown as the BusinessEntity in the sequence diagram.

DataAccessObject

A data access object abstracts the database access and provides an interface to load and store data. When the ValueObjectAssembler needs to obtain data directly from the persistent storage to build the value object, it can use a data access object. This is shown as the DataAccessObject object in the diagrams.

Strategies

This section explains different strategies for implementing a Value Object Assembler pattern.

ValueObjectAssembler as an arbitrary Java Object

Business Object Strategy

The BusinessObject role in this pattern can be supported by different types of objects as explained below.

• The BusinessObject can be a session bean. The ValueObjectAssembler may use a Service Locator (see Service Locator pattern) to locate the required session bean. The ValueObjectAssembler requests this session bean to provide the data to construct the composite value object.
• The BusinessObject can be an entity bean. The ValueObjectAssembler may use a Service Locator (see Service Locator pattern) to locate the required entity bean. The ValueObjectAssembler requests this entity bean to provide the data to construct the composite value object.
• The BusinessObject can be a data access object. The ValueObjectAssembler requests this data access object to provide the data to construct the composite value object.
• The BusinessObject can be an arbitrary Java object. The ValueObjectAssembler requests this Java object to provide the data to construct the composite value object.
• The BusinessObject can be another ValueObjectAssembler. The ValueObjectAssembler requests the other Value Object Assembler to provide the data to construct the composite value object.
   

Consequences

• Separation of business logic
  When the client includes logic to manage the interactions with distributed components, it becomes difficult to clearly separate business logic from the client tier. The Value Object Assembler contains the business logic to maintain the object relationships and to construct the composite value object representing the model. The client needs no knowledge of how to construct the model or the different components that provide data to assemble the model.
• Loose coupling between clients and the Application Model
  The Value Object Assembler hides the complexity of the construction of model data from the clients and establishes a loose coupling between clients and the model. With loose coupling, if the model changes, then the Value Object Assembler requires a corresponding change. However, the client is not dependent on the model construction and inter-relationships between model business components, so model changes do not directly affect the client. In general, loose coupling is preferred to tight coupling.
• Network performance
  The Value Object Assembler drastically reduces the network overhead of remote method calls and chattiness. The client can request the data for the application model from the Value Object Assembler in a single remote method call. The assembler constructs and returns the composite value object for the model. However, the composite value object may contain a large amount of data. Thus, while use of the Value Object Assembler reduces the number of network calls, there is an increase in the amount of data transported in a single call. This tradeoff should be considered in applying this pattern.
• Client performance
  The server-side Value Object Assembler constructs the model as a composite value object without using any client resources. The client spends no time assembling the model.
• Transaction performance
  Typically, updates are isolated to a very small part of the model and can be performed by fine-grained transactions. These transactions focus on isolated parts of the model instead of locking up the coarse-grained object (model). After the client obtains the model and displays or processes it locally, the user (or the client) may need to update or otherwise modify the model. The client can interact directly with a session façade to accomplish this at a suitable granularity level. The Value Object Assembler is not involved in the transaction to update or modify the model. There is better performance control because transactional work with the model happens at the appropriate level of granularity.
• Stale Value Objects
  The Value Object Assembler constructs value objects on demand. These value objects are snapshots of the current state of the model represented by various business components. Once the client obtains a value object from the Value Object Assembler, that value object is entirely local to the client. Since the value objects are not network aware, other changes made to the business components used to construct the value object are not reflected in the value objects. Therefore, after the value object is obtained, it can quickly become stale if there are transactions on the business components.

Related Patterns

The Value Object Assembler builds a coarse-grained composite value object from multiple source objects and manages the relationships between these source objects. A source object can be a session bean, entity bean, another Value Object Assembler, or a regular Java object.

• Value Object Pattern [SJC]
  The Value Object Assembler uses the Value Object pattern in order to create and transport value object to the client. The value object created carries the data for the application model to the clients requesting the data.

• Aggregate Entity Pattern [SJC]
  Aggregate Entity pattern promotes a coarse-grained entity bean design, where entities can produce composite value objects similar to the one produced by the Value Object Assembler. However, the Value Object Assembler is more applicable when the composite value object constructed is derived from a number of components (session beans, entity beans, data access objects, and so forth.) whereas the Aggregate Entity pattern constructs the value object from its own data (that is, a single entity bean).

• Session Façade Pattern [SJC]
  Value Object Assembler is typically implemented as a stateless session bean. As such, it could be viewed as a limited special application of the session façade pattern. More importantly, Value Object Assembler constructs composite value objects that are immutable. Therefore, the client receiving this composite value object can only use the data for its presentation and processing purposes. The client cannot update the value object. If the client needs to update the business objects that derive the composite value object, it may have to access a Session Façade that provides the business service.

• Data Access Object Pattern [SJC]
  A possible strategy for the Value Object Assembler involves obtaining data for the composite value object from the persistent store without enterprise bean involvement. The Data Access Object pattern can be applied, thus leveraging its benefits to provide persistent storage access to the Value Object Assembler.

• Service Locator Pattern [SJC]
  The Value Object Assembler needs to locate and use various business objects. The Service Locator pattern can be used in conjunction with the Value Object Assembler pattern whenever a business object or a service needs to be located.

(c) 2000-2001 Sun Microsystems, Inc. All Rights Reserved.

Version 1.0 Beta