×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Richard Schoen wrote:
We have a batch RPG job that calls a Java class which interfaces into
our Enterprise Workflow web service and it seems to work fine and it's
fast after initial startup.
It also depends on what kind of horsepower the system your run it on has.
Of course, for a batch job it's not so much of a issue ... as resources
are allocated to batch jobs differently than interactive.
When I was initially playing with calling Java from RPG, the bulk of the
invocations I was looking at were from interactive jobs. I didn't want
to subject the user to the startup penalty. Plus, every user would have
to have their own JVM instance ... chewing up system resources.
We decided to go with a tcp/ip sockets implementation that talks to our
java server. The java server receives & responds to the requests. One
instance of the java application, very lightweight native code
requirements.
The initial design was a bit involved (I was learning both java and RPG
sockets at the same time), but we wrappered it quite nicely (love love
love service programs). The server can run on the System i or a PC (or
unix server).
We send a request from the RPG app to the java server via tcp/ip ...
simple requests are answered directly on same connection ... bulk data
requests are written out to specific database files using jdbc.
Note: What I'm describing is different than the data queue based
mechanism that I described earlier.
The only drawback is you need some familiarity with Java, RPG and how
they work together :-)
Drawback? Ha! That's the advantage. Something new to learn.
In todays world: You snooze you loose ... and that goes double for the
technology world.
david
midrange.com
