vi

EMAIL APPLICATION FOR LIMITED DEVICES

BY

Xiaomei Liu

July 2003

vii

TABLE OF CONTENT

LIST OF FIGURES.......................................................................................................8

CHAPTER 1 INTRODUCTION .........................................................................1

1.1 BACKGROUND ........................................................................................................1 1.2 PROBLEM ...............................................................................................................2 1.3 APPROACH .............................................................................................................2 1.4 ORGANIZATION OF THIS PROJECT REPORT ................................................................3

CHAPTER 2 LITERATURE REVIEW............................................................4

2.1 OVERVIEW OF J2EE TECHNOLOGY ..........................................................................4 2.1.1 J2EE standard specifications ...........................................................................4 2.1.2 J2EE Architecture ...........................................................................................7 2.1.3 J2EE standard services and components........................................................11

2.1.3.1 JNDI ......................................................................................................11 2.1.3.2 JavaMail.................................................................................................12 2.1.3.3 Java Servlet ............................................................................................14

2.1.3.3.1 Java Servlet compares to Applet and CGI ........................................14 2.1.3.3.2 Java Servlet basic structure..............................................................15 2.1.3.3.3 Servlet lifecycle ...............................................................................16

2.1.3.4 JSP.........................................................................................................17 2.1.3.4.1 JSP basic structure...........................................................................18 2.1.3.4.2 JSP lifecycle ....................................................................................19

2.1.3.5 EJB ........................................................................................................20 2.1.3.5.1 Session Bean ...................................................................................21 2.1.3.5.2 Entity Bean......................................................................................23

2.2 OVERVIEW OF J2ME TECHNOLOGY .......................................................................27 2.2.1 J2ME Architecture ........................................................................................27 2.2.2 J2ME Virtual Machine ..................................................................................28 2.2.3 Configuration................................................................................................28

2.2.3.1 Connected Limited Device Configuration...............................................28 2.2.3.2 Connected Device Configuration............................................................29

2.2.4 Profile ...........................................................................................................29 2.2.4.1 Mobile Information Device Profile .........................................................29 2.2.4.2 Other Profiles .........................................................................................30

2.2.5 Optional Packages.........................................................................................30

CHAPTER 3 METHODOLOGY ......................................................................31

3.1 REQUIREMENTS ....................................................................................................31 3.2 ANALYSIS AND ARCHITECTURE.............................................................................31 3.3 IMPLEMENTATION.................................................................................................33

3.3.1 Software and hardware used..........................................................................34

viii

viii

3.3.2 Palm client: coding, packaging, and deployment ...........................................34 3.3.3 Web client: coding, packaging, and deployment ............................................36 3.3.4 Server side: coding, packaging, and deployment ...........................................36

CHAPTER 4 RESULTS.......................................................................................47

CHAPTER 5 CONCLUSIONS ..........................................................................52

5.1 CONCLUSION........................................................................................................52 5.2 FUTURE WORK......................................................................................................52

REFERENCES........................................................................................................54

viii

LIST OF FIGURES

Figure 1 J2EE Connector Architecture Overview [cited from 10] ....................................6 Figure 2 J2EE Architecture Diagram .............................................................................10 Figure 3 JNDI................................................................................................................12 Figure 4 JavaMail related protocols ...............................................................................13 Figure 5 The JavaServlet Lifecycle................................................................................17 Figure 6 The JSP lifecycle .............................................................................................20 Figure 7 Stateless session bean lifecycle ........................................................................22 Figure 8 Stateful session bean lifecycle .........................................................................23 Figure 9 Entity Bean lifecycle .......................................................................................25 Figure 10 The J2ME Architecture..................................................................................27 Figure 11 State Transition Diagram ...............................................................................32 Figure 12 The system architecture .................................................................................32 Figure 13 Application architecture.................................................................................33 Figure 14 Start the application deployment tool.............................................................38 Figure 15 EmailApp.ear created ear.gif........................................................................39 Figure 16 Current Descriptor of the EmailApp.ear ear1dec.gif.......................................39 Figure 17 Create the SessionJAR in the applicaiton .......................................................40 Figure 18 Two session beans in the SessionJAR............................................................40 Figure 19 Create the EntityJAR in the application .........................................................41 Figure 20 An entity bean is in the EntityJAR EntityJAR2.gif.........................................41 Figure 21 CMP entity bean............................................................................................42 Figure 22 EQL for finder method ..................................................................................42 Figure 23 SQL query for "findBySender" method..........................................................43 Figure 24 JNDI name of the database ............................................................................43 Figure 25 Create the ClientWAR in the application .......................................................44 Figure 26EmailApp.ear with its components..................................................................44 Figure 27 The deployment descriptor of the EmailApp.ear ............................................45 Figure 28 JNDI Names deploy1.gif ...............................................................................45 Figure 29 Deployment successfully ...............................................................................46 Figure 30 Log in interfaces ............................................................................................47 Figure 31 Receive an email ...........................................................................................48 Figure 32 read emails ....................................................................................................49 Figure 33 Send an email from the PDA .........................................................................49 Figure 34 Receive the email sent by PDA......................................................................49 Figure 35 Reply to PDA client.......................................................................................50 Figure 36 Receive email sent by the web client..............................................................50

Chapter 1 Introduction 1.1 Background

The world has been changing tremendously since the Internet came into our lives.

Like other inventions such as the telephone, radio, and TV, the Internet has changed the

way people communicate and promoted the development of technologies, business and

economy.

Java technology plays an important role in the development of the Internet. Java

programming language was created by Sun Microsystems in 1995. It is "a simple, object-

oriented, multithreaded, garbage-collected, secure, robust, architecture-neutral, portable,

high-performance, dynamic language"[4]. Currently, the Java 2 platform includes three

editions: J2ME, J2EE, and Java 2 Standard Edition (J2SE).

J2SE is the core of Java technology. It provides the compiler, tools, runtime

environment, and APIs for developing Java applications and applets using the Java

programming language.

J2ME is aimed specifically at applications running on devices with limited

hardware resources such as cell phones, PDA, and other electronic embedded devices.

J2ME technology consists of configurations, profiles, and a minimum set of class

libraries supporting small devices.

J2EE is a standard architecture to define and support a multi-tier programming

model. By providing a complete set of services and constructing standardized component

modules, J2EE technology makes developers focus on business problems and leave the

low level programming details to the architecture. J2EE technology reduces the cost, time

and complexity of developing enterprise applications [9].

2

To develop a practical end-to-end application, Java 2 Platform is a good choice

because it provides robust end-to-end solutions.

1.2 Problem

Email has become the most commonly used communicating method since the

Internet technology was widespread used. Email is an electronic message that can be sent

or received through a computer, PDA, pager or cell phone inexpensively and fast. It can

be a text message or message with attachments, such as pictures, documents, music, or

voice mails. In a concise way, the principle of sending/receiving email is: first, the email

is sent to an email server on the sender's side and then sent to another email server, which

the receiver belongs to. Once it arrives at the destination server, it is stored in an

electronic mailbox until recipients retrieve it from their host computers [3]. Yahoo email,

Hotmail email, Microsoft's Outlook and Pine are popular email applications. But it is

hard for users to use these email applications on both a PC and a mobile device.

