Demonstrator Technical Report

horseheadssolidInternet and Web Development

Nov 10, 2013 (3 years and 11 months ago)

74 views






EFIFA
:
Effective Feedback to Improve
Fair Admissions













Demonstrator Technical

Report


i

Contents

Contents

................................
................................
................................
................................
........................
i

Table of figures

................................
................................
................................
................................
...........
iii

Document history

................................
................................
................................
................................
......

iv

Document history

................................
................................
................................
................................
......

iv

Licence and copyright
................................
................................
................................
...............................

iv

1. About the report

................................
................................
................................
................................
.......
5

1.1. Objectives

................................
................................
................................
................................
..........

5

1.2. Scope

................................
................................
................................
................................
.................

5

1.3. Audience

................................
................................
................................
................................
............

5

1.4. References

................................
................................
................................
................................
.........

5

2. Introduction

................................
................................
................................
................................
..............
5

2.1. Software architecture

................................
................................
................................
.........................

5

2.1.1. Web tier

................................
................................
................................
................................
.......

5

2.1.2. Server tier

................................
................................
................................
................................
....

5

2.1.3. Database

................................
................................
................................
................................
.....

6

2.2. Environment overview

................................
................................
................................
........................

6

2.3. Build and deployment overview

................................
................................
................................
.........

6

3. Software desig
n

................................
................................
................................
................................
.......
7

3.1. Domain model

................................
................................
................................
................................
....

7

3.1.4. Pre
-
defined text maintenance entities

................................
................................
.........................

7

3.1.5. Feedback entities

................................
................................
................................
........................

8

3.2. Application logic

................................
................................
................................
................................
.

9

3.3. Web
-
based user interface

................................
................................
................................
................

12

3.3.6. Use of view beans

................................
................................
................................
.....................

12

3.3.7. Layouts

................................
................................
................................
................................
......

12

3.3.8. Tag libraries

................................
................................
................................
...............................

13

3.3.9. Object
-
re
lational mapping and the database

................................
................................
............

13

3.4. Data access objects (DAO)

................................
................................
................................
..............

13

3.5. Package structure

................................
................................
................................
............................

14

4. Server set
-
up

................................
................................
................................
................................
.........

15

4.1. Environment va
riables

................................
................................
................................
.....................

15

4.2. Installed software

................................
................................
................................
.............................

15

4.2.10. Apache Tomcat

................................
................................
................................
........................

16

4.3. Target operating system

................................
................................
................................
...................

16

4.3.11. SunOS user permissions

................................
................................
................................
.........

16

5. Build and deployment

................................
................................
................................
..........................

16

5.1. Use of Ant

................................
................................
................................
................................
.........

16

5.2. Procedure to build

................................
................................
................................
............................

16

5.3. Procedure to deploy

................................
................................
................................
.........................

17

5.4. Issues
with the ZIP archive produced by the build script

................................
................................
.

17

5.5. DELIA/EFIFA database conflict

................................
................................
................................
........

17

5.6. Development tools

................................
................................
................................
...........................

18

5.7. Database setup

................................
................................
................................
................................

18

5.8. Test data set
-
up

................................
................................
................................
................................

18

6. Limitations of the demonstrator
................................
................................
................................
..........

18

7. Future development

................................
................................
................................
.............................

18

7.1. Web user interface

................................
................................
................................
...........................

18

7.2. Adaptation f
or other organisations

................................
................................
................................
...

18

7.2.12. Branding

................................
................................
................................
................................
..

19

7.2.13. Redevelopment

................................
................................
................................
.......................

19

7.3. Service
-
oriented architecture (SOA)

................................
................................
................................

19


ii

Appendix 1 Glossary

................................
................................
................................
................................

20

Appendix 2 References

................................
................................
................................
............................

21


iii

Table of figures

Figure 1
-

Overall architecture

................................
................................
................................
......................

6

Figure 2
-

Field maintenance entities

................................
................................
................................
...........

8

Figure 3
-

Feedback entities

................................
................................
................................
.........................

9

Figure 4
-

Base session bean

................................
................................
................................
.....................

10

Figure 5
-

Field maintenance session bean
................................
................................
................................
.

11

Figure 6
-

Feedback session bean

................................
................................
................................
.............

12

Figure 7
-

Base DAO interface

................................
................................
................................
...................

14

Figure 8
-

Field maintenance DAO interfaces

