Email Answering System Version 1.0

The Email Answering System.

See:
Description

Packages

com.ninecode.email.beans.master	The master beans package.
com.ninecode.email.beans.slave	The slave beans package.
com.ninecode.email.beans.slave.dictionary	The Dictionary robot.
com.ninecode.email.beans.slave.phone	The Phone robot.
com.ninecode.email.beans.slave.stock	The Stock robot.
com.ninecode.email.beans.slave.weather	The Weather robot.
com.ninecode.email.beans.slave.web	The Web robot.
com.ninecode.email.connector	The Email Connector package.
com.ninecode.email.util	The utility package.
test	The unit test package.

The Email Answering System.

This system is a J2EE application that automatically responds to email messages.

It is composed of:

a J2EE email connector that provides underlying functionality to send and receive email messages

a dispatcher bean to perform triage on the incoming email messages based on subject

a responder bean that sends replies as email messages

a dictionary bean that looks up a word to get it's definition

a phone bean that looks up people in Ottawa

a stock bean that returns stock quotations

a weather bean that provides weather forecasts for cities in Canada

a web bean that returns the textual content of a web page

Other functionality can be added quite easily.

Deploying

To deploy the system you'll need to get the email.ear and email.rar from the Sourceforge connector project and follow the deploy instructions.

Building

To build the system you'll need to get the sources from Derrick Oswald and follow the build instructions.

History

This all started back in 2000 when I went to JavaOne and bought a RIM 957. RIM had a contest, to see who could write the best Java application to run on the embedded JVM. The idea was that all these Java programers would come up with some killer apps to kickstart the BlackBerry infrastructure.

Anyway, I did some work on displaying faxes, but the timeline for the contest was too short, and the non-JIT JVM and lack of i/o caused my interest in the contest to wane. I soon realized that viewing faxes was next to useless and what I really needed was web access from the device.

Oh sure, there was Go America, but they wanted US$10.57 per month for 10 kilobytes worth of browsing and then the rates were an exhorbitant amount per kilobyte thereafter. Not that you would seriously browse on the BlackBerry, but if you just wanted to check Slashdot or weather forecasts there was no cheap and easy way.

There were services like Ask Oracle that would respond when asked for travel info or stock quotes, but you couldn't ask for an arbitrary web page and if you asked for weather you had to input a ZIP code, which was somewhat problematic for someone living in Canada like me.

So I began to write a little java server that would respond to email requests the way I wanted. Out of that effort came a monolithic program that, using the javax.mail api, would poll my own mail server and reply to various subject lines, like 'weather' and 'www', with a the text of an html page from the internet.

I told other people at work who had BlackBerries that this was available and they too thought it was useful. But there were some issues with it, not the least of which was my own server being just a node on the @home system, would often get lost in their DNS, so there was often a many-hour delay between sending an email and receiving the response.

Another problem was the dispatch code was one big if statement checking 'if (subject.equals("blah"))', which is to programmers what a messy kitchen is to Aunt Gertrude. So I decided to rewrite it (or mostly rearrange code) so that it was beautiful.

It turned out to be a small tour de force in J2EE usage, involving a connector and message driven beans. If you want to delve a little deeper into the architecture see the (incomplete) design notes and the small configuration management document.

For what it's worth, here it is.

Outstanding Issues.

One of the problems I ran up against was that the paradigm used in J2EE does not allow for EJB's to asynchronously start things and the pop3 paradigm is a polled mode. The life cycle of a bean starts with outside-the-container interaction, so an EJB, by itself, would not allow an asynchronous event (new email arriving) to begin an operation. After looking around it seemed that a connector hooked up to a message queue might do the trick. So I made one. Indeed it allowed me to spin a background thread that polls the pop3 server, but this is probably still illegal and may not work in all containers. This will probably disappear when the Connector 1.5 specification (JSR 112) is adopted and implemented since it addresses these life-cyle and threading issues.

The next problem I ran up against was that deployed beans need to know ahead of time all the resource references they are going to use. So one can't just add a message sink and have the dispatcher dynamically discover it. The solution I came up with was a list of topics and configured resource refs. Oh well.

There's still lots to do (see ToDo), but it works, and that's all that people really care about isn't it.