Integrated Action Learning Project Final Report Development of J2EE-based Content Management System for Tenacor Jason M. Batchelor TS4990 Integrated Action Learning Project

tendencyrheumaticInternet and Web Development

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

204 views


Integrated Action Learning Project Final Report


Development of J2EE
-
based Content Management System for Tenacor


Jason M. Batchelor


TS4990 Integrated Action Learning Project


Instructor, Dr. Sharon Bender


Fall, 2005



Project Description


My project ha
s been to develop a J2EE version of a content management system
originally created in ASP. This was not to be a conventional “port” however, as the
system can now be executed in a truly object
-
oriented fashion, whereas the original
ASP version was designed

early in my programming skills development. Tenacor
would like to package this system as a potential candidate for use by its clients, or as
a “proof of concept” that Tenacor has the necessary assets to manage and produce
J2EE products.

Glenn Piot, Sr. a
s owner of Tenacor, was my project stakeholder.

The CMS, when fully completed, will be used to store and share documents and
simple customization will allow a tailored look and feel for each “hosted” sub
-
site.
The interface is designed to be standards
-
bas
ed to allow for the greatest possible
audience on modern browsers.

The project began in Unit 6 and concludes in Unit 10 of the TS4990 course.
Continuing effort will be necessary to complete a working prototype of the
application after the end of this cours
e.


Feasibility


In performing a feasibility check I examined the following areas:

1.

Proposed change: Create a J2EE port of an existing ASP homepage/Content
Management System.

2.

Level of Need: While there are several CMS available on the web, many of
them sac
rifice usability for “neat features”. This system has proven itself to
be quite usable in its ASP incarnation, and it will carry the lessons learned
from that system over to the new system.

3.

Requirements: Time from me for development of the application, an

application server on which to build the application (LAMP solution), and a
decision on what application platform to use for the coding.

4.

Technical: Barring any usual additions or requirements, most of the
technology is easily available “off the shelf”, in
cluding MySQL, Tomcat and
Apache.

5.

Economic Issues: None, except for a final deployment server once it is ready
to be packaged to sell to a customer other than Tenacor.

6.

Constraints: Time to code the solution, time to develop any extra collateral
images and
interface elements, has required extra time outside of work to
execute.



Prototype


The following prototype depicts the look and feel of the original system, and what
this project should eventually replicate.


The “homepage” (Fig. 1) of a site contains a
space which allows the users to post
announcements, display an image, and also contains “sidebars” on the left (in this
implementation) which give the user access to the site’s folders and quick
-
access
links.


Fig. 1


The “sitefiles” (Fig. 2) page of a s
ite displays the same sidebars as the homepage,
and a list of files and folders available in the current location.


Fig. 2


The Site Manager (Fig. 3) interface, modeled closely after the Windows Explorer
interface, allows those with administrative access
to upload files and links, create
folders to organize information, move, copy, delete and rename files and links, edit
links, and set security for folders and the items they contain. The left panel also
gives a description of the current folder, as well as

who may manage and edit items
in this location.


Fig. 3


The “Upload” screen (Fig. 4) is simply an example of the general look and feel of the
action
-
screens, which are activated by the upload, move, copy, etc. actions.


Fig. 4



Objectives

In produci
ng my project my major objectives were to:


1.

Create user login and access systems with role
-
based security.

2.

Port a standard interface that is easy for the general users, and is simple to
administer to J2EE/JSP.

3.

Use standards
-
based design to create a fast, f
lexible and usable system.

4.

Provide a well
-
architected and documented solution.

5.

Provide useful documentation for the end user that supplements an easy
-
to
-
use interface.


In producing my project my learning objectives were to:


1.

Apply my training in object
-
or
iented design to develop a system that can be
easily extended for future advancements and features.

2.

Produce a working application that can be used to showcase skill proficiencies
in HTML, DHTML, J2EE, and scripting.

3.

Develop an understanding of what it take
s to produce the capstone project.

4.

Enhance my understanding of the needs of stakeholders, testers, and users.

5.

Apply learning from courses taken at Capella.

Project Schedule

In producing my IAL Project I will applied the following project schedule:

Tasks

D
uration

Design Core Phase I

11/7/05


11/20/05

Task 1: Finalize Requirements

Task 2: Develop Object Model

Task 3: Design Security Model

Task 4: Design Doc Storage Model

Task 5: Design Site Preferences Model

Assisting Resources:


Literature

Bender, S. L.

(2003). Producing the Capstone Project.

Basham, Sierra, Bates (2004). Head First Servlets & JSP

O’Reilly (2004). Java in a Nutshell

