Simple Mail Transfer Protocol

Simple Mail Transfer Protocol
Abstract
The objective of this project is to access messages from more than one computer,
which is connected to smtp and to provide extremely importance to messaging and
use of multiple computers increase. It is fully compatible with Internet messaging
standards like MIME (Multiple Purpose Mail Extension) protocol, which allow
message access and management from more than one computer without reliance on
less efficient file access protocol.
This project provides a client e-mail Graphical User Interface program to access
remote message stores as if they were local.
The above project provides all the facilities to a user, which are similar to that of
Outlook for the different messaging concepts using from mailing purpose. Using
this JAVAMAIL API a user is capable of using different mail protocols for
retrieving, composing, forwarding and deleting the selected mails for his inbox. User
can even send mails with attachments whenever he wants.
The JAVA MAIL CLIENT is developed as a Graphical User Interface, which
navigates the user through out the program to perform any task. The main intension
of this project development is to get a good insight on rwal-time applications like
Yahoo mail and Gmail.
Narayana Engineering College -NLR 1

Table of Content Page No
1. Introduction……………………………………………………………….4
Scope of the project 4
Key goals of the project 4
Description of the project 5-6
Project Architecture 7
Introduction to modules 8
2. System Analysis 9
Introduction 9
2.1 Proposed System 10
2.2 Feasibility study 11
Technical Feasibility 11
Operational Feasibility 11
Economic Feasibility 12
2.3 Software Requirement Specification 13
2.4 Requirement specification 13
2.4.1 Introduction 13
2.4.2 Functional Requirements 14
2.5 Data Flow Diagram 15
Data flow Diagram For Login 16
Data Flow Diagram For Signup 17
Composing a message and sending 18
Change password 19
Check mail 20
3. System Design 21

3.1 Introduction 21
3.2 Design Methodology 22
4. UML Diagrams 23-33
5. System Implementation 34
5.1 Introduction 34
5.2 Organization Impact 36
5.3 User Management Assessment 36
6. System Testing 37
6.1 Introduction 37
6.2 Software Testing Technology 38
6.3 Software Testing Strategies 40
6.4 Validation Testing 41-46
7. Technology Implementation 47
Java Introduction 47-49
Over view of j2ee 50-53
J2EE Architecture 54
Over view of jsp 55
Over view of Servlets 57
Over view of JDBC 58-59
Java Mail API 60-83
8. Experimental Results 84-101
9. Conclusion 102
10. Bibliography 103

1. INTRODUCTION
SCOPE OF THE PROJECT:
The SMTP is project, which provides the Graphical User Interface to
the user who is connected to the JAMES SERVER. The above project provides
all the necessary and various protocols to interact with the mail server and access
his email account with all the facilities.
KEY GOALS OF THIS PROJECT:
 Fully compatible with Internet messaging standards, e.g. MIME (Multiple
Purpose Mail Extension).
 Allow message access and management from more than one computer.
 Client needs no knowledge about the server's file store format.
 The protocol checking for new messages; permanently removing messages;
setting and clearing flags; server-based RFC-822 and MIME parsing (so clients
don't need to), and searching; and selective fetching of message attributes, texts,
and portions thereof for efficiency.

DESCRIPTION OF THE PROJECT:
As the above project is developed using JAVA Html, Servlets, JSP it provides a user
friendly graphical user interface which navigates him through out the program by
providing various task related to internet mail messaging facilities when connected to
a mail server.
It provides the user to perform various email messaging operation like checking,
composing, deleting and forward his email. It provides all the facilities, which are
provided to the user by Outlook to access his account.
The various protocols available in JAVA MAIL API package are implemented to
access the users account using this project.
Present project is capable of configuring the authorized user to the mail server,
which has the entire control over the users account management.
In the above project the client is kept unknown with the server mechanism and the
implementation of the various protocols. Due to this feature the authorized user can
easy communicate with respective mail server and access his accounts with all the
facilities, which are provided to him.
The authorized user is capable of accessing his account in similar fashion with
all the facilities that are provided as in Outlook.
The main objective of this project is to specializing the Mailing System from client-
server architecture. So we can decrease the burden on the server by creating a special
server for Mailing System and we can improve Mail Management services.
In the traditional 2-tier architecture there exist only server and client. In most
cases the server was only a data base server that can only offer data. Therefore
majority of the business logic i.e., validations et., had to be placed on the clients

system. This makes maintenance expensive. Such clients are called as ‘fat clients’.
This also means that every client has to be trained as to how to use the application.
Increased network load results since the actual processing of the data takes place on
the remote client; the data has to be transported over the network. As a rule this leads
to increased network stress.
The server, not processed, only sends data. Stored-procedures are a form of
assistance given by the database provider. But they have a limited application field
and a proprietary nature. Application logic can’t be reused because it is bound to an
individual PC-program.
To offset the above-mentioned problems, 3-tier architecture is proposed. A middle
tier called application server (Mailing Server) is introduced. This is also known as
the Web server.
The following are the advantages in the web server:
 Clear separation of Mail control and database for Emails. Through this separation
more control will be there on Mails from different clients.
 Security is Improved
 Reducing The Burden on main Server.
 Dynamic load balancing: if bottlenecks in terms of performance occur, the server
process can be moved to other servers at runtime.
 Change management: It is easy - and faster - to exchange a component on the
server than to furnish numerous PCs with new program versions.

PROJECT ARCHITECTURE
SCOPE:
NETWORK ARCHITECTURE

INTRODUCTION TO MODULES:
The SMTP project is mainly divided into two modules:
Namely
(i) GUI Interaction Module
(ii) Main Mechanism Module
(i) GUI Interaction Module:
The purpose of this module is to prevent the unauthorized user to interact with the
connected mail server. This module is developed in graphical user interface by using
JSP and HTML. This module is provided with the facility called password
authentication. Due to this facility this module impose the user to enter his username
and password to communicate with the respective mail server. If the user is an
unauthorized then this module throws an exception and doesn’t connect that user to
the mail server and if the user is an authorized one then this module connects the
client with the mail server and provides all the Internet Messaging facilities by
accessing his inbox by using next module.
(ii) Main Mechanism Module:
The purpose of this module is to provide the user with all the Internet Messaging
facilities, which are provided with the JAVA MAIL API package. This package
provides the user with various sets of abstract classes defining objects that comprise
a mail system. The API defines classes like Message, Store and Transport. The API
can be extended and can be sub classed to provide new protocols and to add
functionality when necessary. In addition, the API provides concrete subclasses of
the abstract classes. These subclasses, including Mime Message and MimeBodyPart,
implement widely used Internet mail protocols and conform to specifications
RFC822 and RFC2045. They are ready to be used in application development.

1. SYSTEM ANALYSIS
INTRODUCTION:
Requirement Analysis is done in order to understand the problem the
software system is to solve. The problem could be automating an existing manual
process, developing a new automated system, or a combination of the two. For large
systems that have many feature, and that need to perform many different tasks,
understanding the requirement of the system is a major task. The emphasis in
requirements analysis is on identifying what is needed from the system, not how the
system will achieve its goals.
There are two major activities in this phase: problem understanding or
analysis and requirements specification. In the problem analysis, the analyst has to
understand the problem and its context. Such analysis, typically requires a through
understand is needed of the important data entities in the system, major centers
where action is taken the purpose of the different actions that are performed, and the
inputs and outputs.
Understanding the existing system is usually just the starting activity in
problem analysis, and it is relatively simple. The goal of this activity is to
understand the requirements of the new system that is to be developed.
Understanding the properties of system that does not exist is more difficult and
requires creative thinking. Once the problem is analyzed and the essential
understood, the requirements must be specified in the requirement specification.

PROPOSED SYSTEM:
The objective of the system is to communicate the authorized user with mail
server and access his inbox with all the Internet Messaging facilities.
The Feature which is included are in the below list:
 Inbox.
 Outbox
.
 Checking mails.
 Composing, forwarding mails with attachment facility.
 Deleting the unnecessary mails.
The main advantage of this project is that the client is kept unknown from the server
side mechanism by providing user-friendly graphical interface to access his mails
from the connected SMTP.
The proposed system supports all the protocols, which are provided by the JAVA
MAIL API package to provide all the necessary Internet Messaging facilities to the
authorized user. It also provides the password authentication facilities, which is
throws an exception whenever the unauthorized user wants to communicate with the
connected SMTP. It also provides the user to configure his existing account with the
SMTP.

FEASIBILITY STUDY:
TECHINICAL FEASIBILITY:
Evaluating the technical feasibility is the trickiest part of a feasibility study.
This is because, at this point of time, a detailed design of the system is not available,
making it difficult to access issues like performance, costs on (on account of the kind
of technology to be deployed) etc. A number of issues have to be considered while
doing a technical analysis.
i).Understand the different technologies involved in the proposed system:
Before commencing the project, we have to be very clear about what are the
technologies that are to be required for the development of the new system.
ii).Find out whether the organization currently possesses the required
technologies:
Is the required technology available with the organization?
If so is the capacity sufficient?
For instance – “Will the current printer be able to handle the new
reports and forms required for the new system?”
OPERATIONAL FEASIBILITY:
Proposed projects are beneficial only if they can be turned into information
systems that will meet the organizations operating requirements. Simply stated, this
test of feasibility asks if the system will work when it is developed and installed. Are
there major barriers to Implementation? Here are questions that will help test the
operational feasibility of a project:
 Is there sufficient support for the project from management from users?
If the current system is well liked and used to the extent that persons will not be able
to see reasons for change, there may be resistance.
 Are the current business methods acceptable to the user?

If they are not, Users may welcome a change that will bring about a more operational
and useful system.
 Have the users been involved in the planning and development of the project?
