Reuse of Database Access Layer Components in JEE Product ...

machinebrainySoftware and s/w Development

Jun 8, 2012 (5 years and 4 months ago)

320 views

Reuse of Database Access Layer Components in JEE Product Lines: Limitations
and a Possible Solution (Case Study)
Ding Peng, Stan Jarzabek, Damith Rajapakse
Department of Computer Science
School of Computing,
National University of Singapore
ding_peng@alumni.nus.edu.sg;stan@comp.nus.edu.sg;
dcsdcr@nus.edu.sg

Hongyu Zhang
Tsinghua University
China
hongyu@mail.tsinghua.edu.cn

Abstract
We set up an experiment to evaluate JEE as a platform for
product line development. While JEE provides many
useful mechanisms for reuse of common
services/components, still we found that systematic across-
the-board reuse in application domain-specific areas was
hard. The main difficulty was the lack of a mechanism to
represent groups of similar components in a generic,
adaptable form. Such similar components arise as the
number of variant features of a product line grows, and we
need accommodate legal combinations of variant features
in components of a product line architecture. Such
uncontrolled growth of similar component versions
hinders productivity of reuse-based development and
raises maintenance costs. In the paper, we study the
manifestation of this problem in the JEE™ database
access layer. Interactive Development Environments such
as NetBeans or JBuilder speed up the development
process, but they do not address the source of the problem,
which is the lack of mechanisms to design generic
components capable of accommodating variant features in
various combinations. We filled this gap with a “mixed
strategy” solution based on generative programming
technique of XVCL applied on top of JEE. In the paper, we
highlight the nature of the problems we encountered and
our solution.
1. Introduction
JEE
TM
is a widely accepted standard and platform for
Java based enterprise applications. Rapid application
development, reuse and flexible deployment of
applications are crucial in today’s enterprises. Component
platforms such as JEE help industries to achieve these
qualities. Another important industry trend is the product
line approach, whereby productivity is boosted by
systematic reuse across a family of similar software
systems. Because of much synergy in targets, JEE, already
widely accepted in industries, is an viable option to
consider for product lines.
In this paper, we describe an experiment in which we
explored this option. We worked with a product line that
we developed in an earlier project – a Computer-Aided
Dispatch (CAD) system family
1
. We completely re-
designed the previously developed product line
architecture to take best advantage of the JEE platform and
its reuse mechanisms. With understanding of the issues
specific to the new platform, we added some new variant
features
2
of CAD product line to facilitate better
evaluation. We included JBuilder™ into the toolbox for
the project.
We have positive and negative findings. JEE offers
many useful mechanisms for reuse in the area of common
services for component-based systems, such as component
communication and management of components’ lifetime.
Normally, a developer would have to switch his attention
between supporting such services and writing the actual
application code. There would be much repetition of
similar service code across components and mutual cross-
cutting of the application code and service code. JEE
component infrastructure avoids this problem in which it
is very supportive to product line goals.
However, we found little support for systematic reuse
in application domain-specific areas. For product lines
whose members differ in functional features, such as our
CAD systems, this is certainly a problem that needs to be
solved. In an earlier paper, we discussed the problem and
solution in the JEE presentation and business logic system
layers [12]. In this paper, we illustrate problems
encountered in the database access layer (DAL) and
analyze their sources. We outline a solution based on a
“mixed strategy” approach in which we enhance JEE with
generic design capabilities of XVCL (XML-based Variant
Configuration Language,
xvcl.comp.nus.edu.sg
). The




1
A project in collaboration with ST Electronics Pte Ltd., under
the Singapore-Ontario joint research project.
2
Variant features are product line requirements that vary across
product line members.



