RE: framework questions/Remote data access

Joe,
        I also hold a high dislike of buzzwords and FUD.  Everything I say I can
back up and prove.  In terms of business application development, there are
really only a few goals that slightly adjust depending on the particular
business.  "Create software the solves business problems both short term and
long term in the fastest, most flexible, most maintainable way."

1. I got the idea you didn't recommend SQL be used for Aaron's problem
because your recommendation to him discussed enqueing requests on a DQ and
waiting for a response on a que or message.  This doesn't sound like SQL or
JDBC to me.  If you'd advocate SQL in this case, I would agree.  It seems
you are normally advocating RPG IO or record level.
2. You neglected the key design and architectural issues that I discussed.
This is where true value to Aaron and your readership are involved.
3. The power of JDBC lies in the comprehensive data processing support that
SQL provides such as:  date arithmetic, mathematical formulas, summations
(SUM, AVG, GROUP BY), user defined types, subqueries, joins, inner joins,
outer joins, exception joins, RI, etc.  I could go on here but it is better
to look at IBM's SQL manual.  People are normally shocked at what can be
done with SQL today.  The alternative to this using writing the code to
mimic what is already there for you.  This approach is not productive.

JOE:  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"
4.  Joe, yes, you could have multiple child processes but you would have to
write code to manage how many servers to start, how to get the data back to
the requester, etc.  So YES, you could do it but NO you could not do it "as
easily".  I believe in utilizing the IBM supplied functions wherever
possible.  It does not seem like a good idea to recode what is already
there.  If commitment control and journaling are needed which they are not
in many cases, why would you "write this in RPG as you mentioned".
Joe:
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.

5.  My problem with your architecture, is yes, you could "pass it back in a
message" but how do these business rules get surfaced to the UI for
enforcement as I asked before.  For example, on a PO the customer name is
required for any insert or update.  There are many rules which your UI may
need to enforce.  Without a OO model you are forced to implement this
manually in a procedural fashion for each business object such as Customer,
Invoice, Purchase Order, etc.  If you put this logic in each JSP you must
duplicate for each UI enforcement.  Actually the nature of this response
indicates a possible incomplete understanding of OO.  As Marc mentioned,
truly understanding and leveraging OO takes a while and in the 400 community
few people have had a chance to work with OO enough to fully understand it.
Teaching, writing, and presenting don't necessarily indicate a high level of
OO knowledge.  I have seen many IBM classes with instructors that are foil
readers.   The fundamental issue remains that without a OO model on your
Java side, I don't see how you can do anything productive besides code each
function and JSP in a repeated manual process which is very unproductive.
6. I didn't say RPG would go way, I said IBM is putting much more money into
SQL side than native.  RPG will remain for a long time just as the horse and
buggy have.  I agree on the iSeries RPG processing can run faster than Java.

Joe:
.  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).
7. I'm 100% convinced your server-client model could not achieve anything
even close to the productivity and features of our framework in any of the 3
models you mentioned.  There is no way it could with your procedural
approach.  I may be wrong but I doubt it.  Get a neutral party to put
together a spec (we could even use Aarons) if you want to challenge me.
The benefit to the newsgroup is they could see the differences in
development speed and flexibility of the OO approach versus this mixed
approach.   Many shops are trying to make this decision right now and it is
an important one.
8. I'm not saying your approach doesn't work, I'm at a lost how you can be
productive with it.

Respectfully,  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