RE: Look Mom - No Application Servers

>This presupposes that you are doing as much code in Java as you are in RPG<
and that the Java code changes as often as the RPG.  With a proper
framework, this isn't the case.  Sure, you need to manage and distribute the
code, but with a good framework, you'll do this LESS often than writing it
all from scratch, because you don't have the constant change associated with
reinventing the wheel.

You're switching gears on me. I am talking about the cost of implementing a
new language into an IT dept. I agree with what you have said, but we are
not talking about the same point. Sure once everything is implemented with
Java you will have much more libraries to pull from, but it is getting to
that point that is painful.



>If your RPG folks can't understand the code in a simple JSP framework,
there's no way they can write a SOAP envelope.

I very much disagree.  You have been doing Java a long time. An RPG
programmer coming onto the scene has never heard of a "Collection" or a
"String" object. They have no idea what a JavaDoc is. They don't understand
packages. What is a jar? How do application servers work? Etc, etc, etc. It
is starting from ground zero with all the complexities of learning a new
language.  Sure they only have to dip their toes in Java with the framework
you are suggesting, but none-the-less they DO need to start learning Java.

Note that I am not challenging Java being the right/wrong approach.



>And even if you have one hotshot who manages to cobble together a
homebrewed SOAP interface chances are only that one person understands it,
and when he takes a hike, EVERYBODY is stuck.  In fact, because it's written
in "hotshot RPG" you can't even hire someone to fix it, at least not without
a long learning curve.  At least if you use industry standard tools you can
hire a consultant to get you out of a bind.

The simple fact of the matter is that the same RPG programmers that couldn't
understand the "hotshot RPG code" are the same that couldn't download
TextPad (http://textpad.com) and install it on their PC. They are also the
same ones that would NEVER make it with the J2EE thin layer.  Rarely will
you be having the lowest common denominator of your RPG programmers doing
your web development or working on your SOA initiatives.



>It's also a new reality that these days you need to make sure you fnid the
right tool for the job, and that except in very specific situations, this is
no longer a pure RPG question.  Leave RPG for what it's good at, and learn
how to embrace the other technologies available.

The main variable you aren't weighing heavy enough is the introduction of a
new language. Not many that know Java will argue that it isn't a better tool
for web services/web pages.


Aaron Bartell

-----Original Message-----
From: java400-l-bounces+albartell=gmail.com@xxxxxxxxxxxx
[mailto:java400-l-bounces+albartell=gmail.com@xxxxxxxxxxxx] On Behalf Of Joe
Pluta
Sent: Monday, April 17, 2006 7:27 AM
To: 'Java Programming on and around the iSeries / AS400'
Subject: RE: Look Mom - No Application Servers

> From: albartell
> 
> The problem is now that the code needs to be change managed. Let's say 
> for the sake of argument that there are 5 production iSeries boxes 
> that need the new Java/PHP code. Let's also say that I have the first 
> version out there (installed manually) and have started to work on the 
> next version. At this point change management has to start and the 
> question becomes:

This presupposes that you are doing as much code in Java as you are in RPG<
and that the Java code changes as often as the RPG.  With a proper
framework, this isn't the case.  Sure, you need to manage and distribute the
code, but with a good framework, you'll do this LESS often than writing it
all from scratch, because you don't have the constant change associated with
reinventing the wheel.


> "When my application breaks how many people need to be involved to 
> debug it?
> (i.e. J2EE front end is calling RPG business logic through stored 
> procedures. Both Java guys are out this week so we can't fix it until 
> Monday)"

Again, the idea is that you put together a simple framework.  A "J2EE front
end" properly written is a couple of thousand lines of code, if that.  If
your RPG folks can't understand the code in a simple JSP framework, there's
no way they can write a SOAP envelope.

And even if you have one hotshot who manages to cobble together a homebrewed
SOAP interface chances are only that one person understands it, and when he
takes a hike, EVERYBODY is stuck.  In fact, because it's written in "hotshot
RPG" you can't even hire someone to fix it, at least not without a long
learning curve.  At least if you use industry standard tools you can hire a
consultant to get you out of a bind.


> I lived through such a challenge in a medium sized shop (25 or so 
> programmers). It can get messy/expensive/cumbersome fast when new 
> languages are introduced.  A shop just needs to make sure it is a well 
> thought out decision and ensure it fits with their long-term IT 
> strategy and not a short term "I found it free online" fix.

It's also a new reality that these days you need to make sure you fnid the
right tool for the job, and that except in very specific situations, this is
no longer a pure RPG question.  Leave RPG for what it's good at, and learn
how to embrace the other technologies available.

Joe

--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/java400-l.