Early involvement reduces the chances of resistance to the system and in general,
and increases the likelihood of a successful project.
Since the proposed system was to help reduce the hardships encountered in the
existing manual system, the new system was considered to be operationally feasible.
ECONOMIC FEASIBILITY:
Economic feasibility attempts to weigh the costs of developing and implementing
a new system, against the benefits that would accumulate from having the new
system in place. This feasibility study gives the top management the economic
justification for the new system.
A simple economic analysis which gives the actual comparison of costs and
benefits are much more meaningful in this case. In addition, this proves to be a
useful point of reference to compare actual costs as the project progresses. There
could be various types of intangible benefits on account of automation. These could
include increased customer satisfaction, improvement in product quality, better
decision making, timeliness of information, expediting activities, improved accuracy
of operations, better documentation and record keeping, faster retrieval of
information and better employee morale.

SOFTWARE REQUIREMENTS SPECIFICATION
REQUIREMENT SPECIFICATION:
The above client project is designed to interact with the smtp as well as with
various Internet Messaging mail techniques for the authorized user.
2.4.1 INTRODUCTION
Purpose: The main purpose for preparing this document is to give a
general insight into the analysis and requirements of the existing system or situation
and for determining the operational characteristics of the system.
Scope: This Document plays a vital role in the Software Development
Life Cycle (SDLC) as it describes the complete requirements of the system. It is
meant for use by the developers and will be the basis for testing the system. Any
changes made to the requirements in the future will have to go through formal
change approval process.
Developers Responsibilities Overview:
The developer is responsible for:
 Developing the system, which meets the SRS and solving all the requirements of
the system?
 Demonstrating the system and installing the system at client's location after the
acceptance testing is successful.
 Submitting the required user manual describing the system interfaces to work on
it and also the documents of the system.
 Conducting any user training that might be needed for using the system.
 Maintaining the system for a period of one year after installation.

2.4. 2 FUNCTIONAL REQUIREMENTS:
Inputs: The major inputs for the JAVA MAIL CLIENT can be categorized module-
wise. Basically the user has to provide the correct user name and the password to
communicate with the smtp. If once the user provides the correct data then user will
be provided with all the Internet Mail Messaging tools to access his account.
Outputs: The major outputs of the system are to provide the Graphical User
Interface with all the necessary Internet Mail Messaging facilities to the authorized
user.
2.4.3 PERFORMANCE REQUIREMENTS:
Performance is measured in terms different facilities provided to the
authorized user. Since it provides GUI it should generate and perform all the events
as specified.
2.4.4 SOFTWARE AND HARDWARE SPECIFICATIONS
Hardware:
Processor : Intel Pentium III or higher.
Ram : 256 MB or more.
Hard Disk : 16GB HDD
Software:
Java : j2sdk1.4.1
Web-Server : Tomcat4.1
Mail-Server : James-2.1.3
Utility : Telnet
Operating System: Windows 95/98/NT/2000/ME/X.

2.5 DATA FLOW DIAGRAM:
A DATA FLOW DIAGRAM is graphical representation that
depicts information flow and the transforms that are applied as data move from input
to output. Information is transformed as it follows through a computer –based
system. The system accepts input in variety of forms applies hardware ,software and
human element to transform it and produces output in a variety of forms.
The data follow diagram may be used to represent a system or software at
any level abstraction. Input may be control signal transmitted by a transducer a series
of numbers typed by a human operator, a packet of information transmitted on a
network link, or a voluminous data file retrieved from a secondary storage.
RECTANGLE : represent the external entity.
CIRCLE : Representations a process transform.
ARROW : representation one or more data items.

LOGIN:
When a registered client enters his name and password they are compared
to the one’s stored in the database. If both the name and password matches, then
the next form is displayed. If the name and password do not match, the user is
asked to login again.
The dataflow diagram for LOGIN is:
Name do not do
not exist exist
If the user
Exists
User
Name
and
passwor
d
Verify
In the
Databas
e
Displa
y next
form
Logi
n
agai
n

SIGN UP:
If the user is a new one then the form required to register him is
displayed. The user is asked to enter his name and password. Password is retyped.
If both the passwords entered do not match the user has to register again. If both
the passwords match the name is checked with the names stored in the database. If
the same name exists the user is asked to register again with a new name. If the
client successfully registers himself ,the name and password are stored in the
database.
The data flow diagram for SIGN UP is
If not
If same
Name exists
Retype
passwor
d
Enter
name
and
passwor
d
Verify
name in
database
Regist
er
again
Insert
into
database
Displa
y next
form

COMPOSE:
When the user successfully registers or logins the form to
compose or check mail is displayed. In compose form; the sender should enter
the name of the receiver, the subject of the message, and the contents of the
message. The receiver name is compared with the names of the registered
users in the database. If any name matches with the name of the receiver the
receiver name, the subject of the mail, the contents of the mail are stored in a
separate table in the database .
The dataflow diagram for composing a message and sending it is:
Receiver
Not exist If receiver
Exists
Enter
receive
r name
Enter
subject
and
messag
e
Check
whethe
r
receive
r exist
Update
databas
e
Display
menu
options

CHANGE PASSWORD:
When a client wants to change the password, the client has to enter
the new password and retype it. If both are same the database is updated with the
new password. If not the server asks the client to enter the password again.
If both matches
ifnot
Enter
new
passwor
d
Retype
passwor
d
Update
databas
e
Enter
passwor
d again

CHECKMAIL:
When the client wants to check his mails, he opens his INBOX.
In the inbox form, the senders name, the subject and the msgid is present. To
view a message, the client should enter the id of the corresponding message.
Then the message is displayed. In that form when the option BACK is clicked,
the client goes to the check mail form again.
if not
present
If id do not
If exist exist
Id sent
to
server
side
Ente
r the
msgi
d
Server
checks
in data
base
No
msg
exist
Msg is
sent to
client

2. SYSTEM DESIGN
3.1 INTRODUCTION:
The purpose of the design phase is to plan a solution of the problem specified by
the requirement document. This phase is the first step in moving from the problem
domain to the solution domain. In other words, starting with what is needed, design
takes us toward how to satisfy the needs. The design of a system is perhaps the most
critical factor affection the quality of the software; it has a manor impact on the later
phase, particularly testing, maintenance. The output of this phase is the design
document. This document is similar to a blueprint for the solution and is used later
during implementation, testing and maintenance. The design activity is often divided
into two separate phases System Design and Detailed Design.
System Design also called top-level design aims to identify the modules that
should be in the system, the specifications of this modules, and how they interact
with each other to produce the desired results. At the end of the system design all
the major data structures, file formats, output formats, and the major modules in the
system and their specifications are decided.
During, Detailed Design, the internal logic of each of the modules specified
in system design is decided. During this phase, the detail of the data of a module is
usually specified in a high-level design description language, which is independent
of the target language in which the software will eventually be implemented.
In system design the focus is on identifying the modules, where as during
detailed design the focus is on designing the logic for each of the modules. In other

works, in system design the attention is on what components are needed, while in
detailed design how the components can be implemented in software is the issue.
3.2 DESIGN METHODOLOGY:
The two basic modern design strategies employed in software design are
1. Top Down Design
2. Bottom Up Design
Top down Design is basically a decomposition process, which focuses on
the flow of control. At later stages it concern itself with the code production. The
first step is to study the overall aspects of the tasks at hand and to break it into a
number of independent modules. The second step is to break each one of these
modules further into independent sub-modules. The process is repeated one to
obtain modules, which are small enough to group mentally and to code in a
straightforward manner. One important feature is that each level that details of the
Designs at the lower level are hidden. Only the necessary data and control that
must be called back and forth over the interface are defined.
In a bottom-up design one first identifies and investigates parts of design that are
most difficult and necessary designed decision are made the remainder of the design
is tailored to fit around the design already chose for crucial part. It vaguely
represents a synthesis process explained in previous section.
One storage point of the top-down method is that it postpones details of the
decision until the last stage of the decision. It allows making small design changes
when the design is half way through.

4.UML Diagrams:
INTRODUCTION TO UML:
The Unified Modeling Language (UML) is a standard language for writing
software blueprints. The UML may be used to visualize, specify, construct and
document the artifacts of a software-intensive system.
The UML is appropriate for modeling systems ranging from enterprises
information systems to distributed Web-based applications and even to hard real time
embedded systems.
The UML is only language and so is just one part of a software development
method. The UML is process independent, although optimally it should be used in a
process that is driven, architecture-centric, iterative, and incremental. The UML is a
language for Visualizing, Specifying, Constructing, and documenting the artifacts of
a software- intensive system.
A modeling language is a language whose vocabulary and rules focus on the
conceptual and physical representations of a system. A modeling language such as
the UML is thus a standard language for software blueprints.
The UML is a graphical language, which consists of all interesting systems; there are
also different structures that can transcend what can be represented in a programming
language.
The UML is more than just bunch of graphical symbols. Rather, behind each
symbol in the UML notation is a well-defined semantics.

The vocabulary of the UML encompasses three kinds of building blocks:
 Things
 Relationships
 Diagrams
Things are the abstractions that are first-class citizens in a model; relationships tie
these together; diagrams group interesting collection of things.
Things in the UML:
There are four kinds of things in the UML:
 Structural Things
 Behavioral Things
 Grouping Things
 Annotational Things
1. Structural Things: Structural things are the nouns of UML models. These are
the mostly static parts of a model, representing elements that are either conceptual or
physical. In all, there are seven kinds of structural things.
First, a class is a description of a set of objects that share the same attributes,
relationships, and semantics. A class implements one or more interfaces.
Graphically, a class is rendered as a rectangle, usually including its name, attributes
and operations, as figure below.

Window
Origin
Size
Open ()
Close ()
Move ()
Display ()
Second, an interface is a collection of operations that specify a service of a class or
component. An interface therefore describes the externally visible behavior of
element. It also defines a set of operations specifications (that is, their signature) but
never a set of operation implementations. Graphically, an interface is rendered as a
circle together with its name, as figure below.
ISpelling
Third, collaboration defines an interaction and is a society of roles and other
elements that work together to provide some cooperative behavior that’s bigger than
the sum of all the elements. Therefore it represents the implementation of patterns
that make up a system. Graphically, collaboration is rendered as an ellipse with
dashed lines, usually only its name, as figure below.
Chain of
Responsibility
Fourth, a use case is a description of a set sequence of actions that a system
performs that yields an observable result of value to a particular actor. A use case is