1
JEE/XVCL solution allows us to represent DAL
components as generic, adaptable meta-components.
Meta-components can be customized to produce specific
DAL components accommodating any legal combination
of variant features. Specifications of such customizations
are in both human- and machine-readable form. These
mechanisms are sufficient to keep the number and
complexity of DAL components under control in the
product line situation.
2. Brief introduction to JEE
JEE simplifies enterprise application development by
providing a standardized architecture that helps developers
reuse common service components. JEE takes advantage
of many features of the Java 2 Platform, Standard Edition,
such as "Write Once, Run Anywhere
TM
" portability,
JDBC
TM
API for database access, and a security model
that protects data even in internet applications. Building on
this base, JEE adds full support for Enterprise
JavaBeans
TM
(EJB) components, Java Servlets API,
JavaServer Pages
TM
and XML technology. Tools such as
NetBeans and JBuidler provide visual development
environment and template-like mechanism for automatic
generation of JEE/EJB components. JBuilder can be
integrated with application server such as BEA Weblogic,
Tomcat, etc.
3. CAD product line
We briefly describe the domain of our experimentation:
Computer Aided Dispatch (CAD for short) systems are
mission-critical systems that are used by police, fire &
rescue, health service, port operations and others. depicts a
basic operational scenario and roles of a CAD system for
Police.

incident!
Call Taker
D
ispatche
r

Task Manager
R
esources (police units)
monitor

assign task

p
hone

call

Incident
i f

handle

incident

Situation
display
Network



Figure 1. A CAD system for police
Once a Caller reports an incident, a Call Taker captures
the details about the incident and the Caller, and creates a
task for this incident. The Dispatcher selects suitable
Resources for un-dispatched tasks and dispatches the
Resources to execute the task. The Resources carries out
the task instructions and reports to the Task Manager. The
Task Manager actively monitors and updates the tasks
until the case is closed. The Task Manager closes a task
when there are no more activities associated with the task
in the context of CAD system.
At the basic operational level, all CAD systems are
similar. However, the specific context of operation results
in many variations on the basic operational scheme. We
depicted general CAD variant features in Figure 2 and JEE
data access layer (DAL) variant features in Figure 3.
General features
Validation
Database
Distributed
Centralized
Dispatch Algorithm
Call Taker and
Dispatcher Roles
(CT-DISP)
Location
Code Based
Shortest
Distance
Based
Merged
Seperated
Advanced
Validation
Basic
Validation
Encryption
Legend
Mandatory Requirement
Optional Requirement
Alternative Requirements
OR Requirements

Figure 2. General CAD features

Figure 3. Data access layer (DAL) features
4. CAD product line with JEE
We developed the CAD product line architecture
(CAD-PLA, for short) on JEE according to a blueprint of a
product line lifecyle developed in our earlier projects
[13][14], as follows: Having analyzed the CAD domain,
we scoped the product line by selecting variant features for
the project. Then, we defined a default CAD system – a
typical system in CAD domain. We designed logical
runtime architecture for the default CAD on JEE. We
designed CAD-PLA and its components for ease of
customization in the view of variants selected in domain
analysis. We implemented CAD-PLA as a collection of
component configurations [6] within a stable architecture
[5]. We explored EJB/JEE platform and tools (JBuilder) to
maximize reuse.

2
4.1. Domain analysis and a default CAD system
We used UML models such as use case, class,
sequence, activity and deployment diagrams, with
provisions for modeling variant features [8], to model
CAD domain. Task (Figure 4) is a central concept in CAD
systems: A Task is created as soon as the Call Taker has
received the information about the incident. The Task is
closed once the handling of the incident has been
completed. The Task’s lifecycle spans major CAD
components and all the major roles interact by means of a
Task. We defined a default CAD system around the Task
concept, as a natural bridge to a generic CAD-PLA.


Caller

-PhoneNo

-Name

-NRIC

-Location

Task
-ID
-Type
-Location
-SourceType
-Urgency
-Description
-CreationTime
-CompletionTime
-State
Call Taker

Dispatcher

Task Manager

Create/Update Task

1

n
Dispatch/Update Task

1

n
Update/Close Task

1

n
Informs

Resource

-ID

-State

-Location

-OrganizationID

Reports to

0..n

1

Operator

-OperatorID

-OrganisationID

-Name

Execute