................................
................................
............................

14

Figure 9
-

Feedback DAO interfaces

................................
................................
................................
..........

14

Table 1
-

Packages and their use

................................
................................
................................
...............

15

Table 2
-

Ant build script targets and their use

................................
................................
............................

16


iv

Document history

Version

Date

Changes made to document

Author

Contact

DRAFT

20 Mar 2009

Initial document creation
.

Matthew Willard

matthew.willard@softwarecontractservices.co
m

1.0

0
5 May 2009

First relase.

Matthew Willard

matthew.willard@softwarecontractservices.co
m

Li
cence and copyright

Copyright 2008 UCAS. Licenced under the Educational Community Licence, Version 2.0 (the "Licence");
you may not use this file except in compliance with the Licence. You may obtain a copy of the Licence at:


http://www.osedu.org/licenses
/ECL
-
2.0


Unless required by applicable law or agreed to in writing, software distributed under the Licence is
distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
express or implied. See the Licence for the specific langua
ge governing permissions and limitations under
the Licence.


5

1.

About the report

1.1.

Objectives

This report aims to provide detail on several aspects of the
EFIFA
demonstrator's design and development:



Software architecture

and design
, from
the user interface thr
ough to the database.



Build, d
eployment and
server
setup instructions
.



Limitations and thoughts for future development.

After reading this document, a member of technical staff should
able
to install and set
-
up the software as
well as continue its developm
ent.

1.2.

Scope

The report covers the
EFIFA
demonstrator's software design and deployment and does not include business
analysis.

1.3.

Audience

This report should be read
by
all stakeholders in the
EFIFA
project who have a responsibility for deploying,
developing or

maintaining the demonstrator.

It is assumed that readers will have

an understanding of:



H
ow web
-
based software applications are built using

Java and third
-
party toolkits.



UNIX operating systems and
their command
-
line interfaces.

1.4.

References

The report "
EFI
FA
-

Functional Requirements V0.2.doc
" should be read with this document.

The documentation that accompanies third
-
party toolkits should also be read if necessary.

2.

Introduction

EFIFA is built on a
tiered
architecture model with each
tier
dependent only on
the
one
immediately
below.
Each
tier
is encapsulated and decoupled such that its responsibilities are clearly defined and easily
understood.

2.1.

Software architecture

Implementation of the software's functionality is partitioned into three tiers.

2.1.1.

Web tier

Con
tains

components that comprise the web
-
based user interface. JSPs display data and accept data
through forms which
are
bound to attributes on action or view beans and then transferred across to the
server
-
tier.

2.1.2.

Server tier

The server
-
tier contains all the

business, application and persistence logic that encapsulates the software's
functionality. Application logic beans accept requests from web
-
tier action beans and co
-
ordinate the
creation, storage and retrieval of business entities.

Data access objects r
e
ad,
query
and store data to
the database.


6

2.1.3.

Database

A relational database stores all persistent data. An object/relational tool controls the conversion of Java
objects to relational database records and back again.

Database
Server tier
Data Access
Objects
Application logic
beans
Entity model
Web tier
Action
beans
JSPs
View beans

Figure
1

-

Overall architecture

2.2.

Environment overview

The software is cross
-
platform and has few dependencies. The libraries included with the software contain
most of the dependencies while
the target server must have installed
a compatible

s
ervlet
container and
relational database
. Operating system
environment variable
s must
set as required for third
-
party toolkits

and for the software itself.

2.3.

Build and deployment

overview

Build scripts are used to create a distributable software package t
hat can be installed on any correct set
-
up
server. The same build script is used to deploy the software on that server and begin execution.


7

3.

Software design

3.1.

Domain model

The purpose of the domain model is to replicate at a high level of abstraction the maj
or building blocks of
the business that have clear identity, state and behaviour. Business rules are contained with the domain
model.

The demonstrator's domain model is very simple but can grow to accommodate more business entities and
more complicated lo
gic.

All entities that are to be stored in the database are derived from an
EntityBase

class
that define
s

a unique
ID

plus

equality and hashing methods.

3.1.4.

Pre
-
defined text
maintenance entities

Four entities are concerned with the maintenance of pre
-
defined
text

(fields):
Institution
,
Faculty
,
Course

and
Field
.

An
Institution

has many
Faculty
s and each
Faculty

has many
Course
s.

All three
contain many
F
ield
s. All entities are persisted to the database and thus derive from
EntityBase
.


