Running Java App Jena in Azure Cloud: Part 1

The techniques discussed in this post are demonstrated within this Visual Studio project:

Jena is a java application, and as such, it can easily run within an Azure worker role.  Typically any sophisticated cloud app will have various roles, however, this tutorial is merely to get the ball rolling with the simplest thing that can possibly work.  We will deploy Tomcat with a simple Jena application that loads rdf from public endpoints, and allows us to query the loaded data.  Furthermore, we’ll make use of Azure cloud storage to maintain a persistent TDB backed triple store.

Prerequisits

This post assumes you have an Azure account.  Furthermore, you will need to allocate one hosted service and one storage service.  The hosted service will run our worker role which is effectively an on demand instance of Windows Server 2008.  The storage service will act as a cloud drive onto which TDB will write it’s files.  You will need either Windows Vista or Windows 7, a copy of Visual Studio (2008 or 2010), and have the Windows Azure SDK.   More details on getting started with Windows Azure can be found here.

The Worker Role Project

All Windows Azure projects begin with either a web role (.Net IIS application) or a more generic worker role.  In our case we’re using a worker role.  The example project has four things I want to call attention to.  First, we are uploading tomcat, along with a full JRE into the worker role.  For instance, the worker role once started will expect to find tomcat/bin/catalina.bat as well as tomcat/jre/bin/java.exe.  The first thing that happense when a worker role is instantiated is a call to RoleEntryPoint.OnStart() and RoleEntryPoint.Run().  We’ll look at these a little more in depth, but for now just notice that they are defined withint WorkerRole.cs.  During startup the tomcat directory is copied into a writable local directory.  This happens in setup.bat.  Finally, all ports in Windows Azure are dynamic.  In the role config we can specify that our web app will communicate on port 80, however, internally the role we’ll be working with a dynamic port assigned at runtime.  This requires updates to the tomcat configuration which happens in RunTomcat.cs.  To summarize:

1. the tomcat binaries, along with a JRE are included within the project, and eventually packaged and deployed to the worker role.
2. WorkerRole.cs handles startup events.
3. setup.bat copies the tomcat directory onto a writable local disk.  This is important for log file creation.
4. RunTomcat.cs handles dynamic configuration of the HTTP port and other aspects of starting the tomcat process.

Mounting a Cloud Drive

The example project is mostly identical to the Azure Tomcat Acclerator (with a few small enhancements).  The most significant change is that my example mounts a cloud drive onto which we’ll mount a Jena TDB instance. The mounting process happens within the Run() event (WorkerRole.cs). The method could easily be taken out of this project and reused elsewhere.

What is import to know is that the cloud drive is mounted using a configuraion settting, which can easily be managed using Visual Studio’s role configuration editor.  You will supply your own secret key and account name.  Also, the cloud drive should be configured as an HTTP connection.  Within the example project see the source code file RunTomcat.cs.  Within this file we take the dynamic drive letter, assigned at runtime, and provide it to the process’s environment settings where Jena will be able to find it later:

newProc.StartInfo.EnvironmentVariables.Remove("DRIVE");
newProc.StartInfo.EnvironmentVariables.Add("DRIVE", drive);

Seemingly trivial, and yet certainly not conventional.  Most deployments of Tomcat and Jena can assume a certain directory path.  This is not so in the cloud, where everything is allocated dynamically.

Publish and Run Tomcat

Within Visual Studio got to build->publish. This will create two files, one which is the project fully packaged and ready to run in Azure along with a configuration file. You may update your configuration, for instance, you may want to run Jena on a larger system. I would not advise running this particular example on more than one role, as a fully scalable setup would require two roles, one for web tier, and one for data. We’ll leave that as a (todo: create advanced jena architecture with queued readers, and publishing web roles). In my next post I’ll introduce the simple Jena project. We’ll be using Tomcat’s own WAR publishing feature to push the app up to our Azure service, reducing the amount of bits in the initial upload and allowing for making simple changes to the Jena app without bringing down our cloud service.