wftk-j: wftk workflow in Java
11 August 2003: A year or so after its inception, the wftk-j project is underway, with funding from the fine folks at startext GmbH,
in whose offices I am sitting at this very moment.
The general plan for wftk-j used to be as follows:
- Create a JNI wrapper for the ANSI C wftk libraries (XMLAPI, repository manager, core wftk API).
This JNI wrapper will include the native Java implementations of the basic wftk class schema (this became the abstract Repository class).
- Cobble together some kind of servlet front-end using the JNI wrapper. (We started addressing this during my stay in Germany, and startext
is contributing an initial Tomcat JSP front-end using the Java wftk client.)
- At some point in the misty future, start porting code into a native Java implementation. Since JNI wrappers already consist of full-fledged
Java classes, some of whose methods happen to be implemented in other languages, it should be a simple matter to progressively switch out native
methods with pure Java on a piecewise basis. Do that long enough, and you end up with a Java implementation of the wftk.
August 25, 2003: The plot thickens. Once I finished the SOAP adaptor, and we all saw how very
simple indeed it is to set up a simple SOAP server under Python (which I used to test initial versions of the adaptor), a sort of phase change happened,
and a new(ish) plan arose. Now, this is how we're proceeding:
- Create a simple SOAP object: this is actually done already.
- Continue work on the JNI wrapper for the wftk libraries, but not at such high priority, because:
- Create an abstract repository class which will have two implementations: RemoteSOAPRepository and LocalJNIRepository (and of course in the future
we can envision any number of implementations, which is the beauty of Java in the first place.) LocalJNIRepository will simply be the JNI wrapper for
the current C-language repmgr library, while RemoteSOAPRepository will wrap up all requests and ship them off to a SOAP server, initially written in
Python, but subsequently of course implemented in any way we like.
- Some pure-Java work will already be underway (the groundwork is already being laid) so that at some point, native C-heap XML objects will only be
maintained if necessary for communicating with the local JNI-wrapped libraries, while a general client will have no native dependencies at all. This
means that clients may already be pure Java earlier than servers may be -- which is fine. A wftk applet library would be a tremendous addition
to the toolset without requiring any server functionality at all.
So this is a pretty neat plan, I think.
The present implementation breaks down into several sections:
- xmlobj.java wraps the XMLAPI with two classes, xmldata and xmlobj, and the native methods for these classes end up in xmlobj.c. The initial code structure for xmlobj.c was generated in the approved way, with javah.
- simple_soap.java provides a very thin SOAP layer, which relies minimally on the xmlapi-j for parsing and navigation of the result XML. This would motivate a pure-Java implementation of this minimal functionality in the near future.
- repository.java is the Java definition of the repmgr OO schema, essentially comprising the rest of the wftk.
- repository_soap.java is the remote SOAP implementation of the repository class.
- repository_jni.java is the local JNI implementation of the repository class, and its native methods will end up in repository_jni.c.
- wrappertest.java is a simple Java console app which runs tests of the whole shebang (initially, it was just a wrapper test, you see). The point, of course, is that wrappertest neither knows nor cares that the methods of the classes it uses are native or Java, local or remote. Which is cool.
- The javadoc-generated usage docs are the place to start if you simply want to run the Java client from within Java.
Onwards.
This code and documentation are released under the terms of the GNU license. They are
additionally copyright (c) 2003, Vivtek. All rights reserved except those explicitly
granted under the terms of the GNU license.
|