RE: Java versus RPG on iSeries

> From: Richard Dettinger
>
> 0) What is a business application?  Yeah, I'm serious... I guess I don't
> know.

A business application is a living, breathing entity that changes in
response to the changing requirements of a real, live business.  The rules
change, sometimes drastically, in response to external conditions.

> 1) What makes middleware a highly definable problem set?

Middleware is in large part a transport layer, and as such handles
translation, be it from one layer to another in the application, one tier to
another in the network, or one data format to another, such as XML to HTML.

> 2) What makes business applications not highly definable problem sets?

Again, it's the dynamic nature of the business problem space.  A person
today is a vendor.  Tomorrow they may be a customer.  Unless I understand
that today, my class hierarchy may require a major overhaul tomorrow.
Unfortunately, today there is no base to work from: no two businesses can
agree on what a "calendar" is, much less a customer.  And thus, OOP may
require a lot of rework when the business paradigm shifts, whereas a
procedural program simply requires rewriting the affected piece.

This is not top say it cannot be done, Richard!  It's just that I have seen
very few valid implementations.

> 3) What makes business applications complex and changing?  And the
> middleware problem space isn't changing?

The static nature of middleware makes it very amenable to the rigid
definition requirements of a proper OOA/OOD/OOP development cycle.
Formatting HTML is a static problem set.  Defining, say, order pricing is
not.

> 4) In what possibly way is OOP "in general" a bad idea where the problem
> set is complex or changing?  That seems like the ideal environment for the
> OOP paradigm.

I disagree.  It depends upon the level of change.  If it's merely
implementation level, then OO is great.  OO is in fact very productive once
you define your hierarchy.  But if your hierarchy changes regularly, then
OOP is a bad programming choice.  And while you may possibly be able to
develop a hierarchy that is so flexible and extensible as to support any
possible business rule changes, the amount of effort required may outweigh
the benefits of the OOP development process.

OO is nice when you can reuse your own code.  But OO really shines when you
can build on the work of others, thereby eliminating the prodigious startup
costs associated with an OO project.  Unfortunately, there is no common
ground on which business application developers can stand to share object
definitions.

Richard, this is simply my take on it.  I believe that with a proper focus,
a consortium of business application designers could possibly develop a set
of interchangeable business objects that would form the base of an OO
business framework.  This could then be used by application developers as a
basis for the next generation of application design.

Unfortunately, this has been attempted twice that I know of (San Francisco
and ODMG) and neither was particularly successful.  Until application
designers can agree on these fundamental objects definitions, I think OO is
simply an added layer of complexity to the business application development
process.

Perhaps my experience is tainted by being involved with some of the most
successful RPG business applications ever written.  I guess I know what RPG
can do, and I know what happens when people attempt to migrate business
applications to the OO paradigm.  But I'm amenable to changing my opinion.
Once I see people achieving the same level of success with Java as we have
had with RPG, then I'll rethink my position.

Joe