Invoke Prolog from Java

798116

I have code written in Prolog that needs to be invoked from a java class. Could I used JNI to achieve that?

We are currently using LPA/PDC Prolog.

jschellSomeoneStoleMyAlias

Could you - yes.

Should you - I doubt it.

Instead I would suggest the following.
1. Wrap the prolog code as an executable.
2. Add a communications interface to the executable, file based, stdio based or sockets.
3. Test the executable.
4. Use Runtime.exec() in java to manage the executable.
5. Use the communications interface to communicate with it.

Advantages
1. No messing with JNI
2. The two seperate components, java and prolog, can be independently tested.
3. No possibility that the prolog executable can take down the java app. That can't be said for JNI.

798116

Thanks for your insight. Could you please provide more details on lineitem 2 - Add a communications interface to the executable, file based, stdio based or sockets.

I can wrap the Prolog code as an executable. How would I create a communication interface to this executable? I have been able to call a executable using Runtime.exec(...), and use Process.getInputStream() and Process.getErrorStream() to get the output/error. But I am looking for a somewhat more elegant solution.

Also, incase we want to use JNI, how would I create a native library from a Prolog executable.

Thanks again.

JoachimSauer

Ash K wrote:
I can wrap the Prolog code as an executable. How would I create a communication interface to this executable? I have been able to call a executable using Runtime.exec(...), and use Process.getInputStream() and Process.getErrorStream() to get the output/error.

That would be the stdio based interface.

But I am looking for a somewhat more elegant solution.

stdio can be elegant, when done right. Other approaches would be listening on a socket and letting the prolog program connect to you (or vice versa). The actual protocol spoken over the socket would likely be very similar to the stdio-based on, except if you want to use a more heavy-weight, but more standardized technology such as webservices (REST-based or SOAP or ...).

Also, incase we want to use JNI, how would I create a native library from a Prolog executable.

That depends entirely on your prolog environment, you'd have to ask someone who knows about that. Basically, you'd need to have an entry method (or entry methods) that can be called via c-style entry points.

798116

Thanks Sauer.

Joachim Sauer wrote:

The actual protocol spoken over the socket would likely be very similar to the stdio-based on, except if you want to use a more heavy-weight, but more standardized technology such as webservices (REST-based or SOAP or ...).

You have hit the point - we would like to expose the Prolog executable as a SOAP based web-service. One approach would be to wrap the Prolog executable in a Java POJO, and expose the Java POJO as a web-service (JAX-WS based). This would mean input/output messages for the web-service will correspond to input/output for the Prolog executable (stdio). Is the the solution you are talking about? Or, is there any alternative approach? Could you please provide more detail on heavy-weight approach.

Thanks again for your insight.

jschellSomeoneStoleMyAlias

Ash K wrote:
Thanks for your insight. Could you please provide more details on lineitem 2 - Add a communications interface to the executable, file based, stdio based or sockets.

I can wrap the Prolog code as an executable. How would I create a communication interface to this executable? I have been able to call a executable using Runtime.exec(...), and use Process.getInputStream() and Process.getErrorStream() to get the output/error. But I am looking for a somewhat more elegant solution.

When 'elegant' pays the bills then I suppose that it necessary. Myself I find that 'it works' pays them.

But as such I find stdio to be elegant. And perhaps even a bit easier to test than other types of interfaces, and thus easier to plug into unit testing.

jschellSomeoneStoleMyAlias

Ash K wrote:
Thanks Sauer.

Joachim Sauer wrote:

The actual protocol spoken over the socket would likely be very similar to the stdio-based on, except if you want to use a more heavy-weight, but more standardized technology such as webservices (REST-based or SOAP or ...).

You have hit the point - we would like to expose the Prolog executable as a SOAP based web-service. One approach would be to wrap the Prolog executable in a Java POJO, and expose the Java POJO as a web-service (JAX-WS based). This would mean input/output messages for the web-service will correspond to input/output for the Prolog executable (stdio). Is the the solution you are talking about? Or, is there any alternative approach? Could you please provide more detail on heavy-weight approach.

I can only suppose that the intent here is specifically to use Java because you believe it would be easier to use java to achieve that - in other words this is the goal of the project right now?

If so doesn't prolog support that?

854110

Dear Ash

Reading the answers so far I see a proposal to wrap an exe in a service. I guess
this amounts to a CGI like interface between the client and the server. Namely
the Prolog will run as a full process for each query.

You could use a Prolog that supports multi-threading, and define a service
that will run in a thread. You might eventually have more throughput. There
are many multi-threaded Prologs around, SWI Prolog is one.

I have put up a document that shows various simple deployment scenarios
for Jekejeke Prolog. Jekejeke Prolog is also multi-threaded and 100% written
in Java. You can find the report here:

http://www.jekejeke.ch/idatab/doclet/prod/en/docs/10_pro08/13_press/02_deploy/package.html

Best Regards