RE: framework questions/Remote data access -- JAVA400-L

> From: Paul Holm

Paul, I'm not going to get into a long discussion here.  I am going to
address a couple of your issues, and then I'm going to discuss a larger
issue which is constantly missed when people talk about this.


> d)       It doesn't leverage the power of SQL/JDBC.  Using dataqueues,
how
> do you get the data back and forth from mother to children?

I'm not sure where you got the idea that I couldn't or wouldn't use SQL.
The server can do whatever it wants to do in the background.  As to the
power of JDBC, what exactly IS the "power of JDBC"?  If you haven't
figured it out yet, I'm about to start a tirade against buzzwords and
FUD.


> d.       Many, many other features that SQL provides by default.

As I said, the server can use SQL.  So can we just wipe out this entire
round of "reasons"?


> e)       Multiprocessing.  Would this architecture restrict us to each
> child
> server program synchronously handling each DQ request?  JDBC would
allow a
> multi-threaded approach.

The next bit of FUD.  Paul, please provide a real way this improves
performance on the iSeries.  Since I could just as easily have multiple
child server jobs, the multi-threading issues are moot.  Please,
multiprocessing is what the iSeries does best.


> d.       In a mixed model with Java calling RPG, how do you get these
> business rules available to be leveraged by your UI?  Do you have to
now
> kinda of create a dual business model logic?

If it's a business attribute, it gets derived in the server and passed
in the message.  If it's purely presentation logic rather than business
logic, then it belongs in the UI.  Or are you unclear as to how that
works?  This is a really specious argument.


> g)       Non strategic approach.  IBM and the industry are investing
in
> SQL/JDBC/Java and much less in native IO and dataqueues.  Long term
> maintenance of RPG may be an issue as skill bases become dominated by
> Java.

This is definitely FUD.  We've been hearing about the death of RPG and
the IBM midrange for nearly 30 years now.  Please find another dead
horse to beat.


> You are also not able to fully leverage the growing array of JDBC
based
> persistence APIs and other Java components.

More FUD!  The Java components I want (the UI stuff) are all available
in a JSP/servlet UI.  As to persistence APIs, the best ones they have
are stuff like Hibernate, which is write-cached, which means if you lose
your JVM you lose your updates!

WHY WHY WHY WHY would I want to move my mission critical systems from a
native I/O environment with almost zero faults to something that can
lose data anytime the JVM hiccups?


> h)       Productivity or a lack of it.  I may be missing something,
but I
> don't understand how a procedural approach to persistence in RPG along
> with
> business rules procedurally enforced can be done in a productive,
flexible
> manner.  I may be missing something but typically we can create the
basic
> functionality that Aaron mentions (A/R inquiry, updates, Sales,
Security
> based on client,etc) in a day or two.  How long would it take us in
this
> procedural model?

Okay, now on to this stuff.

Paul, you can create a nice file maintenance suite in a quick manner.
So can anybody.  I can do the same thing with a few decent skeleton
programs.  In fact, I can set up an entire client/server system in about
two days that has people cranking out applications with far more
capabilities than your stuff.  I just did it for one of my clients, and
they're thrilled with the speed (not to mention the security).

The problem with code generators is that they tend to code the 80% of
the function that takes 20% of the time.  But then you're left with the
20% of the programming that takes 80% of the time: stuff like
hierarchical pricing structures, by-product analysis, standard cost
rollups, MRP generations, WIP costing, line scheduling and all of the
other stuff that actually requires more knowledge than looking at a
field definition and figuring out how to show it on the screen.

What I'd LIKE to do is to ask that from this point forward we separate
business applications into a few simple categories:

1. Master File Maintenance

This includes the Work With types of inquiries, as well as the popups
for valid values and all that crap that we're used to in our file
maintenance programs.

2. Enterprise Information Inquiries

These are inquiries that support JOINS among multiple files, with
various levels of totals and breakouts, the ability to drill into
values, the ability to easily change selection and order criteria, and
so on.  Add-ons are PDF and XLS generation (and nowadays XML
generation!), email capabilities, web services interface, graphing and
so on.

3. Transaction Processing

This involves any of the meat and potatoes types of programming that
actual requires programming above the junior level.  MRP generations and
line load scheduling are great examples.  Pricing algorithms, even sales
forecasts, can all fall into this category.  This sort of processing is
driven by database flags, typically retrieved from various levels of
master files.  Processing is intense and rules-based, and the rules are
often changeable based on external conditions.

With these three types of processing, it's clear that different tools
are probably better for different jobs.  For example, some sort of tool
can be used to generate master file maintenance programs; we've been
doing that for years both with generators and with skeleton programs.
The current generation of application development tools make this
particularly easy.  The EII class of applications is almost certainly
best done with an SQL approach, and depending on issues of security and
scalability, a pure JDBC approach may be in order.  But for the third
classification of transaction processing, I am still clearly convinced
that procedural languages and specifically RPG are more flexible, more
maintainable, and more productive than OO languages.

Joe