8


Figure
2

-

Field maintenance entities

3.1.5.

Feedback entities

The entities used in the feedback subsystem build
s

on the field maintenance entities.


9


Figure
3

-

Feedback entities

An
Applicant
, derived from
Person
,
makes one or many
Ap
plication
s

for one or many
Choice
s
. Each
Choice

is
targeted

to a

specific
Course

(which in turn is attached to a specific
Faculty

and thus to an
Institution
).

A member of staff will make a
Decision

on the
Choice

and record
Feedback

against it.
They may
also record
SelectionNotes

that
will describe

the factors taken into account when making the
Decision
.

3.2.

Application logic

General infrastructure and co
-
ordination logic is found
application beans that reside
i
n the application logic
layer.


10

The interface to
the application beans is coarse
-
grained and is based on the demands of the user interface
or other client
-
type. An application logic bean's interface is designed to conceal implementation details from
a

client in order to achieve encapsulation and decoupl
ing.

Application bean responsibilities include:



I
nvoking database access

through data access objects
.



Building a single view bean from one or more entity beans for use by the user interface.



Updating entity beans from data collected by the user interface.

The logic is separated into chunks with distinct and related responsibilities. Those chunks usually map onto
major subsystems of the application and are

implemented as plain JavaBeans.
In EFIFA there are two
application logic bean

interfaces (
FieldMainte
nanceSession

and
FeedbackSession
) and their
implementations (
FieldMaintenanceSession
Impl

and
FeedbackSession
Impl
).

A base class implements common functions.


Figure
4

-

Base session bean

FieldMaintenanceSession

is concerned with t
he addition and maintenance of pre
-
defined fields and their
text that is associated with institutions,
facilities

and courses.


11


Figure
5

-

Field maintenance session bean

FeedbackSession

allows the recording of decisions, feedback
and selection notes against applications.
Both gather appropriate required data from the database for use in the user interface.


12


Figure
6

-

Feedback session bean

3.3.

Web
-
based
user interface

The user interface has been written to be

as simple and straightforward as possible. The Stripes framework
was chosen to support the user interface
by providing services and an execution environment. The
cornerstone of Stripes is simplicity and pace of development.

3.3.6.

Use of view beans

E
xpos
ing

en
tity beans to the user interface for
the purposes of
display
and update
is considered to be
bad
practice
and so an alternative method is required.

The application logic beans build
view beans

from data obtained from the database by the data access
objects.

The same view beans are used to capture data entered into the user interface
's forms

for
persistence to the database. The view beans are plain JavaBeans with private
attributes
, accessors and
mutators.

They
are disposable, not
persisted and

contain no
behaviour o
r

business logic.

3.3.7.

Layouts

Stripes supports highly flexible page layouts
that

allow a JSP page to be split into fragments that can be
reused across many pages with only the central content fragment changing.

EFIFA use
s

a central layout page that
is
roughly
based on the UCAS web site pages and
which has
demarcated area
s

for content. The JSPs that were written for the project fit into that
content
area.

More sophisticated use of Stripes's layout model could have reduced the number of effectively re
dundant
JSPs by increasing reuse. The additional learning curve was judged to be less expensive than
creating the
small number of very similar pages.

Future development work
to

prepare the demonstrator for production use should focus on implementing
more
efficient page fragment reuse.


13

3.3.8.

Tag libraries

Stripes tag libraries are used on almost all pages and for the purposes of generating forms and handling
reusable layouts. JSTL tags are used rarely and only when a Stripes tag
is unavailable.

The code librarie
s for the tags are included in the application and do not need to be installed separately.

3.3.9.

Object
-
relational mapping and the database

All data in the software revolves around the domain model and entities in the model that
are to

be persisted
into the
data
base

are annotated to that effect.
Those annotations conform to the Java Persistence API
specification and are thus portable across
different
JPA vendors.

The JPA persistence engine chosen for EFIFA is
Hibernate
, an established and sophisticated tool for
storing
and retrieving java objects from a relational database.

To ease integration between the Tomcat servlet
container, Stripes and Hibernate, the third
-
party toolkit
Stripersist

is used.

A definition in the web application's
web.xml

file causes Striper
sist to be initialised when Tomcat begins
execution. Stripersist in turn invokes Hibernate with the
persistence.xml

file to determine its runtime
parameters.

3.3.9.1

Database creation