realized by collaboration. Graphically, a use case is rendered as an ellipse with solid
lines, usually including only its name, as figure below.
Place order
Fifth, an active class is a class whose objects own one or more processors or
threads and therefore can initiate control activity. An active class is just like a class
except that its objects represent elements whose behavior is concurrent with other
elements. Graphically, an active class is rendered just like a class, but with heavy
lines, usually its name, attributes, and operations, as figure below.
Event Manager
Suspend ()
Flush ()
Sixth, a component is a physical and replaceable part of a system that conforms to
and provides that realization of a set of interfaces. A component typically represents
the physical packaging of otherwise logical elements, such as classes, interfaces, and
collaboration. Graphically, a component is rendered as a rectangle with tabs, usually
including only its name, as figure below.
Orderform java
Seventh, a node is a physical element that exists at run time and represents a
computational resources, generally having at least some memory and often,
processing capability. Graphically, a node is rendered as a cube, usually including
only its name, as figure below.

Server
2. Behavioral things – Behavioral things are the dynamic parts of UML, models.
These are the verbs of a model, representing behavior over time and space. In all,
there are two primary kinds of behavioral things.
First, an interaction is a behavior that comprises a set of message exchanged among
a set of objects which a particular context to accomplish a specific purpose. An
interaction involves a number of other elements, including messages, action
sequences and links. Graphically, a message is rendered as a directed line, almost
always including the name of its operation, as figure below.
Display
Second, a state machine is a behavior that specifies the sequences of states an
object or an interaction goes through during the lifetime in response to events,
together with its responses to those events. A state machine involves a number of
other elements, including states, transitions, events, and activities. Graphically, a
state is rendered as a rounded rectangle angle, usually including its name and its
substates.
Waiting

1. Grouping Things – Grouping things are the organizational parts of UML
models. There are the boxes into which a model can be decomposed. In all,
there is one primary kind of grouping thing namely, packages.
Business rules
4. Annotational Things- Annotational things are the explanatory parts of UML
models. These are the comments you may apply to describe, illuminate, and remark
about any elements in a model. Graphically, a node is rendered as a rectangle with
the dog-earer corner, together with a textual or graphical comment, as figure below.
Return copy ofself
Relationships in the UML
There are four kinds of relationship in the UML:
 Dependency
 Association
 Generalization
 Realization

1. Dependency:
Dependency is a semantic relationship between tow things in which a
change to one thing (the independent thing) may affect the other thing (the dependent
thing). Graphically, a dependency is rendered as a dashed line, and occasionally
including label, as figure.
2. Association:
Association is a structural relationship that describes a set of links, a link
being a connection among objects. Graphically, an association is rendered as a solid
line, possibly directed, occasionally including a label, and often containing other
adornments, such as multiplicity and role names, as figure below.
0.1
Employer employee
3. Generalization:
Generalization is a specialization relationship in which objects of the
specialized elements (the child) are substitutable for objects of the generalized
element (the parent). Graphically, a generalization relationship is rendered as a solid
line with a hollow arrowhead pointing to the parent, as figure below.
1. Realization:
Realization is a semantic relationship between classifiers, wherein one
classifier specifies a contrast that another classifier guarantees to carry out.
Graphically, a realization is rendered as a cross between a generalization and a
dependency relationship, as figure below.

Diagrams in the UML:
A diagram is the graphical presentation of a set of elements, most often rendered as
a completed graph of vertices (things) and arcs (relationships). The UML includes
nine such diagrams:
 Class diagram, a class diagram shows a set of classes, interface,
collaborations and their relationships.
1. Object diagram, an object diagram shows a set of objects and their
relationships.
2. Use case diagram, a use diagram shows a set of use cases and actors
(a special kind of class) and their relationships.
3. Sequence diagram, a sequence diagram is kinds of interaction. An
interaction diagram shows an interaction, consisting of a set of object and their
relationships, including messages that may be dispatched among them. A sequence
diagram is an interaction diagram that emphasizes the time ordering of messages.
4. Collaboration diagram, a collaboration diagram is an interaction
diagram that emphasizes the structural organization of the objects that send and
receive messages.
5. Statechart diagram, a statechart diagram shows a state machine,
consisting of states, transitions, events, and activities.

6. Activity diagram, an activity diagram is a special kind of a state
chart diagram that shows the flow from activity within a system.
7. Component diagram, a component diagram shows the organizations
and dependencies among a set of component.
8. Deployment diagram, a deployment diagram shows the configuration of run time
processing nodes and the components that live on them.
Use Case Diagram:

User
downloadMail
delete
reply
createAccount
composeMail
checkMailList
forwardMail
viewMails
login
<includes>
<includes>
<includes>
<includes>
Class Diagram:

user
mailId
password
login()
checkmail()
viewmail()
composemail()
forward()
reply()
downloadmail()
delete()
WebServer
takeRequest()
forwardRequest()
receiveResponse()
sendResponse()
WebBrowser
takeRequest()
sendRequest()
receiveResponse()
sendResponse()
**
*
*
MailServer
createAccount()
storeMails()
sendMails()
configure()
1*** * 1
*
*
Sequence Diagram:

invalidateSession()
: : User : : Web
Browser
: : Web Server : : Mail Server
login()
forwardDetails() sendDetails()
verifyWithUserAccount
sendReply()forwardReply()
displayPage()
checkMails() forwardDetails() sendRequest()
sendMails()
selectMails()
forwardMails()
displayMails()
composeMails()
forwardDetails()
sendDetails()
sentMsg()
forwardSentMsg()
displaySucessMsg()
replyMail()
forward()
sendDetails() forwardDetails()
sendDetails() forwardDetails()
storeAndForward()
deleteMail()
sendDetails()
forwardDetails()
delete()
downloadMail() sendMailDetails()
forwardmailDetails()
getMail()
getMail()
generatePDF()
sendPDF()
downloadPDF()
logout() sendDetails()
sendResponse()
displayPage()

5. SYSTEM IMPLEMENTATION
5.1 INTRODUCTION:
Implementation is the stage where the theoretical design is turned in to
working system. The most crucial stage is achieving a new successful system and in
giving confidence on the new system for the users that it will work efficiently and
effectively.
The system can be implemented only after through testing is done and if it found
to work according to the specification.
It involves careful planning, investigation of the current system and its constraints on
implementation, design of methods to achieve the change over and an evaluation of
change over methods a part from planning. Two major tasks of preparing the
implementation are education and training of the users and testing of the system.
The more complex the system being implemented, the more involved will be the
systems analysis and design effort required just for implementation.
The implementation phase comprises of several activities. The required hardware
and software acquisition is carried out. The System may require some hardware and
software acquisition is carried out. The system may require some software to be
developed. For this, programs are written and tested. The user then changes over to
his new fully tested system and the old system is discontinued.
Implementation is the process of having systems personnel check out and put
new equipment in to use, train users, install the new application, and construct any
files of data needed to it.

Depending on the size of the organization that will be involved in using the
application and the risk associated with its use, system developers may choose to test
the operation in only one area of the firm, say in one department or with only one or
two persons. Sometimes they will run the old and new systems together to compare
the results. In still other situations, developers will stop using the old system one-day
and begin using the new one the next. As we will see, each implementation strategy
has its merits, depending on the business situation in which it is considered.
Regardless of the implementation strategy used, developers strive to ensure that the
system’s initial use in trouble-free.
Once installed, applications are often used for many years. However, both the
organization and the users will change, and the environment will be different over
the weeks and months. Therefore, the application will undoubtedly have to be
maintained. Modifications and changes will be made to the software, files, or
procedures to meet the emerging requirements. Since organization systems and the
business environment undergo continual change, the information systems should
keep pace. In this sense, implementation is ongoing process.
Evaluation of the system is performed to identify its strength and weakness. The
actual evaluation can occur along any of the fallowing dimensions.
Operational evaluations assessment of the manner in which the system functions
including ease of use, response time, suitability of information formats, overall
reliability, and level of utilization.

5.2 ORGANIZATION IMPACT:
Identification and measurement of benefits to the organization in such areas as
financial concerns operational efficiency, and competitive impact. Includes impact
on the internal and external information flows.
5.3 USER MANAGEMENT ASSESSMENT:
Evaluation of the development process in accordance with such yardsticks as
overall development time and effort, conformance to budgets and standards, and
other project management criteria. Includes assessment of development and tools.
Unfortunately system evaluation does not always receive the attention it merits.
Where properly managed. However, it provides a great deal of information that can
improve the effectiveness of subsequent application efforts.

6. SYSTEM TESTING
6.1 INTRODUCTION:
The testing phase is an important part of software development .It is the process
of finding process and missing operations and also a complete verification to
determine whether the objectives are met and the user requirement are satisfied.
Software testing is carried out in three steps:
The first includes unit testing, where in each module is tested to provide its
correctness, validity and also determine any missing operations and to verify whether
the objectives have been met. Errors are noted down and corrected immediately. Unit
testing is the important and major part of the project, so errors are rectified easily in
particular module and program clarity is increased. In this project entire system is
divided into several modules and is developed individually, so unit testing is
conducted to individual modules.
The second step includes Integration testing .It need to be case, the software
whose modules when run individually and showing perfect results, will also show
perfect results when run as a whole. The individual modules are clipped under this
major module and tested again and verified the results. This is due to poor
interfacing, which may results in data being lost across the interface .A module can
have inadvertent, adverse effect on any other or on the global data structures, causing
serious problems.

The final step involves validation and testing which determines which
the functions as the user – expected. Here are some modifications were. In the
completion of the project it is satisfied fully by the end user.
6.2 SOFTWARE TESTING TECHNIQUES:
Software Testing is a critical element of software quality assurance and
represents the ultimate review of specification, designing and coding.
Testing Objectives
 is process of executing a program with the intent of finding an error.
 A good test case design is one that has a probability of finding an as yet
undiscovered error.
 A successful test is one that uncovers an as yet undiscovered error.