cree浡nⰠbKⰠcree浡nⰠb⸬⁓ erraⰠ䉡Be猠E㈰〴F⸠ee慤⁆ r獴⁄e獩gn⁐慴terns


fnternet

睷w⹧Kogle⹣om

睷wKonj慶愮aom


健ople

偩otⰠd⸬⁓ ⸠


却慫eholder


bquip浥湴

i䉯o欠d4Ⱐ䵡挠l匠堠㄰K㐬⁁4慣aeⰠqo浣慴‵Ⱐp慦慲iⰠ乥t獣慰e‷ ⁏per愬acirefo砬 䵹jni


Port UI


Document Management Phase

11/21/05


11/27/05

Task 1: Convert UI


“SiteManager



䱩獴⁖se眬wfnfo⁖ ew

呡q欠㈺⁃ nvert⁕f


偲i浡r礠Co浭慮d 獣reens
䍲e慴eI⁎e眠wolderⰠjoveⰠCop礬
oen慭eI⁄eleteF

呡q欠㌺⁃ nvert⁕f


卩te⁓ pport⁓ reen猠Epecurit礬⁓ 慲捨c

䅳Ai獴sng⁒ 獯urce猺


䱩ter慴ure

䉥nderⰠp⸠i⸠E㈰〳F⸠mrodu捩ng⁴ e⁃慰獴s
ne⁐roje捴⸠

䉡獨慭Ⱐ卩err愬aB慴es
㈰〴F⸠ee慤⁆ r獴⁓sr癬et猠C⁊卐

O’Reilly (2004). Java in a Nutshell

cree浡nⰠbKⰠcree浡nⰠb⸬⁓ erraⰠ䉡Be猠E㈰〴F⸠ee慤⁆ r獴⁄e獩gn⁐慴terns


fnternet

睷w⹧Kogle⹣om

睷wKonj慶愮a



健ople

偩otⰠd⸬⁓ ⸠


却慫eholder


bquip浥湴

i䉯o欠d4Ⱐ䵡挠l匠堠㄰K㐬⁁4慣aeⰠqo浣慴‵Ⱐp慦慲iⰠ乥t獣慰e‷ ⁏per愬acirefo砬
偨oto獨op‷ ⁍ pni


Port UI


Homepage Management Phase

11/28/05


12/4/05

Task 1: Create Homepage View, List View

Task 1a: C
reate Homepage Layout

Task 1b: Create Tree View

Task 1c: Create News View

Task 2: Create Files List View

Task 3: Create Site Management UI

Assisting Resources:


Literature

Bender, S. L. (2003). Producing the Capstone Project.

Basham, Sierra, Bates (2004)
. Head First Servlets & JSP

O’Reilly (2004). Java in a Nutshell

Freeman, E., Freeman, E., Sierra, Bates (2004). Head First Design Patterns

Shea, D., Holzschlag, M. (2005). Zen of CSS Design: Visual Enlightenment for the Web

Tate, B. and Gehtland, J. (2005)
. Spring: A Developer’s Notebook

Walls, C. and Breidenbach, R. (2005). Spring in Action


Internet

www.google.com

www.onjava.com

www
.springframework.org

http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse


People

Piot, G., Sr.


Stakeholder

Raible, Matt
-

Mentor


Equipment

iBook G4, Mac OS X 10.4, Apache, Tomcat 5, Safari, Netscape 7, Opera, Firefox,
Photoshop 7, MySQL


Quality Assur
ance / Pilot Phase

12/5/05


12/11/05

Task 1: Deploy to a public location.

Task 2: Allow Stakeholder and misc. testers to access the application.

Task 3: Compile a results report with any remaining usability or bug issues that would
need to be addressed b
efore the application were to be deployed to a production server.

Assisting Resources:


Literature

Bender, S. L. (2003). Producing the Capstone Project.

Shea, D., Holzschlag, M. (2005). Zen of CSS Design: Visual Enlightenment for the Web

Zeldman, J. (200
3). Designing With Web Standards


Internet

www.google.com

www.onjava.com


People

Piot, G., Sr.


Stakeholder


Equipment

iBook G4, Mac OS X 10.4, Apache, Tomcat 5, Safari, Netscape 7, Opera, Firefox,
Photoshop 7, FreeB
SD server, MySQL



Risk Management

I have performed a risk management analysis as follows:

Risk Factor Checklist

Risk Considerations


Low

Risk

Medium
Risk

High

Risk

Unfamiliarity with J2EE/JSP



X

Inability to port key functionality to J2EE



X

Ina
bility to acquire server space to run JSP app


X


