Rick.Chevalier@xxxxxxxxxxxxxxx wrote:
I am looking for opinions/reasons, with supporting information, on the use of JAVA instead of RPG to write business logic on the iSeries. The impetus for this request is that our architecture group is suggesting we write any new business logic in JAVA for portability reasons. Keeping our current application code in RPG, just the new stuff. That's what I have been able to ascertain to this point. I know it's not much. The general corporate direction is to move to an SOA architecture with an enterprise service bus (?) handling the service calls between applications.
In know a lot of people out there either use or have experimented with using JAVA on the iSeries. What are your thoughts about doing this?
Okay, you knew I would chime in eventually. So here we go.
When I address this issue, I consider one question to be the most
important: do you plan on leaving your DATABASE on the System i? If
not, then all bets are off, I wish you well, and please drop us a note
from time to time. If you're moving off of DB2 for the i, then any
reason for using RPG (or the System i, for that matter) are gone.
And the architecture group can't say "get off of DB2 for portability".
If you move to Oracle, or SQL Server, or any other database, you have
just as many portability issues. But you need to get this nailed down,
and if the architecture group can't tell you what database they plan to
use in the next decade or so, then you need a new architecture group.
But I digress.
So let's assume you plan to keep your data on the i. Right now all of
your business logic is written in RPG. The biggest problem with RPG is
the ongoing retention of programmers with the RPG skill set. But unless
you plan to rewrite all your business logic in Java, you will have that
issue no matter what. And even the biggest Java advocates will hesitate
to suggest rewriting millions of lines of RPG code in Java, since it has
almost never been done successfully. So skill set is something of a red
herring: until you rewrite everything, you need RPG programmers.
But that's not what your architecture gruop is saying. Instead, they
seem to be suggesting a hybrid approach of Java/RPG, which means that
every time you need to review your business logic, you now need to know
two languages, not one. Not to mention that, generally speaking, for
transaction processing Java is slower than RPG. All of this in the name
of portability, which doesn't make much sense unless they intend to move
the Java code off the System i, including the underlying data. Again,
we return to the fundamental question: where's the data?
If the data is on the System i, then RPG continues to be the best
language to support it.
That doesn't mean, though, that you can't establish a powerful SOA
architecture. I won't comment on ESB; it's a very high-level concept
that requires a rather significant investment. If it's necessary (for
instance in situations with large numbers of dissimilar IT systems) then
it can be very helpful, but it tends to be over-prescribed. In any
case, in order to interface with an ESB, you only need standard web
service capability and it's actually relatively easy to encapsulate RPG
business logic in a web service. With enough time, you can do it in
RPG, you can do it relatively easily with Java, and you can do it with
almost no effort using EGL. The upfront costs for each approach vs. the
ongoing effort is something you have to evaluate yourself.
Finally, despite my endearing love for Mr. Schoen, I disagree on the
idea that your RPG programmers need to learn HTML and all that other
stuff. If you have a well-designed architecture, your business logic
programmers will never care about the user interface. I've been
involved in just such a project, we've created an entire end-to-end Web
2.0 application and I never had to worry about a single line of HTML or
CSS or anything of that. My job was to accept data from and present data
to the UI using web services, and those are skills well within the
capability of any RPG programmer.
That's not to say your RPG programmers *shouldn't* learn other skills;
of course they should. But for example if I had a choice, I'd push them
towards SQL before Java; SQL is much more useful in a business
programming environment.
Joe
midrange.com
