This document describes how to build, deploy, and run the B2B system that allows a user to securely
access multiple email accounts from a single application
Mingle utilizes a multi
part, asynchronous architecture to fetch, store, and manage emails. Agents,
running as Servlets, connect and feed a client’s emails to a central storage system. The client can then
read, label, and delete his/her emails independent
of the original mail server. J2EE provides our
framework, while MySQL supplies persistent storage for all emails. Processes on either side of the
database work asynchronously to provide a seamless experience
for the user.
Our main directory structure appe
ars to the left (in blue):
Below the root, the user can find the Doc directory which
contains this user manual.
The Mingle directory holds all the code, both client and
server, that provides business functionality.
The SQL directory contains both the dat
deployment scripts and a schema file saved as a MySQL
WorkBench (.mwb) file.
The Mingle Directory layout appears below (in red):
The build directory contains all JAR and WAR files.
The dist directory holds the distributable EAR file and all necessar
“libs” holds our 3
ejb contains the NetBeans project files for the server portion of
war contains the NetBeans project files for the client portion of
The nbproject directory stores proper
ty and configuration files for
building and deploying the entire project. The “nb” stands for
The src directory holds all our raw Java files.
Mingle has but a few requirements to deploy and run. The administrator needs to have a MyS
database server and a GlassFish 2.1 application server installed and configured. The administrator
should have GlassFish configured to use JDK 1.5 or higher.
The user needs any number of email accounts with POP3 access. These can be locally controlled s
such as Outlook Exchange or a remote server like Gmail/Hotmail.
Setting Up Mingle’s Database
Once the administrator has installed MySQL, he/she can run Mingle’s database deployment script
(MingleTableCreate_AutoGenerated.sql) that will create all ne
cessary schemas. The administrator
should note that the script creates a default user with the login/password of “admin”/”admin”.
Once deployed, the database will have the following schema:
How to Build Mingle
Mingle comes ready to build with but one cal
l to Ant. From the command line, open the Mingle root
directory and then navigate to the Mingle directory. From here, type “Ant” and hit [Enter]. The entire
project will build and package itself for deployment.
How to Deploy Mingle
makes Mingle deployment easy and straightforward. First, the administrator needs to locate
the Mingle.EAR file in MingleRoot/Mingle/dist. The administrator can then copy this into the autodeploy
directory of GlassFish ([GlassFish_Install_Directory]/AppSer
Alternatively, the administrator can simply load the EAR file through the GlassFish console at
We test as we impleme
nt, dividing the implementation into discrete, measurable goals. Though not a
driven design, we always consider how to test the code we’re currently working on.
Early in the development we pushed randomly
generated data into the database to test
integrity and provide data for early client versions. The Agent began as a stand
alone Java application
that parsed and printed email contents to the console. As each piece matured, we integrated it into the
Mingle system incrementally.
Collaboration and delegation are paramount
Our tendency toward shouldering the entire load can interfere with the project’s evolution.
By consistently distributing responsibilities, every contributor can bring forward new ideas
about their portion
. This fuels a new round of design discussions and helps guide and
mature the project.
Delegation allows another perspective to a particular problem.
Everyone has ideas on how
he/she can implement a solution, but allowing another to handle the problem can
everyone to new approaches.
Communication is the problem. Communication is the answer.
B2B applications, by definition, imply communication between two separate entities.
Sometimes this communication is well
defined (e.g., our email clients all impl
protocols) and connecting the “plumbing” is straightforward. However, since the original
applications get to choose which client features (contacts, calendar, search, etc.) to expose
in an API, B2B applications may not be able to offer the sam
e rich experience as the original
One way around this problem is to create a more intelligent “agent” that mimics a real client
to such a degree that it can utilize full functionality without the restriction of an API. Such an
agent is beyond the o
riginal scope of our project. However, future research into screen
recognition and interaction could effectively eliminate the dichotomy of the client’s
interface (typically the browser) and the B2B’s interface (API).
Tools matter because timing matters
oosing the proper design tools allows for rapid implementation. We decided on an
inclusive Java IDE/Webserver (NetBeans with GlassFish) and a simple, open
(MySQL) which reduced the time spent on environmental problems and maximized our
ementation efforts. The focus on business solutions and not on architectural solutions
allowed for rapid development.
In all things B2B, timing is of the essence. All parties are constantly making changes to
improve their product and drive new business. T
he window of opportunity for connecting
two or more evolving applications is always short. Even in successful B2B relationships
(Amazon, Travelocity, etc.), these companies impose tremendous pressure on themselves
and their business partners to evolve and
improve the user’s experience. This in turn
produces rapid development cycles to keep up. Development tools that appear transparent
to the developer allow the project to hit its timeline goal.
Known Bugs (or Things to Watch Out)