Andrew McLaughlin wrote:
>
> Hi Diego,
>
> I'm a little dense in this area, can you break down the components? I'm thinking
>that I'll
> have to write my own software on the server side to be able to select data as well
>as do
> the normal I/O. While UniData does have a C adapter so that I can access the data
>files
> from Unix I'm not sure what else that I would have to write to complete the chain.
>
> Is JNI (Java Network Interface)? Just guessing. That's a new one for me.
>
I'll try to be less terse this time.
First, RMI is a great solution, much simpler to code than say RPC's
for developing client/server interfaces. The only complication is that
to support legacy systems not written in Java, you will need to create
a (non-portable) bridge using JNI (see Dan Kirkpatrick's response to you).
JNI allows you to interface with the C language, having thus access to
the underlying operating system or application interfaces in C.
As D.K. says, in JNI you have to map Java classes to C structures on
the output arguments, and C to Java on the input arguments, all the while
checking for errors at each step. This is a lot easier to say than to do.
Most errors will cause the JVM to dump a (most enigmatic) core.
Given this difficulty, I suggest to minimize the number of JNI functions.
One way is to create a mega-call in JNI where the parameters are a command
and a related argument list as strings, in a way similar to ioctl() calls.
A typical API would then be handled in this way:
my_jni_call(..., OPEN_CMD, arg, NULL)
my_jni_call(..., READ_CMD, arg, argsz)
my_jni_call(..., WRITE_CMD, arg, argsz)
etc, etc.
While this goes against elegancy in design, it will add to the robustness
of the product by eliminating error-prone Java<->C mapping code.
Unfortunately, this came to me only after writing about 3000 lines of
the interface code.
I suggest reading "Core Java, Volume II", by Horstmann and Cornell for
both RMI and JNI examples and references.
--
Diego Pons Pharos Consulting LLC