These above objectives imply a dramatic change in view port.
Testing cannot show the absence no defects, it can only show that software errors are
present.
TEST CASE DESIGN:
Any Engineering product can be tested in one of two ways .
1. White Box Testing: This testing is also called a Glass Box Testing. In this
testing, by knowing the specified function that a product has been designed to
perform the test can be conducted that demonstrates each function is fully
operation at the same time searching for errors in each function. It is a test case

design method that uses the control structure of the procedural design to derive
test cases. Basis path testing is a white box testing.
Basis Path Testing:
 Flow Graph Notation
 Cyclamatic Complexity
 Deriving Test Cases
 Graph matrices.
Control Structure Testing:
 Condition Testing
 Data flow Testing
 Loop testing.
2. Black Box Testing: In this testing by knowing the internal operation of a
product, tests can be conducted to ensure that “all gears mesh”, that is the internal
operation performs according to specification and all internal components have
been adequately exercised. It fundamentally focuses on the functional
requirements of the software.
The steps involved in black box testing case design are

 Graph based testing methods
 Equivalence partitioning
 Boundary value Analysis
 Comparison testing
5.3 SOFTWARE TESTING STRATEGIES:
A software testing strategy provides a road map for the software developer.
Testing is a set of activities that can be planned in advance and conducted
systematically .For this reason a template for software testing a set of steps into
which we can place specific test case design methods should be designed for
software engineering process. Any software testing strategy should have the
fallowing characteristics.
 Testing begins at the module level and works “outward” toward the integration
of the entire computer based system.
 Different testing techniques are appropriate at different points in time.
 The developer of the software and an independent test group conducts testing.
 Testing and Debugging are different activities but debugging must be
accommodated in any testing strategy.
Unit Testing:
Unit testing focuses verification efforts is smallest unit in software design
(module)

2. . Unit test considerations.
3. Unit test procedures.
Integration Testing:
Integration testing is a systematic technique for constructing the program
structure while conducting tests to uncover errors associated with interfacing. There
are two types of integration testing.
1. Top-Down Integration: Top down Integration is an Incremental
approach to construction of program structures.
Modules are integrated by moving downwards throw the control hierarchy
beginning with the main control module.
2. Bottom-Up Integration: Bottom up integration as its name
implies, begins construction and testing with automatic modules.
3. Regression Testing: In this contest of an integration test strategy,
regression testing is the re execution of some subset of test that have already
been conducted to ensure that changes have not propagate unintended side
effects.
5.4 VALIDATION TESTING:
At the culmination of integration testing, software is completely assembled as a
package; interfacing errors have been uncovered and corrected, and a final series of
software tests – validation testing –may begin. Validation can be fine d in many

ways. But a simple application is that validation succeeds when software functions in
a manner that can be reasonably expected by the customer.
Reasonable expectation is defined in the software requirement
specification – a document that describes all users –visible attributes of the
software .The specification contains a section called a “Validation Criteria “.
Information contained in that section forms the basis for a validation testing
approach.
Validation Test Criteria:
Software validation is achieved through a series of Black-Box tests that
demonstrate conformity with requirement .A test plan outlines the classes of tests to
be conducted, and a test procedure defines specific test cases that will be used in an
attempt to uncover errors in conformity with requirements. Both the plan and
procedure are designed to ensure that all functional requirements are satisfied; all
performances requirements are achieved; documentation is correct and human –
engineered; and other requirements are met.
After each validation test case has been conducted, one of the two
possible
Conditions exist: (!) The function or performance characteristics conform to
specification and are accepted. Or (2) a deviation from specification in uncovered
and a deficiency list is created. Deviation or Error discovered at this stage in a
project can rarely be corrected prior to scheduled completion. It is often necessary to
negotiate with the customer to establish a method for resolving deficiencies.
Configuration Review:
An important element of the validation process is a configuration
review.

The intent of the review is to ensure that all elements of the software configuration
have been properly developed. , Are to be catalogued, and have the necessary detail
to support. The maintenance phase of the software cycle. The configuration review
sometimes called an audit.
Alpha and Beta Testing:
It is virtually impossible for a software developer to for see how the customer
will really use a program. Instructions may use may be misinterpreted, strange
combination of data may be regularly used; and output that seemed clear to the tester
may be unintelligible to a user in the field.
When custom software is built for one customer, a series of acceptance tests are
conducted to enable the customer to validate all requirements.
Conducted by the end user rather than the system developer, an
acceptance test can range from an informal “ test drive “ to a planned and
systematically executed series of tests. In fact, acceptance testing can be conducted
over a period of weeks, months, thereby uncovering cumulative errors that might
degrade the system overtime.
If software is developed as a product to be used by many customers, it is
impractical to perform formal acceptance tests with each one. Most software product
builders may use a process called alpha and beta testing to uncover errors that only
the end user seems to be able to find.
A customer conducts the alpha test at the developers site. The software is used in
a natural setting with the developer “ looking over the shoulder “ of the user and
recording error and usage problems. Alpha tests are conducted in controlled
environments.
The beta test is conducted at one or more customer sites at the end of the user of
the software. Unlike alpha testing, the developer is generally more present.

Therefore the beta test is a “live” application of the software in an environment
that cannot be controlled by the developer. The customer records all the problems
that are encountered during the beta testing and reports these to developer at regular
intervals. As a result of problems reported during beta tests, the software developer
make s modification and then prepares for the release of the software product to the
entire customer base.
6. Maintenance and Enhancement:
As the number of computer-based systems, grieve libraries of computer
software began to expand. In the house of developed projects produced tones of
thousand software program statements. Software products purchased from the
outside added hundreds and thousands of new statements. A dark cloud appeared on
the horizon. All of these programs, all of these source statements had to be corrected
when false were detected, modified as user requirements changed, or adapted to new
hardware that was purchased. These activities were collectively called software
maintenance.
The Maintenance phase focuses on change that is associated with error
correction, adaptations required as the software environment evolves, and changes
due to enhancements brought by changing user requirements. Four types of changes
are encountered during maintenance phase.
 Correction
 Adaptation

 Enhancement
 Prevention
Correction:
Even with the best quality assurance activities is lightly that the user will
uncover defects in the software. Corrective maintenance changes the software to
correct defects.
Maintenance is a set of Software Engineering activities that occur after software
has been delivered to the user and put into operation. Software Configuration
Management is a set of tracking and control activities that began when a software
project begins and terminates only when the software is taken out of the operation.
We may define maintenance by describing four activities that are undertaken
after a program is released for use.
 Corrective maintenance
 Adaptive Maintenance
 Perfective Maintenance or Enhancement
 Preventive Maintenance or Re-engineering.
Only about 20 percent of all maintenance work is spent “fixing mistakes “

The maintenance 80 percent are spent adapting existing systems to changes in their
external environment, making enhancements requested by users, and reengineering
an application for use.
Adaptation:
Over time, the original environment (E > G, CPU, operating system,
business rules, external product characteristics) for which the software was
developed is likely to change. Adaptive maintenance results in modification of the
software to accommodate change to its external environment.
Enhancement:
As software is used, the user will recognize additional functions that will
provide benefit. Perceptive maintenance extends the software beyond the original
functional requirements.
Prevention:
Computer Software deteriorates due to change, and because of this, preventive
maintenance, often called Software Engineering, must be conducted to enable the
software to serve the needs of its end users.
In essence, preventive maintenance makes changes to computer diagrams so that
they can be more easily corrected, adapted, and enhanced. Software configuration
Management (SCM) is an umbrella activity that is applied throughput the software
process. SCM activities are developed to
 Identify Change.
 Control chug.
 Ensure that change is being properly implemented.

 Report change to others that may have an interest.
7.Implementation of Technology
JAVA
INTRODUCTION:
JAVA is related to C++, which is a direct descendent of C. Much of the
character of Java is inherited from these two languages. From C Java derives its
syntax. Many of Java’s Object Oriented features were influenced by C++. In fact
several of Java’s defining characteristics come from-or are responses to-its
predecessors. Moreover, the creation of Java was deeply rooted in the process of
refinement and adaptation that has been occurring in computer programming
languages for the past three decades.
Sun Micro systems began a project for software to run TV and VCR sets i.e.,
interactive TV and VCR. A team of software led by James Gosling and other laid
specifications for this project in January 1991. By September 1992 the basic system

was drafted. These interactive sets were called set-top boxes. The hardware called
*7O/S was named as Green and the programming languages as OAK. Later the
language was renamed as JAVA. Meanwhile in 1993, the development of Browser
called MOSAIC led to the widespread use of WWW (World Wide Web), it is
realized by chance that Java was well suited for the web because it was secure and
most importantly Architecture neutral.
In September 1994 a browser called Hot Java was developed. Later Java replaced
the original compiler in C. Hot Java was the first commercial product to developed
entirely in Java. On May 23rd
January 1996, Java is freely distributed on the Internet.
Somewhat surprisingly, the original inputs for Java were not on the Internet.
Instead, the primary motivation was the need for platform independent {i.e.,
architectural neutral} language that could be used to create software to be embedded
in various consumer electronic devices, such as microwave ovens and remote
Controls. The trouble with C and C++ complier targeted for that CPU. The
problem is that compilers are expensive and time consuming to create. An easier and
most cost effective solution was needed.
In an attempt to find such a solution, Gosling and others began work on a
portable platform neutral language that can be used to produce code that would run
on a variety of CPU’s under differing environment. This effort ultimately led to the
creation of Java.
JAVA OVERVIEW:
Java is loosely based on C++ syntax, and is meant to be Object oriented.
It however differs from C++ in many ways. Structure of Java is widely between an
interpreted and compiled language. The Java compiler into ‘Bytecode’ compiles Java
programs, which are secure and portable across different platforms. The technique of
having intermediate code i.e., Byte code solves both the security and the portability
problems. Byte code is highly optimized set of instructions designed to be executed

