10 replies to this topic

[si_ddharths1]

Hi,
Has anybody ever called a jaava programme from proiv through a C wrapper.

Hope to get some replies soon.

Cheers,
Siddharth

[Richard Bassett]

I'll be happy to be corrected, but I don't believe you can do this.
You can call C from Java ("JNI" ISTR) but not vice-versa.
Ask yourself - where is the JVM going to come from?

[Paul Blew]

Siddharth,

From the first line of the first page of the Java JNI Docs:

Java Native Interface (JNI) is a standard programming interface for writing Java native methods and embedding the Java virtual machine into native applications.

I'm sure you could build an interface that you could access from PRO-IVs LINK command.

I think you're going to need a C guru though.

Regards,
Paul

[Richard Bassett]

OK, thanks Paul, I'm happily corrected. I'll go and RTFM

So, if we can successfully incorporate a Java Virtual Machine into the ProIV kernel, we could then maybe find a way to make LINK() call Java methods. Or maybe execute applets..?

This is likely to be a LOT of technically difficult work to do properly. Frankly I wouldn't fancy it much - and I am allegedly a C guru

Realistically Siddharth, I would guess it's more something ProIV themselves might look at the feasibility of (maybe they have) rather than something you could sensibly take on as part of application development.

Edited by Richard Bassett, 05 October 2004 - 11:30 AM.

[si_ddharths1]

Thanx for your replies.

[Wayne Biggs]

Siddharth,

We developed a 'C' interface to a Java servlet using sockets to pass requests back and forth. The 'C' routing is linked to the pro-iv kernel as standard and we use LINK('command','resultstring') to pass in the required command. The java servlet then calls the relevant classes, passing data back through the socket to the 'C' routine and then back into pro-iv.

Obviously, it can't be used to call arbitrary classes within the java servlet but if you are looking for a short-term solution then this may be the quickest (although you will still require a 'C'/Java comms expert to develop the socket interface).

HTH,

Wayne

[Richard Bassett]

Wayne makes a very good point Siddharth.
If you are happy for your ProIV process to act as a 'client' making some kind of 'remote procedure call' to invoke the Java you need then there might be various possibilities. I must stress I have not done anything like this and I am not aware of anyone who has. You would need to research carefully what is actually possible and how much work is involved.
However, the kind of things I'd guess might be feasible are:
C in ProIV making calls out to CORBA objects implemented in Java?
C in ProIV making calls out to Java beans in some EJB server?
C in ProIV making calls that appear to the callee as Java RMI calls?
C in ProIV making calls out using 'Web Services' technologies that invoke some Java?
C in ProIV making calls out on any RPC mechanism able to invoke Java at the remote end?

[Cleve Haynes]

C in ProIV making calls out using 'Web Services' technologies that invoke some Java?

Hi Richard

This is almost what we are planning to do.

For outgoing communication we are going to embed a http client in the ProIV kernel so we can use SOAP to interface to other systems by using LINK commands.

For incoming communication, we already have a SOAP module running in Apache which takes a SOAP message and then calls a ProIV task specified in the SOAP message. The logic in the web server knows nothing about the task it is calling, so we can create new interfaces without any code changes to the Apache module by simply creating a new SOAP message and a new ProIV task.

We have a guy who is a pretty cluey C programmer that does a lot of this stuff for us.

This strategy should greatly simpify all the inferfaces that we currently have, which are a horrible mixture of socket sends, file read/writes, and reams of c++ code trying to make Corba work.

Cleve.

[Richard Bassett]

Sounds fun Cleve! Good to know people are working on this stuff.
I can see this allows Java but it sounds almost like you are "wrapping" ProIV Bus+Task in Web Services, is that right?
As a matter of interest, what approach are you taking to transactions (database transactions that is) with this stuff?

Edited by Richard Bassett, 11 October 2004 - 10:46 AM.

[Cleve Haynes]

I can see this allows Java but it sounds almost like you are "wrapping" ProIV Bus+Task in Web Services, is that right?
As a matter of interest, what approach are you taking to transactions (database transactions that is) with this stuff?

We are not planning to use Java (did I mention I hate it? ) Just C & perhaps PHP for some other outgoing interfaces.

Yes, we are effectively wrapping ProIV Bus & Tasks in a web service.

As for transaction management, that is an entire other project going on that is too much to write in here! Basically this project is to write a new transaction management engine to handle any system updates (from internal or external sources). You don't want to perform system updates using Bus & Tasks if that transaction takes too long (since B&T is synchronous), times out, etc, etc. What we do instead is when the Task runs, it does validation, then writes the transaction data to a queue and then returns a return code to the web server. The background ProIV "transaction servers" then process the transactions.

Cleve.