This is a pretty poor argument, Aaron. An app server is no more work than
Apache.
I am not talking about Apache, I am talking about the 5250 application stack
- I should have clarified. How does that change your comment back to me?
That's part of the beauty of the Java stack; all of the enterprise level
functions are standardized, unlike just about any other stack.
There are very few, if any, Java stacks that I have seen that give you an
enterprise environment out of the gates. Everything is needing to be piece
mealed together. Maybe that is my fault for trying to live too much in the
open source space? Maybe EGL is the first that I will experience. What
other framework environments have you worked with in Java that are
enterprise ready - specifically DB conn pooling - right out of the box?
Granted it doesn't take much to get to the DB conn pooling point, but I have
never seen it out of the box, and I have always had problems with it
depending on the collection of Java software needed to produce an
application (i.e. MyFaces/Tapestry, Hibernate). I will be glad to be proved
wrong on this point and accept any education you can give me.
Sorry, Aaron, but you're going to have to lose your aversion to anything
that even looks like Java if you're going to have a credible argument in
this space.
You are missing my point. I use Java - a lot. I use it in places where it
is either a client requirement (usually meaning I am NOT working with i5OS
and inherrently not RPG), or where RPG just doesn't make sense (i.e.
building graphical charts, communicating with the desktop, etc). Our
disagreement is WHERE to use Java and app servers vs. what you are
suggesting. In my argument I am conveying that it might not be a "WHERE"
situation, because IBM _can_ develop something that doesn't require Java.
Does Java=Bad? No. Java equals changing your IT infrastructure which *can*
be bad. When I say "bad" I simply mean a whole lot of time was spent
changing infrasturcture without as much payback as what should have been
(talking in the long run).
Which article? From my April article
(
http://www.ibmsystemsmag.com/i5/april07/developer/12353p5.aspx):
It was one that had a place to enter a customer number, and then you could
click on an order, and then you could click on a line item - all on the same
page. I just read it last week and am nearly 100% sure it was your article
(I remember that grinning photo of you staring back at me ;-). Does that
ring any bells? Maybe it was for a different trade rag.
You're talking about objective??? When your primary argument has been "it
has Java in it, so it must be bad!" Well, pleased to meet you Mr. Pot, I'm
Mr. Kettle! <grin>
You are putting words in my mouth. My argument is this: IBM *should* be
providing us solutions with the same simplicity as the 5250 stack, but they
are instead listening to vendors clamoring for platform independence. Most
RPG shops don't give a rip about platform independence, and even though THEY
haven't asked for it, it is what IBM provides as the GUI solution. If IBM
were to provide a proprietary desktop GUI that was completely run from RPG
(like Client Access), I think it would take off like wildfire for internal
applications!
I would sum up our disagreement to the fact that we both think Java can play
a role in the iSeries IT infrastructure (yes, I do think Java can be used in
a company), but the median as to where that should be is ENTIRELY different
in both of our minds - I will leave it at that.
Here's the 64,000 dollar question: was I right about WDSC or not?
You won't find me fighting against this point. I love WDSC. I can easily
deal with it's short comings (i.e. crashes, bugs, etc) because it isn't used
at run-time and I can always go back to SEU/PDM in a pinch. To sum it up,
development tools live in a separate space than a software stack - though
the lines are blurring more and more on that point.
<joe>
Seriously, Aaron, your almost pathological hatred of Java is blinding you to
the best set of solutions on the planet. No, I don't think this could be
done using RPG/C/C++ (C? C++? Who programs in those these days?). They
would have had to rewrite all of the J2EE stuff such as security and
connection pooling, which would have been a horrendous waste of resources.
They would have had to reinvent JavaServer Faces in RPG, which neither
CGI-DEV or RPGSp really supports (you have to really look into the JSF
support for both client-side and server-side to see what it does).
</joe>
IBM, IMO, has their fingers very involved in JSF and supporting technologies
- thus consuming A LOT of their time. They aren't just taking JSF for
"free" off the shelf. For those that are curious, you can see how some of
the different specifications operate by going here:
http://jcp.org/en/jsr/detail?id=252 (JSF spec).
As to your comment about it not being able to be done with a mix of RPG and
C/C++, well I don't really know how to answer that given my respect of your
knowledge. It *can* be done in those languages, IBM just choose to do it in
Java for platform independence sake.
Aaron Bartell
http://mowyourlawn.com
midrange.com