Geographical Map
-Area
-Graphic
Displayed on
n
1
Displayed

n

1

DMPrOI
-Location
-PRoI Type
Happend in
0..1
1
Organization

-OrganizationID

-Name

-AreaOfResponsibility

-Manager

belongs to

n

1

Belongs To

n

1

n
1
n


Figure 4. CAD class diagram
4.2. A JEE CAD-PLA
We skip the intermediate step of building a runtime
architecture for the default CAD system and describe the
final, refined for reuse, JEE CAD-PLA. CAD-PLA was
based on a standard five-layer JEE model (Figure 5).

Figure 5. Five-layer architecture model
Presentation layer components used JSP to generate
and format responses to the clients. Enterprise beans
encapsulated the application logic on the server side. A
Session Bean represented an activity (or process)
operating on business objects and an Entity Bean provided
a persistent storage mechanism for business objects. Many
business objects corresponded to classes in a class diagram
of Figure 4. There are two types of persistence of Entity
Beans, namely bean-managed (BMP) and container-
managed (CMP) persistence. With BMP, a developer
writes the Entity Bean code to access a database. With
CMP, the EJB container automatically generates the
necessary database access calls. We applied both BMP and
CMP in our system. Typically, each Entity Bean has a
corresponding table in a relational database where bean
instances are stored. We used MySQL 4.0 as the Database
server.
One of the main performance problems associated with
EJBs is the amount of network traffic needed to access
attributes of the bean. The standard solution for alleviating
the network delays is to return all the attributes in one
method call, using a simple data-holder class. In JEE, this
is achieved by the Value Object Pattern [5] and we applied
it in our architecture. To achieve database independence,
we applied the Data Access Object (DAO) Pattern which
separates Entity Beans from low-level database access
code. We designed a generic evaluator component to
further separate DAO details from the query generation
and evaluation code. We also used MVC, Template,
Composite and many other recommended general and
JEE-specific design patterns.
5. Evaluation of the JEE DAL for CAD-PL
The five-layer architecture model has several
advantages. Firstly, rather than building isolated
components, it allows us to build modules comprising a
collection of client and server components, forming
meaningful parts of an application. These components
communicate through standardized, abstract interfaces,
and when combined together form a complete application.
Sometimes, change can be conveniently propagated from
one bean to other related beans. Suppose we change Task
bean from basic validation to advanced validation. Create
Task process and dispatch Task process beans will change
their behavior automatically to reflect advanced validation.
Tools such as Jbuilder™ provide templates to facilitate
auto generation of EJB codes, which speeds up
development. For example, to create a Task bean, a
developer typically enters attributes such as Task name, or
Task location into a template, and the tool creates methods
such as findByPrimaryKey, setTaskName, getTaskName,
setLocation, getLocation, etc. automatically. Reusability is
achieved due to EJB standard specification.
The key issue in product line (PL) approach is to
customize components of a product line architecture
(PLA) to accommodate variant features required in the