There are no SQL scripts to create the EFIFA database. Instead, a parameter i
n the
persistence.xml

file
tells Hibernate to automatically generate the database accordi
ng to entity bean annotations.

Tables are
created for each entity and a
nnotations that describe the
associations
between entities are
used to create
relationships bet
ween table
s.

3.3.9.2

Primary keys

All primary keys are generated and managed by Hibernate.

3.4.

Data access objects

(DAO)

Storage and retrieval of entities to the database is delegated by the application logic beans to the data
access objects. These classes
conceal th
e specifics of how entities are stored and retrieved.

A base DAO

interface
defines
the following functionality:



Retrieve all the entities of a particular type.



Retrieve a specific entity by
unique ID.



Persist a new entity.



Update an existing entity.



Delete

an entity using the entity or a unique ID.



Commit outstanding transactions.



Find any entity
by any of its attributes.

A

generic abstract

base DAO implements
that interface's functionality.



14

Figure
7

-

Base DAO interface

For every

persisted entity, there
is a sub
-
interface derived from the base DAO interface and a concrete class
derived from the generic abstract base DAO.

Each derived interface and class replaces the generic type
parameters in the base interface and class with the

type of the entity being persisted.


Figure
8

-

Field maintenance DAO interfaces

Most entity
-
specific DAOs do not require further functionality beyond t
hat implemented in the base DAO

but
there are some exceptions. For
example
,
ChoiceDAO

implements an additional
getChoices(Integer)

method that retrieves all of the
choices for a particular institution.


Figure
9

-

Feedback DAO interfaces

Additional functionality in DAOs is mostly implemented using SQL ins
tead of HQL.

The SQL makes the
DAOs brittle and tightly coupled to the database structure. An association change between two entities
could cause some DAO methods to break.

Future refactoring would focus on replacing the SQL with
JPA's own query language

or even object
traversal.

3.5.

Package structure

The application is split across several packages. The root package for all code is
uk.ac.ucas.
efifa
. Sub
-
packages and their use are:

Package

Use

uk.ac.ucas.efifa.dao

Base DAO i
nterface
.

uk.ac.ucas.efifa.dao.
feedback

Interfaces

for
Applicant
,
Application

and
Choice

DAOs.

uk.ac.ucas.efifa.dao.fieldmaintenance

Interfaces for
Institution
,
Faculty
,
Course


15

and Field DAOs.

uk.ac.ucas.efifa.dao.stripersist

Stripersist
-
based abstract implementation of
the
BaseDAO

i
nterface.

uk.ac.ucas.efifa.dao.stripersist.feedback

Concrete DAO classe
s

for
Applicant
,
Application

and
Choice
.

uk.ac.ucas.efifa.dao.stripersist.fieldmaintenance

Concrete DAO classes for
Institution
,
Faculty
,
Course

and
Field
.

uk.ac.ucas.efifa.entities

All entity classes.

uk.ac.ucas.efifa.session

Base and concrete classes for the beans that
contain application logic and provide a
coarse
-
grained interface to the web tier.

uk.ac.ucas.efifa.web.actions

Base Stripes Action class.

uk.ac.ucas.efifa.web.acti
ons.feedback

Stripes Action classes for the feedback
system.

uk.ac.ucas.efifa.web.actions.fieldmaintenance

Stripes Action classes for the field
maintenance system.

uk.ac.ucas.efifa.web.viewbeans.feedback

Simple Java beans used to transfer data
between we
b and server tiers.

uk.ac.ucas.efifa.admin.database

Stripes Action classes that handle initial
population of the database with text data.

Table
1

-

Packages and their use

4.

Server set
-
up

4.1.

Environment variables

The required environmen
t variables divide up into two groups: those for toolkits and those for EFIFA.

Toolkit
environment variables should be set
-
up according to the instructions for those toolkits but a summary is
below:

Name

Purpose

Default

CATALINA_HOME

Root directory for T
omcat's installation.

/usr/tomcat/

ANT_HOME

Root directory for Ant's installation.

/usr/ant/

JAVA_HOME

Root directory for the JDK's installation.



The EFIFA software itself requires just one variable.

Name

Purpose

Default

EFIFA_HOME

Root directory for

EFIFA's

installation.

The variable is used
by the Ant build script and when loading test data into the
database.

/usr/research/efifa/

4.2.

Installed software

