RE: Development ideas

> From: jpcarr@tredegar.com
>
> First.  The best frameworks to think about are open ones. J2EE and SQL.
> Regardless of the self-interested opinions,  These are the most common
> standards/frameworks to build on at this time.

John, I'd like to respectfully offer a slighlty different opinion of J2EE
for the iSeries.  While I'm not dismissing the concept, how many successful
J2EE implementations have you seen on the iSeries, as opposed to traditional
RPG/COBOL applications?

I don't want to come off as saying J2EE is wrong here.  While there is no
question that my personal opinion is that J2EE is overkill for most
applications, even so I must admit that this particular one - a complete
rewrite from scratch - has the best chance of being successfully implemented
in J2EE.

Why do I say this?  Because there is conceivably little or no connection to
legacy data.  There is a chance that the database can be designed from the
ground up to support an effective J2EE framework.  J2EE applications are
fundamentally incapable of handling legacy databases, but the lack of one
here means that hurdle at least is passed.

However, there are others.  Until you can show a proven methodology for
building an entire application, from soup to nuts, including security,
change management, backup, failover and all the rest, with J2EE on the
iSeries, I challenge the blanket statement that J2EE and SQL is good, or
even common.  Most of us with reasonably long histories of development
experience have a proven methodology for developing and testing in a
procedural environment using RPG or COBOL.  It's not "open" or "standard",
except that it's been used in midrange shops for decades - the time proven
technique of design, analysis, code, unit test and system test, using
standard procedural languages.

It ain't sexy, but it works, and it works with the skill set most
traditional iSeries programmers have today.

On the other hand, a true J2EE application means designing your entire
system from the beginning using UML and working your way down the
implementation tree.  It's certainly possible, and as I said, it may even be
viable here.  But there's a lot of overhead, and the VB programmers ain't
gonna be interested.  So, while it's a possible option, I just don't think
it's NECESSARILY the "best" option.

Joe