Deploying your Talia Site

Once you've installed and configured your Talia site (you may also want to import some data), you will want to run your site on a public server. There are are several possibilities to do that.

Easy for Development: Mongrel

The easiest way to try out your application is probably still Mongrel, a lightweight web server for ruby. You can install mongrel with

gem install mongrel

and you're set to go. Your sever can be easily started using the built-in startup script for Rails:

script/server

(Note that, in the absence of Mongrel, this script will default to a ruby server called "Webrick". This is likely to give you pain, so install mongrel for development).

Mongrel works fine with both JRuby and native implementations. In theory, you can also run your whole site with it, using several separate instances and a proxy server. However, this is quite complicated and for Talia we suggest that you go for one of the other options on this page.

Quick and Clean: The glassfish gem

If you're running Talia on JRuby (which we recommend), there's a really easy way to get it started on a Java server: The glassfish gem. To install it do

gem install glassfish

Glassfish is a commercial-strength Java application server. The gem contains the core of this server and the additional software that lets you run your rails application. You can use it in almost the same way as mongrel:

glassfish <options>

where it accepts many of the options as the script/server script. It should run your application unaltered, lets you create multiple runtimes and should be quite reliable. If you've got a very simple installation, this may be all you need (but check the notes on using sesame with multiple instances!).

JRuby Deployment for Real Men (or Women :) with an application server

This section shows you how to deploy your application to a Java application server with all the bells and whistles. This is usually the road you want to take for a "real" deployment. It's not all that difficult, but there are a few things to keep in mind.

The basic idea is to build a Java web application (.war) file from your application, which can then be deployed to any compatible application server, like Tomcat or glassfish. Tomcat is the traditional choice (and maybe you have it already up and running in your organization). Glassfish is a newer server, has a nice web interface and whole bunch of options.

In this guide, we'll be using glassfish.

Preparing your Talia application for deployment

The first thing to do is to install the warbler gem. This is a little tool that will turn any Rails application into a .war file without much effort. Just go

gem install warbler

to get the software. Talia has a default configuration file for warbler, which you can find in config/warbler.rb. But before we roll out the war, there are a few other things to do.

Note for Mac users: To use the warbler gem, you will need Java 6 on your system. Java 6 is available in Mac OS X 10.5 Leopard or higher. If you have Leopard installed, Java 6 will be there, but it won't be the default. You can find a small "Java Preferences" program in "Applications -> Utility", with which you can choose the default Java engine.

Installing your Application Server

Of course you'll have to have your Java application server installed. In case you want to use glassfish, you can download it from their site and follow the instructions in the installation and quick start guides that are linked from the download page.

If you're on Linux, there may be a glassfish (or tomcat) package that you can install with your usual package manager. Mac OS X Server comes with Tomcat pre-installed although you have to enable it in the server preferences.

Once you have glassfish installed, you can go to http://<your server>:4848 and you should be greeted by the glassfish administration console.

You can login here with the default account "admin" and the password "adminadmin". To deploy a new web application, click on "Web Applications" on the left and then on the "Deploy" Button

In the deployment screen, you'll have to enter a name for your application, and a "context root" - after you deployed the application, it will be available under http:<your server>:8080/<context root>/. You will also need to give the .war file itself - you can either upload it from your local computer, or search it on the server's file system.

The rest of the settings can be left at their defaults in most cases, just click ok and after a few seconds your web application should show up as deployed. To test it, visit the http:<your server>:8080/<context root>/ address and see if everything works as expected.

Preparing Sesame

When you configured Talia, you probably choose to use Sesame with the "native" backend, which is simply a file. This backend (as well as the SQL backend) has an important limitation: The file (or database) will be locked by the first process opening it and other processes will receive an error when they try to access it. Since we want to deploy multiple runtimes of our Talia installation, and since there is no clean way around this feature the native or sql Sesame backends cannot be used in a production environment.

The solution is to install Sesame as a server, which is both easy and adds additional flexibility. You will first have to download the latest version of Sesame 2. What you want is the openrdf-sesame-<version>-sdk.zip file (or the .tar.gz version). When you unpack it, you will find a "war" directory with two .war files inside. Deploy each of them as a web application.

Note: If you want to deploy on a public server, you must also access restrictions on the Sesame applications or put the Sesame server behind some kind of firewall so that it's not reachable from the web. Unfortunately, that's still a bit of a paint, see SecuringSesame

Note: If you secure the server in the recommended way, the workbench will not work. See the "Sesame Console" section below for more information.

You will now be able to go to the Sesame administration workbench, which should be at http://<your server>:8080/openrdf-workbench/ if you went for the default values.

To create a new sesame database for your application, click on "New Repository". You will need to choose the type of Repository - a good choice will be "Native Java Store" for a plain store or "Native Java Store RDF Schema" to enable inferencing.

You must enter an ID (which will be part of the store's URL) and a title for your database. The process will also ask you for the indexes that you want on the data; leave them at their default values for now. Once you have created your repository, you will be shown a "Summary Screen"

Note down the "Location" URL from this screen. You will need it to connect Talia to your repository.

Using the Sesame Console

If you secured your sesame server in the recommended way, the Sesame workbench will not work. However, on the SecuringSesame page you'll find a patched version of the Sesame console tool that will work with repositiories which require authentication, along with instructions on how to install it.

You can find more about the Sesame console on the console documentation page. To create a simple repository, start up the console and do the following steps:

> connect http://<myserver>/openrdf-sesame/ user pass.
Connected to http://<myserver>/openrdf-sesame/
> create native.
Please specify values for the following variables:
Repository ID [native]: test_native
Repository title [Native store]: Test Store
Triple indexes [spoc,posc]: 
Repository created

Configure Talia to use a Sesame Server

To make talia use the Sesame server repository that we set up before, you will have to modify the config/rdfstore.yml file of your application. You will usually only need a server storage for the "production" environment. For development and testing you should be fine with a plain file storage.

Your rdfstore.yml should look something like this:

--- 
production: 
  type: sesame
  location: ./sesame_production.db
  backend: http
  url: <LOCATION URL>
test: 
  type: sesame
  location: ./sesame_test.db
  backend: native
development: 
  type: sesame
  location: ./sesame_development.db
  backend: native

where for the LOCATION URL you enter the URL for the repository, which is the one that was shown in the "Location" field when you created the repository in the sesame workbench.

Configure the paths for the data files

You must set absolute paths for your data (and iip) directories When you use the "default" locations for data files, Talia will store them in a directory relative to the your application directory. Since they are not packaged into the war file, Talia would not be able to find them if you deployed the application to a web server.

Thus, you must give an absolute path to an directory that is readable by the application server so that Talia can find the data. These things are configured in the config/talia_core.yml file. In that file, you should have entries that look like this.

iip_root_directory_location: /var/lib/talia/talia_test/iip/
data_directory_location: /var/lib/talia/talia_test/data/

Note: Remember to check the permissions on those directories and ensure that they are readable by the application server.

Importing the data

Now you will have to import the data with your new settings, to make sure that it ends up in the server-side Sesame database and in the global data directories.

Build the war and deploy

After all the settings are in place, creating your application is a breeze. You'll have different options on how to run your app, see TaliaDeployment for more information.