EFIFA depends on the Ant build tool (at least v
ersion
1.7.1), Java Development Kit (at least v
ersion

1.5.0)
and Apache Tomcat (at least v
e
r
sion
6.0).


16

4.2.10.

Apache Tomcat

Due to
UCAS's current
firewall
policy
, Tomcat must be set to work on port 80 instead of the default of 8080.
The change is made within the
server.xml

configuration file. Refer to Tomcat's do
cumentation for more
detail.

Tomcat makes use of several ports, including the "shutdown" port of 8005. Deployment onto a new server
revealed a port conflict

and

t
he shutdown port was changed to 8006 in the
server.xml

configuration file.

No other changes w
ere made to
server.xml
.

4.3.

Target operating system

EFIFA will work on any operating system for which a Java Development Kit is available. It has been tested
on Windows XP Pro and SunOS 5.

4.3.11.

SunOS user permissions

The software should be installed and run from a
n account that is a member of the
webservd

group. The
current deployment executes under a username of
tomcat
. All directories associated with EFIFA must be
owned by that user.

The
webservd

group does not include
the permissions to open privileged ports

(
those between 0 and 1024
)
.
That
privilege

must be added executing the following command as
root
:

usermod
-
K defaultpriv=basic,net_privaddr tomcat

5.

Build and deployment

Scripts have been used to ease building and deploying the software.

5.1.

Use of Ant

The tool

chosen for automating the build and deployment is Ant.


Target

Purpose

build

Builds everything

deploy

Copies web application archives to the
Tomcat directory

dist

Builds everything ready for deployment to
Tomcat

start
-
all

Starts HSQLDB and Tomcat

st
art
-
hsqldb

Starts the HSQLDB server

start
-
tomcat

Starts the Tomcat servlet container

stop
-
all

Stops HSQLDB and Tomcat

stop
-
hsqldb

Stops the HSQLDB server

stop
-
tomcat

Stops the Tomcat servlet container

backup
-
database

Backs
-
up the EFIFA database

T
able
2

-

Ant build script targets and their use

5.2.

Procedure to build

The project can be built only from the main development directory because that is where all the
required
sources
are kept.

1.

Open a command
-
line window at the location

of the development directory.

2.

Type
ant dist

to

invoke Ant with the target that builds a distributable archive.


17

3.

Look in the newly created
dist

directory for the
efifa.tar.gz

archive.

5.3.

Procedure to deploy

These instructions assume that
no EFIFA deployment cu
rrently exists.

1.

Copy that
efifa.tar.gz

distribution archive

from the
dist

directory to the
research

directory (the
default is
/usr/research/
).

2.

Start a Telnet session on the server and
go to the main

research
directory.

3.

Unzip/untar the distribution archive
such that a new directory is created called
efifa
.

4.

Change into the new
efifa

directory

and execute the command
ant deploy
.

That will expand the
archive into its correct locations (including Tomcat's web application directory).

5.

Execute the command
ant star
t
-
all

to start the HSQLDB database server and Tomcat servlet
container.

6.

Test the availability of the application by
opening the main EFIFA page in a web browser. The
default location for production is
research.ucas.
com
/efifa/
.

For deployments that current
ly

exist and which are running,

follow these instructions
first
.

1.

Start a Telnet session on the server and

go to the main EFIFA directory (the default is
/usr/research/
efifa/
).

2.

Execute ant
stop
-
all

to stop both HSQLDB and Tomcat.

3.

Execute
ant backup
-
database

if a database backup is required before replacing this deployment
with the new deployment.

4.

Change down one directory level (the default

would be
/usr/research/
)

and remove the
efifa

directory (for example, on a UNIX system use
rm
-
R efifa
).

5.

Follow the in
structions as for a server without an EFIFA deployment, beginning at step 3
.

5.4.

Issues with the ZIP archive produced by the build script

Under some conditions, the TAR/ZIP archive produced by the build script on the development computer is
incompatible with t
he utilities to unzip the archive on the server. If that occurs then on the development
computer, extract and rebuild the archive using a different tool (for example, use WinRAR or WinZIP).

5.5.

DELIA/EFIFA database conflict

DELIA and EFIFA have broadly simila
r architectures and both use the HSQLDB relational database server
and the Tomcat servlet container. They
share one runtime instance of Tomcat but require separate
database server instances.

The first deployments of
EFIFA
caused a conflict between the two

running database servers, despite them
being
configured on different ports. The conflict cause
d

Tomcat to report many thread deadlock and
database connection errors
when Stripersist invokes Hibernate with a database connection.

On occasion,
the HSQLDB s
erver instances term
inate abnormally and abruptly, leaving the application unusable.

A cause for the conflict was never established and continues to occur under the following conditions:



DELIA's HSQLDB instance has been kept running during an EFIFA deploym
ent.



The Ant target
start
-
all

is used to start HSQLDB and Tomcat

after an EFIFA deployment.

A solution appears to be to stop DELIA's HSQLDB instance (using
ant stop
-
hsqldb

after Tomcat's been
stopped)