This project develops an email application that can be used on a PC or a Palm OS

PDA using JavaTM 2 platform technologies. It is based on the multi-tier architecture.

J2ME is used for the client side application running on a Palm OS PDA. J2EE is used for

server side applications running on a J2EE application server.

1.3 Approach

The end-to-end architecture of this project consists of the following tiers:

• Client tier: includes end user components, which is for web browser clients and

PDA clients.

• Web tier: includes web components such as JavaServer Pages and Servlets that

deal with client server communications and request/response procedures. The

3

connection between the client and web tier is Hyper Text Transfer Protocol

(HTTP).

• Middleware tier: includes EJB business components that encapsulate business

rules. This tier communicates with the client tier, web tier and the Enterprise

Information Systems (EIS) tier.

• EIS tier: includes information management components – database system.

The functionality of the application is divided into three parts:

• Presentation logic: how the interfaces between the users and applications work.

The logics include how users input the information that the application needs and

how the application displays the information the users need.

• Business logic: how to send, receive, save, and delete messages from an email

server. This is the most important part of this application.

• Database access logic: how to connect to a database for saving, updating and

getting data.

1.4 Organization of this project report

Chapter 2 introduces the literature review of Java technology with concentration

on J2ME and J2EE technologies that are adopted in this project. Chapter 3 describes the

methodology of this project, which provides the details of the project development:

requirement, requirement analysis, architecture design and implementation. Chapter 4

demonstrates the results of execution of the email application and shows its capabilities.

Chapter 5 summarizes this work and suggests its future development.

Chapter 2 Literature review

This chapter introduces the J2ME and J2EE technologies with respect to their

architectures, some of the services and component models they provide.

2.1 Overview of J2EE technology

J2EE technology is a standard specification and architecture that defines and

supports multi-tier distributed component-based enterprise applications. It is a multi-

vendor standard technology. The J2EE standard has been developed by Sun Microsystems

and Java Community Process (JCP). JCP is an organization founded in 1995. The

international Java developers and licensees in this open organization develop and revise

Java technology [6]. Now JCP has over 500 company and individual participants.

Members of JCP cooperate and set up the standard of J2EE, but compete through

implementing the specifications and making their products more competitive. Only Sun

Microsystems owns the licensing right for J2EE products. The companies who want to

brand their products as J2EE must have the specification, reference implementation of the

specification and pass the compatibility tests offered by Sun Microsystems. Now, there

are several J2EE 1.3 Compatible Implementations such as BEA WebLogic Server 7.0,

IBM WebSphere Application Server 5.0, Oracle 9i Application Server, SunTM ONE

Application Server, and Fujitsu Interstage Application Server, etc [12].

2.1.1 J2EE standard specifications

J2EE specifications include three parts: the J2EE Platform Specification, the J2EE

Connector Specification, and the J2EE Client Provisioning Specification.

J2EE Platform Specification

5

The J2EE Platform Specification specifies the J2EE architecture, application

components, containers, resource adaptors, J2EE standard services, security, transaction

management, naming, application programming interface (API), interoperability,

application assembly and deployment, application clients and service provider interface,

etc, which are needed by developing J2EE applications [11]. In version 1.4, it also

introduces new APIs, which implement core Web services protocols, new Management

and Deployment APIs, new versions of the JSP, EJB, and Connector APIs, and other

features that make J2EE 1.4 technology as the premier Web services and enterprise

application integration platform [10].

J2EE Connector Architecture Specification

The J2EE Connector Architecture specifies a standard architecture for integrating

a Java application server with heterogeneous EIS such as mainframe transaction

processing (TP) or a relational database. Not all these EISs are written by Java. A Java

application server cannot access them directly without some appropriate connectors.

Connectors are adaptors that let these incompatible parts communicate with each other.

J2EE Connector Architecture is the Java solution for application integration [14]. With

the J2EE Connector Architecture, EIS vendors do not need to customize their products

for each application server and J2EE application vendors do not need to add additional

codes when a new EIS is connected to a server.

Figure 1 shows the J2EE connector architecture. It provides a standard

architecture for EISs to build a resource adapter for its system product. The resource

adapter is plugged into an application server. An EIS needs just one resource adapter and

one application server can hold several resource adapters of different EISs. Both the

6

server and the application components located in the server can access the EIS via the

resource adapter. Application components have an application contract with the resource

adaptor and the server has a system contract with the resource adaptor.

Figure 1 J2EE Connector Architecture Overview [cited from 10]

For application servers and EISs, J2EE Connector Architecture defines a

Connection Manager contract, a Transaction Manager contract, and a Security Manager

contract that enable outbound connectivity to an EIS. It defines a Transaction Inflow

contract and a Message Inflow contract that enable inbound connectivity. It also defines a

Lifecycle Management contract and a Work Management contract, which enables

resource adapter lifecycle management and thread management [13].

For application components and EISs, J2EE Connector Architecture defines a

Common Client Interface (CCI) API. The application developer can write codes for

applications to connect to a resource adapter using CCI API. The other connectivity

technologies include Java IDL, RMI over IIOP and Java Native Interface (JNI).

7

J2EE Client Provisioning Specification

The J2EE Client Provisioning Specification extends J2EE technology by enabling

a J2EE application server to manage and distribute services to varieties of clients such as

mobile devices, PDAs or PCs. These clients can be built on a J2ME or J2SE platform or

platforms that do not support Java. Usually these clients are sophisticated, also called rich

clients. J2EE Client Provisioning technology simplifies the deployment of rich client

technology in the wireless and wire line enterprise.

This specification defines a central repository of client applications and content

called provisioning portal. The portal manages the distribution of clients and their

content. Users can discover the rich client application from the portal and the portal can

deliver services to the users. The specification defines the APIs to customize the

provisioning portal. These APIs are used to interact with the delivery process. It also

defines a Provisioning Archive (PAR), which is a file format that standardizes the way

client applications and contents are packaged and deployed to the provisioning portal.

Another technology is an extensible Service Provider Interface (SPI). It defines an

adapter for different devices. The adapter allows the provisioning server to be compatible

with the new generated devices [15].

2.1.2 J2EE Architecture

J2EE is a distributed solution using multi-tier architecture. Before we look at the

architecture of J2EE, it is better to look back at a little background.

Mainframe architecture

Before client/server architecture appeared, the mainframe architecture was widely

adopted. In this architecture, all the functions like presentation, business logic, and

8

database access run on a single host computer. Users interact with the host through a

terminal with little function. This architecture works fine for small applications and the

applications that access the local database with low network use.

Two-tier architecture

Client/server architecture was born along with the network and PC development.

In the two-tier client/server architecture, the database is separated from the mainframe.

The advantages of this architecture are: not only can the data be shared by different client

applications running on different machines but also any change that occurs in the

database logic does not affect the client side; different databases can be accessed easily

by just changing the interface. Two-tier architecture is a good distributed computing

solution. But the disadvantages are also obvious for fat clients (business logic is on the

client side). First, deployment is not easy because client side applications need to be

installed on every machine and the update is difficult. Second, the memory and the

processor speed are limited for a single machine. Third, the network traffic between the

client and the server is overloaded and the performance is very poor when the users are