by virtual machine that the Java run-time system emulates. That is the Java run time
system is an interpreter for Byte code.
These Byte codes are essentially instructions encapsulated in a single byte, to
what is known as Java Virtual Machine (JVM), which resides in standard browser,
any application can have JVM built-in .JVM, which verifies these Byte codes into
machine specific instruction at run time.
Why JAVA is important to the Internet
The Internet helped catapult Java to the forefront of programming, and Java, in
turn, has had a profound effect on the Internet.
The reason for this is quit simple: Java expands the universe of objects that can
move about freely in cyberspace. In a network, two very broad categories of objects
are transmitted between the server and your personal computer: passive information
and dynamic, active programs. For example, when you read your e-mail, you are
viewing passive data. Even when you download a program, the program’s code is still
only passive data until you execute it. However, a second type of object can be
transmitted to your computer, yet is initiated by program. For example, the server to
display properly the data that the server is sending might provide a program.
As desirable as dynamic, networked programs are, they also present serious
problems in the areas of security and portability. Prior to Java, cyberspace was
effectively closed to half the entities that now live there. Java addresses those
concerns and, by doing so, has opened the door to an exciting new form of program:
the applet.
The Applet
 No go-to.
 No operator overloading.

 No automatic coercion {casting}.
 No garbage collection.
An Overview of J2EE:
The following topics describe the J2EE Platform requirements for each kind
of J2EE platform element.
J2EE Application Components:
The J2EE runtime environment defines four application component types that a J2EE
product must support:
Application clients are Java programming language programs that are typically GUI
programs that execute on a desktop computer. Application clients offer a user
experience similar to that of native applications, and have access to all of the
facilities of the J2EE middle tier.
Applets are GUI components that typically execute in a web browser, but can
execute in a variety of other applications or devices that support the applet-
programming model. Applets can be used to provide a powerful user interface for
J2EE applications. Servlets, JSP pages, filters, and web event listeners typically
execute in a web container and may respond to HTTP requests from web clients.

Servlets, JSP pages, and filters may be used to generate HTML pages that are an
application’s user interface. They may also be used to generate XML or other format
data that is consumed by other application components. A special kind of servlet
provides support for web services using the SOAP/HTTP protocol. Servlets, pages
created with the Java Server Pages™ technology, web filters, and web event listeners
are referred to collectively in this specification as “web components.” Web
applications are composed of web components and other data such as HTML pages.
Web components execute in a web container. A web server includes a web container
and other protocol support, security support, and so on, as required by J2EE
specifications. Enterprise Java Beans™ (EJB) components execute in a managed
environment that supports transactions. Enterprise beans typically contain the
business logic for a J2EE application. Enterprise beans may directly provide web
services using the SOAP/HTTP protocol.
J2EE Server Support for Application Components:
The J2EE servers provide deployment, management, and execution support for
conforming application components. Application components can be divided into
three categories according to their dependence on a J2EE server:
Components that are deployed, managed, and executed on a J2EE server. These
components include web components and Enterprise JavaBeans components. See
the separate specifications for these components.
Components that are deployed and managed on a J2EE server, but are loaded to and
executed on a client machine. These components include web resources such as
HTML pages and applets embedded in HTML pages.
Components deployment and management is not completely defined by this
specification. Application Clients fall into this category. Future versions of this
specification may more fully define deployment and management of Application
Clients.
J2EE Containers:
Containers provide the runtime support for J2EE application components. Containers
provide a federated view of the underlying J2EE APIs to the application components.
J2EE application components never interact directly with other J2EE application
components.
J2EE Servers:
Underlying a J2EE container is the server of which it is a part. A J2EE Product
Provider typically implements the J2EE server-side functionality using an existing
transaction processing infrastructure in combination with Java 2 Platform, Standard

Edition (J2SE) technology. The J2EE client functionality is typically built on J2SE
technology.
Resource Adapters:
A resource adapter is a system-level software component that implements network
to an external resource manager. A resource adapter can extend the functionality of
the J2EE platform either by implementing one of the J2EE standard service APIs
(such as a JDBC™ driver), or by defining and implementing a resource adapter for a
connector to an external application system.
Java™ Transaction API (JTA)
The Java Transaction API consists of two parts:
An application-level demarcation interface is used by the container and application
components to demarcate transaction boundaries. An interface between the
transaction manager and a resource manager used at the J2EE SPI level (in a future
release).
RMI-IIOP:
The RMI-IIOP subsystem is composed of APIs that allow for the use of RMI-style
programming that is independent of the underlying protocol, as well as an
implementation of those APIs that supports both the J2SE native RMI protocol
(JRMP) and the CORBA IIOP protocol. J2EE applications can use RMI-IIOP, with
IIOP protocol support, to access CORBA services that are compatible with the RMI
programming restrictions (see the RMI-IIOP spec for details).
JDBC™ API:
The JDBC API is the API for connectivity with relational database systems.
The JDBC API has two parts: an application-level interface used by the application
components to access a database, and a service provider interface to attach a JDBC
driver to the J2EE platform. Support for the service provider interface is not required
in J2EE products.
Java™ Message Service (JMS):
The Java Message Service is a standard API for messaging that supports
reliable point-to-point messaging as well as the publish-subscribe model. This

specification requires a JMS provider that implements both point-to-point messaging
as well as publishes-subscribe messaging.
Java Naming and Directory Interface™ (JNDI):
The JNDI API is the standard API for naming and directory access.
The JNDI API has two parts: an application-level interface used by the application
components to access naming and directory services and a service provider interface
to attach a provider of a naming and directory service.
Java Connector Architecture:
The Connector architecture is a J2EE SPI that allows resource
adapters that support access to Enterprise Information Systems to be plugged in to
any J2EE product. The Connector architecture defines a standard set of system-level
contracts between a J2EE server and a resource adapter.
Security Services:
The Java™ Authentication and Authorization Service (JAAS)
enables services to authenticate and enforce access controls upon users. It
implements a Java technology version of the standard Pluggable Authentication
Module (PAM) framework, and extends the access control architecture of the Java 2
Platform in a compatible fashion to support user-based authorization.
The Java™ Authorization Service Provider Contract for Containers (JACC) defines a
contract between a J2EE application server and an authorization service provider,
allowing custom authorization service providers to be plugged into any J2EE
product.
Web Services:
J2EE provides full support for both clients of web services as well as
web service endpoints. Several Java technologies work together to provide support
for web services. The Java API for XML-based RPC (JAX-RPC) provides support
for web service calls using the SOAP/HTTP protocol. JAX-RPC defines the
mapping between Java classes and XML as used in SOAP RPC calls. The SOAP
with Attachments API for Java (SAAJ) provides support for manipulating low-level
SOAP messages. The Web Services for J2EE specification fully defines the
deployment of web service clients and web service endpoints in J2EE, as well as the
implementation of web service endpoints using enterprise beans. The Java API for
XML Registries (JAXR) provides client access to XML registry servers.
Deployment:

The Java 2 Platform, Enterprise Edition Deployment Specification defines
a contract between deployment tools and J2EE products. The J2EE products provide
plug-in components that run in the deployment tool and allow the deployment tool to
deploy applications into the J2EE product. The deployment tool provides services
used by these plug-in components.
J2EE Architecture:

OVERVIEW OF JSP:

Java Server Pages™ technology is the Java™ technology in the J2EE platform for
building applications containing dynamic Web content such as HTML, DHTML,
XHTML and XML. The Java Server Pages technology enables the authoring of Web
pages that create dynamic content easily but with maximum power and flexibility.
The Java Server Pages technology provides a textual description for the creation of a
response from a request. The technology builds on the following concepts:
Template Data:
Substantial portions of dynamic content are actually fixed. The JSP technology allow
for the natural manipulation of this data.
Addition of Dynamic Data:
The JSP technology allows the addition of dynamic data to the template data in a
way that is simple yet powerful.
Encapsulation of Functionality:
The JSP technology provides two related mechanisms for the encapsulation of
functionality: the standard Java Beans component architecture and the tag library
mechanism.
Good Tool Support:
The JSP technology has features that enable the creation of good authoring tools.
The result is a flexible and powerful server-side technology.
Benefits of the Java Server Pages Technology:
The Java Server Pages technology offers a number of benefits:
Write Once, Run Anywhere™ properties:
The Java Server Pages technology is platform independent, both in its
dynamic Web pages, Web servers, and its underlying server
components. You can author JSP pages on any platform, run them on
any Web server or Web enabled application server, and access them
from any Web browser.

High quality tool support:
The Write Once, Run Anywhere properties of JSP allows the user to choose best-of-
breed tools. Additionally, an explicit goal of the Java Server Pages design is to
enable the creation of high quality portable tools.
Separation of Roles:
JSP supports the separation of roles: developers write components that interact
with server-side objects.
Reuse of components and tag libraries:
The Java Server Pages technology emphasizes the use of reusable components such
as Java Beans™ components, Enterprise Java Beans™ components and tag libraries.
Separation of dynamic and static content:
The Java Server Pages technology enables the separation of static content from
dynamic content that is inserted into the static template.
Support for scripting and actions:
The Java Server Pages technology supports scripting elements as well as actions.
Actions permit the encapsulation of useful functionality in a convenient form that
can also be manipulated by tools; scripts provide a mechanism to glue together this
functionality in a per-page manner.
Web access layer for N-tier enterprise application architecture(s):
The Java Server Pages technology is an integral part of the Java 2 Platform
Enterprise Edition (J2EE), which brings Java technology to enterprise computing.
OVERVIEW OF SERVLETS:
What is a Servlet?

A servlet is a web component, managed by a container that generates dynamic
content. Servlets are small, platform independent Java classes compiled to an
architecture neutral byte code that can be loaded dynamically into and run by a web
server. Servlets interact with web clients via a request response paradigm
implemented by the servlet container. This request-response model is based on the
behavior of the Hypertext Transfer Protocol (HTTP).
What is a Servlet Container?
The servlet container, in conjunction with a web server or application server,
provides the network services over which requests and responses are set, decodes
MIME based requests, and formats MIME based responses. A servlet container also
contains and manages servlets through their lifecycle. A servlet container can either
be built into a host web server or installed as an add-on component to a Web Server
via that server’s native extension API.
Servlet Containers can also be built into or possibly installed into web-enabled
Application Servers. All servlet containers must support HTTP as a protocol for
requests and responses, but may also support other request / response based protocols
such as HTTPS (HTTP over SSL). The minimum required version of the HTTP
specification that a container must implement is HTTP/1.0. It is strongly suggested
that containers implement the HTTP/1.1 specification as well.
A Servlet Container may place security restrictions on the environment that a servlet
can executed In a Java 2 Platform Standard Edition 1.2 (J2SE) or Java 2 Platform
Enterprise Edition 1.3 (J2EE) environment, these restrictions should be placed using
the permission architecture defined by Java 2 Platform. For example, high-end
application servers may limit certain action, such as the creation of a Thread object,
to insure that other components of the container are not negatively impacted.
OVERVIEW OF JDBC:
JDBC drivers implement the interfaces and classes of the JDBC API. The following
sections describe the JDBC driver options that you can use with Web Logic Server.

