Monday, November 12, 2007

Jena tip: importing ontologies from the database

Today I wrote a short tutorial on using the Jena OntDocumentManager to allow OWL imports to be resolved from ontologies already stored in a local database.

del.icio.us: jena, java, semantic-web, how-to.

Wednesday, November 07, 2007

RESTful web services book

I've tended to assume that I understood the REST vs SOAP distinction in web services, though as it has turned out most of the WS work I've done up to now has been in SOAP/WSDL territory. So REST was something I'd read blog posts about, but not used seriously. Today I got a copy of Leonard Richardson and Sam Ruby's book RESTful web services. Julie our admin dropped the newly-delivered book off at my desk about 9.30. As I usually do, I flicked through the contents to get a sense of the book before parking it on The Pile of things Intended To Be Read (eventually). A few hours later I'd read the first four chapters thoroughly and skimmed the rest of the book. This is a really well-written book, striking – for me – the perfect balance between explaining the principles and showing the techniques. Too many other CS text books either give you recipes to follow slavishly and leave you to reverse-engineer the principles, or else they part company with the ground and never return. Anyway, big kudos to Richardson and Ruby for a job well done.

So, I now get REST. I don't know that I completely buy all of the arguments, but only because I have a research interest in automation and agent systems, and I think those need more scaffolding. It seems to me that REST works particularly well – and the book makes a compelling case that it does – when you have a team of human developers trying to build usable, useful applications to deploy today. That's a big and important aim, no doubt, and good luck to them. However, if you want to build an autonomous system over a web services foundation, I think you probably need some of the things that SOAP and WS-* were reaching for. The problems with Big Web Services, as I see them, lie in the imperfect execution of the design and specification processes, rather than being fundamentally in a blind alley. I haven't (yet) caught the meme that REST good, Old School web services bad-in-principle. That being said, I think it would make an interesting investigation to think about layering an agent architecture over a RESTful base. Something to work on. Oh, and WADL looks interesting – something else to follow up on.

Richardson and Ruby's book is O'Reilly, so they have an animal picture on the front cover. In this case, a vulpine phalanger. Is that obscure or what? Note to self: write book for O'Reilly before all the cute animals are taken, and you're left with a choice of slug, horsefly or amoeba!

del.icio.us: web-services, rest, book, ruby, web, architecture.

Friday, November 02, 2007

JavaFX in Eclipse: mini-HowTo

I've been meaning to explore JavaFX for some time now, and decided to spend a couple of days on it this week, as part of an investigation for an ongoing semantic web UI project. My Java development environment is Eclipse, and since I had to jump through a couple of hoops to get JavaFX working in Eclipse, I thought I'd document the steps here.

  1. Install JavaFX locally. I downloaded the .tgz archive from the OpenJFX site. Beware that there's no top level directory in the archive, so create a directory first, for example /usr/share/java/openjfx, and cd there before un-tar'ing. I haven't checked that the .zip file has the same issue for Windows users, but I'm guessing it does. I'll refer to this directory later as $JFX.
  2. Install the JavaFX plugin for Eclipse in the usual way from this auto-update site:
    http://download.java.net/general/openjfx/plugins/eclipse/site.xml
    (see also step-by-step instructions)
  3. Create a new Java project (there's no JavaFX-specific entry in the New context menu for new projects, but that's OK). In the source folder, create a new JavaFX file from the New context menu (right-click » New » Other » JavaFX » JavaFX file).
  4. Add some source code to the file. My test file is, imaginatively, test1.fx. I added one of the standard tutorial examples:
    import javafx.ui.*;
    Frame {
        title: "Hello World JavaFX"
        width: 200
        height: 50
        content: Label {
            text: "Hello World"
        }
        visible: true
    }
  5. Note the sytax error: Frame is not recognized (well it wasn't for me, anyway). Solution: add the JavaFX libraries to the build properties. The plug-in adds a library to the User libraries of Eclipse: I guess that in future releases the library will be automatically added. Also, if your downloaded copy of JavaFX is newer than the plugin's, you could reference the libs in $JFX/trunk/lib here.
    Update: Don't remove JavaFX and add a different library (for example JavaFX-local) that references different versions of the Java fx lib .jars. It turns out that the current version of the plugin will automatically add a JavaFX library if there's not one in the build path when you try to launch the app. Having two sets of JavaFX jars makes things break in an ugly way. I've reported this as a bug.
  6. To run the example, there's no 'run as JavaFX' from the context menu of test1.fx. Instead, click Open Run Dialog..., create a new entry under JavaFX Application, and enter the name of the fx file to run as an argument to the JavaFX runner:

    Save the run config, then run the application.

del.icio.us: javafx, java, eclipse, howto