E-Commerce Project

CSI5389 E-Commerce Project - Part B

Original Author: Istvan T. Hernadvolgyi

Modified by: Saeid Nourian

Course Professor: Dr. Liam Peyton

System Requirement

J2SE must be installed.
Tomcat must be installed.
MySQL must be installed.
JDBC driver for MySQL must be downloaded and added to classpath.
XML/XSL Java libraries must be downloaded and added to classpath if not included in J2SE installation package.

Overview of Project

You are required to develop an online diary application. A diary consists of entries which are dated. The user of the diary may share certain entries with other users, not necessarily with one user. Users who are diary pals can also post message in each others diaries.

Functional Requirement

Anyone can create an account to become a user by providing a unique user name and a password
Users can add, edit and delete entries from their own diaries
Users can share diary entries with other users
Users can browse their diaries via a user-friendly, intuitive interface which shows the calendar year, months and days

Architectural Requirement

The responding server entity is always a Java servlet
Entries and other persistent information are stored in a database
The diary output is a result of an XML/XSLT conversion, which may take place either at the browser- or at the server-side, according to the choice of the user

Architecture

Milestone I: Database Schema

When persistence is required, the application must also have a well thought out data model. Therefore the first milestone is the design of a database schema. A good schema requires normalized tables, primary keys for each table and foreign keys for relations. For very complex systems the careful selection of indices (hash columns) is also essential, but in out case it is not relevant. It must be understood, however that any design error at this stage will carry over to the modules that depend on this. Therefore, we have to pay due attention even to this simple schema.

We require representation of the following entities and relations:

user: {name, password}
diary entry:

user: whom the message is for
sender: whom the message is from
subject: subject line of message
sent: time the message was posted
active: when the message should appear
message: the message body

diary pals: user who can send message to each other
shared entries: entries which are accessible by other authorized users

Due to the simplicity of the problem at hand, the model solution schema is as follows (primary keys are underline and foreign keys are italicitized).

users
user	Password
jill	awatto
monica	xafilah
jake	ontnorot

entries
id	*user*	*sender*	subject	sent	active	message
1	jill	jake	hi	2001/10/23	2001/10/25	hi jill!
2	jake	jill	hello	2001/10/25	2001/10/26	hello jake!

share
id	*user*
1	jill
1	jake
1	monica
2	jake
2	jill

pals
*user*	*pal*
jill	jake
jake	jill
monica	jill

In this example, there are three authorized users: jill, monica and jake. Jake sent a message to jill on 2001/10/23 which is to appear in jill’s diary on 2001/10/25. He could do this, because jill designate jake as a diary pal. Similarly, jake received a message jill on 2001/10/25. jill was so happy about this message that she shared this entry with monica (the message with id 1 in the shares table). Jill and jake can send each other message because they are diary pals. Jill can also send message to monica but monica was not granted this privilege from jill.

It is also important to understand that this is a data model and other than primary and foreign key constraints, higher level restrictions will be enforced by the layers built on top of this data model.

Milestone II: Database Agent

The access to the above SQL database is done through JDBC. In a well-designed e-commerce application, the details of database communication must be hidden from the business components. Therefore this project requires that a single Java class (namely DBAgent) take responsibility of handling all JDBC interface calls and provide the business components with relative information.

Below we list the operations which the agent must perform and also the command prompt test that verifies it:

Checking if a user is registered:

java project1.DBAgent –isUser <name>
where <name> is the name of a user. It should report yes or no.

Adding a new user.

Java project1.DBAgent –newUser <user> <pass>
If the user is already registered, it should result in a primary key violation exception from the database.

Authentication:

Java project1.DBAgent – checkUser <user> <pass>
where <user> is the name of the user and <pass is the passoword provided for the user name. It should report yes or no.

Check for a diary pal:

java project1.DBAgent –isPal <user> <pal>
where <user> and <pal> are user names. This should return yes if <pal> is authorized by <user> to send message to <user>.

Add a diary pal:

java project1.DBAgent –newPal <user> <pal>
This should result in a foreign key violation if either <user> or <pal> are not registered and it should result in a primary key violation if <pal> is already a diary pal of <user>.

Add a new entry:

java project1.DBAgent –newEntry <user> <sender> <subject> <message> <y> <m> <d>
where <y>, <m> and <d> are the year, month and day values for the message to appear. This operation, if succeed, should return a unique entry id assigned by the database. Exception is raised by SQL driver if the date is invalid or users don’t exist.

java project1.DBAgent –share <id> <user>
where <id> is the id of a message. Exception is raised if foreign keys are violated.

Check access to an entry:

java project1.DBAgent –isShared <id> <user>
should return yes or no.

Delete an entry:

java project1.DBAgent –remEntry <id>
should delete message. Also since <id> is foreign key it should trigger a cascading delete.

Display an entry:

java project1.DBAgent –showEntry <id>
this operation should fetch the message text corresponding to id.

In addition to providing these functionalities through its interface, DBAgent should also be implemented efficiently and handle simultaneous connections:

The agent should be able to reuse connections (perform several of its duties on the same connection)
Recover lost connections
Be thread safe (if invoked asynchronously, no operation like insert or update should corrupt the database or report incorrect information)
Recycle database resources

The solution to above is connection pooling and sensible design. Many databases support it by default, but still have to be configured appropriately. Our model solution explicitly implements a pool of agents which serve requests on behalf of multiple clients. Pay attention to the synchronization of critical code sections.

Milestone III: XML Agent

EC applications can exchange and utilize complex structures data if the data is layed out according to a formal specification and if it is represented in a standard format. XML is a standard markup for structured data and there is standard way of describing its layout. We follow this very paradigm by specifying the date structure of a diary.

<?xml version=”1.0” encoding=”UTF-8”?>

<!ELEMENT Diary (Year)>

<!ELEMENT Year (Month+)>

<!ELEMENT Month (Week+)>

<!ELEMENT Week (Day+)>

<!ELEMENT Day (Entry*)>

<!ELEMENT Entry (Subject, Message)>

<!ELEMENT Subject (#PCDATA)>

<!ELEMENT Message (#PCDATA)>

<!--Every diary has an owner and a user (the one who is looking at

diary). They can be the same person. -->

<!ATTLIST Diary

owner CDATA #REQUIRED

user CDATA #REQUIRED

<!ATTLIST Year

value CDATA #REQUIRED

<!ATTLIST Month

value (1|2|3|4|5|6|7|8|9|10|11|12) #REQUIRED

<!--The value attribute is the week of the month (1 for 1st week).

The firstDay attribute designates what day the first day of the week falls on: 1 for Sunday, 2 for Tuesday,...) -->

<!ATTLIST Week

value (1|2|3|4|5|6) #REQUIRED

firstDay (1|2|3|4|5|6|7) #REQUIRED

<!ATTLIST Day

ofMonth (1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|181|9|20|21|22|23|24|25|26|27|28|29|30|31) #REQUIRED

<!--from: sender of message

sent: date the message was sent

id: the id of this message which can be used to retrieve the message -->

<!ATTLIST Entry

from CDATA #REQUIRED

sent CDATA #REQUIRED

id CDATA #REQUIRED

This is very intuitive since a diary inherently chronological and we have months embedded in years, weeks embedded in months, days in weeks and finally the entries themselves inside the particular day when they supposed to appear.

The duty of the XML agent, therefore, is to fetch the entries for the requested time period and format it according to the above specifications; to produce a well-formed structured XML document.

Milestone IV: XSLT Transformation

Most modern browsers support the XSLT style-sheet transformation operation. This means that the browser retrieving an XML document which has a URL pointing to an XSLT style-sheet, the browser will perform the XSLT commands on the XML document. If it is a browser, it is expected that the result of the transformation is an HTML document. Of course, XSLT is more general and can be used in other context as well.

Here the requirements are only that the XSLT style-sheets produce legible, user-friendly HTML documents transforming the output of the XML agent.

Milestone V: User Interface

The user interface is composed of HTML documents and Java servlets. They are almost entirely user interface issues since the database logic and even the request-response format has been solved for previous milestones. However, it is the task of the servlets to perform session tracking. HTTP and HTTPS are session-less protocols and therefore the servlet must identify and protect individual user sessions.

While this milestone requires the most amount of code, it is also the most straight forward to write.