Types of JDBC Drivers:
Web Logic Server uses the following types of JDBC drivers that work in conjunction
with each other to provide database access: Standard JDBC drivers that provide
database access directly between a Web Logic Server connection pool and the
database. Web Logic Server uses a DBMS vendor-specific JDBC driver, such as the
Web Logic drivers for Oracle and Microsoft SQL Server, to connect to a back-end
database.
Wrapper drivers that provide vendor-neutral database access. A Java client
application can use a wrapper driver to access any database configured in Web Logic
server (via a connection pool). BEA offers three wrapper drivers—RMI, Pool, and
JTS. The Web Logic Server system uses these drivers behind the scenes when you
use a JNDI look-up to get a connection from a connection pool through a data
source. A client application can also use these drivers directly to get a connection
from a connection pool (You can use RMI from external clients and the pool and JTS
from server-side clients only).
However, BEA recommends that you use a data source to get a connection from a
connection pool, rather than using these drivers directly. The middle tier architecture
of Web Logic Server, including data sources and connection pools, allows you to
manage database resources centrally in Web Logic Server. The vendor-neutral
wrapper drivers make it easier to adapt the purchased components to your DBMS
environment and to write more portable code.
Using JDBC Drivers with Web Logic Server:
 Web Logic Server JDBC Drivers
 Web Logic jDriver for Oracle
BEA’s Web Logic jDriver for Oracle is included with the Web Logic Server
distribution. This driver requires an Oracle client installation. The Web Logic jDriver
for Oracle XA driver extends the Web Logic jDriver for Oracle for distributed
transactions.
Type 2 (requires native libraries):
 Web Logic jDriver for Oracle
 Web Logic jDriver for OracleXA

 Third-party drivers, such as the Oracle OCI driver and the IBM DB2 driver
 Between Web Logic Server and DBMS in local and distributed transactions.
Type 3:
 Web Logic RMI Driver
Between an external client and Web Logic Server (connection pool).
Type 4 (pure Java):
 Web Logic jdrivers for Microsoft SQL Server
 Third-party drivers, including: Oracle Thin and Oracle Thin XA drivers
Between Web Logic Server and DBMS in local and distributed transactions.

JAVA MAIL API
The Java Mail API is an optional package (standard extension) for reading,
composing, and sending electronic messages. You use the package to create Mail
User Agent (MUA) type programs, similar to Eudora, Pine, and Microsoft Outlook.
Its main purpose is not for transporting, delivering, and forwarding messages like
sendmail or other Mail Transfer Agent (MTA) type programs. In other words, users
interact with MUA-type programs to read and write emails. MUAs rely on MTAs to
handle the actual delivery.
The JavaMail API is designed to provide protocol-independent access for sending
and receiving messages by dividing the API into two parts:
The first part of the API is the focus of this course. Basically, how to send and
receive messages independent of the provider/protocol.
The second part speaks the protocol-specific languages, like SMTP, POP, IMAP, and
NNTP. With the JavaMail API, in order to communicate with a server, you need a
provider for a protocol. The creation of protocol-specific providers is not covered in
this course as Sun provides a sufficient set for free.
Reviewing Related Protocols
Before looking into the JavaMail API specifics, step back and take a look at the
protocols used with the API. There are basically four that you'll come to know and
love:
 SMTP
 POP
 IMAP
 MIME

You will also run across NNTP and some others. Understanding the basics of all the
protocols will help you understand how to use the JavaMail API. While the API is
designed to be protocol agnostic, you can't overcome the limitations of the underlying
protocols. If a capability isn't supported by a chosen protocol, the JavaMail API doesn't
magically add the capability on top of it. (As you'll soon see, this usually is a problem
when working with POP.)
SMTP:
The Simple Mail Transfer Protocol (SMTP) is the mechanism for delivery of email.
In the context of the JavaMail API, your JavaMail-based program will communicate
with your company or Internet Service Provider's (ISP's) SMTP server. That SMTP
server will relay the message on to the SMTP server of the recipient(s) to eventually
be acquired by the user(s) through POP or IMAP. This does not require your SMTP
server to be an open relay, as authentication is supported, but it is your responsibility
to ensure the SMTP server is configured properly. There is nothing in the JavaMail
API for tasks like configuring a server to relay messages or to add and remove email
accounts.
POP:
POP stands for Post Office Protocol. Currently in version 3, also known as POP3,
RFC 1939 defines this protocol. POP is the mechanism most people on the Internet
use to get their mail. It defines support for a single mailbox for each user. That is all
it does, and that is also the source of most confusion. POP does, not support much of
what people are familiar with when using POP, like the ability to see how many new
mail messages they have, at all. These capabilities are built into programs like
Eudora or Microsoft Outlook, which remember things like the last mail received and
calculate how many are new for you. So, when using the JavaMail API, if you want
this type of information, you have to calculate it yourself.
IMAP:
IMAP is a more advanced protocol for receiving messages. Defined in RFC 2060,
IMAP stands for Internet Message Access Protocol, and is currently in version 4,
also known as IMAP4. When using IMAP, your mail server must support the

protocol. You can't just change your program to use IMAP instead of POP and
expect everything in IMAP to be supported. Assuming your mail server supports
IMAP, your JavaMail-based program can take advantage of users having multiple
folders on the server and multiple users can share these folders.
Due to the more advanced capabilities, you might think everyone would use IMAP.
It isn't. It places a much heavier burden on the mail server, requiring the server to
receive the new messages, deliver them to users when requested, and maintain them
in multiple folders for each user. While this does centralize backups, as users' long-
term mail folders get larger and larger, everyone suffers when disk space is
exhausted. With POP, saved messages get offloaded from the mail server.
MIME:
MIME stands for Multipurpose Internet Mail Extensions. It is not a mail transfer
protocol. Instead, it defines the content of what is transferred: the format of the
messages, attachments, and so on. There are many different documents that take
effect here: RFC 822, RFC 2045, RFC 2046, and RFC 2047. As a user of the
JavaMail API, you usually don't need to worry about these formats. However, these
formats do exist and are used by your programs.
NNTP and Others:
Because of the split of the JavaMail API between provider and everything else, you
can easily add support for additional protocols. Sun maintains a list of third-party
providers that take advantage of protocols that Sun doesn't provide support for, out-
of-the-box. There, you'll find support for NNTP (Network News Transport Protocol)
[newsgroups], S/MIME (Secure Multipurpose Internet Mail Extensions), and more.
Installing:
There are two versions of the JavaMail API commonly used today: 1.2 and 1.1.3. All
the examples in this course will work with both. While 1.2 is the latest, 1.1.3 is the
version included with the 1.2.1 version of the Java 2 Platform, Enterprise Edition
(J2EE), so it is still commonly used. The version of the JavaMail API you want to

use affects what you download and install. All will work with JDK 1.1.6+, Java 2
Platform, Standard Edition (J2SE) version 1.2.x, and J2SE version 1.3.x.
Note: After installing Sun's JavaMail implementation, you can find many example
programs in the demo directory.
Installing JavaMail 1.2:
To use the JavaMail 1.2 API, download the JavaMail 1.2 implementation, unbundle
the javamail-1_2.zip file, and add the mail.jar file to your CLASSPATH. The 1.2
implementation comes with an SMTP, IMAP4, and POP3 provider besides the core
classes.
After installing JavaMail 1.2, install the JavaBeans Activation Framework.
Installing JavaMail 1.1.3:
To use the JavaMail 1.1.3 API, download the JavaMail 1.1.3 implementation,
unbundle the javamail1_1_3.zip file, and add the mail.jar file to your CLASSPATH.
The 1.1.3 implementation comes with an SMTP and IMAP4 provider, besides the
core classes.
If you want to access a POP server with JavaMail 1.1.3, download and install a
POP3 provider. Sun has one available separate from the JavaMail implementation.
After downloading and unbundling pop31_1_1.zip, add pop3.jar to your
CLASSPATH, too.
After installing JavaMail 1.1.3, install the JavaBeans Activation Framework.
Installing the JavaBeans Activation Framework:
All versions of the JavaMail API require the JavaBeans Activation Framework. The
framework adds support for typing arbitrary blocks of data and handling it

accordingly. This doesn't sound like much, but it is your basic MIME-type support
found in many browsers and mail tools, today. After downloading the framework,
unbundled the jaf1_0_1.zip file, and add the activation.jar file to your CLASSPATH.
For JavaMail 1.2 users, you should now have added mail.jar and activation.jar to
your CLASSPATH.
For JavaMail 1.1.3 users, you should now have added mail.jar, pop3.jar, and
activation.jar to your CLASSPATH. If you have no plans of using POP3, you don't
need to add pop3.jar to your CLASSPATH.
If you don't want to change the CLASSPATH environment variable, copy the JAR
files to your lib/ext directory under the Java Runtime Environment (JRE) directory.
For instance, for the J2SE 1.3 release, the default directory would be
C:jdk1.3jrelibext on a Windows platform.
Using with the Java 2 Enterprise Edition:
If you use J2EE, there is nothing special you have to do to use the basic JavaMail
API; it comes with the J2EE classes. Just make sure the j2ee.jar file is in your
CLASSPATH and you're all set.
For J2EE 1.2.1, the POP3 provider comes separately, so download and follow the
steps to include the POP3 provider as shown in Installing JavaMail 1.1.3. J2EE 1.3
users get the POP3 providers with J2EE so do not require the separate installation.
Neither installation requires you to install the JavaBeans Activation Framework.
Reviewing the Core Classes:
Before taking a how-to approach at looking at the JavaMail classes in depth, the
following walks you through the core classes that make up the API: Session,
Message, Address, Authenticator, Transport, Store, and Folder. All these classes are
found in the top-level package for the JavaMail API: javax.mail, though you'll
frequently find yourself using subclasses found in the javax.mail.internet package.