Sickness or family emergency


X


Data disaster (computer or power outage)



X









High Risk Analysis

Risk Considerations

Risk Significance and Potential Solution

Unfamiliarity with J2EE/JSP

Signi
ficance: This is what the app is intended to
be written in. Having less familiarity with the
target platform increased the risk that it would
take longer to implement working solutions.

Solution: Continuing to study J2EE/Servlet/JSP
technology through sev
eral books and online
sources.

Inability to port key functionality
to J2EE

Significance: Items such as upload and download
handling and file system manipulation were
difficult to design and implement, and created
problems with executing the application as

planned.

Solution(s): Narrowed focus to utilizing tools
such as the Spring framework and AppFuse to
offset the learning curve and to take advantage
of built
-
in functionality they provide.

Data disaster (computer or
power outage)

Significance: If work in
progress was lost due to
computer or power outage, then there would
have been an obvious effect on the ability to
produce the final product.

Solutions: Regular backups of all project
materials to local disk storage and online storage
to preserve the latest

source files in case of
emergency. Power backup unit to protect
computers in case of power outage.




Contingency Plan


After completing a risk analysis it has been determined that the high
-
level risks to
the successful completion of my project were:


1.

U
nfamiliarity with J2EE/JSP

2.

Inability to port key functionality to J2EE

3.

Data disaster (computer or power outage)


Efforts to offset these risks were in place. However, my project did not develop
successfully at a rate that allowed completion of the prototyp
e by course
-
end. As
suspected, the learning curve to reproducing a known design in a new platform was
sufficient to make it impossible to determine the correct starting point for
development of a working solution in the time given. The issue was not so muc
h the
lack of reference information, but the sheer volume of the available information. No
fewer than a dozen differing frameworks exist on which one could develop a J2EE
project, but a clear “winner” does not immediately make itself apparent when one is
f
irst studying the available technologies.


Redirection will be to permit the Data Model Design

phases of my project to
constitute my project in its entirety, combined with screen shots of the prototype
from which the application is being ported. The outst
anding phase(s) [e.g.,
implementation] of my project will be completed outside the scope of the capstone
project. With approval, such redirection represents my project in its entirety.

Literature Review


I performed the following literature review concerni
ng the value in producing my
project:


Books/Publications


1.
Suh, P., Addey, D., Thiemecke, D.,

Ellis, J. (Glasshaus, 2003)
Content
Management Systems



Your site may have relatively simple needs, and not require complex CMS
functionality such as workflow

or version control. Alternatively, your needs may be
very specific, and not well matched by any commercially available CMS. In either of
these situations it may be inappropriate to buy an expensive, multi
-
featured CMS,
especially if you have web applicati
on developers within your company. If this
describes your situation, building a system that exactly matches your requirements
may be a better investment.” (Addey, 2003)


Given that there are many available sources for content and document management
system
s, both commercial and open source, one of the questions one must ask is,
“Why another C/DMS?” Simply put, when this project is completed, it should provide
a balance of ease of use and functionality that does not appear to be available on the
market at th
is time. The commercial systems are mostly tailored to large
enterprises, and their ease of use depends on the acuity of the front
-
end developers
who must adapt the system to use within the enterprise environment at hand. The
open
-
source systems, sadly, se
em to focus much more on “how many cool features
can we stuff into this?” than on “how can we make basic content and document
management simpler?” The system that my project is using as its “model” was built
with an eye toward making things fit into the av
erage user’s workflow. To this end,
the interface strives to emulate the Windows environment as much as possible; in
order to reduce the amount of new functionality the user must learn to perform their
usual tasks.


This seems to be the strongest argument
for building one’s own CMS, as described in
Chapter 6 of Content Management Systems. If the available systems do not match
your needs, it is often more cost effective to design your own. In a sense, I have the
advantage of having developed this system in a
nother language, and having seen
how it’s worn with age.


2. Ariadne,
What are...Document Management Systems?
Retrieved Oct. 29,
2005, from
http://www.ariadne.ac.uk/issue17/what
-
is/


"
Organisations

which manage large web sites are now aware of the difficulties of
managing a web site using simple HTML authoring tools. … The use of
document
management systems

can help to address some of the problems.” (Kelly, B., 1998)


This article mainly points out
the fact that simple HTML
-
writing tools are not up to
the task of managing and tracking large documentation efforts within an
organization. It focuses on the fact that an automatic solution offers the benefits of
managing the mundane tasks of describing th
e content (through metadata tags),
freeing users to concentrate more on the use of those documents than on the
sharing and disseminating thereof.