3
specific system, PL member, that we wish to build. The
ease of selecting PLA component configurations and their
customization determines the economic benefit of the PL
approach [6]. Therefore, we analyzed the impact of variant
features on CAD domain model, and JEE CAD-PLA
components. We found that variants had a profound
impact on CAD. Understanding the impact of variants on a
domain model is a good starting point for tracing the
impact of variants on PLA and components’ code. For
example, Caller/Task validation method (VALID) and
Call Taker and Dispatch roles (CT-DISP) affected use
cases such as Create Task, View Task, Create Caller, and
many others. Class and sequence diagrams were also
affected by these variants. As UML provisions for
modeling variant features are limited, we used extensions
described in [8] to model CAD product line.
At times, the impact of variants on the PLA and
components’ code was quite drastic, and required us to
change allocation of functions across components,
component communication patterns, and/or component
interfaces. Certain variants (or their combinations)
required us to include/exclude certain components to/from
a PLA. We say that a variant has architectural (or non-
local) impact on the PLA, if the chain of customizations
triggered by the variant spreads through the system rather
than being confined to a small number of components.
Variants that affected multiple CAD models most often
also had such architectural, non-local impact on JEE
CAD-PLA.
In our case study, most of the general variants had both
architectural and non-local impact on CAD. For example,
one option under the CT-DISP variant is that Dispatcher
and Call Taker roles are played by one person. In such
case, components related to CallTaker and Dispatch Task,
both user interface and business logic must be re-
formulated and re-designed into single components to
reflect new requirements for system operation. In most
cases, addressing a variant also requires us to modify
component implementation.
We have discussed handling general CAD variant
features in a CAD-PLA in other papers [12][13][14]. In
this paper, we focus on the database access layer (DAL)
features (Figure 3). Changes of a database and database
access codes may have profound impact on application-
level CAD components and vice versa. JEE uses DAO
pattern to shield application-level code from possible
changes in the database. DAL components, built around
DAO, receive database requests (queries) from the
business logic and presentation layers. DAL receives
result of the query first and then passes it to the caller in
the required format which is either input parameter or
output parameter.
CAD-PLA must cater for many CAD systems that
differ in general features (Figure 2). General variants often
affect the database structure, database access codes. The
choice of general features of CAD triggers the need for
specific variant features that affect DAL components
(Figure 3). Table 1 shows some of the Entity Bean DAL
components (listed in the first column) affected by variant
features (listed in the first row).
Table 1. DAL components

DB
Type
Connection
Pool
Input
Parameter
Bean
Type
Caller Bean
X
X
X
X
Task Bean
X
X
X
X
Organization Bean
X
X
X
X
Area Bean
X
X
X
X
Resource Bean
X
X
X
X
Location Bean
X

X

X

X
Command Bean
X

X

X

X
Any member of CAD product line needs Entity Beans
implementing some combination of features, as shown in
Figure 6. Strictly speaking, each path from the top to the
bottom in Figure 6 denotes a unique Entity Bean, that may
be needed in some CAD system. Suppose we address four
different databases, then we have four choices at Level 1.
We have two choices at Level 2; seven choices at Level 3;
and two choices at Level 4. Therefore, we may have as
many as 112 possible Entity Beans that arise from CAD
variant features. Here, our analysis covers only rather
simplified situation. In reality, transaction attribute,
exception handling and many other variants need be taken
into account which is likely to result in thousands possible
Entity Beans.

Figure 6. Features affecting DAL components
Entity Beans implementing various combinations of
variant features are similar to each other, in their
interfaces, the way they represent underlying tables, and in
implementation details. Consider Task bean and Caller
bean. Caller bean needs the caller phone information,
location information etc. Task bean needs the task creation
date, task area information. The classes implementing the
two beans are the same with the exception of attribute
names/types, and small differences in algorithmic details.
Unfortunately, JEE does not provide any mechanism to

4
abstract this kind of similarity pattern into a generic
component for reuse.
Component explosion problem affects all the software
layers, not only DAL. We observed the same situation in
JEE presentation and business logic component layers of
JEE Web Portals [12]. The problem is not limited to JEE.
Other OO and component-based technologies lack strong
enough mechanisms to address the problem at the root
level, or even to deal with its symptoms. Studies indicate
that as many as ten thousand versions of a component may
arise during evolution of industrial product lines [6].
6. JEE/XVCL “mixed strategy” solution
“Mixed strategy” approach avoids the problem of
component explosion by means of generic design:
Whenever we observe enough similarity among a group of
components affected by variant features, rather than
multiplying component versions, we apply generative
programming technique of XVCL to build a generic,
adaptable meta-component. Along with a generic
component, we keep specifications of how to produce
concrete components for required combinations of variant
features. Such specifications can be examined by a
developer, and also executed by the XVCL Processor to
produce custom components on demand.
We described XVCL mechanisms in other papers, so
here we only outline the general structure of the solution.