Session:
The Session class defines a basic mail session. It is through this session that
everything else works. The Session object takes advantage of a java.util.Properties
object to get information like mail server, username, password, and other
information that can be shared across your entire application.
The constructors for the class are private. You can get a single default session that
can be shared with the getDefaultInstance () method:
Properties props = new Properties ();
// fill props with any information
Session session = Session.getDefaultInstance (props, null);
Or, you can create a unique session with getInstance ():
// Fill props with any information
Session session = Session.getInstance (props, null);
In both cases here the null argument is an Authenticator object, which is not being
used at this time. More on Authenticator shortly.
In most cases, it is sufficient to use the shared session, even if working with mail
sessions for multiple user mailboxes. You can add the username and password
combination in at a later step in the communication process, keeping everything
separate.
Message:
Once you have your Session object, it is time to move on to creating the message to
send. This is done with a type of Message. Being an abstract class, you must work
with a subclass, in most cases javax.mail.internet.MimeMessage.
A MimeMessage is a email message that understands MIME types and headers, as
defined in the different RFCs. Message headers are restricted to US-ASCII

characters only, though non-ASCII characters can be encoded in certain header
fields.
To create a Message, pass along the Session object to the MimeMessage constructor:
MimeMessage message = new MimeMessage (session);
Note: There are other constructors, like for creating messages from RFC822-
formatted input streams.
Once you have your message, you can set its parts, as Message implements the Part
interface (with MimeMessage implementing MimePart). The basic mechanism to set
the content is the setContent () method, with arguments for the content and the mime
type:
Message.setContent ("Hello", "text/plain");
If, however, you know you are working with a MimeMessage and your message is
plain text, you can use its setText () method, which only requires the actual content,
defaulting to the MIME type of text/plain:
Message.setText ("Hello");
For plain text messages, the latter form is the preferred mechanism to set the content.
For sending other kinds of messages, like HTML messages, use the former. More on
HTML messages later though.
For setting the subject, use the setSubject () method:
Message.setSubject ("First");

Address:
Once you've created the Session and the Message, as well as filled the message with
content, it is time to address your letter with an Address. Like Message, Address is
an abstract class. You use the javax.mail.internet.InternetAddress class.
To create an address with just the email address, pass the email address to the
constructor:
Address address = new InternetAddress ("president@whitehouse.gov");
If you want a name to appear next to the email address, you can pass that along to the
constructor, too:
Address address = new InternetAddress
("president@whitehouse.gov", "George Bush");
You will need to create address objects for the message's from field as well as the to
field. Unless your mail server prevents you, there is nothing stopping you from
sending a message that appears to be from anyone.
Once you've created the addresses, you connect them to a message in one of two
ways. For identifying the sender, you use the setFrom () and setReplyTo () methods.
Message.setFrom (address)
If your message needs to show multiple from addresses, use the addFrom () method:
Address address [] =;
Message.addFrom (address);
For identifying the message recipients, you use the addRecipient () method.

This method requires a Message.RecipientType besides the address.
Message.addRecipient (type, address)
The three predefined types of address are:
Message.RecipientType.TO
Message.RecipientType.CC
Message.RecipientType.BCC
So, if the message were to go to the vice president, sending a carbon copy to the first
lady, the following would be appropriate:
Address toAddress = new InternetAddress ("vice.president@whitehouse.gov");
Address ccAddress = new InternetAddress ("first.lady@whitehouse.gov");
Message.addRecipient (Message.RecipientType.TO, toAddress);
Message.addRecipient (Message.RecipientType.CC, ccAddress);
The JavaMail API provides no mechanism to check for the validity of an email
address. While you can program in support to scan for valid characters (as defined by
RFC 822) or verify the MX (mail exchange) record yourself, these are all beyond the
scope of the JavaMail API.
Authenticator:
Like the java.net classes, the JavaMail API can take advantage of an Authenticator to
access protected resources via a username and password. For the JavaMail API, that
resource is the mail server. The JavaMail Authenticator is found in the javax.mail
package and is different from the java.net class of the same name. The two don't
share the same Authenticator as the JavaMail API works with Java 1.1, which didn't
have the java.net variety.

To use the Authenticator, you subclass the abstract class and return a
PasswordAuthentication instance from the getPasswordAuthentication () method.
You must register the Authenticator with the session when created. Then, your
Authenticator will be notified when authentication is necessary. You could popup a
window or read the username and password from a configuration file (though if not
encrypted it is not secure), returning them to the caller as a PasswordAuthentication
object.
// fill props with any information
Authenticator auth = new MyAuthenticator ();
Session session = Session.getDefaultInstance (props, auth);
Transport:
The final part of sending a message is to use the Transport class. This class speaks
the protocol-specific language for sending the message (usually SMTP). It's an
abstract class and works something like Session. You can use the default version of
the class by just calling the static send () method:
Transport.send (message);
Or, you can get a specific instance from the session for your protocol, pass along the
username and password (blank if unnecessary), send the message, and close the
connection:
Message.saveChanges (); // implicit with send ()
Transport transport = session.getTransport ("smtp");
Transport.connect (host, username, password);
Transport.sendMessage (message, message.getAllRecipients ());

Transport.close ();
This latter way is best when you need to send multiple messages, as it will keep the
connection with the mail server active between messages. The basic send ()
mechanism makes a separate connection to the server for each method call.
Note: To watch the mail commands go by to the mail server, set the debug flag with
session.setDebug (true).
Store and Folder:
Getting messages starts similarly to sending messages, with a Session. However,
after getting the session, you connect to a Store, quite possibly with a username and
password or Authenticator. Like Transport, you tell the Store what protocol to use:
// Store store = session.getStore ("imap");
Store store = session.getStore ("pop3");
Store.connect (host, username, password);
After connecting to the Store, you can then get a Folder, which must be opened
before you can read messages from it:
Folder folder = store.getFolder ("INBOX");
Folder.open (Folder.READ_ONLY);
Message message [] = folder.getMessages ();
For POP3, the only folder available is the INBOX. If you are using IMAP, you can
have other folders available.
Note: Sun's providers are meant to be smart. While Message message [] =
folder.getMessages (); might look like a slow operation reading every message from

the server, only when you actually need to get a part of the message is the message
content retrieved.
Once you have a Message to read, you can get its content with getContent () or write
its content to a stream with writeTo (). The getContent () method only gets the
message content, while writeTo () output includes headers.
System.out.println (((MimeMessage) message). getContent ());
Once you're done reading mail, close the connection to the folder and store.
Folder.close (aBoolean);
Store.close ();
The Boolean passed to the close () method of folder states whether or not to update
the folder by removing deleted messages.
Moving On:
Essentially, understanding how to use these seven classes is all you need for nearly
everything with the JavaMail API. Most of the other capabilities of the JavaMail API
build off these seven classes to do something a little different or in a particular way,
like if the content is an attachment. Certain tasks, like searching, are isolated, and are
discussed later.
Using the JavaMail API:
You've seen how to work with the core parts of the JavaMail API. In the following
sections you'll find a how-to approach for connecting the pieces to do specific tasks.
Sending Messages:
Sending an email message involves getting a session, creating and filling a message,
and sending it. You can specify your SMTP server by setting the mail.smtp.host
property for the Properties object passed when getting the Session:

String host =;
String from =;
String to =;
// Get system properties
Properties props = System.getProperties ();
// Setup mail server
Props.put ("mail.smtp.host", host);
// Get session
// Define message
MimeMessage message = new MimeMessage (session);
Message.setFrom (new InternetAddress (from));
Message.addRecipient (Message.RecipientType.TO,
New InternetAddress (to));
Message.setSubject ("Hello JavaMail");
Message.setText ("Welcome to JavaMail");
// Send message
You should place the code in a try-catch block, as setting up the message and
sending it can throw exceptions.
Fetching Messages:
For reading mail, you get a session, get and connect to an appropriate store for your
mailbox, open the appropriate folder, and get your message(s). Also, don't forget to
close the connection when done.

String host =...;
String username =...;
String password = ...;
// Create empty properties
// Get session
// Get the store
Store.connect (host, username, password);
// Get folder
Folder folder = store.getFolder ("INBOX");
Folder.open (Folder.READ_ONLY);
// Get directory
For (int i=0, n=message.length; i<n; i++)
{
System.out.println (i + ": " + message [i]. GetFrom ()[0]
+ "t" + message[i].getSubject());
}
// Close connection
Folder.close (false);
Store.close ();

What you do with each message is up to you. The above code block just displays
who the message is from and the subject. Technically speaking, the list of from
addresses could be empty and the getFrom ()[0] call could throw an exception.
To display the whole message, you can prompt the user after seeing the from and
subject fields, and then call the message's writeTo () method if they want to see it.
BufferedReader reader = new BufferedReader
(
New InputStreamReader (System.in));
// Get directory
For (int i=0, n=message.length; i<n; i++)
{
System.out.println (i + ": " + message [i]. GetFrom ()[0]
+ "T" + message [i]. GetSubject ());
System.out.println ("Do you want to read message? " +
"[YES to read/QUIT to end]");
String line = reader.readLine ();
if ("YES".equals(line))
{
Message [i]. WriteTo (System.out);
}
Else if ("QUIT". equals (line))
{
Break;
}

}
Deleting Messages and Flags:
Deleting messages involves working with the Flags associated with the messages.
There are different flags for different states, some system-defined and some user-
defined. The predefined flags are defined in the inner class Flags. Flag and are listed
below:
Flags.Flag.ANSWERED
Flags.Flag.DELETED
Flags.Flag.DRAFT
Flags.Flag.FLAGGED
Flags.Flag.RECENT
Flags.Flag.SEEN
Flags.Flag.USER
Just because a flag exists doesn't mean the flag is supported by all mail
servers/providers. For instance, besides deleting messages, the POP protocol
supports none of them. Checking for new mail is not a POP task but one built into
mail clients. To find out what flags are supported, ask the folder with
getPermanentFlags ().
To delete messages, you set the message's DELETED flag:
Message.setFlag (Flags.Flag.DELETED, true);
Open up the folder in READ_WRITE mode first though:
Folder.open (Folder.READ_WRITE);
Then, when you are done processing all messages, close the folder, passing in a true
value to expunge the deleted messages.

