Using Jena in an Application Server

I’ve been lurking on the jena-dev mailing list for a while now, and I’m constantly impressed with the level of patience displayed by the jena team at handling repeated questions and queries. This is despite the comprehensive documentation which covers all aspects of the toolkit.
Often these queries stray outside the realm of RDF and Jena into basic questions such as “how do I write a JSP or a web application”. Makes me wonder if there’s been a sudden increase in the number of undergraduate semantic web projects. Anyway one question I’ve seen quite often recently is “How do I use Jena within an Application Server?”
Here are some notes and pointers that may help answer that particular question. I don’t have time for a complete tutorial, but hopefully the following pointers may be sufficient to get your oriented.

The Database

I’ll assume that you’re going to be working with data held in a relational database. In Jena terminology this is known as a “persistent model”.
The Jena team have created a HOWTO on using persistent models. See that page for detailed database configuration options and pointers to database specific documentation.
You don’t have to worry about creating the relational database structure into which your RDF data will be stored. Jena will do that for you automatically once you create your first persistent model. This makes it very simple to get up and running.
The persistent model HOWTO contains example code that shows how to create and configure a persistent model.
However within an application server the code you’ll write is going to be slightly different: you’re going to need a connection pool.

Connection Pooling

All Java application servers allow you to configure a database connection pool, the specifics vary from server to server so you’ll need to consult your server documentation to find out how to do that. Here’s the Tomcat 5.5 JDBC data source documentation. You should be able to find similar documentation for JBoss, Weblogic, et al.
Once correctly configured a connection pool will allow you to do a JNDI lookup to obtain a DataSource from which you can create a Connection.
Creating a Jena Model is then simply a matter of instantiating a DBConnection. Here’s a code snippet which illustrates this:

// Obtain our JNDI context
Context initialContect = new InitialContext();
Context env = (Context) initialContext.lookup("java:comp/env");
// Look up our data source
DataSource dataSource = (DataSource)env.lookup("jdbc/MyDataSource");
// Allocate and use a connection from the pool
Connection connection = dataSource.getConnection();
//Create a Jena IDBConnection
IDBConnection jenaConnection = new DBConnection(connection, "MySQL");
//use open for an existing model, or createModel to create a new one
Model model =;
//do some useful work, then tidy up

Business Logic

So far we’ve looked at creating connections and opening a Model to get access to the persistent data. For example you may navigate through the model using the Jena API or query it using ARQ the SPARQL query engine built upon Jena. More information on how to do that can be found in Phil McCarthy’s “Search RDF data with SPARQL” tutorial.
The context within which this code lives will depend on the overall architecture of your application.
If you’re just writing a simple Java web application that uses servlets and/or JSPs then you’ll want to structure your code so that the logic is in a servlet or utility code accessed from a JSP, ideally a tag library. This avoids mixing up your user interface code with your application logic. To ensure that your connection pool is available to your web application you’ll need to configure a resource reference in its web.xml
However if you’re writing a full J2EE application that uses EJBs, then you’ll want to do all of your Jena manipulation from with a bean. As J2EE Container Managed Persistence is designed for relational databases and not triple stores, you’ll have to use Bean Managed Persistence. In other words write the database manipulation code yourself.
Personally I’d suggest going with a Session bean that delegates to a Data Access Object to do the real work. Your Jena specific code will then be relegated to a small manageable layer in your application. In this scenario you’ll need to configure the bean’s deployment descriptor to ensure that it has a resource to your connection pool.
Hopefully that’s some useful pointers that’ll help get you started.

Notes on Creating the WebJay API

Am catching up a bit here as I’ve been on holiday and then away travelling over the last few weeks. Lucas Gonze has written up an excellent response to my XTech paper discussing the design decisions and trade-offs he encountered whilst designing the WebJay API.
This was exactly the kind of discussion and sharing I was hoping to trigger. Gonze makes a few other points, notably about problems with web frameworks and client libraries in this posting to rest-discuss.
I should also apologise for not highlighting WebJay’s use of XSPF in my paper. Gonze rightly points out my omission. I found WebJay to be the simplest and most elegant API that I reviewed.
I think I may give it 12 months or so and then take another trawl back through available services and see whether the state of the art has moved on at all.
In his write-up Gonze notes that: I just realized while I was working on this document that there’s no way to get from an XSPF playlist on Webjay to the FOAF profile of the creator; ideas on how to fix that are welcome.
My suggestion is as follows:

  • Provide a FOAF export of the WebJay profile information. There’s enough data already captured (name, email, homepage) to create a minimal profile with enough IFPs to allow it to be easily merged with other data on the web. This will also provide a hook if a user doesn’t have their own profile
  • Give the WebJay FOAF profile more utility by providing links to a users playlist metadata (perhaps via an XSPF-RDF conversion).
  • Revise the WebJay account management form to allow a user to enter a link to another FOAF profile, e.g. one they maintain themselves. This would be rdfs:seeAlso‘d from their WebJay FOAF document
  • Revise the XSPF export to include a hook to the WebJay FOAF description. As XSPF uses namespaces, I’d be inclined to just add FOAF terms directly, e.g. a foaf:Person element and rdfs:seeAlso link to the profile. The alternative is to create a new custom element to link to additional metadata about the user.

I think that covers all the bases: adding additional coherence to the WebJay API by allowing navigation between users and playlists, whilst also allowing navigation from WebJay metadata to other documents on the Web, i.e. a users FOAF profile. As Audioscrobbler also provides a FOAF export of its users metadata, some interesting application possibilities begin to open up, e.g. recommending playlists based on a users listening habits. See the section, “Connecting Social Content Services” in my paper for some relevant further discussion.

Goodbye XML-Deviant

I see Micah’s latest XML-Deviant is up on this week, and its also to be the last in the series. It’s a shame to see it go as I’ve enjoyed reading the column over the last few years. I also thoroughly enjoyed contributing to the column during my own period of XML-Deviancy. But all things come to an end; I’m looking forward to seeing what replaces the column in future.
Tip of the hat to the other XML-Deviants: Edd, Kendall and Micah for all of their efforts along the way; especially Edd for originally conceiving of the column.