Figure 7. JEE/XVCL CAD-PL
Our JEE/XVCL “mixed strategy” solution addressed
four groups of similar components for which we built
generic meta-components. They are shown in rectangle
boxes of Figure 7 as CMP Entity Beans, BMP Entity
Beans, DAO Pattern, and SQL Evaluator. Below the
rectangle boxes, there are generic building blocks from
which the XVCL Processor could synthesize, after
possible customizations, concrete classes or Entity Beans.
The top-most meta-component, called SPC, contained
specifications describing how to customize lower level
meta-components to produce concrete classes or Entity
beans for any required combination of features.
7. Evaluation of results
In the default CAD built on JEE, DAL included 42
Entity Bean classes and 19 DAO classes, comprising the
total of 5811 LOC (without blank lines and comments).
The JEE/XVCL “mixed strategy” solution for DAL
consisted of 20 meta-components, comprising the total of
2354 LOC, counting both JEE and XVCL code. These 20
meta-components were generic and adaptable, capable of
accommodating anticipated range of variant features.
The reduction of physical and conceptual size of the
solution had positive impact on implementing changes.
We conducted an experiment to compare the effort
involved in changing DAL components in each of the JEE
and JEE/XVCL representations. We implemented variant
features in new combinations in both representations. We
considered variants DB Type, Connection Pool, Input
Parameter and Bean Type. We measured the effort in
terms of the number of modification points, modified
classes, and total number of lines of code (LOC) in Entity
Beans that we needed modify to accommodate the change.
In Figure 8 and Figure 9, we show the number of
modification points in DAL in each of the JEE and
JEE/XVCL “mixed strategy” solutions. Modification
points are either in class attributes (A), or methods (M) in
each of the 42 classes. X stands for DB Type, Y – for
Connection Pool, Z – for Input Parameter, and P – for
Bean Type.
Entity
Bean
DAO

Value
Object

A
M
A
M
A
M
Total

X
0
0
2
38
0
0
40
Y
0
0
3
38
0
0
41
Z
7
56
7
14
14
21
119
P
24
20
4
38
11
24
122
Figure 8. Modification points (JEE)
Entity
Bean
DAO

Value
Object


A
M
A
M
A
M
Total

X
0
0
1
3
0
0
4
Y
0
0
1
4
0
0
5
Z
1
8
1
4
1
3
18
P
3
4
1
6
1
4
19
Figure 9. Modification points (JEE/XVCL)
8. Conclusions
In the product line situation, variant features need be
implemented into software components, resulting in an
explosion of component versions. In the paper, we focused
on the problem of explosion of component versions in the