over 100. Disadvantages for thin clients (business logic is moved to the server side) are:

heavy load on the server machine and hard to maintain when different applications need

to work with the same data.

Three-tier and n-tier architecture

In the 3-tier architecture, the business logic is separated into an intermediary

position between the client and the database server. This middle tier can be still divided

into several smaller tiers. Thus 3-tier architecture becomes n-tier or multi-tier architecture

when the tiers are greater than 3. This is a very common architecture today.

9

Although the 3-tier or n-tier architecture overcomes the limitations of 2-tier

architecture, it still has big limitation: application programmers have to deal with

infrastructures with different servers. Obviously, this is a hard work for programmers

[18].

The Common Request Broker Architecture (CORBA), with the introduction of

object services, solves infrastructure problem by making transaction services, persistence

and naming services. But it needs explicit use of the services. It means that programmers

have to write some codes or make some function calls explicitly when they want to use

the services every time.

Distributed computing

It is a good time to talk about distributed computing before introducing the J2EE

architecture. Distributed computing means that a complex computing task is assigned to

several interconnected separated computers. In other words, distributed computing allows

computers in different locations to do part of the tasks and cooperate with each other.

Thus distributed object technologies such as JavaRMI, CORBA and Microsoft's .Net

were developed. The object can be transferred from one machine to another and can be

called by applications on different computers. Distributed objects evolved from 3-tier

architecture systems.

In recent years, distributed objects technology makes it possible to put procedural

business objects into the middle tier. So the graphical or web-based applications could

use the middle tier. The middle tier can serve more client applications or web clients.

More complex applications need n-tier architectures. With the development of

technologies, people realize that existing standard services will be helpful for

10

programmers to develop complex enterprise applications At the server side, component

concepts are gradually evolved. Components are models for developing distributed

application. Servers manage components at run time and make them available to remote

clients. These components are developed by programmers and can be used, bought or

sold as independent executable software. Components must conform to a standard, so

they can be used easily for different clients and different computer systems. These

concepts lead to the J2EE architecture.

J2EE architecture

J2EE architecture is based on the n-tier architecture and component model. The

keys to the J2EE architecture are: first, the J2EE server provides underlying services for

its components; second, the business logic can be wrapped into a reusable component that

is platform-independent. So developers do not need to define these services by

themselves, only focus on the business logic and pay little attention to the infrastructure.

Figure 2 J2EE Architecture Diagram

HTTP SSL

J2SE, J2ME

Client

Database

Standard Services

J2SE

EJB

EJB Container

Standard Services

J2SE

JSP Servlet

Web Container

J2EE Server

11

Figure 2 illustrates the J2EE architecture. Based on J2SE, J2EE server provides

underlying services in the form of the containers, which provide J2EE runtime

environments for the components in it. These services are the interfaces between the

components and the low-level platform. Containers include EJB container that manages

EJBs, web container that manages JSP pages and Servlets, application client container

that manages client components and applet container.

2.1.3 J2EE standard services and components

The J2EE standard services include HTTP, HTTPS, JavaTM Transaction API

(JTA), RMI-IIOP, JavaTM IDL, JDBCTM API, JavaTM Message Services (JMS), Java

Naming and Directory Interface (JNDI), JavaMailTM, JavaBeansTM Activation Framework

(JAF), JavaTM API for XML Parsing (JAXP), J2EETM Connector Architecture, Security

Services, Web Services, Management and Deployment. Some of the services are

provided by J2SE. JNDI, JavaMail, Servlet, JSP and EJB are introduced below.

2.1.3.1 JNDI

JNDI provides a standard API for the Java application to access heterogeneous

naming services and directory services infrastructure. Using JNDI, a Java application can

store and retrieve Java objects in a distributed computing environment and access any

type of directory service.

A naming service provides name registering and object retrieving by its unique

name. It is a name-object mapping functionality. For example, Internet Domain Name

System (DNS) maps the people-friendly name http://www.yahoo.com to machine

recognized name 123.123.123.123.

12

Directory service always has a naming service. A directory associates not only

names with objects but also objects' attributes. So an object can be found by the name or

by its attributes without knowing its name through directory services.

There are so many directory services and each of them has their own API. So the

complexity of the application codes increases by dealing with all of the APIs. JNDI is the

solution for this issue. In Figure 3, varieties of naming and directory services are plugged

in through JNDI Server Provider Interface (JNDI SPI). Java applications use the JNDI

API to access these naming and directory services [8].

In a J2EE application, clients, EJB, web components and database system are

required to have access to a JNDI naming environment which is provided by the

containers. By using the naming service, application components can be customized

without accessing or changing components source code [11].

Figure 3 JNDI

2.1.3.2 JavaMail

The JavaMailTM API is a set of abstract APIs that model a mail system for

reading, composing, and sending electronic messages by accessing message stores and

Java Application

JNDI API

JNDI SPI

Naming Manager

LDAP CORBA RMI DNS others

13

transports. Using the JavaMail API, developers can write a Mail User Agent (MUA) type

application to read or write an email. Microsoft Outlook, Eudora, and Pine are all MUA

type applications. Related protocols to the email system are introduced below. (See

Figure 4)

Figure 4 JavaMail related protocols

Simple Mail Transfer Protocol (SMTP)

The SMTP is the mechanism for transferring email from the sender's user agent to

the sender's mail server and/or from the sender's mail server to the recipient's mail server.

Post Office Protocol (POP)

POP is a mail access protocol. It is a simple protocol that transfers mail from the

recipient's mail server to the recipient's user agent.

Internet Message Access Protocol (IMAP)

IMAP is a more advanced protocol for receiving messages. An IMAP mail server

allows users to access and manipulate the remote mailboxes located at a remote server.

Users can access the mail folders from different machines. Also, an IMAP mail server

has commands that allow the users to obtain components of messages. This advantage is

useful for a low-bandwidth connection between the mail server and a mail agent like

SMTP

SMTP SMTP

POP/IMAP POP/IMAP

User Agent User Agent Mail Server Mail Server

14

PDA. With the low-bandwidth connection, the user can just download part of the

messages which are, in general, good enough for the users.

Multipurpose Internet Mail Extensions (MIME)

MIME is not a mail transfer protocol. Instead, it defines the content of what is

transferred: the format of the messages, attachments, and so on. MIME type includes

text/plain, multipart, and message/rfc822. Corresponding to the Java types are

java.lang.String, java.mail.internet.MimeMultipart, and MimeMessage. JavaMail uses

JAF to supports MIME type. MIME byte streams can be converted to/from Java objects

using javax.activation.DataContentHandler objects [11].

2.1.3.3 Java Servlet

A Java Servlet is a server-side component for dynamically enhancing the

functionality of a server and accessing the existing business systems. On a web server, a

Java Servlet provides a way for building web applications that implement the

request/response operations. The Servlet technology is a popular choice for building

interactive Web applications [8].

2.1.3.3.1 Java Servlet compares to Applet and CGI

A Java applet is a Java program that can be transported across a network and

executed inside a Java-enabled web browser on the client side. A servlet executes on a

Java-enabled server. An applet provides a graphical interface to users, but a servlet does

not. A servlet works behind the scenes on the server side. The servlet only provides the

results to the client by HTML format or some other formats.

15