Folder.close (true);
There is an expunge () method of Folder that can be used to delete the messages.
However, it doesn't work for Sun's POP3 provider. Other providers may or may not
implement the capabilities. It will more than likely be implemented for IMAP
providers. Because POP only supports single access to the mailbox, you have to
close the folder to delete the messages with Sun's provider.
To unset a flag, just pass false to the setFlag () method. To see if a flag is set, check
with isSet ().
Authenticating Yourself:
You previously learned that you could use an Authenticator to prompt for username
and password when needed, instead of passing them in as strings. Here you'll
actually see how to more fully use authentication.
Instead of connecting to the Store with the host, username, and password, you
configure the Properties to have the host, and tell the Session about your custom
Authenticator instance, as shown here:
// Setup properties
Properties props = System.getProperties ();
Props.put ("mail.pop3.host", host);
// Setup authentication, get session
Authenticator auth = new PopupAuthenticator ();
Session session = Session.getDefaultInstance (props, auth);
// Get the store

Store.connect ();
You then subclass Authenticator and return a PasswordAuthentication object from
the getPasswordAuthentication () method. The following is one such
implementation, with a single field for both. As this isn't a Project Swing tutorial,
just enter the two parts in the one field, separated by a comma.
Since the Popup Authenticator relies on Swing, it will start up the event-handling
thread for AWT. This basically requires you to add a call to System.exit () in your
code to stop the program.
Replying to Messages:
The Message class includes a reply () method to configure a new Message with the
proper recipient and subject, adding "Re: " if not already there. This does not add any
content to the message, only copying the from or reply-to header to the new
recipient. The method takes a Boolean parameter indicating whether to reply to only
the sender (false) or reply to all (true).
MimeMessage reply = (MimeMessage) message.reply (false);
Reply.setFrom (new InternetAddress ("president@whitehouse.gov"));
Reply.setText ("Thanks");
Transport.send (reply);
To configure the reply-to address when sending a message, use the setReplyTo ()
method.
Forwarding Messages:
Forwarding messages is a little more involved. There is no single method to call, and
you build up the message to forward by working with the parts that make up a
message.
A mail message can be made up of multiple parts. Each part is a BodyPart, or more
specifically, a MimeBodyPart when working with MIME messages. The different

body parts get combined into a container called Multipart or, again, more specifically
a MimeMultipart. To forward a message, you create one part for the text of your
message and a second part with the message to forward, and combine the two into a
multipart. Then you add the multipart to a properly addressed message and send it.
That's essentially it. To copy the content from one message to another, just copy over
its DataHandler, a class from the JavaBeans Activation Framework.
// Create the message to forward
Message forward = new MimeMessage (session);
// Fill in header
Forward.setSubject ("Fwd: " + message.getSubject ());
Forward.setFrom (new InternetAddress (from));
Forward.addRecipient (Message.RecipientType.TO,
// Create your new message part
BodyPart messageBodyPart = new MimeBodyPart ();
MessageBodyPart.setText (
"Here you go with the original message:nn");
// create a multi-part to combine the parts
Multipart multipart = new MimeMultipart ();
Multipart.addBodyPart (messageBodyPart);
// Create and fill part for the forwarded content
MessageBodyPart = new MimeBodyPart ();
MessageBodyPart.setDataHandler (message.getDataHandler ());
// add part to multi part

// Associate multi-part with message
Forward.setContent (multipart);
// Send message
Transport.send (forward);
Working with Attachments:
Attachments are resources associated with a mail message, usually kept outside of
the message like a text file, spreadsheet, or image. As with common mail programs
like
Eudora and pine, you can attach resources to your mail message with the JavaMail
API and get those attachments when you receive the message.
Sending Attachments:
Sending attachments is quite like forwarding messages. You build up the parts to
make the complete message. After the first part, your message text, you add other
parts where the DataHandler for each is your attachment, instead of the shared
handler in the case of a forwarded message. If you are reading the attachment from a
file, your attachment data source is a FileataSource. Reading from a URL, it is a
URLDataSource. Once you have your DataSource, just pass it on to the DataHandler
constructor, before finally attaching it to the BodyPart with setDataHandler ().
Assuming you want to retain the original filename for the attachment, the last thing
to do is to set the filename associated with the attachment with the setFileName ()
method of BodyPart. All this is shown here:
// define message
Message message = new MimeMessage (session);
Message.setFrom (new InternetAddress (from));

Message.addRecipient (Message.RecipientType.TO,
Message.setSubject ("Hello JavaMail Attachment");
// Create the message part
BodyPart messageBodyPart = new MimeBodyPart ();
// Fill the message
MessageBodyPart.setText ("Pardon Ideas");
Multipart multipart = new MimeMultipart ();
// Part two is attachment
MessageBodyPart = new MimeBodyPart ();
DataSource source = new FileDataSource (filename);
MessageBodyPart.setDataHandler (new DataHandler (source));
MessageBodyPart.setFileName (filename);
// Put parts in message
Message.setContent (multipart);
// Send the message
When including attachments with your messages, if your program is a servlet, your
users must upload the attachment besides tell you where to send the message.
Uploading each file can be handled with a form encoding type of multipart/form-
data.

<FORM ENCTYPE="multipart/form-data"
Method=post action="/myservlet">
<INPUT TYPE="file" NAME="thefile">
<INPUT TYPE="submit" VALUE="Upload">
</FORM>
Note: your SMTP server, not the JavaMail API, limits Message size. If you run into
problems, consider increasing the Java heap size by setting the ms and mx
parameters.
Getting Attachments:
Getting attachments out of your messages is a little more involved then sending
them, as MIME has no simple notion of attachments. The content of your message is
a Multipart object when it has attachments. You then need to process each Part, to
get the main content and the attachment(s).
Parts marked with a disposition of Part.ATTACHMENT from part.getDisposition ()
are clearly attachments. However, attachments can also come across with no
disposition (and a non-text MIME type) or a disposition of Part.INLINE. When the
disposition is either Part.ATTACHMENT or Part.INLINE, you can save off the
content for that message part. Just get the original filename with getFileName () and
the input stream with getInputStream ().
Multipart mp = (Multipart) message.getContent ();
For (int i=0, n=multipart.getCount (); i<n; i++)
{
Part part = multipart.getBodyPart (i));
String disposition = part.getDisposition ();

if ((disposition != null) &&
((Disposition.equals (Part.ATTACHMENT) ||
(Disposition.equals (Part.INLINE))) {
SaveFile (part.getFileName (), part.getInputStream ());
}
}
The saveFile () method just creates a File from the filename, reads the bytes from
the input stream, and writes them off to the file. In case the file already exists, a
number is added to the end of the filename until one is found that doesn't exist.
// from saveFile ()
File file = new File (filename);
For (int i=0; file.exists (); i++)
{
File = new File (filename+i);
}
The code above covers the simplest case where message parts are flagged
appropriately. To cover all cases, handle when the disposition is null and get the
MIME type of the part to handle accordingly.
if (disposition == null)
{
// Check if plain
MimeBodyPart mbp = (MimeBodyPart) part;
If (mbp.isMimeType ("text/plain"))
{
// Handle plain
} Else
{
// Special non-attachment cases here of

// Image/gif, text/html,...
}
...
}
Searching with SearchTerm:
The JavaMail API includes a filtering mechanism found in the javax.mail.search
package to build up a SearchTerm. Once built, you then ask a Folder what messages
match, retrieving an array of Message objects:
SearchTerm st = ...;
Message [] msgs = folder.search (st);
There are 22 different classes available to help you build a search term.
AND terms (class AndTerm)
OR terms (class OrTerm)
NOT terms (class NotTerm)
SENT DATE terms (class SentDateTerm)
CONTENT terms (class BodyTerm)
HEADER terms (FromTerm / FromStringTerm, RecipientTerm /
RecipientStringTerm, SubjectTerm, etc.)
Essentially, you build up a logical expression for matching messages, and then
search. For instance the following term searches for messages with a (partial) subject
string of ADV or a from field of friend@public.com. You might consider
periodically running this query and automatically deleting any messages returned.
SearchTerm st =
New OrTerm
(New SubjectTerm ("ADV:"),

New FromStringTerm ("friend@public.com"));
Message [] msgs = folder.search (st);
8. Experimental Results:
Homepage:

Login Page:

Invalid User: (Login fails)

User Home Page (After Login):

About Us:

Inbox:

Read Mail: (Read a selected Mail from inbox)

PDF Generation for Mail:
Download Attachment:

Compose Mail:

Adding Attachment:

Mail Sent Success Page:

Forward Mail page:

Reply Mail Page:

Delete mail confirmation page:
Contacts page:

SignOut Success Page:

Registering User in James Mail Server:

9. CONCLUSION
 All the users in the organization have appreciated the project.
 The usage of software increases the efficiency, decreases the effort.
 It has been thoroughly tested and implemented.

10.BIBILOGRAPHY
1. SOFTWARE ENGINEERING By Roger.S.Pressman
2. THE COMPLETE REFERENCE By Patrick Naughton, and
Herbert Schildt
3. Referred for JAVA MAIL API to:
http://java.sun.com/developer/onlineTraining/JavaMail/contents.htm
l

Simple Mail Transfer Protocol

More Related Content

What's hot

Viewers also liked

Similar to Simple Mail Transfer Protocol

Recently uploaded

Simple Mail Transfer Protocol