ESME Blog

In my last blog, I mentioned my tests with the Stax.net cloud as hosting opportunity for ESME.  Well, after fighting various issues dealing with proxies and request timeouts,  I finally got ESME installed at Stax, then logged in via OpenID and posted my first cloud-based ESME message.

I really think the Stax environment is great once you get the hang of it.

To get ESME working, I used the sample application from Stax and then copied the files from the ESME war file from the Google Code site. I copied all the esme files into the “webapp” directory and then did a “stax deploy” command to load it all up into the Stax system.  I had to make some adjustments to the ant build file for the Stax deployment, because I have a limitation on the size of files that I can send via HTTP ( Therefore, the source code currently available in Stax is missing all the Jar files.)  Besides that problem, everything worked out well.

I also was able to use the cloud-database in the Stax environment rather than the existing Derby implementation. If you wanted to use a remote DB (for example, behind the firewall), you just have to change the details.

I just added the following snippet to the web.xml file:

<resource-ref>
<res-ref-name>esme</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

and the following snippet to the stax-application.xml

<resource name=”esme” auth=”Container” type=”javax.sql.DataSource”>
<param name=”username” value=”esme_2″ />
<param name=”password” value=”xxx” /> [password is hidden for this blog]
<param name=”url” value=”jdbc:stax://esme” />
</resource>

Now, that ESME is installed, it is possible to perform operations-related tasks -all from my browser.

Still open

• There are still exceptions dealing with file-based activities.  For example. the search interface via Compass currently doesn’t work, because it uses file. These have to be changed as well to have a fully functional application.
• It would be cool to be able to clone this application(including database)  for others.
• It would be useful to have the ability to restrict access to particular IP addresses (maybe, this is a function for which Stax could charge?)

I’m been playing with Stax -  “the fastest way for developers to build, manage and scale Java applications on EC2″ as a means to get ESME into the cloud. I’ve already created an example application (not ESME) based on the standard functionality and am now exploring the environment to get ESME up and running. Currently, the main problem is associated with the fact that ESME uses a local Apache Derby database for test purposes. One requirement on Stax is that local files can’t be created, so I have to use a JDBC data-source to a DB hosted in the Amazon cloud or somewhere else. I’ve created a database in the Amazon cloud (via Stax – real easy by the way -) and am now looking at configuring ESME to use this database. Once this step is done, the next step/scenario would be to use a remote database. This is an interesting scenario that I’ve discussed in another blog about architectural patterns which describes the possibility of a ESME server that  is cloud-based but the database is in the DMZ behind the firewall.  This pattern is interesting, because corporations often have problems with cloud-based installations, because the data is usually not under their control. There may be performance problems associated with such a pattern but this is something that might be able to be lessened via hardware and/or network-related measures.

Once we get the ESME server up and running, I’ll post another blog with our experiences.