For a web application, Java Applet is a good choice if users are on an intranet.

This is because there are less network connections and less bandwidth limitations on the

intranet; thus the performance is good. But the situation is different if users use the

Internet. For the Internet, the servlet technology is a better choice for web applications.

Servlets have several advantages over the Common Gateway Interface (CGI),

which is another dynamic method on the server side. First, servlets run in the same

process as the server, and are loaded only once when invoked the first time. All the

requests from a client can be performed through threads within the same process quickly

and efficiently. CGI must create a new process to service each request and CGI cannot

access databases through a single database connection for multiple requests. So the

performance of servlets is higher than that of CGI. Second, servlets are server

independent. Servlets can run on any server that supports the servlet technology. This

portability of servlets is very important for enterprise-distributed applications [2].

2.1.3.3.2 Java Servlet basic structure

There are four packages related to servlets in the J2EE API: javax.servlet,

javax.servlet.http, javax.servlet.jsp, and javax.servlet.jsp.tagext. The first two are for

servlets. They contain classes and interfaces that describe and define the contracts

between a servlet class and a servlet container, which provide the runtime environment

for the instances of a servlet class. The javax.servlet.http package is for a servlet class

that uses the HTTP protocol. The last two are for JSP pages.

All servlet classes must extend one of two servlet classes: GenericServlet or

HttpServlet. All servlet classes implement three methods: init(), destroy() and service().

16

The init() method is implemented by most servlets. It is called when the servlet is first

loaded and called just once during the lifetime of a servlet. The destroy() method is called

when the servlet is unloaded. All servlets override the service() method that is

automatically called by the server. For a servlet that extends the GenericServlet class, the

method name is service(). For the servlet which extends the HttpServlet class, the name

of service() method is changed to "doMethod()" such as doPost(), doGet(), etc. The

service() method gets information from the client, accesses other resources, and

responses to the client. The following is an example for a servlet class.

public class EmailServlet extends HttpServlet

