Value Object Assembler

Avijeet Dash and Satyabrata
Dash

Introduction

Value Objects are used whenever a set of fine-grained data has to be passed
back and forth between remote objects to avoid the overhead of multiple network
round trips. Typically Value Objects represent the data of a business entity.
Value Objects don’t have any relationship among them. They combining represent
the model or sub model of the system.

Clients usually need various views of the data for different display
requirements and other data processing. Such requirements need Composite Value
objects, which are formed from many Value Objects. The Value Objects come from
many sources like entity beans, business objects and possibly session beans. The
consolidation of value objects from all these different sources is what Value
Object Assembler stands for. It can be implemented as an independent Java object
or ideally as a session bean method.

When clients individually access each distributed objects that define the
model, it incurs the following overhead.

1. There is a tight coupling between Business and Presentation Layer
.
Session Façade tries to solve this problem by exposing only the
coarse-grained Session Bean to the clients. But the way Value Object Assembler
is different from Session
Façade is Value Object Assembler is used to construct Value
Objects. So Session Façade can be used as Value Object Assemblers when
the Façade constructs the Value Objects itself or Session Façade can use a
Java object to be used as Value Object Assemblers.
2. The client accesses the distributed components via Network layer, which
   is a potential overhead. This above observation is based on the assumption
   that Client Layer and Business Layer are remotely located from each other. For
   example Servlet and JSPs (Presentation Layer Clients) can be present in Web
   Server where as the Business Layer Façade (Session Bean) is present in the
   application Server.

   Even if we assume that both Client and Business Layers are physically
   located in the same JVM, but the inherent nature of EJB1.1 API makes all the
   call to business methods be treated as remote calls. EJB 2.0 therefore
   introduces Local Interface for local clients (clients co-existing in the
   same JVM), where calls are treated as normal call to any object in the JVM.

Value Object Assembler pattern is very helpful in a Client-Server model,
where client side remote calls to Server should be minimized to reduce the
network overhead.

This pattern enforces good design principles by loosening the couple between
Client and Business Layers. So any changes in the implementation on the Server
side will not affect the client unless there are some changes in the interface
(Session Façade).

Value object Assembler uses Value Objects to retrieve data from various
business objects and other objects that define the model or part of model.

Sample Code

Find the sample code at http://www.phptr.com/corej2eepatterns/codeChap8_3.html#ex8.28

Conclusion

Value Object Assembler pattern is closely related with the following
patterns.

1. Value
   Object

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.

2. Composite
   Entity

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).

3. Session
   Façade

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.

4. Data Access Object

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.

5. Service Locator

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.

(The authors are senior developers at MindTree Consulting. They can be
reached at avijeetd@mindtree.com and
satyabrata_dash@mindtree.com.)