such that no HSQLDB or Tomcat instances are running

and

t
hen
:



S
tart DELIA's HSQLDB instance by executing
ant start
-
hsqldb

from the DELIA main directory
(the default is
/usr/research/
delia/
)
.



Monitor the active HSQLDB process
for

successful start
-
up (on a UNIX system, use
ps
-
ef

from
the command
-
line).



Change
to the EFIFA main directory and start that HSQLDB instance using the same target as for
DELIA.


18



There should now be two HSQLDB processes. Monitor those for at least a minute for abrupt and
abnormal termination.



Start Tomcat from either DELIA or EFIFA's mai
n directory using
ant start
-
tomcat
.



Again, monitor the two HSQLDB instances.



If the instances appear to be stable then
open EFIFA's main page in a web browser and
perform
one of the functions that uses database access (
for example, field maintenance).

If
that is
successful then the application is stable.

5.6.

Development tools

EFIFA has been developed using the Eclipse Java development environment with the set
o
f MyEclispe
extensions.

Since EFIFA has no dependencies on either Eclipse or MyEclipse
,
any Java dev
elopment tool
can be used for further work.


5.7.

Database setup

All the required
libraries for HSQLDB are containe
d within the EFIFA distribution

and the Ant build script is
all that's required to execute HSQLDB (using ant
start
-
hsqldb

from the command
-
line).

Hibernate will create the database schema i
f

it does not exist.

The configuration file to control that is
persistence.xml
.

5.8.

Test data

set
-
up

Test data is contained within a Microsoft Excel spreadsheet
and transferred to the database by a Stripes
action bea
n. A JSP page allows the action bean to be invoked.

The test data spreasheet must be in the
root directory indicated by the

EFIFA_HOME

environment variable (by default, that is
/usr/research/efifa/
)
.


The URL for the admin

screen to populate the databas
e is
research.ucas.com/efifa/jsp/admin/PopulateDatabase.jsp
.

Blank databases should be populated first with "
Fields, institutions, faculties and courses
" and then with
"Applications".

Populating the database is a good method for testing that HSQLDB has sta
rted
-
up successfully.

6.

Limitations of the demonstrator

The demonstrator has not been dev
eloped as production software.

Features that would normally be part of
production software were cut, including auditing, security or logging. Any future development of

the
demonstrator should certainly add logging. Development into a production system would have to implement
security and auditing.

7.

Future development

7.1.

Web user interface

Currently, page reuse is limited to the main layout that surrounds page content.

Som
e screens that are very
similar exist as separate pages instead of one single page. For example,
the screen that contains the form
for leaving feedback is almost identical to the confirmation page displayed after feedback has been left.

That redundancy c
ould be removed with better use of Stripes's reusable layout features.

7.2.

Adaptation for other organisations

EFIFA currently targets HEIs but could address the needs of other organisations. Adaptation could take
place on two levels: branding and redevelopmen
t.


19

7.2.12.

Branding

If a different page design was applied to the EFIFA screens and form labels changed, then the application
could easily be used by an organisation with
a similar three
-
level structure to that of an HEI.

Instead of an
institution,
its
faculties
and courses, the target organisation
could

consist of a top
-
level company,

departments and teams.

With those similarities, adapting EFIFA for that organisation would be straightforward.

7.2.13.

Redevelopment

Some organisations do not fit into a three
-
level model.

In that case, additional or even fewer levels may be
required. To support that, additional development would be required.

The recommendation is to implement a configuration feature that would allow
for
custom
organisation

levels
to be created and linked
together. For example, a large organisation may require four levels: company top
-
level, national office level, regional office level and department level.

The software would provide a maintenance feature for the creation of those levels and the assignment

of
pre
-
defined field text against them.
Such a feature would allow the software to be
used with any
organisation model.