{

public void init(ServletConfig config) throws ServletException

{ …}

public void doPost (HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException

{ …}

public void destroy(){ …}

}

2.1.3.3.3 Servlet lifecycle

A J2EE server includes one or more containers to provide run time environments for

components and service client requests. A web container hosts servlets and JSP pages. It

handles the whole lifecycle of a servlet and provides the network services over which

requests and responses are set, decodes MIME-based requests, and formats MIME based

responses. A servlet container must support HTTP as a protocol for requests and

responses [19]. The following steps describe the lifecycle of a servlet. See Figure 5.

17

Figure 5 The JavaServlet Lifecycle

1. The server loads a servlet by its name when a client first requests the servlet.

2. The server creates one or more instances of the servlet class.

3. The server constructs a ServletConfig object which provides the initialization

information for the servlet and calls the servlet's init(ServletConfig sc) method.

4. The server receives requests from the client and calls the service() method of the

servlet.

5. The service() method is processed.

6. The result is sent to the client.

7. The servlet services the other requests.

8. The server unloads the servlet by calling the destroy() method. [2]

2.1.3.4 JSP

A JSP page is a web page that contains the static content and dynamic content. In

a JSP page, the HTML, WML, or XML tags define the static content. JSP tags that

Client

Web Container

Servlet A

Servlet B

4 HttpServletRequest

6 HttpServletResponse

Instance of A

loaded A class 1

2

Initiated A

3

Serviced A

5,7

8

18

include java codes define the dynamic content. The goal of JSP technology is to simplify

the creation and management of a dynamic web page. The JSP technology makes it faster

and easier to build and maintain web-based applications for developers and designers.

JSP technology separates the user interface from the dynamic content enabling designers

to change the page layout without altering the dynamic content and/or vice versa.

2.1.3.4.1 JSP basic structure

A JSP page is a mixture of documents including HTML scripts and Java codes.

Specifically, a JSP page is a HTML file that encloses Java codes between <% … %> tag.

JSP tags fall into the following categories: Directive, Scripting element, Action, and

Author defined tags. A typical JSP page might look like this:

<%@ page import="java.util.*" %>

<html>

<body>

Today is <%= new Date(). ToString() %>

…

</body>

</html>

Directives: The format of a directive tag is <%@ …… %>. Directives provide the

information of the JSPs to a web container. The information includes the global values,

class declaration, etc. Directives do not produce any response to a client. But they are the

necessary conditions to execute a JSP file. There are several directives used in the JSP

pages:

1. page directive: The format is <%@ page …… %>. It defines and manipulates

attributes of a page such as which language is used in this page, what packages

19

are imported, if a session is used, etc. Corresponding attributes are language,

import, and session.

<%@ page language="java"

import="java.io.*, java.util.*, java.net.*, java.lang.*, javax.servlet.*, %>

2. include directive: format is <%@ include …… %>. If the JSP needs to use other

files, include directive tells the file name. "file" is the only attribute of include.

For example:

<%@ include file="PageTop.html" %>

3. taglib directive: format is: <%@ taglib …… %>. It allows the pages to use

custom tags.

Scripting element: The format is <%! …… %>. It is the java code in a JSP page.

1. declaration: The format is <%! …… %>. It is a block of java code that defines

variables and methods for the generated servlet. It does not write anything to the

output stream.

2. scriptlet: The format is <% %>. It is a block of java code that executes the

request/response process.

3. expression: format is <%= %>. It is a combination of the scripting language

expression and a string that return to the client.

4. standard actions include: <jsp:UseBean>, <jsp:setProperty>, <jsp:getProperty>,

<jsp:param>, <jsp:plugin>, <jsp:include>, and <jsp:forward>.

2.1.3.4.2 JSP lifecycle

The lifecycle of a JSP page is similar to that of a servlet. Figure 6 shows the

lifecycle of a JSP page.

20

Figure 6 The JSP lifecycle

1. The JSP container loads a JSP class.

2. The corresponding servlet code is automatically generated from the JSP code,

compiled and loaded into the servlet container.

3. The servlet processes the request and the response from/to the client.

4. The server unloads the servlet by calling the destroy() method.

JSP technology is an extension of the Java Servlet technology. JSPs and Servlets

provide a solution for web applications using dynamic web scripting/programming. They

lead to platform independence, enhanced performance, and separation of logic from

display [5].

2.1.3.5 EJB

According to Sun Microsystems, Enterprise JavaBeansTM is "the server-side

component architecture for the J2EETM platform. EJBTM enables rapid and simplified

development of distributed, transactional, secure and portable Java applications [17]." An

Client

Web Container

JSP A

Request

Response

JSP container 1

2

4

Servlet container

corresponding Servlet of A

First request

3

loaded JSP A

21

EJB is a functional component in the J2EE architecture. It belongs to the middle tier --

business logic tier, which is between the web tier and the EIS tier. It lives in an EJB

container and the EJB container is in an application server. The application server

provides the runtime environment for the container and manages low-level resources

needed by the container. The container provides the runtime environment for the beans

and manages all the beans, which are in the container. The primary reason that EJBs are

used is to take advantage of the services that the container provides such as persistence,

transaction, scalability, portability, and resource management. By using EJBs,

programmers can focus on business logics other than the system level programming. An

EJB is a simple, portable, reusable, deployable, and scalable software component. It can

be assembled as a component to any J2EE server. There are three types of EJBs: Session

Bean, Entity Bean, and Message Driven Bean. Message Driven Bean will not introduced

here.

2.1.3.5.1 Session Bean

A session bean models business logic and usually accomplishes the "verb"

process and the enterprise's workflow. It is not a persistent object and does not represent

a shared database, but it can access the database by reading, updating, or inserting data. It

works for a single client and cannot be shared by multiple clients. A remote client

accesses a session bean through the session bean's remote interface and invokes the

methods declared in that interface. After the client quits or the method call finishes, the

session bean no longer exists. There are two types of session beans: stateful session bean

22

and stateless session bean. A stateful session bean keeps the state of a client who calls it,

but the stateless session bean does not.

Stateless session bean

Figure 7 shows the life cycle of a stateless session bean. A stateless session bean

has two states: the Does Not Exist state and the Ready state.

Figure 7 Stateless session bean lifecycle

When a stateless session bean is in the Does Not Exist state, it means that the

session bean has not been initiated; no such session bean is in the memory of the system

at all. It can transit from the Does Not Exist state to the Ready state by three method

invocations that are container-initiated.

A stateless session bean that is in the Ready state, also called Method-Ready pool,

is ready to service the client requests. Typically, a container initiates numbers of session

beans and puts them into a pool. The numbers of the instances created by the container

depend on the container's needs. The instances of the session beans in the pool are all

ready to be used by clients. When a client invokes a business method on a bean object,

any available instance in the pool will delegate the task. This instance will be unavailable

to the other calls. The container will call the remove method to transit the session bean

back to Does Not Exist state when the container no longer needs the bean.

Does Not Exist

Ready

newInstance() setSessionContext() ejbCreate()

remove() ejbRemove()

23

Stateful session bean

A stateful session bean keeps the state of the client who calls it during the

methods calls. Every method call from a client is serviced by the same instance. It has

three states: Does Not Exist, Ready, and Passive. (See Figure 8)

Figure 8 Stateful session bean lifecycle

A stateful session bean has one more state than a stateless session bean-- Passive

state. A container cannot discard a stateful session bean in Ready state because that

session bean represents the state of a client, and the client might need that session bean

later. At this time, the container puts the session bean into a Passive state. When it is in

the Passive state, the session bean releases the resources it held before. When the

container decides that the passive session bean is needed again, it calls ejbActivate () to

activate the passive session bean and the bean reenters the Ready state.

2.1.3.5.2 Entity Bean

An entity bean represents an entity. It expresses the "noun" word in the

requirement. An entity bean represents the persistent data in a database. Compared to a

relational database, each entity bean maps to a table and has a primary key; each instance

of an entity bean maps to one record in the table. The big difference between an entity

bean and a session bean is that the entity bean is persistent even if the application

Ready

newInstance() setSessionContext() ejbCreate()

remove() ejbRemove()

Passive

ejbActivate()

ejbPassivate()

Does Not Exist

24

terminates. It can be shared by multiple clients and may participate in relationships with

other entity beans.

There are two types of entity beans according to how they manage persistence:

container-managed persistence (CMP) beans and bean-managed persistence (BMP)

beans.

Container-managed persistence

CMP means that the EJB container manages the persistence of an entity bean. The

EJB container handles all database access for the entity bean. There are no SQL queries

in the bean's class. All the persistence and relationship fields of the entity bean are

declared to the container in the deployment descriptor file and the container will map the

entity bean to a table and the persistent fields to the table's columns during deployment.

CMP enables the developers to change a bean's data source without affecting its

implementations. So the bean's codes are not tied to a specific database. If the entity bean

is deployed to a different J2EE server that uses a different database, the bean's code does

not need to be modified [16].

Although developers do not need to write SQL queries in the source code, they

need to use the Enterprise JavaBeans query language (EJB QL) to define queries for

entity beans and the container. The EJB QL defines the queries for the finder and select

methods for a CMP entity bean. Developers also need to define the abstract schema

name, persistent fields and relationships for an entity bean in the deployment descriptor.

An abstract schema defines a bean's persistent fields and relationships. An abstract

schema name is a logical name referenced in EJB QL queries. The deployment tool

25

automatically translates the EJB QL queries to an underlying data store language. A CMP

entity bean is more portable and easier to be developed [16].

Usually, a CMP entity bean needs the entity bean class, local home interface,

local interface, and remote interfaces. Local home interface defines the create, finder, and

home methods which can be invoked by local clients. Local clients may be the other

beans which in the same container. Local interface defines the business and access

methods, which can be invoked by the local clients. The advantage using local interfaces

is that the performance improves. The method calls defined in the local interface do not

need to involve RMI. In general, local method calls are faster than remote method calls.

Entity bean class defines ejbcreate, ejbPostCreate, ejbRemove, and get/set abstract

methods defined for the persistent and relationship fields.

Bean-managed persistence

Beans’ developers need to write the codes to manipulate the database accesses.

With BMP, accessing the database is explicitly written in the entity bean class using

JDBC and SQL.

Entity bean's lifecycle

Figure 9 Entity Bean lifecycle

ejbRemove()

ejbPassivate()

ejbActivate()

newInstance() setEntityContext()

finalize() unsetEntityContext()

ejbCreate() ejbPostCreate()

Does Not Exist

Pooled Ready

26

An entity bean that is in the Does Not Exist state (See Figure 9) is not initiated.

When the EJB server is started, the container creates several instances and places them

into a pool of available instances of the specified entity bean class. The method

newInstance() uses the default constructor, which has no arguments. The entity beans in

the pool are in the Pooled state. These pooled instances are identical and do not represent

any record in the database. None of them are assigned to an EJB object. The container

can invoke the create() method or finder methods of the pooled instances.

When a client needs a specific instance of the bean, it invokes the create()

method, then the container first creates an EJB object and assigns an entity bean instance

from the pool to that EJB object. The container invokes the ejbCreate() method which is

the corresponding method to the create() method called by the client. After the

ejbCreate() is done, the ejbPostCreate() method is called. An entity bean instance is

moved from the Pooled state to the Ready state. Then an entity bean object is returned to

the client.

When an entity bean instance is in the Ready state, the client can invoke the

bean's business methods. Synchronizing the data represented by the instance with the

corresponding data in the data source is accomplished by the instance's ejbLoad() and

ejbStore() methods called by the container. [5]

The EJB 2.1 specification enhances the EJB architecture with support for Web

services. Enterprise developers can implement and deploy web service applications with

the same level of ease as other server-side applications.

27

2.2 Overview of J2ME technology

As one of the three platforms, Java 2 Platform, Micro Edition (J2ME) is specially

designed for consumer and embedded devices such as cell phones, PDAs, TV set-top

boxes, and a broad range of other devices [17]. It is a collection of technologies and

specifications that are designed for a variety of small devices. These technologies

include: Connected Limited Device Configuration (CLDC), Mobile Information Device

Profile (MIDP), Connected Device Configuration (CDC), Foundation Profile (FP), Java

CardTM Technology, Java CardTM Technology, Java Embedded ServerTM Technology

,PersonalJavaTM Technology , and Java TVTM API , etc.

2.2.1 J2ME Architecture

J2ME aims at a variety of devices. These devices are divided into different

categories based on the memory, processing power, and persistent storage; and new

devices continue to emerge in the commercial market. So the J2ME architecture defines

configurations, profiles, and optional packages to support different type of devices. (See

Figure 10)

Figure 10 The J2ME Architecture

KVM

CLDC

MIDP

Optional Package

JVM

CDC

Foundation Profile

Personal Profile Personal Base

Profile

Optional Package

28

2.2.2 J2ME Virtual Machine

Since CLDC and CDC are defined for different categories of devices, each of

these two configurations has their own Java virtual machine. The underlying virtual

machines for CLDC are Kilo Virtual Machine (KVM) and HotSpot. KVM aims for the

small inexpensive mobile devices and the HotSpot aims for the newer generation larger

devices. The virtual machine for CDC is CVM.

2.2.3 Configuration

Configurations define the Java virtual machine, a minimal set of Java class

libraries, and APIs that can be used for a certain group of devices. Currently, there are

two J2ME configurations: CLDC and CDC.

2.2.3.1 Connected Limited Device Configuration

CLDC is the smaller one of the two configurations. It is the foundation of the Java

runtime environment designed for small devices with simple user interfaces, limited

memory in the range of 128 kilobytes to 1 megabyte, 16-bit or 32-bit slow processors,

low bandwidth and intermittent network connections not using TCP/IP. Typical devices

include the mobile phones, pagers, and PDAs.

The APIs designed for the CLDC are: classes in the java.lang, java.io, and

java.util packages, which are inherited from J2SE and classes in the javax.microedition.io

package, which are used for the small devices.

29

2.2.3.2 Connected Device Configuration

CDC is designed for the larger devices that have more memory, faster processors,

and robust network connections. These devices usually have a large range of user

interface capabilities, a minimum of 2 MB of memory, a 32-bit or better CPU, high-

bandwidth network connections, and the TCP/IP network protocol. Examples are TV set-

top boxes, Internet TVs, etc.

2.2.4 Profile

Not only configurations but also profiles are needed in order to provide a

complete runtime environment for devices. Based on corresponding configurations,

profiles define high-level APIs for specific device categories for the applications’

lifecycles, user interfaces, and network communications. There are several profiles that

have been defined: MIDP for CLDC and Personal Profile (PP), Personal Basis Profile

(PBP) and FP for CDC.

2.2.4.1 Mobile Information Device Profile

Combined with CLDC, MIDP provides a complete J2ME application runtime

environment targeted at mobile information devices, such as mobile phones and entry

level PDAs. MIDP specifications address issues such as user interfaces, persistence

storages, networking, and application lifecycles. J2ME makes a new generation of

wireless applications, such as an enterprise client/server application, which the client runs

on the Palm OS PDA. MIDP, CLDC and KVM form the foundation for developing this

kind of Java applications.

30

The MID Hardware layer refers to the devices. The Native System Software layer

is the native operating system and system library provided by device manufacturers. The

KVM layer is the runtime environment for Java applications. The CLDC layer provides

the core Java APIs. The MIDP layer provides basic libraries for interface, persistent

storage, and networking and timer classes.

2.2.4.2 Other Profiles

CDC is divided into several layers. New layers can be added into it so that

different functionality can serve for different types of devices. FP is the lowest level

profile for CDC, which provides a network-capable implementation of CDC that can be

used for embedded implementations without user interfaces. PP is a profile for CDC,

which supports a full GUI or Java applet. It supports full Java Abstract Window Toolkit

(AWT) libraries. PBP is a subset of PP, which provides an environment for network-

connected devices that need specified graphical toolkits. PP and PBP are layers on the top

FP.

2.2.5 Optional Packages

Optional Packages are packages that can be further extended based on CDC,

CLDC and corresponding profiles.

This chapter introduces J2ME technologies and J2EE technologies. Using J2ME

and J2EE technologies, a portable, scalable, and robust email application is easy to

develop. The next chapter discusses the methodology of this project.

Chapter 3 Methodology

The objective of this chapter is to introduce the methodology of this project.

Firstly, requirements of this project are described. Secondly, after the analysis of the

requirements, the technical strategies and architecture are presented. Finally, based on the

requirements and architecture design, the implementation is introduced, i.e. to express the

requirements and architecture in a programming language.

3.1 Requirements

1. The user must have an ASURITE ID and Password.

2. The user shall be able to send, receive, save, and delete emails via a web browser

or a Palm OS PDA.

3. A PDA user shall be able to perform the above functions via the wireless network.

4. A PDA user shall save the emails to the PDA device.

5. The application shall be implemented with Java programming language.

6. Application shall use J2EE and J2ME technology.

7. The database system used in this application shall be MS Access or Cloudscape.

8. User interfaces should be straightforward and easy to use.

3.2 Analysis and Architecture

From the requirements, a state transition diagram is drawn for a user. See Figure

11. A user has two states: Log off and Log in. In order to use the application, a user needs

to log in. At the start point, the user is in the Log off state. If the user log in successfully,

the state of the user is transited to the Log in state. Otherwise, the user has to log in again

with valid user id and password. In the Log in state, the user can send, receive, save, and

32

delete emails that are the main functionalities of this email application. After log off, the

state of the user turns to Log off state again.

Figure 11 State Transition Diagram

Based on the requirements and the analysis, the system architecture and

application architecture are designed. Figures 12 shows the system architecture. Clients

communicate with (send requests and get responses) a web server and the application

server by HTTP. The application server communicates with the IMAP email server by

SMTP and IMAP protocols and communicates with the database system by JDBC.

Figure 12 The system architecture

User

Log off Log in Log in successfully

Log in failed

send receive

save delete

Log off

HTTP

Clients

Database server

Web Server Application Server

IMAP Email Server

HTTP

33

Figure 13 shows the application architecture of this project. J2EE server holds a

web container and an EJB container. A servlet and several JSP pages are located in the

web container. Three EJBs exist in the EJB container. The two clients talk to the J2EE

application server by HTTP. The application server does the most of the tasks for the

clients which include login, send/receive emails, save/delete emails. In order to

accomplish the tasks, the J2EE server needs to contact with the IMAP email server and

the database system.

Figure 13 Application architecture

3.3 Implementation

The implementation language, the suitable operating system, software/hardware

used, coding, packaging, and deploying procedures are introduced in the following.

DB

IMAP Email Server

HTTP

Palm PDA

Web Browser

EmailServlet

WebClient.jsp

Content.jsp

Send.jsp

Delete.jsp

Web Container

forward

J2EE Server

Login EJB

SendReceive EJB

Email EJB

EJB Container

save

34

3.3.1 Software and hardware used

1. Operating System: Windows XP or Windows 2000

2. Build tool: Ant 1.4.1

3. J2SE: JSDK 1.3.1 or higher

4. J2EE reference implementation: Sun Microsystems' J2EE SDK 1.3.1. A reference

implementation is for demonstrating the capabilities of J2EE.

5. J2ME reference implementations: Sun Microsystems' CLDC reference

implementation 1.0.2 and Sun Microsystems' MIDP reference implementation 1.0

6. Testing software: Palm OS Emulator (POSE). This is software that emulates the

various models of Palm OS PDAs on Windows. It is used for writing, testing and

debugging applications [7].

7. Web Browser: Internet Explorer

8. Palm OS PDA: Visor

9. wireless card for PDA.

3.3.2 Palm client: coding, packaging, and deployment

The source code of the application running on POSE or Palm OS PDA is

EmailMIDlet.java. MIDlet stands for a Mobile Information Device Application. For

MIDlets, not only the APIs are different from their counterparts in J2SE and J2EE but the

packaging and deployment are also different. The steps for developing Palm client are

listed below.

1. Write source code EmailMIDlet.java. The EmailMIDLet.java has the following

functionalities:

35

• Users log in to the server by providing the correct user information: User Id,

Password, email address, and IP address of the server. If log in fails, the

system prompts user to log in again.

• Users can receive new messages right after logging in successfully.

• Users send emails to any valid asu.edu email address.

• Save/Delete emails to/from the local database.

• The HTTP protocol is used to connect with the J2EE server.

2. Compile the EmailMIDlet.java to EmailMIDlet.class. Use "javac" command with

several options to compile the source code. Although the command is the same as

used for the J2SE compilation, the classpath is different. So the classpath should

be set correctly.

3. Pre-verify the class file. All MIDlet classes must be pre-verified before running

on a device. The Java virtual machine for J2SE performs bytecode verification.

But in the KVM, the verification has to be done manually before deployment

because of the size constraints. Pre-verifying is the Java security model in J2ME.

Pre-verifying uses the "preverify" command.

4. Package an EmailMIDlet.jar file. Using "jar" command to compress all the

classes into a jar file.

5. Make the EmailMIDlet.jad manifest file. Using a text editor to create a jad file

called EmailMIDlet.jad. Target device can use this manifest file to check some

pre-downloaded properties in order to make sure the MIDlet could fit into the

target device for downloading. Properties include MIDlet-Name, MIDlet-Version,

MIDlet-Vendor, MIDlet-Profile, MIDlet-Configuration, and MIDlet-<n>, etc.

36

6. Converting the EmailMIDlet.jad to the EmailMIDlet.prc. PRC stands for Palm

Resource Code. PRC file is an executable file for Palm OS based MIDP

application. With the converter tool, a JAR file and a JAD file can be converted

into a .prc file.

7. Deploy the EmailMIDlet.prc to the POSE or a wireless device. For POSE, first,

install the application runtime environment MIDP.prc that supports the MIDP

Palm OS devices and make sure that the Java Preference setting-- Networking is

set to "Enabled"; second, install EmailMIDlet.prc and make sure that the POSE

property-- communications is set to "Redirec NetLib calls to host TCP/IP". For a

real device, use HotSync application to install the .prc file to that Palm PDA [1].

3.3.3 Web client: coding, packaging, and deployment

The enip.html is a simple HTML file running on the web browser for users to

input user id, password, and email address. The PageTop.html is an HTML file which is

included in each HTML and JSP file to display the time and greeting. The JSP files

dynamically create other HTML files.

3.3.4 Server side: coding, packaging, and deployment

Server side applications use J2EE technology. The packaging and deployment of the

applications use the deployment tool comes with the J2EE reference implementation. The

steps for the server side applications are listed below.

1. Write source codes for web components and business components. Web

component applications include servlet (EmailServlet.java) and JSP pages

(WebClient.jsp, content.jsp, Delete.jsp, Send.jsp). EJB components include Login

EJB, SendReceive EJB, and LocalEmail EJB.

37

o Servlets and JSP pages execute in a web server and respond to HTTP

requests from clients. EmailServlet.java is a servlet file that is used for

getting requests from Palm users or web browser users and for sending

responses to both clients. For Palm clients, EmailServlet.java connects

with three EJBs to accomplish the sending, receiving, deleting, and saving

of emails. For web browser clients, EmailServlet.java forwards the

requests to WebClient.jsp to accomplish the above processes. JSP pages

cooperate with servlet and EJBs to get the results and display them to the

web clients.

o There are three EJBs used in the application. Each of them includes the

bean file, the local/remote interface file, and the home interface file. The

business logics are accomplished through these EJBs. They get

information from the client through servlet, jsp pages, connect with IMAP

email server, connect with database, and send results back to servlet or jsp

pages.

2. Compile and build the source codes. Using Ant build tool to compile and build

the source codes.

3. Package all components to a J2EE application and deploy the application to a

server. Packaging a J2EE application includes creating the bean’s deployment

descriptor, packaging the deployment descriptor and the bean’s class file into an

EJB JAR file, and inserting the EJB JAR file into the Enterprise Achieve (EAR)

file. Then deploy the .ear file into a J2EE server. Deployment descriptor is an

XML file provided with each module and application that describes how they

38

should be deployed. Developers can do packaging with a deployment tool or

manually. The following 16 figures (Figure 14 – Figure 29) demonstrate the

procedure of packaging the EmailApp.ear file and deploying it to a server using a

deployment tool.

First, start the J2EE server and open the application deployment tool. "localhost" is

the server name. In Figure 14, no application has been created yet.

Figure 14 Start the application deployment tool

Under the "Files" fold at the left pane of the tool, a J2EE application named

EmailApp.ear is created. (See Figure 15).

39

Figure 15 EmailApp.ear created ear.gif

Figure 16 shows the current deployment descriptor of the EmailApp.ear, which is

automatically created by the tool.

Figure 16 Current Descriptor of the EmailApp.ear ear1dec.gif

40

Next, package a SessionJAR in the EmailApp.ear application (See Figure 17).

Figure 17 Create the SessionJAR in the applicaiton

Two session beans are in the SessionJAR: LoginEJB and SendReceiveEmailEJB

(See Figure 18). Beans' class files and an util class file are packaged into the JAR file.

Figure 18 Two session beans in the SessionJAR

41

Next, create an EntityJAR in the EmailApp.ear application (See Figure 19).

Figure 19 Create the EntityJAR in the application

Figure 20 shows that LocalEmailEJB entity bean is in the Entity JAR. The three

class files and an util class file are packaged in the EntityJAR.

Figure 20 An entity bean is in the EntityJAR EntityJAR2.gif

42

Figure 21 shows that LocalEmailEJB entity bean is a CMP entity bean. It has 5

fields: content, date, sender, subject, and receiver. The primary key is the date field,

which is a String type data. "LocalEmail" is the bean's abstract schema name.

Figure 21 CMP entity bean

Figure 22 shows an EJB-QL query for the "findBySender" method written by the

developer.

Figure 22 EQL for finder method

43

Figure 23 displays the SQL query for findBySender() method. The deployment

tool generated the SQL query based on the EJB-QL query.

Figure 23 SQL query for "findBySender" method

The JNDI name of the database is "jdbc/Cloudscape". (See Figure 24)

Figure 24 JNDI name of the database

44

Create a web archive (WAR) file that contains the web components in the

application (See Figure 25). EmailServlet, all JSP pages are packaged in the WAR file.

Figure 25 Create the ClientWAR in the application

EmailApp.ear includes ClientWAR, EntityJAR, and SessionJAR files. (See

Figure 26)

Figure 26EmailApp.ear with its components

45

Figure 27 displays deployment descriptor of EmailApp.ear after packaging all the

components into it. It includes three modules, which are 1 session jar, 1 entity jar, and 1

war file.

Figure 27 The deployment descriptor of the EmailApp.ear

Figure 28 shows the JNDI names for the three EJBs an database.

Figure 28 JNDI Names deploy1.gif

46

Finally, deploy the EmailApp.ear into the server. EmailApp.ear is deployed

successfully (See Figure 29).

Figure 29 Deployment successfully

This chapter presents the procedures of developing the email application. After

coding, compiling, building, packaging and deploying, this email application is ready to

run and users can send and receive emails from a web browser or a PDA. Users can also

use POSE to test the application. In the next chapter, the screen shots of the running

results are displayed, which are the evaluation of this project from a user's view.

Chapter 4 Results

This chapter displays the screen shots of the running results . To run the web

client, point the browser at the following URL: http://localhost:8000/email/enip.html.

Or use the IP address instead of "localhost". For the PDA client (screen shots from

POSE), run the EmailMIDlet, which is installed into the emulator or device. Besides the

user id, password, and email address, PDA client (POSE) has to type in the IP address of

the application server.

Figure 30 shows log in interfaces for web client and PDA client.

Figure 30 Log in interfaces

48

After log in successfully, both clients got an email message (See Figure 31)

Figure 31 Receive an email

Figure 32 shows the detail of the email on web browser and the PDA.

49

Figure 32 read emails

Send an email from the PDA. (See Figure 33)

Figure 33 Send an email from the PDA

Figure 34 shows that the web client and the PDA received the email sent by the PDA.

Figure 34 Receive the email sent by PDA

50

Figure 35 show that the web client replies an email.

Figure 35 Reply to PDA client

The web and the PDA clients receive the email sent by the web client.

Figure 36 Receive email sent by the web client

51

Above screen shots demonstrate some of the functionalities of the email

application. "Delete" is another function of this application. A web client can use the

check box to set a mark for deleting an email. After checking the box, the corresponsive

email will be deleted. For a PDA client, clicking the "Delete" button will finish the

deletion. A PDA client can also search emails by sender's email address or name.

When a new email arrives, the PDA client can get it even if a web client already

reads it. A PDA client gets new emails by checking the date of the email arrival.

This chapter introduces how the email application develops from the requirement

phase to the testing phase. The next chapter will give a conclusion for this project.

52

Chapter 5 Conclusions

5.1 Conclusion

Java 2 Platform technology (J2ME, J2SE, and J2EE) provides a standard

application model for developing the multi-tier, thin-client applications. With this model,

developer only needs to focus on the business logics other than the other infrastructures.

The costs, time, and complexity of developing the application are lowered. Thus, make

the work of the developers, architects, project managers, and users easier and the

application is more portable and scalable.

5.2 Future work

Future work on this project will include the following:

1. Use other J2EE compatible implementations such as WebLogic Server,

WebSphere Application Server, or Oracle 9i Application Server. These are

popular J2EE products used in industry, which might be more stable and scalable

than the application server used in this project when the number of clients

increases.

2. Other database systems can be used. For example, Oracle might be better when

the number of users of the email application increase.

3. Security issues: Email systems normally need high-level security protection. Java

security includes language level security, JVM level security, browser level

security, and API level security, etc. Programmers can increase the security level

of the application by using the API level security. Java 2 Platform provides the

53

java.security package for the application security. This package provides the ways

to use security concepts such as certificates, keys, message digests, and digital

signatures.

4. Using other security protocols is another way for addressing security issue. For

example, use the HTTPS protocol (the HTTP protocol over the SSL protocol) for

the client and the server communication.

5. Other functionalities can be added to this application, such as searching emails by

date or a sender's name for the web client, attaching files of various formats, and

creating more folders for users’ convenience, etc.

54

References

[1] ASJ. (2002). The Lurker's Guide to Running Midlets on POSE (Palm OS Emulator)

Retrieved May, 3, 2002, from

http://www.blueboard.com/j2me/notes/2002_6_24.htm

[2] Callaway, Dustin R. (1999). Inside Servlets. Addison Wesley.

[3] Harness E-mail: How It Works. (2002). Retrieved March 1, 2002, from

http://www.learnthenet.com/english/html/20how.htm

[4] Hoff, van Arthur. (n.d. ). Java and Internet Programming Similar to C and C++, but

much simpler. Retrieved January 7, 2003, from

http://www.ddj.com/documents/s=988/ddj9508f/9508f.htm

[5] IBM. (n.d). Entity Bean lifecycle. Retrieved December 6, 2002 from

http://www.ibm.com/servers/eserver/iseries/software/websphere/wsappserver/doc

s/as400v35/docs/ejbentlf.html

[6] Java Community Process. (n.d. ). Community Development of Java Technology

Specifications. Retrieved February 1, 2002 from

http://www.jcp.org/en/home/index

[7] PalmSource. (n.d. ). Palm OS Emulator. Retrieved September 19, 2001, from

http://www.palmos.com/dev/tools/emulator/

[8] Prasks Resources on Sun Certified Java Architect Enterprise Java Technology

Architecture. (2000). Retrieved January 10,2003, from

http://prasks.webahn.com/architect/scja.html same as 16

55

[9] Sun Microsystems. (n.d. ). JavaTM 2 Enterprise Edition. Retrieved December 1, 2002,

from http://developer.java.sun.com/developer/Books/j2ee

[10] Sun Microsystems. (n.d. ). JavaTM 2 Platform, Enterprise Edition (J2EETM)

Introduction. Retrieved September 1, 2002 from http://java.sun.com/j2ee/

[11] Sun Microsystems. (2002). Java™ 2 Platform Enterprise Edition Specification,

v1.4. Retrieved February 9, 2003 from http://java.sun.com/j2ee/j2ee-1_4-pfd2-

spec.pdf

[12] Sun Microsystems. (n.d. ). JavaTM 2 Platform, Enterprise Edition J2EETM .

Retrieved October 1, 2002, from http://java.sun.com/j2ee/compatibility.html

[13] Sun Microsystems. (n.d. ). J2EETM Connector Architecture. Retrieved January 15,

2003, from http://java.sun.com/j2ee/connector/

[14] Sun Microsystems. (n.d. ). Download and Specification. Retrieved December 1,

2002, from http://java.sun.com/j2ee/download.html#connectorspec

[15] Sun Microsystems. (n.d. ). J2EETM Client Provisioning. Retrieved January 1, 2003

from http://java.sun.com/j2ee/provisioning

[16] Sun Microsystems. (2002). J2EETM Tutorial. Retrieved April, 2002, from

http://java.sun.com/j2ee/tutorial/ same as 19

[17] Sun Microsystems. (n.d. ). JavaTM 2 Platform, Micro Edition (J2METM). Retrieved

February 1, 2003 from http://java.sun.com/j2me/j2me-ds.pdf

[18] Tremblett, Paul. (2001). Instant Enterprise JavaBeans. McGraw-Hill. Same as 14

[19] Yong, Xue. (2003). Web Container. Retrieved December 18, 2003, from London

Metropolitan University Computing (London North Campus), Department of

Computing, UK site: http://www.unl.ac.uk/simt/im269/week3/week3-part4.pdf