Client JAR for FEDORA Server Access

 · Peter Murray
Last updated: June 02, 2006

At OhioLINK we've reached the conclusion that coding would be easier if we created a modestly robust JAR file that is an implementation of the AXIS-based web services interface to a FEDORA server. Our initial effort is ready for public consumption; you can check it out of our Subversion repository at:

http://drc-dev.ohiolink.edu/svn/FedoraClientJar/trunk

The JavaDocs are available at:

http://drc-dev.ohiolink.edu/javadoc/FedoraClientJar/

If you ask the OhioLINK team, they'll tell you that the API has undergone significant changes in its young life, but I think it will settle down now. Some features:

  • The client library and nothing but the client library (distinguished from the core developer's client library in that there is no Swing presentation code mixed in).
  • Good embedded JavaDocs for all packages, classes and methods. (Some of the descriptive and proscriptive elements could be better, and will probably improve with age.)
  • A single class that contains both API-A and API-M remote methods.
  • A class that helps with searching the Resource Index through the REST interface. (It only implements the "find tuples" returning results as a CSV stream at the moment.)
  • A factory-based method for instantiating classes that hopefully will be extensible and easy to use.

To Dos:

  • Implementing mock interfaces for the methods to enable unit testing of client application code without needed to start a FEDORA server. (The stubs for this are already in the packages.)
  • JUnit tests of the "Live" interfaces against a pre-configured FEDORA server.
  • Adding a class to help with searching the native FEDORA index (and probably Gert's General Fedora Search Plug-in as well).
  • Adding more helper methods (such as use of the file-upload servlet).

I'm also toying with adding JavaBeans and DAO pattern classes as well. If someone already has these in a client-side implementation and would be willing to offer them to this code library, our team (and probably many others) would appreciate it.

Comments and code contributions are welcome.