7.3.

Service
-
oriented architecture

(SOA)

EFIFA's software design

is based on components whose function is well defined and organised into
d
ecoupled tiers. The design supports integration into
any business system, including one based on SOA.

The main features of the software are defined on the two session beans:
FeedbackSession

and
FieldMaintenanceSession
.

Clients invoke those
functions, pro
viding
any required data (for example, the
ID of an entity)

and accepting a bundle of data as the result.

The web
-
tier is one example of a client.

Other types of client could also invoke the software
's

functionality

and use the results
with
one
o
f those
c
lients
being
a SOA framework
.


20

Appendix 1

Glossary

Definitions taken from Wikipedia.

Ant

Apache Ant is a software tool for automating software build processes
. It is
implemented using the Java
langua
ge, requires the Java platform
and is best suited to building Java
projects.

Apache Tomcat

Apache Tomcat is a servlet container developed by
the Apache Software Foundation.
Tomcat implements
the Java Servlet and the JavaServer Pages (JSP) specif
ications from Sun Microsystems
and provides a
"pure Java" HTTP web server env
ironment for Java code to run.

HSQLDB

HSQLDB (Hyperthreaded Structured Query Language Database) is a relational database man
agement
system written in Java.

Stripes

Stripes is an open source web application framework based on the model
-
view
-
controller patte
rn.

It aims to
be a more lightweight framework than Struts by using Java technologies such as annotations and generics
that were introduced in Java 1.5, to achieve "convention over configuration".

This emphasizes the idea that
a set of simple conventions

used throughout the framework reduce configuration overhead.

Model

View

Controller (MVC)

MVC
is an architectural pattern used in software engineering.

Successful use of the pattern isolates
business logic from user interface considerations, resulting in
an application where it is easier to modify
either the visual appearance of the application or the underlying business rules without affecting the other.

In MVC, the model represents the information (the data) of the application; the view corresponds to
e
lements of the user interface such as text, checkbox items, and so forth; and the controller manages the
communication of data and the business rules used to manipulate the data to and from the model.

Eclipse/MyEclipse

Eclipse is a multi
-
language software
development platform comprising an IDE and a plug
-
in system to
extend it. It is written primarily in Java and is used to develop applications in this language and, by means of
the various plug
-
ins, in other languages as well

C/C++, Cobol, Python, Perl, PHP

and more.

MyEclipse is a commercially available Java EE and AJAX IDE created and maintained by the company
Genuitec, a founding member of the Eclipse Foundation. MyEclipse is built upon the Eclipse platform, and
integrates both proprietary and open sourc
e solutions into the development environment.

Domain model

A domain model, or Domain Object Model (DOM) in problem solving and software engineering can be
thought of as a conceptual model of a system which describes the various entities involved in that sy
stem
and their relationships.

The domain model is created in order to document the key concepts, and the
domain
-
vocabulary of the system being mode
l
led. The model identifies the relationships among all major
entities within the system, and usually identif
ies their important methods and attributes.

Data access object (
DAO
)

A
n object that provides an abstract interface to some type of database or persistence mechanism, providing
some specific operations without exposing details of the database.

This isolati
on separates the concerns of
what data accesses the application needs, in terms of domain
-
specific objects and data types (the public
interface of the DAO) and how these needs can be satisfied with a specific DBMS, database schema etc.
(the implementation
of the DAO).


21

Java Persistence API

(
JPA
)

A
Java programming language framework that allows developers to manage relational data in Java
Platform, Standard Edition and Java Platform, Enterprise Edition applications.

Object
-
relational mapping

(
ORM
)

Object
-
rel
ational mapping
:

a programming technique for converting data between incompatible type systems
in relational databases and object
-
oriented programming languages.

This creates, in eff
ect, a "virtual object
database
" which can be used from within the progra
mming language.

Unified
Modelling

Language

(
UML
)

A

standardized general
-
purpose
modelling

language in the field of software engineering.


UML includes a set
of graphical notation techniques to create abstract models of specific systems.

Appendix 2

References

Ant buil
d tool:
ant.apache.org

HSQLDB database:
hsqldb.org

Java Persistence API (JPA):
java.sun.com/javaee/overview/faq/persistence.jsp

Java SE Development Kit (JDK) 1.6:
java.sun.com/javase/6/

Tomcat servlet container:
tomcat.apache.org

UML:
www.uml.org