Running Mingle - Google Code

looneyvillestaticSoftware and s/w Development

Aug 15, 2012 (5 years and 2 months ago)

232 views

Mingle Documentation

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.

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
abase
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
y
deployment files.



“libs” holds our 3
rd

party libraries



Mingle
-
ejb contains the NetBeans project files for the server portion of
Mingle.



Mingle
-
war contains the NetBeans project files for the client portion of
Mingle.



The nbproject directory stores proper
ty and configuration files for
building and deploying the entire project. The “nb” stands for
NetBeans.



The src directory holds all our raw Java files.

Mingle
Root

Doc

Mingle

SQL

Mingle

build

dist

libs

Mingle
-
ejb

Mingle
-
war

nbproject

src

Prerequisites

Mingle has but a few requirements to deploy and run. The administrator needs to have a MyS
QL
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
ervers
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

GlassFish

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
ver/domains/domain1/autodeploy).
Alternatively, the administrator can simply load the EAR file through the GlassFish console at
http://localhost:4848
.

Running Mingle

[Fabio


you’re on!]

Test Plan

We test as we impleme
nt, dividing the implementation into discrete, measurable goals. Though not a
true test
-
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
referential
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.

Lessons

Learned



Collaboration and delegation are paramount

o

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.

o

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
expose
everyone to new approaches.



Communication is the problem. Communication is the answer.

o

B2B applications, by definition, imply communication between two separate entities.
Sometimes this communication is well
-
defined (e.g., our email clients all impl
emented POP3
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
client.

o

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

o

Ch
oosing the proper design tools allows for rapid implementation. We decided on an
inclusive Java IDE/Webserver (NetBeans with GlassFish) and a simple, open
-
source database
(MySQL) which reduced the time spent on environmental problems and maximized our
impl
ementation efforts. The focus on business solutions and not on architectural solutions
allowed for rapid development.

o

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)