- These list items are microformat entries and are hidden from view.
- https://dltj.org/article/fedora-client-jar/
- 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/trunkThe 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.
- 2006-06-02T17:23:30+00:00
- 2018-01-03T03:34:57+00:00
Client JAR for FEDORA Server Access
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.