5
JEE database access layer (DAL), caused by feature
combinations.
In JEE solution, many similar components had to be
implemented. Despite striking similarities, groups of
similar components had to be repeatedly implemented. We
addressed the problem with a generative technique of
XVCL. The JEE/XVCL “mixed strategy” solution could
represent each of the groups of similar DAL components
in unique, generic, adaptable form. Not only did
JEE/XVCL representation collapse the physical and
conceptual size of DAL representation, but it also reduced
the effort to implement changes to DAL.
While the “mixed strategy” solution solves the problem
of component version explosion and makes reuse easier, it
is not without pitfalls. It is easier to understand a concrete
program than a meta-program. It is also difficult to
validate a meta-program as we can derive many concrete
programs from it. The current form of XVCL is an
assembly language for generic design via
parameterization. XVCL’s explicit and direct articulation
is the source of its expressive power, but it also adds a
certain amount of complexity to the problem. However,
benefits of being able to deal with issues of genericity at
the meta-level plane seem to outweigh the cost of the
added complexity. These benefits include ease of reuse
with adaptation, the overall reduction of conceptual
complexity and size of the solution, improved traceability
and changeability. We are currently collecting empirical
and analytical evidence to support the above hypothesis.
Our lab studies and two projects by our industry partner
ST Electronics confirm our expectations [9].
In the future work, we plan to extend empirical studies
on JEE and .NET platforms to further substantiate the
results reported in this paper. We plan to study the impact
of pattern-driven development on reuse in the application
domain-specific areas of component-based systems. We
believe there may be good opportunities for “mixed
strategy” to improve productivity in application of patterns
and in maintaining software developed in pattern-driven
way. Finally, we plan to work on tools helping in detecting
similarity patterns in legacy code, for possible re-
engineering into “mixed strategy” solutions [2].
[3] Basit, H.A., Rajapakse, D.C., and Jarzabek, S. “Beyond
Generics: Meta-Level Parameterization For Effective
Generic Programming,” Proc. 17
th
Int. Conf. on Software
Engineering and Knowledge Engineering, SEKE’05, Taipei,
July 2005
[4] Basit, H.A., Rajapakse, D.C., and Jarzabek, S. “Beyond
Templates: a Study of Clones in the STL and Some General
Implications,” Int. Conf. Software Engineering, ICSE’05, St.
Louis, May 2005, pp. 451-459
[5] Clements, P. and Northrop, L. Software Product Lines:
Practices and Patterns, Addison-Wesley, 2002
[6] Deelstra, S., Sinnema, M. and Bosch, J. “Experiences in
Software Product Families: Problems and Issues during
Product Derivation,” Proc. Software Product Lines
Conference, SPLC3, Boston, Aug. 2004, LNCS 3154,
Springer-Verlag, pp. 165-182
[7]
Jarzabek, S. and Li, S.
“Eliminating Redundancies with a
“Composition with Adaptation” Meta-programming
Technique,” Proc. ESEC-FSE'03, European Software
Engineering Conference and ACM SIGSOFT Symposium on
the Foundations of Software Engineering
, ACM Press,
September 2003, Helsinki, pp. 237-246; paper received
ACM Distinguished Paper award
[8] Jarzabek, S. and Zhang, H. “XML-based Method and Tool
for Handling Variant Requirements in Domain Models”,
Proc. 5
th
International Symposium on Requirements
Engineering, RE’01, August 2001, Toronto, Canada, pp.
166-173
[9] Pettersson, U., and Jarzabek, S. “An Industrial Application
of a Reuse Technique to a Web Portal Product Line,”
accepted for ESEC-FSE'05, European Software Engineering
Conference and ACM SIGSOFT Symposium on the
Foundations of Software Engineering, ACM Press,
September 2005, Lisbon, pp. 326-335
[10] Wong, T.W., Jarzabek, S., Myat Swe, S., Shen, R. and
Zhang, H.Y. “XML Implementation of Frame Processor,”
Proc. ACM Symposium on Software Reusability, SSR’01,
Toronto, Canada, May 2001, pp. 164-172
[11] Introducing Enterprise Java Beans, Justin Couch, Daniel H.
Stenberg. Java
TM
2 Enterprise Edition Bible pp. 818-830
[12] Yang, J. and Jarzabek, S. “Applying a Generative Technique
for Enhanced Reuse on JEE Platform,” 4
th
Int. Conf. on
Generative Prog. and Component Eng., GPCE'05, Sep 29 -
Oct 1, 2005, Tallinn, Estonia, pp. pp. 237-255
[13] Zhang, H. and Jarzabek, S “An XVCL-based Approach to
Software Product Line Development,” Conf. on Software
Engineering and Knowledge Engineering,SEKE’03, San
Francisco, July 2003, pp. 267-275
References
[1] Bassett, P. Framing software reuse - lessons from real world,
Yourdon Press, Prentice Hall, 1997
[14] Zhang, H. and Jarzabek, S. “A Mechanism for Handling
Variants in Software Product Lines,” special issue on
Software Variability Management of Elsevier’s journal
Science of Computer Programming, Volume 53, Issue 3,
Dec. 2004, pp. 255-436
[2] Basit, A.H. and Jarzabek, S. “Detecting Higher-level
Similarity Patterns in Programs,” ESEC-FSE'05, European
Software Engineering Conference and ACM SIGSOFT
Symposium on the Foundations of Software Engineering,
ACM Press, September 2005, Lisbon, pp. 156-165



6