While this article is old, it points to one of the driving forces behind designing the
original system which
my project is based upon; ease of maintenance. The original
system was designed because our customers had a large number of documents that
they wanted to keep updated, and wanted to have us maintain the links to, on a
continuing basis. The idea of our syst
em was to give them a tool by which the
customer could manage their own documents and keep them in an interface
paradigm that `was familiar to them.


3. Yedit,
Business Document Management

Retrieved Oct. 29, 2005, from
http://www.yedit.com/web
-
content
-
management
-
system/business
-
document
-
management.html



What if you could manage and keep track of all the changes to a document (any
kind of document, not just

word processor files), without mandating that everyone
use the same software (especially important if you collaborate with other businesses
or even just people out side your business).


“You would be able collaborate with anyone, at anytime with all chang
es and
versions kept up to date automatically. Furthermore, all changes could be traced
back to whom made them, to which document and when. All old versions of
documents would be available for you to check the information that is present in
later versions.



The ultimate goal in developing a document management system lay in its ability to
allow collaboration, especially in cases where your team of users does not work from
the same office, or perhaps even within the boundaries of the same state or country.
This article describes the major reasons for using document management systems,
and why they are on the web, instead of using some client
-
server setup. The web is
used for its ubiquity within modern businesses. It states that the norm for document
sharing
has traditionally been shared drives or email, but that requires that the users
all know the same software, and can somehow avoid versioning issues (two people
working simultaneously on the same document, overwriting each others’ changes).

Lessons Learned

My primary lesson learned in this project was this: I still have a tendency to bite off
more than I can chew when trying to familiarize myself with a new development tool,
language, or environment. While I have been able to pick up languages and
programmin
g environments fairly quickly in the past, Java presented me with many
fundamental issues that should only have been attempted with a more structured
approach.


Given that my ambition outstripped my ability to learn and implement in the allotted
time, it w
ould probably have made more sense for me to attempt the project in
something I’ve had more training in here at Capella, such as ASP.NET. It is
unfortunate that Capella’s program gives such short shrift to server
-
side Java, as it
appears that most of the i
ndustry has shifted to server
-
side use, and has minimized
Java as the front
-
end client aspect of web applications. Had I received similar
training in J2EE as that which was presented to me for .NET, I would most likely
have been able to better manage the l
earning curve involved in my chosen project.


My stakeholder did advise me to look into the available resources which Ford uses for
its own J2EE projects, but as I explained to him, those resources are Ford
proprietary, and I did not wish to cause any lega
l issues in the creation of my
project.


Matt Raible was, again, quite nice to assist me as his time permitted. What he has
created with the AppFuse project bears scrutiny for the high level of automation it
offers to web developers. It was especially inte
resting to see how much automated
testing could be brought to play while attempting to decide how to structure one’s
application.


Of all the Capella Thinking Habits, I would most likely quantify this one as one of
those in the “Continuous Learning” catego
ry, as it’s quite obvious to me that I have
much more to learn if I wish to pursue server
-
side Java development as an additional
tool in my programmer’s toolbox.


Despite the good training I have acquired in my time here at Capella, I was unable to
complet
e the project portion of my course in time. Nevertheless, I intend to press
on, and continue to learn, using the foundation that Capella laid for me as a guide
into the future.

Appendix

The following appendices would be added to the Integrated Action Lear
ning Project
Final Report to provide a sample of my work and to evidence satisfactory project
completion:


Appendix A: Screen shot samples of the CMS

Redesign Prototype screen shot of the file manager interface:

Appendix B:

Stakeholder Confirmation of S
atisfactory Project Completion




Date:
December 9, 2005


To: Capella University


From:
Glenn Piot, Sr.


Subject: Satisfactory Project Completion



To whom it may concern:


Jason Batchelor

satisfactorily completed the pr
oject titled, “
Development of J2EE
-
based Content Management System for Tenacor
” per the project plan and/or
according to the specifications of the stakeholder.


While a working prototype has not yet been completed, Jason has created a feasible
object model

and entity relationship design which meets with my expectations.
Implementing even a known design in a new technology always poses uncertainties, and
Jason
desires

continue to work on developing a working prototype after the completion
of his course.
U
ser

interface
completion
and testing phases will be
conducted
once his
prototype is available
.


I have reviewed the project final report and find that there is no content that breaches
security or privacy needs of the stakeholder or beneficiary in the project
. It is therefore
deemed “publishable.” This means that the learner will upload a copy to a project
tracking Web site that has been maintained to meet academic requirements in the
respective degree program.



Sincerely,


Glenn Piot, Sr.

gpiotsr@comcast.ne
t