× 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.




Hi Erin,

I never trust my first, off the top of my head reactions (that doesn't
mean they're never right, just should be reviewed,) but I'm kind of heads
down coding at the moment, so here goes:

First, depending on your time frames and requirements, you may need a
short term and a long term strategy.

Your primary issue is interprocess communication (IPC) from a high
level, and you should review the various ways that can be accomplished.

My first inclination is to have a Java intermediary, standalone or in
WebSphere (or other server,) that communicates with your vendor data. Once
you have it, then you have options to get it to your legacy programs. These
range from writing the data out to files that mirror what your legacy apps
expect, to writing to data or message queues. There are upsides and
downsides to any approach, as usual.

I'm going to leave it at that for now, may have more time later.

Two pieces of free advice, guaranteed to be worth what you paid for
them:

Since your team "do not have any experience in the techniques or
technical implementation options," get some reliable (in all ways) resource that does.

Remember that slower is faster. Doing it as right as possible now
will save grief, problems and dollars later.

Good luck!


Joe Sam

Joe Sam Shirah - http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International? http://www.jguru.com/faq/I18N
Que Java400? http://www.jguru.com/faq/Java400

----- Original Message ----- From: <EStrobel@xxxxxxxxxxxxxxxx>
To: <java400-l@xxxxxxxxxxxx>
Sent: Tuesday, December 23, 2008 10:37 AM
Subject: RPG to Java-based Services


We are in the process of implementing a new policy admin system under
Insurance Application Architecture (IAA) and some third party software
components we've purchased and can no longer directly access a database
file to get the data we need for legacy systems. This is a rule by the
vendor - all data within their components must be retrieved via their Java
based services - no direct access or SQL. However, all of our back-end
systems (Billing, Claims, etc) are written in RPG and Synon RPG. We need
to integrate this new policy admin system with the old back-end systems
and do not have any experience in the techniques or technical
implementation options to make this happen.

My job is to figure out how to do this - have our legacy RPG/Synon based
applications access their Java based services - what methods are possible,
pros/cons, performance implications, etc. These "services" can be exposed
as either web services (SOAP/HTTP) or EJB2 RMI. I believe at the moment
they are EJB's and are remote - they will not reside on the same physical
box as the RPG code. The platforms of each box more than likely will be
different: Our legacy RPG code is on an iSeries, and the Java based
services will be deployed within Websphere Application Server on Windows,
AIX or Linux. More often than not, we'll need to send in parameters, and
be able to get back all of the relevant data we're looking for.

Any ideas or experiences?
Erin L Strobel
Information Services - Programmer
Church Mutual Insurance
1-800-554-2642 Ext. 4947
--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.