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 = ModelRDB.open(jenaConnection);
//do some useful work, then tidy upBusiness 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.
Lost Boy 